工信部发布“人工智能+软件”专项行动方案：到2028年覆盖2万家规模以上软件企业

工信部发布“人工智能+软件”专项行动方案，提出到2028年覆盖2万家规模以上软件企业，重点推动智能编程工具、智能开发平台、智能体软件标杆应用和软件企业智能化技改。对软件企业而言，这一政策信号并不只是增加一个产品方向，更意味着企业需要重新评估数据基础、研发工具链、智能体场景与项目交付能力之间的优先级。

政策重点从单点工具延伸到软件企业整体智能化

从公开目标看，“人工智能+软件”专项行动覆盖的并非单一产品类别，而是贯穿软件研发、产品建设和企业经营的多个环节。

一是推动智能编程工具应用。其核心价值在于辅助代码生成、测试、调试、文档编写和知识检索等研发工作，帮助研发团队减少重复劳动。对于软件企业来说，智能编程工具的价值不能只用生成代码的数量衡量，更应关注缺陷率、代码评审效率、测试覆盖和研发人员协作方式是否改善。

二是推动智能开发平台建设。相比单个开发工具，平台更强调数据、模型、开发环境、测试流程和部署能力的整合。企业如果只采购工具而没有统一的权限、知识库、代码规范和质量管理机制，往往难以形成可持续的研发收益。

三是推动智能体软件标杆应用。智能体并不等同于普通聊天机器人。它通常需要连接企业数据、业务系统和操作流程，能够围绕相对明确的任务进行理解、决策辅助或流程执行。软件企业既可以把智能体作为自身产品能力的一部分，也可以围绕行业客户建设可复制的解决方案。

四是推进软件企业智能化技改。这里的重点不只是把人工智能嵌入软件产品，也包括企业内部的产品规划、研发管理、客户服务、项目交付和运营流程改造。政策目标因此与企业的经营效率和交付能力直接相关。

企业首先要判断：短板究竟在哪里

不同软件企业的基础差异较大，不能简单按照“先上模型”或“先做智能体”的顺序行动。更实际的做法，是先识别当前最影响业务增长和交付效率的短板。

数据基础薄弱，优先补齐数据与知识资产

如果企业的产品文档、接口说明、客户案例、实施经验和历史工单分散在个人电脑或项目群中，优先建设智能体可能会遇到明显障碍。模型可以调用的内容不足，输出就难以稳定；知识没有持续维护，应用也很难跨项目复用。

这类企业应先梳理数据权属、敏感信息、文档结构和更新责任，建立面向研发与交付的知识库。数据治理不必一开始追求大而全，但应优先覆盖高频、稳定且与业务结果直接相关的资料，例如产品手册、代码规范、实施流程、故障案例和验收标准。

研发重复工作较多，优先建设智能编程工具链

对于拥有较成熟研发团队、代码仓库和测试流程的软件企业，智能编程工具通常是较容易启动的切入口。企业可以从代码补全、单元测试生成、接口文档整理、缺陷定位和旧代码解释等场景开始。

这类试点应设置清晰的研发指标，同时保留人工评审和安全检查。智能编程工具可以提高开发效率，但不能替代架构设计、代码审查和质量责任。尤其在涉及核心业务、数据安全或高可靠性系统时，企业需要明确哪些代码可以辅助生成，哪些环节必须由资深人员审核。

产品能力同质化，优先寻找智能体场景

如果企业已经具备较完整的数据和研发基础，但产品主要依赖人工操作或定制服务，可以考虑从智能体软件切入。不过，智能体场景不宜从“能不能对话”出发，而应从客户愿意为哪一项任务付费出发。

较适合优先验证的场景，通常具有任务边界清晰、输入输出相对稳定、结果容易评价等特点。例如面向企业内部的售后知识问答、实施任务辅助、运维告警分析、销售方案初稿生成或业务流程协同。对于需要跨系统执行的场景，还应提前评估权限控制、操作留痕和异常处理机制。

项目交付成本较高，优先推进交付能力改造

不少软件企业已经能够开发人工智能功能，但在客户现场仍然依赖大量人工配置、重复实施和项目经理经验。这说明企业短板可能不在模型能力，而在交付标准化。

这类企业应把智能化技改延伸到需求分析、方案设计、项目配置、测试验收和售后服务。通过沉淀行业模板、交付组件、实施知识和标准接口，逐步减少每个项目从头定制的比例。只有交付能力得到改善，人工智能能力才可能转化为更稳定的毛利和更快的项目复制。

对产品规划和研发流程的影响

“人工智能+软件”会改变软件产品的规划方式。过去企业更多围绕功能模块、版本周期和客户定制需求安排产品路线，今后还需要考虑数据是否可用、模型如何接入、智能能力如何评估，以及人工智能功能能否嵌入原有业务流程。

产品团队可以重点检查三个问题：

• 智能能力解决的是高频业务问题，还是仅作为展示功能存在；
• 产品是否具备接入企业数据和外部系统的标准接口；
• 智能输出是否能够被解释、校验、追踪和持续优化。

研发流程也需要相应调整。需求评审中要增加数据和安全评估，开发阶段要建立提示词、模型调用和知识库的版本管理，测试阶段要覆盖准确性、稳定性、越权风险和异常处理，发布后还要持续收集用户反馈与错误样本。

这意味着人工智能项目不能完全沿用传统软件项目的验收方式。除了功能是否上线，还要关注输出质量、人工接管比例、任务完成率和对实际业务的影响。

对行业解决方案建设的影响

对于软件服务商和行业解决方案提供商，政策带来的机会不只是增加一个“AI模块”，而是推动解决方案从功能交付转向任务交付。

例如，传统行业软件可能提供合同管理、客户管理或设备管理功能，加入智能体后，企业更关心的是能否自动完成合同要点提取、客户风险提示或设备异常处置建议。解决方案的竞争重点因此会从功能数量，逐步转向行业知识、流程连接、数据质量和交付效果。

但行业化不能停留在概念包装。企业需要明确适用客户、数据来源、部署方式、人工审核边界和效果评价标准。对于涉及生产安全、财务决策或个人敏感信息的场景，还应在项目初期明确责任边界，避免把尚未验证的能力直接用于关键决策。

企业申报与试点准备应围绕真实项目展开

专项行动涉及软件企业智能化建设和应用推广，企业如果计划参与相关试点或项目申报，应避免只准备技术名词和产品宣传材料。更有价值的准备，是把一个真实业务场景梳理清楚。

至少应形成以下几类材料：

1. 企业现有软件产品、研发流程或交付流程的主要痛点；
2. 计划采用的智能编程工具、智能开发平台或智能体应用范围；
3. 所需数据、系统接口、权限机制和安全管理安排；
4. 试点前后的效率、质量、交付周期或客户服务指标；
5. 项目实施阶段、参与团队和后续复制计划。

政策本身并不等于明确的资金支持、统一考核标准或具体申报结果。企业在准备过程中，应以正式发布的申报通知和实施要求为准，不宜仅依据概念热度提前作出投入承诺。

结语：先补短板，再选择人工智能切入口

对大多数软件企业而言，落实“人工智能+软件”不宜从追逐最复杂的模型或智能体开始。更稳妥的路径是先判断自身处于哪个阶段：数据是否可用，研发流程是否规范，产品是否有明确的智能化需求，交付过程是否具备复制条件。

数据基础不足，就先做好知识资产和数据治理；研发重复工作突出，就优先引入智能编程工具；已有行业数据和产品能力，就验证边界清晰的智能体软件场景；项目交付成本较高，就把重点放在流程标准化和交付能力改造上。

这也是企业理解本次政策目标的关键：人工智能不是独立于软件业务之外的新项目，而是对产品、研发、交付和经营体系的一次系统性检验。