---
title: 告别"氛围编程"：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践
source_url: https://mp.weixin.qq.com/s/-_IBJFuXpvoqMJxL9oaEJQ
publish_date: 2026-05-07
tags: [wechat, article, agent, harness, rag, coding]
review_value: 7
review_confidence: 7
review_recommendation: neutral
sha256: 7cd968b4e5cc11cf6a9d7f9d8151d6a28d56fd48043b2c120f544705c9c320f6
---
# 告别"氛围编程"：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践
> Source: https://mp.weixin.qq.com/s/-_IBJFuXpvoqMJxL9oaEJQ
> Author: 王树新 (高德大模型应用平台)
> Date: 2026-05-07
> Collected: 2026-05-07
## 一、识别 AI Coding 的三大核心问题
故事要从去年9月说起。当时在云栖大会 Qoder 分论坛上分享了基于 Prompt 工程、上下文工程的研发提效实践经验，出码率达到53%。经过半年多的 AI 极速发展，出码率可以达到 80%-90% 以上。但深入访谈团队、查看 PMO 数据指标时发现：提效并不明显。
**三大问题：**
1. **自由发挥问题**：AI 生成的代码常常天马行空，业务理解不足、规范缺失。
2. **效率降低问题**：指令不够清晰时，多轮对话反复拉扯，来回几次，还不如自己写。
3. **关键信息丢失问题**：多轮对话中，AI 往往会"忘记"之前的重要约束。
**当时的方案（Qoder）：** 通过 Repo Wiki、Memory 和 Rules 约束 AI 自由发挥；通过提示词工程改善效率；通过上下文工程和 Quest 模式避免信息丢失。
愿景：开发者只需要定义需求、验证结果；文档、编码、测试交给 AI。开发者从编码者变为 AI 架构师。
## 二、从"出码率"看"提效"背后的深层困境
**原因1：研发是全链路，不仅仅是写代码**
需求从提出到上线完整链路：产品提需、产研评审、方案设计、开发、代码评审、测试、联调、上线。《人月神话》——没有银弹。AI 优化了编码环节，但编码只占整个链路的 30%，整体提效有限。
**原因2：Vibe Coding 在存量应用中风险极高**
存量应用有历史包袱、隐式依赖、业务知识沉淀在代码里。"氛围编程"可能生成与现有系统完全不兼容的方案，问题可能在上线后才暴露。
案例：AI 修改了一个核心接口的参数顺序，单元测试全过，上线后三个下游服务报错，排查整整一天。
**原因3：任务粒度过大时 AI 顾此失彼**
一个涉及前后端十几个模块的重构任务，不可能在一个对话里完成，AI 上下文窗口有限，注意力分散。
**结论：AI 编程要从"个人技能"升级为"团队级工程能力"，从"氛围编程"进化为"规范驱动、工程治理"的研发范式。**
## 三、解法：SDD 与 Harness
### SDD（规范驱动开发）
**核心思想颠覆：** 规范不再是写给人类看的散文，而是结构化的、可被 AI Agent 精确理解和执行的"意图代码"。
传统开发：PRD/设计文档 = 指导书，代码 = 唯一真理之源 → 文档很快过期、与代码脱节。
SDD 颠覆：规范 = 唯一真实来源。需求变更时，首先修改"规范"，AI 工具根据规范重新生成、验证并更新底层代码。
**SDD 四步流程：**
1. **Specify（定义规范）**：开发者与 AI 探讨，输出一份结构化规范，定义用户故事、验收标准和系统约束。
2. **Plan（制定计划）**：AI 像编译器一样，将规范"编译"成详细的技术方案和任务拆解列表。
3. **Implement（执行落地）**：AI Agent 逐个执行任务列表，自动生成高质量代码。
4. **Validate（验证闭环）**：根据规范自动生成测试用例并执行，确保生成的代码与规范完全契合。
**SDD 关键：验收标准必须是可测试的、无歧义的。** 例如"用户登录成功后跳转到首页"是模糊的，而"用户登录成功后，3秒内跳转到首页，并在首页显示用户昵称"就是可测试的。
### Harness（驾驭工程）
**类比：** 想象一匹野马——AI 大模型拥有无穷力量，但没有马具，你根本骑不上去。Harness Engineering 的核心不是改变马的基因（模型本身），而是为这匹野马设计一套精密的控制系统。
**Harness 四大核心支柱：**
1. **上下文工程**：不再是简单的 RAG，而是结构化的信息投喂。维护一个"单一事实来源"，让 Agent 知道项目的目录结构、当前的执行计划以及哪些文档是最新的。
2. **架构约束**：这是 Harness 最硬核的部分。通过物理手段强制 AI 遵守规则。例如，规定 UI 层的代码绝对禁止直接访问数据库层。如果 AI 试图违反架构分层，代码甚至无法通过语法检查，从而在提交前就被拦截。
3. **反馈回路与熵管理**：AI 一定会犯错，关键在于如何发现并修正。建立自动化的测试沙箱：Agent 写完代码 → 自动运行测试 → 失败 → 读取错误日志 → 自我修正并重试。将人类修复错误的经验固化为新的规则，确保 AI 永远不会犯同样的错误两次。
4. **人类监督**：人类从"写代码的人"变成了"审核员"和"环境设计师"。职责是定义复杂的业务边界，处理那 5% AI 无法判断的模糊逻辑，以及优化 Harness 本身的规则。
**范式转移：**
- 提示词工程 → 上下文工程 → Harness Engineering
- "怎么跟 AI 说话" → "AI 应该看到什么" → "AI 如何在受控环境中运行"
## 四、Qoder 平台落地实践
### 知识库三层分层
**项目层知识：** 项目概述、目录结构、架构设计、技术选型。维护一个顶层 README.md 文件作为 Qoder 的"单一事实来源"。
**技术层知识：** 通用技术知识、编码规范、中间件、三方库文档、最佳实践、常见问题解决方案。跨项目复用。
**资产层知识：** 可复用的代码片段、组件、模板、历史需求 PRD、技术方案、归档的测试 Case。团队多年积累的"砖块"。
### Quest Spec 模式（Spec 生成）
通过 Spec 模式，AI 会主动提问，引导开发者澄清隐性知识，逐步补齐完整的 Spec。包含：数据模型、接口规范、验收标准。
**HITL（Human-In-The-Loop）：** 需求文档中有很多"隐性知识"——产品经理认为理所当然但实际需要澄清的信息。需求澄清不是全自动的，需要人工干预。
### 专家团模式（Experts Mode）
不同任务由不同角色的 Agent 来完成：前端工程师、后端工程师、测试工程师、架构师等。
AI 根据 Spec 生成执行计划，把大型任务拆解成可管理的小任务，每个小任务都有明确的输入、输出和验收标准。系统内置五类专家，每类专家有独立工具集，支持自定义专家类型。
**用户角色转变：** 用户也是协调链路的一部分。可以在专家团运行时随时介入，Experts Leader 在下一轮循环中处理。和 Experts Leader 澄清意图、对齐方向、审核计划、验收结果——更像带一个有经验的研发小组。
### 部署全链路
通过 Aone（阿里内部CI/CD平台）提供的 MCP（Model Context Protocol）工具，将构建产物交付给运维 Agent 进行部署。打通从需求到部署的全链路。
### Skills 能力扩展
Skills 是 Qoder 的能力扩展机制。例如数据库操作 Skill：AI 可以直接查询和修改数据库，进行数据准备和验证。
## 五、未来方向
1. **更智能的 Spec 生成**：当前 Spec 生成还需要较多的人工干预，未来希望通过更智能的对话式需求澄清，降低人工成本。
2. **更强大的 Agent Teams**：当前协作模式还比较简单，未来希望探索更复杂的协作模式，比如多轮迭代、动态角色分配等。
3. **更完善的知识管理**：知识库是整个体系的基础，未来希望探索更智能的知识提取、知识更新、知识复用机制。