不久前，我写了一篇题为“我让克劳德代码在编码前先思考。这是提示词。”的文章。这个前提触动了人们的神经：人工智能编程助手的问题从来不在于智能。这些模型编写一个可运行函数的速度比你描述它的速度还要快。问题在于流程。如果任其自行其是，克劳德代码的表现就像一个才华横溢的初级开发人员，跳过了阅读现有代码、编写测试以及在发布前审查自己工作的那些环节。它先编码，后思考。
因此，我为它制定了一套流程。我称之为/wizard（向导），它迫使一个克劳德实例养成纪律严明的资深工程师的习惯：在写下一行代码之前先阅读代码库，在实现之前先用验收标准定义“完成”，先编写一个失败的测试，然后编写刚好能通过测试的最少代码，接着尝试破坏你刚刚编写的代码。输出结果相同，都是可运行的代码，但不再有凌晨两点那种“为什么生产环境出错了”的后续麻烦。
那是第一版。一个克劳德，一种纪律，一次处理一个拉取请求。
这篇文章讲的是，当我停止试图让克劳德成为一个更好的开发人员，转而让它成为一个更好的工程团队时发生了什么，以及这对我的工作产生了什么影响。因为这里有一个没人警告过我的部分。在第一版中，我不再编写代码，也不再逐行进行代码审查。在第二版中，下一层负担也消失了：我不再编写那些驱动工作的深度技术提示词和吉特哈布议题。剩下的完全是另一个层面的工作。我调整工作流，并监督在其中运行的代理。我担任指挥。
新来的？ 你不需要读过第一版的文章也能理解这一篇，但它是下文所有内容的基础。原文链接以及存放所有这些内容的开源仓库链接都在底部。
转变：从资深开发人员到带领团队的资深架构师
关于独自工作的纪律严明的资深开发人员，有一点需要注意：他们仍然是在独自工作。他们仔细阅读、全面测试、自我审查，按顺序一次处理一个任务，并在每次代码审查往返期间阻塞等待。第一版是一个出色的独立贡献者，但独立贡献者是有上限的：只有一双手。
一位真正的资深架构师不会整天坐在编辑器前。他们将问题分解为可分离的关注点，编写大家共同遵循的契约，并将后端、用户界面和测试覆盖工作交给同时工作的人员。他们进行规划、分发任务、集成成果，并保持审查流水线运转，几乎从不亲自编写代码。这就是第二版：思维模式从“让克劳德成为资深开发人员”转变为“让克劳德成为带领团队的资深架构师，”而对我而言，则是从管理团队转变为指挥团队。具体来说：有一个单一的主线程编排器，它本身从不编写代码，而是将工作分发给专门的子代理，每个子代理都在其独立的吉特工作树中，并行构建，通过自动化审查关卡同时驱动多个拉取请求。
第一次目睹这一场景时，真正让我感到惊讶的情感回报是：我只需描述一个功能，然后走开，回来时发现一个工程团队在我睡觉期间一直在交付成果。
从第一版到第二版：变化之处
如果你使用过原始的/wizard（向导），以下是整个升级内容的表格总结：
| 第一版（一名纪律严明的开发人员） | 第二版（带领团队的架构师） |
|---|
