问题#

AI Coding 存在的三大问题：

• 第一，自由发挥问题。 AI 生成的代码常常天马行空，原因在于业务理解不足、规范缺失。你让它写个功能，它可能给你三种不同的实现方式，每一种都”能跑”，但每一种都可能和你现有的架构格格不入。

• 第二，效率降低问题。 听起来很矛盾——AI 不是应该提效吗？但实际使用中，如果指令不够清晰，你会在多轮对话中反复拉扯。你说”改一下”，它改了；你说”不对，是这样”，它又改了。来回几次，还不如自己写。

• 第三，关键信息丢失问题。 多轮对话中，AI 往往会”忘记”之前的重要约束。任务粒度过大时，开头说的架构要求，到后面就消失了。

SDD（规范驱动开发）#

SDD 的核心思想是颠覆性的：规范不再是写给人类看的散文，而是结构化的、可被 AI Agent 精确理解和执行的”意图代码”。

在传统开发中，PRD 或设计文档只是”指导书”，代码才是唯一的”真理之源”。这导致文档往往很快过期、与代码脱节。SDD 颠覆了这个结构：规范成了唯一的真实来源。当需求变更时，开发者首先修改的是”规范”，随后由 AI 工具根据规范重新生成、验证并更新底层代码。

SDD 的工作流包含四个阶段：

第一，Specify（定义规范）。 开发者与 AI 探讨，输出一份结构化规范，定义好用户故事、验收标准和系统约束。这是”原始需求”阶段。

第二，Plan（制定计划）。 AI 像编译器一样，将规范”编译”成详细的技术方案和任务拆解列表。这是”技术文档”阶段。

第三，Implement（执行落地）。 AI Agent 逐个执行任务列表，自动生成高质量代码。这是”软件开发”阶段。

第四，Validate（验证闭环）。 根据规范自动生成测试用例并执行，确保生成的代码与规范完全契合。这是”功能及代码规范测试”阶段。

Harness（驾驭工程）#

如果说 SDD 解决的是”做什么”的问题，Harness 解决的就是”如何可控地做”的问题。

Harness 这个词很形象。想象一匹野马——AI 大模型拥有无穷的力量，但没有马具，你根本骑不上去，甚至可能被它甩下来。Harness Engineering 的核心，不是去改变马的基因（模型本身），而是为这匹野马设计一套精密的控制系统。

一个成熟的 Harness 系统包含四个核心支柱：

• 第一，上下文工程。 不再是简单的 RAG（检索增强生成），而是结构化的信息投喂。维护一个”单一事实来源”，让 Agent 知道项目的目录结构、当前的执行计划以及哪些文档是最新的。

• 第二，架构约束。 这是 Harness 最硬核的部分。通过物理手段强制 AI 遵守规则。例如，规定 UI 层的代码绝对禁止直接访问数据库层。如果 AI 试图违反架构分层，代码甚至无法通过语法检查，从而在提交前就被拦截。

• 第三，反馈回路与熵管理。 AI 一定会犯错，关键在于如何发现并修正。建立自动化的测试沙箱：Agent 写完代码 → 自动运行测试 → 失败 → 读取错误日志 → 自我修正并重试。更重要的是，将人类修复错误的经验固化为新的规则，确保 AI 永远不会犯同样的错误两次。

• 第四，人类监督。 人类从”写代码的人”变成了”审核员”和”环境设计师”。职责是定义复杂的业务边界，处理那 5% AI 无法判断的模糊逻辑，以及优化 Harness 本身的规则。

从提示词工程到上下文工程，再到 Harness Engineering，这是一个范式转移：从”怎么跟 AI 说话”，到”AI 应该看到什么”，再到”AI 如何在受控环境中运行”。

总结#

基于 SDD 和 Harness 的解法，我们实现了从”氛围编程”到”规范驱动、工程治理”的范式转变。开发者主动去成为需求定义者、规范审核者、结果验证者。AI 不再是不可控的黑盒，而是在 Harness 约束下的可靠工具。