山东CIO联盟 · AIHUB深度观察

过去二十多年，企业信息化建设基本遵循一套相对稳定的模式：

业务部门提出需求，IT部门分析需求，软件厂商或开发团队设计系统、编写代码，经过测试、部署和培训，最终交付使用。

对于复杂的ERP、MES、PLM等企业系统，这套模式至今仍然发挥着重要作用。

但在大量部门级、小型和个性化的应用需求中，企业管理者和IT负责人经常面临一个困境：

一个业务部门希望增加一个简单的功能，可能需要经历需求沟通、排期、开发、测试和上线等多个环节。项目本身并不复杂，但从产生需求到真正用起来，往往需要相当长的时间。

另一方面，IT部门的资源始终有限。面对越来越多的业务需求，只能不断排序、取舍。

现在，AI Coding正在尝试改变这个过程。

当业务人员能够通过自然语言描述需求，让AI帮助设计界面、编写程序、建立数据结构，甚至生成一个可以运行的应用时，我们需要思考的就不只是程序员的效率问题了。

企业软件的生产方式，可能正在发生一次重要变化。

一、软件开发的门槛正在降低

过去，开发软件是一项专业性很强的工作。

即使一个简单的业务应用，也需要理解编程语言、数据库、前后端框架，以及部署和维护方式。

低代码、无代码平台曾经试图降低这些门槛，也确实解决了一部分问题。但业务人员仍然需要学习平台的组件、数据模型和流程配置方法。

AI Coding带来的新变化，是让自然语言逐渐成为软件开发的重要入口。

例如，一家制造企业的质量部门希望建立一个质量异常跟踪工具。

过去，业务人员可能需要向IT部门说明：

需要填写哪些质量异常信息；

不同类型的问题如何分派；

哪些人员负责处理和审核；

如何统计问题的关闭时间；

怎样查询历史问题和生成报表。

IT人员再把这些描述转换为需求文档、数据库结构、程序逻辑和操作界面。

现在，这个过程中的相当一部分工作，可以尝试由AI辅助完成。

业务人员描述工作流程，AI进一步追问尚未明确的规则，形成需求规格，生成应用原型，再根据实际使用反馈不断修改。

当然，这并不意味着业务人员已经具备独立开发和维护生产级系统的能力。

但是，从业务需求到可运行原型的距离，正在明显缩短。

这可能是AI Coding对企业更重要的意义。

二、真正的变化，不是程序写得更快，而是谁能够参与软件建设

如果AI Coding只是帮助程序员把原来需要十天的编码任务缩短到几天，它带来的主要还是IT部门内部的效率提升。

这当然很有价值，但还不足以改变企业信息化建设的基本模式。

更深层的变化是：

软件建设可能从少数专业人员承担的任务，逐渐变成业务人员与IT人员共同参与的过程。

过去，业务人员主要负责提出需求、确认方案和验收结果。

未来，在一些边界清晰、风险可控的场景中，业务人员可能直接参与需求澄清、原型设计，甚至完成部分应用构建。

IT部门则更多负责制定技术规范、提供共享能力、审核关键设计、连接企业系统，并保障应用能够安全稳定运行。

软件建设的流程可能从：

业务提需求 → IT排期 → 开发实施 → 业务验收

逐渐演变为：

业务提出问题 → AI协助澄清需求 → 生成应用原型 → IT审核与集成 → 业务持续优化

这并不是取消IT部门，而是重新分配软件建设过程中的工作。

对于传统制造企业，这种变化尤其值得关注。

企业往往存在大量规模不大、个性化程度较高的数字化需求：现场异常记录、设备巡检、质量改善跟踪、供应商协同、项目进度管理、部门数据分析等。

这些需求有的并不适合投入大量资源进行传统软件开发，却又很难完全依靠标准化软件解决。

如果AI能够显著降低这类应用的建设成本，企业过去因为不经济而没有实现的数字化需求，就可能获得新的解决途径。

这意味着AI Coding不仅可能提高现有开发效率，还可能扩大企业软件应用的覆盖范围。

三、但一个重要问题出现了：谁来管理越来越多的软件？

软件生成得越来越容易，并不意味着软件的管理也越来越简单。

恰恰相反，这可能成为企业新的挑战。

一个业务人员用AI生成的应用，也许能够很好地完成演示。

但真正进入企业运行环境后，需要回答的问题远不止功能是否可用。

数据存放在哪里？

是否可以访问ERP或MES中的真实业务数据？

员工调岗或离职后，系统权限如何调整？

业务规则发生变化，谁负责修改？

系统出现错误，谁承担处理责任？

如果应用持续使用三年、五年，谁负责维护？

对于生产、财务、采购等业务，错误还可能造成真实的经济损失。

因此，软件开发成本下降，不等于软件全生命周期成本同比例下降。

Google DORA关于AI辅助软件开发的研究也提示，AI带来的效率收益并不会自动转化为组织整体交付能力的提升。代码生成速度提高以后，验证、测试、协作和运行治理仍然不可缺少。

未来企业可能面临一个过去不太突出的矛盾：

一方面，业务部门可以更快地创建应用；另一方面，如果缺乏统一管理，企业可能出现大量缺少维护责任、数据管理混乱、安全边界不清的应用。

这与过去企业大量使用Excel、Access以及部门自建小系统的情况有某些相似之处。

只是AI Coding可能进一步提高应用产生的速度和复杂度。

如何让软件生产更容易，同时避免形成新的系统孤岛和技术债务，将成为企业IT治理的重要课题。

四、企业未来可能需要两种不同的软件建设模式

我们不认为未来所有业务系统都应该让员工用AI自行开发。

对于传统企业，更合理的选择可能是建立分层的软件建设体系。

第一类：核心业务系统，仍然需要专业化建设和严格治理。

ERP、MES、PLM等系统承载着企业关键业务数据、交易记录和业务流程。

它们涉及复杂的业务规则、数据一致性、系统集成和长期运行责任。

AI可以参与这些系统的定制开发、测试、实施和维护，但并不意味着这些系统能够被业务人员随意生成和替代。

第二类：部门级、轻量级应用，可能成为AI Coding的重要突破口。

对于数据范围明确、业务边界清晰、风险较低的应用，可以探索由业务人员提出需求、AI辅助构建、IT审核后上线的方式。

例如一些内部信息收集、任务协同、报表分析和非关键流程管理工具。

但只要应用涉及企业敏感数据、共享数据库或者关键系统写入，就必须提高审核和治理要求。

这种分类不是依据程序大小，而是依据业务风险、数据权限、系统影响和维护责任。

未来，企业IT部门未必需要亲自开发每一个小应用，但需要确保这些应用在统一的规则下运行。

五、CIO的价值，可能从建设系统转向建设企业的软件生产能力

这可能是AI Coding给CIO带来的最重要的变化。

传统企业IT部门的能力，很大程度上体现为能够采购、实施、集成和维护多少业务系统。

未来，这些能力仍然重要，但企业可能需要增加一项新的组织能力：

让更多业务人员能够在安全、可控的环境中，利用AI参与软件和流程创新。

这要求IT部门建设的不只是一个AI Coding工具，而是一套完整的运行机制。

近来受到关注的Harness，可以帮助我们理解这一点。

在企业软件工程中，Harness可以理解为围绕AI开发过程建立的一套约束和支撑机制，包括需求规格、业务上下文、开发规范、工具调用、测试、代码审查、部署、日志、权限和回滚等环节。

其目标不是让AI完全自由地开发，而是让AI生成的软件能够接受工程化管理。

对于CIO而言，未来可能需要重点掌握三种能力。

首先是业务理解能力。

IT部门不仅需要知道业务提出了什么需求，还需要理解需求背后的流程、规则、价值和风险。

AI可以协助需求分析，但最终仍需要业务部门确认业务目标和验收标准。

其次是企业架构与治理能力。

当应用开发门槛降低，统一身份、数据权限、API管理、主数据、系统集成和运行监控的重要性反而可能上升。

企业需要让不同来源、不同开发方式的应用共享可信的基础能力，而不是各自建设一套新的数据和权限体系。

第三是组织赋能能力。

IT部门需要帮助业务人员学习如何准确描述需求、如何评价AI生成的结果、如何识别风险，以及何时必须交由专业人员处理。

未来衡量IT部门能力的指标，也许不应只是开发了多少系统、处理了多少需求工单。

还可以包括：

企业业务需求从提出到验证需要多长时间？业务人员能够自主解决多少低风险数字化问题？应用质量是否得到保障？IT部门是否减少了重复建设和长期维护成本？

换句话说，CIO管理的可能不再只是一个IT部门，而是整个企业的软件建设和数字化创新能力。

六、对于山东制造企业，现在应该做什么？

我们认为，现在既不必急于让所有员工学习AI编程，也不应把AI Coding仅仅视为程序员的新工具。

更有价值的做法，是选择一个真实业务需求，开展小范围实验。

例如，从企业长期积压的部门级数字化需求中，挑选一个业务责任人明确、流程比较清晰、数据容易获得、不会直接影响核心生产和财务交易的场景。

让业务人员与IT人员共同参与，比较两种方式：

一种是企业原有的需求分析和软件开发流程。

另一种是业务人员在AI帮助下完成需求澄清和原型构建，再由IT人员进行审核、完善和测试。

观察的不应只是AI用了多长时间生成程序，而应包括需求沟通时间、修改次数、实际可用程度、IT审核工作量、测试缺陷和后续维护成本。

这样的实验，即使最后没有成功上线，也能够帮助企业回答一个重要问题：

AI Coding究竟降低了企业软件建设的总成本，还是仅仅把成本从编码环节转移到了审核、测试和维护环节？

只有回答了这个问题，企业才有依据决定是否扩大应用范围。

七、软件越来越容易开发，IT部门会不会变得不重要？

我们的判断恰恰相反。

当软件开发是一项稀缺能力时，IT部门的重要价值之一，是掌握专业的软件建设资源。

但当AI逐渐降低软件开发的技术门槛，单纯掌握编码能力的稀缺性可能下降。

企业真正稀缺的能力，可能逐渐转向对业务的理解、跨系统的连接、统一的技术架构，以及对软件质量、安全和业务结果的持续负责。

这些能力并不会因为AI能够生成代码而自动产生。

一个值得思考的趋势是：

过去，企业IT部门主要负责为业务建设软件；未来，IT部门可能需要负责让整个组织具备安全、持续地建设和改进软件的能力。

这不意味着所有企业都会沿着同一条道路发展。

AI Coding能在多大程度上改变传统制造企业的软件建设，仍然需要通过真实项目验证。

但对于CIO而言，现在已经值得开始思考：

如果未来企业的软件开发成本显著下降，我们现有的IT组织、项目管理方式、供应商合作模式和数字化建设规划，是否还应该保持不变？

更进一步的问题是：

当软件本身不再那么稀缺，企业IT部门真正不可替代的价值究竟是什么？

这可能是未来几年，每一位CIO都需要重新回答的问题。

AIHUB观察与交流

山东CIO联盟·AIHUB正在持续关注AI Coding、企业Agent、业务流程重构，以及AI时代企业IT组织能力的变化。

我们希望与制造企业CIO、数字化负责人和技术专家共同研究：AI能否真正降低企业软件建设与实施成本，以及如何在提高创新效率的同时保障系统安全、质量和长期可维护性。

如果您的企业已经开始利用AI开展应用开发、系统实施或业务人员自助构建应用，欢迎与我们交流实际经验，包括已经取得的成效、遇到的困难以及仍待解决的问题。

我们相信，真正有价值的经验不仅来自成功案例，也来自对失败和实施边界的认真总结。

山东CIO联盟 · AIHUB

让AI成为企业能力。