Infinite Red 创始人、游戏开发者 Jamon Holmgren 分享了自己的软件开发智能体工作流。他说很多公司疯狂消耗 token，却连最基础的工程体系都没有，还总说“没时间”；但既然他一个人都能做到，其他团队也没有太多借口。-----------我干脆把自己整套智能体工作流都摊开讲一遍，因为我看到太多人漏掉了其中一些非常关键的部分，而这正在严重影响他们的效果。

下面是我目前在用、也推荐采用的配置：

**0. 一个作为路由器的 `AGENTS.md`**

它负责把智能体引导到正确的技能、文档和工具。

**1. 一份根据自身需求定制的标准工作流文档或技能**

如果你还没有现成方案，可以直接参考 Matt Pocock 的 skills。

我在大多数会话里都会通过 `引用它，让智能体把这份工作流加载进来。

**2. 为每个系统准备可自我维护的文档，并要求智能体持续更新**

我会手动引用那些明确知道会用到的文档，也可以让智能体通过 `AGENTS.md` 自行找到它们。

另外，我会在每份文档开头的前 7 行提供一段更详细的摘要，方便通过 grep 快速定位正确的文档。这个规则本身也会写进 `AGENTS.md`。

**3. 智能体必须实际运行应用**

智能体始终都应该亲自运行应用、测试自己的工作，并在过程中发现和修复问题。

在智能体以自主或异步方式工作时，这一点尤其重要。

**4. 端到端测试，以及持续编写和维护测试的明确指引**

还要有专门的文档说明：

* 如何编写测试；* 哪些做法需要避免；* 当前所有测试的清单；* 每项测试具体覆盖什么。

这些内容可以放在另一份 Markdown 文档中。

实现功能时，要编写并运行有针对性的测试，并随着代码变更持续改进测试，和代码一起提交。

**5. 在 pre-commit hook 中加入自定义检查器**

针对你曾经遇到过的各种问题编写检查规则。

检查器应支持通过 `--fix` 自动修复问题。

如果无法通过确定性规则自动修复，就让它调用成本更低的模型，例如 Composer 2.5 或 Sonnet 来修复。

重点不是单纯标记问题，而是最终真正产出清理后的代码。

**6. 在每个主要阶段进行跨智能体审查**

包括：

* 调研；* 规划；* 实现；* 收尾。

可以使用 Codex、Claude、Cursor 或其他工具，但审查者不应该是编写同一份代码的同一个模型。

还要准备专门的智能体审查文档，明确说明：

* 应该检查什么；* 应该如何开展审查。

同时还可以设置不同的审查角色，从不同角度检查代码，例如：

* 可维护性；* 代码质量；* 安全性；* 性能；* AI 生成代码的典型问题；* 特定业务领域，例如“金融服务专家”等。

每个角色还可以负责维护一组对应的系统文档，并持续保持这些文档最新。

**7. 使用智能体执行轨迹或工作表，记录每次会话中的工作**

如果某个智能体执行到一半失败了，你应该能够直接把这份工作表交给另一个智能体，让它接着完成剩余工作。

工作表应与代码一起提交，这样所有内容都能关联起来，方便以后查找。

你以后确实会再次引用这些记录。

还可以让智能体为不同工作表添加对应的 Git tag，方便快速定位。

**8. 每次会话结束时，让智能体自动提供反馈**

将这些反馈追加到一份文档中，并和本次工作一起提交。

之后定期在交互式会话中读取这些反馈，用它们持续改进你的工作流。

**9. 准备一个 `tools` 或 `bin` 目录**

其中放置 Python 或 Bash 脚本，智能体也应具备创建这类脚本的技能，用来让自己的工作更高效。

例如，我有一个叫作 `agent_review` 的 Bash 脚本，智能体可以通过 CLI 发起其他智能体的审查，而不需要记住每个智能体各自不同的调用方式。

还要准备相应文档，说明如何有效编写脚本，并要求智能体持续扩充这些工具。

**10. 定期让智能体扫描最近的提交**

从跨提交、更高层次的视角检查潜在问题和容易踩坑的地方。

**11. 准备一份编码约定文档**

这份文档只记录你希望在代码库中遵循的具体编码规范。

审查智能体会经常使用它。

不过，其中很多规则最好同时固化到检查器里。

**12. 准备一个智能体循环或“夜班”技能**

用于自主执行任务，并从编排层面明确智能体应该如何开展工作。

**13. 准备一个智能体可以访问的任务队列**

我的方案只是一个 `TODOS.md` 文件。

你的任务队列也可以放在 Linear 等系统里，并提供一个通过 API 获取任务的 CLI。

**14. 定期执行“虚假信心测试审计”**

准备一个专门的技能，用来查找那些看似通过、实际上并没有验证预期行为的测试，并修复这些测试。

**15. 使用视觉回归测试**

对界面进行截图，通过工具进行比较，同时交给智能体进行视觉审查。

截图应与代码一起提交。这里使用 Git LFS 会比较方便。

至少也应该把这些截图上传到 PR 中。

**16. 自动执行性能基准测试**

让系统能够检测到性能何时出现退化。

**17. 准备性能分析工具**

让智能体能够：

* 针对特定场景进行基准测试；* 尝试新的实现技术；* 比较不同输出；* 比较不同性能分析结果。

**18. 在每个工作周期结束时执行完整验证**

包括：

* 运行全部测试；* 性能测试；* 智能体审查；* 全局扫描；* 其他所有验证流程。

这样，当你回来查看结果时，整个项目会尽可能处于整洁、可靠、可交付的状态。

如果你把这些内容都配置好，你的智能体编程体验会和那种只靠简单提示词、每次都要手动一步步引导智能体的方式完全不同。