AI+软件落地后,软件公司要先重做交付方式

工信部近日印发“人工智能+软件”专项行动实施方案。它把行业重心从“有没有AI功能”推向“能否把需求、开发、测试、运维和服务一起重组”。真正的竞争，将发生在交付链条而非演示界面。

文｜最极客

9月11日，工信部印发《“人工智能+软件”专项行动实施方案》。文件提出推动传统软件和信息技术服务智能化升级，并将智能体软件、智能服务列为新业态。对软件公司而言，这不是在产品菜单里多加一个对话框，而是一次关于交付方式的重新定价。

过去两年，许多企业采购AI，最先买到的是“生成”：生成代码、生成报表、生成客服话术。它们改善了局部效率，却很少改变项目最终是按时交付、还是在反复返工中拖延。原因并不神秘。软件项目真正昂贵的环节，往往不是敲下第一行代码，而是把模糊需求变成可验收的规则，再把规则留在测试、上线和售后的每一次变更里。

专项行动把智能编程、智能服务、智能体软件放在同一张产业图里，恰好点出了这一点。智能编程可以缩短实现时间；但如果需求没有版本、接口没有边界、数据没有负责人，生成得更快只会让后续的排查更快堆积。对客户而言，AI最有价值的形态不是“替人写完”，而是让每一个决定都可追溯、每一次异常都能回到责任人。

这也解释了为什么软件公司的产品团队会先承压。传统项目中，产品经理把需求写进文档，研发把它翻译为系统，交付团队在现场处理例外。智能体进入后，规则、工具权限和升级路径需要在一开始就被写成机器能执行的约束。谁能调用什么数据，遇到低置信度时停在哪里，客户如何撤回或修正结果，都不能留给一句“模型会学习”。

软件企业因此需要把评估指标从“生成了多少内容”转向更接近经营结果的数字：需求确认周期是否缩短，缺陷是否更早暴露，客户问题的首次解决率是否提升，人工复核究竟拦下了多少错误。前者容易在发布会上展示，后者才决定续费率和服务毛利。

文件还特别提到代码审查、AI安全等岗位需求。这不是对自动化的否定，而是提醒行业：自动化扩大了可被交付的范围，也扩大了错误被复制的半径。对面向政企、金融、制造的厂商，安全和审计不会是上线后的附加项，而会成为报价的一部分。

短期内，客户大概率仍会要求看见一个聊天入口；长期看，客户会用更朴素的问题检验AI：一次故障能否更快定位，一份方案能否少改两轮，一名新员工能否在权限受控的情况下更快上手。能把这些问题写进产品、流程和合同的软件公司，才更可能把“AI+软件”从功能升级做成一门可持续的生意。