📌 引言：我们是不是把 AI 编程玩走偏了？
最近，“软件开发范式转型”成了技术圈最热的话题。很多研发团队开始大张旗鼓地推行所谓的 SDD（Specification-Driven Development，规范/文档驱动开发）。它的核心逻辑听上去很美：产品经理或架构师把需求写成极致详细的结构化文档（PRD/Spec），直接喂给 AI，AI 自动化产出全套业务代码。
但实际落地后，一线的骨干工程师很快发现自己陷入了深渊：
“这不就是变相的形式主义吗？” “代码迭代这么快，文档刚写完就过时了。”
随着业务的频繁迭代，人类修改了代码，就不得不去补文档；或者修改了需求，得小心翼翼地喂给 AI，还要时刻提防 AI 产生幻觉把人类之前的优化逻辑一把覆盖掉。人类从过去的“代码打字员”，沦为了低效的“文档搬运工兼肉眼校对员”。既要维护代码，又要维护文档，这种高昂的双向同步成本（Synchronization Overhead），完全违背了 AI 提升效率的初衷。
其实，我们一直坚持的“代码即文档”并没有过时，SDD（文档 -> 代码）只是 AI 模型推理能力不成熟时的过渡期产物。技术演进的最新终极形态，是 Mitchell Hashimoto、Andrej Karpathy 以及 OpenAI 技术团队彻底推红的全新范式——Harness Engineering（马具工程 / 基座工程）。
一、 传统 SDD 的死穴：为什么“直接喂 PRD”往往是大坑？
把大段面向人类的自然语言 PRD 直接丢给 AI，指望它吐出生产环境可用的代码，必然会遭遇以下三大致命冲突：
1. 信息密度的错配（自然语言的模糊性 vs 代码的绝对精确）
自然语言允许模糊和业务妥协（例如：“网络不好时提示一下”）。但代码和编译器要求绝对的精确：什么是网络不好？超时 5000ms 还是断网 404？提示是用 Toast、Dialog 还是 Snackbar？当 PRD 缺失这些细节时，AI 只能靠幻觉去猜业务边界，猜错的代价极大。
2. 系统上下文的断层
传统的 PRD 往往只写“新需求是什么”，却丢失了系统现有的老代码和架构包袱。它不知道现有的 SDK 封装了哪些通用组件、目前路由框架用的是哪一套、之前的全局异常是怎么捕获的。AI 只能闭门造车，写出与老系统严重割裂的“屎山代码”。
3. 缺乏自我验证机制
代码写错了，编译器和 CI 会报错，测试会挂掉；但文档写错了、需求与代码脱节了，没有任何原生机制能进行“自动编译和运行时校对”。为了让两边对齐，团队只能投入海量的人力去肉眼 review 需求与代码的差异。
【走偏的路径：过渡期 SDD 模式】 [人类写 10 页 PRD] ──> 喂给 AI ──> AI 盲人摸象 ──> 产出割裂代码 ──> 人类痛苦重构与人工肉眼对齐（地狱循环）
【正确的路径：前沿 Harness 模式】 [简短意图/数据骨架] ──> 结合现有[代码/环境上下文] ──> AI 结合 Harness 自主试错、编译、跑测试 ──> 100% 精准交付
二、 什么是 Harness 编程范式？（马与马具的比喻）
在技术界，Harness 的字面意思是“马具”或“缰绳”。
- AI 模型是那匹“野马”：它拥有无穷的蛮力和惊人的编码速度。但如果你放任它去读大白话文档、随意修改全库，它就会脱缰，带来巨大的破坏性（引入隐蔽 Bug、破坏架构一致性）。
- Harness 是你为 AI 打造的“缰绳与沙盒”：它不是写给人类看的 Word 文档，而是由“边界规则、自动化传感器、确定性的运行反馈环”共同构成的硬核约束系统。
在 Harness 范式下，我们不再向 AI 提供长篇大论的“说明书”，而是提供一个无法逾越的规则边界。代码与协议本身就是唯一的真理源（Single Source of Truth）。
三、 Harness 驱动开发（HDD）的核心三要素
真正高效的 AI 协作，不再依靠人类去写长篇大论的需求，而是由人类为 AI 打造一个完全闭环的 Harness：
1. 约束而非描述（Constraint Harness）
与其写 10 页纸的需求描述，不如在项目根目录下维护一份极其精简、硬核的约束文件（如 .cursorrules 或 CLAUDE.md）。它只声明底线：
- 我们的技术栈是 ArkTS / TypeScript。
- 禁止直接修改
src/core目录。 - 所有的网络请求必须走统一封装的拦截器。
这不是文档，这是给 AI 设立的驾驶边界和避坑指南。
2. 自动化反馈环（Sensors & Feedback Loops）
当 AI 接收到人类简短的意图描述后，Harness 会在后台死死盯着它。AI 每修改完一个文件，Harness 自动在后台静默运行编译器、Linter（语法检查）和测试集（Unit Tests）。 如果编译报错或测试未通过，Harness 会直接把报错日志摔在 AI 脸上：“第 42 行类型不匹配，请结合上下文重写！”。AI 在这个确定性的“沙盒”里自己跟编译器去死磕，直到所有测试亮起绿灯。全过程人类不需要做任何肉眼校对。
3. 把需求转化为“测试断言”（Executable Specification）
最完美的“需求文档”，永远不是 .docx 或 .pdf 文件，而是 test.ts 或自动化集成测试用例。
人类和 AI 协作的第一步，不是写业务代码，而是先把业务需求变成测试代码：
“用户点击保存按钮，数据库应该多一条记录” -> 在 Harness 里就是一段
assert(db.count() == before + 1)。
只要测试断言写得对，AI 就会在 Harness 的鞭策下自动试错、全库搜索、补全业务逻辑，直至跑通测试。此时，测试用例就是永远不会过时、100% 精准的需求文档。
四、 程序员的思维跃迁：从编写代码到设计环境
OpenAI 团队曾做过一个著名的实验：3 个工程师在几个月内不人工编写任何一行代码，完全通过 Harness 引导 AI 智能体去自主调试、重构和编译验证，最终高效搞定了一个拥有超百万行代码的生产级复杂系统。
这标志着软件工程研发模式的彻底改变：
| 维度 | 传统 PDD / 过渡期 SDD | 前沿 Harness 范式 (HDD) |
|---|---|---|
| 人类的核心工作 | 苦思冥想写代码 / 苦哈哈写文档、喂 AI | 设计开发环境、定义边界规则、编写测试断言 |
| 真理源 (Source of Truth) | 需求文档与代码双重维护（极易脱节） | 代码、协议与测试用例本身，文档由 AI 随用随生 |
| 纠错与验证机制 | 人类看日志改代码，或肉眼校对 AI 的产出 | Harness 捕获编译器/测试报错，AI 自主闭门 Debug |
| 研发效率 | 线性提升，被“同步成本”严重拖累 | 指数级提升，AI 在沙盒中并发执行 |
💡 结语：让文档回归“代码的即时投影”
“代码即文档”在 AI Agent 时代有了全新的生命力。既然大模型可以在几秒钟内读懂整个工程的 AST（抽象语法树），那么文档就不应该由人类来手动维护，而应该由 AI 随用随生。
当新员工入职或者需要向业务方汇报时，直接让 AI 扫描现有的代码库和协议骨架，实时生成一份最新、最准确的架构图和说明文档即可。看完，即可销毁，它根本不需要长期维护。
人类不当打字员，也不当文档搬运工。在 AI 编程的终极范式里，我们的角色是“马车夫”——配置好 Harness 的缰绳，写好测试用例的终点线，剩下的全库重构和代码编写，放手让 AI 在沙盒里自己跑通！
