Appearance
第13章 把经验装进说明书——Skill
小a发现团队每次做代码评审，都要跟 Agent 重复同样的话：先看影响范围、跑测试、检查权限、别急着说“可合并”。他一边复述一边想，这太浪费了。
“能不能把这一套流程存下来，让 Agent 每次都照着走？”他问老z。
“能。外部能力已经有了接入边界，你发现的另一件事是：同一类任务还会反复需要检查表、约定和资料。这类可复用的工作说明，就是我们常说的 Skill。”老z说，“但先提醒你一件事：‘Skill’没有跨平台统一定义。本章把它作为一种工程模式讨论：用可发现、可按需加载的说明组织经验；不假定某种文件格式或自动触发机制。”
先把名字对齐
| 中文术语 | 英文全称或缩写 | 本书工作定义 | 不等于什么 |
|---|---|---|---|
| 技能 | Skill | 可发现、可按需加载的任务经验说明；不是统一行业协议 | 一个可执行 Tool |
| 指令包 | instruction bundle | 适用条件、步骤、资料、工具和验收说明的组合 | 强制执行引擎 |
| 发现／触发／渐进加载 | discovery／trigger／progressive loading | 先读索引、判定适用、再加载正文的三步 | 模型必然正确选择 |
| 软约束 | soft constraint | 借文本影响模型决策的规则 | 代码级权限或校验 |
Skill 的内容与边界
“一个 Skill 里都装什么？”小a问。
“一个 Skill 通常包含适用条件、目标、步骤、可用工具、输入输出约束、例外和验收方式。”老z说，“它可能是 Markdown 文件、数据库记录或代码配置；重点不在格式，而在内容是否可审查、可版本化和可验证。”
“能逐个说说这七部分吗？”小a问。
“可以。用一个‘代码评审’Skill 做样本，逐项拆开看：”
| 组成部分 | 代码评审 Skill 中的样例 | 写糊的后果 |
|---|---|---|
| 适用条件 | “准备合并到主分支的代码变更” | 写成”代码相关任务”→ 任何任务都触发 |
| 目标 | “确认变更可安全合并，并留下可追溯的评审记录” | 缺目标→ 模型不知道做完该产出什么 |
| 步骤 | 影响范围→跑测试→查权限→输出结论 | 步骤无序→ 模型跳步或漏步 |
| 可用工具 | read、run_test、git_diff | 不声明→ 模型用错工具或不用工具 |
| 输入约束 | “变更涉及的文件列表、目标分支” | 不约束→ 模型评审了无关文件 |
| 输出约束 | “结论 + 测试结果 + 风险清单” | 无约束→ 输出一段散文，无法验收 |
| 例外 | “若无法跑测试，标记并转人工” | 无例外→ 遇到障碍就卡住或编造结果 |
| 验收 | “每步有结果，结论可被另一人复核” | 不可验收→ 不知道算不算做完 |
“这八部分不是每个 Skill 都要写全，”老z补充，“但缺哪部分，那部分的风险就留给运行时。适用条件和验收是两条底线——前者决定‘该不该加载’，后者决定‘加载了算不算做完’。其他部分越完整，模型遵循的可靠性越高。”
“那这些部分，哪些最容易被写糊？”小a问。
“适用条件和验收方式。”老z说，“适用条件写得含糊，模型就会在错的场景加载它——比如把‘发布前检查’用到普通草稿上；验收方式写得不可观察，比如‘认真检查’，加载了也没法判断到底做完没有。一个能用的 Skill，至少要能回答两件事：什么时候该用它，怎么算用完了。”
“Skill 和 Tool、MCP 的关系我老混。”小a说。
| 概念 | 主要回答的问题 | 约束强度 |
|---|---|---|
| Tool | 能执行什么动作 | 由实现和权限决定 |
| MCP | 怎样发现与交换外部能力 | 由协议与宿主决定 |
| Skill | 面对任务该怎样组织动作 | 通常是软约束 |
“这三者是不同层面。”老z指着表说，“Tool 回答‘能做什么’，是动作实现；MCP 回答‘怎么发现和交换外部能力’，是协议边界；Skill 回答‘面对这类任务该怎么组织动作’，是经验说明。Skill 不替代 Tool，也不替代 MCP——它调用前者、可能经由后者发现资源，但自己只是一份说明书。”
“写进 Skill 的‘发布前运行测试’会被保证执行吗？”小a问。
“不会。模型可遗漏、误解或抵触文字说明。”老z说，“需要强制的前置条件落在 CI、工具校验、审批或权限控制中；Skill 的价值是让正确路径更明确，而不是替代这些机制。一条简单的判断：如果某个步骤失败会造成不可逆后果，它就不该只靠 Skill，而要有硬约束兜底。”
“那 Skill 和 System Prompt 有什么区别？”小a追问，“它们不都是写给模型的文字说明吗？”
“生命周期不同。”老z说，“System Prompt 是每次请求都在场的常驻规则，它声明的是‘始终适用的边界’；Skill 是按需加载的，它只在特定任务场景被带入上下文。System Prompt 是房子的承重墙，Skill 是按需取用的工具箱说明书——前者不能太厚，后者可以详尽，因为不是每次都加载。”
比喻：岗位手册
手册写得再好，也不能保证每个人都照做；要确保的环节，靠的是门禁。Skill 是手册（软约束），门禁是代码（硬约束）。
发现与按需加载
“那我是不是把所有 Skill 都塞进提示词，模型就能用了？”小a问。
“别。把所有说明全文放入上下文会挤占任务空间，也会让彼此无关的规则互相干扰。”老z说，“较稳妥的设计分两层：先加载名称、描述、适用范围等索引；再在任务确实匹配或用户明确选择时加载正文。匹配可以由规则、用户选择或模型判断完成，三种方式的误触发率和可解释性不同，不能混称为‘自动正确’。”
“这三触发方式，差别在哪？”小a问。
“代价不同。”老z说，“规则触发可解释、可测试，但写死条件，覆盖不到没预料到的场景；用户选择准确，但增加交互负担；模型判断覆盖面广，但可能误判——把不相关的 Skill 加载进来，轻则浪费上下文，重则引入冲突规则。多数系统混用：关键 Skill 用规则或用户选择兜底，辅助 Skill 允许模型判断，但都留日志。”
| 触发方式 | 准确性 | 覆盖面 | 代价 |
|---|---|---|---|
| 规则匹配 | 高（条件明确） | 低（只覆盖预定义条件） | 条件维护成本 |
| 用户选择 | 最高（人决定） | 取决于用户认知 | 交互负担 |
| 模型判断 | 中（可能误判） | 高（语义匹配） | 误触发占用上下文 |
“那索引本身会不会出问题？”小a问。
“会。索引是 Skill 的一道快照：名称、描述、适用范围。”老z说，“Skill 正文改了但索引没更新，模型读到的是旧描述；索引写了‘适用所有 TypeScript 项目’，但某份 Skill 其实只针对测试框架——**索引漂移会让触发判断建立在过时或过宽的信息上。**因此索引和正文应一起版本化，加载日志里同时记两者版本。”
“那加载之后呢？”小a问。
“加载后的内容也应标明来源和版本。这样，当回答或行为异常时，可以追溯是模型推理问题、说明过时，还是加载选择错误。”
“加载进上下文的 Skill 正文，会一直留着吗？”小a追问。
“这涉及一个取舍。”老z说，“如果一直留着，后续每一轮都占用上下文，但模型能反复参照；如果用完就移除，省了空间，但模型可能在后续轮次忘记它。常见做法是按 Skill 的参考频率决定：步骤型 Skill（一次性检查表）用完可以移除；规则型 Skill（贯穿整个任务的约定）应保留到任务结束。不管哪种，移除时应在消息历史里留一条记录，标明‘某版本 Skill 已从上下文移除’，方便审计。”
软约束为什么是软的
“我一直没完全理解‘软约束’到底软在哪。”小a说，“Skill 写得那么详细，模型怎么会不照做？”
“因为指令和数据走的是同一条通道。”老z说，“模型收到上下文时，它无法在机制上区分‘这是必须遵守的系统规则’和‘这是一段参考文本’——它看到的都是 token。模型会按概率给最可能的续写，而‘最可能’不等于‘照着 Skill 走’。”
“那有没有可能让约束变硬？”
“有，但要换通道。”老z说，“硬约束不走文本，走代码——工具执行器拒绝、权限层拦截、CI 强制检查。这些不依赖模型‘自觉’，它们在模型之外执行，模型绕不过去。软约束影响模型的决策概率，硬约束限制模型的行动边界——两者配合使用，前者让正确路径更可能被选，后者保证即使没被选也不会失控。”
要点
软约束"软"在它和普通文本共用同一条通道，模型按概率决定是否遵循。要保证的环节，用代码层硬约束，不靠文字。
“那软约束失败的典型场景有哪些？”小a问。
“至少三种。”老z说，
| 失败场景 | 表现 | 根因 |
|---|---|---|
| 遗漏 | Skill 要求跑测试，模型直接跳到结论 | 步骤多时模型可能跳步 |
| 误解 | Skill 要求‘列影响范围’，模型列了一堆无关文件 | 描述歧义或模型理解偏差 |
| 抵触 | Skill 要求‘不声明可合并’，模型在结尾还是写了‘可以合并’ | 任务的惯性压过规则约束 |
“这三种都不算 bug，”老z补充，“它们是软约束的固有特性。应对方式不是‘写更严厉的 Skill’，而是给关键步骤配硬约束：遗漏测试就在合并前门禁拦住，声明可合并就在工具层不让它输出这个词。”
把说明写成可执行的检查表
“能给我看个例子吗？”小a问。
“以下是示意，不绑定任何系统：”
markdown
---
name: review-change
when: "准备合并代码变更时"
---
1. 说明本次变更的影响范围。
2. 运行与受影响模块相符的测试，并记录命令和结果。
3. 若涉及权限或网络，列出新增边界并请求确认。
4. 未完成任何一项时，不声明变更可合并。“这个‘说明影响范围’算不算好步骤？”小a问。
“算，因为它可观察。好的说明会给出可观察的完成条件，而不是‘认真检查代码’这类不可核验的要求。”老z说，“判断一个步骤写得好不好，看它能不能被另一个执行者照着做、并能说出‘做完了’或‘没做完’。‘运行测试并记录命令和结果’可观察；‘仔细看看代码’不可观察。”
| 步骤写法 | 可观察？ | 问题 |
|---|---|---|
| “运行受影响模块的测试，记录命令和结果” | 是 | 无 |
| “仔细检查代码质量” | 否 | 无法判断完成状态 |
| “列出本次变更的影响范围” | 是 | 范围可被另一人复核 |
| “确保没有安全问题” | 否 | “确保”无验收标准 |
“那危险操作呢？”小a继续问。
“它还应把危险操作转交给硬约束，而不是把密钥、绕过方法或无限权限写进上下文。”老z说，“示意： Skill 里写‘部署前需要审批’，审批本身由工具或流程引擎强制执行；Skill 只负责提示这个步骤存在，不承担强制责任。把密钥或绕过逻辑写进 Skill 等于把敏感信息放进模型上下文，反而扩大了泄露面。”
“那步骤之间有依赖怎么办？”小a问。
“在说明里写清顺序，而不是让模型自己猜。”老z说，“比如‘先跑测试，通过后再请求审批，审批通过后才提交’——每一步的完成是下一步的前提。Skill 可以表达顺序，但不强制顺序；真要保证顺序，靠的是工具的状态检查或流程引擎，不是说明里的编号。”
“那一个步骤写得好不好，有没有自检方法？”小a问。
“有一个简单的测试：把这条步骤单独拿出来，交给一个不知道上下文的同事，看他能不能照着做并说出‘做完了’。”老z说，“如果他说‘做什么？怎么算做完？’，这条步骤就不够清楚。示意： ‘检查代码质量’——同事会问‘检查什么？质量标准是什么？’；改成‘运行 npm test 并贴出通过/失败的测试数’，同事就知道做什么、怎么算做完。”
| 模糊步骤 | 同事的疑问 | 改写后 |
|---|---|---|
| "检查代码质量" | 检查什么？标准是什么？ | "运行 npm test，记录通过/失败数" |
| "确保安全" | 怎么确保？什么算安全？ | "列出本次变更涉及的权限变更，若无写'无'" |
| "优化性能" | 优化什么？目标是什么？ | "测量修改前后 npm run bench 的耗时，记录差值" |
| "review 代码" | 看什么？输出什么？ | "读取 diff，按文件列出潜在风险及理由" |
“这个自检方法也能用在验收方式上。”老z补充，“验收方式回答的是‘怎么算做完’——如果它依赖主观判断（‘看起来不错’），它就不可观察；如果它能被另一个执行者用客观标准核对（‘测试全部通过’），它就可观察。”
选择错误与规则冲突
“那模型把 Skill 选错了怎么办？”小a问。
“Skill 的选择本身是一个可失败的决策：索引可能遗漏适用说明，语义匹配也可能把‘发布前检查’加载到普通草稿任务。”老z说，“示意： 两份 Skill 分别要求‘只生成预览’和‘执行提交’，冲突时系统按任务阶段、显式用户选择或预先定义优先级裁决，并把选择结果记录下来。无法裁决时请求澄清，而不是让模型把两份步骤混合后假装都已完成。”
“那怎么知道是选错了，还是模型没照做？”小a问。
“靠加载日志和执行日志分开记。”老z说，“加载日志记录‘在什么条件下加载了哪份 Skill、版本是多少’；执行日志记录‘模型实际做了什么、每步的完成状态’。两份对不上，才能定位问题：加载对了但没照做，是模型遵循问题；加载错了，是触发或描述问题。没有这两份日志，故障只能靠猜。”
“那多份 Skill 同时适用时，裁决顺序是什么？”小a追问。
“按这个优先级链走：”
text
1. 用户显式选择 ── 最高优先级，直接采用
│（无显式选择时）
↓
2. 互斥标签检查 ── 两份 Skill 标了互斥？→ 停下请求澄清
│（不互斥时）
↓
3. 预定义优先级 ── 配置里声明了谁优先？→ 采用高优先级
│（无优先级声明时）
↓
4. 任务阶段判定 ── 当前处于哪个阶段？→ 采用匹配阶段的
│（仍无法判定时）
↓
5. 请求澄清 ── 不让模型自己混合拼接“关键在最后一步：无法裁决时请求澄清，不让模型把两份步骤混合后假装都已完成。”老z强调，“混合是最危险的——它会产出一份看似合理、实则谁的要求都没真正满足的结果。”
“能举个例子吗？”小a问。
“两份 Skill：A 要求‘只生成预览，不修改文件’，B 要求‘直接修改并提交’。”老z说，“如果模型混合它们，可能产出‘修改了文件但没提交，还声称只生成了预览’——既改了文件，又没按 A 的要求保持只读，也没按 B 的要求提交。混合的产物比选错一份更难排查。”
把说明当作受版本管理的输入
“能不能串一个完整场景？”小a问。
“贯穿场景是发布变更：Skill 可包含检查范围、测试命令、人工确认点和输出模板。”老z说，“发现阶段只读取名称、描述、版本和适用范围；触发阶段由用户选择、规则或模型匹配决定；加载阶段才把正文与引用资料纳入上下文。三者应各留日志，否则无法判断是描述不准确、触发错误还是模型未遵循。”
“两个 Skill 同时适用呢？”小a问。
“两个 Skill 同时适用时，不依靠提示词先后顺序碰运气。”老z说，“定义优先级、互斥标签或合并规则；若要求冲突，例如一个要求只读、另一个要求写入，停在人工选择而不是把两份说明拼接。”
“Skill 改了之后怎么验证没改坏？”小a问。
“版本变更用固定测试集比较：检查是否加载了正确说明、是否调用了预期工具、是否违反了不可跳过的硬约束。”老z说，“Skill 是会过时的——业务流程变了、工具签名变了、安全策略变了，旧 Skill 就会和现实脱节。把它当作受版本管理的输入，而不是写一次就永远对的真理。”
“过时具体长什么样？”小a追问。
“三种典型漂移。”老z说，
| 漂移类型 | 表现 | 诱因 |
|---|---|---|
| 工具签名漂移 | Skill 写‘调用 run_test’，但工具已改名为 run_tests | 工具重构后未同步更新 Skill |
| 流程漂移 | Skill 要求‘提交到 main 分支’，但团队已改用 PR 流程 | 团队规范变了，Skill 没跟上 |
| 安全策略漂移 | Skill 写‘部署前通知 Slack’，但通知渠道已换成别的 | 基础设施变更未传播到 Skill |
“这些漂移的共同点是：Skill 描述的世界和真实世界不一致了。”老z说，“模型照着过时的 Skill 行动，会调用不存在的工具、遵循废弃的流程、走旧的安全策略。过时的 Skill 比没有 Skill 更危险——没有 Skill 时模型会谨慎探索，有过时 Skill 时模型会自信地走错路。”
“那怎么发现漂移？”
“靠两类信号。”老z说，“一是主动巡检：定期拿 Skill 引用的工具名、分支名、命令名去和当前系统比对，对不上的标红。二是被动捕获：当模型按 Skill 行动却频繁失败（工具不存在、分支不存在、命令报错），这些失败信号就是漂移的证据。两类都要落到日志里，否则漂移会一直潜伏，直到某次事故才暴露。”
“那 Skill 和 Tool、MCP、Hook 的关系？”小a问。
“Tool 是动作实现，MCP 是发现／交换边界，Hook 是运行时介入；**Skill 不替代其中任何一层。**它是一层组织经验说明，让模型在面对重复出现的任务时有一条明确的正确路径可循。”
Skill 的目录与命名空间
“如果 Skill 多了，怎么管理它们？”小a问。
“Skill 会像代码一样膨胀，需要目录和命名空间。”老z说，“几十份 Skill 平铺在一个目录里，索引会越来越难维护——描述互相覆盖、适用条件重叠、命名随意。给 Skill 分层是工程化的第一步，和给代码分包是同一个道理。”
“那怎么分层？”
“按职责分。”老z说，“常见的分法是三层：全局通用（所有会话都可用）、项目专用（绑定某个项目或仓库）、团队规范（某个团队的流程约定）。每层的索引、权限和更新节奏不同——全局 Skill 更新要评审，项目 Skill 可以跟项目走，团队规范由团队维护。”
| 层 | 适用范围 | 更新节奏 | 权限 |
|---|---|---|---|
| 全局通用 | 所有会话 | 慢，需评审 | 平台管理员 |
| 团队规范 | 特定团队 | 中，团队评审 | 团队成员 |
| 项目专用 | 特定项目 | 快，跟项目走 | 项目维护者 |
“命名空间呢？”
“用来解决同名冲突。”老z说，“不同团队可能都有个 review Skill，但内容完全不同。给 Skill 名加命名空间前缀——eng-review、sec-review——既能区分来源，也能在加载日志里一眼看出用的是哪份。命名冲突不处理，模型就会在两份同名 Skill 之间摇摆，加载日志也分不清谁是谁。”
“那目录和命名空间的维护，谁负责？”
“要有一个明确的 owner。”老z说，“Skill 是需要维护的资产：新增要评审、变更要测试、过时要清理。没有 owner 的 Skill 目录，会像没有 owner 的代码库一样腐烂——Skill 越来越多、越来越旧、越来越没人敢改。给每个 Skill 标 owner，是让它可维护的最低要求。”
“那一次任务能加载多少份 Skill？有没有预算？”小a追问。
“要有，而且这是个常被忽略的预算。”老z说，“每份 Skill 的正文都要占上下文，三份详细 Skill 就可能吃掉几千 token。加载预算应该和任务预算一起设——不是‘能加载就加载’，而是‘这份 Skill 的价值超过它占的上下文才加载’。”
“那加载多了会怎样？”
“症状是‘上下文臃肿但任务没变清楚’。”老z说，“模型面对一堆 Skill，要么每份都参考一点、行为被稀释，要么挑最显眼的一份、其余被忽略。加载过多 Skill 的效果，和没有 Skill 一样糟——区别只是一个看起来准备充分、一个明显没准备。判断标准是：加一份 Skill 后，任务的成功率或质量是否真的提升，而不是‘该有的都有’。”
“那有没有简单的加载预算规则？”
“有，但不绝对。”老z说，“一个实用起点：默认只加载索引，正文加载不超过 2-3 份且总字数设上限；超出预算的任务，优先用最相关的 Skill，其余降级为‘描述可查’。这规则不是放之四海皆准，但比‘不限量加载’安全得多——预算的本质，是给上下文留出给任务本身的空间。”
贯穿场景：一次发布评审的完整 Skill 生命周期
“能不能从头到尾串一次？”小a问。
“好。假设有一份 release-review Skill，跟踪它从被发现到任务结束的全过程。”
老z画了一条时间线：
text
任务开始：用户说"帮我评审这次发布"
↓
[发现] 系统读取所有 Skill 的索引（名称、描述、适用范围、版本）
↓ `release-review` 的描述含"发布评审"，进入候选
[触发] 模型判断：当前任务匹配"发布评审" → 标记为适用
↓ 加载日志记录：skill=release-review, version=3, trigger=model
[加载] 读取 `release-review` 正文（8 个步骤 + 工具清单 + 验收标准）
↓ 正文进入上下文，标明来源和版本
[执行] 模型按步骤推进：
步骤1：读取 changelog → 工具 read 返回内容 → 完成
步骤2：运行测试 → 工具 run_test 返回通过 → 完成
步骤3：检查权限变更 → 工具 git_diff 返回无变更 → 完成
步骤4：输出结论 → 生成评审报告
↓ 执行日志记录：每步的完成状态 + 工具结果摘要
[移除] 任务结束，Skill 正文从上下文移除
↓ 消息历史保留"release-review v3 已加载并执行"的记录
任务结束“这条时间线上，每一站都可能出问题。”老z说，“发现阶段：索引过时，描述还写着旧版工具名；触发阶段：模型误判，把‘草稿评审’匹配成‘发布评审’；加载阶段：正文和索引版本不一致；执行阶段：模型跳过某步或误解某步；移除阶段：忘了移除，后续轮次还带着它占上下文。每一站的故障，只有对应的日志才能定位。”
“那如果中途用户改了主意呢？”小a问。
“比如用户中途说‘算了，这次不走完整流程，快速看一下就行’。”老z说，“这时已加载的 release-review 和新意图冲突。正确做法是：标记当前 Skill 为‘已中止’，记录中止原因，再按新意图决定要不要加载另一份更轻量的 Skill。不能让旧 Skill 和新意图共存——那等于两套规则打架。”
小结
Skill 是把流程经验封装成可发现、可按需加载的说明层。当一个任务反复出现、有固定的步骤和验收标准时，把这些经验写成一份说明书，让模型在需要时能找到、读懂、照着做。它的价值在于复用——写一次，多个会话都能用，不必每次都靠 prompt 从零讲起。一份完整的 Skill 包含适用条件、目标、步骤、可用工具、输入输出约束、例外和验收方式；其中适用条件和验收是两条底线，前者决定该不该加载，后者决定怎么算做完。加载是渐进的：先读索引判断是否适用，适用了再加载正文，避免一次性把所有 Skill 都塞进上下文。三种触发方式（规则、用户选择、模型判断）各有代价，多数系统混用并把关键 Skill 交给更可靠的方式兜底。
Skill 本质上是软约束。它之所以"软"，是因为指令和数据走同一条通道——模型无法在机制上区分"必须遵守的规则"和"参考文本"，它按概率给最可能的续写。因此模型可能遗漏步骤、误解描述或抵触约束，这三种都不是 bug，而是软约束的固有特性。应对方式不是写更严厉的措辞，而是给关键步骤配硬约束：工具执行器拒绝、权限层拦截、CI 门禁。Skill 让正确路径更可能被选中，硬约束保证即使没被选中也不会失控。
Skill 的可靠性依赖三份日志：加载日志（在什么条件下加载了哪份、版本多少）、执行日志（模型实际做了什么、每步完成状态）、移除记录（何时从上下文移除）。三者对应三类失效来源：触发错误、模型未遵循、上下文残留。此外，Skill 会随时间漂移——工具改名、流程变更、基础设施迁移都会让旧 Skill 描述一个已不存在的世界。过时的 Skill 比没有 Skill 更危险，因为没有 Skill 时模型会谨慎探索，有过时 Skill 时模型会自信地走错路。把它当作受版本管理的输入，用主动巡检和被动捕获两类信号发现漂移，是维持 Skill 可靠性的长期工作。
Skill 的工程化不止于写正文。它需要目录和命名空间——全局通用、团队规范、项目专用三层各有更新节奏和权限，命名加前缀解决同名冲突，每个 Skill 要有 owner 负责维护；它需要加载预算——默认只读索引，正文加载限制在 2-3 份且设字数上限，判断标准是加一份 Skill 后任务质量是否真的提升。贯穿一个发布评审场景，Skill 的完整生命周期是发现（读索引）→ 触发（判适用）→ 加载（读正文）→ 执行（按步骤走）→ 移除（任务结束），每一站都可能失败，每一站的故障只能靠对应的日志定位。当任务复杂到需要同时推进多个独立目标时，单靠 Skill 和单 Agent 就不够了，下一步要讨论的是否引入多个执行者。
动手核验
- 为一次代码评审写一个不超过十步的 Skill，给每步加可观察的完成条件。
- 将其中“必须完成”的要求分别落到测试、工具校验或审批，验证单靠文字不能代替它们。
- 为该 Skill 写索引描述，并列出一个应触发、一个不应触发的任务。