这个系列从一句有冲击力的判断开始：当代码生产超过人类理解，控制必须从实现转向约束。
经过八篇讨论，这句话需要被改得更精确。软件从来没有完全透明，约束也从来没有脱离实现。AI 真正加剧的是生成、验证与组织理解之间的不对称。应对它的办法不是宣布“透明性终结”，而是判断：面对哪一种未知，我们还需要理解什么，又需要哪些独立证据和恢复能力？
本篇不再重复一次未来宣言，而把全系列压缩成一个可操作的矩阵。
三种黑箱
来源黑箱：不知道为什么这样生成
最终代码可能清晰可读，团队却不知道它依赖了哪些上下文、为何选择这种结构、哪些假设没有进入仓库。来源黑箱影响的是意图、追溯和审查质量。
它主要出现在开发阶段，但不是 AI 独有。复制旧代码、使用外包制品或继承缺少记录的遗留系统也会产生相同问题。AI 让这类变化更容易快速、大批量出现。
系统黑箱：局部清楚，组合行为不清楚
源码、模块和配置都能访问，系统行为却由依赖、网络、数据、并发、部署环境和第三方服务共同形成。大型分布式系统长期处在这种状态。
系统黑箱的难点不是找不到任何代码，而是没有一个视角能穷尽所有交互。理解必须借助接口、架构图、实验、遥测和事故经验分布在组织中。
行为黑箱：运行结果具有统计性或适应性
当大模型直接参与生成、分类、规划或工具调用，同一输入可能因上下文、采样、模型版本和外部数据产生不同结果。此时静态源码无法完全规定产品输出。
行为黑箱需要评测分布、置信与失败类别、权限边界和持续监控。它不应被倒推到所有 AI 生成代码：模型写出的普通排序函数，仍然可以是一个确定性程序。
运行时代码代理可能同时具备三种黑箱：生成理由难追溯，工具与依赖形成复杂系统，决策又具有统计性。组合风险更高，但分析仍要逐层进行。
三层控制
认识控制：知道知识和未知在哪里
认识控制不要求一个人理解全部系统，而要求关键知识有明确归属，重要决定可以追溯，团队知道哪些组件只依赖契约、哪些区域必须深入审查。
常见资产包括设计说明、架构决策记录、代码审查、来源证明、依赖清单和责任地图。它们提供解释与调查基础，却不能单独保证系统行为正确。
行为控制：用证据限制允许发生的事
行为控制把目标和禁区转成接口、类型、不变量、权限政策、测试、静态分析和形式证明。对运行时模型，还包括离线评测、对抗测试、工具策略和输出验证。
它的边界是规格问题：没有写出的风险不会自动被证明，错误约束也可能被完美执行。因此证据必须标明主张、适用条件和残余不确定性。
运行控制：发现、限制和纠正真实失败
运行控制假定生产环境会出现模型外事实。它通过监控、审计、限流、隔离、灰度、熔断、降级、补偿和事故响应缩短影响。
运行控制也不能替代前两层。无限权限的系统即使监控完善，也可能在告警抵达前造成不可逆损害；没有设计理由的系统即使成功回滚，也可能反复制造同类事故。
把三种黑箱与三层控制放在一起
| 对象 | 认识控制 | 行为控制 | 运行控制 |
|---|---|---|---|
| 来源黑箱 | 记录模型、输入版本、设计取舍与批准者 | 小批生成、独立审查、构建与测试门槛 | 将具体部署绑定到可核验制品和审批 |
| 系统黑箱 | 接口所有权、依赖图、关键数据流、责任地图 | 契约、不变量、隔离、兼容性与故障测试 | 可观测性、容量保护、灰度、降级与恢复 |
| 行为黑箱 | 说明模型能力、数据、已知限制与适用范围 | 代表性评测、对抗测试、权限与工具约束 | 漂移监测、抽样审计、停止条件与人类升级 |
矩阵中的九格不是必须全部堆满的合规清单。它的作用是暴露空白：若团队只说“我们有测试”，可以继续追问测试针对哪种黑箱、支持哪一层控制，以及真实运行失败时谁行动。
控制强度应当跟随后果，而不是跟随潮流
一个生成内部报表脚本的助手，与一个可以批准贷款、调整药物剂量或修改生产防火墙的代理，不应使用同一控制标准。
可以沿四个问题确定强度：
- 后果是否可逆？ 错误文案可以编辑，资金转出和隐私泄漏难以撤回。
- 影响范围多大？ 单个开发环境与全体生产租户不同。
- 系统自主性多高？ 提出建议、创建草稿、执行操作和自我扩展权限是不同等级。
- 失败能否及时观察？ 明确报错比悄悄改变排序、歧视某类用户或积累财务偏差更容易控制。
低风险任务可以依赖抽样审查和普通测试。高风险、广影响、难逆转又难观察的系统，则需要更强规格、独立验证、细粒度权限、人类批准和事故演练。
三个案例
AI 生成一个纯函数
主要风险是来源和实现质量。保留小 diff，检查算法与边界，用性质测试和静态分析验证即可。研究基础模型内部特征通常不是必要控制。
AI 修改一个分布式结算服务
来源、系统两种黑箱同时重要。除了代码证据，还要检查数据迁移、幂等、依赖失败、权限、灰度范围和补偿路径。控制重点是跨模块不变量与故障半径。
代理在生产中自动处理退款
三种黑箱同时存在。模型判断具有统计性，工具调用具有外部副作用，还可能读取敏感数据。除了离线评测和制品审计，还要设置金额上限、身份验证、速率限制、异常升级、人类复核和即时停用能力。
案例说明，“AI 系统需要概率控制”只对行为本身具有概率性的场景成立。开发阶段用了生成工具，不足以把整个软件从确定性工程改写为统计工程。
透明性不是越多越好，而要分配到关键位置
完全开放所有内部细节会制造信息过载，也可能泄漏安全和隐私信息。完全依赖外部行为又会让调试、审计和知识积累困难。
成熟设计应当分配透明性：
- 高后果规则和权限策略要清楚、可检查；
- 复杂组件可以隐藏实现，但必须给出稳定契约和失败方式；
- 生成过程保存足够来源证据，不必永久保存全部敏感上下文；
- 运行模型说明适用范围和已知限制，不用虚假的自然语言解释掩盖不确定性；
- 事故调查能够从用户影响追到版本、配置、制品和责任角色。
真正要反对的不是黑箱，而是没有选择依据的黑箱：团队不知道自己隐藏了什么，也不知道用什么证据弥补。
控制的有限定义
本系列最终采用的定义是：
工程控制，是在明确适用条件和残余不确定性的前提下，拥有与风险相称的理由相信系统会保持在可接受边界内，并能在越界时及时发现、限制和纠正。
这个定义不承诺绝对安全，也不把一切降为概率。确定性协议可以保留确定性性质，统计模型则需要分布性证据；两者都必须面对规格遗漏、环境变化和组织执行问题。
它也没有把理解排除在控制之外。理解帮助我们提出正确性质、解释反例和修复未知故障；约束帮助我们在无法理解全部细节时限制风险；运行反馈帮助我们发现此前理解和规格都没有覆盖的现实。
八篇文章留下的八个判断
- 软件工程从来依靠分层理解，而不是单个心智掌握一切。
- AI 的关键压力是生成—验证落差，不是代码行数本身。
- 认知债是安全修改所需知识与团队可调用知识之间的缺口。
- 控制需要多层独立证据，没有单一指标可以取代其余方法。
- 架构通过故障半径、权限、时间和相关性塑造风险。
- 约束设计是一种增强的工程能力，不是脱离实现的职业特权。
- 来源可以分布，责任仍必须落在能够行动的人与组织上。
- 不同黑箱需要不同控制；“AI”不是统一风险类别。
结语：从全面理解，走向有边界的可信
AI 不会让工程从理性走向神秘，也不会自动把复杂性提升为更高级秩序。它只让我们更难继续假装：实现出现了，理解、验证和责任就会自然跟上。
黑箱转向最值得保留的，不是“透明性已经死亡”这句宣言，而是一条更朴素的纪律：实现越容易生成，越要说明什么不能交给生成；系统越难穷尽，越要给关键主张配置证据；行为越难预测，越要限制权限并准备恢复。
未来的软件可能包含更多机器生成的内部细节，但它是否值得信任，仍取决于人类怎样设计边界、检查证据、分配责任并从失败中更新。