黑箱转向（总序）：当生成速度超过验证速度

Lingming — Sun, 01 Mar 2026 21:22:10 -0500

设想两个团队都在一天内新增五千行代码。第一个团队由工程师逐步编写，第二个团队主要让代码代理生成。第二天发生故障时，两边都不能仅靠“把五千行重新读一遍”解决问题：他们还要理解依赖、配置、数据状态、部署环境和外部服务。区别在于，第二个团队可能还缺少一层东西——为什么生成器选择了这些结构，哪些默认假设从未被写进需求，以及审查能力是否跟得上生成速度。

这正是本系列所谓的“黑箱转向”。它不是一个关于“人写的代码透明、机器写的代码神秘”的简单故事，也不是宣告阅读代码已经无用。更有限、也更可检验的判断是：

生成式 AI 降低了制造实现的成本，却没有按同样比例降低澄清需求、检查行为、整合系统和承担后果的成本。真正扩大的，是生成与验证之间的落差。

软件从来不是完整的白箱

大型软件早已超出单个人的完整理解。操作系统、数据库、浏览器、云平台和开源依赖都通过分工与抽象运行；模块化本来就是让人无需了解全部内部细节，也能依赖一个稳定接口继续工作。AI 没有发明这种局部黑箱。

因此，“白箱时代”最多是一种工程理想：源代码原则上可检查，关键决定可以追溯，局部实现能够被解释。它从来不意味着某个人真的能把整个系统放进头脑，也不意味着可见源码自动带来正确性。

生成式 AI 改变的，是这套理想的成本结构。一个团队可以比过去更快地产生超出其审查容量的改动，也可以在没有形成充分心智模型之前获得一个看似完整的系统。反过来，AI 也可能帮助解释旧代码、补测试、整理文档和缩小理解成本。结果不是单向的技术宿命，而取决于团队怎样使用它。

先区分三种黑箱

“黑箱”如果只表示“不完全理解”，范围会大到失去分析价值。本系列把它拆成三种可以分别治理的问题。

第一种是来源黑箱。代码本身可能清晰，但团队不知道某个实现为什么被生成、依赖了哪些上下文、经过哪些人工判断。这是意图、来源和审查证据的问题。

第二种是系统黑箱。每个组件可能都能阅读，组合后的行为却受依赖版本、网络、配置、并发、数据和外部服务共同影响。这不是 AI 独有的问题，而是复杂软件长期面对的问题。

第三种是行为黑箱。当大模型在运行时参与分类、生成、规划或工具调用，系统行为具有统计性和情境敏感性。此时，仅检查一份静态源代码无法穷尽可能输出，需要专门的评测、权限边界与运行监控。

代码代理在运行时自行修改并执行程序时，三种黑箱可能同时出现。但它们仍不能被混成一个问题：生成普通代码，不会自动让普通程序变成概率程序；模型内部难以解释，也不等于生成出来的源代码无法分析。

控制不等于全知，也不等于只看结果

本系列把工程控制定义为：在说明适用条件和残余不确定性的前提下，拥有足够证据相信系统会保持在可接受边界内，并能在越界时发现、限制和纠正。

这个定义包含三层能力：

控制层	要回答的问题	常见手段
认识控制	我们知道哪些，哪些仍不知道？	设计说明、代码审查、来源记录、依赖清单
行为控制	哪些性质必须成立，证据是什么？	类型、契约、不变量、测试、静态分析、形式验证
运行控制	失败如何被发现、隔离和恢复？	指标、日志、追踪、限权、灰度、降级、回滚

三层不能相互替代。接口契约不能证明需求本身正确；测试通过不能证明输入空间已经穷尽；可观测性也不能弥补无限权限。黑箱工程不是放弃理解，而是把“需要理解到什么程度”和“还需要哪些独立证据”说得更清楚。

八篇文章各自解决什么

篇章	核心问题
第一篇：软件工程从来不是完全的白箱	传统软件如何通过结构化、信息隐藏和协作管理不完全理解？
第二篇：生成—验证落差，真正的拐点	AI 在什么条件下提高产出，又怎样制造审查与整合瓶颈？
第三篇：认知债——团队知道得越来越少吗	怎样区分代码复杂、知识流失和缺少设计理由？
第四篇：控制不可读之物，需要哪些证据	代码审查、测试、契约和形式验证如何形成分层保证？
第五篇：架构即风险几何	架构怎样限制故障半径、权限范围和风险持续时间？
第六篇：从编码者到约束设计者？	工程师的任务组合如何变化，哪些编码能力仍不可替代？
第七篇：AI 生成代码出错，谁负责	作者身份、来源证据、组织问责和法律责任如何区分？
第八篇：三种黑箱，三种控制	面对不同黑箱，怎样选择透明性、约束与恢复机制？

本系列不主张什么

它不主张 AI 已经成为所有团队的主要代码生产者，也不主张软件工程存在一个全球同步的历史拐点。2025 至 2026 年的调查和实验仍呈现混合结果：AI 能提高某些任务的速度，也可能增加返工、评审批量和交付不稳定性；资深开发者、陌生代码库和高责任任务的结果尤其不能从简单基准推断。

它也不主张约束将“取代”实现、观测将“取代”阅读，或者架构师将“取代”程序员。更合理的变化是重心重新分配：当实现更便宜，问题定义、边界设计、验证证据和运行责任会变得相对更稀缺。

黑箱转向真正要求的，不是对不可理解的浪漫化，而是一种更严格的谦逊：知道自己没有验证什么，知道系统可能怎样失败，也知道失败之后由谁采取行动。

延伸阅读与参考资料

下一篇：《黑箱转向（一）：软件工程从来不是完全的白箱》。