Skip to Content
其他Skills 教程用好 Matt Pocock Skills案例 · 测试手册：把单体提示词拆成 skills flow

案例 · 测试手册：把单体提示词拆成 skills flow

原提示词：es-center-server-services/.ai/prompt/test-00.md —— 版本测试手册生成。

上一篇：深入 · 下一篇：案例 · 周报打磨

这份提示词在做什么

  • 输入：基线点（提交 hash / 日期 / tag）+ 当前版本 + 输出目录。
  • 方法论：代码 diff + 规格文档 + git 提交信息 三方交叉，不偏信单一来源。← 这点做对了。
  • 产物：分三层的测试手册 ——
    1. 非专业可读的改动 / 修 bug / 新功能清单；
    2. 专业测试手段（界面 + API + SQL + 日志 + 抓包 + AI），标注哪些已自动化自测；
    3. 给架构师 / 开发的审查：新 bug / 回归风险 / 规范一致性 / 已知权衡。
  • 输出结构：1 个导读 + 3 个分层文件。

问题在于它是一整块单体大提示词 —— 一次性读完整版 diff + 文档 + commit 再产出三层文档。直接跑会踩三个坑。

诊断：直接跑为什么不好

  1. Context 经济学破产 —— 一整个版本的 diff + 全部规格塞进主 context，迅速吃掉 smart zone；等分析到第三层（回归审查）时模型已退化，而第三层恰恰最吃推理。
  2. 三个 phase 混做 —— 收集事实、回归审查、磨叙述是三种活，混在一起互相干扰。
  3. 第三层其实就是 /code-review，却被当成”顺便” —— “新 bug / 回归风险 / 规范一致性 / 已知权衡” 正好等于 code-review 的 Standards 轴（规范）+ Spec 轴（是否偏离 / 破坏），却没用上双轴纪律。

改造：拆成 skills flow

三步：① 后台收集（提交 + 规格 + 测试数字）→ ② /code-review 出第三层 → ③ /grill-me 磨前两层。下面每步都是能直接跑的指令，把 {{基线}} {{输出目录}} 换成实际值即可。

第 1 步 · 后台收集三方事实（并行三个 /research）

# 改动清单：since 基线的提交 + commit 意图
/research 列出本仓库自 {{基线}}（提交 hash / tag / 日期）以来的全部 git 提交，每条给出：hash、摘要、改动意图（从 commit message 推断）、影响的功能点。结果写到 {{输出目录}}/source-commits.md，带 hash 引用。
# 规格意图：需求 / 设计 / 规格文档
/research 找到本仓库自 {{基线}} 以来涉及的需求文档、设计文档、规格（spec），提炼每项改动「应有的意图」。结果写到 {{输出目录}}/source-spec.md。
# 自测数字：跑自动化测试
/research 运行本仓库的自动化测试（单元 + 集成），记录 tests / failures / errors / skipped 的实际数字，并列出覆盖到哪些改动项。结果写到 {{输出目录}}/source-tests.md。

三份 md 就是后续的 primary source。

第 2 步 · 第三层（回归审查）= /code-review

# 第三层：新 bug / 回归风险 / 规范一致性 / 已知权衡
/code-review 审查自 {{基线}} 以来的全部 diff，双轴都跑：Standards 轴查规范一致性；Spec 轴查是否偏离 source-spec.md 的意图、是否破坏了既有行为。每条发现给出：严重度、代码证据（文件:位置）、判断、建议。产物作为 {{输出目录}}/03-dev-review-for-architects.md。

第三层就是 code-review 的产物——别再”顺便检查”。

第 3 步 · 前两层（磨叙述）= /grill-me

# 第一层 + 第二层 + 导读
/grill-me 以 {{输出目录}}/source-commits.md、source-spec.md、source-tests.md、03-dev-review-for-architects.md 为素材，磨出三份文档：
1. 01-overview-for-everyone.md：通俗的改动 / 修 bug / 新功能清单（这层同时是「版本更新日志」）；
2. 02-test-guide-for-qa.md：每项改动的测试方法（界面步骤 + 至少一种专业手段），标注哪些已自动化自测（引用 source-tests.md 的数字）；
3. README.md：导读（版本范围、大纲、自测结论速览、破坏性变更显眼标注、文档地图）。
破坏性变更（权限改名、接口语义变更、配置删除等）在导读和第一层显眼标注。

一次性产出、不维护 repo 约定 → 用 /grill-me（非 grill-with-docs）。

为什么这样拆

步骤skill补的短板
收集事实（三方）/research（后台并行）不让整版 diff 吃掉主 context；读完留带引用的 md
第三层回归审查/code-review（since 基线，双轴）Standards 抓规范、Spec 抓回归；比”顺便检查”严谨
磨三层叙述/grill-me把”改了啥”逼问成”对测试人员意味什么、用什么手段测、标没标自测”
验收提示词原带的「质量检查清单」它天然就是可验证的成功标准 —— 每条 [ ] 对应一个产物该有的属性

收益

  • Context 健康：事实收集丢后台，主 context 只在 code-review / grill-me 时承载”分析 + 写作”，稳在 smart zone 内。
  • 第三层质量跃升：从”顺便检查”升级成双轴纪律，回归与规范各跑一个 subagent。
  • 一份 flow 两个产物：第一层通俗清单 = 版本更新日志；整套 = 测试手册。同一套交叉分析的不同切面。
  • 提示词不浪费：方法论（三方交叉）、输出结构（1 导读 + 3 文件）、质量检查清单全部保留 —— skills 只让执行更有纪律。

验收（= 原提示词的质量检查清单）

  • 三层受众清晰分离：非专业 / 专业测试 / 开发。
  • 每个改动项标注「新功能 / 改进 / 修 bug / 破坏性变更」。
  • 第二层每项给出可操作的验证手段（界面步骤 + 至少一种专业手段），并标注对应自动化测试类。
  • 自动化测试结论有实际数字（tests / failures / errors / skipped），且区分”单元自测通过”与”真实环境待验证”。
  • 第三层每条审查发现给出：严重度、代码证据（文件:位置）、判断、建议；不误报、不把”已知接受权衡”当新 bug。
  • 破坏性变更（权限改名、接口语义变更、配置删除等）在导读和第一层显眼标注。
  • 交叉验证：代码行为与规格 / 提交信息一致；发现脱节如实记录。

上一篇：深入 · 下一篇：案例 · 周报打磨 →

深入：化繁为简案例 · 周报打磨：批量任务的 context 黑洞