AI 正在加速代码编写，却也让软件交付过程变得更加碎片化。为了破解这个“AI 悖论”，关键在于构建统一的架构并引入智能编排能力，将分散的 AI 工具、上下文、信任体系与监管流程整合起来，从而实现从开发到部署的持续价值流动，并避免技术债务的堆积。
译自：How to solve the AI paradox in software development with intelligent orchestration[1]
作者：Manav Khurana
软件行业在 2025 年末走到了一个转折点。当几个关键的 AI 模型相继突破能力阈值后，行业领袖们开始从根本上重新思考 AI 在编码中扮演的角色。早期的结果讲述了一个引人深思的故事。
在 Y Combinator 2025 年冬季批次的初创公司中，有四分之一使用 AI 生成了其 95% 的代码；各类组织也持续报告称，引入 AI 后开发者的生产力提升了 20% 到 50%。
然而，这些亮眼数字背后，掩盖了一个日益严重的结构性问题。编码，仅仅是软件交付过程中的一个环节，开发者每天花在上面的时间大约只有 52 分钟。仅仅加速这一个阶段，无异于在流水线上只加快其中一个工位，这必然会给后续的所有环节——代码审查、测试、安全扫描、部署和运维——带来巨大的压力和挑战。
现在，无论是工程师还是高管，都逐渐认识到这就是所谓的“AI 悖论”。本能地增加更多 AI 工具只会让问题变得更糟，因为其根本症结在于碎片化。真正的机遇，在于思考质量和安全如何贯穿整个软件开发生命周期来运作。
是什么阻碍了工程师团队
碎片化以多种形式存在，每一种都在限制着 AI 所能释放的真正价值。
“增加更多 AI 工具的本能只会加深问题，因为根本原因是碎片化。”
碎片化的 AI 工具。
大多数企业在过去十年中，通过逐个添砖加瓦的方式构建了其软件交付能力。如今，几乎每个工具都自带一个 AI 智能体。开发者可能用一个 AI 来辅助编码，用另一个进行安全分析，再用第三个来排查 CI/CD 流水线中的故障。这些智能体各自为政，彼此之间缺乏共享的认知和协作。
碎片化的 AI 上下文。[2]
由于缺乏统一的数据模型，每个智能体都在自己的信息孤岛中运行，无法获取关于整个项目的完整上下文。需求、代码历史、安全影响、部署约束和运维反馈分散在不同的系统中，需要团队手动去弥合这些信息鸿沟。
碎片化的 AI 信任。
即使拥有出色的 AI 工具，建立信任也非一日之功。有些开发者让 AI 生成整个功能模块；而另一些则对任何 AI 建议都持怀疑态度，不经手动重写绝不采纳。这两种极端做法本身都没有错。真正的差距在于，缺乏一套一致、可靠的验证和确认流程。这套流程应当能帮助团队根据任务的质量要求和风险等级，判断哪些工作适合交给 AI，以及在每种情况下需要多大程度的人工介入和批准。
碎片化的 AI 监管。
对数据驻留日益增长的要求，使得单一的部署模型已无法满足所有需求。与此同时，新兴的 AI 法规也提出了紧迫的治理需求，要求能够识别和记录在获批准的工具乃至“影子工具”中 AI 的使用情况。监管机构和行业组织要求更多的“可证明”控制措施。组织不能再推迟对 AI 安全与治理体系的重新审视了。
碎片化的 AI 预算。
财务团队看到了基础设施投资和各团队采购的软件工具中，AI 相关的“支出项”正在快速增长。他们合理地在推动务实精神，要求在进一步投入之前，必须明确展示使用遥测数据、成本控制和投资回报率。
开辟从碎片化到持续流动的道路
仅仅在现有工具之间实现更好的集成，无法根治这个问题。答案需要一个统一的、专为软件交付而构建的架构[3]。这种架构用持续的、并行的执行取代了顺序化的阶段划分，让 AI 智能体在循环中协同操作，而人类开发者则扮演着编排与决策的核心角色。
一个有效的平台应当覆盖从需求规划到生产运维的整个生命周期。当智能体们共享一个共同的执行环境时，部署智能体可以即时访问代码变更，安全智能体会自动触发修复流程，性能智能体则能直接反馈架构层面的见解。上下文随着工作流程自然传递，而不会在环节交接时丢失。
在泰雷兹的案例中，碎片化曾意味着团队之间几乎完全隔离地工作。迁移到一个统一平台改变了他们的协作环境，显著加强了遍布全球多个地点的多元化团队之间的沟通与协调效率。
智能编排的有效性，还取决于能否建立并维护整个组织中代码、需求、测试用例、安全发现、部署记录和性能指标之间的关联关系。
这种“组织记忆”使智能体能够访问[5]完整的上下文信息：某个功能是谁、为何而提出，适用的约束条件是什么，存在哪些类似的已有实现，以及当前的变更将如何影响下游系统。一个带有清晰所有权跟踪的服务目录，可以将开发者体验指标和安全指标结合起来，以便及时检测和修正偏差。
当代码合并请求的周期时间激增，或者变更失败率突然上升时，系统能够自动触发预设的响应机制。底层的数据模型持续演进，学习模式，使得每一个智能体都变得更加智能。
开发团队需要可定制的自主权，来定义智能体应该依赖哪些上下文、可以简化哪些工作流、必须执行哪些合规规则。对于低风险的变更，智能体可以自主完成；中等风险的变更则触发指定的审查工作流；而高风险的变更必须获得明确的人工批准。智能体能够跨越企业的整个工具链运作，从 Jira、PagerDuty、Confluence 和 Snowflake 等系统中提取所需上下文，而统一平台则负责全局的协调与编排。
组织必须将合规性要求深度贯穿于其 AI 运营体系中，这包括 AI 威胁建模、自动化的供应链安全扫描、密钥检测以及全面的 AI 使用治理。策略关卡会自动执行既定规则，审计跟踪会捕获每个智能体做出的关键决策，“影子”智能体检测功能则能识别出未经批准的工具使用。
通过持续合规性监控和可随时导出的证据包，组织能够清晰地向监管机构展示其治理成效。团队只需定义一次策略，平台便会确保它们在整个生命周期内得到一致地执行。西南航空就通过采用统一平台，在整个组织范围内实现了关键指标、安全标准和代码质量的一致性。
灵活的部署选项（如 SaaS、专用实例、自我托管）能够支持本地化部署和云托管等多种模型。透明、基于使用量的定价模式将成本与价值直接挂钩，提供代币消耗情况和团队级预算控制的清晰可见性。类似“应用市场”的方法，使得团队可以为每一项具体任务选择最合适的模型，而不是为不需要的捆绑功能付费。
定义未来走向的架构决策
那些成功将平台整合与智能编排相结合的组织，不仅能行动得更快，更是在改变软件交付本身的性质。他们的 AI 投资产生了复合增长效应，而非加剧碎片化。工作流程从分离的阶段演变为持续的执行，价值得以从构思到生产不间断地流动。
“每月碎片化地引入 AI 应用，都会增加更多的技术债务……整合并非可选项。”
将 AI 悖论仅仅视为一个暂时的麻烦，是一种战略误判。对于那些仅将 AI 视作编码加速器，而非整个交付流程转型杠杆的组织而言，这构成了一个基础性的、且会不断扩大的挑战。而做出关键架构决策的窗口期正在迅速缩短。
每个月碎片化地引入新的 AI 应用，都意味着堆积更多的技术债务、更复杂的集成工作以及更大的组织惯性。整合已不是一道选择题。真正的抉择在于：组织是选择今天有意识地主动行动，还是明天被动地艰难应对。
关于在云栈社区分享和探讨更多软件开发与架构实践，我们始终保持着开放的态度。
引用链接
[1] How to solve the AI paradox in software development with intelligent orchestration: https://thenewstack.io/solve-ai-paradox-orchestration/
[2] AI上下文。: https://thenewstack.io/better-context-will-always-beat-a-better-model/
[3] 为软件交付而构建的架构: https://thenewstack.io/monolith-vs-microservice-architecture-for-software-delivery/
[4] 泰雷兹: https://about.gitlab.com/customers/thales/
[5] 使代理能够访问: https://thenewstack.io/googles-data-commons-gives-ai-agents-access-to-a-vast-trove-of-stats/
[6] 西南航空: https://youtu.be/xLA69Qq5cVs
发表于 4 天前
|
查看: 818|
回复: 0
