从写代码到领导智能体：一场开发范式的转变

一段关系的演变

一位开发者在博客中分享了自己的亲身经历：起初，他与 Claude Code 的互动十分简单——输入请求，阅读反馈，纠正错误，再次输入。这种方式确实有效，但所有协调工作都由人来完成。是他记住三条消息前的决定，是他注意到模型偏离方向，也是他判断任务何时算「完成」。

如今，他的大多数提示词不再要求写代码，而是描述一个流程：哪些阶段依次运行、每个阶段由谁执行、什么算作证据、何时停止。智能体负责写代码，人则负责制定它工作的规则。

这不是关于「更好的提示词」的故事，而是关于一份不同的工作。

阶段一：提示词交互的瓶颈

最初，所有工作都发生在一个长对话中。请求一个功能，得到一个 diff，指出问题，重复。问题会缓慢浮现：

• 聊天记录成了唯一的真相来源。 决定只存在于滚动回看中，当上下文变长，模型会悄悄「忘记」之前达成的共识。
• 每一次修复都会污染下一步。 当开发者要求写测试时，模型已经看过了实现代码，于是测试匹配的是代码，而非需求。
• 「完成」意味着「模型说它完成了」。 没有证据，只有信心。

这些并非模型的错。问题在于，把分析、架构、开发、测试和审查全部塞进一个上下文，同时还要记住一切。

阶段二：规格驱动开发的突破

第一个真正的改变是采用规格驱动开发（SDD），使用 Spec Kit 将工作拆分为明确的阶段，每个阶段产出一个文件：

spec → clarify → plan → tasks → analyze → implement → verify

其中两条规则改变了后续的一切。

规则一：状态通过文件传递，而非聊天

在每个阶段之间清空上下文。听起来很浪费，但效果显著：plan 必须读取真实、已批准的 spec.md，tasks 必须读取真实的 plan.md。每个阶段都与实际写下来的内容保持一致，而不是与对话中堆积的半成品决定保持一致。如果不在文件里，就等于没发生。

规则二：实现者不写测试

这一点最令人意外。实现阶段只写产品代码，测试在验证阶段才写，基于规格中的验收示例，由不允许阅读产品源码的智能体完成。原因很简单：已经看过实现的上下文，写出的测试是在确认实现；而「盲测者」写出的测试才是在确认需求。甚至还有一个审查步骤，专门标记那些预期值无法追溯到验收示例的测试。

盲测者（blind tester） 指的是在编写测试时不允许阅读产品源代码的智能体或人。这一做法借鉴了软件工程中的「黑盒测试」思想：测试应当只依据需求文档和验收标准来验证行为，而不是依据实现细节来反推期望值。当一个上下文已经看过实现代码时，它写出的测试往往会迁就代码的实际行为——例如把某个偶然的错误返回值写成期望值，或者绕过难以触发的分支。这种测试虽然能通过，却不能证明需求被满足，只能证明代码没有变化。让一个隔离的、未见过源码的子智能体基于验收示例写测试，再让第三个角色审查测试的预期值是否可追溯到验收示例，就形成了一个「需求 → 测试 → 实现」的独立验证链。这也解释了为什么编排流程必须为每个角色分配全新、最小的上下文——上下文污染本身就是测试失效的源头。

两条入口，一条流水线

新功能从需求开始：规格是编写出来的，代码随之而来。Bug 从现有代码和症状开始：规格是从代码行为和报告问题中逆向发现的。关键在于，两条路径产生相同的 spec.md，因此 Bug 修复会重新汇入同一条流水线。逆向路径被允许在三个关卡停下来而非猜测：复现、预期行为、归因。教会智能体何时停止，与教会它做什么同样有价值。

Spec Kit 是 GitHub 开源的一套规格驱动开发（Spec-Driven Development，简称 SDD）工具包，核心思路是让规格文件成为开发的唯一真相来源，而不是把需求散落在聊天记录、issue 或开发者的脑子里。它把开发流程拆解为一系列可验证的阶段命令：spec 定义要解决什么问题，clarify 消除规格中的歧义，plan 给出技术方案，tasks 拆分为可执行任务，analyze 做一致性检查，implement 生成代码，verify 验证结果。每个阶段产出一个磁盘上的文件，下一阶段必须读取上一阶段的真实文件才能继续。这样设计的意义在于：无论人还是 AI，都对着同一份写下来的契约工作，而不是对着各自记忆中的半成品共识。Spec Kit 与 Claude Code、Copilot 等智能体协作时，通常以斜杠命令或提示词模板的形式嵌入工作流，使「先写规格再写代码」成为可自动化的流水线，而不仅仅是一种倡导。

阶段三：成为编排者

即使有了 SDD，开发者仍然手动运行每个阶段：清空上下文、运行下一个命令、读取输出、决定是否继续。他形容自己像一个非常专注的 for 循环。于是，他把这个循环写成了提示词。主会话不再干活，而是成为编排者：

• 只作为编排者行动，绝不亲自执行任何阶段的工作
• 按顺序运行阶段，每个阶段创建一个隔离的子智能体
• 每个阶段前读取进度文件，完成后记录结果
• 子智能体最多用 10 行汇报：状态、产出物、阻塞项
• 如果某阶段失败或被阻塞，记录并停止，不运行后续阶段

信任机制的构建

每个阶段使用全新子智能体，只给必要信息：目标、阶段指令、相关产出物、约束和验收标准。不传入之前的对话记录或推理过程。编排者本身只保留决定下一步所需的状态，它是一台状态机，不是工作区。

标准交接格式：每个子智能体返回统一报告，包括状态（PASS/FAIL/BLOCKED）、摘要、产出物、验证、阻塞项和建议的下一步。其中一条关键原则：PASS 仅在验收标准被实际检查过时才有效。没有报告错误不等于有证据。

进度即结构化状态：进度文件是编排者的记忆，记录当前阶段、已完成阶段、产出物、验证结果、阻塞项和审查轮次。如果仓库实际状态与文件矛盾，编排者会调查，而不是信任任何一方。

有硬性限制的审查循环：SDD 阶段通过后，新的子智能体对整个变更做代码审查。如果有问题，新智能体修复，相关测试重新运行，再由独立审查检查结果。两条护栏：最多三轮审查，超过则停止报告而非宣布成功；不允许自我认证，不能凭自己的解释标记问题已解决，也不能为了让合理发现消失而编辑规格。

明确的退出条件：流程只有在以下条件同时满足时才结束——无可操作的审查发现、相关测试运行并通过、验证报告通过、规格/代码/测试保持一致、最终 diff 无意外更改、无阻塞项。然后才提交、推送并创建 PR。如果无法确定目标分支，就停下来询问。「不要猜分支」写在了提示词里。

交接格式（handoff format） 是多智能体编排中的关键接口设计：上游智能体完成任务后，必须按照约定的结构化模板向下游汇报，而不是自由发挥地写一段总结。在本文的流程中，标准交接格式包含状态（PASS/FAIL/BLOCKED）、摘要、产出物、验证、阻塞项和建议的下一步。结构化交接的价值在于三点：一是让编排者不必阅读全部推理过程就能判断流程是否可以继续；二是强制智能体在声称完成时附上可检查的证据；三是把「汇报」本身变成一种受约束的输出，避免智能体用自然语言模糊掉失败和不确定性。与此配套的还有「10 行汇报」这类长度限制，目的是防止子智能体把上下文重新灌回主会话，从而破坏隔离。交接格式设计得越具体，编排者对流程的信任就越不依赖于对模型「感觉」的信任。

阶段四：为智能体而规划

当执行变得智能体化后，薄弱点向上游移动：计划本身。为人类写的计划（「重构模块」「修复测试」）对于在隔离上下文中工作、没有历史的智能体来说太模糊了。

因此需要第二个提示词，其唯一职责是产出编排者可执行的计划。每个任务都携带自己的执行契约：目标、需加载的上下文、范围、实现指导、依赖关系、验收标准、验证方式、交接产出物。同时产出依赖图（哪些顺序执行、哪些可并行、哪里可能冲突）和执行状态检查点。

判断好计划的标准：另一个智能体能否仅凭任务规格和引用的文件执行这个任务，而无需原始调查过程？ 如果不能，任务就还没有规划完。

真正改变的是什么

回顾整个过程，代码确实变好了，但那不是主要区别。工作本身变了。

提示词阶段	领导智能体阶段
写请求	写流程
聊天记录保存状态	文件保存状态
一个上下文做所有事	每个角色有全新、最小上下文
「完成」是模型的看法	「完成」是已验证条件的清单
靠通读一切来发现错误	关卡、限制和审查来捕捉
更多智能体感觉像进步	只委派目标所需的部分

几条值得传递的经验：

• 上下文是需要管理的资源。 像受限系统中的内存一样对待：只加载需要的，其余持久化。
• 教智能体停下来。 阻塞项、关卡和轮次限制让流程值得信赖。会暂停并解释的智能体，比猜测后继续的更有价值。
• 分离构建者和检查者。 盲测和独立审查只有在检查者没看过构建者推理时才有效。
• 要求证据，而非信心。 把这一点写进提示词，否则智能体会愉快地报告成功。
• 你仍然负有责任。 审查规格、计划和最终 diff。领导智能体不等于离开房间。

开发者角色的重新定义

这一转变的核心并非工具升级，而是职责重构。当智能体接管了代码生成，人的价值转移到流程设计、信任机制构建和质量把关上。从「写代码的人」变成「制定规则并验证结果的人」，这或许是 AI 编程时代最深刻的范式转移。

你还在长对话阶段，还是已经开始为智能体编写流程？关键在于：你设计的护栏是否足够让流程在没有你盯着的情况下仍然可信。