本文作者是来自高德大模型应用平台的王树新。今天想和大家分享的主题是《告别"氛围编程"：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践》。

一、 识别 AI Coding 的三大核心问题

故事要从去年9月说起。当时，我受邀在云栖大会 Qoder 分论坛上，分享了我们团队基于 Qoder 进行研发提效的实践经验。那是一个充满期待的时刻——我们基于 Prompt 工程、上下文工程，在技术方案环节和研发环节实现了53%的 AI 出码率。在当时，这个数字让我们看到了 AI 编程的巨大潜力。

经过半年多的 AI 极速发展，我们团队的出码率可以达到 80%-90% 以上了。这个数字看起来非常漂亮，几乎翻了一倍。但当我们深入访谈团队、查看 PMO 的数据指标时，我们发现了一个令人困惑的事实：提效并不明显。

出码率提升了，但项目交付周期没有明显缩短；AI 写了更多代码，但开发者的工作量并没有减少。这让我们不得不停下来，认真思考这个问题。

让我先回顾一下当时分享的核心内容。我们识别出了 AI Coding 存在的三大问题：

第一，自由发挥问题。 AI 生成的代码常常天马行空，原因在于业务理解不足、规范缺失。你让它写个功能，它可能给你三种不同的实现方式，每一种都"能跑"，但每一种都可能和你现有的架构格格不入。

第二，效率降低问题。 听起来很矛盾——AI 不是应该提效吗？但实际使用中，如果指令不够清晰，你会在多轮对话中反复拉扯。你说"改一下"，它改了；你说"不对，是这样"，它又改了。来回几次，还不如自己写。

第三，关键信息丢失问题。 多轮对话中，AI 往往会"忘记"之前的重要约束。任务粒度过大时，开头说的架构要求，到后面就消失了。

针对这些问题，我们当时提出了 Qoder 的系统化实践方案：通过 Repo Wiki、Memory 和 Rules 来约束 AI 的自由发挥；通过提示词工程来改善效率问题；通过上下文工程和 Quest 模式来避免关键信息丢失。

在分享的最后，当时我对于AI编程的未来充满期待：未来，开发者只需要定义需求、验证结果；而文档、编码、测试这些"体力活"将交给 AI。AI 将从生产工具转变为新的研发基础设施，开发者也将从编码者变为 AI 架构师。这是当时的愿景。

二、 从“出码率”看“提效”背后的深层困境

但是半年后，我们感到了困惑。为什么出码率提升没有带来真正的提效？我花了很长时间思考这个问题，最终发现了三个核心原因：

原因1：研发是一个全链路的过程，不仅仅是写代码

让我们来看一个需求从提出到上线的完整链路：产品提需、产研评审、方案设计、开发、代码评审、测试、联调、上线。每一个环节都有沟通成本，都有等待时间，都有可能出错。

《人月神话》中有一个著名的理论——没有银弹。为什么？因为软件开发不仅仅是编码，它涉及到沟通、协作、决策。你把编码环节优化了 50%，但如果编码只占整个链路的 30%，那整体提效只有 15%。更何况，AI 生成的代码可能带来更多的 Code Review 时间，更多的调试时间，更多的返工时间。

这让我意识到：真正的提效，必须打通全链路，而不仅仅是优化单个环节。 因此，我们要让 AI 能够跨越环节边界，从需求到部署形成闭环。

原因2：存量应用进行 Vibe Coding 风险非常高

什么是 Vibe Coding？就是"氛围编程"——随口给 AI 几句提示词，让它几秒钟生成几千行代码。这种方式在新项目、小脚本上可能还行，但在存量应用中，风险极高。

存量应用有什么特点？它有历史包袱，有隐式依赖，有业务知识沉淀在代码里。你让 AI 去"氛围编程"，它可能给你生成一个看起来完美、但和现有系统完全不兼容的方案。更可怕的是，这些问题可能在上线后才暴露。

我们曾经遇到一个案例：AI 生成的代码修改了一个核心接口的参数顺序，单元测试全过了，但上线后导致三个下游服务报错。排查了整整一天。这让我深刻意识到：在存量应用中，AI 编程必须从"氛围"走向"规范"，必须有明确的验收标准。

这就是我们引入 SDD（Specification-Driven Development，规范驱动开发）的原因。SDD 的核心思想是：在 AI 写代码之前，必须先将人类模糊的想法转化为清晰、无歧义的结构化规范，让 AI 在可控的轨道上运行。

原因3：大型项目、复杂需求超出了单次 AI 对话的能力边界

我们遇到过这样的需求：一个涉及前后端十几个模块的重构任务。你不可能在一个对话里完成，AI 的上下文窗口有限，它的注意力也会分散。任务太大，AI 就会顾此失彼。

这三个原因指向同一个结论：AI 编程要从"个人技能"升级为"团队级工程能力"，要从"氛围编程"进化为"规范驱动、工程治理"的研发范式。

三、 解法：引入 SDD 与 Harness

明确了问题，我们开始寻找解法。我们的目标是：让 AI 不仅在研发写代码环节提效，更要打通从需求 PRD 到直接部署的全流程。

我们将视角放到了两个核心思想上：SDD（规范驱动开发） 和 Harness（驾驭工程）。

SDD（规范驱动开发）

SDD 的核心思想是颠覆性的：规范不再是写给人类看的散文，而是结构化的、可被 AI Agent 精确理解和执行的"意图代码"。

在传统开发中，PRD 或设计文档只是"指导书"，代码才是唯一的"真理之源"。这导致文档往往很快过期、与代码脱节。SDD 颠覆了这个结构：规范成了唯一的真实来源。当需求变更时，开发者首先修改的是"规范"，随后由 AI 工具根据规范重新生成、验证并更新底层代码。

SDD 的工作流包含四个阶段：

第一，Specify（定义规范）。 开发者与 AI 探讨，输出一份结构化规范，定义好用户故事、验收标准和系统约束。这是"原始需求"阶段。

第二，Plan（制定计划）。 AI 像编译器一样，将规范"编译"成详细的技术方案和任务拆解列表。这是"技术文档"阶段。

第三，Implement（执行落地）。 AI Agent 逐个执行任务列表，自动生成高质量代码。这是"软件开发"阶段。

第四，Validate（验证闭环）。 根据规范自动生成测试用例并执行，确保生成的代码与规范完全契合。这是"功能及代码规范测试"阶段。

Harness Engineering（驾驭工程）

如果说 SDD 解决的是"做什么"的问题，Harness 解决的就是"如何可控地做"的问题。

Harness 这个词很形象。想象一匹野马——AI 大模型拥有无穷的力量，但没有马具，你根本骑不上去，甚至可能被它甩下来。Harness Engineering 的核心，不是去改变马的基因（模型本身），而是为这匹野马设计一套精密的控制系统。

一个成熟的 Harness 系统包含四个核心支柱：

第一，上下文工程。 不再是简单的 RAG（检索增强生成），而是结构化的信息投喂。维护一个"单一事实来源"，让 Agent 知道项目的目录结构、当前的执行计划以及哪些文档是最新的。

第二，架构约束。 这是 Harness 最硬核的部分。通过物理手段强制 AI 遵守规则。例如，规定 UI 层的代码绝对禁止直接访问数据库层。如果 AI 试图违反架构分层，代码甚至无法通过语法检查，从而在提交前就被拦截。

第三，反馈回路与熵管理。 AI 一定会犯错，关键在于如何发现并修正。建立自动化的测试沙箱：Agent 写完代码 → 自动运行测试 → 失败 → 读取错误日志 → 自我修正并重试。更重要的是，将人类修复错误的经验固化为新的规则，确保 AI 永远不会犯同样的错误两次。

第四，人类监督。 人类从"写代码的人"变成了"审核员"和"环境设计师"。职责是定义复杂的业务边界，处理那 5% AI 无法判断的模糊逻辑，以及优化 Harness 本身的规则。

从提示词工程到上下文工程，再到 Harness Engineering，这是一个范式转移：从"怎么跟 AI 说话"，到"AI 应该看到什么"，再到"AI 如何在受控环境中运行"。

基于这两个核心思想，我们开始在 Qoder 上进行落地实践。

四、 全流程自动化实践

从需求 PRD 开始，到 Spec 生成，到任务拆解，到代码生成，到测试验证，再到最终部署，整个过程是全自动化的。开发者在这个过程中扮演的角色，是需求澄清者、规范审核者、结果验证者，而不是代码编写者。

接下来，让我详细拆解整个实践过程。

步骤1：设计知识库

整个实践的基础是知识库。我们按照项目层、技术层、资产层三层结构来组织知识。

• 项目层知识包括项目的概述、目录结构、架构设计、技术选型等。这些是 AI 理解项目上下文的基础。根据按需加载的思想，我们维护一个 顶层README.md 文件，作为 Qoder 的"单一事实来源"——如果某个信息不在文档里，对 Qoder 来说它就不存在。
• 技术层知识包括通用的技术知识、编码规范、中间件、三方库文档、最佳实践、常见问题解决方案等。这些知识可以跨项目复用，是团队技术沉淀的体现。
• 资产层知识包括可复用的代码片段、组件、模板、历史需求 PRD、技术方案、归档的测试 Case等。这些是团队多年积累的"砖块"，AI 可以直接使用它们来构建新的功能。

在实际项目中，文档按照知识库三层分层结构设计目录，然后通过一个 README.md 文档来进行索引，按需加载。这种分层索引机制既保证了知识的结构化组织，又实现了按需加载的灵活性，让 AI 智能体能够高效获取所需知识，避免上下文过载。

这里要特别讲一下 Memory 的概念。Memory 是 Qoder 的一个核心能力，它解决了 AI 的"上下文焦虑"问题。在长周期的项目开发中，AI 需要记住很多信息：之前的决策、当前的进度、待办的事项等。Memory 提供了一种结构化的方式来存储和管理这些信息。通过这种 Memory 体系，AI 可以在正确的上下文中做出正确的决策，而不是每次都从零开始。

步骤2：处理需求 PRD

有了知识库，下一步是处理需求 PRD。我们使用 Qoder 的 Quest Spec 模式来生成规范化的 design.md 文档。

这个过程不是全自动的，而是需要人工干预的。这就是 HITL（Human-In-The-Loop，人在回路） 的思想。

为什么要 HITL？因为需求文档中有很多"隐性知识"——那些产品经理认为理所当然、但实际上需要澄清的信息。比如"用户登录"这个简单的功能，背后可能有：支持哪些登录方式？是否需要记住登录状态？密码强度有什么要求？登录失败怎么处理？等等。

通过 Spec 模式，AI 会主动提问，引导开发者澄清这些隐性知识，逐步补齐完整的 Spec。Spec 中会包含：

数据模型：涉及哪些数据表，字段定义是什么，关系是什么。

接口规范：API 的输入输出、错误码、幂等性要求等。

最重要的是：验收标准。这是 SDD 的核心。验收标准必须是可测试的、无歧义的。比如"用户登录成功后跳转到首页"是一个模糊的描述，而"用户登录成功后，3 秒内跳转到首页，并在首页显示用户昵称"就是一个可测试的验收标准。

有了完整的 Spec，AI 就有了明确的"施工图纸"，不再是"氛围编程"。

步骤3：专家团执行任务

Spec 准备好后，进入执行阶段。我们使用 Qoder 的专家团模式（Experts Mode）。

专家团模式的核心思想是：不同的任务由不同角色的 Agent 来完成。就像一个真实的开发团队，有前端工程师、后端工程师、测试工程师、架构师等角色。

AI 会根据 Spec 生成执行计划，把大型任务拆解成可管理的小任务。每个小任务都有明确的输入、输出和验收标准。然后，根据任务类型，分配给不同角色的 Agent。

系统内置五类专家，每类专家有独立工具集，系统还支持自定义专家类型（根据PPT内容介绍专家）

此外，要重点强调下用户角色的转变：用户也是协调链路的一部分。你可以在专家团运行时随时介入，Experts Leader 在下一轮循环中处理，调整任务方向或取消不再需要的任务。你的角色变了：和 Experts Leader 澄清意图、对齐方向、审核计划、验收结果，更像带一个有经验的研发小组。

步骤4：任务部署

代码生成和测试通过后，进入部署阶段。我们通过 Aone（阿里内部CI/CD平台）提供的 MCP（Model Context Protocol）工具，将构建产物交付给运维 Agent 进行部署。

通过 MCP，运维 Agent 可以：触发 CI/CD 流水线；执行部署脚本；查询部署状态；处理部署异常。这样，就打通了从需求到部署的全链路。开发者不再需要手动操作各种工具，只需要在 AI 的引导下完成关键决策。

对于前后端联动的项目，我们还打通了一些扩展工具的 Skills。

什么是 Skills？Skills 是 Qoder 的能力扩展机制。通过 Skills，AI 可以获得各种额外的能力，比如：

数据库操作 Skill：AI 可以直接查询和修改数据库，进行数据准备和验证。

有了这些 Skills，AI 就能够完成端到端的开发、测试、验证，而不仅仅是工程代码的生成。

五、 总结与展望

基于 SDD 和 Harness 的解法，我们打通了从需求到部署的全链路。更重要的是，我们实现了从"氛围编程"到"规范驱动、工程治理"的范式转变。开发者不再是被动的代码编写者，而是主动的需求定义者、规范审核者、结果验证者。AI 不再是不可控的黑盒，而是在 Harness 约束下的可靠工具。

展望未来，我们认为有三个方向值得探索：

第一，更智能的 Spec 生成。 当前 Spec 生成还需要较多的人工干预，未来希望通过更智能的对话式需求澄清，降低人工成本。

第二，更强大的 Agent Teams。 当前 Agent Teams 的协作模式还比较简单，未来希望探索更复杂的协作模式，比如多轮迭代、动态角色分配等。

第三，更完善的知识管理。 知识库是整个体系的基础，未来希望探索更智能的知识提取、知识更新、知识复用机制。

来源  |  阿里云开发者公众号

作者  |  王树新