常用 Skill 模式目录

系列入口：如何使用 Agent。单个 Skill 怎么写，看 写第一个 Skill。

一、先按「模式」找，而不是凭空设计

写 Skill 时一个省力的关键认知：绝大多数工程场景，都能归到少数几种反复出现的模式里。你要做的往往不是发明全新结构，而是识别「这件事属于哪类模式」，再套用那类的骨架做定制。这篇整理六类最高频的模式，当作你的起步目录。

二、六类模式逐一说明

1. 评审模式（Review）

• 触发：用户要 review、提交前检查、合并前把关。
• 主干：读取改动 → 按固定维度检查（逻辑、边界、空值、安全、风格）→ 输出分级问题清单。
• 输出物：按严重程度排序的问题列表 + 通过/不通过结论。
• 迷你范例：「先读改动，按『逻辑错误 / 边界与空值 / 安全 / 风格』四类检查，每类下列具体位置，最后给能否提交的结论。」
• 要点：检查维度要稳定可复用，别每次临场发挥。定制时只需替换成团队真正关心的维度。

2. 测试模式（Testing）

• 触发：补单元测试、提升覆盖率、为某段逻辑写用例。
• 主干：分析被测单元 → 列出正常/边界/异常路径 → 生成测试 → 跑通确认。
• 输出物：可运行的测试代码 + 覆盖了哪些场景的说明。
• 迷你范例：「先读函数，列正常路径、三个边界（空、最大、临界）、两个异常输入，逐一生成用例并跑通，最后说明覆盖范围。」
• 要点：强制覆盖边界和异常，这正是 Agent 的强项；定制点是项目测试框架与断言风格。

3. 发布模式（Release）

• 触发：准备发版、上线前检查。
• 主干：逐项走发版清单（版本号、迁移、配置、回滚方案、通知）→ 每步核对 → 缺项即拦截。
• 输出物：勾选状态的发布清单 + 阻断项提醒。
• 迷你范例：「逐项核对版本号、数据库迁移、各环境配置、回滚方案、通知是否就绪，每项标注通过/缺失；有关键项缺失就停止，不允许带阻断项发版。」
• 要点：清单式、任何关键项不满足就停止，不可逆操作尤其严格；定制点是团队实际发版清单。

4. 排障模式（Diagnose）

• 触发：报错、异常行为、性能问题需要定位。
• 主干：收集现象与日志 → 提出假设 → 用最小手段验证 → 锁定根因 → 再修复。
• 输出物：根因分析 + 证据链 + 修复建议。
• 迷你范例：「先收集报错、日志和复现条件，列出最可能的两三个假设，用最小手段逐一验证，锁定有证据支撑的根因后，再给修复方案。」
• 要点：强调「先定位再动手」，避免瞎试（对应 空转纠偏）；定制点是系统日志位置与可用验证手段。

5. 文档模式（Document）

• 触发：生成 README、接口说明、变更说明、把改动讲清楚。
• 主干：读取代码/改动 → 提炼关键信息 → 按固定结构成稿。
• 输出物：结构化文档，通常带使用示例。
• 迷你范例：「先读改动和相关代码，提炼功能、参数、返回与异常，按『简介—用法—参数—示例—注意事项』结构成稿，所有描述以代码为准。」
• 要点：以代码为准，避免凭空编造不存在的行为；定制点是团队文档结构规范。

6. 重构模式（Refactor）

• 触发：在不改外部行为的前提下改善代码结构。
• 主干：确认现有行为与测试基线 → 小步改造 → 每步跑测试 → 确保行为不变。
• 输出物：结构更清晰的代码 + 「行为未变」的验证证据。
• 迷你范例：「先确认现有行为并跑通测试作为基线，每次只做一个小改造并立即跑测试，任何一步行为变化都回退检查，最终给出行为未变的验证证据。」
• 要点：小步、有测试兜底、行为等价，绝不大爆炸式重写；定制点是现有测试基线覆盖度。

三、怎么用这个目录

你的需求	套用模式	定制点
提交前把关	评审	团队关心的检查维度
给函数补测试	测试	项目的测试框架与风格
上线前检查	发布	你的发版清单
排查一个 bug	排障	系统的日志与验证手段
写接口文档	文档	文档结构规范
改善旧代码	重构	现有测试基线

做法很简单：先判断属于哪类 → 复制该模式的主干骨架 → 只替换成你项目的具体维度、命令和格式。混合场景也常见（比如「重构 + 测试」），可以让一个 Skill 在不同步骤调用对应的模式思路。

怎么快速判断一个新需求属于哪类？可以用「产出物是什么」来反推，这比逐字分析需求更快：

• 你最终要的是一份「问题清单 + 能否通过」→ 评审模式；
• 要的是「能跑的用例」→ 测试模式；
• 要的是「勾好的发版清单」→ 发布模式；
• 要的是「根因 + 证据」→ 排障模式；
• 要的是「一篇说明」→ 文档模式；
• 要的是「结构更好但行为不变的代码」→ 重构模式。

如果一个需求同时想要多个产出（比如「重构它并补测试」），通常说明它可以拆成两个阶段，各自套用对应模式；硬塞进一个 Skill 往往会让主干不清晰。判断不清时，先问「这件事成功交付时，我手里具体多了什么」，答案往往直接指向模式。

四、套用模式时的常见误区

• 把模式当死模板照搬：模式给的是主干思路，真正的维度、命令、格式必须替换成你项目的，否则会水土不服。
• 跳过验证环节：任何模式都强调用测试/清单做客观确认，只抄步骤不留验证，质量没有保障。
• 强行让单一 Skill 承载过多模式：导致目的混杂。应按产出物拆分，保持一个 Skill 一类核心目的。
• 忽视定制点：比如评审模式真正的价值在团队关心的检查维度，这部分不替换，Skill 只是空壳。

一个好的自检：套完骨架后问三句——它的产出物是否明确？主干每步是否可执行、有验证？其中命令和标准是否已替换成我项目真实的？ 这三问能在使用前发现大多数套用问题。

五、常见问题

Q：六类之外的需求怎么办？ 这六类覆盖了大部分工程场景；真正特殊的需求，可以先判断它是否是某类的变体，或组合两类思路。模式是起点不是牢笼，完全特殊的再自行设计结构即可。

Q：一个 Skill 里混合多类模式好吗？ 简单的组合（如重构中带测试验证）很自然；但核心目的应保持一个，避免评审、发布、排障全塞进一个 Skill，那会让触发和主干都混乱。

Q：这些模式和现成的规则/钩子怎么配合？ Skill 承载流程与方法；每次都要守的约束放 rules；需要程序级强制的检查用钩子。一个 Skill 在执行中可以读取规则、调用脚本或触发钩子，各司其职。

Q：我是新手，该先用哪类练手？ 建议从评审或测试模式入手，它们触发清晰、产出容易验证，且最容易观察到价值。跑通一类后，再逐步尝试发布、排障等更复杂的模式。

六、两个进阶模式：生成器与编排型 Skill

六类核心模式之外，随着使用深入你还会遇到两类进阶形态，先有个印象，遇到时知道它们的存在。

生成器模式（Generator）：触发后不是做检查，而是根据少量输入批量产出结构统一的内容——比如根据一个数据模型定义，一次性生成实体类、接口、迁移脚本和基础测试。它的主干是：读取结构化输入（字段、类型、关系）→ 按既定规则映射到多个目标文件 → 生成后逐一校验。输出物是一组成套、彼此配套的文件。这类模式特别适合大量高度同构、手工写极易漏改的场景，关键是生成规则要确定、且生成结果可通过编译和测试验证。要注意它和文档模式的区别——文档产出一篇说明，生成器产出多份配套代码。

编排型 Skill（Orchestrating Skill）：它本身不直接完成具体工作，而是负责把一个较大流程拆解、在不同步骤调用其他 Skill 或子代理，再汇总结果。主干是：识别任务包含哪些阶段 → 按依赖顺序调用对应能力 → 收集各阶段结论 → 汇总成最终交付。它适合横跨多类模式的复杂流程，比如一次完整的发版可能顺序调用测试、评审、发布检查。编排型 Skill 的价值在于把「先做什么、再做什么、每步找谁」固化下来，但要注意避免过度嵌套导致流程难以追踪。

这两类进阶形态再次说明一个规律：模式是从真实重复工作里抽象出来的，需要时才引入，而不是一开始就追求模式大全。 新手先把六类核心用熟，等遇到「需要批量生成成套文件」或「需要把多个 Skill 串成一条流程」的真实痛点时，再自然地采用这两类进阶模式即可。

七、各模式的「不该用」信号

知道何时不该用，和知道何时套用同样重要。逐类点一下反信号，避免你把模式硬套到不合适的场景。

• 评审模式不该用：当任务还在探索、根本没有可审查的确定改动时，过早评审只会制造噪音；应等有具体产出再触发。
• 测试模式不该用：当被测代码本身正在剧烈变动、行为尚未定稿时，先写大量测试很快会过期；应等逻辑相对稳定，或只先锁定已确定的核心行为。
• 发布模式不该用：日常开发、本地调试阶段不必走完整发版清单，那会严重拖慢节奏；它只在真正临近上线时启动。
• 排障模式不该用：如果你已经清楚根因、只是需要执行修复，就不必再走完整假设验证流程，直接改更高效。
• 文档模式不该用：代码还没定型时大量生成文档，很快与实现脱节；文档最好在改动稳定后再写或更新。
• 重构模式不该用：当需要改变外部行为（也就是在做新功能或修真实缺陷）时，不能用「行为不变」的重构框架，那会捆住手脚；该做的是功能或修复流程。

把正反两面合起来看，选模式其实是在同时判断两件事：你要的产出物是什么、当前阶段适不适合启动这套流程。 只看产出物可能在错误时机套用，只看时机又可能选错骨架，两者结合判断才准确。这也解释了为什么同一个需求在不同阶段可能匹配不同模式——早期需要文档澄清，中期需要测试，临上线需要发布检查。模式跟随「产出物 + 阶段」动态选择，而不是给需求贴上一个永久标签。

最后给一个非常实用的现场决策口径，帮助你快速行动：先花十秒问「此刻我具体想拿到什么」，确定产出物大类；再问「现在是不是做这件事的合适阶段」，排除反信号；两问通过，就大胆套用对应骨架并做项目化定制。熟练之后，这个判断几乎是一瞬间完成的，而你也会越来越自然地把团队的重复流程沉淀成恰当的 Skill。

八、把六类模式放进一次团队落地里

最后用一个团队视角，把这些模式如何串起来讲清楚，你会发现它们覆盖了研发的主要环节。需求开始时，用文档模式把需求背景和接口约定写清楚；开发完成、提交前，走评审模式做结构化把关，并通过测试模式确保关键逻辑有用例；改动涉及旧代码时，用重构模式在行为不变的前提下小步改善结构；准备上线时，切到发布模式逐项核对清单、确认回滚方案；上线后若出现异常，则用排障模式按「假设—验证—根因」的方式定位，而不是凭直觉乱试。

这条链路说明一个关键点：Skill 模式不是孤立的技巧集合，而是可以贯穿需求—开发—交付—运维的一整套可复用方法。 当团队把这些高频环节都沉淀成对应 Skill，个人经验就变成了组织资产，新人或 Agent 都能沿着统一骨架把事做对，而不必每次靠口口相传。这也是为什么值得花精力识别和沉淀模式——复用一次是省事，固化成团队资产则是整体效率的提升。

需要提醒的是，落地时不必六类同时上马，更稳妥的做法是从最痛、最高频的那一类开始，用顺一个再推下一个，并且每类都结合自己团队的真实清单和标准做定制，而不是照搬通用骨架。让模式库随实际使用逐步长全，比一次性铺开更容易坚持，也更能真正解决问题。到这一步，你对 Skill 的理解就从「写一个脚本说明」上升到了「建设团队可复用方法论」，这正是本模块希望帮你达到的高度。

总结

写 Skill 不必从零发明：评审、测试、发布、排障、文档、重构这六类模式已覆盖大部分工程需求，认出属于哪类、套上对应骨架再做项目化定制，就能又快又稳地把团队的重复流程沉淀成 Skill。