衡量工信部“人工智能+软件”方案的成效，需要一个证据单位：验收通过的变更

2026 年 9 月 11 日，工信部官员和软件行业代表出席“人工智能+软件”专题新闻发布会。照片由《每日经济新闻》记者张锐拍摄；本文所用版本由已发布原图缩放而成。[3]

中国为编程 AI 的普及定下了一个规模庞大的目标。到 2028 年，工业和信息化部提出让高水平智能编程工具和开发平台覆盖 20,000 家规模以上软件企业。同一方案还提出，在软件企业建设 100 个智能化改造项目，在重点行业遴选 100 个智能体软件典型应用，培育至少 5 个高质量开源项目，并建设至少 15 个基础软硬件适配中心。[1]

这些目标显示出政策雄心和大规模推广能力。至于生成的补丁进入真实代码仓库后能否经受考验，目标数字没有给出答案。

衡量进展，更有用的单位是一项验收通过的变更：改动范围明确、出处有记录，测试和策略检查记录随附；审查者理解剩余风险，发布状态可监测，变更也能回滚。工信部 9 月方案没有把它列为一项指标；本文根据方案自身的架构提出这个分析单位。方案把编程工具同代码仓库和云服务连接起来，将代码质量和研发效能纳入政策支持的考量，要求安全测试覆盖整个生命周期，并对 AI 生成代码实施访问控制和安全审查。[1][2]

区分这两种尺度十分重要，因为“覆盖 20,000 家企业”衡量的是软件供应链的入口。价值要到另一端才会显现。

覆盖目标与绩效结果之间仍有一段距离

这份以工信部 2026 年第 209 号文件印发的方案，把软件生产方式智能化变革列在六项重点任务之首，并以智能编程作为首项工作。方案要求发展拥有项目级端到端开发能力、由智能体驱动的工具，并同代码托管平台、云服务和开源社区集成。方案还鼓励地方主管部门把采用智能编程后的代码质量、研发效能等实效，作为利用现有渠道支持软件企业的重要依据。[1]

这比单纯要求采购编程助手席位更有实质内容。然而，公开文件没有界定企业达到何种状态才算“覆盖”。文件没有说明，开通一个账号、达到月活跃用户门槛、覆盖一定比例的代码仓库，或经核验确认工具已贯穿整个开发生命周期，哪一种才算达标。文件也没有公布代码质量或研发效能的共同基线。[1]

因此，两种差异很大的实施方式都可计入标题所说的覆盖目标。浅层实施中，供应商接入工具，报出许可证或用户数，便算完成采用。深入实施则会改变一项工作从需求流向代码、测试、审查、部署、事件响应和维护的方式。前一种扩张很快，经济收益仍然未知；后一种留下记录所需的时间更长，却能说明 AI 究竟缩短了工作时间，还是把工作转移到了别处。

工信部配套解读更接近深入实施。解读把智能编程写入需求分析、代码生成和测试验证各环节，还提到代码审查和 AI 安全等新岗位，没有把生成代码直接视作成品。[2] 方案要求用代码质量、研发效能等实际结果检验应用成效，并重塑软件开发流程。[1] 这些目标到了验收关口，才转化为能够衡量的结果。

编程模型位于一套更长技术栈的起点

从提示词到补丁的演示，画面里只剩一项请求和一段代码。企业中的一次变更至少依赖五层系统。

第一层是生成层：模型、编程客户端、智能体运行时、检索方法和工具版本。供应商可以只改进其中一项，其余部分保持原状。即使产品名称保持不变，模型别名仍可改指其他版本；因此，只记下助手品牌，很难复现当时的结果。

第二层是上下文与权限层。工具接触的内容包括源文件、问题单、构建日志、内部文档、密钥等敏感信息和依赖项元数据中的一部分。工具身份所获权限决定了它能否读取代码仓库、创建拉取请求、运行构建或部署制品。自主程度越高，工具能够完成的有用任务越多；一条受攻击者操纵的指令或一份错误计划所能影响的范围也越大。工信部明确要求对开发工具和代码仓库实行访问控制，并防范恶意指令注入。[1]

第三层是变更产物。补丁需要说明用途，关联对应的需求或缺陷，并留下足够的溯源信息，以区分人工编写、AI 建议和智能体执行的内容。完整保存每条敏感提示词并非溯源记录的前提。一份精简凭据可以把变更同工具及模型版本、获准访问的代码仓库范围、相关输入的引用，以及负责提交审查的人员关联起来。

第四层是验证层：构建、单元测试与集成测试、静态分析、依赖项与许可证检查、安全审查；在需要验证行为时，还要加入能够实际运行的验收测试。工信部要求企业用大模型和编程工具发现漏洞、识别缺陷、划分风险等级，同时把智能安全测试嵌入软件开发全过程。[1] AI 因而同时生产和检查代码，两项判断也会相互影响：补丁与测试若源自同一处误解，测试仍会确信错误行为正确。

第五层是发布层。审查者接受剩余风险，变更合并到指定分支，构建结果成为能够部署的制品，上线后的数据再决定变更是否保留。功能开关、分阶段发布、监控、事件关联和回滚，把一次代码审查决定转化为责任可追溯的运行决策。缺少这一层时，“验收通过”有时只表示一份表面合理的代码差异已进入主分支。

这条链条由此产生几组能够如实反映流程的分母：生成的变更、提交审查的变更、验收通过的变更、已经部署的变更，以及经过观察期后继续保留的变更。把它们全部归入“AI 编写的代码”，也就无法看出工作和失败落在哪个环节。

凭据应随补丁一同流转

面对常规变更，这些证据原本分散在问题跟踪器、提交记录、持续集成系统、审查日志、制品注册库和部署平台里。编程智能体参与后，将各处记录串联起来尤其重要。一份有用的验收凭据应当关联：

需求、代码仓库、基准修订版本，以及模型和工具版本；
补丁，以及一并生成的迁移脚本、测试或配置；
具体运行了哪些检查、所用环境及结果；
安全、依赖项、许可证和策略检查中发现的问题；
审查者的决定，以及重要的改判或豁免记录；以及
构建制品、上线过程、监测窗口和回滚路线。

这套证据架构由本文提出，中国尚未公开将其作为报告模板。美国国家标准与技术研究院（NIST）的安全软件开发框架可以作为外部参照。NIST 将安全开发实践分为组织准备、软件保护、安全软件生产和漏洞响应四类；其面向 AI 的社区配置文件，又把这种生命周期视角延伸到生成式 AI 和双用途基础模型。[6][7] 工信部没有表示将采用 NIST 这套体系。此处只比较一点：两者都把保障工作贯穿软件生命周期；若只扫描补丁的最终文本，关键环节便会缺失。

这份凭据还能避开一个衡量陷阱。假设助手把最初的编码时间减少 30 分钟，却增加 20 分钟审查时间、15 分钟测试修复时间，后续回滚工作也略有增加。在补丁生成时便停止计量的仪表板会显示一项收益。按变更建立的记录才能说明端到端耗时是否缩短、变化出现在哪类任务中，又伴随怎样的质量代价。

建立这种记录并不要求按照验收通过的 AI 产出给开发者个人排名。个人排名会鼓励细小、容易批准的改动，也会抑制必要的拒绝。更合适的比较单位，是团队在一类稳定任务上的整体表现，例如某项服务中的缺陷修复。评估时，应同该团队采用工具前的基线比较，并把审查负担、下游质量和耗时并列考察。

外部证据凸显了分母问题

两项受到广泛讨论的 2025 年研究指向不同方向，也正好说明覆盖数量不足以说明实际成效。

Google Cloud 的 2025 年 DORA 研究收集了近 5,000 名技术从业者的资料。结果显示，90% 的受访者使用 AI，超过 80% 感到生产率有所提高，30% 对 AI 生成的代码信任度很低或完全不信任。统计分析发现，AI 采用程度较高与交付吞吐量和产品表现较高相关，同时也与较低的交付稳定性相关。[4] 这些结果来自观察性关联与自我报告，无法证明 AI 导致了其中任何一项结果。它们仍显示，在同一项调查里，交付提速与稳定性改善没有同步出现。

METR 开展了一项随机对照试验，16 名经验丰富的开源开发者在自己熟悉的成熟代码仓库中完成 246 项任务。在允许使用 2025 年初 AI 工具的条件下，开发者完成任务所花的时间增加了 19%；他们事前预计 AI 会提升速度，试验结束后仍相信自己变快了。[5] 这项研究设计严谨，适用范围却很窄：参与者人数少，研究范围限于特定代码仓库和时间段，所用工具此后也有更新。由此无法推导出 2026 年编程 AI 会拖慢中国软件企业。相关启示限于一点：有经验的用户对速度的感受，仍须由按任务计时的结果判断。

两项研究放在一起，说明单一、通用的生产率系数难以成立。工具版本、对代码仓库的熟悉程度、任务类型、测试质量、审查惯例和部署风险都会影响结果。国家级计划只有保留比企业计数更细的证据，才能发现这些差异。

智能体把验收单位从变更扩展到行动

方案还涵盖编程助手之外的智能体。方案要求发展安全可靠、行为能够验证的工业智能体，尤其关注它们同工业控制软件或核心业务系统交互的情形；还提出建设智能体应用商店和 Skills（技能）仓库，实行规范的上架审查与运营管理。[1] 在 9 月 11 日的发布会上，中国电子信息产业发展研究院朱敏从技术、产品和应用三个层面介绍智能体计划，相关要求包括可验证的工业行为，以及经过上架审查的 Skills 市场。[3]

对于智能体，验收单位要从代码变更扩展为一项经过授权的行动。凭据必须标明智能体、所接任务的目标、获准使用的工具和数据、实际发起的调用、批准范围、副作用和恢复路径。读取目录的技能与修改生产计划的技能不能等同看待。商店认证标识若忽略权限、依赖项版本和访问遭拒时的行为，只能认证封装形式，无法证明运行安全。

同样的原则也适用于方案拟建设的面向代码生成、智能测试和运维的高质量数据集。数据集即使能够改进模型，仍不排除其中存在许可证不兼容、密钥等敏感信息、重复的评测样本，以及陈旧且存在漏洞的代码模式。它的供应链凭据需要记录来源、采集日期、许可与同意的依据、转换过程、去重规则、访问限制与已知排除项。工信部方案要求开展数据标注、清洗、合成和治理，并借助开源社区及代码托管平台流通共享。[1] 这些记录是否会跟随发布的数据集流转，决定了下游用户能够核验到何种程度。

怎样让 2028 年目标更易解读

方案提出制定智能编程能力成熟度分级和评估标准，完善软件产品与服务的质量管理和评价规范，并制定贯穿智能体开发、部署和应用环节的安全管理规范。[1] 这些后续标准和规范可用于衔接全国覆盖规模与项目级结果。

以下四项披露可以让进展更容易解释：

定义覆盖。 公布符合条件的企业总数，以及从安装转为实际使用所需的活跃度门槛；分别统计试用、活跃团队和生命周期集成。
报告验收漏斗。 针对稳定的任务类别，披露提交审查、遭拒、验收通过、已经部署，以及观察期后继续保留的变更数量，避免使用生成代码行数充当结果。
核算审查尾部成本。 在首次提交变更所需时间之外，同时跟踪审查者用时、返工、测试修复、安全检查发现的问题、上线后暴露的缺陷、事件和回滚。
把结果绑定到版本。 保留每项已报告改进背后的模型、工具、政策、代码仓库范围、评估窗口和基线。汇总数据可以在保护企业和开发者隐私的同时，继续说明具体衡量了什么。

这些属于本文的分析建议，方案本身没有作出相应承诺。有了这些披露，100 个智能化改造项目可以在精心打磨的演示之外，留下范围明确的案例。每个案例包括一项具体工作流程在采用工具前后的对照、一条明确说明的验收链、一项质量结果，以及该结果成功迁移或未能迁移的条件。

工信部提出的 20,000 家企业目标有其价值。工具会在真实使用中改进，规模较小的企业需要接入集成基础设施，国家级计划也要选定统计对象。不过，覆盖规模位于这条供应链的起点。代码生成转化为软件生产的节点，是一项验收通过的变更：它可供审查和测试，归属可追溯，并能部署、监测和回滚。

cronfeed.work