主题
告别"氛围编程"：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践
各位好，我是来自高德大模型应用平台的开发工程师，我叫王树新。大家可以看到，其实我今天分享主题主要是为了 Harness 和 SDD，然后我们是如何基于 Qoder 在我们团队进行这个实践的。
那其实在开始之前，我想先说一下，就是去年 9 月份，我当时受邀在云栖大会 Qoder 的分论台上，分享了我们团队在 Qoder 进行研发提效的一些实践经验。其实当时我们的分享都是基于像 ProPolar，然后上下文工程，在技术方案的环节和研发环节进行的一些提效。当时我们对外暴露的一个出码率是 53%。然后其实在当时，我们能看到这个数字它背后可能说对于 AI 在编程这个方面会有巨大的潜力。
我先回顾一下当时在云栖会上分享的一些核心内容。首先是在当时那个场景下，我们识别出了 AI Coding 存在的三个主要的问题：
第一个就是自由发挥的问题。AI 生成代码常常是这种天马行空的，原因就是因为它业务理解不足，或者是说规范很缺失。然后你让它写一个功能，它可能给你三种不同的实现方式，每一种都能跑，但每一种和我们现有的架构都是格格不入的。
第二个原因就是这个效率低下的问题。我们听起来好像很矛盾——我们用了 AI，难道不应该是提效吗？为什么我们这里边反而会说到这个效率低下的问题？实际上，在实际的使用过程当中，如果我们的指令不够清晰，你会在多轮对话的过程当中需要反复的和 AI 进行拉扯。你说改一下，它改了，然后你说不对，还要再改，它又改了。经过这么来回几次，很多人就说还不如自己写。
第三个就是关键信息丢失的问题。我们在这种多轮对话过程当中，AI 常常会忘记之前的一些重要的约束。在任务的这种颗粒度非常大的时候，开头说的一些架构的要求，到后面它就完全忘记了。
所以针对这些问题，我们当时是使用 Qoder 进行了一些系统化的实践方案。比方说，通过这种 Repo、Wiki、Memory 和 Rules 来约束 AI 的自由度；然后通过提示词工程来改善它的效率问题；我们通过这种环形工程快速模式避免一些关键信息的丢失。
那当时其实在分享最后，我还表达了对于 AI 编程的未来充满了期待：未来开发者只需要去做需求验证结果这种事，像文档、编码、测试这种体力活，我们完全可以交给 AI 来干。AI 可以从一个生产工具转变为新的研发的基础设施，开发者也能够从编码者转变为一个 AI 的架构师。
但这是半年前的一个愿景。但其实半年都过去了，情况是什么样的？
刚才有一位 CTO 说的这些，我很有共情。因为我觉得我们当时暴露的数字是 53%，然后现在我们经过很多的访谈，包括 PMO 的一些数据，告诉我们说我们现在整个团队的出码率 80% 到 90% 都是由 AI 来生成的，并且都能采纳了。但实际上，我们会发现即使我们的 AI 写了非常多代码，但是开发者的工作量并没有减少。出码率提升了，但是整个项目的交付周期并没有明显的缩短。
所以我们面对这样的一个现象，就不得不停下来认真思考一下这个背后的问题是什么。所以，为什么出码率的提升它没有带来真正的提效呢？
那我其实花了很长时间去思考这个事情，然后并且团队做了大量的实践，最终我们是归纳了三个核心的原因：
第一个，研发是一个全链路的过程，它不仅仅是写代码。 我们其实来看一个需求从提出到上线，当然这我们在高德内部要经过产品的提需，然后产品经理去做对需求的评审，然后方案的设计、开发、代码的评审、测试链路、上线。每一个环节都有沟通成本、等待时间、都有可能犯错。
其实在《人月神话》里面有一个这样的一个理论——没有银弹。为什么没有银弹呢？就是因为人家开发过程它其实不仅仅是编码，更多的它还要涉及到沟通、协作、决策。你把编码环节优化了 50%，但是它其实在整个链路当中，编码可能只占 30%。那我们来看全链路的话，其实它整体提效就只有 15%。
所以我们用 AI 在生成代码的时候，可能还会再去引入更多的 Code Review 的时间、更多的调试时间、然后更多的对话、更多的返工的时间。所以我意识到，如果说要真正提效的话，必须打通从需求侧到声称到部署这样的一个全链路，而不仅仅是优化一个单个的环节。所以接下来我可能会跟大家去交流一下，就是怎么让 AI 跨越这种环节的边界，从需求到部署形成闭环。
第二个原因呢，就是存量的应用进行氛围编程存在较大风险。 其实刚才我听到很多问题还更多的是一个新的应用从零到一的时间去生成，但实际上在阿里内部，我们大多数的都是存量的大型项目。对于这种存量的大型项目，我们用氛围编程这种方式其实风险非常高。
存量应用的特点呢，就是有历史包袱、有隐式的依赖，还有很多的这种隐性的业务知识沉浸在代码里边。你让 AI 去氛围编程，那它可能给你一个看起来很完美，但是和现有的系统完全不兼容的方案。更可怕的是，这些问题它可能等到上线之后我们才会发现。
我们曾经就遇到过一个案例，就是在我们用 AI 生成了一个代码，它修改了一个核心接口的参数的顺序。然后我们去跑单侧，单元测试全通过了，然后上线之后很多下游的服务就找过来告诉我们，下游服务三个下游服都疯狂地报错了，然后排查了一整天才找到原因。
第三个原因呢，就是大型项目超出 AI 能力边界。 其实 AI 编程要从"个人技能"升级为"团队级工程能力"。因为大型项目涉及前后端十几个模块的重构任务，不可能在一个对话里完成。AI 的上下文窗口有限，注意力会分散，任务太大就会顾此失彼。
那么针对这三个核心的原因，我们就开始思考怎么去解决。那首先我们先确定了三个核心的思路：
第一个思路，就是我们必须要打通全链路，让 AI 跨越环节的边界。 所以我们当时是打通了从需求的 PRD 到设计、到开发、到测试、到上线部署的完整链路。那在这个链路当中，我们是把 AI 作为整个链路当中的一个核心的引擎，而不是仅仅作为一个编码的工具。
第二个思路呢，就是我们要建立一种受控的编程模式，而不是外部耦合的氛围编程。 所以我们当时是基于 Harness 治理和 SDD 这种方式，来构建一个受控的编程模式。那这种模式呢，它能够保证 AI 在一个明确的边界内进行生成，而不是天马行空。
第三个思路呢，就是我们要建立一种团队级的 AI 协作模式，而不是单点地使用 AI。 所以我们当时是构建了一个多角色的 Agent 团队，来模拟一个真实的开发团队。那这样呢，就能够让 AI 能够更好地去协作，更好地去完成复杂的任务。
那接下来我就分别从这三个方面来详细地介绍一下，我们具体是怎么做的。
一、SDD 工作流：规范驱动的开发模式
那首先呢，我们先来看一下 SDD 工作流。那 SDD 呢，它是 Specification-Driven Development 的缩写。那这个呢，它是一种基于规格说明书的开发模式。
那 SDD 工作流主要是由这么四个关键的步骤来组成的：
Specify（定义规范）。开发者与 AI 探讨，输出一份结构化规范，定义好用户故事、验收标准和系统约束。
Plan（制定计划）。AI 就像编译器一样，将规范"编译"成详细的技术方案和任务拆解列表。
Implement（执行落地）。AI Agent 逐个执行任务列表，自动生成高质量代码。
Validate（验证闭环）。根据规范自动生成测试用例，并执行，确保生成的代码与规范完全契合。
那通过这样的一个工作流呢，我们就能够让 AI 能够在一个明确的规范下进行开发，而不会天马行空。
二、Harness 治理：建立受控的编程模式
那接下来呢，我们来看第二个方面，就是 Harness 治理。那这个呢，其实是我们整个方案的一个关键。
那为什么要进行 Harness 治理呢？就是因为我们在使用 AI 进行编程的时候，AI 它的自由度是非常高的。如果我们不进行任何的限制的话，那 AI 它可能就会天马行空，生成一些不符合我们要求的代码。
那一个成熟的 Harness 系统包含四个核心支柱：
第一个就是上下文工程。 那这个呢，主要是结构化信息投喂。那通过建立"单一事实来源"，让 Agent 知道目录结构、执行计划、最新文档，定义复杂的业务边界。
第二个就是架构约束。 那这个呢，主要是建立自动化的测试沙箱。通过物理手段强制 AI 遵守规则。例如：UI 层代码绝对禁止直接访问数据库层。失败就进行自我修正，确保问题在提交前就被拦截。
第三个就是反馈回路与知识管理。 那这个呢，主要是人类修复错误的经验固化为新规则，确保 AI 不犯同样的错误，同时优化 Harness 本身规则。处理 AI 无法判断的模糊逻辑。
第四个就是人类监督。 那这个呢，主要是把人类从"写代码的人"变成"审核员"和"环境设计师"。从"怎么跟 AI 说话"，到"AI 应该看到什么"，再到"AI 如何在受控环境中运行"。
那通过这样的四个方面的治理呢，我们就能够建立一个受控的编程模式，而 AI 在这个模式内进行生成，就不会天马行空。
三、知识管理：Memory 能力构建
那接下来呢，我们来看第三个方面，就是知识管理。那这个呢，其实是我们整个体系的基础。
那在这个过程当中，我们其实是基于 Qoder 的 Memory 能力来构建知识管理的。那 Memory 呢，它是 Qoder 的一个内置的能力，它就是把我们的一些知识做结构化的组织和存储。
那在实际的项目中，我们是按照三层结构设计目录：
- Project Layer（项目层）：包含项目概览、技术方案、测试用例等。
- Technology Layer（技术层）：包含编码规范、第三方库版本、接口文档等。
- Assets Layer（资产层）：包含架构文档、知识库版本等。
那同时呢，我们还在 Memory 提供了一种结构化的方式来存储和管理当前的进度、待办的事项等信息。
那 README.md 中为文档提供索引，文档按需加载，主动记忆。那这种所谓的机制呢，就能够保证我们知识的一个结构化的组织，同时也能够让 Agent 能够去做按需的加载，按需的去获取。
四、需求澄清：Spec 模式与 HITL
那接下来呢，我们来看第四个方面，就是需求澄清。那这个呢，其实是我们在有了知识库之后，下一步就开始处理需求的 PRD。
我们其实是使用 Qoder 的 Quest 的 Spec 模式来生成规范化的规格说明书。那这个过程呢，它其实不是自动化的，而是需要人工干预的。那为什么要人工干预呢？就是因为当前的文档当中其实是有很多隐性知识的。很多产品经理提了一个 PRD，它里面会有很多知识，会认为是研发同学理所当然应该知道的，但实际上是需要我们在使用 AI 开发的过程中，需要 AI 生成的。
比方说，我们想做一个用户登录的这样的一个功能，那它背后其实需要去告诉 AI：支持哪些登录方式？然后要不要进入这个登录态？密码的强度是怎么设置的？登录失败怎么处理？等等。
那通过 Agent 的这种模式，AI 就会主动的去提问，然后引导开发者去澄清这些隐性的指示，逐步的去补充一个完整的规格说明书。那验收标准呢，必须是可测试的、无歧义的，如"用户登录成功后 3 秒内跳转到首页"。
那 HITL 呢，它确保关键决策由人类做出，提高系统的可靠性和可控性。
五、执行：专家团模式与任务拆解
那在有了规格说明书之后呢，AI 就像那边有了一个明确的施工的图纸，就不再是 一种氛围编程的模式了。那之后呢，就是进入到这个执行的阶段。
那之前一段我们为什么使用 Qoder 的专家团的这样一个模式呢？就是因为我们其实在思考，我们当前所有的人类的组织的设计，我们分成了有前端工程师、测试工程师、后端工程师等等，让那个角色。而专家团的核心思想其实也是不同的任务交给不同角色的 Agent 团来完成，然后像一个真实的开发团队一样。
那 AI 就会根据规格说明书去生成具体的执行的计划，然后把一个大型的任务拆解成一些可管理的小任务，然后每一个小任务都有明确的输入和输出，包括验收标准。然后之后再把这些任务分配给不同角色的 Agent 团来执行。
那这个里面，像它的专家团其实是内置了很多 Agent：
- 调研专家：技术方案选型、问题根因排查。
- 编码专家：新功能开发、Bug 修复、代码重构。
- QA 专家：回归验证、质量门禁检查。
- 评审专家：代码审查、风险评估。
- 浏览器专家：前端交互验收、端到端测试。
那这个里面其实除了专家，用户在使用这些专家的时候，其实不仅仅是一个观察者，更多的我们也能够参与进去。比方说，在专家团它在执行的过程当中，我们发现有一些问题，我们可以随时地去介入，然后和专家团有一个 Leader 的这样一个角色，让它去调整任务的方向，或者是取消不在需要的这样的一些任务。
那这样的话呢，其实我们角色就变了，就不再是一个观察者，或者是一个执行者，而是能够和 Leader 去澄清意图、对其方向、审视计划、验收结果。就像我们带了一个有经验的这样的一个研发小组一样。
六、部署：MCP 工具与运维 Agent
那之后呢，就是到了这个部署阶段。所以我们是打通了，通过这种 MCP，打通了整个的阿里内部的 AI CICD 的平台。
那 MCP（模型上下文协议）的能力呢，包括：
- 运维 Agent 可以触发 CI/CD 流水线、执行部署脚本。
- 查询部署状态、处理部署异常。
- 打通从需求到部署的全链路。
那通过这样的方式呢，就像是把整个的从需求的 PRD 到部署全流程就给打通了。
那这个里面呢，其实也可以通过一些 Skills 的方式去扩展。比方说，实际上我们在真正实践过程当中，我们会发现除了工程代码，我们还要去操作一些底层的数据库。那么可以通过这个数据库操作的 Skill，直接的让 AI 帮我们查询、修改数据库。
这样的话呢，其实整个的端到端的开发，然后测试验证这样的流程，就完全都可以自动化掉。
七、总结与展望
最后就是回顾一下今天的分享。就是我们从最早的这个云栖会出发，然后去发现了出码率提升，但是提效不明显的这样一个问题。然后分析了三个核心的原因，并且基于这些原因给出了一些具体的解法。
那其实我们能够看到，整个的这个过程，其实我们是实现了从这个氛围编程到规范驱动、工程治理这样一个范式的转变。然后我们通过这种 Harness 治理，去让 AI 在约束下变成了一个可靠的工具。
那范式转变的意义呢：
- 开发者：从被动代码编写者变为主动的需求定义者、规范审核者、结果验证者。
- AI：从不可控的黑盒变为 Harness 约束下的可靠工具。
那在未来，我认为我们其实有三个方向可以去探索：
第一个方向，就是更智能的规格说明书生成。 其实当前规格说明书生成还需要更多的人类的干预，我们其实希望未来能通过更智能的对话的方式去做需求的澄清，让需求澄清过程更加自然流畅，减少开发者的认知负担。
第二个方向，就是更强大的 Agent Teams。 我们当前 Agent Teams 的协作模式还可以去更多的探索，比方说一些更复杂的一些场景。让多个 Agent 之间形成更高效、更智能的协作网络。
第三个方向，就是最底层的基础——知识管理。 我们如何去做整个知识库的体系，如何去构建，然后知识如何去更新、如何去复用。让团队的知识沉淀能够持续增值，形成良性循环。