驾驭AI超级周期,CIO必须重构企业的软件生产体系

一种是购买标准化产品，由供应商实施；另一种是根据自身需求组织定制开发。无论采取哪种方式，背后的基本逻辑都是一样的：业务部门提出需求，IT部门组织开发，项目团队交付系统，系统上线后进入运维阶段。

过去二三十年，企业一直在使用数字化手段改造生产、营销、供应链、财务和客户服务，却很少真正改造软件自身的生产过程。

企业可能拥有先进的智能工厂，却仍然通过大量Word文档传递需求；可能拥有实时供应链，却无法实时了解软件项目中的价值衰减；可能拥有统一数据平台，却仍然让不同项目重复建设相似的功能；可能要求业务部门沉淀数据资产，却允许IT部门最重要的架构经验、业务规则和项目知识停留在个人电脑、微信群和项目文档中。

换句话说，很多企业已经数字化了业务，却还没有真正数字化自己的软件生产体系。

东软白皮书提出，AI不仅参与代码生成，还将进入需求理解、架构设计、测试验证、运行优化和系统演进的全流程。这意味着，过去以人为主要生产要素、依靠流程标准化和大规模人力协同的软件生产模式，将逐步进入智能化生产时代。 

这对CIO提出了一个尖锐的问题：

当AI成为新的软件生产力要素之后，企业是继续把AI嵌入旧流程，还是借助AI重新设计整个软件生产体系？

前一种方式是“AI加法”，后一种方式才是真正的AI原生转型。

如果企业只是给开发人员配置智能编码助手，却仍然使用模糊的需求、割裂的知识、失控的架构和落后的验收机制，那么AI的结果往往不是消除问题，而是更快地复制问题。

AI可以让好体系跑得更快，也可以让坏体系更快失控。

白皮书从目标形态、交付形态、资源形态和组织形态四个方面，概括了软件产业正在发生的结构性变化。对行业用户而言，这四个变化同样可以用来重新审视企业IT部门的未来定位。 

第一，从建设确定性系统，转向建设并治理复杂智能系统

传统软件的核心是确定性逻辑。

输入什么数据、执行什么规则、输出什么结果，原则上都能够通过程序代码严格定义。测试工作的核心，也是验证系统是否按照预定规则运行。

但大模型和智能体进入业务系统之后，企业面对的是一种新的“概率性系统”。

同一个问题可能得到不同答案；智能体可能根据上下文采取不同路径；模型能力会随着版本升级发生变化；知识库、提示词、外部工具和业务环境都会影响最终结果。

因此，企业的系统建设目标不能再停留在“功能是否正确”，还要回答：

AI的决策是否可信？结果是否可解释？上下文是否准确？智能体是否越权？模型升级后系统是否仍然稳定？人工在什么情况下必须介入？关键责任由谁承担？

这意味着，CIO管理的不再只是信息系统，还将包括模型、知识、智能体及其行为。

第二，从一次性项目交付，转向持续价值运营

传统项目往往以上线和验收为终点。

然而，AI系统上线只是起点。模型需要持续评测，知识需要持续更新，智能体需要持续优化，成本需要持续调整，用户反馈需要不断进入新的迭代循环。

因此，行业用户与数智化厂商之间的关系也会发生改变。企业需要的不再只是“把系统建完”，而是合作伙伴能否持续改善业务效率、优化客户体验、降低运营风险，并推动业务能力不断演进。

未来采购软件时，CIO不能只询问“系统什么时候上线”，还要询问：

系统上线后如何持续学习？知识由谁维护？模型如何升级？效果如何评测？业务价值如何跟踪？运营成本如何控制？

软件采购模式也将从购买静态功能，走向购买持续演进的业务能力。

第三，从人力密集型建设，转向知识密集型生产

传统项目竞争很大程度上是人力竞争：投入多少顾问、架构师、开发人员和测试人员。

AI时代，更稀缺的资源将是可被机器理解、调用和复用的行业知识、业务规则、架构方法、软件资产和工程经验。

未来，拥有一千名开发人员并不一定比拥有一套高质量行业知识体系的企业更有竞争力。真正的差距在于：

谁能把专家经验显性化，谁能把业务规则结构化，谁能把历史系统中的隐性知识提取出来，谁能让这些知识在不同项目和智能体之间重复使用。

对CIO而言，知识管理不能再只是门户网站中的一个栏目，而要成为软件生产的核心基础设施。

第四，从项目型组织，转向人机协同型组织

AI原生组织不再只有人类员工，还包括模型、智能体、Skills、知识库和自动化工具。

白皮书提出由“全人劳动力”“人携Agent劳动力”和“Agent自闭环劳动力”组成的三元混合劳动力体系：复杂、高风险任务更多由专家主导；标准化、重复性、低风险任务则可以逐步提高AI自治比例。 

这对CIO组织管理的影响非常深远。

未来，IT部门可能不再按照固定人数配置项目，而是按照任务动态组合业务专家、技术人员和智能体。管理者需要管理的不只是“谁负责这项工作”，还要管理“哪些工作由AI完成、AI能够调用哪些工具、在什么条件下必须转交人工”。

组织设计将从职位管理走向能力管理，从人员编制走向任务编排。

白皮书提出了一个以“四层环境三层映射”为核心、由六大能力支撑的AI原生软件工程框架，目标是形成“统一规划、统一平台、统一运营、统一治理”的软件生产体系。六大能力包括软件资产与技术、知识工程与方法、组织与能力发展、基础设施与工具、安全与合规、运营与治理。 

其背后的重要思想是：不能只优化开发环节，而要打通产品研发、生产过程、价值交付和价值实现四层环境，把软件资产、生产过程、交付结果与客户业务价值连接起来。

白皮书第6页的“四层环境三层映射”架构图，试图建立从客户价值诉求、软件资产水平、软件生产过程，到业务价值和交付结果之间的贯通关系，并通过QCD管理、业务价值衰减分析和生产结果映射，实现全过程量化。 

对行业用户而言，这个框架的意义可以概括为一句话：

CIO不能只管理项目是否按时、按预算上线，还要管理业务意图在需求、架构、代码和运行过程中是否发生了失真。

很多项目的问题，并不是开发人员没有完成需求，而是业务价值在层层传递中不断衰减。

董事会希望提升客户体验，业务部门把它翻译为建设客户平台，产品经理进一步拆分为几十项功能，项目团队按照功能清单开发，最终系统虽然通过验收，却没有真正改善客户体验。

AI可以提高每一环的工作效率，但如果价值传递链条没有打通，最终得到的仍然是“更快交付了一个价值有限的系统”。

因此，AI原生软件工程首先不是代码工程，而是业务意图的高保真传递工程。

1. 把软件从“项目成果”变成“企业资产”

传统项目结束后，企业往往只留下代码、系统和文档。大量业务规则、设计决策、测试经验和问题处理方法，随着项目人员离开而流失。

白皮书提出，AI时代的软件资产不应只包括代码、组件和平台，还应包括业务意图、业务能力、架构方法、Prompt模板、Skill、数据、测试规则和运行经验，使这些资产能够被AI持续理解、调用、复用和演进。 

这对CIO至少有三方面启示。

第一，要建立企业级软件资产目录和业务能力地图。企业应当知道自己拥有哪些客户管理能力、风险管理能力、供应链能力和运营能力，而不是只知道部署了多少套系统。

第二，要把遗留系统现代化与知识提取结合起来。对历史代码进行架构反推、业务规则抽取和接口关系梳理，不只是为了重构系统，也是为了把沉睡在旧系统中的业务知识重新变成企业资产。

第三，要把复用率纳入评价。如果每个项目都从头建设，AI只能降低单个项目的成本；只有实现跨项目、跨部门复用，AI才能真正提高企业级研发投入回报率。

2. 从建设“知识库”升级为运营“知识生产线”

很多企业已经建立了知识库，但实际效果并不理想。

原因是大量知识只适合人阅读，不适合AI调用；有些内容已经过期，有些内容彼此矛盾，有些内容缺乏权限和版本管理。知识虽然被存放起来，却没有真正进入业务流程和软件生产过程。

白皮书把知识划分为Know-Why、Know-What和Know-How，覆盖政策法规、行业知识、业务流程、业务规则、架构方法、工程方法和项目经验，并强调把业务知识与工程知识进行语义对齐和可计算化。 

这意味着，企业知识工程至少要完成三个转变：

从文档收集转向知识建模；从被动查询转向主动供给；从静态存储转向持续运营。

尤其值得CIO关注的是“上下文供给机制”。未来AI生成结果的质量，很大程度上取决于企业是否能够为不同任务提供准确、完整、权限合适且版本一致的上下文。

一家企业可以采购同样的大模型，但拥有更高质量上下文的企业，最终获得的AI能力可能完全不同。

模型能力逐步商品化之后，企业之间真正拉开差距的，将是上下文工程和知识运营能力。

3. 把组织管理对象从“人”扩展到“人、Agent与任务”

未来IT项目的组织方式可能发生根本变化。

以往，企业围绕项目建立团队；未来，企业可能围绕任务动态组合业务专家、架构师、开发人员、测试人员和多个智能体。

这要求企业建立任务分级机制：哪些任务复杂度高、风险高、影响大，必须由专家决策；哪些任务规则明确、重复度高，可以交给智能体执行；哪些任务由AI完成初稿、人工审核确认。

同时，绩效评价也要发生改变。

过去主要评价个人完成了多少工作，未来还要评价其沉淀了多少知识资产、训练了多少可复用的智能体、改善了多少人机协同流程，以及是否帮助其他团队提高了生产效率。

AI时代最有价值的员工，不一定是完成任务最多的人，而可能是能够把个人经验转化为组织能力的人。

4. 建设统一的AI原生开发者平台

随着各部门自行采购模型、智能编码工具和智能体平台，企业很容易形成新的AI孤岛。

白皮书提出“算力统筹、模型私有、工具统一”，围绕知识服务、模型服务、Agent能力、软件资产服务和AI开发工具链，重构内部开发者平台，并形成统一模型入口、统一知识入口、统一Agent入口和统一治理入口。 

对CIO而言，统一平台的价值不是追求技术上的“大一统”，而是建立企业级控制面。

业务团队仍然可以灵活选择模型和工具，但所有模型调用、知识访问、智能体权限、成本消耗和安全行为，都应进入统一的可观测、可审计体系。

企业可以采用租用算力、自建算力和Token/API服务相结合的混合模式。真正重要的不是选择一种技术路线，而是能够根据数据敏感度、业务连续性、性能要求、成本和创新速度动态配置。

5. 把安全从上线前检查变成生产过程的内生能力

AI原生系统带来的安全风险，已经从传统代码、网络和系统安全，扩展到数据与知识安全、提示词与上下文安全、模型与供应链安全、Agent安全、生成结果与工程安全以及合规监管风险。 

特别是智能体进入核心流程之后，安全问题将从“AI说错话”升级为“AI做错事”。

一个能够读取客户数据、调用业务接口、生成审批意见并触发交易的智能体，与一个普通问答机器人有本质区别。

因此，企业必须为智能体建立类似员工的数字身份和权限体系：明确它能够访问什么数据、调用什么工具、执行什么操作、在什么额度内自主决策，以及何时必须请求人工授权。

安全门禁还应嵌入需求、设计、开发、测试、发布和运行全过程，并统一治理代码资产、知识资产、规格资产、测试资产和Agent资产。对于AI生成成果，还要明确知识产权归属、使用边界和版权责任。 

安全不应成为AI创新之后补上的“刹车”，而应成为企业敢于规模化应用AI的“底盘”。

6. 建立AI时代新的度量、成本和质量体系

AI提高了代码生成速度，却也使传统研发指标迅速失效。

代码行数越多，未必意味着价值越大；AI生成率越高，也未必意味着效率越高。如果生成的大量代码需要人工修改、引入技术债务或造成后续返工，表面的生产率提升反而可能带来更高的长期成本。

白皮书提出，软件生产力度量应从统计“开发了多少代码、交付了多少功能”，转向评估业务意图是否被正确表达、架构是否有效传递、生成过程是否稳定可控、成果是否可验证，以及问题是否形成闭环。 

企业可以重点关注三类度量。

架构层面，关注业务价值、业务能力和业务规则是否准确映射到系统能力；开发层面，关注Spec质量、上下文质量、AI生成采纳率、人工修订率、缺陷率和低置信度结果占比；交付层面，关注自动化测试覆盖率、代码审查有效性、安全扫描命中率、回滚率和问题修复周期。

与此同时，AI FinOps将成为CIO与CFO共同面对的新课题。

白皮书建议对GPU算力、模型训练、模型推理、商业API、Token、知识库、向量数据库、MCP工具和Agent运行成本进行统一分类、计量与分摊，使成本能够追溯到具体账户、项目、团队和业务域。 

企业还应根据任务价值和复杂度进行模型分级调用，通过上下文压缩、精准检索、缓存复用、模型量化、弹性伸缩和智能路由降低资源消耗，并同时度量人力成本与AI成本。 

最终，企业需要回答的不是“用了多少Token”，而是：

每完成一项有效业务任务需要多少成本？节约了多少人力？缩短了多少周期？提高了多少质量？创造了多少业务价值？

质量保障体系也必须随之改变。白皮书提出从传统阶段式文档评审，转向“规约—生成—运行时”的全栈验证：质量左移到Spec，利用静态分析、一致性检查和冲突检测消除源头歧义；质量右移到生产环境，通过日志、性能和业务数据持续反馈；对AI生成物设置专项门禁和差分测试，低置信度结果自动转交人工深度审计。 

未来QA不再只是测试人员，而将成为质量体系设计者、过程审计员和AI能力训练师。

综合白皮书的框架，行业用户推进AI原生软件工程，不应从“买什么工具”开始，而应从五项管理转变开始。

第一，从项目管理转向价值流管理。项目上线不是终点，要持续追踪软件是否真正改善业务结果。

第二，从系统清单管理转向软件资产管理。企业不仅要知道运行了哪些系统，还要知道沉淀了哪些可复用的业务能力、知识、组件和智能体。

第三，从知识存储转向知识运营。知识要有主人、有版本、有权限、有质量评价，并能够进入AI上下文和业务流程。

第四，从人员管理转向混合劳动力管理。管理对象需要扩展到员工、模型、智能体和工具，并根据任务风险明确人机分工。

第五，从IT成本管理转向AI价值运营。不能只统计算力、Token和模型费用，还要把资源消耗与业务任务和业务价值连接起来。

这五个转变中，任何一个都不是单纯的技术问题。它们涉及业务架构、财务机制、人才管理、采购模式、风险治理和企业文化，因此必须由CxO团队共同推动，而不能只交给研发部门。

对于大多数企业而言，不适合一开始就建设覆盖全公司的庞大平台。更现实的做法，是从一条高价值软件生产链路切入，建立最小闭环，再逐步扩展。

第一阶段：0—3个月，选场景、建基线

选择一个业务价值明确、需求变化频繁、知识积累较多，同时风险可控的系统或产品线作为试点。

重点不是立即追求AI代码生成率，而是完成现状诊断：需求如何传递、知识在哪里、哪些功能重复建设、技术债务有多大、项目成本如何构成、质量问题主要发生在哪些环节。

同时建立AI使用基线，包括交付周期、返工率、缺陷率、知识复用率、测试覆盖率、单位任务成本和用户反馈周期。

没有基线，就无法证明AI的价值。

第二阶段：3—6个月，打通知识、资产和工具链

围绕试点场景建立业务能力地图和软件资产目录，梳理业务规则、架构约束、接口关系、测试资产和历史缺陷。

建设稳定的上下文包和任务模板，将知识库、代码仓库、需求管理、测试管理和AI工具连接起来。同步建立统一模型入口、智能体身份、权限控制、成本标签和日志审计。

这一阶段的目标，不是追求平台功能齐全，而是形成“知识进入AI—AI参与生产—结果接受验证—反馈更新知识”的最小闭环。

第三阶段：6—12个月，规模化运营与治理

在试点验证有效之后，把能力扩展到更多产品线和项目。

建立软件资产复用机制、AI FinOps体系、智能质量门禁和智能体治理制度，将资产复用率、知识引用率、AI生成首次通过率、单位任务成本和业务价值贡献纳入组织评价。

同时形成由CIO牵头，业务、技术、财务、人力资源、法务和安全部门共同参与的AI原生软件工程治理机制。

规模化的关键不是部署更多工具，而是让统一规则、统一平台和统一度量真正进入日常经营。

1. 在审批下一轮AI和软件工程投资之前，管理层至少需要回答以下问题：

2. 我们的AI软件工程目标，是提高个人编码效率，还是重构企业级软件生产能力？

3. 业务意图能否持续追踪到需求、架构、代码、测试和运行结果？

4. 企业最有价值的行业知识和业务规则存放在哪里，能否被AI安全调用？

5. 历史系统中的隐性知识和技术债务是否已经被系统识别？

6. 不同部门是否正在重复采购模型、工具和算力资源？

7. 智能体拥有什么身份、权限和行为边界？

8. AI生成结果由谁负责，什么情况下必须人工审核？

9. 企业能否把Token、模型和算力成本归因到具体业务任务？

10. 当前度量的是代码产量，还是业务价值、质量和可持续演进能力？

11. 软件供应商交付的是一次性系统，还是能够持续运营的行业智能能力？

12. 如果这些问题尚无清晰答案，那么企业即使已经采购了大量AI工具，也很可能仍停留在AI原生软件工程的早期阶段。

AI原生软件工程不是一次普通的研发效率提升，也不是DevOps之后的又一次工具升级。

它本质上是在重新定义企业如何把业务意图、行业知识、专家经验、数据资产和人工智能，转化为可运行、可验证、可复用、可持续演进的软件能力。

未来企业之间的差距，不只体现在谁拥有更强的大模型，还将体现在谁拥有更高质量的知识、更丰富的软件资产、更成熟的人机协同机制，以及更可信的治理体系。

对CIO而言，角色也将随之改变。

过去，CIO主要负责建设和运营信息系统；未来，CIO还要经营企业的软件资产、知识资产、模型资源、智能体劳动力和数字化生产体系。

真正领先的企业，不会满足于让AI帮助员工更快完成旧工作，而会重新思考：哪些工作应该由人完成，哪些工作可以由智能体执行，哪些知识应当沉淀为组织资产，哪些软件能力可以持续复用，技术投入如何转化为长期业务价值。

因此，AI原生软件工程的终点，并不是“让AI写出更多代码”。

它真正要实现的是：

让企业以更低成本、更高质量和更快速度，把不断变化的业务意图，持续转化为可信的软件能力和可衡量的商业价值。

这才是AI时代CIO最值得投入的一场转型，也是企业数智化从“系统建设”走向“智能生产力运营”的关键一步。

  关于IDC CXO卓越圈

IDC CXO卓越圈旨在为CXO会员提供一个跨界、融合、共享、交流、通向卓越的平台，针对企业在数字化转型过程中遇到的问题进行探讨， 受邀的CXO会员不仅可以听到来自于IDC资深分析师的独家洞察，更可以各抒己见，与来自不同行业的CXO跨界交流，共享卓越。

IDC CXO卓越圈通过三种方式与大家交流，一是“IDC CXO专属下午茶”线上/线下活动，二是“IDC CXO卓越圈”微信群，三是“CXO卓越圈”公众号。

CXO卓越圈微信公众号的内容覆盖4大方向：总体ICT技术与行业发展趋势，数智化转型的战略方法与实践，支持数智化转型的新技术趋势与应用，CXO角色与组织结构转型。

IDC与您一起在技术加速商业变革的智能经济时代携手同行！