夜雨聆风AI 编程正在制造一场新的软件危机
而且这次，工具越多，问题越大。
事情正在以肉眼可见的速度变糟。
一个朋友最近告诉我，他们团队用 Cursor 写了一整个微服务，三周上线。听起来很棒。直到他发现团队里没有一个人能说清楚这个服务的错误处理逻辑——因为那部分代码是 AI 生成的，review 的时候没人仔细看，测试过了就当过了。
这不是孤例。过去半年，我看到的 AI 辅助项目里，至少一半出现了同样的模式：代码量暴涨，理解率暴跌。 PR review 从"这段逻辑有问题"变成了"看起来能跑，合了吧"。
这不是效率提升。这是技术债务的工业化生产。
软件工程正在经历第三次危机。前面两次我们都扛过来了——靠的不是更聪明的工具，而是对人如何协作、如何做决策的重新理解。这一次，答案大概也一样。
三次危机
第一次：1968 年
NATO 在德国开了一场会，把一群计算机科学家凑到一起。议题叫"软件工程"——当时还没人用这个词。会上的共识令人不安：几乎所有大型软件项目都在同时崩溃。延期、超支、缺陷满天飞。这不是某个团队的问题，是整个行业的方法论失效了。
Dijkstra 从会上回来，几乎是抑郁的。但他做了件关键的事——他开始追问为什么。他的结论是：程序员有太多自由。 goto 语句让你可以在代码里任意跳转，结果就是谁也看不懂谁的代码。
他的方案是结构化编程：用 if-then-else、while、for 替换 goto。翻译成白话：给程序员套上缰绳，不让乱跑。 这招管用了。
第二次：1990s-2000s
严格说不算一个明确的时间点，更像是累积效应。瀑布模型在需求明确的时候还行，但大多数软件的需求根本不明确。写 200 页的需求文档，三个月后发现用户想要的是另一个东西。Agile 的回应是：别假装你能预测未来，小步快跑，持续交付，频繁反馈。
这次危机的解决方式也不是工具，而是协作模式的改变——站会、迭代、retro，这些都是关于人怎么一起工作。
第三次：现在
AI 可以写代码了。不是写 demo，是写能上生产的代码。一个下午的工作量，Cursor 十分钟搞定。问题是：写出来的代码，谁来理解？谁来维护？谁为它负责？
1968 年的危机是"人写不出足够好的软件"。2026 年的危机是"AI 写出了人看不懂的软件"。
讽刺的是，我们花了 50 年解决第一个问题，然后制造了一个更麻烦的版本。
这三次有什么不同
三次危机的共同点是同一个：复杂度超出了人的掌控能力。
不同的是失控的方式。
1968 年：程序员控制不了自己写的代码。代码规模一大，goto 满天飞，逻辑纠缠成一团。解决方案是约束——限制程序员的自由度。
2000 年代：团队控制不了变化的节奏。需求在变，技术在变，团队规模在变。解决方案是协作——用迭代替代预测，用反馈替代计划。
2026 年：人类控制不了 AI 写的代码。不是因为它写得不好——恰恰相反，它经常写得很好。问题是你不知道它什么时候会写错，以及写错了你能不能发现。
更致命的是，AI 让"一个人搞定一切"变得可能了。CS146S 那门课的口号就是整个学期不准手写一行代码。"超级个体"的概念是：一个人就是一支军队。
但这里有一个 Brooks 在 1975 年就指出过的问题：沟通成本随人数指数增长。 当你的"团队"从 5 个人变成 1 个人 + 5 个 AI Agent 时，沟通成本并没有消失——它转移了。你需要和每个 Agent 对齐上下文、纠正偏差、处理冲突。
Mitchell Hashimoto 说得更直白："每当你发现 Agent 犯错，就加一条规则，让它永远不会再犯同样的错。" 这就是沟通成本，只不过付给的不再是同事，而是配置文件。
更坏的消息是：当只有你一个人理解这个系统时，你就是唯一的 bus factor。
Harness Engineering 在解决什么
花叔的《Harness Engineering 橙皮书》是到现在为止我看到对这个问题最系统的回应。
框架本身不复杂，五根缰绳：
指令层：告诉 AI 你要什么，边界在哪。
约束层：告诉 AI 什么绝对不能做——用 hooks 拦截，不是写在 prompt 里祈祷。
反馈层：让 AI 在犯错的第一时间知道自己错了。
记忆层：别每次都从零开始，把踩过的坑固化成规则。
编排层：多 Agent 协同时的任务分配和等待。
核心设计哲学就一句话，Martin Fowler 说的：AI 的自主性越高，解空间就必须越小。 这不是在限制 AI。是在保护项目。
约束层是整个框架的灵魂。指令层写"请不要 push 到 main"是建议，约束层用 PreToolUse hook 拦截 git push main 是铁律。建议可以被忽略，铁律不能。
Mitchell 的做法更朴素——每发现 Agent 犯一次错，就在 AGENTS.md 里加一条规则。几周下来，这个文件就成了 Agent 的行为边界。
五个领域的 Harness 形态
马术：缰绳 → 物理约束，防止力量失控航天：NASA 线束规范 → 信号路径，防止电子干扰软件测试：Test harness → 隔离环境 + mock，控制变量安全：安全带 → 失败时兜底保护AI Agent：Hooks + 规则 + 评估器 → 程序级拦截，确定性硬约束
五个领域，做的是同一件事：用约束把不可靠的组件变得可靠。
有没有用？有用。足以解决第三次危机吗？不够。
Brooks 从来没有过时
1986 年，Brooks 发表《没有银弹》。核心论点：
Essence（本质困难）：概念结构的设计——数据怎么组织，接口怎么定义，系统怎么分层。这些东西天生复杂，和用什么工具没关系。Accident（次要困难）：怎么把设计表达成代码，怎么在硬件限制下跑起来。这些东西，工具可以帮你。
Brooks 的结论是：除非次要困难占了全部工作的 9/10，否则你把次要困难降到零，生产率也不会有数量级的提升。
40 年过去，这个结论依然成立。
Harness Engineering 解决的是什么？是 Accident。 它让 AI 不那么容易跑偏，让 Agent 的协作不那么混乱，让上下文管理不再失控。这些都是次要困难。
它没有帮你决定：这个系统应该拆成几个模块？数据库选 Postgres 还是 Mongo？用户故事该不该拆成两个 epic？
这些决策需要的东西，AI 没有，Harness 也提供不了：判断力。 对业务的理解。对 tradeoff 的感觉。对"什么情况下可以违反规则"的直觉。
Brooks 当年给出的不是悲观的结论，是清醒的提醒。Harness Engineering 最好也当成同样的东西来看：一个管用的约束系统，不是终极答案。
软件工程终究是人的事
Brooks 在《人月神话》里还说过一件事，比"没有银弹"更根本：
向一个已经延误的项目添加人手，只会让它更延误。
这是反常识的。因为新加入的人需要沟通、学习、对齐，这些开销会吃掉他带来的所有生产力增量。
这就是为什么"超级个体"的概念有一个致命漏洞：你以为你取代了团队，实际上你只是把团队换成了 AI Agent。Agent 一样需要对齐、纠偏、手把手教——Mitchell 的 AGENTS.md 就是证据。你的沟通对象变了，沟通的工作量没变。
Brooks 提出的解决方案是外科手术团队：一个主刀医生理解整个系统，其他人——副手、麻醉师、护士——各司其职，支撑主刀医生。不是民主决策，是专家决策 + 专业支撑。
放到今天来看，这个模型比"超级个体"更靠谱。不是一个人 + 一堆 AI Agent，而是一个人做决策 + 一群人做支撑 + AI 做执行。
你可以把外科手术团队套到 AI 时代：主刀医生做决策，AI 做执行，其他人做支撑。关键是决策权不能交给 AI——不是因为 AI 不够聪明，是因为AI 不为后果负责。 它不会在凌晨三点被报警叫醒，不会在事后复盘时脸红，不会有"当初如果选了另一种方案就好了"的遗憾。
人类不可替代的价值不在于执行，在于判断。在于你能为你的决策承担后果。
结语
1968 年，Dijkstra 用"不准用 goto"来约束程序员的无序。
1986 年，Brooks 说别幻想银弹，复杂度是软件的本质。
2026 年，Harness Engineering 用五根缰绳来约束 AI 的无序。
每一条约束都是必要的。但它们都只是约束。它们能让事情不失控，不能让事情变好。
让事情变好的，从来都是人——知道什么时候该打破规则的人，知道 tradeoff 在哪里的人，愿意为自己的决策负责的人。
AI 可以写代码。但软件工程，从来不只是写代码。
参考：花叔《Harness Engineering 橙皮书》、Fred Brooks《人月神话》、Mitchell Hashimoto "My AI Journey"
— END —
