文章核心内容：作者通过多个Claude代码窗口和Git工作树构建了一个个人AI工厂，利用不同版本的Sonnet和O3进行计划制定、执行和结果检查。工厂能够自我改进，作者强调调整输入而非直接修补输出。日常工作中，作者主要使用Claude代码作为接口，结合本地MCP运行Goose和O3，逐步优化工作流程。

文章主要内容总结：

标题：构建个人AI工厂（2025年7月快照）

发布日期：2025年7月1日

概述： 作者详细描述了他如何构建一个个人AI工厂，通过多个Claude代码窗口和Git工作树来管理AI代理的生成、执行和验证代码的过程。该工厂能够自我改进，通过调整输入（如计划、提示和代理组合）来优化输出，而不是直接修改生成的代码。

关键点：

1. 指导原则：修复输入，而非输出

   • 当出现问题时，作者不直接修改生成的代码，而是调整计划、提示或代理组合，以确保下一次运行正确。
   • 类比于游戏《Factorio》，目标是构建一个能够自我生产的工厂，通过AI代理生成代码、验证代码并自我改进。

2. 日常工作流程：构建工厂

   • 步骤1：计划
     • 作者向Claude代码提供高级任务，Claude调用o3生成计划，并生成一个包含原始任务和实施计划的<task>-plan.md文件。
   • 步骤2：执行
     • Sonnet 4读取并验证计划，将其转化为任务列表。Claude代码根据任务复杂性使用Sonnet 3.7或Sonnet 4执行计划，并在每个任务步骤中生成提交记录，以便在出错时回滚。
   • 步骤3：验证与反馈
     • Sonnet 4和o3分别验证生成的代码是否符合原始计划和任务要求。任何问题都会反馈到计划模板中，而不是直接修复代码。

3. 为什么输入优于输出

   • 输出是可丢弃的，而计划和提示可以积累和改进。
   • 在源头调试问题可以扩展到所有未来任务。
   • 这种方法将AI代理从代码生成器转变为自我改进的同事。

4. 扩展工厂

   • 作者开始编码更复杂的工作流，使用特定代理（通过MCP管理）来构建特定任务。
   • 例如，一个MCP会扫描生成的Clojure代码并应用本地风格规则，确保代码风格一致。
   • 作者还构建了一系列小型代理，每个代理负责特定任务，通过组合这些代理可以构建更复杂的工作流。

5. 迭代输入的秘密

   • 作者强调迭代输入的重要性，而不是直接修复输出。通过并行运行多个代理，并将失败或停滞的教训反馈到下一次迭代中，工厂能够不断改进。

6. 未来改进计划

   • 作者计划改进代理的整体协调性，自动化工作流和代理之间的依赖管理。
   • 调整业务文档，使其更适合代理使用，关注用例而非低层次实现细节。
   • 构建更复杂的工作流，增加代理数量和协调性。
   • 最大化跨提供商的token使用，解决Bedrock的token限制问题。

总结： 作者的个人AI工厂已经能够自动生成代码，但仍需人工干预。核心原则是“修复输入，而非输出”，通过不断迭代和改进输入，工厂能够自我优化，逐步实现更复杂的工作流和自动化。

评论内容主要围绕AI辅助编程工作流的有效性和实用性展开，观点多样，既有支持也有质疑。以下是主要观点的总结：

1. 对工作流的具体性和实用性的质疑

• 评论1：作者对AI工作流的具体内容表示困惑，不确定是理想化的工作流还是实际应用中的工作流。
  • 引用：“I can't tell if they are talking about some kind of dream workflow that they have, or something they're actually using productively.”
• 评论2：希望看到更多具体细节，例如Claude和o3如何交互。
  • 引用：“I'd love to see more specifics here, that is, how Claude and o3 talk to each other, an example session, etc.”

2. 对AI生成代码质量的怀疑

• 评论4：质疑AI生成的代码是否适用于复杂的生产系统，认为个人使用的简单应用更可信。
  • 引用：“Writing high quality code in a complex production system? Much harder to believe.”
• 评论14：质疑使用多个Claude窗口进行代码管理是否足够严谨。
  • 引用：“Can someone convince me they're doing their due-diligence on this code if they're using this approach?”

3. 对AI工作流效率的讨论

• 评论9：虽然AI工作流有潜力，但目前专注于单一任务仍然更高效。
  • 引用：“it’s really promising, but I found focusing on a single task and doing it well is still more efficient for now.”
• 评论10：批评AI生成代码的方式，认为直接编写代码更环保和可持续。
  • 引用：“Just freaking write the code that you can expand and modify in the future instead of increasing your carbon footprint.”

4. 对AI工作流的支持与优化建议

• 评论7：作者分享了自己的AI工作流，强调在编写代码前先创建规范文档。
  • 引用：“Create a spec.md doc, before writing any code.”
• 评论15：认为AI可以帮助从需求生成代码，最终减少遗留代码问题。
  • 引用：“Fix your requirements, not the generated code.”

5. 对AI工作流未来发展的展望

• 评论16：认为AI工厂模式可以打破资源不平等，促进更多人参与创业。
  • 引用：“This 'AI factory for everyone' model may be able to break resource inequality.”
• 评论19：探讨LLM是否能够自我改进，并提出当前的技术限制。
  • 引用：“Could this be extended to the point of an LLM producing/improving itself?”

6. 对AI工作流局限性的反思

• 评论21：指出“修复输入”的假设在某些情况下不适用，尤其是在处理旧代码或大型代码库时。
  • 引用：“But how does this work for old code, large codebases, and emergencies?”
• 评论12：认为AI辅助工作流虽然会持续存在，但不会完全取代程序员。
  • 引用：“yes AI assisted workflow might be here to stay but it won't be the magical put programmers out of job thing.”

7. 对具体技术细节的讨论

• 评论22：询问Azure OpenAI订阅是否比ChatGPT更便宜。
  • 引用：“Is 'Azure OpenAI subscription' cheaper than ChatGPT via OpenAI?”
• 评论24：要求作者展示具体的代码。
  • 引用：“Show us the code, mate.”

总结：

评论中对AI辅助编程工作流的态度各异，支持者认为其有潜力提高效率并减少代码问题，而质疑者则对其具体应用、代码质量和效率表示怀疑。部分评论还提出了对技术细节和未来发展的探讨。