---
title: "黑箱转向（总序）：当生成速度超过验证速度"
url: https://lingming.blog/posts/2026/the-manifesto-for-software-engineering-after-human-comprehension/
date: 2026-03-01
lastmod: 2026-07-28
tags: ["软件工程","生成式 AI","代码生成","软件验证","工程治理"]
categories: ["软件工程","人工智能"]
description: "AI 生成代码真正改变了什么？本文区分三种软件黑箱，提出“生成—验证落差”这一有限命题，并给出黑箱转向系列的完整路线图。"
---

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


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

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

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

## 软件从来不是完整的白箱

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

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

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

## 先区分三种黑箱

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

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

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

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

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

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

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

这个定义包含三层能力：

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

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

## 八篇文章各自解决什么

| 篇章 | 核心问题 |
| --- | --- |
| [第一篇：软件工程从来不是完全的白箱]({{< relref "/posts/2026/the-white-box-assumption.md" >}}) | 传统软件如何通过结构化、信息隐藏和协作管理不完全理解？ |
| [第二篇：生成—验证落差，真正的拐点]({{< relref "/posts/2026/the-generative-inflection-point.md" >}}) | AI 在什么条件下提高产出，又怎样制造审查与整合瓶颈？ |
| [第三篇：认知债——团队知道得越来越少吗]({{< relref "/posts/2026/the-collapse-of-linearity.md" >}}) | 怎样区分代码复杂、知识流失和缺少设计理由？ |
| [第四篇：控制不可读之物，需要哪些证据]({{< relref "/posts/2026/controlling-the-unreadable.md" >}}) | 代码审查、测试、契约和形式验证如何形成分层保证？ |
| [第五篇：架构即风险几何]({{< relref "/posts/2026/architecture-as-risk-geometry.md" >}}) | 架构怎样限制故障半径、权限范围和风险持续时间？ |
| [第六篇：从编码者到约束设计者？]({{< relref "/posts/2026/the-new-engineer-from-coder-to-constraint-designer.md" >}}) | 工程师的任务组合如何变化，哪些编码能力仍不可替代？ |
| [第七篇：AI 生成代码出错，谁负责]({{< relref "/posts/2026/the-ethics-of-the-black-box.md" >}}) | 作者身份、来源证据、组织问责和法律责任如何区分？ |
| [第八篇：三种黑箱，三种控制]({{< relref "/posts/2026/redefining-control-in-the-age-of-generative-systems.md" >}}) | 面对不同黑箱，怎样选择透明性、约束与恢复机制？ |

## 本系列不主张什么

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

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

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

## 延伸阅读与参考资料

- [D. L. Parnas：On the Criteria To Be Used in Decomposing Systems into Modules](https://doi.org/10.1145/361598.361623)
- [DORA：State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/)
- [METR：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
- [Stack Overflow：2025 Developer Survey — AI](https://survey.stackoverflow.co/2025/ai/)
- [NIST：Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)

*下一篇：[《黑箱转向（一）：软件工程从来不是完全的白箱》]({{< relref "/posts/2026/the-white-box-assumption.md" >}})。*