银河it-SDD规范驱动+Harness驾驭工程AI全栈开发 - 实战课程- 慕课网

从“抽卡”到“契约”：SDD与Harness如何重构AI全栈开发的工程秩序
核心结论：AI编程的核心矛盾已经从“模型能不能生成代码”转向“生成的代码能不能被信任”。SDD规范驱动与Harness驾驭工程的组合，本质上是在用确定性工程约束来对冲大模型的概率性输出。这不是提示词技巧的升级，而是开发范式的结构性迁移——将“对齐”从代码层上移到规范层，将“验证”从人工Review下放到环境层。

Vibe Coding的工程困境：高产出与低采纳的悖论
Vibe Coding的兴起让原型开发速度大幅提升，但当项目规模膨胀时，问题集中爆发。Stack Overflow数据显示，67%的开发者表示AI代码需要大量人工修改。企业实践中，Vibe Coding项目的维护成本达到传统项目的2.3倍。得物技术团队的分析精准地描述了这个问题：AI生成的代码往往是“外星代码”——风格不一致、复用率低、采纳率低。结果是“AI生成了代码，但Review成本和返工成本反而更高了”。

这组数据指向一个工程事实：AI生成代码的瓶颈不在“能不能跑”，而在“能不能被团队接受”。

Harness Engineering：给AI搭一个“不翻车的工作环境”
Harness Engineering在2026年2月由HashiCorp创始人Mitchell Hashimoto正式命名，其原始定义极为精炼：“每当你发现agent犯了错，你就花时间工程出一个解，让它再也不可能犯这个错。”

OpenAI的内部实践为这个定义提供了最具冲击力的注脚：一个3-7人的团队在5个月内用Codex Agent生成了约100万行代码、合并了约1500个PR，零行手写源代码。负责该项目的工程师Ryan Lopopolo的总结在技术圈广为流传：“Agents aren’t hard; the Harness is hard.”（Agent不难，难的是Harness。）

Harness的核心方法论可以浓缩为两条法则。强约束——能用确定性约束（lint、type、sandbox、CI硬失败）的地方，永远不要用提示词。自愈循环——agent必须能从环境里拿到“地面真相”，能自我评估、自我修正。Anthropic的实证发现进一步印证了这一点：“能不能用coding agent真正解决问题，强相关于这个agent能不能验证自己的工作。”

SDD：反转代码与规范的权力关系
如果Harness解决的是“环境应该怎么搭”，SDD（Specification-Driven Development）解决的是“代码应该从哪里来”。

GitHub提出的SDD定义是：Spec是一份代码行为准则的契约，成为工具和AI代理的代码生成、测试和验证所依赖的单一事实来源。 民生银行科技团队在实践中将这一范式进一步具体化：SDD模式下的规格是“具有明确性、可被验证、可演进、AI可读的面向开发流程的技术性描述，也是人类与AI之间的共同技术契约语言”。

这个范式转变的工程意义在于消除了“规范与实现之间的差距”。传统方法试图通过更好的文档来缩小这个差距，但接受差距是不可避免的。SDD通过使规范可执行来消除差距：当规范和实现计划用于生成代码时，不存在差距，只有转化。

一篇arXiv学术论文进一步区分了两种Harness的耐久性差异：技术Harness（编排循环、工具、上下文管理、护栏）是短暂的，会随着模型能力提升而贬值；而方法论Harness（以规范为核心的团队实践）编码的是团队的意图、规范和积累的决策，因此会随时间增值。团队的投入优先级应该倾斜于后者。

工程判断力的边界
课程标注“初阶”难度，技术储备要求“掌握任意一门编程语言即可”。但SDD和Harness的核心门槛不在语法，而在工程判断力：知道规范应该写到什么粒度才既能约束AI又不阻碍探索，知道规则应该覆盖哪些维度、以什么顺序加载、在什么条件下回退。

课程标注了起点——帮助有编程基础的开发者理解“AI工程化”的目标形态是什么样子。但在地图上从一个坐标走到另一个坐标的路径——那种在AI输出看起来正确时仍然追问“为什么正确、在什么条件下会失效”的判断力——需要在真实项目的失效与修复中亲自走一遍。

本作品采用《CC 协议》，转载必须注明作者和本文链接