告别“氛围编程”：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践
告别“氛围编程”：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 记忆系统, 办公效率, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/-_IBJFuXpvoqMJxL9oaEJQ
摘要
阿里妹导读 文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。 本文作者是来自高德大模型应用平台的王树新。今天想和大家分享的主题是《告别"氛围编程"：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践》。 一、 识别 AI Coding 的三大核心问题 故事要从去年9月说起。当时，我受邀在云栖大会 Qoder 分论坛上，分享了我们团队基于 Qoder 进行研发提效的实践经验。那是一个充满期待的时刻——我们基于 Prompt 工程、上下文工程，在技术方案环节和研发环节实现了53%的 AI 出码率。在当时，这个数字让我们看到了 AI 编程的巨大潜力...
核心内容
阿里妹导读
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
本文作者是来自高德大模型应用平台的王树新。今天想和大家分享的主题是《告别"氛围编程"：基于 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 知道项目的目录结构、当前的执行计划以及哪些文档是最新的。
第二，架
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充