企业官网建设流程全解析

1. 先想清楚一个问题：为什么通用大模型还不够用

先说个实际场景。我拿 Claude 写代码有段时间了，发现一个问题：让它写一个不太常见的算法、处理一段特殊格式的数据，它也能写，但总差那么一点。不是不会，是“不会好好干”——要么用了过时的写法，要么忽略了我这边的环境约束，要么把团队里的编码规范全忘了。

刚开始我以为是提示词写得不够好，后来发现不是。问题在于，我每次都在让模型从零开始理解“我所在这个项目里做事的方式”，可这些东西明明是可以沉淀、可以复用的。通用的对话模型是拿海量公共数据训练出来的，它懂全世界的常见知识，但它不懂你项目里的约定、你团队的习惯、你那个业务域里的黑话和禁忌。

Agent Skills 解决的就是这个问题。

它的核心思路很简单：把某一类任务的做法——包括操作步骤、规则约束、脚本工具、参考资料——打包成一个结构化的“技能包”，放进一个技能目录里。需要的时候，智能体自动检索并加载对应技能，用技能里规定的方式去干活，而不是凭空生成一套做法。

我最初注意到这个概念，是因为官方在推 Agent Skills 这种模式，后来发现它其实是整个 AI Agent 工程化里非常关键的一环。如果你只是拿大模型做聊天玩具，无所谓；但如果你想让 AI 进入你的业务流程、帮你处理真实的工作，那“技能体系”这关迟早要过。

我在这篇文章里会用一套从零搭建的完整过程，把 Agent Skills 的原理、结构、实现细节和踩坑经历都讲一遍。不管你是刚接触智能体开发，还是已经在用各类 Agent 框架，这篇文章应该都能给你提供点实际参考。

1.1 大模型“什么都会一点”背后的真实困境

咱们先认真聊聊，为什么通用模型会在特定任务上翻车。

大模型的训练目标决定了它的输出是“基于概率的合理续写”。你给它一个任务，它基于训练时看到的无数相似问题，合成一个看起来合理的答案。听起来没问题对吧？问题在于，你的任务在它训练集里“相似样本”太少了。

举个例子。我问它“写一段Python代码，把文件夹里的文件按创建时间排序”，这种任务它见多了，写得又快又好。但我换个问法：“按我们项目里的时间戳命名规则，把归档目录里的日志文件按批次编号整理到季度目录下，旧的保留最近三份”，合理性和可用性就明显下降。再叠加上我团队里实际使用的依赖库版本、内部工具函数、目录约定，模型基本就是全靠猜了。

这不是模型“不够聪明”，而是信息不足。它不知道你们项目里有没有现成的工具函数，不知道日志批次是怎么编号的，不知道季度目录的命名习惯。它只知道“通用做法”，而通用做法在你的具体场景里，往往不是最优做法，甚至可能是错误做法。

这就是为什么大模型在 demo 里看起来无所不能，一接入生产就原形毕露。

1.2 提示词、微调、技能：三种方案到底差在哪

面对上面这个问题，常见的解法有三条路：写更长的提示词、做微调、搞技能包。

写提示词是最直接的，把规则、范例、约束全部写进 system prompt 里。但它有个天花板：上下文窗口是有限的，你不可能把所有项目知识都塞进去。而且一份几千字的提示词，模型在生成时真的会逐条遵守吗？实测下来，越靠后的规则被忽略的概率越高——模型的注意力是会被稀释的。

微调是另一条路，把特定领域的知识“训练”进模型参数里。听着很优雅，但成本高得吓人：需要准备大量高质量训练数据、需要投入计算资源、需要维护多个模型版本，而且一旦业务规则变了，你得重新训练。除非你是大厂或者有专门的算法团队，否则这条路对绝大多数项目来说都不现实。

技能路径则是一种中间路线。它不像微调那样改变模型本身，也不像提示词那样把所有信息一次性灌进去，而是把“做某类任务的全部知识和工具”组织成一个独立单元，模型需要时才加载。

打个比方：提示词是端上一桌菜让你全部吃掉，微调是干脆把厨师换掉让他只学你这家店的口味，技能则是把一个料理包放在冰箱里，客户点到这道菜时，按说明加热就好。

2. Agent Skills 的结构拆解：一个技能包到底是什么

要搞清楚 Agent Skills，得先搞清楚一个技能包的物理组成。

一个标准技能包是一个目录，里面通常包含三类东西：SKILL.md文件、脚本文件、资源文件。三者分工明确，缺一不可。

这一点跟很多人想的不太一样。很多人以为“技能”就是一段更长的提示词，把好的 prompt 存成文件就是技能了。没那么简单。真正的 Agent Skills，核心是“文档 + 代码 + 数据”的组合体，模型在技能的引导下，不只是“知道该怎么做”，而是能真正调用工具去执行。

我这么说可能有点抽象，直接看目录结构就明白了。

2.1 一个标准技能包的目录长什么样

下面是一个我实际用过的技能包结构，用来做技术方案文档的标准化输出：

document-planner/ ├── SKILL.md ├── scripts/ │ ├── generate_outline.py │ └── check_requirements.py ├── references/ │ ├── template.md │ └── examples/ │ ├── case_1.md │ └── case_2.md └── assets/ └── style_guide.md

SKILL.md是技能包的门面，也是智能体最先读取的文件。它负责告诉模型：这个技能是干什么的、适用于哪些场景、工作流程是什么、有哪些约束和禁忌。其余目录里放脚本和参考资料，用来支撑技能的落地。

为什么脚本和参考资料这么重要？因为纯文字描述是模糊的。你说“输出一份符合规范的技术方案”，模型可能对“规范”有自己的理解；但如果你在 references 里放了一份公司实际使用的模板，在 scripts 里放了一个检查脚本来校验输出是否满足要求，那这个技能的可用性就完全是另一回事了。

2.2 SKILL.md 是所有逻辑的核心：它该怎么写

SKILL.md不能随便写，它有相对固定的格式要求。我一般用这样的结构：

--- name: document-planner description: 在需要产出技术方案文档时使用。帮助整理文档大纲、填充关键章节、并校验方案完整度。适用于设计文档、架构评审文档、敏捷迭代方案等场景。 --- # 技能说明 这个技能用于生成结构化的技术方案文档… # 工作流程 1. 先询问用户方案背景和目标 2. 根据模板生成大纲 3. 逐章填充内容并提醒用户补充缺失信息 4. 最后用脚本校验完整度 # 关键规则 - 所有方案必须有背景、目标、方案对比、风险分析四个部分 - 涉及技术选型时必须给出至少两个候选方案并对比 - 不使用“大概”“可能”等模糊措辞 # 禁止事项 - 不要编造测试数据 - 不要在没有用户确认的情况下直接推荐付费商业服务

name是技能的唯一标识，description则决定了这个技能会不会被触发。

这里的description值得多说两句。智能体在收到用户请求后，会遍历技能目录里所有技能包的描述信息，判断哪个技能跟当前任务相关。如果你的 description 写得过窄，模型可能找不到它；写得过泛，它又会被错误触发。

我见过不少人的技能包翻车，翻就翻在 description 上。有人写“用于技术文档的场景”，这个描述太宽，模型在用户问“帮我写封邮件”的时候也可能认为这个技能相关，结果加载了一个跟任务不相干的技能。正确做法是写清触发条件，甚至可以把反例也写上，比如“不要在用户只询问简单问题时使用”。

2.3 脚本和资源文件：从“建议”到“执行”的跨越

能真正区分一个技能包是“玩具”还是“生产力工具”的，是它是否包含可执行逻辑。

资源文件不必多说，模板、示例、规范文档都是资源文件，它们给模型提供了上下文参考。但脚本文件，才是让技能包“活”起来的关键。

我之前在做一个日志分析技能时，一开始只有 SKILL.md 和几个参考文档。模型每次生成的结论都模棱两可，分析也不够深入。后来我加了一个stats.py脚本，能自动统计日志里各类错误出现的频次、时间分布、涉及的模块名单，然后让模型基于脚本输出的数据做结论。效果立竿见影。

这是因为大模型本质上是文本生成器，它不擅长精确计算，也不擅长处理大量结构化数据。但通过脚本做计算，模型只负责解读脚本输出结果并组织语言，这就把“精确的事情”交给了精确的工具，“理解的事情”留给了模型本身。

一句话总结：模型负责思考，脚本负责计算，资源负责提供依据。

3. 从零搭建一个 Agent Skill：完整实操过程

理论说完了，咱们上手做一个。

我选一个比较通用的技能场景来做示例：中文文案校对与风格统一。这个技能用来检查中文文案的常见问题，比如中英文之间缺空格、标点全角半角混用、长句不易读、特定术语不统一等等。

你要问为什么选这个示例？因为它不涉及具体的业务依赖，任何人拿到都能复现，而且足够实用。

3.1 第一步：定边界——这个技能到底管什么

很多人做技能的第一步是列“我要让这个技能做什么”，我建议反过来，先列“它不做什么”。

当时我给自己定的边界是这样的：

• 做得：中文文本规范性检查、风格一致性建议、长句拆分建议
• 不做：内容事实性审核（我不打算让模型判断用户写的产品描述是否属实）
• 不做：SEO 关键词分析（那是另一个技能的事）
• 不做：自动改写（这个技能只做“检查和建议”，不做“代写”）

为什么要先定边界？因为技能越聚焦，SKILL.md 里的规则就越明确，模型执行时就越不会跑偏。

技能粒度是个两难：粒度太小，技能包数量爆炸，管理和维护成本高；粒度太大，一个技能包塞了太多目标，模型容易顾此失彼。我的经验是，一个技能包只解决“一类任务”，同类任务再细分场景就通过参数或规则去区分，而不是拆成另一个技能。

3.2 第二步：写 SKILL.md 的实操模板

边界定清楚后，我开始写 SKILL.md。下面这份内容基本是我作为模板在用的，你可以根据自己的需求调整：

--- name: cn-copywriting-polish description: 检查中文文案的规范性和风格一致性。适用于博客文章、产品描述、公众号推文、活动文案等。当用户需要校对、润色、检查错别字、统一术语/中英文空格/标点时使用。如果用户是在做代码评审或询问技术架构，不要使用本技能。 --- # 技能说明 对中文文案进行规范性检查并给出修改建议。只做检查和提供修改建议，不直接代写或大段重写内容，除非用户明确要求。 # 检查清单 1. 中英文之间是否有空格（中文与数字之间不需要空格） 2. 全角标点与半角标点的使用是否统一，中文语境中句读应使用全角标点 3. 是否存在明显错别字（如“的地得”误用） 4. 是否有过长难句，是否建议拆分 5. 项目相关的术语是否保持一致 # 工作流程 1. 让用户提供文档，或要求用户粘贴内容 2. 运行 scripts/check_doc.py 获取文本统计数据和基础检查结果 3. 结合检查结果逐条给出建议 4. 最后用列表输出“修改建议汇总”，并标注每条建议的严重程度 # 输出格式 按以下格式输出： 检查概览：整体评价 + 问题数量 问题列表： - 严重度：高/中/低 | 位置：第x段第y行 | 问题：… | 修改建议：… 修改建议汇总：...

注意几个关键点：

description里我加了一句“不要使用本技能”的负向条件。这个非常重要——模型做技能匹配时，正例和反例都看到比只看正例匹配得更准。

另外我刻意写明了输出格式。给模型规定明确的输出格式，是提高稳定性最有效的手段之一。你让模型自由发挥，它每次发挥的都不一样；你给它一个固定框架，它就能每次都给你同样的交付结构。

3.3 第三步：脚本要解决什么样的问题

scripts/check_doc.py这个脚本，承担的是“模型不擅长”的任务：精确统计。

举个例子，让模型数一篇文章里到底允许多少处中英文之间缺空格的错误，它大概率数不对。因为模型是概率生成，不是准确的计算。但脚本可以。

这个脚本的功能我设计得比较克制，只做这几件事：

• 读取文本，统计总字符数、总段落数
• 用正则匹配中英文之间缺空格的位置
• 识别连续超过 90 字的长句
• 统计特定术语出现的次数（用于判断不统一的情况）
• 输出 JSON 格式的结构化结果

这里有个设计观念值得强调：不要让脚本做“判断”，让脚本做“统计”，由模型来做判断。

比如脚本输出“术语‘智能体’出现 12 次，‘AI 代理’出现 10 次”，合不合理？该不该统一？怎么改？这些判断交给模型，因为模型能理解上下文。但如果让脚本直接输出“术语不统一，需要把 AI 代理改成智能体”，一旦项目里这两个词有语境区分，脚本就歇菜了。

硬规则和软规则要分开。硬规则（如正则能精确判断的格式问题）脚本可以直接定论；软规则（如语言风格、术语取舍）脚本只提供数据，结论交给模型。

3.4 第四步：资源文件怎么准备

资源文件是给模型“开眼界”用的。

我在references/里放了两类东西：

一是好的范例。我收集了几篇用这个技能打磨后客户反馈不错的文案，作为good_example.md放进去。模型看过好东西之后，产出的标准会明显向范例靠拢。这叫 few-shot 的力量——给两个好例子，比写十条规则有效得多。

二是术语对照表。我把项目里常见的术语、使用频率、正确写法整理成了terminology.md：

智能体（不写“智力体”“AI代理”） 模型上下文（不写“上下文窗口长度”） 推理成本（不写“调用费用”）

术语表的价值在于它把“团队里的约定”以最高密度传递给了模型，一行术语对照表，胜过长篇大论的风格描述。

资源文件不是越多越好，每个文件都要对技能目标有直接贡献。放一堆无关的背景资料，只会分散模型的注意力。我的标准是：每个文件都能回答一个“做这个任务时必然遇到或可能遇到的关键问题”。

4. 让技能“被正确触发”和“稳定输出”的实战经验

做技能包容易，做好很难。

我现在看到的常见情况是：SKILL.md 写了，目录结构也搭了，但实际用的过程中，模型要么压根不触发这个技能，要么触发了却不好好用。这背后有两个核心问题：触发准确率和输出稳定性。

这两个问题不解决，技能包做得再漂亮也是摆设。

4.1 描述文件决定技能命运：怎么写出精准的 description

先讲触发。智能体判断该不该用某个技能，主要看SKILL.md里description字段跟用户当前需求的语义匹配度。这是最容易被忽视、也最容易出问题的一环。

我总结了几条提高触发准确率的经验：

1. 用动词开头，写行为，不写名词分类。

错误示范：“技术文档相关技能”。模型看了完全不知道什么场景用。

正确示范：“在需要撰写技术方案、设计文档或架构评审材料时使用”。

2. 写清适用场景，更写清不适用场景。

不少人只写“什么时候用”，不写“什么时候不用”。问题是，模型对正向条件的判断有偏差，尤其是用户请求比较模糊时——它总觉得“好像沾点边，要不就加载吧”。加一条负向条件能明显降低误触发率。实测中，加了“不要使用”说明后，误触发率能降低一半以上。

3. 控制长度，200字以内。

description 太长了，匹配时模型反而抓不住重点。把最关键的触发信号放在最前面，次要信息放后面。

我后期对触发逻辑做了一件事：写完 description 后，自己站在用户角度造二十条请求，跑一遍匹配测试，看描述会不会被正确触发、会不会在无关请求上被误触发。发现问题就改描述。这是成本最低、回报最高的调试方式。

4.2 输出不稳定？那是因为你的 SKILL.md 缺少“强制结构”

触发解决了，接下来是输出稳定性。

同一个技能，模型第一次给出的回答和第二次可能完全不同——一个是几十字的简洁回复，一个是上千字的详细报告。对用户来说，这种不一致很伤体验。

我的解决方案是在 SKILL.md 里加入强制结构。

什么叫强制结构？就是规定得死死的那部分输出格式。比如上面例子里的“输出格式”段落，明确规定“检查概览 + 问题列表 + 修改建议汇总”三件套，每部分怎么排版、每条建议怎么标注严重度。模型看到这么明确的结构约束，通常都会遵循。

另外还可以在 SKILL.md 里加“写作风格”约束：

# 写作风格 - 语气：直接，不用敬语和客套话 - 表达：条目式呈现，不用长篇大论 - 态度：明确给出建议，不要模棱两可

风格约束不需要太多，五条以内就好。写多了模型记不住，反而把核心规则稀释了。

还有一个很实用的小技巧：在 SKILL.md 的工作流程里加入“在最后一步，检查输出是否符合技能中的格式要求，不符合则重新整理”。这不是废话，这是一道兜底保险。模型在自我检查模式下，能发现并修正不少格式问题。

4.3 技能记忆问题：为智能体注入“行业直觉”的三种方式

技能包除了规则，还需要一些“软知识”。

我实践下来，最有效的三种方式：

方式是给范例。再多的规则描述，不如给模型一个完整的参考案例。比如做文案校对技能时，我会在 references/examples 里放一篇修改前的原文和一篇修改后的对照版，模型看一眼就明白“原来用户要的是这种力度的修改”。规则描述是抽象的，范例是具体的，具体比抽象好使。

方式是给反例。我专门建了一个common_mistakes.md，列出这个技能场景下用户常见的不符合预期的处理方式。比如“不要过度修改导致原文风格大变”“不要只给模糊意见，要给出精确的修改方案”。模型看到“不要做”的东西，比看到“要做”的东西更不容易犯错。这跟带新人是一个道理，你告诉他“哪里是红线”，比单纯说“好好干”有效得多。

方式是给术语表。术语表不只是约束模型用词的，还能配置模型的“领域感知”。当一个模型知道你用“智能体”而非“AI 代理”时，它对整个领域的话语体系都会更敏感。这个有点玄学，但我多次实测确实有差异。语言习惯会影响思维方式，大模型也一样。

4.4 按需加载：Agent Skills 如何管理上下文

最后说一个有时候不明显、但实际上影响很大的问题：上下文稀释。

假设你给 Agent 配置了二十个技能包，每个技能包含三四个文件，一次性全部加载会让上下文窗口瞬间爆满。而上下文是智能体推理的关键资源——被技能文本占满了，模型就没有多少空间处理用户的具体问题。

我没开玩笑。曾经我在一个项目里配置了五个技能包，每个包都塞了一堆资料，结果用户提了个简单问题，模型回答的质量反而明显下降了。后来一查，系统提示加上五个技能包的文档，占了上下文窗口的大半，模型真正能用来“思考”的 token 所剩无几。

Agent Skills 的设计哲学就是专门解决这个问题的：按需加载。

智能体平时只读取各个技能包的 description 做匹配判断，匹配上了才会完整的读取 SKILL.md 和所需资源。这套机制和 RAG（检索增强生成）有异曲同工之妙——都是“需要时再取”，而不是“全部拿过来”。

这意味着你在写技能包时也要有这个意识：SKILL.md 之外的资源文件，不是必须加载的，而是在技能内部需要时再读取的。所以资源的组织方式要清晰，比如在 SKILL.md 里写明“判断术语问题时，查看 references/terminology.md”，而不是所有文件一起塞给模型，让模型自己找重点。

5. 我踩过的坑：Agent Skills 落地的真实教训

这一部分可能对所有准备实际使用的人而言是价值最高的。

我从接触 Agent Skills 以来，踩过的坑少说也有七八个。大的问题导致技能包整个废弃重写，小的问题就是输出质量不理想。挑几个典型的说，希望能帮读者少走弯路。

5.1 坑一：技能粒度失控——“万能技能包”的诱惑与陷阱

我做的第一个技能包，想让它包打天下。当时想做一个叫content-creator的技能，既能生成文案，又能做 SEO 优化，还能做排版校对、数据推荐，甚至还能分析竞品。

结果呢？什么都做，什么都不精。

生成文案时它记不住风格规则，优化 SEO 时它把文案生成规则也带进来了，整个输出乱成一锅粥。

后来我把这个技能拆成四个：copywriter（负责文案生成）、seo-optimizer（负责关键词布局建议）、cn-polish（负责校对）、competitive-analysis（负责竞品分析）。拆完以后，每个技能的输出质量都有了明显提升。

我的原则很简单：技能包越小越专一，模型越容易稳定发挥。

这里要特别提醒的是：拆分不是简单地把一份大文档切成几份，而是要让每个技能包的规则、流程、资源都围绕自己的核心任务组织。拆完之后还要重写各自的 description，保证匹配时不互相打架。

5.2 坑二：脚本路径写死导致技能迁移即崩溃

有次我把本地一个技能包发给同事，结果他一跑就报错。

排查了半天，是脚本里的文件路径问题——我在scripts/里写死了绝对路径，比如/Users/myusername/projects/agent-skills/...。换个环境，路径全失效了。

而且问题不止在脚本里。SKILL.md 里的资源引用也用了绝对路径。在我电脑上能用，因为文件系统就长那样；换到同事电脑上，目录结构不一样，模型就找不到references/terminology.md了。

正确的做法是，永远使用相对路径。在 SKILL.md 中引用资源时，用相对于技能包根目录的路径：references/terminology.md，而不是/Users/xxx/projects/xxx/技能包名/references/terminology.md。

脚本里的资源加载路径同理，脚本在执行时通过自身所在目录来返回到根目录，再拼接相对路径。

技能包的核心优势之一就是可迁移性和共享性，路径写死了这个优势就彻底没了。

5.3 坑三：规则写得太抽象，模型只能“靠猜”

我早期的 SKILL.md 写了一句话：“输出要保证高质量文案”。这句话现在回看纯属废话。

什么叫“高质量”？模型理解不了这种主观描述。它不是你的资深编辑，它只是一台概率机器。它需要可量化的、可执行的具体标准。

后来我把“高质量”拆成了可检测的规则：

• 标题最多 20 个字包含核心关键词编号
• 每个段落不超过 5 行
• 每句话少于 30 个字，超过就需要拆分
• 全文中英文之间必须有空格
• 每一段必须有一个明确的核心观点，放在段落首句

这些规则模型就能精确执行。

每次编写技能规则时，我会多问自己一句：这条规则，换个人能照着做出来吗？如果连人都觉得模糊，模型更不可能做好。这就是判断规则是否写得到位的一个简单标准。

5.4 坑四：技能输出不做验证，上线一周没人发现技能坏了

技能包本质上也是软件，软件就会有 bug。但技能包的 bug 比较隐蔽——它不报错，只是输出质量下降，你觉得不对劲，但说不出到底哪里不对。

我就碰到过这种问题：有个行业分析技能，有段时间输出质量大幅下滑，但我一时找不到原因。后来一查，是参考资料里的一个关键行业报告链接失效了（模型去看的时候拿不到内容），但我直到一个多星期后才通过用户反馈发现。

吃过这个亏之后，我给技能包加了一个轻量级的自检机制：脚本覆盖了核心检查逻辑，能自动验证输出的关键字段是否完整、引用的格式是否匹配。

技能包上线之后，要定期对技能包进行回测，准备几份标准测试样本，跑一遍看输出质量有没有明显下降。不要等用户来告诉你技能坏了——还剩多少指标来支撑你的判断？很简单：给技能加一个极强的信号——输出质量持续下降时，它是最早感受到的人。

5.5 坑五：忽略技能之间的“冲突”

当技能库数量多起来以后，会面临一个新的问题：不同技能之间的规则互相冲突。

举个例子。我的cn-polish技能要求“中英文之间必须有空格”，但我的brand-writing技能又规定“品牌名称与英文之间不加空格，保持连写”。当用户要求用品牌写作风格润色一篇文案时，模型加载了两个技能，两份规则打架，输出变得完全不可控。

后来我给技能规则加了优先级说明，在 SKILL.md 里增加“规则优先级”字段：

# 规则优先级 规则冲突时，按以下优先级解决： 1. 用户明确要求的格式 > 技能默认格式 2. brand-writing 的风格规则 > cn-polish 的通用规则 3. 安全相关规则 > 风格相关规则

技能之间不可怕，可怕的是你没有定义好冲突时的处理顺序。可能有人觉得，我又不做什么复杂的业务，用不上优先级。但技能一多，这问题早晚会遇到。建议引入优先级机制，让冲突时的处理变得可预期。

6. 技能包的管理与迭代：别让它腐化成文档垃圾

技能也像代码一样，是需要持续维护和演进的。我见过一个团队，花两周时间建了一整套技能库，上线两周后就没有人再维护了。三个月后，技能库里一半的技能已经不符合实际业务流程了，再也没人用。

技能库腐化是真实存在的。怎么应对？

6.1 给技能包建立版本管理

技能包本质上是一段可执行的代码资产。既然是代码资产，就应该纳入版本管理。

我强烈建议每个技能包都作为独立仓库（或者一个仓库下的独立目录）用 Git 管理。每次修改技能，都写清楚 commit message，配合变更描述说明“改了什么、为什么改”。这带来的价值在你三个月后回看某个技能时才能充分体现——你能知道当初为什么做了某个决定，能基于历史记录做理性的重构。

另外，在 SKILL.md 的 frontmatter 里加version字段，遵循语义化版本规则（major.minor.patch）。major 代表不兼容的变更（比如整个技能流程改了），minor 代表向后兼容的功能变更（比如再加一项检查），patch 是细微调整（比如改措辞）。

6.2 建立技能回测用例集

回测就像是在给技能的每个版本设置一套准入标准。每次迭代一个技能包，就拿着这套用例跑一遍，看输出质量是否达标。

我当时给cn-polish技能建了一个测试文档集，包含二十个测试用例：有正常博客文、有产品详情页、有科技资讯稿、有带大量英文术语的杂文，还有故意写坏的文本用来测试纠错能力。

每次修改技能后，跑一遍测试集，对比修改前后的输出质量，就能判断这次的修改是优化了还是回退了。

第一次建测试集比较花时间，但一旦建好了，后续所有迭代都能基于这套标准进行，效率反而高了。这套方法论也可以明显降低技能包回归的风险。

6.3 从“个人技能包”到“团队技能市场”

当你把技能包用顺了，自然会想到一个问题：能不能让整个团队都用起来？

答案是肯定的，但要有方法。

我见过比较有效的做法是建一个“技能市场”目录，按使用频率和成熟度把技能包分类：

• 草稿区：还在实验中的技能，只有作者自己在用
• 可用区：已经被作者回测过、输出稳定、可以给他人使用
• 已发布区：经过至少三个人以上试用反馈没问题，正式向团队推广

这个分级制度能避免一个很尴尬的情况：某个人写了个半成品技能包，共享到团队里，别人一用发现质量很差，整个团队对技能库的信用都失败了。

分级管理后，技能质量就有了保障。而一个技能从草稿到正式发布，本身就经历了一个完整的质量验证流程。

7. 最后说点实在的：当前阶段值得做的事

如果把 Agent、提示词工程、技能工程、编排这些概念放在一起看，Agent Skills 仍然处在“概念已经验证，但工程实践方法论还在演进”的阶段。各个框架和工具对技能的标准化程度、兼容性、运行机制都还有差异，但这恰恰是个时间窗口——现在积累的工程经验，后面大概率能直接迁移到未来的标准体系上。

在我自己的实践中，收获最大的倒不是某个技能包本身，而是“把知识资产化”这套思路。过去团队里的经验、规则、模板全部散落在各个文档和人的脑子里，每一次都要靠人来讲、靠人去悟。技能包把这些东西结构化了、版本化了，变成了模型可以直接消耗和执行的东西，这比偶尔让 AI 帮你写一段代码要值钱得多。

如果你准备入门，我的建议是选一个重复性最强、规则最明确的任务下手做技能包装。比如文档格式整理、周报汇总、日志分析、报告校对之类的。难度低、见效快，跑通一次全流程之后，再做复杂的技能。

如果不出意外，你第一个技能包大概率做得不够好，会意识到这个问题。别灰心，我给所有技能包填了版本号和回测机制，接下来就是不断迭代。技能工程和写代码一样，不是一蹴而就的事，但每一次重构，都会让它离“可投入生产的内部工具”更近一步。