← 返回网页版

黑箱转向(八):三种黑箱,三种控制

黑箱时代如何重新定义控制?本文用三种黑箱与三层控制构成决策矩阵,说明何时需要理解、验证、限权、监控和恢复。

2026-03-07Lingming约 1 分钟 https://lingming.blog/posts/2026/redefining-control-in-the-age-of-generative-systems/

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

经过八篇讨论,这句话需要被改得更精确。软件从来没有完全透明,约束也从来没有脱离实现。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
  • NIST:Generative AI Profile for the AI Risk Management Framework
  • NIST SP 800-207:Zero Trust Architecture
  • DORA:State of AI-assisted Software Development 2025
  • SLSA:Provenance and Build Terminology

上一篇:《黑箱转向(七):AI 生成代码出错,谁负责》。

Lingming 灵明 · https://lingming.blog/posts/2026/redefining-control-in-the-age-of-generative-systems/