黑箱转向（八）：三种黑箱，三种控制

Lingming — Sat, 07 Mar 2026 17:44:27 -0500

这个系列从一句有冲击力的判断开始：当代码生产超过人类理解，控制必须从实现转向约束。

经过八篇讨论，这句话需要被改得更精确。软件从来没有完全透明，约束也从来没有脱离实现。AI 真正加剧的是生成、验证与组织理解之间的不对称。应对它的办法不是宣布“透明性终结”，而是判断：面对哪一种未知，我们还需要理解什么，又需要哪些独立证据和恢复能力？

本篇不再重复一次未来宣言，而把全系列压缩成一个可操作的矩阵。

三种黑箱

来源黑箱：不知道为什么这样生成

最终代码可能清晰可读，团队却不知道它依赖了哪些上下文、为何选择这种结构、哪些假设没有进入仓库。来源黑箱影响的是意图、追溯和审查质量。

它主要出现在开发阶段，但不是 AI 独有。复制旧代码、使用外包制品或继承缺少记录的遗留系统也会产生相同问题。AI 让这类变化更容易快速、大批量出现。

系统黑箱：局部清楚，组合行为不清楚

源码、模块和配置都能访问，系统行为却由依赖、网络、数据、并发、部署环境和第三方服务共同形成。大型分布式系统长期处在这种状态。

系统黑箱的难点不是找不到任何代码，而是没有一个视角能穷尽所有交互。理解必须借助接口、架构图、实验、遥测和事故经验分布在组织中。

行为黑箱：运行结果具有统计性或适应性

当大模型直接参与生成、分类、规划或工具调用，同一输入可能因上下文、采样、模型版本和外部数据产生不同结果。此时静态源码无法完全规定产品输出。

行为黑箱需要评测分布、置信与失败类别、权限边界和持续监控。它不应被倒推到所有 AI 生成代码：模型写出的普通排序函数，仍然可以是一个确定性程序。

运行时代码代理可能同时具备三种黑箱：生成理由难追溯，工具与依赖形成复杂系统，决策又具有统计性。组合风险更高，但分析仍要逐层进行。

三层控制

认识控制：知道知识和未知在哪里

认识控制不要求一个人理解全部系统，而要求关键知识有明确归属，重要决定可以追溯，团队知道哪些组件只依赖契约、哪些区域必须深入审查。

常见资产包括设计说明、架构决策记录、代码审查、来源证明、依赖清单和责任地图。它们提供解释与调查基础，却不能单独保证系统行为正确。

行为控制：用证据限制允许发生的事

行为控制把目标和禁区转成接口、类型、不变量、权限政策、测试、静态分析和形式证明。对运行时模型，还包括离线评测、对抗测试、工具策略和输出验证。

它的边界是规格问题：没有写出的风险不会自动被证明，错误约束也可能被完美执行。因此证据必须标明主张、适用条件和残余不确定性。

运行控制：发现、限制和纠正真实失败

运行控制假定生产环境会出现模型外事实。它通过监控、审计、限流、隔离、灰度、熔断、降级、补偿和事故响应缩短影响。

运行控制也不能替代前两层。无限权限的系统即使监控完善，也可能在告警抵达前造成不可逆损害；没有设计理由的系统即使成功回滚，也可能反复制造同类事故。

把三种黑箱与三层控制放在一起

对象	认识控制	行为控制	运行控制
来源黑箱	记录模型、输入版本、设计取舍与批准者	小批生成、独立审查、构建与测试门槛	将具体部署绑定到可核验制品和审批
系统黑箱	接口所有权、依赖图、关键数据流、责任地图	契约、不变量、隔离、兼容性与故障测试	可观测性、容量保护、灰度、降级与恢复
行为黑箱	说明模型能力、数据、已知限制与适用范围	代表性评测、对抗测试、权限与工具约束	漂移监测、抽样审计、停止条件与人类升级

矩阵中的九格不是必须全部堆满的合规清单。它的作用是暴露空白：若团队只说“我们有测试”，可以继续追问测试针对哪种黑箱、支持哪一层控制，以及真实运行失败时谁行动。

控制强度应当跟随后果，而不是跟随潮流

一个生成内部报表脚本的助手，与一个可以批准贷款、调整药物剂量或修改生产防火墙的代理，不应使用同一控制标准。

可以沿四个问题确定强度：

后果是否可逆？ 错误文案可以编辑，资金转出和隐私泄漏难以撤回。
影响范围多大？ 单个开发环境与全体生产租户不同。
系统自主性多高？ 提出建议、创建草稿、执行操作和自我扩展权限是不同等级。
失败能否及时观察？ 明确报错比悄悄改变排序、歧视某类用户或积累财务偏差更容易控制。

低风险任务可以依赖抽样审查和普通测试。高风险、广影响、难逆转又难观察的系统，则需要更强规格、独立验证、细粒度权限、人类批准和事故演练。

三个案例

AI 生成一个纯函数

主要风险是来源和实现质量。保留小 diff，检查算法与边界，用性质测试和静态分析验证即可。研究基础模型内部特征通常不是必要控制。

AI 修改一个分布式结算服务

来源、系统两种黑箱同时重要。除了代码证据，还要检查数据迁移、幂等、依赖失败、权限、灰度范围和补偿路径。控制重点是跨模块不变量与故障半径。

代理在生产中自动处理退款

三种黑箱同时存在。模型判断具有统计性，工具调用具有外部副作用，还可能读取敏感数据。除了离线评测和制品审计，还要设置金额上限、身份验证、速率限制、异常升级、人类复核和即时停用能力。

案例说明，“AI 系统需要概率控制”只对行为本身具有概率性的场景成立。开发阶段用了生成工具，不足以把整个软件从确定性工程改写为统计工程。

透明性不是越多越好，而要分配到关键位置

完全开放所有内部细节会制造信息过载，也可能泄漏安全和隐私信息。完全依赖外部行为又会让调试、审计和知识积累困难。

成熟设计应当分配透明性：

高后果规则和权限策略要清楚、可检查；
复杂组件可以隐藏实现，但必须给出稳定契约和失败方式；
生成过程保存足够来源证据，不必永久保存全部敏感上下文；
运行模型说明适用范围和已知限制，不用虚假的自然语言解释掩盖不确定性；
事故调查能够从用户影响追到版本、配置、制品和责任角色。

真正要反对的不是黑箱，而是没有选择依据的黑箱：团队不知道自己隐藏了什么，也不知道用什么证据弥补。

控制的有限定义

本系列最终采用的定义是：

工程控制，是在明确适用条件和残余不确定性的前提下，拥有与风险相称的理由相信系统会保持在可接受边界内，并能在越界时及时发现、限制和纠正。

这个定义不承诺绝对安全，也不把一切降为概率。确定性协议可以保留确定性性质，统计模型则需要分布性证据；两者都必须面对规格遗漏、环境变化和组织执行问题。

它也没有把理解排除在控制之外。理解帮助我们提出正确性质、解释反例和修复未知故障；约束帮助我们在无法理解全部细节时限制风险；运行反馈帮助我们发现此前理解和规格都没有覆盖的现实。

八篇文章留下的八个判断

软件工程从来依靠分层理解，而不是单个心智掌握一切。
AI 的关键压力是生成—验证落差，不是代码行数本身。
认知债是安全修改所需知识与团队可调用知识之间的缺口。
控制需要多层独立证据，没有单一指标可以取代其余方法。
架构通过故障半径、权限、时间和相关性塑造风险。
约束设计是一种增强的工程能力，不是脱离实现的职业特权。
来源可以分布，责任仍必须落在能够行动的人与组织上。
不同黑箱需要不同控制；“AI”不是统一风险类别。

结语：从全面理解，走向有边界的可信

AI 不会让工程从理性走向神秘，也不会自动把复杂性提升为更高级秩序。它只让我们更难继续假装：实现出现了，理解、验证和责任就会自然跟上。

黑箱转向最值得保留的，不是“透明性已经死亡”这句宣言，而是一条更朴素的纪律：实现越容易生成，越要说明什么不能交给生成；系统越难穷尽，越要给关键主张配置证据；行为越难预测，越要限制权限并准备恢复。

未来的软件可能包含更多机器生成的内部细节，但它是否值得信任，仍取决于人类怎样设计边界、检查证据、分配责任并从失败中更新。

延伸阅读与参考资料

上一篇：《黑箱转向（七）：AI 生成代码出错，谁负责》。

工程哲学 on Lingming 灵明