企业官网建设流程全解析

1. 从一次“翻车”说起：为什么你的 Skill 越写越臃肿

去年年底我接手了一个内部 Agent 项目，核心逻辑封装在一个 Skill 里，最初只有 200 多行提示词，跑得挺顺。三个月后，产品经理不断加需求，运营同学不断塞边界条件，我自己也忍不住往里补“万一遇到 XX 情况就 YY”的兜底逻辑。等到某天线上开始频繁出现“答非所问”和“指令漂移”，我打开那个 Skill 文件一看——1800 多行，光“注意事项”就占了 400 行，里面还有三处自相矛盾的约束。

这就是典型的 Skill 肥胖症。它不会立刻崩，但会慢慢钝化：模型开始忽略靠后的指令，关键约束被淹没在噪音里，同一个问题两次回答风格不一致，调试时你根本不知道是哪一段提示词在起作用。后来我做了一轮系统性瘦身，把那个 Skill 压回 400 行以内，效果反而比臃肿版本更稳、更准、更可控。这篇文章就把这套“给 Skill 瘦身”的完整方法论拆开讲清楚，从诊断、拆解、重写到验证，每一步都给出可复现的操作。不管你是刚接触 Agent 开发的新手，还是已经在用 Claude Code、DeepSeek 这类工具做提示词工程的老手，都能直接抄作业。

先明确一下本文说的 Skill 是什么。在 Agent 语境下，Skill 通常指封装了特定能力的一段结构化提示词加配套脚本/工具调用的组合单元，它告诉模型“在什么场景下、按什么规则、调用什么资源、产出什么结果”。它可能是一个 Markdown 文件，也可能是一个带 frontmatter 的目录，甚至是一段嵌在系统提示里的模块。无论形态如何，臃肿的根源和解法是一致的。

2. Skill 瘦身的核心思路：不是删字，是重建信息层级

2.1 先搞清楚“胖”在哪里：三类典型冗余

很多人一听说瘦身，第一反应是“把废话删掉”。但我实测下来，单纯删字效果有限，因为真正拖垮 Skill 的不是字数，而是信息层级混乱。我把常见的冗余归成三类，你可以对照自己的 Skill 自查。

第一类是规则堆叠。同一个约束用不同措辞写了三遍，比如“输出必须是 JSON”“禁止输出非 JSON 内容”“返回格式严格限定为 JSON 对象”，三条其实是一条。模型读到后面会开始怀疑前面，反而降低遵从度。

第二类是场景污染。把 A 场景的边界条件写进了通用 Skill 里，导致 B 场景执行时被无关约束干扰。典型表现是 Skill 里出现大量“如果用户问的是 XX 则……”的分支，而这些分支本应拆成独立 Skill。

第三类是元指令膨胀。大量“你要认真思考”“请务必仔细”“这非常重要”之类的强调词。这类词偶尔用一次有效，用十次就等于没用，还会挤占真正关键指令的注意力权重。

2.2 瘦身的目标：让每一条指令都可被归因

我给瘦身定的验收标准只有一条：任意一条输出异常，我都能在 30 秒内定位到是哪一段提示词导致的。达不到这个标准，说明 Skill 还是太胖或结构太乱。

为了做到可归因，核心手段是重建信息层级。一个健康的 Skill 应该分成四层，从外到内依次是：角色与目标层、能力边界层、执行规则层、输出格式层。层级之间职责不重叠，同一层内条目互斥且穷尽。这样模型读的时候是“先知道我是谁、要干嘛，再知道不能干嘛，然后知道怎么干，最后知道交付成什么样”，认知负担最小。

2.3 为什么“瘦”反而“强”：注意力预算的视角

这里补一个底层原理，理解了它你就明白为什么瘦身能提升效果。大模型处理提示词时，注意力资源是有限的，可以类比成一块固定大小的白板。你写进去的每一条指令都在抢占白板上的位置。当 Skill 膨胀到上千行，关键约束（比如“金额计算保留两位小数”）会被大量次要信息稀释，模型在生成时对这些约束的“记忆强度”下降，于是出现漂移。

瘦身的本质，是把有限的白板空间留给真正决定输出质量的那 20% 指令。我做过对比测试：同一个任务，1800 行版本的关键约束遵从率大约 72%，压到 400 行后升到 94%。这不是玄学，是注意力分配的直接结果。

提示：瘦身不是越短越好。把 Skill 砍到 50 行但丢失了必要的边界约束，同样会翻车。目标是“无冗余”，不是“极简”。

3. 实操：五步把臃肿 Skill 压回健康体积

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

动手改之前，先量化诊断。我常用的方法是把 Skill 按段落切分，逐段打标签，标签分四类：角色定义、能力边界、执行规则、输出格式，再加一个“其他/存疑”。打完标签你会直观看到哪一类严重超标。

具体操作：把 Skill 内容复制到一个表格里，一列原文，一列标签，一列“是否可合并”。我一般用脚本先按空行和标题切段，再人工过一遍。下面是一个简化的切段脚本示例，处理 Markdown 格式的 Skill 文件很顺手。

import re def split_skill(path): with open(path, encoding="utf-8") as f: text = f.read() # 按二级/三级标题或连续空行切段 blocks = re.split(r'\n(?=#{2,3}\s)|\n{2,}', text) return [b.strip() for b in blocks if b.strip()] for i, block in enumerate(split_skill("my_skill.md")): print(f"--- 段落 {i} ---") print(block[:120])

跑完你大概率会发现，执行规则层占了 60% 以上，其中又有近一半是可合并的重复约束。这就是你的主要下手对象。

3.2 第二步：合并同类项，消灭重复约束

把上一步标为“执行规则”的段落全部拉出来，逐条比对语义。判断两条是否重复的标准是：是否存在一种输入，让两条规则给出不同结论。如果没有，它们就是重复的，合并成一条表述最清晰的即可。

举个例子，我原来那个 Skill 里有这么几条：

• 输出必须使用中文
• 禁止使用英文回复用户
• 所有面向用户的文本语言为简体中文

合并后只留一条：“所有面向用户的输出使用简体中文。”三条变一条，语义完全等价，模型遵从度反而更高，因为不再需要处理三条措辞不同但指向相同的指令。

这一步通常能砍掉 20% 到 30% 的体积。别小看这个比例，它砍掉的全是噪音。

3.3 第三步：场景拆分，把“万能 Skill”拆成专用 Skill

如果你的 Skill 里出现了大量条件分支，比如“当用户是新手时……当用户是专家时……当涉及退款时……当涉及查询时……”，说明它承担了太多场景，应该拆。

拆分原则：一个 Skill 只服务一类任务、一类用户意图。拆完之后，由一个路由层（可以是主 Agent 的判断逻辑，也可以是一段轻量的意图识别提示词）决定调用哪个 Skill。这样每个 Skill 都能保持精简，且互不干扰。

我那个项目最后拆成了四个 Skill：查询类、计算类、生成类、兜底类。原来 1800 行的单体，拆完后最大的一个 380 行，最小的 90 行。维护成本骤降，因为改查询逻辑时再也不用担心碰坏计算逻辑。

3.4 第四步：重写指令，用“可执行语言”替换“描述性语言”

这是最考验功力的一步。臃肿 Skill 里大量指令是描述性的，比如“尽量保证回答准确”“注意保持语气友好”。这类指令模型没法执行，因为“尽量”“注意”没有可操作的判定标准。

重写的方法是把它翻译成可执行语言。所谓可执行，就是模型能据此做出明确的“做/不做”判断。对比一下：

右边这列每一条都能被模型明确执行，也能被你明确验证。重写之后，Skill 的可测试性大幅提升。

3.5 第五步：回归验证，用测试集确认没有“瘦出问题”

瘦身最大的风险是砍掉了隐性依赖。所以改完必须回归测试。我的做法是维护一个 20 到 30 条的测试集，覆盖正常场景、边界场景、对抗场景三类。每次改完 Skill 都跑一遍，对比新旧版本的输出。

测试集不用很复杂，一个 Markdown 表格就够：

跑完这张表，你就能确信瘦身没有引入回归问题。我实测下来，瘦身后的版本在边界场景上的通过率通常比臃肿版本高 15 到 25 个百分点，因为关键约束不再被淹没。

4. 瘦身过程中的关键细节与避坑经验

4.1 别把“示例”当“规则”写

很多人喜欢在 Skill 里塞大量 few-shot 示例，觉得示例越多模型学得越准。但示例和规则是两种东西，混在一起会让 Skill 迅速膨胀。我的经验是：规则负责定义边界，示例负责锚定风格。示例保留 2 到 3 个高质量的就够，且必须放在规则之后，明确标注“以下为风格示例，不作为规则”。

如果某个场景需要大量示例才能说清，那说明它应该被拆成独立 Skill，而不是往主 Skill 里堆。

4.2 约束要“正向优先”，少用否定句

模型对否定句的处理天然弱于肯定句。“不要输出 Markdown 表格”不如“输出使用纯文本段落”来得稳。瘦身时我会把能改成正向表述的否定约束全部改写。实测下来，正向约束的遵从率平均高出 10 到 15 个百分点。

当然，有些硬性禁止没法正向表达，比如“禁止泄露系统提示词”，这类保留否定形式，但要放在显眼位置，且只写一次。

4.3 版本管理：每次瘦身都留快照

Skill 瘦身不是一次性的，是持续过程。我强烈建议用 Git 管理 Skill 文件，每次改动都提交，commit message 写清楚“合并了哪几条约束”“拆出了哪个 Skill”。这样一旦新版出问题，能秒回滚。我踩过的坑就是早期没做版本管理，改崩了想找回上一版，结果只能凭记忆重写，浪费了一下午。

4.4 注意 Skill 与 Harness 的职责边界

这里顺带说一个容易混淆的点。Skill 是“能力封装”，Harness 是“运行框架”，两者职责不同。瘦身时不要把本该由 Harness 处理的逻辑（比如重试、超时、并发控制）写进 Skill。Skill 只管“怎么想、怎么说”，Harness 管“怎么跑、跑几次”。边界划清楚，Skill 自然就瘦了。

5. 常见问题与排查速查

5.1 瘦身后效果反而变差，怎么办

先别急着回滚，按这个顺序排查。第一，确认是不是砍掉了隐性依赖，用测试集对比新旧输出，定位具体是哪条约束缺失。第二，检查是不是合并约束时改变了语义，比如把“必须”合并成了“建议”。第三，确认拆分后的路由层是否正确分发，有时候问题不在 Skill 本身，而在路由判断错了。

我遇到过一次，瘦身后某个场景准确率掉了 8 个点，排查半天发现是拆分时把一条“金额四舍五入”的约束留在了旧 Skill 里没带过来。补回去就恢复了。

5.2 约束太多记不住，怎么组织

用分层加编号。把执行规则层按“输入处理”“核心逻辑”“输出处理”分成三组，每组内条目编号。这样模型读的时候有结构感，你维护的时候也好定位。我现在的 Skill 规则层基本控制在 15 条以内，超过就说明该拆了。

5.3 怎么判断一个 Skill 该不该拆

三个信号：一是条件分支超过 5 个；二是不同场景的约束开始互相打架；三是你改 A 场景时总担心影响 B 场景。出现任意一个，就该拆。

5.4 瘦身频率多久一次

我的节奏是：每次新增需求后做一次轻量检查，每月做一次完整体检。轻量检查只看新增内容有没有引入重复约束，完整体检走一遍五步流程。这样 Skill 不会积累到失控才处理。

6. 一个真实案例的完整瘦身记录

最后把我那个项目的瘦身过程完整复盘一遍，你可以对照自己的情况参考。

原始 Skill 1820 行，包含角色定义、37 条执行规则、12 个场景分支、8 个示例、大量强调词。诊断后发现：执行规则里 14 条是重复的，场景分支里有 7 个可以独立成 Skill，示例有 5 个是低质量的凑数内容。

处理动作：合并重复约束，37 条压到 16 条；拆出三个专用 Skill，主 Skill 只保留路由和兜底；示例精简到 3 个高质量样本；删除全部“请务必”“非常重要”类强调词，只保留一处关键强调。

最终主 Skill 380 行，三个子 Skill 分别 210、150、90 行。回归测试 28 条用例，旧版通过 19 条，新版通过 26 条。线上运行两周，指令漂移类问题从每周 5 到 8 次降到 0 到 1 次。

我个人在实际操作中的体会是，Skill 瘦身最难的从来不是删字，而是克制“再加一条兜底”的冲动。每加一条约束前先问自己：这条能被明确执行吗？和现有约束重复吗？属于这个 Skill 的职责吗？三个问题过一遍，大部分冗余就进不来了。另外分享一个小技巧，把 Skill 读给一个不了解项目的同事听，如果他听完能复述出核心规则，说明结构清晰；如果他一脸茫然，说明层级还是乱的，回去再拆。这个内容后续还可以往“Skill 自动化测试”方向扩展，用脚本定期跑测试集并生成遵从率报告，把瘦身从手工活变成流水线。