我是如何构建 /goal 命令以及它如何为我所用的

我过去的大多数 AI 编程会话往往以同样的方式收尾：冗长的对话、半成品的工作，以及我努力回忆做完了什么、没做什么。因此我构建了一个名为 /goal的命令。你给它一个宏大的目标，它就会持续工作，直到目标完成并经过检查，或者遇到真正的阻碍。

今天是 2026 年 11 月 9 日。这在当下至关重要，因为 AI 助手能够迅速编写大量代码，而难点已经从编写代码转移到了信任代码上。 /goal 便是我应对该问题的答案。

/goal 究竟是什么

它不是一个程序。它是一套书面指令，当我在输入 /goal 后紧跟一个目标时，助手就会遵循这些指令。这些指令描述了一个流程，就像发布检查清单描述如何进行版本发布一样。

目标可以只有一句话。我最近输入的一个目标是："完整实现我的浏览器扩展 v1.1 计划，分阶段进行，每个阶段提交一次，未经我的许可不要 push 或 deploy。" 这一句话就涵盖了十个阶段的工作，大约二十五次提交。

一句话阐明核心理念

不同的工作交给不同的模型，且谁也不能批改自己的作业。

• 规划 交给最强的规划模型。它会阅读项目，对待办事项排序，将目标划分为各个阶段，并编写一个追踪文件。
• 构建 交给快速且更便宜的编程模型。每个阶段都会获得一个从追踪文件开始的全新智能体，因此没有任何阶段会依赖前面阶段耗尽或混淆的记忆。
• 关键代码 交给最严谨细致的编程模型。当任务涉及删除用户数据、覆盖文件或发布脚本等操作时，我会将其标记为关键任务。
• 审查 交给一个独立的只读审查器。它从未编写过这些代码。它只阅读 diff 并报告问题；它不能编辑任何内容。

分步执行流程

步骤 1：规划阶段

在编写任何代码之前，规划器会检查项目：未结的笔记、未完成的工作、git 状态以及用于构建和测试的命令。然后它会编写一个包含目标和核对清单的追踪文件，清单中的每一项都有一个可验证的单行检查项（例如必须执行通过的命令）。每个项还会打上模型标签。追踪文件是唯一的真实数据源（single source of truth）。即使对话过长助手遗忘了上下文，追踪文件依然清楚记录着一切。

它还会记录决策。当我的计划中有我尚未回答的悬而未决问题时，追踪文件会列出它为每个问题选择的默认方案，以便我稍后可以推翻或修改它们。

步骤 2：每个阶段一个全新的智能体

每个阶段都由一个全新的智能体来构建。它编写代码、运行构建和测试、修复失败项，并用清晰朴素的说明完成一次 commit。它在追踪文件中勾选自己的项。随后它停止运行，下一个阶段以干净的状态重新开始。

步骤 3：审查关卡

当一个阶段提交后，独立的审查器会对照追踪文件的检查项阅读 diff。它依次检查四件事：代码是否真正满足验收检查、是否安全、是否处理了边界异常情况，以及文档是否与代码的行为一致。它会返回一个按优先级排序的问题列表，每项都标明文件、代码行以及一句失败场景描述。

步骤 4：修复与重新审查

确认存在的问题会作为修复任务交给全新的智能体。修复完成后，审查器会再次检查。存在未解决已确认问题的阶段不能被标记为完成，整个目标也不能被称为已完成。

步骤 5：如实汇报

最后，只有在满足所有标准且每项检查都变绿（通过）时，我才会收到标为 COMPLETE 的报告。否则它会标为 PARTIAL 并准确列出缺少的内容。报告从不弄虚作假、四舍五入。

它在真实项目中捕获了哪些问题

该项目是一个用于录制浏览器标签页音频的个人浏览器扩展。新版本将录音存储在浏览器的私有文件系统中，允许我按名称保存到文件夹中，修复视频文件，并添加了一个媒体库页面。

审查器发现了测试未能捕获的真实 bug：

• 文件夹保存功能原本每次都会悄悄回退到旧的“另存为”对话框。运行保存操作的 background 页面无法读取扩展设置，因此代码悄然选择了默认值。而测试之所以通过，是因为它们使用了一个模拟的设置存储。
• 某个修复步骤可能会生成一个缩短的文件，该文件仍能通过其自身的检查，随后替换掉原始文件。
• 恢复的录音在文件名中显示了错误的时长，因为修复后的文件具有新的修改日期。
• 写入失败可能会静默丢弃录音的剩余部分。

这些都不是什么罕见古怪的问题。但每一个在几周后都会表现为录音丢失、时长过短或命名错误。

我写入其中的规则

• 不要停下来提问。自行决策，将决策记录在追踪文件中，然后继续执行。
• 对外交互或破坏性操作属于例外：push、deploy、发送消息、删除数据或任何需要我密码的操作。这些会变成受阻项（blocked items），并附上需要我亲自运行的准确命令。
• 绝不能为了让检查通过而禁用失败的检查，也绝不能删除失败的测试。
• 不做无关的代码清理。只编写服务于目标的代码。
• 除非我传入了相应参数或明确指示，否则绝不 push 或 release。

结语

/goal 之所以对我很有效，是因为它把一个模糊的愿望转化为了可追踪、可验证的步骤清单，而且负责构建模块的人绝不是审批该模块的人。它并没有让助手变得更聪明，但它让结果更加值得信赖，也减少了我必须投入的精力。

优点

• 一句输入即可驱动大型的多阶段工作。
• 追踪文件能够在漫长的会话和上下文丢失中留存下来。
• 独立审查能够发现代码作者自身测试所遗漏的 bug。
• 每个阶段都是一次小提交，因此提交历史清晰易读且方便回滚。
• 最终报告会如实反映哪些已验证、哪些未验证。
• 诸如 push 和 deploy 等高风险操作始终处于我的掌控之中。

缺点

• 执行速度较慢。这个项目花费了数小时，因为每个阶段都有构建、审查和修复循环。
• 消耗大量 token，因为多个智能体都会阅读相同的代码。
• 审查器会发现无休止的微小边缘情况，因此你需要对审查轮次设置上限。
• 在模拟环境中运行的测试无法证明真实设备上的行为。某些检查仍需要人工参与。
• 薄弱的目标陈述会产生薄弱的计划。该命令无法挽救一个含糊不清的目标。

注意事项

本文仅供参考学习，介绍的是我个人的配置方案。文中的名称、路径和项目细节均已做泛化处理，你自己命令中的任何占位符都必须替换为你自己的值。模型名称和工具行为变化频繁，因此在将其用于重要工作之前，请务必核实各项说法，并在低风险的小型项目上测试该流程。

常见问题解答

• 什么是 /goal 命令？ — 它是一套保存下来的指令，引导 AI 编程助手对一个大目标进行规划、构建、审查和验证，然后如实汇报。
• 它是一个程序还是一个插件？ — 都不是。它是命令文件中编写的流程，供助手遵循，因此你可以像编辑任何文本文档一样编辑它。
• 为什么针对每项工作使用不同的模型？ — 规划、常规编程和细致审查需要不同的优势能力，针对每项任务选择合适的模型既能节省成本，又能提高质量。
• 为什么每个阶段都要使用全新的智能体？ — 全新的智能体会从追踪文件开始，而不是从冗长、已被部分遗忘的对话中开始，从而避免了目标偏移和过时的假设。
• 为什么审查者必须与构建者分离？ — 作者往往容易轻信自己的成果，因此未参与编写代码的读者能够发现作者所忽视的问题。
• 它会自动部署或推送代码吗？ — 不会。push、release 和 deploy 都需要我的明确批准，该命令会将它们列为受阻步骤。
• 当它无法完成某些任务时会怎么做？ — 它会将该项标记为受阻（blocked），写明具体错误以及如何解除阻塞，然后继续进行其他独立的工作。
• 多花这些时间值得吗？ — 对于大型或高风险的改动，是值得的，因为多轮审查能在早期捕获 bug。而对于小修小补，普通的对话会更快。

标签

#ClaudeCode #AICoding #DeveloperWorkflow #CodeReview #Automation #SoftwareEngineering #AIAgents #Productivity #DevTools #BuildInPublic