ARTICLE · 1009412
工信部部署软件行业高质量数据集 企业怎样把研发记录变成可验证的工程能力
工信部部署软件行业高质量数据集 企业怎样把研发记录变成可验证的工程能力
代码生成得更快，为什么测试、审查和上线确认仍然慢？判断一次软件智能化改造是否有效，不能只看开发人员用了多少AI，也要看他们还需要花多少时间证明这些输出值得采用。 工信部此次部署软件行业高质量数据集，给数据治理从业者提供了一个具体切入点：把需求、代码、测试与运行记录组织成有上下文、可复现、可验证的任务材料，帮助企业减少错误交付和重复确认。这项工作既不能被采购编程工具替代，也不必一开始就扩张成全公司的数据平台项目。 本文结合《“人工智能+软件”专项行动实施方案》，讨论三个问题：哪些研发记录值得沉淀；同一批记录怎样支撑不同AI任务；企业凭什么决定扩大投入，而不是只看演示效果。 这份文件的文号为工信部信发〔2026〕209号，成文日期为2026年9月2日，发布日期为9月11日。工信部信息技术发展司同日发布了官方解读。成文日期和网站公开日期应当区分。工信部通知 文件第十五项明确部署“建设软件行业高质量数据集”，列出的关键场景包括代码生成、智能测试、智能运维，并提出完善标注、清洗与合成等工具链，引导企业提升软件工程数据治理能力。（《实施方案》第六部分，第十五项） 如果只把这条理解成“收集更多代码”，就缩窄了政策中的工作对象。测试预期从哪里来，历史缺陷怎样复现，运维诊断能看到什么信息，都不由代码文本单独回答。 把相关条款放在一起，企业的实施问题会清楚很多： 下图将政策部署与企业需要回答的问题对应起来。右侧是本文的实施解读，不是新增的官方验收标准。 
文件提出的2028年目标，包括推广应用覆盖2万家规模以上软件企业、累计组织实施100项智能化技改项目、在重点行业打造100个智能体软件标杆应用。这些是阶段目标，不能当作已经完成的产业成绩，也不能推导出每家企业都能获得补贴。（《实施方案》第一部分） 对数据治理工作的直接启示是：治理成果要能解释某项研发任务如何变得更可靠、更省时，以及新增了哪些风险。文件没有规定企业必须使用某一种本体、知识图谱产品或特定平台，本文后面的做法属于实施建议。 用一个假设案例展开。某创建订单接口在首次请求成功写入订单后，响应未能及时到达客户端。客户端重试，服务端又创建了一笔订单。本例不对应真实企业，也不包含任何模型实测结果。 产品负责人先确认业务规则：在约定的有效期内，同一客户使用同一个幂等键、提交相同请求内容，应当得到同一订单的结果。幂等键可以理解为一次业务操作的唯一凭据，它用于识别重复提交。相同键却携带不同内容，应拒绝或按明确规则处理，不能随意覆盖原订单。 这里已有一个重要区别：系统收到两次请求，不代表客户希望创建两笔订单。模型如果不知道这条业务约定，即使能把代码写通，也可能实现错误的行为。 假设开发人员增加了“先查询有没有，再决定是否创建”的逻辑。连续点两次测试通过，但两个请求同时到达时，都可能在写入前查到“没有”，随后各创建一笔。这个例子说明，功能描述正确、代码可以运行、某个测试通过，是不同层面的证据。 要把这次修复沉淀为有用材料，至少需要连起几件事：当时的接口约定、缺陷版本、重现步骤、经审查的修改、验证环境，以及能区分修复前后的测试。数据库约束、事务边界、失败重试策略可能影响实现，不能只留下一个补丁文件。 反过来，也不应把所有日志原样塞进去。需要的是能证明“同一次操作被重复处理”的关联信息，而非完整客户身份、密钥或无关交易明细。完整性应围绕判断所需的证据检查，不等于无差别保存一切。 由此可以把一条候选材料分成三种状态： 这比把所有“已关闭缺陷”统一标为优质样本更谨慎。缺陷关闭说明流程状态发生了变化，未必证明修复正确，更不证明它适用于别的版本。 文件把代码生成、智能测试、智能运维并列提出，有实际意义：它们依赖的输入、允许的动作、正确性的证明方式都不同。 先用同一案例比较三者，再看各自需要怎样的证据。 
对代码修复任务，模型需要看到待修复版本、接口约定和当时可获得的故障描述，产出的是补丁候选。历史上经确认的修复，可以作为学习材料或评估参考，却不能提前放进待测模型可检索的目录。 对测试生成任务，重点变成能否把业务约定转成检查。模型应提出能暴露缺陷的请求序列与预期结果。它可以生成串行重复、并发重复、同键不同内容等测试，但这些测试的预期必须由接口约定支撑。不能因为代码现在返回什么，就自动把什么写成正确答案。 对运维诊断任务，输入则是故障发生时已经可见的日志、监控、部署版本和近期变更。合理输出可以是“怀疑重试触发重复创建，并建议核查某段调用链”；在没有充分证据时，不应直接宣布根因，更不能顺手删除订单。 采集可以共用来源，样本必须按任务重新组织。企业不一定因此维护三份相互割裂的数据，而可以保存一个可追溯的证据集合，再按用途生成不同的数据视图。 这里的“高质量数据集”也不只指用于训练模型的数据。用于检索的工程案例、独立评测材料，以及运行时按权限提供的上下文，均可能参与应用，但用途不能混淆。同一条材料用于训练时可以包含输入与经确认的答案；用于评测时，答案和隐藏检查必须与模型可见输入隔离。 对于刚起步的企业，可以先验证“提供准确上下文是否比现有方式更有效”，再决定是否需要微调模型。业务规则尚不明确时，增加训练轮次不会替企业把规则定下来。 研发记录分散在需求平台、代码仓库、测试系统和运行日志中。接通这些系统，只解决了读取问题；治理还要决定它们能否被放在一起解释。 在本例中，一份最小的任务档案可以围绕缺陷编号建立关联：需求版本限定预期，代码提交确定对象，测试记录提供验证证据，部署标识说明环境，运行反馈提示修复后的表现。关联不能只靠标题相似或模型语义判断，关键连接应有提交记录、关联编号或人工确认依据。 如果使用本体建模，可以将它理解为明确“需求、变更、缺陷、测试、部署”是什么，以及彼此允许有哪些关系。例如，“测试验证某项需求”与“测试在某个版本执行成功”是两种关系。前者说明检查意图，后者说明一次执行结果，混为一谈就会误以为一次通过可以永久证明需求满足。 先统一这些关系的含义，再决定是否采用图数据库。只有几个对象的试点，用结构化清单和稳定编号也能开始；工具选择不应先于问题判断。 时间边界尤其容易被忽略。假设要评估AI在故障首次报出时能否定位原因，就不能给它后来补写的根因总结，也不能让它检索到修复后的代码。否则，评估的是看答案后的解释能力。 下图以“故障首次报出”为界说明输入与后续证据怎样分开；这是本例的评测设计，不是所有任务统一采用的截断时间。 
这条界线也要求企业保留历史版本。拿今天的接口文档去解释过去的实现，可能把当年合理的行为误判为错误；拿历史规则指导今天的代码，又可能放过已经变更的要求。 涉及外部模型、共享数据或开源材料时，还要单独检查用途边界。内部能读取代码，不代表可以向外部服务上传；代码公开可见，也不代表可以忽略许可与使用条件。工程上应保留来源、适用许可、批准用途和处理记录，具体判断交由相应责任人确认，不能靠一次自动脱敏得出全面合规结论。 对这个案例而言，脱敏还不能破坏请求关联。若每行日志把同一幂等键替换成不同值，敏感字段虽然“去掉了”，重复提交的证据也消失了。应在获准范围内保持分析所需的一致映射，同时控制映射表权限。 合成数据也遵循相同原则。可以按已确认规则构造并发请求、延迟响应和异常分支，用于增加检查覆盖；但要标明合成来源，确认生成环境和断言有效，不能把合成事件说成生产上真实发生过的故障。 软件工程数据有一个优势：部分结果可以通过执行检查。这个优势也容易造成误判，以为只要测试全绿，就能证明数据和模型都可靠。 在重复订单案例中，如果测试只检查“返回成功”，重复创建仍可能漏过。更有效的断言应检查订单数量、同键请求对应的订单标识，以及相同键携带不同内容时是否符合约定。预期结果必须先由规则确定，再由测试表达。 可以先做两项反向检查：测试在已知缺陷版本上能否稳定暴露目标问题；在经确认的修复版本上能否通过。如果两边都通过，测试可能没有触及缺陷；如果两边都失败，则可能是环境、依赖或断言有问题，不能简单算作模型修复失败。 这仍不足以完成验收。只复现当年那一次请求，可能让方案过度适配一个例子。需要由独立验证人员保留未向生成过程展示的变化条件，例如并发到达、响应丢失、同键参数变化，以及正常的不同键请求。最后一种用于检查修复是否误伤正常业务。 数据隔离也应按缺陷家族和代码演化关系检查。同一个问题在多个分支上的近似补丁、同一测试的改名副本，不宜分别混入学习材料与独立评测。按文件随机拆分，未必能隔离这些关系。具体分组粒度由要证明的能力决定：验证本项目新版本，与验证跨项目迁移，不能共用一个含糊结论。 同时要明确验证环境的权限和资源边界。执行生成代码本身存在风险，测试应在隔离环境中运行，限制网络、凭据和资源使用；出现异常外连、越权访问或破坏性行为应中止，而非只记录一个低分继续运行。 为了避免结果好看却无法解释，评估记录至少保留三类信息： 并发测试未触发错误，不能证明所有并发情况均安全。涉及事务、唯一性约束等关键设计时，仍需要代码审查和针对性验证。通过一批评测，应表述为“在已说明的范围内达到要求”，而不是获得永久可靠的资格。 文件第九项提出技能包资源库等建设，第十九项同时部署智能体身份、可信互联、数据安全和行为管控等安全技术。把这两项结合起来看，企业需要沉淀的除了知识，还有可控的执行方式。（《实施方案》第四、七部分） 在本例中，一个“重复请求缺陷辅助排查”技能包，可以规定读取哪些接口约定、如何查询获准日志、怎样关联版本、何时生成测试候选、缺少证据如何提问。它还应写清输出格式与失败条件，让使用者知道何时不能继续。 但技能包本身不是权限系统。即便文档写了“不得修改生产数据”，如果工具账号拥有写权限，风险仍在。读取日志、提交补丁、合并代码、部署上线，应按各自风险由真实系统实施授权，不能都交给同一个高权限身份。 一个合理的起步范围是：AI读取获准材料，在隔离环境提出候选修改和测试；开发人员审查补丁；独立验证人员检查行为；发布负责人决定是否上线。批准不能只剩一个“确认”按钮，还应能看到变更内容、验证结果、影响范围和回退条件。 如果版本不匹配、规则存在冲突、关键证据缺失，技能应停止推进或转人工。上线后发现异常，停止扩大使用，并由有权限的人员按预案处理。代码回滚不会自动撤销已经产生的业务数据后果：已经重复创建的订单需要业务核查和单独处置，不能将“可回滚”写成没有成本的安全承诺。 至于可信数据空间，它可以成为未来跨主体共享某些工程资源的协作选项，但本文件没有要求企业通过某个可信数据空间完成这些任务。不能为了连接热点，把一种可能的实施方式改写成政策指定路径。 最小试点可以只选择一个维护团队、一类反复出现且风险可控的缺陷、一个明确的软件范围。以本例为起点，先把辅助生成回归测试做好，再决定是否让AI提出修复候选；没有必要同时启动自主开发、自动部署与生产运维。 下面给出本文建议的角色分工和放行依据。企业可以合并岗位，但不能取消独立复核，也不应让“共同负责”掩盖最终批准人。 
试点启动前，应先冻结一版任务说明：输入范围、禁止动作、输出要求、结果判定方式和停止条件。对于这类接口，重复创建、跨客户串单等高风险行为，应在试点规则中明确为不可接受；不能用大量普通测试通过来抵消。其他指标的阈值应结合已有基线与风险确定，不使用政策并未规定的统一分数。 比较新旧工作方式时，要尽量控制任务难度、人员经验、可用工具和时间预算。既记录成功采用，也记录未采用、重新修改和环境失败。若只有较简单的任务使用AI，却拿全部人工任务作对照，得出的“效率提升”没有足够解释力。 管理层尤其应看每项通过验收的变更需要投入多少总工作。模型生成一分钟，工程师花更久查证和返工，并不一定降低交付成本；反过来，某次生成稍慢，但减少了反复定位，也可能有价值。总成本还应包括持续维护数据、执行测试和监控风险，不能只算模型账单。 不必预先承诺统一的提升比例。先观察通过率、审查修改时间、退回原因及新增风险，形成是否继续的依据。若多数失败来自接口规则未确认，应先补规则；若输入材料完整却仍频繁生成错误，应调整任务范围或工具方案；若环境无法重现，应先修复验证设施。不要把所有失败都转成继续购买数据的理由。 试点验收至少应留下四项可以再次使用的成果：按版本组织的任务材料、可重复执行的验证集、受控的工作流程，以及真实的成本和失败记录。这里所说的资产沉淀是企业管理与复用意义上的能力积累，不据此判断会计上的资产确认。 从这份文件出发，数据治理服务可以把交付对象进一步具体化：为某类研发任务恢复证据关系，建立持续更新的数据供给，让企业有能力判断工具是否值得采用。 这要求数据团队与研发团队各自承担明确责任。数据团队管理版本、关联、质量和可用范围，不能单方面决定业务行为；开发和产品人员确认规则与实现，不能把缺失上下文全部视为“模型不够强”；验证人员保留独立检查，安全人员确认数据与工具边界。治理平台负责把这些活动记录和运行起来，而不是代替负责人作决定。 交付范围也要带上持续维护约定：接口发生变化时，哪些样本需要复核；关键依赖升级后，哪些验证需要重跑；来源授权改变时，哪些材料必须停用；责任人离岗时，谁接手判断。否则，一批今天有用的样本，仍可能成为下一次错误的来源。 《实施方案》给出的机会，可以落实为一项很具体的工作：让企业过去解决过的问题，成为下一次可以检索、检验和受控复用的工程经验。高质量数据集在其中承担连接作用，但效果要在实际任务中证明。
一 第十五项为什么值得与技改和安全要求一起读
第二项将代码质量、研发效益作为支持智能化技改的重要依据，要求企业关注结果，而非只统计工具覆盖。 第七至九项涉及智能体工程能力、与既有软件系统融合、行为可校验，以及技能包和知识库等资源建设，意味着数据要进入实际工作过程。 第十一项强调持续服务和价值交付能力，第十九项关注生成代码审查、提示注入、代码仓库及工具访问等风险，说明上线之后仍有运营责任。
二 一个修复记录里到底缺了什么
事实齐全且能够重现，可以进入相应任务的数据准备。 结论可能正确，但版本或环境缺失，只能作为待核实线索。 描述与证据矛盾，退回调查，不由模型补写一个看似完整的故事。
三 同一次缺陷不能给三种任务发同一份材料
四 数据治理的重点是恢复关系和时间
五 能运行的测试不一定是可信的裁判
任务结果：问题是否解决，是否引入新的功能或安全缺陷。 证据状态：能够复现、环境失败、材料不足和结论存疑分别统计，不把未知强行归为正确或错误。 人工与资源成本：从准备材料到审查、修改、验证所花的总时间，以及模型调用、运行环境和维护成本。
六 从数据集到技能包 要补上授权和失败处理
七 智能化技改要验收一项工作而非一批调用量
八 数据治理团队可以交付什么新价值
延伸阅读