[译]构建个人 AI 工厂（2025 年 7 月版）
概述
我保持多个 claude 代码窗口同时运行，每个窗口对应独立的 git-worktree 分支。o3 和 sonnet 4 负责制定计划，sonnet 3.7 或 sonnet 4 执行计划，最后由 o3 将结果与原始需求进行比对验证。发现的问题会反馈至计划模板，代码随之重新生成。这个工厂具备自我进化能力。
继续阅读，看看哪些内容可能对您有所帮助。
指导原则——修正输入，而非输出
当出现问题时，我不会手动修补生成的代码，也不会与 Claude 争论。相反，我会调整计划、提示或代理组合，从而确保下一次运行从构建层面就是正确的。
如果你玩过 Factorio，就会明白核心在于建造一个能自我生产的工厂。若未接触过，可以想象一个俯视角沙盒游戏——传送带和机器不断制造零件，因为工厂必须扩张。用 AI 代理实现相同理念：建造一个能生成代码、验证代码并随时间自我改进的代理工厂。
日常基础工作流程 - 构建 AI 工厂
我的主要交互界面是 claude code，它现在就是我的电脑。我还运行着一个本地 mcp 系统，负责执行 Goose 和 o3。保留 Goose 只是因为我已经配置好它能调用我们 Azure OpenAI 订阅中的模型。虽然计划未来改进，但目前运作良好。
第一步：规划
我会向 claude code 提交高层级任务，它会调用 o3 来生成执行计划。o3 是个优秀的规划者，能通过提出一系列问题来明确具体工作内容。最后我会让它生成一个 <task>-plan.md 文件，包含原始需求与具体实施方案。
第二步：执行
首先，sonnet 4 会读取计划、验证并将其转化为任务清单。接着 claude code 根据任务复杂度选择用 sonnet 3.7 或 sonnet 4 来执行计划。由于我日常工作主要使用 Clojure，因此更倾向用 sonnet 4 来确保括号匹配正确。 一个关键指令是要求 claude 在完成每个任务步骤时同步编写提交记录。这样无论是 claude 还是我都能在出错时回退到之前的状态。
第三步：验证 → 反馈至输入环节
代码生成后，我会让 sonnet 4 根据原始方案验证代码。接着由 o3 对照原始方案和原始需求进行二次验证。o3 毫不妥协。Claude 倾向于讨好用户，会保留不必要的向后兼容代码。o3 则会指出并要求删除这些代码。Claude 还经常在代码中添加"lint 忽略标记"，同样会被 o3 揪出。双模型验证机制能发现问题，省去了我与 Claude 反复沟通的麻烦。
sonnet 4 或 o3 发现的任何问题都会反馈到方案模板中修正，而非直接在线修改。
Git 工作树让我能并行开启多个 Claude 代码实例，同时开发多个功能。虽然仍需手动合并，但不再需要单独盯守某个智能体。
为何输入优于输出
输出结果可弃置；计划和提示词却能持续积累价值。
在源头调试能惠及所有未来任务。
它将智能体从代码打印机转变为自我提升的协作伙伴。
例如：曾有智能体编写了将整个 CSV 加载到内存的代码。我让它改用流式处理，并让智能体将"CSV 必须使用流式处理"写入计划规范。现在，我的计划检查器会自动标记任何未采用流式处理的 CSV 代码，我再也不用在每次 PR 审查时惦记这事。这就是工厂的自我进化。
扩展 AI 工厂规模
我已开始编码更复杂的工作流，为特定任务构建专门的代理（通过 MCPs 实现）。
一个 MCP 会扫描所有生成的 Clojure 代码，然后应用我们本地的代码风格规则。这些规则是原始计划和代理指令的一部分，但生成的代码经常存在风格问题。特别是当 Claude 进入 lint/测试/调试循环时。这个专注的代理意味着我们能获得更严格的行为，并始终如一地应用代码风格规则。
我也开始对内部库实施这种做法。它擅长检查生成的代码，并将诸如重试和 Thread/sleep 这样的代码替换成我们的重试库。
我正在构建一系列这样的小型智能体。每个智能体都能处理一项特定的细分任务，通过将它们组合起来，我就能搭建更复杂的工作流程。例如，我可以拿一份 API 文档和一组内部定义的业务案例，让多个智能体协作生成 API 集成方案、测试用例和技术文档。这种方式能显著提升功能开发和系统集成的效率，无需手工完成所有工作。
实现这个目标不能一蹴而就。秘诀在于： 持续迭代输入内容
并行发起多个任务尝试几乎没有成本——所以我经常这样做。所有智能体都并行运作。当某个智能体失败、卡顿或缺乏上下文时，我会把经验教训反馈到下一轮迭代中。我克制直接修正输出的冲动，转而优化输入内容。
这个循环就是工厂的核心：代码本身是可丢弃的；而指令集和智能体才是真正的资产。
接下来
我正在改进这个工厂的几个方面：
优化智能体之间的整体协调。目前我倾向于手动启动任务，但希望能实现更自动化的工作流管理和智能体间依赖关系处理。
将业务文档与智能体对齐。调整我们采集信息的抽象层级，使其更适合智能体高效使用。这意味着减少底层实现细节，转而聚焦于用例场景。
更复杂的工作流。目前的配置已能构建相当复杂的工作流程，但我还想更进一步。这意味着需要更多智能体、更紧密的协调以及它们之间更复杂的交互。
跨供应商优化 token 使用。Bedrock 的 token 限制（尤其是 Sonnet 4 模型）严重制约了效率。需要实现 Claude Max 套餐与 Bedrock 之间的无缝切换。
总结
这就是我当前 AI 工厂的现状：足够在我续杯咖啡时自动提交代码，但还不足以让我彻底告别工资单。约束条件会变，但核心原则不变： 修正输入，而非输出 。
原文链接：
https://www.john-rush.com/posts/ai-20250701.html