![图像](https://pbs.twimg.com/media/HH27K7gbQAANEU5?format=jpg&name=large)

很多 AI Agent 项目走到中后期，都会开始沉淀 skills。

一开始，这几乎是必然动作。写代码要有 TDD skill，排查问题要有 debug skill，提交前要有 review skill，写文档要有 writing skill。每一个 skill 都像是在给 Agent 补一块局部能力：让它在某类任务上更稳定、更专业、更符合团队习惯。

但系统一旦继续生长，一个更深的问题就会浮出来：**skills 的数量增加，并不必然带来 Agent 行为的稳定性。**

表面上看，这是一个能力组织问题；但在机制层面，它其实是一个工程控制问题。小规模时，问题是“有没有合适的 skill”；规模扩大后，真正的问题变成了：**这些能力在什么阶段被调用，由什么责任视角调用，依据什么输入推进，留下什么产物，又由什么机制决定是否可以进入下一步。**

这也是我设计 Unified Skills 时真正想解决的事情：**不是再做一组 skills，而是把 skills 组织成一套分层 workflow。**

更准确地说，skills 解决的是“怎么做”，而 workflow 解决的是“什么时候做、由谁做、做到什么程度算通过、失败时退回哪里、过程证据留在哪里”。当 Agent 开始承担连续工程任务时，真正要治理的就不再是能力本身，而是能力进入流程的方式。

## 一、Skills Library 的上限，不是能力不足，而是工程失稳

![图像](https://pbs.twimg.com/media/HH28XHobYAASd6l?format=png&name=large)

很多团队一开始搭建 skills library，逻辑都很自然：把常见问题抽成一组可复用方法论，需要时调用。

- 需要写测试时，调用 TDD skill；
- 需要调试时，调用 debug skill；
- 需要审查时，调用 review skill；
- 需要写作时，调用 writing skill。

这种方式当然有效。因为它把零散经验变成了可复用结构，让 Agent 至少在局部问题上不再完全依赖临场发挥。

但这套方式的上限也很清楚。问题不在于 skill 没价值，而在于**工程工作从来不是一次技能调用，而是一条连续推进的责任链。**

当任务复杂度上升，系统会开始暴露出四类典型失稳。

1\. 时序失稳：Agent 会跳步骤

Agent 很容易从一个模糊想法直接进入实现，然后在最后补一句“已验证”。skill 可以告诉它测试该怎么写，debug 应该怎么做，但 skill 本身并不能天然约束它：**什么时候才有资格开始写，什么时候必须先澄清，什么时候必须先停下来做设计。**

这意味着，skills library 解决了局部执行质量，却没有解决阶段推进合法性。系统依旧可能以一种“看起来很高效，实际上不断跳过前置条件”的方式运行。

2\. 责任失稳：Agent 会自证通过

更危险的问题，是 self-confirming loop。

同一个 Agent 可以自己理解需求，自己做设计，自己列计划，自己完成实现，再自己 review，最后得出“没有问题”的结论。问题不在于它不努力，而在于工程系统不能把“提出问题、执行任务、判断通过”全部交给同一个认知视角。

这是工程里最常见却最容易被忽视的风险：**不是模型能力不够，而是责任边界没有切开。**

3\. 证据失稳：过程不可追踪

一次对话里，Agent 看起来好像完成了很多工作：澄清了需求、查了资料、做了设计、列了计划、写了实现、通过了 review。

但几天之后回看，往往很难回答以下问题：

- 当时的需求边界到底是什么？
- 哪些外部资料被采纳，哪些被拒绝？
- 设计时讨论过哪些替代方案？
- 计划里哪些任务允许并行，哪些必须串行？
- review 审的是 spec 完整性，还是只是代码风格？
- ship 时有没有留下导出、同步、发布和回滚记录？

如果这些问题无法回放，那么整个流程看似完成，实际上却缺少可审计证据。它更像一场即时表演，而不是一个可复盘的工程过程。

4\. 治理失稳：skills 之间没有组织关系

TDD、review、debug 当然都可以是好 skill，但如果它们只是平铺在一个目录里，Agent 仍然要在运行时临场决定：先调哪个，什么时候切换，什么情况下跳过，失败后回到哪里。

而这个“临场决定顺序”的过程，本身就是最大的随机性来源。

所以，skills library 可以提升局部能力，但不能单独解决工程稳定性。因为它解决的是**能力复用问题**，不是**流程治理问题**。

## 二、Workflow 不是 Skills 的顺序表，而是阶段协议

![图像](https://pbs.twimg.com/media/HH28dXfa8AACPB-?format=png&name=large)

从这个角度看，Unified Skills 的第一层升级，并不是多做几个 skill，而是把 skills 放进一个明确的阶段流里。

主路径不是“需要什么就调用什么”，而是：

/refine -> /design -> /plan -> /build -> /review -> /ship

这条路径背后的判断是：**工程交付需要状态机，而不是自由联想。**

/refine：把模糊想法收敛成可验证规格

/refine 的任务不是“继续聊一聊需求”，而是把模糊想法压缩成可验证的 spec。它关心的是：

- 问题是什么；
- 用户是谁；
- 成功标准是什么；
- 约束有哪些；
- 当前缺哪些外部事实；
- 最终产物类型是什么。

这一阶段如果没有收敛清楚，后面所有实现都可能在错误目标上越跑越快。

/design：在实现前冻结创作与体验判断

很多系统最容易犯的错，是把 design 偷偷塞进 build。也就是说，边做边想、边写边改、边实现边决定体验。

这在小任务里看起来无伤大雅，但在多产物系统里会迅速失控。UI、文章、deck、视觉稿这些产物，本质上都需要先完成创作和体验层面的判断，再进入生产。否则，build 阶段就会不断替代 design 阶段，最终让整个流程失去边界。

/plan：定义任务拓扑，而不是写一份待办清单

/plan 真正要做的不是列出一些 todo，而是定义任务拓扑：

- 哪些任务必须串行；
- 哪些任务可以并行；
- 哪些文件或模块允许写入；
- 哪些步骤完成后才能进入下一阶段；
- 哪些风险需要前置处理。

计划不是形式主义，它的意义在于把“工作如何展开”从运行时 improvisation，变成可审查的结构。

/build：消费已批准输入，而不是重新发明目标

/build 才是实现和内容生产真正发生的地方。但它最重要的纪律不是“认真执行”，而是：**只消费已经批准的 spec、design 和 plan，而不是在实现过程中重新定义目标。**

这是很多 Agent workflow 会失效的关键点。因为如果 build 可以随时回写目标、改写边界、替代 review，那前面的阶段就会全部失去约束意义。

/review：门控，而不是口头确认

/review 也不应该只是“帮我看看”。

真正的 review 是门控。它的职责不是鼓励，不是润色，也不是在明显缺失时给一句“整体不错”。它必须有能力阻断流程：只要发现 blocking 问题，就要明确退回 /build，必要时甚至退回 /plan 或 /refine。

/ship：交付完成，不等于实现结束

最后的 /ship 处理的不是代码本身，而是交付动作：发布、导出、同步、记录、回滚信息、交付痕迹。工程系统最容易被忽略的一点是：**代码写完，并不等于交付完成。**

交付真正结束，必须以可追踪的收尾动作为标志。

因此，workflow 的意义不在于给 skills 排一个顺序，而在于把每个阶段变成有输入、有输出、有门控的协议。它解决的不是“快点进入某种能力”，而是“任务如何合法地推进到下一状态”。

## 三、真正的升级，不只是阶段流，而是纵向分层

![图像](https://pbs.twimg.com/media/HH28gSsasAAM9kq?format=png&name=large)

如果只有阶段流，这个系统依然可能退化成一组更长、更复杂的 prompt。真正让 Unified Skills 变成工程系统的，不只是横向阶段，而是纵向分层。

我把它抽象成六层：

CANON -> Command -> Agent -> Skill -> Artifact -> Hook / validate

这不是六种文件分类，而是六种不同的系统职责。每一层都解决一个问题，同时拒绝解决另一个问题。一个方案是否成熟，不看它能不能跑通一次，而看它能不能被复用、治理和演化。

## 四、CANON：所有 Workflow 的宪法

![图像](https://pbs.twimg.com/media/HH28kqLboAEXHvJ?format=png&name=large)

最上层是 CANON.md。

它不是某个具体 skill，也不是项目说明书，而是所有阶段、角色和技能都必须继承的全局纪律。它定义的不是某类任务技巧，而是不可放松的底线：先陈述假设、控制范围、验证优先、遇到矛盾先停止并澄清、调试先找根因、不做 yes-machine。

这一层解决的是**纪律统一**，而不解决具体任务策略。

为什么它必须独立存在？因为如果没有 CANON，每个 skill 都会带着自己的隐含价值观。TDD skill 强调测试，debug skill 强调根因，review skill 强调质量，但它们之间缺少统一的行为合同。久而久之，整个系统会出现一种隐性腐蚀：局部方法论都很认真，整体行为却越来越不一致。

所以 CANON 的作用不是让技能更强，而是让所有局部方法论不能为了局部方便，绕过全局纪律。

这也是第一条原则：**具体能力可以增加纪律，但不能放松纪律。**

## 五、Command：阶段控制器，而不是快捷入口

Command 层回答的问题是：**现在处在哪个阶段，这个阶段应该读什么、产出什么、通过条件是什么。**

在 Unified Skills 里，Command 不是 prompt shortcut，而更像 workflow controller。

例如 /plan 的职责，不是“调用一个计划类 skill”，而是定义计划阶段的合法输入、合法输出和门控条件。它要消费已经批准的 spec 和 design，产出 03-plan.md，在大型任务里拆出子计划和并行矩阵，并明确写入范围和风险点。

这一层解决的是**阶段推进协议**，而不解决具体任务的方法论。

换句话说，Command 不负责告诉你“debug 怎么做”，也不负责告诉你“review 怎么看代码”；它负责回答的是：**当前阶段是否具备进入条件，当前产物是否达到通过条件。**

这也是第二条原则：**workflow 需要阶段状态机，而不是能力快捷方式。**

## 六、Agent：责任视角，而不是人格表演

Agent 层最容易被误解。

很多系统引入 agent，是为了让模型“扮演”产品经理、架构师、设计师、审查员。但如果角色只停留在语气层面，它最多制造一点表演感，并不能真正提升工程质量。

Unified Skills 里的 Agent 层，核心不是角色扮演，而是**责任切分**。

需求分析、任务计划、软件实现、规格审查、代码质量审查、发布判断，最好不要全部由同一个视角闭环完成。不是因为模型不能同时做这些事，而是因为工程系统不能把“提出问题、执行任务、判断通过”压在同一个认知回路里。

例如：

- review agent 不应该重新定义需求，它应该基于已批准的 spec 判断实现是否完整；
- software engineer agent 不应该在 build 阶段决定任务拓扑，它应该在 plan 的约束内实现；
- design reviewer 不应该只说“视觉不错”，它应该阻断缺少证据来源、模式综合和采纳/拒绝理由的设计稿。

这一层解决的是**责任分离**，而不解决阶段协议定义。

这是第三条原则：**Agent 的核心价值是责任分离，不是人格化。**

## 七、Skill：真正可复用的方法论单元

![图像](https://pbs.twimg.com/media/HH280MjbAAA0NyW?format=png&name=large)

Skill 层是最具体的一层，也是最容易被过度简化的一层。

一个合格的 skill，不应该只是一段“请你认真做 X”的提示词。它必须至少说明：

- 什么时候进入；
- 什么时候退出；
- 具体步骤是什么；
- 哪些说法是常见借口；
- 哪些情况必须停止；
- 如何验证自己做完了。

这也是为什么 Unified Skills 里的 SKILL.md 往往不只是“做法说明”，而是会包含入口/出口、流程、红旗、常见说辞、验证清单，强纪律技能甚至会定义 Iron Law。

这一层解决的是**方法论复用**，而不解决整体工作流编排。

也就是说，Skill 负责回答“这一类事情怎么做”，但不负责回答“现在是不是该做这件事”。后者属于 Command 和 Agent 的职责。

这是第四条原则：**Skill 是执行方法论，不是工作流总控。**

## 八、Artifact：把过程变成证据链

![图像](https://pbs.twimg.com/media/HH28o2CacAE7eKg?format=png&name=large)

如果只看对话，Agent 的工作很容易变成一段不可回放的即时表演。

今天看起来它澄清了需求、做了设计、写了计划、完成了实现、通过了 review；但过几天回头看时，很多关键信息已经散失在上下文里，既无法复盘，也无法迁移。

所以 Unified Skills 把 artifact 作为 workflow 的一层，而不是一组顺手保存的文档。

01-spec.md、02-design.md、03-plan.md、04-review.md、05-ship.md 这些文件，并不是文档洁癖，而是 Agent 行为的审计轨迹。它们记录的不是“写过什么”，而是“为什么这样推进、为什么这样取舍、为什么允许进入下一阶段”。

这一层解决的是**过程审计与复盘**，而不解决运行时拦截。

与此同时，artifact 也是多产物 workflow 成立的前提。软件、文档、文章、deck、视觉稿并不共享同一种构建路径。如果没有 artifact\_type，系统就很容易用软件工程的方式处理所有产物，或者用内容创作的方式绕开软件质量门控。

这是第五条原则：**没有 artifact，workflow 就缺少可审计证据。**

## 九、Hook / Validate：把约定变成护栏

![图像](https://pbs.twimg.com/media/HH28rl9bQAAlOaV?format=png&name=large)

只靠提示词约束 Agent，是不稳定的。

提示词可以提醒模型不要做破坏性操作，但运行时 hook 才能拦截破坏性命令。文档可以要求技能命名规范、索引一致、根文档同步，但 validate 才能发现 README、AGENTS、skills-index、锁文件和 hooks 实现之间是否已经发生合同漂移。

这也是 Unified Skills 里 hooks 和 ./validate 的意义所在。

它们不负责替代思考，也不负责替代高层 review；它们负责把一部分纪律从“应该遵守”变成“违反就会暴露”。

这一层解决的是**运行时护栏与维护期漂移暴露**，而不替代高层判断本身。

这一点非常关键。高层纪律如果没有低层护栏，最终就只是建议。系统最容易发生的腐蚀，不是某个 prompt 突然写错，而是多个合同慢慢表面不一致：README 说一套，AGENTS 说一套，skills-index 还是旧的，hooks 实现又是另一套。等这些漂移积累起来，Agent 在不同入口读到的，就不再是同一个系统真相。

这是第六条原则：**高层纪律必须有低层护栏，否则只是建议。**

## 十、两阶段 Review：分层门控的一个具体例子

分层 workflow 不是抽象口号，它必须体现在具体门控设计里。Unified Skills 里的 review，就是一个很典型的例子。

这里的 review 不是单阶段“代码看起来怎么样”，而是拆成两关。

第一关：Spec Compliance

第一关先检查实现是否覆盖了 spec 中定义的功能需求、边界条件、错误路径和验收标准。它关心的不是“写得漂不漂亮”，而是：**实现了什么，是否把该做的事情做全了。**

第二关：Code Quality

只有在第一关通过后，才进入第二关。第二关才讨论 correctness、readability、architecture、security、performance 等质量维度。它关心的是：**这些功能是如何被实现的，代价和质量是否合理。**

这个拆分看似简单，但它体现了分层 workflow 的价值。

如果功能都没实现完整，就急着讨论代码风格，审查资源会被浪费；如果功能缺失和质量问题混在一起，反馈也会变得模糊。两阶段 review 的作用，就是把问题类型切开：先确认做没做对，再确认做得好不好。

这不是让 review 更复杂，而是让门控更有顺序、更有边界、更有退回路径。

## 十一、从 Prompt 到 Workflow，再到治理结构

![图像](https://pbs.twimg.com/media/HH28uR0aUAAkLvv?format=png&name=large)

回到最开始的问题：AI Agent 工程化到底需要什么？

更长的 prompt 有用，但不够。更多的 skills 有用，但也不够。真正需要设计的，是 skills 之间的组织关系，以及这些组织关系如何进一步沉淀为治理结构。

也就是说：

- 用 CANON 定义不可放松的全局纪律；
- 用 Command 定义阶段状态机；
- 用 Agent 定义责任视角；
- 用 Skill 承载可复用方法论；
- 用 Artifact 留下过程证据；
- 用 Hook / validate 把规则变成护栏。

这套结构的目标，不是让 Agent 显得更复杂，而是让它在复杂任务里更可控。一个系统是否工程化，不看它能不能完成一次任务，而看它能不能稳定地推进、回退、审计和复盘。

所以，prompt 是表达，skill 是方法，workflow 是制度，而 layered workflow 才是治理结构。

![图像](https://pbs.twimg.com/media/HH286ASaIAA-git?format=png&name=large)

所谓 Agent 工程化，真正工程化的不是生成能力本身，而是**任务推进权、通过判定权、责任边界和证据链的分配方式。**

这也是 Unified Skills 想表达的核心判断：**AI Agent 的下一层抽象，不是继续堆 skills，而是把 skills 放进一套有阶段状态机、责任分离、证据链和运行护栏的分层 workflow。**

进一步而言，真正成熟的 Agent 系统，不应该只是“会做很多事”，而应该知道：**在什么阶段，由什么模块，以什么责任，依据什么证据，完成什么结果。**

技术方案的价值，不在于提出一个新名词，而在于重新划清问题边界，并给出可落地的系统结构。对 Agent 来说也一样。真正的工程化，不是把能力堆得更多，而是让系统知道自己何时开始、何时停止、何时退回、何时交付。