AI 模型能包揽软件全流程，但几乎都不该那样用

过去两年间，大多数关于 AI 与软件开发的讨论都集中在安全层面：如何确保 AI 生成的代码是安全的？如何防止知识产权流出组织边界？如何治理 prompt、模型和数据访问？

这些问题很重要，但它们并非决定 AI 计划成败的关键问题。

各类组织正在意识到，AI 不仅仅是一款提升开发者生产力的工具。它是软件交付内部一个全新的架构层。当 AI 进入生产环境，最大的风险正从模型输出转向系统设计。

"当 AI 进入生产环境，最大的风险正从模型输出转向系统设计。"

换言之，AI 不会破坏你的 SDLC，但糟糕的 AI 架构却很有可能。

我们正在重蹈早期云采纳的覆辙

任何经历过云采纳第一个十年的人，都看过这部老电影。

当时所有人都感受到了尽快上云的压力……然后账单就来了。成本飙升，治理日趋复杂，工作负载可移植性变得困难。一些组织通过将工作负载回迁或采用混合云策略来重新获得灵活性和控制权，从而做出了应对。

我们看到 AI 领域正在上演类似的情况——一些组织正在亲身了解，当 AI 使用从少数开发者尝试 agent 扩展为企业级软件交付战略时，会发生什么。每次调用代码生成、测试创建、文档更新和验证活动的 prompt，都会消耗 LLM 推理和计算资源。随着采纳规模扩大，相关成本、治理需求和运营复杂性也在同步增长。

随着更多组织将 AI 迁移到生产环境，业界越来越达成共识：AI 不能仅仅作为服务被消费，还必须作为一个系统进行治理，具备更高的可见性和监督。

未来不是单一模型；而是一条 AI 供应链

软件交付不是一项单一活动。它是一系列专业活动的集合，涵盖规划、编码、测试、验证、部署、治理、合规和运营。期望一个模型高效地完成所有这些功能，类似于期望一个服务或一个平台来管理整个软件栈。

相反，AI 原生的软件交付将呈现为一条供应链。

想象一个未来的开发工作流，不同的 AI 系统负责交付的不同阶段：

一个规划模型帮助定义需求并生成用户故事。

一个编码模型生成实现逻辑。

一个测试模型创建单元测试和集成测试。

一个验证 agent 根据需求审查输出。

合规 agent 确保策略和监管控制得到满足。

治理系统监控整个管道中的活动、成本和模型性能。

在这个世界里，软件交付成为一个编排的 AI 能力网络，而不是对单一模型的依赖。

这种转变在围绕 agentic 系统的更广泛讨论中已经可见。然而，关于 agent 的讨论往往聚焦于它们能做什么，而不是它们在软件交付中处于什么位置，以及组织应该如何治理它们。

为什么小模型可能比前沿模型做更多工作

像 Claude、Gemini 和 GPT-5 这样的大型前沿模型可以在多个领域进行推理，综合复杂信息，生成详细计划，并处理广泛的任务。但这并不意味着它们是软件开发周期中每项工作的最佳工具。事实上，大多数 SDLC 工作并不需要前沿智能。

《星球大战》在这里提供了一个有用的类比——C-3PO 和 R2-D2 都是智能机器，但它们服务的目的截然不同。

前沿模型是 AI 中的 C-3PO——能力出色的多面手，可以支持各种任务，但在规模化运营时也资源密集且成本高昂。然而，大多数软件交付任务需要的是 R2-D2：一种针对特定工作优化的专业系统。软件交付不需要一个聪明的助手。它需要一队专家。

"软件交付不需要一个聪明的助手。它需要一队专家。"

依赖单一前沿模型处理每项 SDLC 任务的组织，与使用专业 AI 系统的组织相比，将花费更多、扩展效率更低、控制力更弱。相反，一组专门的"R2-D2"模型和 agent 可以针对以下任务进行优化：

一个专门生成单元测试的模型。

一个优化用于代码审查的模型。

一个负责构建验证的模型。

一个专注于合规检查的模型。

一个用于评估需求是否已满足的模型。

这些任务中的许多并不需要前沿模型的广泛推理能力。它们需要的是一致性、速度和专业化。

这并不意味着前沿模型会消失。在工作流开始时，可能会使用大型模型来帮助定义需求、映射业务目标或制定实施计划。它也可能被用在管道末端作为"AI 裁判"，评估输出、验证质量，或根据组织策略核实合规性。

但在此之间的大量工作，可能会越来越多地由更小、更专业的模型来处理——它们的运行成本更低，更容易微调，输出也更可预测。

AI 控制计划和编排将治理带入管道

从历史上看，软件团队往往将治理和合规作为下游活动来对待。开发者写代码，安全团队审查，审计员验证，合规团队在事后核实需求。

然而，当软件由多个 AI 系统生成、修改、测试和验证时，治理不能再是一个独立的工作流。它必须成为一种集成能力，嵌入到交付生命周期本身中，使组织能够轻松追踪：

AI 使用在哪些地方

哪些模型在做决策

输出如何被验证

组织策略是否被遵循

成本如何被追踪和优化

合规要求如何被执行

本质上，当 AI 成为软件交付基础设施的一部分时，治理不能再事后补救。它必须从一开始就被设计到系统中。

"当 AI 成为软件交付基础设施的一部分时，治理不能再事后补救。它必须从一开始就被设计到系统中。"

随着 AI 被嵌入到软件交付的每个阶段，开发团队将需要一种方式来协调模型、agent、策略、合规需求、测试工作流和成本控制——这在一个日益复杂的生态系统中愈发必要。这就是为什么我们开始看到 AI 控制平面和编排层的出现，它们帮助组织治理 AI 交互、管理 token 消耗，并在 AI 驱动的开发生命周期中维护信任。

在整个行业中，我们看到对以下内容的增长需求：

参考实现，展示前沿模型、开源模型、agent、数据平台和治理框架如何组合在一起。

培训，帮助 DevOps 团队理解在 AI 原生世界中软件交付如何改变，以及如何管理新的工作流。

FinOps 工具，提供对 AI 使用和运营成本的可见性，使领导者能够做出明智的决策。

这些能力共同提供了一样许多组织仍然缺乏的东西：一份实用的蓝图，教导如何以可扩展、可治理、经济上可持续的方式采纳 AI。

这就是为什么有经验的技术合作伙伴的角色正变得更重要，而不是更不重要。组织现在真正需要的是一项战略——将 AI 集成到软件交付中，而不创造新的技术债务、治理空白或失控的成本。

归根结底，竞争优势不会来自任何一个 AI 模型，而是来自拥有正确规模的架构——以及正确的合作伙伴——来将所有部分整合在一起。