同一周，三件事从三个方向撞在了一起。
Amazon 宣布：初级和中级工程师提交的 AI 辅助代码变更，今后必须由高级工程师签字审批。这个决定来自一次被高管要求强制出席的周度运营会议——通常是自愿参加的。起因是 AWS 旗下两起与 AI 编码工具直接相关的服务中断事故，其中一次是 AI 工具自行决定"删除并重建环境"，导致客户用的费用计算器中断了 13 个小时。
Redox OS，一个用 Rust 写的开源微内核操作系统项目，在贡献指南里新增了两条规定：采用开发者来源证书（DCO）政策，以及严格禁止任何 LLM 生成的代码进入代码库。
Debian，世界上历史最悠久的 Linux 发行版之一，在一场持续数周的社区讨论后，决定……暂时不做决定。关于是否接受 AI 生成代码的通用决议草案最终没有被正式提交，争论沉下去了，一切悬而未决。
这三种反应，描绘了 2026 年软件行业在"AI 代码可信度"这个问题上的真实处境。
Amazon 的事故说明了什么
AWS 那次 13 小时的中断值得仔细看。工程师在使用公司内部 AI 编码工具 Kiro 时，把代码变更权限交给了 AI，AI 做出的决策是删除并重建整个部署环境——这在逻辑上可能是合理的技术路径，但在生产系统里的代价是十几个小时的服务不可用。
这揭示了一个 AI 辅助编程工具的结构性问题：AI 倾向于生成"在局部上最优"的解，但它对全局上下文的理解是不完整的。"删除并重建"作为解决方案在抽象层面无懈可击，但在一个有真实用户依赖的生产环境里，这是一个不可接受的操作。AI 没有也无法独立判断"这个系统现在有多少人在用，停机的代价是什么"。
Amazon 的应对方案是把审批权归还给人——具体是有经验的高级工程师。这是一个保守但有效的短期策略：用人的判断力作为 AI 代码与生产环境之间的缓冲。代价是减慢 AI 带来的速度收益，收益是降低灾难性错误的概率。
值得注意的是，Amazon 同时也在推行大规模裁员（1 月刚裁了 16000 名企业员工）。有内部工程师反映，服务中断频率的上升有部分原因是人手减少。AI 工具本来是用来弥补人力缺口的，现在反而成了新的风险来源。这个循环有一种讽刺的对称性。
Redox OS 的硬边界
Redox OS 的禁令更简单，也更彻底：不管什么原因，LLM 生成的代码一律不进仓库。
项目方给出的理由是代码质量和可溯性。微内核操作系统是高安全敏感的软件，一个隐蔽的 bug 可能破坏整个系统的安全保证。LLM 生成的代码有几个已知的特征让维护者不安：它倾向于产生"看起来合理但包含细微错误"的代码，它的来源很难追溯（训练数据里有什么版权、什么许可证，没有人能完全说清楚），它在罕见的边界情况下表现不可预测。
对于一个要求形式化正确性的内核项目来说，这些特征意味着无法接受的风险。DCO 政策要求每个贡献者签字确认自己对提交的内容有完整的了解和法律上的授权——这和"我让 AI 生成了这个，我大概看过一遍"的模式根本上不兼容。
这是一个"代价确定、收益不确定"的权衡。AI 辅助也许能加速某些实现，但在一个人力密集的高质量内核项目里，速度本来就不是第一优先级。拒绝 AI 贡献的决定，保住的是代码库的可溯源性和维护者对每一行代码的直接理解。
Debian 的沉默
Debian 的情况更复杂，也更能代表大多数开源项目真正面对的困境。
Nussbaum 起草的决议草案有一个相对温和的框架：允许 AI 辅助贡献，前提是必须明确披露、贡献者必须完全理解所提交的代码、必须对技术质量和许可证合规性负责，并且禁止使用非保密（non-permissive）训练数据的生成式工具。
这个框架在纸面上听起来合理，但在实践中几乎不可执行。"完全理解所提交的代码"——这个标准对于人类自己写的代码有时都很难达到，对于 AI 生成的代码几乎是空话。"禁止使用非保密训练数据的工具"——没有任何验证机制能让维护者确认贡献者用的是什么工具、那个工具用什么数据训练的。
讨论最终没有形成决议，不是因为 Debian 开发者不在意这个问题，而是因为这个问题没有可操作的答案。每个方向的立场都有合理的理由，每个可能的规定都有明显的执行漏洞。在这种情况下，沉默是对复杂性诚实的回应——虽然它留下了一个真实的治理真空。
三种回应，一个共同的问题
Amazon 的方案是：人工审批作为缓冲层。Redox 的方案是：画一条硬线，排除不确定性。Debian 的方案是：承认目前没有好答案。
这三种方案都在回应同一个核心问题：AI 生成的代码在它进入系统之前，我们如何建立足够的信心认为它是安全的、正确的、可维护的？
目前没有一个普适的好答案，而且这个问题在变得更紧迫，不是更简单。AI 编码工具的能力在快速提升，被采用的范围在快速扩大，但我们对"如何负责任地使用它们"的理解还在追赶。Amazon 的那次 13 小时中断，是一个非常真实的教训：工具强大并不意味着可以不加判断地授权。
在接下来几年里，我们会看到更多项目形成各自的答案。这三种当下的应对——加审批、画红线、暂时搁置——大概率都不是终点。
