从混乱到可控：AI时代代码开发为什么需要Harness

发表于 | 分类于

从混乱到可控：AI时代代码开发为什么需要Harness

AI 编程最容易让人兴奋的地方，是它让代码来得太快。

你说一句“帮我把这个功能补上”，它就开始读文件、改代码、写测试、解释方案。以前一个下午才能推进的事，现在像被压缩进十几分钟。这个变化当然重要。但越用到后面，我越觉得真正的问题不是速度，而是控制。

代码来得太快以后，新的问题会出现：需求还没钉住，代码已经写完；边界还没说清，重构已经发生；测试只跑了成功路径，结论已经写成“完成”；AI 把不确定的猜测补成了流畅的解释，人看着也觉得合理。

这不是 AI 的问题。这是开发过程没有 Harness。

一、混乱不是从写代码开始的

很多人以为，开发混乱来自代码写得不好。

当然，代码会写坏。但更早的混乱，通常发生在代码之前。

一个需求往往是这样开始的：

“这个同步偶尔不对，帮我优化一下。”
“这个页面加载有点慢，修一下。”
“这个导出最近有失败，你看看。”
“让 AI 帮我把测试补齐。”

这些话听起来像任务，其实不是。它们只是问题的影子。

“同步不对”到底是数据丢了、状态没刷新、冲突没合并，还是 UI 没更新？
“加载慢”到底是接口慢、首屏慢、感知慢，还是空态判断错了？
“导出失败”到底是生成失败、上传失败、状态写回失败，还是用户重复点击造成多个任务？
“补测试”到底要覆盖主路径，还是要覆盖缺配置、空数据、异常和超时？

如果这些问题没有被拆开，开发就已经开始漂了。AI 只会让这种漂移跑得更快。

二、Harness 不是测试工具

很多人听到 Harness，会先想到 test harness。这个理解没有错，但太窄。

测试 Harness 是把代码放进一个可控环境里：准备输入，替换依赖，执行动作，观察输出，断言结果。它的核心不是测试两个字，而是可控条件。

我说的代码开发 Harness，是把整个开发过程放进可控条件里。

一个需求从想法到上线，中间会经过很多次转换：

  • 用户说的话，转换成问题定义。
  • 问题定义，转换成需求。
  • 需求，转换成设计。
  • 设计，转换成计划。
  • 计划，转换成代码。
  • 代码，转换成测试证据。
  • 测试证据，转换成验收结论。
  • 验收结论，转换成发布和复盘。

每一次转换都会丢信息，也会混入猜测。开发 Harness 的作用，就是在这些转换点放控制面，让信息不要随便变形。

所以，Harness 不是让开发变慢的流程。它是让开发在速度变快以后，仍然不失控的结构。

三、AI 时代最危险的是“合理的脑补”

AI 的强项和风险，常常是同一件事：它特别擅长补全。

上下文不完整，它会补。目标不清楚，它会补。边界没写，它会补。测试没覆盖，它也会补一段解释，让你觉得问题不大。

人也会脑补，但人脑补得慢。AI 脑补得快，而且语言很顺。顺到什么程度？顺到你会忘记它中间其实没有证据。

比如你说：“旧接口应该没人用了。”

你只是表达一个猜测。AI 可能在后面的设计里写成：“由于旧接口已无人使用，可以删除兼容逻辑。”

注意，中间那个“应该”消失了。一个假设，变成了事实。

开发 Harness 要做的第一件事，就是把 Fact、Assumption、Unknown 分开。

Fact 是有证据的事实。
Assumption 是当前暂时相信、但还没验证的假设。
Unknown 是还不知道的信息。

只要这三类东西混在一起，AI 越努力，风险越大。

四、真正的控制点是这些

一套实用的开发 Harness，至少要控制五件事。

第一，控制方向。

每个任务先判断它是 Expansion、Hold，还是 Reduction。

Expansion 是扩展能力。Hold 是不扩大范围，只修复、硬化、迁移、清理、提效。Reduction 是收缩范围、下线旧能力、降低复杂度。

为什么要先声明这个？因为不同方向的任务，评价标准完全不同。

如果一个任务是 Hold，却做着做着新增了三个用户可见能力，那就是越界。
如果一个任务是 Reduction，却加了一堆兼容层和配置项，那可能是假减法。
如果一个任务是 Expansion，却没有设计错误态、发布和回滚，那就是只扩能力不扩控制。

第二，控制范围。

每个任务都要写 In Scope 和 Out of Scope。

In Scope 说这次做什么。Out of Scope 更重要，它说这次不做什么。

开发失控，很多时候不是因为没人做事，而是因为太多人顺手做了相关但不属于这次的事。

第三，控制事实。

Research 阶段只做研究，不写方案。列出现有代码怎么做、已有测试覆盖什么、日志显示什么、哪些是猜测、还有哪个问题阻断。

这一步像刹车。不是为了停住，而是为了让后面的加速有方向。

第四，控制执行边界。

AI 写代码时，要明确允许改哪些文件、禁止改哪些文件、不能改变哪些契约、发现范围外问题时只记录不修。

不要指望一句“别改太多”能管住 AI。它需要明确边界。

第五，控制证据。

任务结束不能只写“测试通过”。要写清楚：跑了什么命令，验证了什么路径，输入是什么，输出是什么，哪些没测，剩余风险是什么。

没有证据的完成，只是一种情绪。

五、最小可用 Harness

如果任务很小，不一定要写完整文档。但至少可以保留这十行：

1
2
3
4
5
6
7
8
9
10
Mode:
Goal:
In Scope:
Out of Scope:
Facts:
Assumptions:
Unknowns:
Allowed Changes:
Forbidden Changes:
Validation:

这十行并不复杂，但它们分别挡住了不同的失控点。

Mode 挡住方向漂移。
In Scope 和 Out of Scope 挡住范围膨胀。
Facts、Assumptions、Unknowns 挡住脑补。
Allowed Changes 和 Forbidden Changes 挡住无关改动。
Validation 挡住没有证据的完成。

如果这十行写不出来，不要急着改代码。

六、这不是流程崇拜

我并不喜欢为了流程而流程。很多流程确实只是把人拖慢。

但 Harness 不是那种东西。它的价值不在于格式，而在于它能减少返工、误判和救火。

真正拖慢开发的，从来不是几行边界说明，而是这些事：

  • 做完才发现问题定义错了。
  • 测完才发现只测了成功路径。
  • 上线才发现缺配置。
  • 回滚时发现新数据旧代码不认识。
  • 复盘时发现证据散在聊天记录、终端和脑子里。

这些才贵。

Harness 的目标，是让每一次“我以为”，都变成可以检查、验证、回滚和复盘的东西。

七、AI 编程真正严肃的地方

AI 编程刚开始流行时，大家讨论最多的是效率：能不能快十倍，能不能少写代码，能不能一个人做一个团队的事。

这些都重要。但真正严肃的地方，是当代码生产能力变得很便宜以后，确定性变得更贵了。

你不再缺生成代码的能力。你缺的是判断这段代码该不该生成、生成到哪里停、怎么知道它对、出事怎么退、下次怎么不再犯同样的错。

换句话说，未来工程师越来越像在设计一个代码生产系统。

代码只是结果。Harness 才是让结果可靠地产生的那套控制面。

如果要用一句话总结：

AI 让开发跑得更快，Harness 让开发还能跑在路上。