从“氛围编程”到“规范可控”：SDD + Harness 驱动工程 AI 全栈开发的技术范式演进

引言：AI 编程的“半程红利”困局

2026 年，AI 编程工具的代码生成能力已跨过实用门槛。以高德大模型应用平台的实践数据为例，出码率已从 53% 提升至 80%-90%——这一数据看起来接近“自动化”的理想状态。

但一个反直觉的困局随之浮现：项目交付周期并未等比例缩短。编码快了，但 Code Review 慢了；出码多了，但返工也多了。这揭示了一个被低估的真相：出码率不等于交付率，编码环节仅占研发全链路的 20%-30%，即使编码效率翻倍，整体提效也有限。

更深层的问题在于，AI 生成的代码往往缺乏对存量应用隐性依赖、历史架构决策的认知，甚至可能因“过早宣布胜利”或“上下文污染”而导致上线故障。行业共识正在形成：AI 编程必须从“个人技能”升级为“团队级工程能力”，从“氛围编程”（Vibe Coding）进化为“规范驱动、工程治理”的研发范式。

SDD（规范驱动开发）与 Harness Engineering 的组合，正是这一演进路径的核心技术框架。

一、SDD：规范即代码，重构“事实来源”

1.1 传统开发 vs. SDD：权力结构的反转

在传统开发中，代码是唯一的“事实来源”，PRD 和设计文档服务于代码，往往在上线前就已过期。SDD 颠覆了这一结构：规范成为主要工件，代码服务于规范。

这一范式转移的核心价值在于：当需求变更时，开发者不再需要逐行修改代码，而是修改“规范”，随后由 AI 工具根据规范重新生成、验证并更新底层代码。维护软件意味着演进规范，而不仅仅是修补代码。

1.2 SDD 的四阶段工作流

Microsoft Learn 与 GitHub Spec Kit 将 SDD 实践归纳为四个递进阶段：

1. Specify（定义规范）：定义软件“做什么”及“为什么”——用户故事、验收标准（必须是可测试、无歧义的，如“3 秒内跳转并显示昵称”）、边界条件。
2. Plan（制定计划）：决定“如何构建”——架构、技术栈、实现方法。
3. Task（拆解任务）：将计划分解为离散、可执行的开发任务，按阶段组织。
4. Implement（执行实现）：AI 在规范、计划、任务清单的指导下编写代码，每个任务依据规范验证。

验收标准是 SDD 的“灵魂”。只有当规范精确到足以生成工作系统时，“意图与实现之间的鸿沟”才能被消除。

1.3 为什么企业级开发必须引入 SDD

微软官方文档指出，三种趋势使 SDD 对企业团队至关重要：

• AI 能力突破：自然语言规范已能可靠生成代码，自动化了“规范→实现”的机械翻译。
• 软件复杂性爆炸：现代系统集成数十种服务，SDD 通过规范驱动生成实现系统性对齐。
• 变更速度加快：SDD 将需求变更从“阻碍”转化为“正常工作流”——更新规范，受影响工件被系统化重新生成，而非手动重写。

在“棕地”（Brownfield）场景（存量应用）中，SDD 要求通过“宪法”记录现有架构模式和约束，新功能规范需确认现有基础设施和集成点。如果某条架构约定不在代码库中以机器可读的形式存在，对 AI Agent 来说它就不存在。

二、Harness Engineering：为 AI 设计“缰绳”与“反馈系统”

2.1 Harness 的本质：让 AI 不再犯同样的错

Mitchell Hashimoto（HashiCorp 联合创始人）对 Harness Engineering 的定义极为精炼：“每当你发现 AI Agent 犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错。”

OpenAI 工程团队的实践进一步扩展了这一概念：在 5 个月内，约 100 万行代码、1500 个 PR 全部由 Agent 生成，但人类工程师的工作转移到了定义产品规格、设计约束、搭建反馈系统等“支撑结构”上。

2.2 Harness 的四个核心支柱

结合高德与得物技术的落地实践，一套成熟的 Harness 体系包含四个关键模块：

支柱一：结构化上下文与“地图式”索引 Agent 在运行时无法访问存储在 Google Docs、聊天记录或人脑中的知识。Harness 要求在代码库内建立结构化的 docs/、product-specs/、design-docs/ 目录。关键在于提供“地图”而非“百科全书”——通过一个精简的顶层索引（如 AGENTS.md 控制在 ~100 行），让 Agent 按需渐进式披露深层信息，避免上下文过载。

支柱二：Agent 专业化与架构约束 赋予所有权限的通用 Agent 更易出错。实践建议分离 Planner、Generator、Evaluator 角色。得物技术的 Harness 实践更具体：让 AI“模仿”而非“凭空创造”——在提示词中显式指定参考文件、复用数据结构、模仿分层方式（Controller/Service/Repository），将 AI 的创作空间约束在已有的工程范式内。

支柱三：结构化执行与“反向验证” 不让 Agent 在未经批准的计划前写代码。理想执行流为：理解 → 规划 → 执行 → 验证。在验证环节，通过自定义 Linter、结构测试强制执行架构规则（如“UI 层禁止直接访问数据库层”）。同时，建立反馈回路：Agent 写完代码→自动运行测试→失败→读取错误日志→自我修正并重试；人类修复的经验固化为新规则，防止再