---
title: "黑箱转向（八）：三种黑箱，三种控制"
url: https://lingming.blog/posts/2026/redefining-control-in-the-age-of-generative-systems/
date: 2026-03-07
lastmod: 2026-08-31
tags: ["软件控制","生成式 AI","系统复杂性","软件验证","工程哲学"]
categories: ["软件工程","人工智能"]
description: "黑箱时代如何重新定义控制？本文用三种黑箱与三层控制构成决策矩阵，说明何时需要理解、验证、限权、监控和恢复。"
---

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


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

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

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

## 三种黑箱

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

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

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

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

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

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

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

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

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

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

## 三层控制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 三个案例

### AI 生成一个纯函数

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

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

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

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

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

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

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

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

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

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

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

## 控制的有限定义

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

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

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

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

## 八篇文章留下的八个判断

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

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

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

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

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

## 延伸阅读与参考资料

- [NIST：Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- [NIST：Generative AI Profile for the AI Risk Management Framework](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence)
- [NIST SP 800-207：Zero Trust Architecture](https://www.nist.gov/publications/zero-trust-architecture)
- [DORA：State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/)
- [SLSA：Provenance and Build Terminology](https://slsa.dev/spec/v1.1/terminology)

*上一篇：[《黑箱转向（七）：AI 生成代码出错，谁负责》]({{< relref "/posts/2026/the-ethics-of-the-black-box.md" >}})。*