从写提示词到写检查项，他的AI编程流程改到第三版

同一套AI编程流程，作者已经改到第三版，还给每一版编了号。工具在更新，模型在变强，去年春天还需要人一步步盯着的环节，现在能自己跑完。v1是计划模式加一份手写的SPEC.md，v2把它做成了TracerKit，v3则把每一步都搬进了helderberto/agent-skills这个仓库。

v3的思路一句话能说完：过去靠提示词完成的步骤，现在写成技能；过去靠"请记得"提醒的事，现在写成会报错的检查。

为什么放弃TracerKit

TracerKit本身能用，问题在于它是一个独立工具，有自己的发布周期。每调整一个步骤，都要在那边改代码、发版本，再到每个项目里更新一遍。作者想要更简单的更新方式，也想更方便地加新技能。

他本来就把其他技能放在agent-skills里，把规格流程挪过去之后，所有东西集中到一处。改一个步骤或加一个技能，只需要一次提交。TracerKit里的核心想法保留了下来：先访谈再写规格、用示踪弹式的工单、任务完成前必须验证，这些现在和其余技能住在同一个仓库。

两个仓库拼出来的流程

v3不是从零设计的，大部分来自两个仓库，作者各取了自认为最好的部分。

• 从Matt Pocock的技能里取流程骨架：grill-me负责访谈，一直问到计划没有未决分支；to-spec和to-tickets负责规格与工单，工单是带阻塞关系的示踪弹切片；diagnosing-bugs是分阶段的调试循环；此外还有tdd、prototype、domain-modeling、codebase-design和retro。
• 从Addy Osmani的agent-skills里取每一步内部的工程深度：frontend-ui-engineering用于写组件前先做决策；source-driven-development让代码遵循所装版本的文档；还有security-and-hardening和performance-optimization。

作者把每一项都裁剪到只保留能改变智能体在自己项目里行为的程度，并统一挂到/hb:命名空间下。

八条命令走完一个功能

一个功能会经过八个命令，分规划、构建、交付三段。规划段是triage、grill、to-spec、to-tickets；构建段是build和review；交付段是to-pr和retro。并非每个任务都要全走一遍，/hb:triage负责评估工作量并指出从哪开始，小修小补可以直接跳到/hb:build。

以同一个暗色模式开关为例。v1里作者要打开计划模式，写一段话请Claude讨论方案并生成规格；现在从一条命令开始：/hb:grill dark mode。访谈按轮进行，每轮把所有当下能回答的问题一次问完，每个问题附带推荐答案，回一个"是"就算接受。定下来的术语进词汇表，难以回退的决策在落地时写成ADR。

对话随后变成产物：/hb:to-spec dark-mode和/hb:to-tickets dark-mode。规格落在.specs/specs/dark-mode.md，工单是带阻塞边的薄纵向切片，智能体因此知道下一个没被阻塞的是哪张。v1里的检查清单还在，只是现在有了顺序。

构建同样是一条命令：/hb:build dark-mode。它取下一张未被阻塞的工单，测试先行，跑项目自带的检查并提交。加上--all参数，会在一次批准之后把工单分发给并行的子智能体。收尾靠两条命令：/hb:review把差异发给多个审查者，把他们的发现合并成一份带排序的结论；/hb:to-pr跑检查、推送、开PR并盯着CI。

护栏靠报错，不靠嘱咐

写在提示词里的要求在压力下会被跳过，会失败的检查不会。所以作者的大部分护栏都是会以错误退出的东西：

• /hb:check在每次提交前跑项目自己的lint、类型检查和测试，覆盖率不达标就让构建失败，"补测试"不再是一句请求；
• hitl工单会在需要人参与的工作开始前拦住/hb:build --all；
• /hb:safe-repo --diff在PR发出前扫描分支里的密钥；
• harden列出需要先经他批准的改动：认证、PII、CORS、文件上传。

智能体可以跑得快，因为它没法悄悄跳过这些检查。

调试先建反馈回路

/hb:debug有一条作者即使不用智能体也会遵守的规则：没有反馈回路之前不谈理论。在翻代码猜原因之前，智能体必须先给出一个能复现缺陷的命令，它要在确切症状上失败、每次运行结果一致、几秒内跑完，可以是一个失败的测试、一条curl、一段无头浏览器脚本。

之后才列出3到5条带排序的假设，每条都附一个能证伪它的预测。这一步是为了拦住智能体去修第一个看起来说得通的原因，作者说这个习惯浪费了他大部分调试时间。回路变绿之后才动手修，并把回路留作回归测试。

流程自己改自己

最后一步是/hb:retro。它读取本次会话，建议改的是环境而不是代码：缺了哪个检查、AGENTS.md里哪条规则应该变成lint规则、哪个文件智能体找了太久。

这正是离开TracerKit的回报。复盘得出的结论变成agent-skills里的一行修改，每个项目在下次更新时都会拿到。规格仍然在中心，和v1一样；变的是它周围的一切——反复重打的提示词成了技能，反复给出的提醒成了检查。下一次工具或模型更新时，这套流程还会再变，届时它会是一次提交，以及v4。