告别"氛围编程"：阿里高德团队的Harness治理与SDD规范驱动开发实践
🎯 核心发现：80%出码率 ≠ 提效
阿里高德大模型应用平台负责人王树新分享了一个令人困惑的事实：
"我们团队的AI出码率可以达到80%-90%以上，但查看PMO数据指标时，发现提效并不明显。"
现象：
- 出码率提升了近一倍（从53%到80%+）
- 项目交付周期没有明显缩短
- 开发者工作量并没有减少
这迫使团队重新思考：AI编程的真正提效瓶颈在哪里？
🚨 AI Coding的三大核心问题
问题1：自由发挥
AI生成的代码常常"天马行空"：
- 业务理解不足
- 规范缺失
- 一个功能可能生成三种不同实现，每种都"能跑"，但都与现有架构格格不入
问题2：效率降低
听起来矛盾，但实际存在：
- 指令不够清晰时，在多轮对话中反复拉扯
- "改一下"→改了→"不对，是这样"→又改
- 来回几次，还不如自己写
问题3：关键信息丢失
- 多轮对话中，AI会"忘记"之前的重要约束
- 任务粒度过大时，开头的架构要求到后面就消失了
🔍 为什么高出码率没有带来提效？
原因1：研发是全链路过程，不只是写代码
需求从提出到上线的完整链路：
产品提需 → 产研评审 → 方案设计 → 开发 → 代码评审 → 测试 → 联调 → 上线
每个环节都有：
- 沟通成本
- 等待时间
- 出错可能
《人月神话》的启示：
"没有银弹。软件开发不仅仅是编码，它涉及到沟通、协作、决策。"
计算：编码环节优化50%，但编码只占整个链路的30% → 整体提效只有15%
更何况，AI生成的代码可能带来更多：
- Code Review时间
- 调试时间
- 返工时间
结论：真正的提效，必须打通全链路，而不仅仅是优化单个环节。
原因2：存量应用进行Vibe Coding风险极高
Vibe Coding（氛围编程）：随口给AI几句提示词，让它几秒钟生成几千行代码。
存量应用的特点：
- 有历史包袱
- 有隐式依赖
- 有业务知识沉淀在代码里
风险案例：
AI生成的代码修改了一个核心接口的参数顺序，单元测试全过了，但上线后导致三个下游服务报错，排查了整整一天。
结论：在存量应用中，AI编程必须从"氛围"走向"规范"，必须有明确的验收标准。
原因3：大型项目超出单次AI对话的能力边界
涉及前后端十几个模块的重构任务：
- AI的上下文窗口有限
- 注意力会分散
- 任务太大就会顾此失彼
✅ 解法：SDD + Harness
SDD（Specification-Driven Development，规范驱动开发）
颠覆性思想：
"规范不再是写给人类看的散文，而是结构化的、可被AI Agent精确理解和执行的'意图代码'。"
传统开发的痛点：
- PRD或设计文档只是"指导书"
- 代码是唯一的"真理之源"
- 文档很快过期、与代码脱节
SDD的结构反转：
- 规范成为唯一的真实来源
- 需求变更时，首先修改"规范"
- 由AI工具根据规范重新生成、验证并更新底层代码
SDD四阶段工作流
| 阶段 | 名称 | 核心动作 | 输出物 |
|---|---|---|---|
| 1 | Specify（定义规范） | 开发者与AI探讨，输出结构化规范 | 用户故事、验收标准、系统约束 |
| 2 | Plan（制定计划） | AI像编译器一样，将规范"编译"成技术方案 | 详细技术方案、任务拆解列表 |
| 3 | Implement（执行落地） | AI Agent逐个执行任务 | 自动生成的高质量代码 |
| 4 | Validate（验证闭环） | 根据规范自动生成测试用例并执行 | 代码与规范完全契合的验证 |
Harness Engineering（驾驭工程）
核心隐喻：
"想象一匹野马——AI大模型拥有无穷的力量，但没有马具，你根本骑不上去，甚至可能被它甩下来。Harness Engineering的核心，不是去改变马的基因（模型本身），而是为这匹野马设计一套精密的控制系统。"
Harness四支柱：
1️⃣ 上下文工程
不再是简单的RAG，而是结构化的信息投喂：
- 维护"单一事实来源"（Single Source of Truth）
- 让Agent知道项目目录结构、当前执行计划、最新文档
- 按需加载，避免上下文过载
2️⃣ 架构约束
最硬核的部分——通过物理手段强制AI遵守规则：
- 规定UI层代码绝对禁止直接访问数据库层
- 如果AI试图违反架构分层，代码甚至无法通过语法检查
- 在提交前就被拦截
3️⃣ 反馈回路与熵管理
AI一定会犯错，关键在于如何发现并修正：
Agent写完代码 → 自动运行测试 → 失败 → 读取错误日志 → 自我修正并重试
更重要的是，将人类修复错误的经验固化为新的规则，确保AI永远不会犯同样的错误两次。
4️⃣ 人类监督
人类角色转变：
- 从"写代码的人"→"审核员"和"环境设计师"
- 职责：定义复杂的业务边界
- 处理那5% AI无法判断的模糊逻辑
- 优化Harness本身的规则
🛠️ 全流程自动化实践
知识库三层架构
| 层级 | 内容 | 说明 |
|---|---|---|
| 项目层 | 项目概述、目录结构、架构设计、技术选型 | AI理解项目上下文的基础 |
| 技术层 | 通用技术知识、编码规范、中间件、三方库、最佳实践 | 可跨项目复用，团队技术沉淀 |
| 资产层 | 可复用代码片段、组件、模板、历史需求PRD、测试Case | 多年积累的"砖块"，AI直接复用 |
Memory体系
解决AI的"上下文焦虑"问题：
- 在长周期项目开发中存储关键信息
- 记住之前的决策、当前进度、待办事项
- 结构化方式存储和管理信息
- 让AI在正确上下文中做正确决策，而不是每次都从零开始
Quest Spec模式
生成规范化的design.md文档，需要HITL（Human-In-The-Loop）：
为什么需要HITL？ 需求文档中有很多"隐性知识"——产品经理认为理所当然、但实际上需要澄清的信息。
示例："用户登录"功能背后的问题：
- 支持哪些登录方式？
- 是否需要记住登录状态？
- 密码强度有什么要求？
- 登录失败怎么处理？
AI主动提问 → 引导开发者澄清 → 逐步补齐完整Spec
Spec核心要素
| 要素 | 说明 |
|---|---|
| 数据模型 | 涉及哪些数据表、字段定义、关系 |
| 接口规范 | API输入输出、错误码、幂等性要求 |
| 验收标准（最重要） | 可测试、无歧义的具体标准 |
验收标准示例：
- ❌ 模糊："用户登录成功后跳转到首页"
- ✅ 清晰："用户登录成功后，3秒内跳转到首页，并在首页显示用户昵称"
专家团模式（Experts Mode）
核心思想：不同任务由不同角色的Agent完成，就像真实开发团队：
前端工程师 ←→ 后端工程师 ←→ 测试工程师 ←→ 架构师
↓ ↓ ↓ ↓
UI实现 API开发 测试用例生成 架构评审
系统内置五类专家，每类有独立工具集，支持自定义专家类型。
用户角色转变：
- 用户不再是单纯的代码编写者
- 成为协调链路的一部分
- 可以随时介入、调整任务方向或取消任务
- 更像"带一个有经验的研发小组"
📊 关键实践原则
范式转移的演进路径
提示词工程 → 上下文工程 → Harness Engineering
↓ ↓ ↓
"怎么跟AI说话" → "AI应该看到什么" → "AI如何在受控环境中运行"
从个人技能到团队级工程能力
| 维度 | "氛围编程" | 规范驱动工程 |
|---|---|---|
| 出码率 | 高但不可控 | 高且可控 |
| 质量保障 | 依赖个人经验 | 基于验收标准自动验证 |
| 团队协作 | 单兵作战 | 专家团协作、人机协同 |
| 知识复用 | 随机、不确定 | 结构化的知识库支持 |
| 适用场景 | 新项目、小脚本 | 存量应用、大型项目 |
开发者的角色进化
从：被动的代码编写者 到：主动的需求定义者、规范审核者、结果验证者
AI的定位：不再是不可控的黑盒，而是在Harness约束下的可靠工具
🔮 未来展望
-
更智能的Spec生成
- 当前还需较多人工干预
- 希望通过更智能的对话式需求澄清，降低人工成本
-
更强大的Agent Teams
- 当前协作模式较简单
- 探索更复杂的协作：多轮迭代、动态角色分配
-
更完善的知识管理
- 知识库是整个体系的基础
- 探索智能的知识提取、更新、复用机制