AI+软件方案:Agent 转正写进国策不抄条文,先拆最硬的一块——「开发方式」这四个字,到底改了的什么.

🔵 点击上方蓝字「小火慢炖出滋味」关注我，每周一到周四更新。

本期观察：企业上 Agent，多数人把账算反了——这话我们上期刚聊过。

9 月 11 日，工信部一份文件刷屏：《「人工智能+软件」专项行动实施方案》（工信部信发〔2026〕209号）。

上期我们讲「Agent 正在转正」——行业已经把它从工具管成了员工。这份方案，等于把那件事写进了国策。

今天不抄条文，先拆最硬的一块：方案到底要改什么——从「开发方式」这四个字说起。这份方案很大，我们分几期慢慢拆。

一、这份方案，到底要干什么

一句话：它是国务院「人工智能+」行动，落到软件行业的一份施工图。

它的上位令是国发〔2025〕11号「人工智能+」行动意见；这份 209 号文，把那个大目标落到了软件这个具体行业。

成文 9 月 2 日，公开发布 9 月 11 日，执行口是工信部信息技术发展司。

为什么说落点是软件？因为「人工智能+」能不能真正落地，关键看软件与各产业的融合能力。

软件是 AI 进到千行百业的「最后一公里」载体。而软件行业自己，也得先想清楚一件事。

这股浪潮里，我的核心竞争力该往哪重塑？这正是这份方案要指导的方向。

方案没空谈，它盯准了三个具体抓手：开发方式、产品形态、服务模式。

从这三个维度提改进要求，把软件变成驱动产业升级的那台「核心引擎」。

本文先做第一步——把「开发方式」这四个字拆透；产品形态、服务模式，留到下两期接着拆。

它背后站着一组数据：2025 年我国软件业务收入 15.48 万亿元，是 2012 年的 6.2 倍。

截至 2026 年 6 月，日均词元调用量突破 500 万亿。

体量够大、渗透够快，但融合的深度和广度还不够。所以方案要做的，是给这辆快车换发动机。

换发动机，坐在车上的每一家软件企业都得跟着调坐姿——尤其那些还在靠老师傅、靠堆人做项目的。

二、最该记住的，是「三个转变」

十九条措施、六个方面，落到根上就是三件事——正好对应方案对「开发方式、产品形态、服务模式」三方面的改进要求：

这三行，是整个方案的主轴，也是方案给软件行业重塑核心竞争力的三道抓手。

（后两行先点一句，下期再展开） 产品形态，是从「你点它才动」的被动工具，变成能感知业务状态、基于目标自主推进的主动系统；服务模式，是从卖一份软件或一套 license，变成交付可衡量的业务结果。三者递进——开发时人机协同，产出的产品能主动执行，最终交付的是价值而非软件本身。

拆开「开发方式」这四个字，才是真文章。

方案开篇第一句，把「开发方式」摆在变革首位：AI 改的首先是「软件怎么被做出来」。但这四个字落到一家软件企业，到底改什么？

被忽略的文档，到这见真章

我指导过的软件企业，几乎家家都有文档——可内容与质量，撑不起「让智能体生成可用软件」这件事。

简单产品，靠反复语言沟通、磨合细节就能出来；项目一旦上了复杂度，真正管用的，是产品定义、架构设计那几份关键过程文件。

它们不再是给人看的说明书，而成了一线指挥智能体员工的作战地图。

所以「开发方式」的本质，是把人过去发力写代码的活，交给智能体；人退到上游，去做定义产品、定架构、写指导文件。

这恰恰对上方案里「以代码质量、研发效益为实效依据」——工具省不省钱，不看你用了没有，看产出对不对。

也和我一直说的「人干人事，机器干机器事」，是同一件事。

我自己的实践：三步法

· 第一步，定版指导性文档：把产品设计、架构设计写清楚，这是后面一切的地基；

· 第二步，构建智能体组织：派一个「架构师智能体」牵头，去协调多个不同分工的智能体员工；

· 第三步，组织验收：不是做完一再做二再做三的流水线，而是按产品特性切成多个迭代，边做边验。

我拿真实操作数据比过两种交付节奏：一种是「边说边干、边变交付」的全量迭代——需求在生成过程里反复漂移，改一处牵一片；

另一种是先定产品设计、再定系统架构、最后交给智能体开发交付的阶段迭代。

简单软件的架构可能就一句话，对智能体而言则是一条约定或裁决依据（产品设计本身当然也要多次迭代）。

同样的产品，两种节奏的 Token 消耗差出 2~5 倍。

这 2~5 倍不是拍脑袋，是我从真实项目里摸出来的——它说明：第一步「定版指导文档」省下的，不只是时间，是真金白银。

落到企业，这套三步法本质是对现有软件工程和项目管理的变革，强化的，正是「人干人事，机器干机器事」这条分工线。

方案把「人机协同」写进主语，不是喊口号。它意味着：人不再是唯一的写代码的人，但人要对「协同」的结果负责。

「代码质量、研发效益」怎么落地？

读到方案里「以代码质量、研发效益为智能体应用实效的重要依据」，我第一反应是五年前那场数字化爆发。

那时候全省几十个工业品类轮番上技改，从产线到能耗一套套改造。

如今，轮到软件企业做「智能化技改」了——而且「改造软件开发流程」上一段刚讲过，此处不多言。

真正要问的是：代码质量怎么衡量？研发效益又怎么衡量？

我的看法很直：智能体生成的代码，和工程师手写的代码，原则上该是同一套标准。

不管最后是人维护还是 AI 维护，代码终归是要被维护的。

所以它照样得遵循业界的经验与规范——圈复杂度、可测试性、命名与分层、缺陷密度，一套都不会少。

只不过，这恰好又绕回第一个话题：很多团队以前「忽略的规范和质量建设」，到这儿就见真章了。

平时文档稀烂、流程糊弄，人还能靠加班和老手救场；把活交给智能体，糊弄不过去了。

真金不怕火炼，火一来，掺没掺假立刻现形。

那研发效益怎么衡量？我烧过 Billion 级别的 Token，也贴着好几家被服务企业的研发过程看过。

基本判断就一句话：看一个版本交付的「迭代次数」和「深度」。

深度

从人的一个想法，到最后交付，中间经过了多少步骤；

次数

同一个环节，被重复返工了多少遍。

这俩数，不只是检验研发体系规不规范——深度越短、次数越少，说明需求定义和架构越清楚，智能体才跑得顺；

它更是智能体成本核算的核心环节：Token 烧在哪、返工烧多少，全藏在这张表里。

看到这可以先停一下：你手里的智能编程工具，现在卡在模型，还是卡在需求？

本期收个尾

今天只拆了「三个转变」里的第一个——开发方式。它也是最硬的一块。

把人从写代码的位置，挪到定义、架构、指导的位置；把「代码质量、研发效益」从一句口号，变成可以量、可以算账的东西。

产品（被动响应→主动执行）、服务（产品交付→价值交付）那两个转变，以及方案里更具体的「智能体新业态」「红线管控」「这周能动手做什么」，我们下期接着拆。

留个思考题

方案把「开发方式」摆首位，本质上是逼企业补以前忽略的「定义与架构」功课。

如果让你给自家研发流程做个体检：从老板一个想法，到你手上能跑的版本，中间要经过几步、返工几遍？这俩数，你现在量得出来吗？

往期回顾

· AI 落地不是买模型，而是先画流程那场 30 分钟结束的质量验收 · 一个老板该看的五个步骤

·  AI Agent 正在"转正"：行业把它从工具管成了员工不追概念，只看信号。本周观察到一个值得注意的变化——企业上 Agent，多数人把账算反了

小火慢炖出滋味 ｜ 周二业界观察 ｜ 每周一到周四更新 · 点击上方蓝字关注