Strategy Research · Full Illustrated Edition

AI 正在重构软件产业：从系统生成、研发工作流到资本竞争

战略研究深化版 · 以 ERP、分布式系统、大型 AI 三种场景为基础 · 全文配 12 张工程图

开篇：另一个视野看世界，两种故事，和一个原点

先换一个视野看世界。说一个硬判断：百万 token 的上下文，或许依然支撑不起一个业务系统的形态——上下文再长，也只是"读得完"，不是"算得清"；AI 作为一套系统，本身也存在自己的短板，它是被造出来的系统，不是全知全能的神。

而这套系统当初为什么会被造出来？提供一个未必是史实、但值得琢磨的可能性：它的研发初衷，可能只是一个天才程序员——每天被无限的伪产品需求、反复改稿的 UI 设计、写不完的周报日报包围，一眼看穿了硅谷英雄的虚伪，但又舍不得那份舒适的待遇，于是干脆发明了一套"工作算法"：让机器替自己应付需求、画界面、写汇报。硅谷的英雄叙事之下，藏着的可能只是一个聪明的偷懒者。随后，市场上大量的同质产品故事、同质的数字化建设，给了这套算法被"激活"的土壤——GPT 被点燃，资本给它插上翅膀，才变成了今日的局面。

这个视野的价值不在于考证起源，而在于校准预期：AI 不是神迹降临，而是一个朴素的自动化愿望 + 一个巨大的同质化市场 + 资本的加速器，共同作用的结果。看清这一点，就不会把它当万能的神，也不会把它当一文不值的玩具——它有短板，和任何系统一样。

在这个视野之下，再看当下关于 AI 的两种故事模式。第一种是存量博弈的故事：工厂思维、效率优先——用 AI 降本增效、优化现有流程、压缩现有环节的人力与成本。它的叙事主体是"存量"：在已有的业务、已有的平台、已有的组织里，把每一分效率挤出来，把每一个人力省下来。

第二种是出海开拓的故事：创新、创造——用 AI 去做过去做不了的产品、服务和体验，去开辟原本不存在的市场，而不是在旧地图上抢同一块地。

这两种故事都成立，但它们都不是互联网上传播最广的那个版本。当下刷屏的"AI 压力"，仔细看或许只是一张卖 token 的营销：它贩卖焦虑，让你觉得不用 AI 就会被淘汰，却从不告诉你——焦虑不是生产力，恐惧也采购不来方案。

这篇文章不站在任何一种营销叙事上。AI 的故事要成立，必须下到自己身上、从自己的原点出发——这才是故事的生命所在：你的业务是什么？你的系统要跑多少年？你的账打算怎么算清？离开这个原点，AI 的故事要么是别人的广告，要么是自己的幻觉。而从原点出发的人很快会发现：AI 的爆发力是真的，长跑的难度也是真的——这正是全文要展开的问题。

引言：从"AI 能否生成系统"到三个更准确的问题

上一版讨论的核心问题是：AI 能不能生成一套完整的系统？但这个问题问得太粗。真正需要回答的是三个更精确的问题：

1. AI 到底能生成什么、不能生成什么？
   三种系统的技术难度完全不同，需要从真实工程过程分析 AI 的短板。
2. 软件研发工作流发生了什么变化？
   从过去"人写代码、团队协作"，转向 AI 参与需求、设计、开发、测试、部署和运营的完整流程。
3. 这种变化如何重构竞争格局？
   谁的竞争优势被削弱，谁获得新机会，哪些壁垒正从软件转向模型、算力、设备、数据和资本？

全文逻辑链条：AI 能否生成完整系统（三场景能力分析）→ 软件研发工作流重构 → 产业竞争格局重构。

第一部分：AI 能否无损创建三种不同规模的系统？

一、先改变判断标准：AI 生成代码 ≠ AI 交付系统

传统软件研发拆分为需求、设计、开发、测试、部署和维护。AI 出现后，代码生成速度大幅提高，但系统建设仍受四个关键能力制约：

这里必须区分四个常被混用的概念：

同时，"无损"本身也需要定义。所谓无损创建，至少要在六个维度上全部通过验证：

换句话说：AI 生成一个界面，不等于生成一个系统；AI 生成一个能够登录、增删改查的应用，也不等于生成一个成熟的企业软件；AI 生成一套架构图，更不等于这套架构已经经过真实流量、设备规模和故障条件的验证。

这四个阶段不能混为一谈。尤其是大型系统：代码可以生成得很快，但系统行为的验证往往需要长期运行、真实数据和复杂测试。

AI 当前最大的工程短板，不只是写错代码，而是如何保证大量生成的代码在复杂系统中长期保持正确。

"生产成熟"还意味着系统必须通过一套量化的运行考核指标。这些指标要在上线前就定义为验收标准，AI 生成的系统同样要接受同一套考核——不会因为代码是 AI 写的就放宽：

代码生成可以加速，但指标不达标就是不达标：CPU 长期满载、内存持续泄漏、P99 超时、安全漏洞未修复、对账有差异——任何一项不通过，系统都没有达到"生产成熟"，与开发速度无关。

用一个更直白的比喻来总结这一节：

系统是长跑生态，AI 就像一个"老六"冲出来，拼了个镜头，后面就没气了——哪方面都算不清，还有还要还债的感觉，对比成熟的体系。但是拦不住我们过去做的数字化交付，就交付一个首单，兴奋点或许只是初体验。

拆开看，这段话有四层意思。其一，AI 的爆发力在"生成"环节，镜头感极强——几天就能拿出一个能演示的系统；但长跑考验的是"算得清的账"：性能算得清、资源算得清、安全算得清、故障算得清，这些恰恰是冲刺覆盖不到的部分。其二，"还要还债"说的是技术债：AI 快速生成的代码，如果没有约束、测试和文档，冲得越快，欠债越多，最后都要由长期运营来偿还——成熟体系的价值，恰恰在于几十年长跑里把这笔账算得清。

其三，"首单"与"初体验"：过去数字化交付的兴奋点，往往停在首单上线那一刻；但那只是系统的初体验，不是系统的价值——系统的价值在首单之后的持续运行里。而且必须承认，过去相当一部分"交付"，本质上就是 PPT 工程 + 东拼西凑的演示系统：汇报页做得比系统好，演示数据比生产数据真实，验收当天跑得通，验收之后没人敢动。用这套标准看，AI 几天生成一个能跑的 demo，确实"超越"了大多数存量交付——但这恰恰说明比较的对象出了问题：拿演示系统当参照物，永远量不出生产系统的差距。

其四，也是最值得警惕的一层：眼下这种兴奋点的来源，恰恰是此前大量的无效建设。过去二十年的互联网平台与数字化建设，相当一部分是重复的、低效的、甚至是无效的——大量平台建完即闲置，大量系统上线即僵死，大量数字化项目长期停留在演示层和汇报层。正是这个巨大的"无效存量"，把行业基线拉得足够低，才让 AI 交付一个首单就足以让人兴奋。换句话说，兴奋不是因为 AI 交付了多了不起的东西，而是因为对照的存量太弱。

但必须看清楚：这种兴奋，对真正的支柱系统压根没影响。财务、生产、供应链、核心交易、基础设施——这些长跑系统的验收标准，没有因为 AI 出现而降低一分：该算清的账照样要算清，该还的债照样要还，该跑的年限照样要跑。镜头可以属于冲刺者，支柱只能属于长跑者。成熟体系的护城河，正是这些镜头之外的年份。

二、场景一：100 人生产型企业 ERP——AI 面对的是业务复杂度

1. 系统目标

构建一套覆盖以下模块的完整 ERP：销售订单与客户管理、采购与供应商管理、产品 BOM 与工艺路线、生产计划与工单、仓库库存与批次管理、质量检验与产品追溯、财务与成本应收应付、权限审批审计报表。

关键不是模块数量，而是模块之间的业务关系：销售订单产生生产需求 → 生产计划计算物料需求 → 采购补充库存 → 仓库执行领料 → 车间执行工单 → 质量部门检验 → 产品入库发货 → 财务结算。这是一条完整的业务链。

图 1 · ERP 业务全景图

一条完整的业务链，处处是异常

业务主链 异常流（返工/报废） 风险点 / 人工闸门

2. AI 生成 ERP 的四个主要短板

以下分析不是断言 AI 无法完成这些工作，而是指出：需要额外的业务定义、验证和工程约束。

短板 01 · 业务需求不完整。企业通常没有完整、准确、统一的业务需求文档。真实需求散落在 Excel、员工经验、历史流程、微信群和口头规则中。AI 可以根据已有信息生成系统，但无法仅凭不完整描述自动推断出企业全部真实规则——例如客户订单延期时，是否允许生产部门调整工单？是否需要销售经理审批？库存已占用怎么办？

短板 02 · 跨模块业务一致性。单个模块生成容易，跨模块一致性更难。订单、工单、库存、采购、质量和财务之间存在状态依赖。订单修改后若未同步调整库存预留和生产计划，系统会出现"数据表面正确、业务实际错误"的情况。

举一个最典型的例子：客户订单已经确认，生产工单已经下达，原材料已经领用——这时候客户修改订单数量，系统应该如何处理？如果工单已开始生产、原材料已消耗、产品已入库甚至已发货，修改订单会涉及多个模块，这不是生成一个"修改订单"的接口就能解决的，它需要一套完整的业务规则链：

订单变更 → 生产计划调整 → 物料需求重新计算 → 库存校验 → 成本调整 → 财务处理 → 变更记录

ERP 的核心壁垒不是页面，而是业务状态之间的正确关系。

短板 03 · 历史数据迁移。企业原有数据常存在重复客户、物料编码不统一、库存账实差异、历史订单缺失等问题。AI 可以辅助清洗和映射，但无法通过代码生成保证历史数据真实准确——数据迁移必须经过业务核对、抽样、对账和验收。

短板 04 · 生产异常与财务边界。生产企业存在报废、返工、补料、拆单、合单、退货、成本差异等大量异常。AI 可以生成处理流程，但每一种异常的业务责任、数据影响和财务规则必须明确定义，不能依赖模型自行猜测。

3. ERP 的新研发工作流

传统路径是"先选 ERP 产品 → 实施顾问配置 → 定制开发补齐需求"。AI 参与后可以形成新工作流：

图 2 · ERP 新研发工作流

AI 负责生成，人负责闸门

AI 自动环节 上线节点 人工闸门（不可跳过）

4. ERP 的真正竞争变化

ERP 领域的 AI 竞争，不一定首先发生在大型厂商之间，而可能首先发生在：软件实施成本、定制开发效率、行业业务知识、数据迁移能力、企业系统集成和持续服务能力。

传统 ERP 厂商拥有成熟产品和业务经验；AI 原生团队拥有快速构建和定制优势；企业内部团队拥有真实业务知识和数据。未来的竞争可能是：谁能把企业业务知识转化为可靠、可持续运行的软件系统，谁就有机会大幅降低传统 ERP 的实施和定制成本。但对于财务、制造、质量和供应链等核心流程，成熟产品的标准化能力仍是重要优势。

过去，一家 100 人企业要建设成熟 ERP，通常需要企业软件产品、实施顾问、业务流程梳理、软件开发团队和长期维护升级。AI 的出现使企业能够用更小的团队构建更符合自身业务的系统，但不代表 ERP 厂商会立即消失——成熟 ERP 的价值还包括行业经验、业务流程、实施能力、客户数据迁移、财务合规、售后和长期维护。真正受到冲击的，可能是依靠高昂定制费用、低效率开发和复杂实施流程获得利润的软件服务模式。

图 3 · ERP 系统架构

真正的难点是跨模块一致性

业务模块 平台 / 状态依赖 人工闸门

图 4 · ERP 部署拓扑

数据必须经过业务核对才能进入生产

应用层 数据主库 复制链路 人工闸门

三、场景二：千万级流量 + 1000 万 IoT 设备——AI 面对的是系统规模与可靠性

1. 系统目标：先把规模算清楚

目标系统：接入 1000 万台 IoT 设备、支持千万级业务流量的分布式系统。规模指标必须先定义：假设每台设备每分钟发送一条 1 KB 的消息，则吞吐量为 R = 10⁷ ÷ 60 ≈ 16.7 万条消息/秒；如果设备每秒发送一次，则达到 1000 万条消息/秒。

这意味着设计必须明确：设备接入数量、在线连接数、消息吞吐量、峰值流量、数据保存周期和业务响应时间。不能把设备数量直接等同于并发量。

目标指标可以先定义清楚：

另外要注意：千万级流量必须明确是日请求量、峰值并发，还是每秒请求数——口径不同，架构成本、网络带宽、消息队列、存储能力和计算资源完全不同。

图 5 · IoT 接入全景

先算清规模，再谈架构

数据主链路 设备异常流 必须显式定义的语义

这套系统至少需要考虑：

• 设备身份认证与连接管理；
• 消息接入和流量控制；
• 消息队列与数据缓冲；
• 实时计算和数据聚合；
• 分布式存储；
• 数据一致性；
• 服务发现与负载均衡；
• 故障隔离与恢复；
• 监控、告警和运维；
• 安全、权限和设备生命周期管理。

2. AI 生成分布式系统的四个主要短板

短板 01 · 架构正确性与规模验证。AI 可以生成微服务、消息队列、数据库和部署配置，但"生成了架构"不等于"架构能扛住目标吞吐量"。某消息处理服务单机测试正常，在大量设备同时上线时可能因连接管理、内存占用和资源竞争出现问题。

短板 02 · 分布式一致性。IoT 设备可能重复发送、断线重连、延迟发送或跨节点迁移。系统必须明确：消息是否允许重复？哪些操作必须幂等？设备状态如何更新？最终一致性如何保证？消息顺序是否重要？AI 可以生成相关机制，但必须针对真实业务验证。

短板 03 · 故障与恢复。分布式系统真正困难的是异常状态：节点失效、消息队列积压、网络中断、数据库故障、局部服务异常。AI 生成的代码能处理常见错误，但复杂故障组合需要系统化测试和真实运行数据。

短板 04 · 资源成本与调度。千万设备规模下，连接数、消息速率、存储和计算资源之间直接耦合。AI 可以提出调度策略，但资源配置必须通过压力测试、容量规划和实际监控确定——不能靠加服务器解决所有架构问题。

但是，生成一个分布式架构，与证明这个架构能承受目标规模，是两回事。真正需要验证的是：

• 设备同时上线时，系统会不会崩溃？
• 消息堆积时，系统能不能恢复？
• 某个节点故障时，数据会不会丢失？
• 网络抖动时，设备会不会产生大量重复连接？
• 数据重复发送时，业务会不会重复执行？
• 流量突然增长时，系统能不能扩容？
• 系统扩容后，数据分区和资源分配是否合理？

这套系统的难点不是代码数量，而是系统行为。1000 万设备并不一定需要超级复杂的单体架构——合理的边缘计算、消息分层、数据聚合和分布式部署，可能比简单增加服务器更重要。AI 可以帮助设计和实现，但规模化能力必须由真实测试、运行数据和故障验证证明。

3. 分布式系统的新研发工作流

图 6 · 分布式系统新研发工作流

压测不过，就回炉重来

研发环节 验证 判定闸门 失败回路

与 ERP 的关键区别在于验证对象不同。ERP 主要验证业务流程是否正确；分布式系统需要验证吞吐量、延迟、连接规模、资源消耗、故障恢复、数据一致性和扩展能力。

AI 可以参与架构设计和代码生成，但分布式系统的最终交付，必须建立在可重复的性能测试和可靠性验证之上。

4. 这个场景的竞争格局

分布式系统的竞争不止于软件开发能力，还涉及云平台、数据中心、网络基础设施、消息系统、数据库、设备接入平台和运维安全体系。传统云厂商拥有成熟基础设施和服务生态；AI 原生企业可以借开源技术、云服务和自动化开发快速构建系统，但需承担规模验证、成本控制和持续运营责任。

竞争门槛不会因为 AI 能生成代码而消失，而是从"如何开发系统"转向"如何以合理成本持续运行系统"。

图 7 · 分布式系统架构

可靠性机制必须显式设计

系统分层 机制约束作用点 可靠性清单

图 8 · 多可用区部署拓扑

任何单点失效都不能拖垮全局

服务节点 数据库主 复制 / 转移 故障注入

四、场景三：大型 AI 系统——AI 面对的是模型、计算与产品的协同

1. 系统目标：先区分两种完全不同的任务

大型 AI 系统不是聊天应用，它包含前端产品、用户身份与权限、API 服务、请求路由、模型推理、工具调用、上下文管理、数据处理、模型训练、GPU 集群、监控运营。必须区分两种工程任务：

• 用已有模型构建 AI 产品
  ——可以利用现有模型、云服务和开源技术完成；
• 训练有竞争力的大型基础模型
  ——还需要训练数据、模型设计、计算资源、训练基础设施、评估体系和大量工程优化。

两者难度完全不同，混为一谈是常见误判。

图 9 · 大型 AI 系统全景

调用模型 ≠ 训练模型

产品/推理链路 模型发布 数据闭环 外部系统

2. AI 生成大型 AI 系统的四个主要短板

短板 01 · 模型能力 ≠ 代码生成能力。AI 可以生成调用模型的程序，但模型本身的能力取决于训练数据、模型结构、训练方法、参数规模和计算资源。生成一个模型服务，不等于训练出一个有竞争力的基础模型。

这里要特别明确：模型权重不是全部训练数据。训练数据经过处理、筛选、组织和训练，最终形成模型参数；模型参数保存在模型文件中，通过推理计算参与输出。而用户数据、上下文、工具、业务数据库和模型权重，是不同的系统组成部分。因此，AI 系统不是简单地把互联网数据装进一台机器——它需要一个完整的生产体系。

短板 02 · 模型训练与计算优化。大模型训练涉及 GPU 资源、分布式训练、数据并行、模型并行、通信开销、内存管理和训练稳定性。AI 可以辅助生成训练代码，但无法仅凭代码生成证明训练效率和模型效果。

短板 03 · 推理系统的资源调度。大模型推理需要处理上下文长度、并发请求、显存使用、批处理、模型加载和延迟。规模化推理场景下，内存、显存、网络带宽和计算资源的关系直接决定系统成本。

短板 04 · 产品、模型与运营闭环。用户体验不只由模型决定：产品还要处理需求理解、上下文、工具调用、权限、异常、内容安全和服务质量。模型输出的评估同样关键——不能把用户反馈直接等同于训练数据，更不能未经处理就自动用于训练。

3. 大型 AI 系统的新研发工作流

图 10 · 大型 AI 系统新研发工作流

模型与产品的双螺旋

产品链路 模型链路 数据闭环 人工闸门

这里的新变化是：过去产品研发和模型研发相对分离，现在 AI 产品开发可以把模型调用、工具使用、前端体验、业务数据和自动化流程组合在一起。但模型训练和模型推理，仍然需要独立的工程体系。

4. 大型 AI 系统的五层竞争门槛

图 11 · 大型 AI 五层架构

越往下，约束越硬、资本越重

产品/系统层 模型层 基础设施层 硬约束

AI 降低了产品层和应用层的开发门槛，但大型模型的训练与推理仍受计算资源和工程效率约束。大型 AI 企业的竞争，是模型、系统、基础设施、产品和商业运营的综合竞争——既不只是模型能力竞争，也不是简单的资本竞争。

五、三个场景的能力边界：真正的差异是什么？

随着系统规模和复杂度增加，AI 生成代码的价值仍然存在，但验证、资源调度和持续运行的重要性同步上升。

不能简单地说"AI 能生成 90% 的代码，就意味着能完成 90% 的系统工程"。代码生成率与系统交付率不是同一个指标。

六、软件研发工作流的根本变化

这是第一部分要落的结论：过去软件研发围绕人力组织和代码生产展开，现在 AI 开始参与整个软件生命周期。

传统工作流：需求 → 架构 → 人工开发 → 人工测试 → 部署 → 维护。

AI 参与后的工作流：需求与业务资料 → AI 需求分析 → 系统规格与约束 → 架构设计 → AI 代码生成 → 自动化测试 → 人工审查 → 部署与监控 → 运行反馈。

但真正的关键在下一步：成熟的 AI 研发工作流，不应该让 AI 从一句需求直接生成整个系统、一次性部署，而应该采用：

需求分解 → 系统约束 → 模块生成 → 自动测试 → 人工审查 → 集成验证 → 灰度部署 → 运行反馈

其中系统约束是最重要也最容易被忽略的一环：ERP 的约束是业务状态、财务规则、数据一致性；分布式系统的约束是性能、可靠性、数据一致性、资源成本；大型 AI 的约束是模型质量、推理延迟、资源调度、安全。AI 必须在约束下生成代码——没有约束，AI 生成的代码可能看起来完整，但无法保证满足真实业务要求。

同时必须强调：业务规则不能随便改。业务规则是系统的宪法——每一次变更都必须经过评审、影响分析、灰度验证和回归测试。AI 让修改代码的成本大幅下降，但这恰恰放大了"随手改规则"的风险：一次未经评估的规则变更，会在下游模块产生连锁反应，造成"数据表面正确、业务实际错误"，其代价远高于一个普通的代码 bug。系统约束的意义，就是把"随便改"变成受控地改：谁提出、谁审批、影响哪些模块、如何回归验证、何时生效、如何回滚——全部要有记录、有责任人。

新的研发角色

这些角色不必然意味着增加岗位——同一个人可以承担多个角色。真正变化的是：企业需要重新定义哪些工作由 AI 完成、哪些必须由人负责、以及如何验证 AI 的结果。

第二部分：AI 正在如何重构产业竞争格局？

真正的变化不是"所有企业都在用 AI"，而是不同类型的企业正在利用 AI 重新组织自己的竞争优势。

一、第一条主线：传统软件厂商 vs AI 原生企业

传统软件厂商的优势来自长期积累：成熟产品、行业业务知识、客户关系、数据迁移经验、企业实施能力、产品稳定性、长期服务体系。AI 原生企业的优势来自新的研发方式：更低开发成本、更快产品迭代、更灵活的业务定制、更小团队规模、AI 与业务流程的深度结合。两者的竞争不是"旧软件被 AI 替代"，而是两种生产方式之间的竞争：

哪些软件最先受到冲击？不是所有软件，而是具备以下特征的——功能相对标准化、业务逻辑清晰、需求容易描述、价值主要通过界面和流程提供、定制开发成本高、客户可用 AI 快速构建替代方案。典型如简单 CRM、内部审批、基础报表、业务表单、轻量管理系统和部分行业定制工具。

但具有复杂行业知识、深度集成、长期数据积累和强监管要求的软件，不会因 AI 能生成代码就立即失去竞争力。传统软件厂商真正要面对的问题是：客户是否还愿意为过去的开发和实施成本支付同样的价格。

二、第二条主线：门户竞争 vs AI 入口竞争

过去，互联网门户的竞争围绕用户入口展开。现在，AI 正在改变用户获取服务的方式：用户不再打开多个应用主动寻找，而是直接向 AI 提出目标，由 AI 完成信息检索、业务分析、工具调用和部分操作。

用户可能不再需要主动进入每一个软件，而是通过 AI 入口调用不同软件的能力。竞争焦点随之改变：传统门户竞争用户访问量、页面停留、广告、交易和应用使用；AI 入口竞争用户任务、模型能力、工具调用、业务流程和用户上下文。

新的竞争关系将出现在：搜索平台竞争 AI 信息入口、企业软件竞争 AI 工作流入口、电商平台竞争 AI 商品发现与交易入口、企业服务平台竞争 AI 业务代理、AI 产品竞争用户习惯和任务完成能力。

但门户不会必然消失——门户仍可能拥有品牌、用户关系、交易系统、产品内容、业务数据、供应链、支付和履约能力。更准确的判断是：

AI 可能削弱门户对用户访问路径的控制，但不必然削弱门户背后的业务资产。竞争重点将从"用户是否进入我的网站"，转向"用户通过 AI 完成任务时，是否调用我的服务"。

三、第三条主线：高级架构师与高级程序员的价值重构

这里需要谨慎：AI 能生成代码，不意味着高级架构师和高级程序员会被整体消灭。因为大型系统的复杂性不只来自代码编写，还来自需求不确定性、系统边界、数据一致性、复杂故障、业务责任、性能成本和安全合规。

人才竞争将出现三个变化：① 基础开发能力的稀缺性下降——AI 帮助更多人完成常见编程任务；② 系统判断能力的价值上升——企业需要能判断架构是否正确、系统是否可靠的人；③ 人才组织方式改变——减少重复性开发工作，同时增加系统设计、AI 工作流、质量和运营责任。

未来高级架构师的竞争可能转向：

高级程序员真正面临的竞争，不是"AI 能不能写一段代码"，而是：如果一个人的竞争优势主要来自编写代码，当 AI 能完成大量类似工作时，他必须重新定义自己的价值——价值不再主要来自写代码的速度，而是来自能否定义正确的问题、构建正确的约束、识别系统风险，并确保最终结果成立。这是人才结构变化，不是人才消失。

四、第四条主线：模型平台 vs 云平台 vs AI 应用企业

产业链呈分层结构：芯片与计算设备 → 云计算与数据中心 → 基础模型平台 → AI 开发工具 → AI 应用企业 → 客户与用户 → 业务数据与反馈。

芯片与计算设备企业：竞争计算性能、内存带宽、能源效率、供应能力、设备生态和软硬件协同。芯片竞争与 AI 应用竞争相关联，却不要求所有应用企业承担同样的资本投入。

云计算与基础设施企业：竞争 GPU 资源、网络、存储、数据中心、资源调度、企业服务和运行成本。云平台把基础设施能力转化为可购买、可调用的服务，因此可能成为 AI 时代最重要的基础设施供应商。

基础模型企业：竞争模型能力、训练数据、推理效率、模型评估、产品体验、开发者生态和企业客户。但模型能力越强不等于商业竞争必然越强，还要看用户是否愿意使用、企业是否愿意付费、推理成本是否可控、是否具备持续迭代能力。

AI 应用企业：不必自己训练基础模型，竞争优势可能来自对某个行业、某个业务流程或某类客户需求的深度理解。

五、资本竞争：AI 为什么可能形成新的技术高墙？

资本竞争需要拆成两个层次。第一层：软件生产资本下降——AI 减少部分重复开发：小型企业获得软件能力的门槛降低；传统软件厂商的定制开发业务面临价格压力；AI 原生企业获得更快的产品迭代能力。第二层：大型 AI 基础设施资本增加——GPU、高带宽内存、高速网络、存储系统、数据中心、电力、散热，这些都是资本密集型资源，大型模型训练和大规模推理服务正在形成新的基础设施竞争。

但要注意：资本门槛不是所有 AI 企业都必须面对的同一条门槛。企业可以选择自建基础设施、使用云平台、调用外部模型、部署开源模型或混合架构。真正需要巨额资本的，主要是那些要控制大型模型训练、基础设施和规模化推理能力的企业。

真正值得关注的是：AI 可能同时降低应用层的进入门槛，并提高大型基础设施层的竞争强度。这不是矛盾——因为应用开发与基础模型训练，是两个完全不同的成本结构。

软件开发门槛下降，系统规模化门槛仍然存在，大型 AI 基础设施的资本门槛可能上升——由此形成一个新的产业结构：

六、第五条主线：设备与内存，是否成为新的竞争门槛？

1. 模型运行对内存的真实需求。设备配置决定了：模型能否运行、能用多大的模型、能处理多长上下文、能支持多少并发、推理速度和成本。

2. 内存不是唯一瓶颈。还受 GPU 算力、内存带宽、网络通信、存储访问、模型量化、推理调度和数据传输约束。增加内存可能解决某些限制，但不能自动解决全部性能问题。

3. 设备门槛可能形成新的市场分层：

图 12 · AI 数据中心拓扑

显存、带宽、电力同时决定成本

推理集群 训练集群 存储 网络 / 电力

七、谁可能获得优势？竞争能力矩阵

与其预测某类企业必然胜出，不如建立竞争能力矩阵（软件与产品能力 × 基础设施能力 × 业务与运营能力）：

• 传统软件厂商
  ：拥有成熟产品、客户和业务经验，但需要适应 AI 研发模式；
• AI 原生企业
  ：具有开发和迭代优势，但需要建立客户、业务和系统可靠性；
• 云与模型平台
  ：拥有基础设施和模型能力，但需持续优化成本、产品和生态；
• 行业企业
  ：拥有真实业务知识和客户资源，可以利用 AI 建立自己的系统能力。

这里的逻辑不是"AI 生成代码 → 所有人失业 → 资本垄断"，而是"AI 生成代码 → 软件生产成本下降 → 企业系统建设能力扩散 → 竞争转向系统质量、规模、资源、产品和运营"。在不同层级，竞争结果可能完全不同：小型企业可能因为 AI 获得过去没有的软件能力；中型企业可能因为 AI 重构内部流程，减少对外部软件服务的依赖；大型企业可能利用 AI 加速已有技术体系，进一步扩大产品和基础设施规模；而大型 AI 平台之间，则可能围绕模型、计算资源、用户入口和资本展开更激烈的竞争。

未来的竞争不再是单一企业之间的竞争，而是不同层级的企业通过合作、整合和生态竞争，重新分配产业价值。

八、最终结论：AI 不是消灭竞争，而是改变竞争发生的位置

竞争门槛并不是简单消失，而是发生迁移：软件开发门槛下降 → 系统规模化门槛仍然存在 → 大型 AI 基础设施的资本门槛可能上升。在这个基础上，有五个判断：

1. 软件开发门槛正在下降。
   AI 让更多企业获得系统建设能力，传统软件开发模式面临效率和价格压力。
2. 系统工程难题仍然存在。
   业务一致性、分布式可靠性、模型质量、生产验证和持续运营，不能通过代码生成自动解决。
3. 研发工作流正在重构。
   从以人工编写代码为中心，转向需求定义、AI 生成、自动测试、工程审查和持续运营。
4. 竞争壁垒正在迁移。
   部分优势从代码生产转向系统设计、业务知识、数据、产品、基础设施和资本。
5. AI 产业竞争正在形成新的分层。
   应用企业可以通过调用模型降低基础设施投入；大型模型和基础设施企业仍要面对高强度的计算、网络、设备和资本竞争。

附：下一步研究建议——把竞争分析落到可验证的产业问题

1. 软件替代边界
   ：哪些 ERP、CRM、门户和企业应用最容易被 AI 原生系统替代？哪些依赖行业数据、复杂流程和长期实施经验，短期难以替代？
2. 研发成本变化
   ：AI 对需求分析、代码生成、测试、部署和维护分别产生什么影响？哪些成本下降，哪些成本转移到验证和运营？
3. 基础设施竞争
   ：大型模型训练、推理服务、千万级设备和企业应用，对 GPU、内存、网络、存储和能源的需求分别是什么？
4. 产业价值重新分配
   ：传统软件厂商、AI 原生企业、云平台、模型平台、芯片企业和行业客户，分别可能获得什么优势，又会失去什么优势？

最终可形成更完整的研究主题：《AI 时代软件产业竞争重构：从代码生产、系统架构到算力资本》——它将把三个系统的技术分析，真正连接到产业竞争、人才战略和资本战略。