企业开发需要 AI 空中交通管制

深度The New Stack2026年3月4日5 分钟阅读
企业开发需要 AI 空中交通管制
60% 的开发团队使用超过 5 种 AI 工具,DevSecOps 专业人员每周因此浪费 7 小时。企业面临工具碎片化与合规管理的双重挑战。

想象一下,如果你是今天的 CIO。你的开发者想试用最新的 AI 编程助手。每周都有新模型、新智能体或新工具冒出来,承诺带来前所未有的生产力提升。你该批准哪些?又该如何决策,同时清楚知道三个月后整个格局会完全不同?

应对这一挑战,出现了两条截然不同的路径:初创公司和小团队优先考虑敏捷性,快速采用那些承诺能最快推向市场的工具。而企业则专注于数据隐私、主权和合规等约束条件,这些是它们运营的基础。

这两种方法之间的张力造成了一个困境。你不能每隔几个月就更换整个技术栈,但原地踏步又意味着落后于那些行动更快的竞争对手。

真正的瓶颈是工具碎片化

说到 AI 工具,数量太多了,而 DevSecOps 专业人员对它们的控制力却不足。

近期数据显示,60% 的开发团队使用超过 5 种工具进行软件开发,49% 使用超过 5 种 AI 工具。这种碎片化的成本是惊人的。DevSecOps 专业人员每周因效率低下损失 7 小时,几乎相当于一整个工作日花在管理脱节的工作流和在不同平台间切换上下文上。

“开发者会使用他们想要的工具。影子 IT 已经演变成影子 AI,问题在于如何管理它。谁或什么来扮演空中交通管制员的角色?”

你可能认为解决方案是限制工具的采用,强制推行一套单一的、经过批准的堆栈。但当这种方法遇到现实时就会失败。开发者会使用他们想要的工具。影子 IT 已经演变成影子 AI,问题在于如何管理它。谁或什么来扮演空中交通管制员?

从氛围编程到企业现实

现在任何人都可以通过提示词生成可运行的代码,将业务需求通过自然语言转化为可工作的应用程序。这种可及性代表了真正的进步,但 73% 的组织已经因“氛围编程”方法而经历了重大问题。

LLM 的非确定性意味着相同的提示词可能产生不同的输出,这带来了传统开发工具所没有的验证挑战。AI 可以优化给定的解决方案,但只有人类才能退一步评估我们是否在用正确的方式解决正确的问题。

企业开发面对的是数百万行代码的现有代码库、不可协商的合规要求、遗留系统集成和复杂的安全协议。这些约束条件会降低 AI 的效力。一行代码看似微小的改动,可能会波及互连的系统,其影响方式即使是经验丰富的开发者在没有全面上下文的情况下也难以预测。

“规模陷阱”

AI 帮助开发者编写指数级增长的代码,这意味着更多的审查、更多的测试要运行、更大的攻击面需要保护,以及更多的技术债需要管理。我们称之为规模陷阱。AI 加速了开发生命周期的一部分,却在其他地方制造了瓶颈。随着代码复杂性增加,最初让 AI 具有吸引力的速度、敏捷性和准确性开始受到侵蚀,形成一个恶性循环:团队行动更快,结果却更慢。

平台即空中交通管制

治理危机真实存在且正在加速。70% 的组织报告称,AI 正使合规管理变得更加困难,而非更容易。单个工具无法解决这个问题,因为它们缺乏在整个软件开发生命周期中执行一致标准所需的可见性和控制力。

“70% 的组织报告称,AI 正使合规管理变得更加困难,而非更容易。”

点解决方案,无论多么复杂,都无法解决 AI 编排、治理和合规的互连需求。需要的是一个能充当空中交通管制员的平台,确保每辆车都遵守规则,同时仍允许司机选择他们喜欢的路线。

以下是平台编排方法在实际中的运作方式:

  • 单一控制点:每一段代码,无论由哪种 AI 工具生成,都流经一个统一的平台,该平台一致地应用你组织的规则和法规。
  • 全面上下文:平台为 AI 智能体提供项目计划、测试套件、合规检查、安全扫描以及你整个 SDLC 的完整图景。有了这个上下文,智能体就能理解依赖关系和影响,从而有效运作。
  • 规模化验证输出:非确定性的 AI 输出需要一致的质量检查。平台方法系统地实施这些验证循环,在问题累积成生产问题之前将其捕获。
  • 设计即隐私:平台处理企业级的数据主权要求,确保你的代码和知识产权仍在你控制之下,而不是用于训练别人的模型。
  • 供应商无关的开发者自由(在护栏内):开发者可以使用他们偏好的工具,并尝试新兴技术,而平台确保一切都符合企业标准。

为持续变化而构建

今天构建编排基础设施的组织,创造了一种可持续的竞争优势,这种优势会随着时间的推移而增强。随着未来几个月和几年 AI 能力的发展,你将拥有立即采用新工具的基础,而竞争对手则需要在碎片化的工具链中改造治理。

你的开发者将拥有使用他们偏好的工具进行创新的自由,尝试新兴能力,并使用任何最有效的方法解决问题。你的企业则能确信,平台会强制执行安全协议、满足合规要求,并保持一致的代码质量,无论代码来源如何。

“未来属于那些能够快速行动而不破坏事物的企业。”

在 AI 开发领域,需要有人扮演空中交通管制员的角色。问题在于,你是通过一个能促进创新的平台方法来实现这种控制,还是通过限制措施将开发驱赶到影子 IT 操作中。

未来属于那些能够快速行动而不破坏事物、在清晰的护栏内激发开发者创造力、并将平台编排视为可持续创新基础的企业。今天建立平台工程基础的组织,将定义软件开发的下一时代。

本文编译自 Why enterprise software development needs air traffic control,版权归原作者所有。

觉得有用?分享给更多人

获取每周 AI 工具精选

工具推荐、实战教程和生态洞察,每周更新。

相关文章

Simon Willison 正在重构 LLM Python 库的抽象层,以支持服务器端工具执行等新功能。他利用 Claude Code 分析了四大 LLM 提供商的客户端库,生成了用于测试的 curl 命令和 JSON 输出。这些调研材料已开源,旨在帮助设计更通用的 API 抽象。

深度Simon Willison·4月5日·1 分钟

智能体技能——包含程序性知识和可执行资源的结构化包,供智能体在推理时动态加载——已成为增强 LLM 智能体的可靠机制。然而,推理时技能增强存在根本性限制:检索噪声引入无关指导,注入的技能内容带来大量 token 开销,而模型从未真正习得它所遵循的知识。我们提出一个问题:技能是否可以被内化到模型参数中,使其在无需任何运行时技能检索的情况下实现零样本自主行为?我们提出 Skill0,一个专为技能内化设计的上下文强化学习框架。Skill0 引入了一种训练时课程,从提供完整技能上下文开始,逐步撤除。技能按类别离线分组,并与交互历史一起渲染为紧凑的视觉上下文,教授模型工具调用和多轮任务完成。动态课程机制…

深度·4月5日·17 分钟

评论