企业官网建设流程全解析

1. 从“臃肿”到“精悍”：一次Skill瘦身的完整复盘

先说说我为什么要折腾这件事。大概三个月前，我手头同时跑着好几个Agent项目，有基于Claude Code做代码审查的，有接DeepSeek API做文档摘要的，还有一个用Codex做自动化测试的。每个项目里都塞了一堆Skill——就是那种告诉Agent“你该怎么干活”的提示词模块。一开始觉得挺爽，功能越加越多，Skill文件从几百行膨胀到两三千行，结果呢？Agent开始犯迷糊了。

最典型的表现是：你让它改个函数名，它给你把整个文件重写了；你让它查个日志，它反手给你生成一段Python脚本。明明Skill里写了“只做最小改动”，它就跟没看见一样。后来我拿几个标准测试用例跑了一遍——就是圈子里常说的“鹈鹕骑自行车”那类提示词测试——发现准确率从最初的85%掉到了60%出头。这时候我才意识到，Skill不是越多越好，臃肿的Skill正在拖垮Agent的表现。

这篇文章就是把我这几个月踩过的坑、试过的方案、最终跑通的那套瘦身方法论完整拆开讲。不管你是刚接触Agent开发的新手，还是已经在调提示词的老手，只要你的Skill也遇到了“越加越笨”的问题，这篇内容应该能帮你省下不少试错时间。核心关键词就几个：Skill瘦身、Agent表现优化、提示词工程、Claude Code、DeepSeek。我会从设计思路讲到实操步骤，再把我遇到的那些奇葩问题和排查方法一并奉上。

2. 为什么Skill会越用越“胖”？先搞懂Agent的认知负荷

2.1 Skill的本质是什么，它和Agent、Harness到底什么关系

很多人刚入门的时候容易把几个概念搅在一起。我用一个生活化的类比来解释：Agent就像是一个刚入职的实习生，Harness是公司给他配的工位、电脑和办公软件，而Skill就是你写给这个实习生的岗位操作手册。手册写得越厚，实习生越容易翻到后面忘了前面。Harness和Agent的区别在于，Harness是运行环境层面的东西——比如Claude Code这个工具本身、DeepSeek的API调用框架、Codex的执行沙盒——它决定了Agent能做什么动作。而Skill是认知层面的东西，它决定了Agent在某个具体场景下应该怎么思考、怎么决策。

我见过不少项目，把本该放在Harness层面的逻辑硬塞进Skill里。比如“调用某个API时先检查网络状态”这种，明明是Harness该处理的，结果写进了Skill，导致每次Agent做决策都要多读几百个token的无关信息。这就是典型的职责错位。

2.2 臃肿Skill的三大典型症状

第一个症状是指令淹没。当你的Skill文件超过1500行，Agent在推理时真正需要的那条指令，很可能被淹没在大量“以防万一”的补充说明里。我做过一个粗略统计：在一个2000行的Skill中，核心指令大概只占15%，剩下的85%都是边界情况处理、示例、注意事项、格式说明。Agent每次调用都要把这2000行全部读一遍，注意力被严重稀释。

第二个症状是规则冲突。这个特别隐蔽。比如你在Skill开头写了“保持简洁，只输出必要内容”，结果在中间某个章节又写了“为了确保用户理解，每个步骤都要详细解释”。这两条规则在不同场景下都合理，但Agent同时读到就会犯迷糊。我遇到过最离谱的一次，Agent在同一个回复里先给我一段极简的代码，然后又附了三百字的解释，完全自相矛盾。

第三个症状是示例过载。很多人喜欢在Skill里塞大量few-shot示例，觉得例子越多Agent学得越好。但实际上，当示例超过5-6个，Agent会开始“模仿示例的表面形式”而不是“理解示例背后的逻辑”。比如你给了10个“用户问A，你答B”的示例，Agent遇到A的变体A'时，会硬套B的格式，哪怕内容完全不匹配。

2.3 瘦身不是删减，而是重构信息层级

这里要澄清一个误区：Skill瘦身不等于简单地把内容删掉。我一开始也犯过这个错误，直接把Skill从2000行砍到500行，结果Agent连基本任务都完不成了。后来才明白，瘦身的核心是重构信息层级——把“每次都需要的信息”和“按需查阅的信息”分开，把“规则”和“示例”分开，把“核心逻辑”和“边界处理”分开。

打个比方，原来的Skill像一本没有目录的厚书，Agent每次都要从头翻到尾。瘦身后的Skill应该像一张思维导图：主干清晰，分支按需展开。具体怎么做，下一章我会详细拆解。

3. 瘦身方案设计：三层分离架构

3.1 核心层、规则层、参考层的职责划分

我最终跑通的方案是把Skill拆成三层。核心层只保留最关键的3-5条指令，控制在200字以内，这部分是Agent每次都必须读的。规则层包含具体的操作规范和约束条件，大概500-800字，Agent在需要做决策时查阅。参考层放示例、边界情况、格式模板，这部分不直接进入Agent的推理上下文，而是通过工具调用按需检索。

这个设计的逻辑依据来自Agent的上下文窗口特性。不管是Claude Code还是DeepSeek，上下文窗口都是有限资源。你把2000行全部塞进去，核心指令的“注意力权重”就被稀释了。而三层分离之后，核心层始终占据最优先的注意力位置，规则层在需要时加载，参考层几乎不占用常驻上下文。

我实测下来，同样的任务集，三层架构的Skill比原始臃肿版本准确率提升了23个百分点，从62%回到了85%以上。而且响应速度也有明显改善，因为Agent不需要每次处理那么多token了。

3.2 什么内容该放哪一层：判断标准与实操方法

判断一条内容该放哪层，我总结了一个简单的测试：如果这条内容缺失，Agent会不会完全无法完成任务？如果会，放核心层。如果只是可能导致结果不够完美，放规则层。如果只是影响边缘情况的处理，放参考层。

举个例子。“你是一个代码审查助手”这句话，缺失了Agent就不知道自己的角色，必须放核心层。“审查时优先关注安全漏洞，其次是性能问题”这条，缺失了Agent还是会审查，只是优先级可能不对，放规则层。“如果遇到SQL注入风险，按以下格式输出警告”这种，放参考层。

实操的时候，我建议先把现有Skill的所有内容列出来，逐条打标签。我自己的Skill从2000行拆完后，核心层只有180字，规则层720字，参考层拆成了5个独立的检索文档。Agent的表现不降反升。

3.3 为什么这种架构能提升Agent表现：注意力机制视角

从注意力机制的角度看，Agent在处理上下文时，每个token获得的注意力权重是不一样的。靠近开头和结尾的内容通常获得更高权重，中间部分容易被忽略。臃肿Skill的问题在于，核心指令往往不在开头也不在结尾，而是散落在中间，自然就被“淹没”了。

三层架构把核心指令固定在开头，规则层紧随其后，参考层移出常驻上下文。这样Agent的注意力资源集中在了最该关注的地方。另外，参考层通过工具调用按需加载，相当于把“记忆”变成了“检索”，这更符合Agent的工作方式——它不需要记住所有细节，只需要知道“遇到什么情况该去哪里查”。

4. 实操：一步步给Skill做减法

4.1 第一步：给现有Skill做“体检”

别急着动手删。先拿一个标准测试集跑一遍现有Skill，记录Agent在哪些任务上表现好、哪些表现差。我用的测试集包括10个代码审查任务、10个文档摘要任务、5个多轮对话任务。每个任务都有明确的预期输出，方便量化对比。

跑完之后，你会得到一张“问题分布图”。比如我的数据显示，代码审查任务中“遗漏安全漏洞”占比最高，文档摘要任务中“输出格式不一致”最严重。这些问题就是你瘦身的重点方向。

同时，用工具统计一下Skill文件的token分布。我用的方法很简单，把Skill按章节切分，分别计算每个章节的token数。结果发现“示例”章节占了42%，“注意事项”占了28%，真正核心的“任务指令”只有12%。这个数据直接告诉我：该砍哪里。

4.2 第二步：核心层提炼——把2000字压到200字

核心层提炼是最考验功力的环节。我的方法是“三问法”：第一问，Agent如果不读这条，能不能知道自己是干什么的？第二问，Agent如果不读这条，能不能知道最终输出什么？第三问，Agent如果不读这条，会不会做出完全错误的行为？

只有三个问题都回答“会”的内容，才留在核心层。按这个标准，我原来的Skill里只有4条内容合格：角色定义、任务目标、输出格式要求、绝对禁止事项。其他全部下移。

写核心层的时候有个技巧：用短句，不用长句。比如“你是一个代码审查助手，负责找出代码中的安全漏洞和性能问题”就比“你的职责是对用户提交的代码进行全面的审查，重点关注安全性和性能方面的潜在问题”要好。前者28个字，后者42个字，信息量一样，但前者Agent处理起来更快更准。

4.3 第三步：规则层重组——按决策场景而非功能模块组织

规则层的组织方式很关键。很多人习惯按功能模块分，比如“代码审查规则”“文档处理规则”“对话规则”。但Agent在实际工作中不是按模块切换的，而是按场景决策的。所以我改成按决策场景组织：当Agent需要判断“要不要修改代码”时，加载一组规则；当Agent需要判断“输出什么格式”时，加载另一组规则。

这样改的好处是，Agent在某个决策点上只需要关注相关的几条规则，而不是把整个规则库都读一遍。我实测下来，按场景组织的规则层，Agent的规则遵循率从71%提升到了89%。

4.4 第四步：参考层外置——用检索代替记忆

参考层的外置我用了两种方式。对于结构化的内容，比如输出格式模板、错误码对照表，我做成JSON文件，Agent通过读取文件的方式获取。对于非结构化的内容，比如边界情况处理示例，我做成向量检索，Agent根据当前上下文检索最相关的2-3个示例。

这里有个坑要注意：检索的粒度不能太细，也不能太粗。太细了检索结果碎片化，Agent拼不起来；太粗了检索结果太长，又回到了臃肿的老路。我的经验是每个检索单元控制在200-400字，正好是一个完整的示例或一条完整的规则说明。

4.5 第五步：验证与迭代——用数据说话

瘦身完成后，必须用同一套测试集重新跑一遍。我的对比数据是这样的：瘦身前准确率62%，瘦身后第一版准确率78%，调整检索粒度后第二版83%，优化核心层措辞后第三版87%。整个过程迭代了四轮，每轮都有明确的改进方向。

这里要提醒一点：不要一次改太多。我第一轮同时改了核心层、规则层和参考层，结果准确率反而掉了。后来改成每轮只改一层，才能准确判断哪个改动有效、哪个改动无效。

5. 避坑指南：我踩过的五个坑

5.1 坑一：把“瘦身”做成了“阉割”

我第一版瘦身直接把Skill从2000行砍到300行，结果Agent连基本的任务边界都搞不清了。用户问一个超出范围的问题，它居然硬答。后来才明白，瘦身是重构信息层级，不是删除信息。该有的约束一条都不能少，只是换了个存放位置。

5.2 坑二：核心层写成了“口号”

一开始我的核心层写的是“你是一个专业的、高效的、严谨的代码审查助手”。这种形容词堆砌对Agent来说几乎是噪音。后来改成“你负责审查代码中的安全漏洞和性能问题，输出格式为：问题类型、严重程度、修复建议”，Agent的表现立刻稳定了。核心层要写“做什么”和“输出什么”，不要写“你有多专业”。

5.3 坑三：规则层规则之间互相打架

这个坑特别隐蔽。比如一条规则说“优先保证准确性”，另一条说“响应速度要快”。单独看都没问题，但Agent同时读到就会纠结。我的解决方法是给规则加优先级标签，明确告诉Agent“当规则冲突时，以哪条为准”。

5.4 坑四：参考层检索结果不相关

检索粒度没调好的时候，Agent经常检索到不相关的示例，然后硬套。比如用户问的是Python代码审查，检索出来的却是JavaScript的示例。后来我在检索前加了一层“场景过滤”，先判断当前场景，再在对应场景的示例库里检索，准确率大幅提升。

5.5 坑五：忘了测试多轮对话场景

单轮任务的测试很容易通过，但多轮对话才是真正的考验。Agent在第三轮、第四轮的时候，很容易忘记核心层的指令，因为上下文里已经堆了很多对话历史。我的解决方法是每轮对话开始时，把核心层重新注入一次。虽然增加了少量token消耗，但换来了多轮场景下准确率从54%到82%的提升，非常值得。

6. 常见问题速查与排查技巧

6.1 Agent突然不遵循核心指令了怎么办

先检查上下文长度。如果对话历史超过了一定阈值，核心指令的注意力权重会被稀释。解决方法是在每轮对话开始时重新注入核心层，或者用系统消息的方式把核心层固定在最高优先级位置。

6.2 瘦身后Agent变得“不敢做事”了怎么办

这通常是因为规则层约束过严。检查一下规则层里有没有“必须”“绝对”“严禁”这类词用得太密。Agent对强约束词很敏感，太多强约束会让它变得保守。适当把一些“必须”改成“建议”，把“严禁”改成“避免”，给Agent留出合理的判断空间。

6.3 参考层检索总是慢半拍怎么办

检索延迟主要来自两个方面：检索库太大，或者检索逻辑太复杂。我的优化方法是给检索库建索引，按场景、任务类型、关键词三个维度预分类。检索时先走索引定位，再做语义匹配。优化后检索延迟从平均800ms降到了200ms以内。

6.4 怎么判断瘦身是否“过度”了

一个简单的判断标准：拿10个典型任务跑一遍，如果Agent在超过3个任务上出现了“完全无法完成”的情况，说明瘦身过度了。如果只是“完成得不够好”，那属于正常波动，可以通过微调规则层来优化。

6.5 一个容易被忽略的细节：Skill文件的编码格式

这个坑我踩了整整两天。Skill文件里如果有特殊字符或者不统一的换行符，某些Agent框架解析时会出问题，导致部分指令“丢失”。表现就是Agent有时候遵循指令，有时候不遵循，看起来像随机行为。后来统一用UTF-8编码、LF换行符之后，问题消失了。如果你也遇到Agent行为“时好时坏”，先检查一下文件编码。

7. 瘦身之后：Agent表现提升的量化对比与长期维护

7.1 实测数据：瘦身前后的关键指标对比

我把瘦身前后的数据整理了一下，方便你直观感受差异。测试集包含25个任务，覆盖代码审查、文档摘要、多轮对话三个场景。

token消耗的下降特别值得关注。瘦身后每次调用少消耗1800个token，按每天1000次调用算，一个月能省下5400万token。如果用DeepSeek API，这部分的成本节省相当可观。

7.2 长期维护：怎么防止Skill再次“发胖”

瘦身不是一劳永逸的。项目迭代过程中，新需求会不断冒出来，Skill很容易再次膨胀。我给自己定了几条规矩：第一，任何新增内容必须先判断属于哪一层，不能直接往核心层塞。第二，每月做一次Skill“体检”，统计各层token占比，核心层超过300字就预警。第三，新规则上线前必须跑回归测试，确认不会影响已有任务的表现。

另外，我建议把Skill文件纳入版本管理。每次修改都记录改了什么、为什么改、测试结果如何。这样当Agent表现出现波动时，可以快速定位到是哪次修改引入的问题。

7.3 什么情况下该考虑重新设计而不是继续瘦身

如果你的Skill已经瘦身过两轮，但准确率还是上不去，可能问题不在Skill本身，而在Agent的Harness配置或者任务设计。比如Harness的工具调用接口设计不合理，Agent需要花大量精力在“怎么调工具”上，自然就没精力关注Skill里的指令了。这时候应该回头检查Harness层面，而不是继续在Skill上折腾。

我在实际项目中的体会是，Skill瘦身的收益在第一个月最明显，之后边际效益递减。当你把准确率从60%拉到85%之后，再想往上提升，靠的就不是瘦身了，而是更精细的规则设计和更高质量的参考示例。所以瘦身要趁早做，但也不要指望它能解决所有问题。