为何在人工智能编程时代，DevSecOps成了新的瓶颈

简而言之：数十年来，开发软件成本最高的环节就是编写代码本身。工程师们必须将需求转化为架构设计，撰写数千行代码，排查错误，编写测试用例，整合各个系统，最终将所有内容部署上线。生成式人工智能正在颠覆这一模式。如今，开发者只需用通俗语言描述需求，AI编码工具就能完成大部分实际实现工作——包括API、SQL查询、测试套件、基础设施代码化、文档编写、迁移脚本，有时甚至能生成整个应用程序。这已不再是小众实验。谷歌2025年的DORA研究报告显示，90%的受访技术从业者已在日常工作中使用人工智能，超过80%的人认为这提升了他们的效率。但其中存在一个值得重视的问题：一旦建成……

编程软件的成本正在大幅下降，因此对这类软件的检测就显得愈发重要。生成的代码越多，需要测试的范围就越广；引入的依赖项越多，通过供应链面临的风险就越大；发布的应用程序越多，需要管理的基础设施就越复杂；版本更新越频繁，投入生产的环境变更就越多。而由人工智能生成的代码则引发了更多疑问：它的来源是什么？是否安全？是否符合标准？又该由谁来负责？因此，软件工程领域的下一个重要转折点或许并非人工智能辅助编码，而是人工智能驱动的DevSecOps——即介于人工智能生成的代码与实际运行系统之间的自动化信任层。

当前形势：人工智能正在突破编码瓶颈

传统的软件工程流程通常如下：

需求分析 → 设计 → 编码 → 测试 → 安全处理 → 部署 → 运维

在很长一段时间里，编写代码本身就占据了大部分工作量。

手动构建一个新的 API 往往需要开发者花费数天时间。

现在，开发者可以这样指导人工智能代理：

“用 Python 构建一个用于新客户注册的 REST API，需包含输入验证、持久化层、身份认证、单元测试、Dockerfile 以及部署配置文件。”

该代理能够在几分钟内完成其中的大部分工作。

这代表了软件开发成本结构的根本性变化。

每新增一个功能、一项服务或一款应用的成本都在不断下降。

人工智能的应用范围已不再局限于代码自动补全——它正在拓展到智能代理行为：解析整个代码库、同时编辑多个文件、执行测试套件、修复故障，并能自主发起拉取请求。

Gartner将这一趋势称为AI原生软件工程——在这种模式下，人工智能贯穿整个开发生命周期，而不仅仅是协助处理代码片段。该机构预计到2028年，90%的企业工程师将依赖AI代码助手。

然而，编写代码更快并不必然意味着软件发布速度也会加快。

这其中的差距才是关键所在。

我们正在消除瓶颈

想象这样一个工程团队，他们过去每周会发布：

100次软件变更。

其测试流程、安全检查及部署基础设施都是为应对大致如此的负载而设计的。

现在引入了人工智能代理。

开发者的工作效率大幅提升，每周的产出量增至：

300次软件修改。

这代表了编码能力的巨大提升。

但问题在于：

300次修改都需要代码审查。

300次修改都需要进行测试。

300次修改都需要通过安全检测。

300次修改可能会引入新的依赖项。

300次修改都需要符合政策要求。

300次修改都需要做出部署决策。

所有这些最终都会导致更多需要在生产环境中监控的软件。

限制并未消失——只是转移了位置。

旧的问题是：

我们能否足够快速地开发软件？

新的问题是：

我们能否快速地对软件进行验证并安全地运行它？

DORA将人工智能的作用描述为放大器——它会放大现有的各种工程实践，无论好坏。他们的研究结果表明，人工智能虽然能提升交付速度，但同时也会暴露出那些原本无法承受如此高效率的系统缺陷。

这种视角的转变至关重要。

新的软件工程公式

简而言之，目前的趋势大致如下：人工智能的采用推动了代码产量的激增，进而导致通过开发流程的变更数量增加，这又需要更多的验证工作，促使团队采用更复杂的自动化手段，最终推动企业加大在平台工程方面的投入。

或者用一句话概括：

编写代码的成本正在降低，而对其的信任则变得愈发重要。

这正是为什么随着人工智能辅助开发成为常态，DevSecOps的重要性会与日俱增，而非逐渐被边缘化的核心原因。

DevSecOps究竟是什么？

人们很容易将DevSecOps简化为“在CI/CD流程中添加安全扫描工具”，但这其实低估了它的实际范畴。

DevSecOps的内涵远比这丰富得多。

其核心在于将：

开发 + 安全 + 运维

整合为一个持续的交付流程。

可以将其视为一种机制，用于判断开发者编写的代码——或是越来越多由人工智能工具生成的代码——是否真的适合在生产环境中运行。

一个完整的DevSecOps流程通常包括：

源代码管理

跟踪代码、分支、提交记录、拉取请求以及随时间变化的历史数据。

代码质量

代码检查、静态分析、架构审核以及可维护性评分。

SAST

静态应用安全测试直接扫描源代码以发现安全漏洞。

机密信息检测

扫描代码中是否意外包含了密码、API密钥、证书或令牌等机密信息。

SCA

软件成分分析可识别出存在风险或漏洞的第三方依赖项。

SBOM

软件物料清单会列出应用程序中实际包含的所有组件。

IaC安全

这类扫描工具用于检查Terraform、CloudFormation、Kubernetes配置文件等基础设施代码。

容器安全

检查容器镜像中是否存在易受攻击的操作系统包、过时的库以及配置错误。

测试

包括单元测试、集成测试、回归测试、API测试、性能测试，以及越来越多用于验证行为正确性的AI生成测试。

策略与合规性

针对企业的特定规则，用于确保软件符合组织要求、监管标准及架构规范。

CI/CD

一旦通过审批，软件就会被构建、打包并部署到不同环境中。

部署

诸如金丝雀发布、蓝/绿部署和特性开关等策略，决定了代码如何进入生产环境。

运行时安全与可观测性

会对实时运行的应用程序持续监控漏洞、攻击、崩溃、异常行为以及性能下降情况。

随着机器在实际编码工作中占据越来越大的比例，这套体系的重要性也愈发突出。

AI也在改变DevSecOps

这种转变还有另一个值得探讨的层面。

DevSecOps 不仅要处理更多由人工智能生成的代码。

DevSecOps 本身也在向人工智能驱动的方向发展。

目前，普通的扫描工具可能会标记出类似这样的信息：

在依赖项 X 中检测到严重漏洞。

而基于人工智能的同一系统则能进一步提供：

检测到严重漏洞。 以下是其重要性的说明。 以下是受影响的代码路径。 以下是推荐的版本。 我已经生成了修复方案。 我已经运行了回归测试。 这是对应的拉取请求。

这代表了一种完全不同的运作方式。

从检测到自主修复

看看这项能力是如何分阶段发展的。

第一代：检测

工具会向人类发出警报：

“存在漏洞。”

工程师随即开始深入调查。

第二代：建议方案

该工具进一步提供：

“存在漏洞，以下是修复方法。”

工程师按照建议进行修复。

第三代：问题解决

该工具再进一步：

“存在漏洞。我已编写修复代码并提交了拉取请求。”

工程师的任务变为审核该修复方案。

第四代：自主化DevSecOps

最终，对于风险较低的变更，整个流程：

检测 → 理解 → 修复 → 测试 → 验证 → 部署 → 监控

几乎可以无需人工干预即可自动运行。

人们不再逐个手动完成步骤，而是转向制定策略、处理异常以及整体监督系统。

软件供应链变得至关重要

这种转变之所以如此重要，还有第二个原因。

现代软件很少是完全从零开始编写的。相反，它是通过许多外部资源组合而成的：来自开源注册库的库、第三方API、预构建的容器镜像、应用框架、托管云服务、可重用的基础设施模块，以及现在由AI工具直接生成的输出。

AI极大地加快了这种组装工作。

Sonatype在2026年针对软件供应链的研究指出，该生态系统正逐渐迈向机器级规模，表现为自动化构建、不断扩展的依赖关系图，以及让来源追溯和信任问题变得比以往更为重要的AI代理。

因此，各组织越来越需要回答以下问题：

这段代码的来源是什么？

是哪款AI生成的它？

是哪个模型版本产生的它？

它引用了哪些依赖项？

这些依赖项是否经过审核并获得批准？

对其进行了哪些安全检查？

应用了哪些策略？

谁批准了它的部署？

当前生产环境中实际运行的是什么？

这使 DevSecOps 远超简单的自动化范畴。

它演变成一种覆盖全企业的软件信任体系。

AI 责任机制成为新要求

这一担忧已在行业调查中显现。

GitLab 2026 年的一项调查显示，80% 的受访者称其所在机构部署 AI 工具的速度快于制定相应治理政策，92% 的受访者表示面临与 AI 生成的代码相关的治理难题。

想象一下审计员会这样询问：

“为什么这段代码会接触到客户的财务数据？”

过去，只需指出负责的开发者即可。

在基于智能代理的开发流程中，诚实的回答或许会是：

“这是某个AI编程代理在处理功能#4821时生成的。”

这引发了一系列全新的治理问题。

是什么提示词促成了它的生成？

它能够访问哪些上下文信息？

它是否引入了新的依赖项？

那个依赖项是否已经过使用审批？

实际进行了哪些测试？

在合并之前是否有任何人对更改进行了审核？

如果有，是哪个AI安全代理对其进行了评估？

简而言之，AI来源追溯正逐渐成为软件供应链中一项新的必备要素。

AI DevSecOps平台的兴起

如今的企业通常使用一系列相互独立的工具，大致如下：

开发者 → GitHub → Jenkins → SonarQube → Snyk → Artifactory → Kubernetes → Datadog → ServiceNow

每种工具仅负责工作流中的某一部分。

人工智能使得这种碎片化状况的成本大幅上升，因为智能体若要发挥作用，就需要能够查看整个生命周期的完整信息。

一个用于处理生产环境故障的人工智能智能体可能需要访问以下内容：

• 原始需求
• 源代码
• 提交历史记录
• 测试结果
• 漏洞数据
• 部署历史记录
• 基础设施配置
• 运行时日志
• 生产环境监控数据
• 过往故障记录

正是这种需求推动了市场向统一的工程平台发展。

Gartner已将平台工程以及基于生成式AI的平台工程列为软件工程领域的关键趋势，预计到2027年，70%拥有平台团队的组织会将生成式AI功能嵌入其内部开发者平台中。

DORA也提出了类似观点：平台的质量在很大程度上决定了人工智能的引入能否真正提升组织绩效，还是只会带来“下游混乱”。

价值所在

这一转变对整个科技行业都将产生重大影响。

哪种编码助手最好？

这个问题依然重要。

但与此同时，一个更重要的企业级问题也在浮现：

谁在掌控着从人工智能生成的创意到可靠生产软件的整个流程？

正是这个流程孕育出了巨大的价值。让我们来看看其中涉及的各个环节：

人工智能编码

Copilot、Claude Code、Cursor等工具。

↓

代码源与协作

GitHub、GitLab、Bitbucket等平台。

↓

安全性

SAST、SCA、机密信息扫描、容器安全以及供应链安全。

↓

构建成果管理

软件包、容器以及来源记录。

↓

CI/CD流程

自动化的构建、测试和部署过程。

↓

云平台

基础设施与运行时环境。

↓

可观测性

日志、指标、追踪数据、故障信息以及生产环境洞察。

↓

治理

政策、审批流程、审计记录以及合规文件。

能够整合这些要素的平台将具有极其重要的战略意义。

未来：开发者成为协调者

这并不意味着开发者的角色会消失。

变化的是他们日常工作的具体内容。

目前大多数开发者将大量时间用于编写实现逻辑。

未来，他们的角色将转向成为智能系统的协调者。

他们不会再对机器说：

编写这个函数。

而是更常会说：

构建这项功能。

具体的实现工作则由人工智能来完成。

人们的注意力转向对架构选择、业务规则以及风险敞口的评估。

安全检测工具会查找系统中的薄弱环节。

测试工具用于确认系统的运行行为是否正确。

部署工具负责处理系统的发布流程。

在系统正式运行后，监控工具会持续进行监测。

如今，相关人员的职责越来越偏向于对整个系统进行整体监管，而非逐个组件地组装系统。

Gartner也做出了类似的预测，指出开发者们将逐渐转向流程编排、问题定义、系统设计，并确保人工智能生成的结果真正符合质量标准。

DevSecOps工程师也在发生变化

DevSecOps领域的职能也在朝着相似的方向发展。

传统上，这一岗位的工作内容主要包括：

• 编写自动化流程
• 维护Jenkins平台
• 配置安全扫描工具

管理部署脚本

排查环境问题

它逐渐意味着以下内容：

• 设计能够端到端交付软件的平台
• 建立整个组织所依赖的规范框架
• 编写代理程序必须遵守的安全规则
• 监督自主编码代理的权限范围
• 设计能够自动解决问题而非等待人工干预的系统
• 追踪每份软件的实际来源
• 创建团队可重复使用的共享模板，避免从头开始
• 量化组织所承担的工程风险程度
• 确保自主交付系统稳定运行

换种说法：

DevSecOps 的工作重点已从维持开发流程的运行转变为构建用于管控人工智能生成软件的控制层。

安全机制从“检查点”变为“护栏”

在当今的大多数组织中，安全措施仅作为一道检查点存在。

开发团队完成某项工作后，

安全团队会对其进行检查。

一旦发现问题，

开发团队会进行修复，

安全团队再重新检查。

当人工智能将开发速度大幅提升到以往无法想象的水平时，这种来回反复的做法已不再实用。

取而代之的模式更像是：

策略 → 自动化 → 持续执行

安全团队只需制定一次规则，

平台便会持续不断地应用这些规则，无需每次都等待人工确认。

具体运作方式如下。

规则：任何暴露在互联网上的 API 均不得跳过身份验证。

有一个 AI 工具发布的 API 缺少此项检查功能。

DevSecOps 平台立即发现了这一问题。

部署会被自动阻止。

该编程工具会收到具体的原因说明。

编程工具随后会对 API 进行修复。

会再次运行测试。

此时安全规则已得到满足。

部署可以继续进行。

安全团队并未手动审查这一过程。

但整个流程中的每一环节都严格遵守了政策要求。

这正是人工智能驱动的 DevSecOps 所带来的真正价值。

为何企业可能会在 DevSecOps 上投入更多而非更少

人们很容易认为人工智能能让企业用更少的工具和更低的工程基础设施成本来运作。

但在技术架构的关键部分，情况恰恰可能相反。

人工智能使各组织能够开发出远超以往数量的软件。

但每新增一个应用程序都会带来一系列后续问题：需要暴露新的API、运行额外的容器、跟踪另一组依赖关系、配置更多的云资源、进行新一轮安全扫描、管理又一次部署、筛选额外的遥测数据、修补新的漏洞，同时还需收集和存储更多的合规性证明。

简而言之，上线运行的软件越多，就需要监控、验证和确保其可靠性的方面也就越多。

GitLab早前的DevSecOps调查已经发现，安全从业者担心人工智能生成的代码会增加他们的工作量，而其2026年的研究则指出了所谓的“人工智能效率悖论”：更快的代码生成速度加上相互脱节的工具，可能会在后续流程中产生新的瓶颈。

因此，经济模式正从：

主要按代码产出量支付员工薪酬

转向：

为能够安全处理海量软件输出的平台付费。

一个简单的例子

以下是一个具体的示例。

假设一家银行需要新增一项功能：

让客户通过移动应用冻结信用卡。

过去

产品经理负责编写需求文档。

开发人员则负责设计API。

那位开发人员负责编写代码。

同事会对代码进行审核。

质量保障团队会构建测试套件。

安全团队会执行扫描检测。

DevOps团队负责搭建开发流程。

运维团队负责部署上线。

整个过程可能需要数天甚至数周才能完成。

明天

相反，产品经理会这样撰写需求：

“让已认证的客户能够冻结和解冻卡片，记录每项操作以供审计，并在操作发生时通知客户。”

工程人员会根据该需求着手实施。

最终会产出：

• API
• 数据库变更
• 业务逻辑
• 单元测试
• API测试
• 基础设施变更
• 文档

这个过程可能只需几分钟。

现在，AI DevSecOps平台开始发挥作用。

它发现该人工智能在新的接口上遗漏了必要的授权检查。

安全代理：阻止。

它还发现新引入的一个开源库存在严重的已知漏洞。

供应链策略：阻止。

编码代理会替换为更安全的依赖项。

再次进行测试。

测试代理：通过。

平台确认加密、日志记录和身份验证功能均已启用。

合规策略：通过。

该应用被部署到测试环境。

通过合成交易来模拟实际使用情况。

运行时验证：通过。

采用金丝雀发布策略，将少量实时流量，比如5%，引导至新版本。

监控结果显示错误率并无异常。

流量会逐步增加，直至覆盖所有人。

该功能现已上线。

整个流程会留下完整的审计轨迹：

需求 → AI智能体 → 代码 → 依赖项 → 测试 → 安全决策 → 批准流程 → 部署 → 运行时证据

这就是AI DevSecOps的实际应用。

有趣的是……

生成代码其实是最简单的步骤。

真正有价值的是那些能够准确回答以下问题的机制：

这款软件真的可以投入生产了吗？

更大的变革

很长一段时间里，关于软件工程中AI的讨论大多集中在一点上：开发人员的产出。

AI能让写代码的人快多少倍？

那个问题似乎已经显得过于局限了。

有一个更重要的问题值得更多关注：

当开发软件不再成为稀缺资源时，会发生什么？

一旦代码变得充裕，各组织真正需要的是一种能够在代码编写的同时建立信任的方法。

这意味着需要进行测试、保障安全、管理软件供应链、实施治理机制、自动执行政策、自动化部署、监控生产环境中的系统、追踪人工智能生成内容的来源，而且越来越多地需要在不等待人工干预的情况下解决问题。

综合起来，这些便构成了下一代DevSecOps。

人工智能在软件工程早期的应用主要在于帮助人们更快地编写代码。

接下来的阶段则是让人类与人工智能代理能够安全地共同运营整个软件工厂。

从这个角度来看，DevSecOps并非仅在开发之后负责清理工作的功能。

DevSecOps成为了整个人工智能驱动的软件工厂所依赖的控制平面。