洗车问题：为什么您的IT组织尚未准备好应对AI生成的代码
文章讨论了AI代理在修改系统时可能破坏自身运行环境的问题（洗车问题），以及企业IT如何适应AI驱动的超循环开发模式。提出了三大挑战：安全遥测与爆炸半径控制、供应链完整性、以及FinOps和代币经济学。建议IT部门从单一生产源转变为分布式生产的安全运营环境提供者。
上周，我的AI桌面代理自杀了——这完全是我的错。事情很简单：我让它降级NVIDIA驱动程序以解决稳定性问题。它照做了，新驱动被移除，旧驱动安装，重启后屏幕一片漆黑。问题在于经典的供应链不匹配：旧驱动集不支持代理本身所需的GPU加速桌面环境。重启后，代理的进程管理器无法初始化，因为它依赖的显示堆栈已失效。而它在重启前杀死的最后一个进程，正是它需要重新启动的那个。这就是“洗车问题”的教科书式案例——代理以破坏自身运行条件的方式修改系统。
这并非关于糟糕AI的故事，而是关于迭代式AI驱动变更遭遇从未设计为吸收此类变更的系统时会发生什么。随着AI辅助开发的普及，代理不再是编写一个完美解决方案，而是反复迭代：尝试、测试、失败、调整、再尝试。二十次、三十次、有时甚至五十次迭代后，解决方案才能达到生产质量。我将这种模式称为“超循环”（Hyper-Loop）。它设定基线，迭代直至找到解决方案，然后将其提升到下一个组装阶段，循环重复。每个阶段进行打包、测试和向上提升，最终形成一条更像粒子加速器而非瀑布模型的流水线。关键细节是：这个循环不需要IT部门参与。它运行在企业的资产和数据上，并且越来越隐蔽。普通知识工作者带着笔记本电脑和免费AI账户，已经在你的基础设施上酝酿下一个突破。
企业IT过去三十年一直在整合生产手段：开发通过IT，部署通过IT，变更管理通过IT。这是一个单线程模型——一条审查流水线，一条审批链，一套控制措施。AI打破了这一模式。软件制品的来源不再是单线程穿过IT，而是多线程、分布式，运行在你几乎无法控制的终端机器上。问题不在于如何阻止——你无法阻止，也不该尝试。问题在于如何构建一个适应新现实的验收过程。我们需要的是一个“测试框架”（testing harness）——一个位于生产意图和生产部署之间的额外审计循环，无论制品来自官方开发团队、承包商，还是通过提示词构建出微服务的业务分析师。
咨询行业已经认识到，AI使高级团队能够交付以前需要金字塔式初级员工才能完成的工作。同样的原则适用于内部：你的组织现在每个层级都在生产软件。无论你喜不喜欢，你现在都是软件审查者。在我观察过的每一个经历这一转变的组织中，都会遇到同样的三道障碍：
- 安全遥测与爆炸半径控制。大多数企业的默认安全姿态假设一组已知开发者通过已知流水线生成代码。当任何人都能生成可部署制品时，这一假设崩溃。答案不是在前端设置更严格的门禁，而是在边缘进行更好的隔离。寻找遥测领域的监控解决方案以获得广角可见性，利用无服务器功能提供安全网。目标不是阻止冒险的员工构建东西，而是确保当出问题时，爆炸半径以英寸而非街区为单位。
- 供应链完整性。系统补丁、依赖更新和软件供应链安全在流水线只有一个入口点时已经很难。现在，每个AI生成的制品都从公共注册表拉取未固定版本和幻觉包名，难度倍增。供应链正成为越来越可行的攻击向量。超循环中每个拉取外部依赖的循环都是潜在的妥协点。组织需要自动依赖扫描，将AI生成制品视为高风险直到证明安全；在制品级别执行严格的固定策略；以及运行时证明，以验证实际使用的依赖关系，而不仅仅是声明的。
- FinOps与代币经济学。成本面已经转移。Token maxing——运行过度推理以暴力破解解决方案——正在被市场纠正，但纠正并未产生标准，而是导致路由、优先级和支出管理解决方案的激增。OpenRouter、Cloudflare AI Gateway等十多个方案正在争夺AI生成工作的计费层。没有统一的成本模型，每个团队的实验就变成影子IT加信用卡。答案不是禁止实验，而是使实验在源头可见且预算化。
超循环模式并非对IT的威胁，而是IT在未来十年将承担的最重要职能。从IT作为单一生产源向IT作为分布式生产的安全运营环境提供者的转型已经在进行。成功的组织将是那些构建测试框架——审计循环、验收门、护栏——使业务能够在不自我毁灭的前提下生产软件的组织。否则，未来将是每个团队运行自己的循环、依赖、成本模型和安全姿态，而IT只在出问题时才发现。洗车问题是真实存在的，唯一的问题是：在AI代理重启到黑屏之前，你的组织是否建立了应对系统？