这篇文章想聊一次纯方法论层面的工程实践，不涉及具体业务场景和产品细节，只讲思路本身——因为这套设计过程本身，我觉得比它解决的具体问题更值得记录。

起点：一堆各自为战的提示词

项目背景很简单：一条以”自动化测试”为核心的流水线，链路大致是「源码 → 文档 → 用例 → 执行 → 反馈修正」这五个阶段。最早的时候，每个阶段对应的 AI 辅助能力，都是各写各的提示词，互相之间没有统一的组织方式，甚至严格来说都不算是规范化的 Skill，就是一批临时拼起来能用的脚本和 prompt。

能跑，但完全没有可维护性——加一个新能力要从头写一遍上下文，两个提示词之间职责重叠还是互补，全靠记忆，没人说得清楚。

这是很多 Agent/AI 工具项目起步阶段的常态：先解决”能不能跑”，再解决”跑得好不好管”。

第一步：先看清整条链路，再决定怎么分类

想清理这堆提示词之前，我先做的不是”整理现有的”，而是回到最上层，把整条业务链路重新看一遍：

源码 → 文档 → 用例 → 执行 → 反馈修正

这五个阶段，天然就是五种不同性质的工作：有的是提取和校验信息（文档阶段），有的是生成结构化内容（用例阶段），有的是执行和收集结果（执行阶段），有的是对比预期和实际、反哺修正（反馈阶段）。

把这五个阶段直接映射成五个横向分类，是这次重构里第一个关键决定：分类不是拍脑袋分的，是链路本身自带的。 如果分类和实际工作流对不上，后面怎么整理都会很别扭。

为了把这个思路记得更牢，我自己画了一张图，把三个维度放在一张图里——下面这三块分别对应的就是我接下来要讲的三个步骤：

第二步：一个 Skill 到底该多大

第二个问题更实际：一个 Skill 应该管多大范围的事？

我最早的想法是”一个功能点一个 Skill”，结果发现这样拆得太碎——比如”从文档提取信息”和”校验文档是否符合规范”，看起来是两件事，但实际使用时几乎总是连续发生的，拆成两个 Skill 只会增加切换成本，没有带来任何独立复用的价值。

于是我做了第一次合并：把这两个语义上连续、几乎不会单独使用的能力合并成一个 Skill。同样的逻辑也用在了”解析执行结果”和”根据结果修正内容”这两步上——它们本质上是一个动作的两个环节，不是两个独立的动作。

判断标准很简单：如果两个能力几乎总是一起被调用，且中间没有独立的决策点，就应该合并成一个 Skill，而不是拆成两个。 反过来，如果一个能力经常被单独调用、有自己独立的输入输出边界，就应该拆出来。

把这个判断标准画成图会更直观：

左边那种情况，两个能力永远是一前一后被调用，中间没有任何分开的现实价值，拆开只会带来额外的上下文切换成本和两份文档需要同步维护的麻烦。右边那种情况，两个能力可以各自被单独调用，合并反而会把一个轻量的查询变成一个重的执行。这个判断一定要具体到两个能力真实的调用频率和依赖关系上，光凭直觉很容易判断错。

第三步：范围也需要分层，不只是类型需要分层

分完横向类型之后，我发现还漏了一个维度：不同 Skill 的适用范围完全不一样。

有些能力是通用的方法论，跟具体项目没关系，理论上换个项目也能直接用；有些能力是这个项目专属的，换个项目就失效；还有一些能力更细，只服务于某个子模块。

所以在横向的”流程分类”之上，我又加了一层纵向的”作用域分级”：

• 全局级：跨项目通用，比如某种通用的模式挖掘方法
• 项目级：这个项目专属，按流程分类组织
• 模块级：项目内某个子模块专属

优先级上，范围小的覆盖范围大的——模块级优先于项目级，项目级优先于全局级，这跟大多数配置系统的”就近覆盖”原则是一致的，不是我发明的新东西，只是把这个常见的工程模式套用到了 Skill 体系上。

第四步：怎么控制质量和风险

光有分类和分层还不够，还需要一套机制去回答两个问题：这个 Skill 靠不靠谱？这个 Skill 能不能自主执行、要不要人盯着？

这两个问题本质上是两个独立的维度，我没有把它们混在一起，而是分别设计了两套等级：

• 一套衡量成熟度：从”核心稳定、被反复验证过”到”还在探索阶段、随时可能调整”
• 一套衡量自主执行的安全边界：从”只能读取信息，不能做任何操作”到”可以完全自主执行，不需要人工介入”

这两个维度互相独立又互相配合——一个刚起步、成熟度很低的 Skill，即使理论上具备自主执行的能力，也应该先限制在低风险等级运行，等验证足够多次之后再逐步放开权限。反过来，一个成熟度很高的 Skill，如果涉及的操作本身风险大（比如会修改重要数据），也不应该无条件给它最高的自主执行权限。

成熟度回答”这个东西好不好”，安全等级回答”能不能放手让它自己跑”，这是两件不同的事，不能用一个指标替代另一个。

走完这一整套设计之后，我的几个复盘

1. 分类不是终点，是起点。 我一开始以为把提示词分好类就算完工，实际上分类只是让后续的合并、分层、等级管控有了一个可以附着的骨架。真正的工作量在骨架搭好之后才开始。

2. 合并的判断标准，比”要不要合并”这个问题本身更重要。 我给自己定的规则是”是否总是一起被调用、中间是否有独立决策点”，有了这条标准之后，后续遇到类似的拆分/合并争议，可以直接套用，不用每次重新纠结。

3. 两个独立的等级体系，比一个混合指标更清晰。 一开始我确实想过用一个”综合评分”来同时衡量质量和风险，后来发现这样反而更难用——因为质量高不代表风险低，风险低也不代表质量高，混在一起的指标谁都看不明白该怎么用。拆成两个正交的维度之后，每个维度的责任边界都很清楚。

4. 文档和执行标准要分开维护，但要联动。 这套 Skill 体系旁边还有一份独立的规范文档，负责定义”什么是对的”，Skill 负责”怎么把事情做对”，两者一一对应，任何一边变了，另一边要跟着检查是否需要同步调整——这条协作原则，让整个体系不会因为迭代而逐渐失去一致性。

这次重构从”能跑的一堆脚本”，走到”有分类、有分层、有质量和风险双重管控的完整体系”，前后经历了两个明确的阶段。现在回头看，这套方法论本身其实跟具体项目关系不大——只要是”AI 辅助的多阶段流水线”场景，这套”先看链路分类、再判断合并粒度、再补范围分层、最后加双维度管控”的思路，应该都能套用。