Devin开始主动查代码风险

Devin把手伸向了代码扫描

Devin近期推出Code Scans，开始主动扫描整个代码库中的安全、性能、测试覆盖、死代码和可访问性问题，并把发现的问题直接交给Devin修复。截至2026年9月18日，这项能力已经出现在Devin官方博客、产品文档与API文档中。

**Code Scans是一套由AI Agent驱动的代码库扫描与修复系统。**它不只是运行一遍静态分析规则，而是尝试理解代码上下文、定位值得处理的问题，再让Devin继续完成修改、测试与验证。

这意味着Devin正在从“接到任务后写代码”，转向“主动寻找任务并完成任务”。过去，开发者需要告诉Agent实现一个接口、修复一个Bug或者迁移一组模块；现在，Agent可以先检查仓库，生成一批风险项，然后继续承担修复工作。

这次更新最值得关注的地方，不是Devin又增加了几个扫描类别，而是AI编程Agent的工作边界变了。代码生成解决的是“怎么把需求写出来”，Code Scans瞄准的则是“一个长期演进的代码库接下来应该修什么”。

Code Scans具体扫描什么

**Code Scan的核心产物不是一段补全代码，而是一组带上下文的代码发现项。**按照Devin目前公开的文档，扫描范围包括安全风险、性能问题、测试覆盖不足、死代码、可访问性缺陷以及其他可配置的代码质量问题。

| 扫描方向 | 主要寻找的问题 | 典型场景 | 后续动作 | |---|---|---|---| | 安全 | 不安全的数据流、权限处理、输入校验及潜在漏洞 | 上线前审计、遗留系统排查 | 生成修复任务并验证改动 | | 性能 | 重复计算、低效查询、阻塞路径和不必要的资源消耗 | API延迟优化、批处理提速 | 修改实现并运行相关测试 | | 测试覆盖 | 缺失测试的关键逻辑和高风险分支 | 合并前检查、旧模块补测试 | 生成测试并执行验证 | | 死代码 | 无引用函数、废弃分支和长期未使用模块 | 大型仓库清理、重构准备 | 删除代码并检查依赖关系 | | 可访问性 | 前端交互、语义标签和辅助技术兼容问题 | Web产品合规与体验改进 | 修改组件并进行回归检查 | | 自定义扫描 | 由团队规则或Profile定义的问题 | 内部规范、框架迁移、架构治理 | 按组织标准创建修复任务 |

**安全扫描与非安全扫描在配置方式上存在区别。**Devin文档显示，通过Code Scans API启动非安全类扫描时，需要传入与扫描类型匹配的Profile ID；如果scan_type与Profile不匹配，或者非安全扫描没有提供Profile，服务会返回HTTP 400。

**Profile是用于定义扫描目标、规则和运行方式的配置对象。**它让团队可以把“寻找性能问题”进一步收窄为更具体的工程要求，而不是让模型漫无目的地浏览仓库。

Devin还提供了不依赖Web应用的Code Scans API，企业可以通过API启动扫描、轮询状态并读取发现项。文档中已经出现组织级扫描、Profile校验和摄取模式等设计，这说明Cognition并不只想把它做成一个供个人开发者点击使用的页面功能，而是希望Code Scans进入企业现有的工程流水线。

真正的变化是Agent开始自己找活

**Code Scans把AI Agent从执行者变成了任务发现者。**传统编程助手通常等待开发者给出明确指令，而扫描系统会先遍历仓库、识别问题、排序风险，再产生可执行任务。

这看起来只是工作流前移了一步，实际影响却更大。企业软件维护中，大量成本并不来自新增功能，而是来自没人愿意碰的遗留模块、逐年下降的测试覆盖率、没有进入待办列表的性能问题，以及长期存在却未触发事故的安全缺陷。

普通代码补全工具对这类问题帮助有限，因为它们依赖开发者先打开文件、选中代码并提出问题。自主Agent则可以连续工作数小时，读取多个目录、追踪调用关系、运行命令并修改多个文件，但自主程度越高，错误扩散的半径也越大。

Code Scans试图形成一个闭环：先扫描代码库，产生发现项，再由Devin理解相关模块、实施修改、运行测试并提交变更。相比只给出一条告警，这种体验更接近给团队增加了一名专门处理技术债的工程师。

它和传统SAST不是一回事

**静态应用安全测试（SAST）是在不运行程序的情况下分析源代码或中间表示，以发现潜在安全缺陷。**CodeQL、Semgrep以及大量商业安全产品都属于这一技术范畴，它们的优势是规则明确、结果可复现，并且适合嵌入持续集成流程。

Code Scans与传统SAST的差异，主要不在于是否能发现某个漏洞，而在于发现问题之后能否理解业务上下文并完成跨文件修复。规则引擎擅长回答“这里是否符合某种危险模式”，Agent更擅长继续回答“在这个仓库里应该怎样改，改完会影响什么”。

| 产品或方式 | 问题发现方式 | 上下文范围 | 自动修复能力 | 更适合的任务 | |---|---|---|---|---| | Devin Code Scans | Agent分析与可配置扫描 | 整个代码库及相关任务上下文 | 可继续交给Devin修改和验证 | 技术债治理、跨文件修复、持续维护 | | GitHub CodeQL | 查询代码语义数据库 | 跨文件数据流与调用关系 | 可结合其他工具生成修复建议 | 高可信安全扫描、供应链流程 | | Semgrep | 规则匹配与数据流分析 | 文件、模块及部分跨文件上下文 | 以规则和辅助修复为主 | 快速规则落地、团队自定义检查 | | Snyk等安全平台 | SAST、依赖与供应链分析 | 代码、依赖和云配置等 | 提供建议及部分自动修复 | 企业安全治理与依赖风险管理 | | Cursor、Claude Code等Agent | 由用户提出任务后分析代码 | 当前会话和已授权仓库 | 较强，但通常需要用户先下达任务 | 功能开发、调试与重构 | | 人工代码审查 | 工程师理解业务与变更 | 取决于审查者经验 | 由工程师修改 | 架构判断、业务逻辑与责任确认 |

**Code Scans目前不能被简单视为传统安全扫描器的替代品。**官方公开材料强调了它能发现并修复多类问题，但没有在参考信息中公布误报率、漏报率、支持语言数量、漏洞基准成绩或与CodeQL、Semgrep的对照测试。

缺少这些数字意味着外界暂时无法判断它在纯检测能力上是否领先。一个Agent能够写出很有说服力的问题描述，并不等于这个问题一定真实存在；同样，一个补丁能够通过现有测试，也不等于它没有改变隐含业务行为。

Code Scans为什么可能比单纯告警更有用

**代码扫描产品最常见的问题不是发现不了风险，而是发现之后没人处理。**大型仓库一次扫描可能产生数百甚至数千条告警，其中相当一部分缺少业务优先级，最终只会堆积在安全后台或持续集成日志里。

Agent的价值在于压缩从告警到补丁之间的距离。它可以读取问题所在模块，寻找相邻实现和现有测试，再按照仓库原有风格生成修改，而不是只提供一段脱离上下文的修复建议。

以测试覆盖扫描为例，单纯报告某个文件覆盖率不足并不困难，真正费时间的是判断哪些未覆盖分支值得测试、如何构造依赖、应该使用仓库里的哪套测试工具，以及新增测试是否会变得脆弱。Devin如果能把这些步骤连续完成，节省的就不只是写几行测试代码的时间。

以死代码扫描为例，文本搜索很容易误判动态引用、反射调用和配置驱动的入口。Agent虽然同样可能出错，但它至少可以继续检查路由配置、构建脚本、测试和运行日志，再决定是否删除相关模块。

以性能扫描为例，真正有价值的发现通常不是“这里有一个循环”，而是“这个循环位于高频请求路径，并且会对同一批数据进行重复查询”。这类判断需要调用链、数据规模和运行场景，已经超出了简单语法规则的能力范围。

自动修复也会放大自动化风险

**扫描与修复由同一个Agent完成，会同时提高效率和风险。**如果检测结果本身有误，Agent可能基于错误前提修改多个文件；如果测试覆盖不足，它还可能把“测试通过”误当成“行为正确”。

Devin本身拥有较高的自主性，可以读取、写入和修改仓库文件，并根据任务运行命令。与只给出行内建议的代码补全产品相比，它的人工确认次数更少，因此一次错误决策可能影响更大的代码范围。

企业在接入Code Scans时至少需要保留以下控制点：

• **扫描权限与修改权限分离。**默认允许Agent读取仓库并生成发现项，不应自动获得生产分支写入权限。
• **所有修复通过独立分支或拉取请求提交。**任何跨文件修改都应该保留可审查的差异记录。
• **限制一次任务的作用范围。**安全修复、性能重构和死代码删除不宜混在同一批变更中。
• **使用独立工具复核关键漏洞。**高风险安全问题仍应由CodeQL、Semgrep、依赖扫描器或人工审计交叉验证。
• **在隔离环境运行命令。**仓库脚本、测试依赖和构建流程本身可能包含不可信行为。
• **监控修复接受率与回滚率。**如果Agent生成的补丁频繁被拒绝或回滚，扫描发现再多也没有实际价值。

**真正值得跟踪的指标不是扫描出了多少问题，而是多少问题被证实、修复并安全上线。**对于Code Scans，企业至少应该记录有效发现率、误报率、补丁接受率、回归测试通过率、人工审查耗时和上线后回滚率。

如果扫描产生100条发现，但只有10条被工程师确认，其中5条补丁能够合并，那么数量庞大的扫描报告并不代表生产力提升。反过来，如果Agent每周只发现20个问题，却有15个能被快速修复，它对团队的实际价值反而更高。

企业场景比个人开发更值得关注

**Code Scans最有潜力的使用场景是大型遗留仓库，而不是从零开始的小项目。**新项目通常结构清晰、上下文有限，开发者用常规Agent已经可以快速检查代码；大型企业仓库则可能包含数百万行代码、多个框架版本和多年累积的技术债。

这也是Devin选择把扫描能力做成组织级API的原因。企业可以把扫描安排在固定周期、特定分支或大型迁移前后运行，再把发现项送入现有工单系统和审查流程。

官方文档还显示，组织策略会影响扫描模式；当组织只允许摄取模式扫描，而请求没有提供对应的摄取模式Profile时，接口会返回HTTP 403。这类权限校验虽然不起眼，却说明Code Scans正在按企业治理产品而不是单次演示功能设计。

不过，企业是否愿意长期使用，还取决于三个尚未完全透明的问题：扫描一次大型仓库需要多长时间、会消耗多少计算资源，以及代码和扫描结果如何存储与隔离。参考资料没有给出Code Scans的独立价格、性能基准和完整数据保留策略，因此当前还无法对总体成本作出可靠判断。

AI编程竞争进入代码库运营阶段

**AI编程产品的下一轮竞争不会只比谁写代码更快，而会比谁能持续维护整个代码库。**代码补全已经成为基础能力，Agent执行终端命令、修改多文件和创建拉取请求也在迅速普及，单次开发任务之间的差异正在缩小。

代码扫描提供了新的任务入口。过去Agent必须等待人类派活，现在它可以通过安全检查、性能分析、测试覆盖和代码质量扫描，持续生成自己的工作队列。

这也会改变AI编程产品的商业逻辑。按补全次数或对话次数收费，更像销售一个开发工具；按仓库持续扫描、发现问题并交付可合并补丁，则更接近销售一套自动化工程能力。

Cognition的方向很明确：Devin不只想成为一个更自动化的IDE，而是希望覆盖软件工程中的任务发现、代码修改、测试验证和交付闭环。Code Scans正是这个闭环里缺失的一环。

现阶段应该怎样评价Code Scans

**Code Scans是一个方向正确、但仍需要真实数据证明效果的产品更新。**它抓住了AI编程落地中的关键矛盾：生成代码已经很快，发现值得修的问题、验证修改没有副作用，才是企业软件维护中更昂贵的部分。

它相对传统扫描器的优势，是能够把发现项继续转化为跨文件修复；它相对普通编程Agent的优势，是不再完全依赖人类发现问题和编写提示词；它最大的风险，则是把模型判断、代码修改和测试验证集中在同一个自动化系统里。

短期看，Code Scans最合理的定位不是“替代安全团队”，而是一个自动化的代码库巡检与修复助手。它适合清理技术债、补充测试、处理低风险缺陷，并为工程师准备可审查的修改方案。

长期看，如果Devin能够公开可重复的扫描基准、降低误报，并证明Agent生成的补丁拥有较高合并率，Code Scans可能比单纯的代码生成更接近AI软件工程的最终形态：系统不再等待人类逐项下达任务，而是主动观察代码库、提出工作、完成修改，再把关键决策交还给人类。

参考来源

• OWASP Cheat Sheet Series：OWASP维护的安全开发实践资料，可用于核对输入校验、身份认证、权限控制等常见安全问题。
• Semgrep开源项目：主流静态分析工具的开源仓库，可作为理解规则扫描、数据流分析与自定义代码检查的参考。
• OpenSSF Scorecard：用于评估开源项目安全实践的自动化工具，可作为仓库级安全治理的对照方案。
• GitHub CodeQL：GitHub维护的代码语义分析与安全查询项目，可用于理解传统SAST和跨文件数据流分析能力。

说明：本文事件信息主要依据Devin官方博客、Devin Code Scans产品文档及Devin API文档整理；因参考链接域名限制，文末未列出相关官方网站链接。