关于软件行业、技术价值与企业生存的思考

客户预算在压缩，项目报价一降再降，需求却没有减少；以前需要一个开发团队干几个月的事情，现在借助 AI，几个人可能就能做出一个能跑的版本。技术人员的数量没有明显减少，但市场对技术人员的需求似乎正在发生变化。

有人说是经济周期，有人说是行业内卷，有人说是 AI 抢了程序员的饭碗。

这些说法都没有错，但我认为，它们只是现象。

真正值得警惕的是：软件行业赖以生存的价值分配方式，正在发生变化。

如果站在一个软件公司技术负责人的位置上看这个问题，我更关心的不是明年用什么框架、哪个技术会流行，而是一个更现实的问题：

如果今天重新组建一家公司，我们还会按照过去的方式招聘、研发、交付和经营吗？

如果答案是否定的，那么过去那套已经运行了十几年的软件生产体系，究竟还有多少东西值得保留？

一、行业没有消失，只是过去的赚钱方式正在失效

先说一个容易被忽略的事实。

软件行业并没有停止增长。

根据工信部公布的数据，2025 年我国软件和信息技术服务业软件业务收入达到 15.48 万亿元，同比增长 13.2%；但同期利润总额增长 7.3%，明显低于收入增速。

这组数据值得琢磨。

行业收入仍在增长，但收入增长并没有等比例转化为利润增长。它至少说明，不能简单地用行业规模判断一家软件公司的经营状况。

市场还有需求，但赚钱越来越考验企业的能力。

过去的软件公司，尤其是以项目制为主的公司，商业模式其实相当直接：

拿到客户需求，组织产品、设计、开发、测试，经过几个月交付系统，按照合同收取项目款。

项目越多，收入越高；团队越大，理论上的交付能力越强。

这套模式在过去很长一段时间里是成立的。

因为软件开发有较高的专业门槛，客户没有能力自己完成，企业也缺少成熟的技术团队。软件公司掌握着技术、人才和交付能力，自然拥有一定的议价空间。

但现在，这种优势正在被削弱。

一方面，低代码、云服务、开源软件和 AI 编程工具不断降低软件开发门槛；另一方面，客户越来越清楚自己究竟需要什么，也越来越有能力判断软件开发的真实成本。

以前一个功能需要开发人员研究几天，现在可能几个小时就能完成。

以前一个管理后台需要前后端多人协作，现在一个熟练使用 AI 的开发人员就能快速搭建出原型。

这里真正发生的变化不是开发速度提高了多少，而是客户开始重新审视：我为什么还要为过去那些昂贵的开发过程支付那么多钱？

当客户发现相同的业务结果可以用更低的成本获得，原有的软件定价体系自然会受到冲击。

所以，软件公司真正面临的危机，并不是没有需求，而是过去依靠技术稀缺性获得的利润空间正在收窄。

这两件事完全不同。

二、AI 并没有消灭软件开发，而是在拆解软件公司的成本结构

我不太赞成把 AI 简单理解为程序员的替代品。

如果从软件企业经营的角度来看，AI 更像一次生产关系的重构。

过去的软件研发是一种高度依赖人工协作的生产过程。

产品经理整理需求，架构师设计系统，开发人员编写代码，测试人员验证质量，运维人员负责部署和运行。

每个环节都需要人，每个人都需要时间，最终形成软件产品。

但 AI 正在改变其中大量重复性、规则明确、可以被描述和验证的工作。

代码生成、单元测试、接口文档、SQL 编写、代码审查、问题定位，甚至需求分析和技术方案初稿，都开始具备自动化的可能。

这意味着什么？

意味着软件公司的成本结构将发生变化。

过去，企业的核心生产资源是人。

一个项目需要多少人、多少个月，基本决定了它的成本。

现在，企业逐渐拥有了另一种生产资源：AI 所提供的智能劳动能力。

一个优秀的工程师，借助 AI，可以承担过去多人才能完成的部分工作。

但这里有一个非常容易犯的错误：

开发效率提高，不等于企业利润自然提高；代码生成成本下降，也不等于软件产品的商业价值下降到零。

因为软件开发从来不只有写代码。

客户说要一个订单管理系统，真正困难的可能不是订单表怎么设计，而是：

• 不同业务部门对订单的定义是否一致？
• 历史数据如何迁移？
• 订单状态流转是否符合实际经营流程？
• 多个系统之间的数据如何保持一致？
• 权限、审计、异常处理如何设计？
• 系统上线后出现业务损失，谁来负责？

AI 可以帮助完成其中大量技术工作，但这些问题的答案并不会因为代码生成得更快而自动出现。

甚至有时候，AI 让错误的方案更快地进入系统。

我见过一种很危险的研发思路：需求没有想清楚，直接让 AI 生成代码；功能跑通了，就认为项目完成了。

这不是研发效率提高，而是把原本发生在开发阶段的问题，推迟到了测试、上线和客户使用阶段。

软件行业过去有一个隐性成本，叫做沟通、理解、协调和纠错。

这些成本不会因为代码生成速度提高就消失。

所以，未来软件企业真正需要优化的，不只是程序员写代码的速度，而是从业务理解到交付验收的整个生产链条。

如果一家企业只是把 AI 当作一个免费的程序员，却不改变需求管理、架构设计、质量控制和交付机制，那么它最终得到的可能只是更多、更快、更难维护的代码。

三、软件公司最大的经营误区：把项目数量当成企业竞争力

站在架构负责人的位置上，我认为很多软件公司的问题，其实在于经营思维。

有些公司看起来业务很多，团队几十人，项目排得满满当当。

但仔细看，会发现一个问题：

每接一个新客户，就重新做一套系统；每来一个新需求，就增加一批代码；每做一个新项目，就产生一套新的技术债务。

公司看起来在不断积累项目，实际上并没有积累多少可以重复利用的资产。

项目交付结束，团队解散，代码留在客户服务器上，下一次遇到类似需求，又从头开始。

这是一种典型的劳动密集型软件经营模式。

它有一个致命弱点：收入依赖持续投入人力。

只要项目停下来，收入就可能跟着停下来。

更麻烦的是，随着项目数量增加，维护成本也在增加。

不同客户有不同的代码分支、不同的部署环境、不同的数据库结构、不同的版本管理方式。

几年下来，企业积累的不是规模优势，而是一堆越来越难维护的历史包袱。

这种公司最怕什么？

不是没有项目，而是项目越来越多，却越来越不赚钱。

从财务角度看，合同金额是收入，真正留下来的才是利润。

一个报价 100 万的项目，如果投入 15 个人做一年，后期还要持续免费维护，未必比一个报价 30 万、两个月完成、可以标准化复用的产品更有价值。

这就涉及一个被很多技术公司忽视的问题：

软件研发必须从项目交付思维，逐渐转向资产经营思维。

什么是资产？

不是代码写了多少行，也不是系统部署了多少台服务器。

而是下一次遇到相似需求时，企业能不能以更低的成本、更短的周期、更稳定的质量完成交付。

一个成熟的权限中心、一套统一的工作流引擎、一套经过验证的多租户体系、一套可复用的行业业务模型、一套自动化部署和监控体系，都可能成为企业真正的技术资产。

但需要注意，不能为了复用而复用。

没有真实业务需求支撑的所谓平台化，很容易演变成另一个烧钱项目。

架构师最应该回答的，不是这个系统能不能抽象成一个平台，而是：

这部分能力未来是否会被反复使用？抽象之后能否降低总成本？维护这个平台的代价是否小于重复开发的代价？

如果不能回答这些问题，那么所谓技术沉淀，很可能只是技术人员的一厢情愿。

四、真正有价值的技术，正在从代码层向业务层迁移

过去，技术人员经常用技术栈来定义自己的竞争力。

会 Spring Cloud、会 Kafka、会 Redis、会 Kubernetes，似乎就代表具备了较强的技术能力。

这些当然重要。

但如果我是公司的技术负责人，在评估一个架构师时，我不会只问他掌握了多少技术。

我更想知道：

他能不能理解公司的业务模式？能不能发现业务流程中的低效环节？能不能判断哪些需求值得做，哪些需求不应该做？能不能在有限预算下设计出能够持续演进的系统？

因为技术本身正在逐渐商品化。

数据库可以购买托管服务，消息队列可以使用云产品，基础组件有大量成熟的开源方案，AI 还能帮助完成代码实现。

如果一个技术团队的主要价值只是把成熟技术组件组合起来，那么它的议价能力必然会受到影响。

真正难以复制的，是对特定行业的理解。

举一个简单的例子。

两个团队都能开发一套设备管理系统。

第一个团队擅长 Java、Vue、MySQL，能够快速完成设备档案、设备列表、数据展示、用户管理。

第二个团队除了这些能力，还理解设备运行规律、故障处理流程、巡检制度、售后服务体系、设备生命周期管理，知道客户真正关心的是设备停机时间、维修成本和故障追溯。

这两个团队最终交付的东西，可能在技术实现上差别不大。

但客户愿意为谁支付更高的费用？

答案往往不难判断。

因为客户购买的不是一个页面，也不是一套数据库。

客户购买的是业务问题的解决方案。

这也是为什么我认为，未来软件行业的竞争会逐渐从技术实现能力，转向行业知识、业务理解和结果交付能力。

技术决定你能不能做出来。

业务理解决定你做出来的东西有没有用。

而商业能力决定客户愿不愿意持续为它付费。

三者缺一不可。

五、软件行业正在出现分化：通用功能越来越便宜，复杂业务越来越值钱

并不是所有软件都会受到同样程度的冲击。

我认为，未来的软件市场会出现比较明显的两极分化。

一类是标准化程度高、业务规则简单、替代成本低的软件。

例如简单的管理后台、常规数据录入系统、基础报表、简单审批、通用信息展示页面等。

这类软件的特点是需求容易描述，功能容易实现，市场上替代方案很多。

过去它们能够形成一定的项目收入，是因为开发成本和交付成本比较高。

但当开发成本下降，客户又能够通过成熟产品、AI 工具或小团队快速实现时，这部分市场必然面临更激烈的价格竞争。

另一类是业务复杂、系统耦合深、数据价值高、交付责任重的软件。

例如工业控制、供应链协同、能源管理、医疗信息化、金融核心系统、复杂企业运营系统等。

这类软件的难点并不在于页面有多少，而在于业务规则、系统集成、数据一致性、安全合规、运行稳定性，以及长期服务能力。

它们不会因为 AI 能生成代码就突然变得简单。

甚至随着企业引入 AI，原有系统的数据治理、权限体系、业务接口和安全机制会变得更加重要。

当然，这并不意味着所有行业软件都有高利润。

行业复杂度高，也可能意味着销售周期长、实施成本高、客户个性化严重。

真正值得进入的领域，必须同时考虑客户付费能力、需求复用程度、交付成本和持续服务收入。

所以，软件公司的战略选择不应该是盲目追逐热门行业，而是找到一个自己能够深入理解、持续积累、重复交付的细分市场。

与其做一个什么都能做、什么都做不深的软件公司，不如成为某一个具体业务领域里真正懂行的技术服务商。

市场从来不缺会写代码的人。

市场缺的是能够把复杂问题真正解决掉的人。

六、架构师的职责必须改变：不能只对技术负责，还要对经营结果负责

我想重点谈谈架构师。

因为我认为，在这轮行业变化中，架构师是最应该重新审视自身定位的一群人。

过去，一个架构师的工作可能是：

选择技术栈、设计系统边界、拆分微服务、制定编码规范、解决性能问题、指导团队开发。

这些工作仍然重要，但已经不够了。

如果你负责一家软件公司的技术体系，却不知道公司的项目毛利率，不知道哪些产品线长期亏损，不知道研发投入和实际收入之间的关系，那么你的架构设计很可能只是技术意义上的正确。

而不一定是经营意义上的正确。

举个例子。

公司准备承接一个客户项目，客户提出要采用微服务架构、容器化部署、分布式事务、统一消息中心。

架构师当然可以设计一套完整的技术方案。

但他应该先问几个问题：

第一，这个客户的业务规模是否真的需要这么复杂的架构？

第二，项目预算是否能够覆盖这套架构带来的研发和运维成本？

第三，客户是否具备相应的运维能力？

第四，这套技术体系未来能否复用到公司的其他项目？

第五，系统上线后，谁来承担长期维护成本？

如果这些问题没有答案，那么技术方案再漂亮，也可能成为公司的经营负担。

我一直认为，好的架构不是把系统设计得多么复杂，而是在业务目标、成本、风险和可演进性之间找到平衡。

架构的第一原则，不是技术先进，而是经济合理。

这句话在当下尤其重要。

未来的架构师，至少应该具备四种能力：

1. 业务建模能力

能够理解客户的真实业务，而不是简单地把需求文档翻译成数据库表和接口。

2. 成本控制能力

能够判断技术方案的投入产出，知道哪些地方值得投入，哪些地方应该使用成熟产品，哪些地方不值得重复造轮子。

3. 资产沉淀能力

能够把项目中的共性能力沉淀为组件、平台、工具和标准化交付方案，让企业的研发投入产生长期收益。

4. 交付治理能力

能够控制需求变更、研发质量、部署风险、系统稳定性和后期维护成本，让软件真正进入客户的生产环境，而不是停留在演示环境。

说得直接一点：

以前架构师更多是在解决系统如何构建的问题。

现在，架构师还必须考虑这套系统为什么值得构建，以及公司能不能通过它持续赚钱。

七、未来的软件公司，可能不再需要过去那么庞大的研发团队

这句话可能不太好听，但我认为应该正视。

AI 不一定会让所有程序员失业，但它很可能改变软件企业的人员结构。

过去一个项目可能需要产品经理、UI 设计师、前端开发、后端开发、测试、运维等多个角色共同参与。

未来，这些角色的工作边界可能会发生变化。

一个人可能借助 AI 完成需求分析、原型设计、代码实现和基础测试。

一个小型技术团队可能承担过去一个中型团队的部分工作。

这不是简单的人员减少，而是组织协作方式的变化。

我认为未来的软件团队会逐渐呈现几个特点：

第一，团队规模缩小，但单人责任边界扩大。

企业不再单纯依靠增加人数来提高产能，而是更加看重个人解决完整问题的能力。

第二，技术岗位与业务岗位的边界进一步模糊。

开发人员需要理解业务，产品人员需要理解技术，架构师需要理解经营。

只懂自己那一亩三分地的人，会越来越难适应新的组织模式。

第三，研发团队的评价标准发生变化。

代码量、提交次数、开发工时，这些指标本来就不能准确衡量研发价值。

未来更应该关注需求交付周期、线上缺陷率、变更失败率、系统可用性、客户问题解决效率，以及单位研发成本创造的业务价值。

第四，质量控制的重要性反而会上升。

当代码生成变得便宜，代码审查、测试覆盖、架构约束、安全检查、数据验证和生产监控就必须更加严格。

因为一个错误如果能够在几分钟内生成，也可能在几分钟内被复制到多个业务模块。

团队人数减少，并不意味着管理责任减少。

恰恰相反，组织越精简，越需要明确的工程标准和质量机制。

这也是为什么我不认同一种极端观点：有了 AI，就不需要架构师、测试人员和技术管理者了。

工具可以替代部分劳动，但不能自动承担企业的系统性责任。

八、软件公司究竟应该如何活下去？

谈了这么多，最后回到最现实的问题。

如果今天我负责一家软件公司的技术和架构体系，我会优先推动以下几件事情。

1. 重新审视业务结构，停止没有利润的规模扩张

不是所有项目都值得接。

尤其是那些需求不明确、预算不足、个性化程度极高、客户又不愿意支付维护费用的项目。

接项目之前，必须算清楚：

• 获客成本是多少？
• 研发投入是多少？
• 实施和部署成本是多少？
• 后期维护需要多少资源？
• 项目能否形成可复用资产？
• 客户是否存在持续付费的可能？

如果一个项目只能带来一次性收入，却需要长期投入人力维护，那么它可能不是资产，而是一笔延迟兑现的负债。

企业应该从追求合同金额，转向关注项目全生命周期利润。

2. 从项目制研发转向产品化与行业解决方案

不是让所有公司都去做 SaaS。

SaaS 也有获客、续费、运维和客户成功成本，产品化并不天然等于赚钱。

真正应该做的是，把反复出现的业务需求识别出来，形成标准产品能力。

例如：

• 通用用户、组织、权限体系；
• 标准化业务流程和审批能力；
• 统一消息、文件、任务和通知服务；
• 行业特有的业务模型；
• 标准部署、升级、监控和运维工具。

客户需要的个性化部分通过配置、扩展机制和有限定制实现。

这样才能逐渐摆脱每个项目都重新开发一遍的困境。

3. 把 AI 真正融入研发生产链，而不是只让程序员使用 AI 写代码

企业应该建立自己的 AI 研发规范。

从需求分析、技术方案、代码生成、代码审查、自动化测试，到部署验证和线上问题分析，逐步形成完整的 AI 辅助研发流程。

但必须有明确的质量边界。

例如：

• 需求必须有可验证的验收标准；
• 核心业务代码必须经过人工审查；
• 关键流程必须有自动化测试；
• 数据库变更必须经过审核；
• 安全和权限逻辑必须有专项验证；
• 生产发布必须具备回滚和监控机制。

AI 的目标不是让企业少雇几个人就结束了，而是让同样的资源能够交付更多可靠的业务价值。

4. 建立真正可控的技术资产，而不是盲目追逐技术热点

我会重新梳理企业现有的技术体系。

哪些服务可以统一？哪些模块重复建设？哪些系统存在严重的架构债务？哪些技术组件已经没有必要继续维护？

该合并的合并，该替换的替换，该下线的下线。

对于没有业务价值的复杂度，坚决做减法。

对于能够产生长期复用价值的核心能力，持续投入。

尤其要避免为了追逐微服务、云原生、AI Agent 等技术名词而增加不必要的系统复杂度。

技术选型不是技术展览。

公司不是为了证明自己掌握了多少先进技术而存在的。

5. 建立交付之后的持续收入

我认为这是很多传统软件公司的薄弱环节。

过去很多公司把项目验收当成终点。

但对于真正有价值的业务系统来说，验收只是开始。

系统需要持续升级、数据治理、性能优化、安全维护、业务调整和运营支持。

如果企业能够从一次性交付，逐渐转向软件订阅、技术服务、运维保障、功能升级和行业增值服务，就有机会建立更加稳定的收入结构。

当然，前提是客户确实愿意持续为这些服务付费。

持续收入不是靠合同里多写几个服务条款，而是靠持续创造客户愿意购买的价值。

九、真正危险的不是 AI，而是企业失去了重新认识自己的能力

写到这里，我想说一个可能比技术变化更加重要的问题。

软件行业过去十几年的发展，让很多企业形成了一种惯性：

有客户就招人，有项目就开发，有需求就加功能，有问题就继续投入人力。

这套逻辑曾经帮助很多公司发展壮大。

但当市场环境变化、开发成本下降、客户议价能力提高时，企业就必须重新回答一个问题：

我们究竟凭什么存在？

如果一家软件公司没有自己的产品，没有行业积累，没有独特的交付能力，没有稳定的客户关系，也没有能够持续产生收益的技术资产，那么它和一个临时拼凑起来的开发团队有什么区别？

如果一家公司的核心竞争力只是拥有几十个会写代码的人，那么当市场上出现更便宜、更高效的生产方式时，它必然会陷入被动。

同样，对于技术人员而言，也需要重新认识自己的价值。

不要把自己局限在某个框架、某种语言、某个技术岗位上。

技术只是解决问题的工具。

真正能够穿越行业周期的，是理解问题、分析问题、组织资源、承担责任并最终解决问题的能力。

我不认为未来的软件行业一定会变得更糟。

相反，随着技术成本下降，过去很多因为开发成本过高而无法实现的需求，可能会重新获得商业机会。

小企业可以拥有过去只有大型企业才负担得起的信息化能力；独立开发者可以服务过去难以触达的细分市场；传统行业也有机会以更低的成本完成数字化改造。

但机会不会平均分配。

那些只会重复生产标准化代码、缺乏业务理解、没有客户积累、无法承担交付责任的企业和个人，会面临越来越大的压力。

而那些能够深入行业、理解客户、控制成本、沉淀资产、持续交付价值的人，反而可能获得新的发展空间。

这不是技术淘汰人的故事。

这是一次价值重新分配的过程。

写在最后

如果让我用一句话概括当下软件行业的变化，我想说：

过去，软件公司靠组织人力生产代码赚钱；未来，软件公司必须靠组织技术解决问题，并持续创造商业价值赚钱。

代码会越来越便宜，技术工具会越来越普及，开发门槛也会越来越低。

但真正理解一个行业、看懂一家企业的经营逻辑、把复杂业务变成可靠系统，并且让这套系统持续产生价值，仍然不是一件容易的事情。

所以，不必过分怀念过去那个只要会写代码就能获得不错回报的时代，也不必因为 AI 的出现就否定技术本身的价值。

时代没有承诺任何一种职业可以永远保持原来的价格。

对于软件公司而言，应该重新审视自己的商业模式；对于技术管理者而言，应该重新审视自己的经营责任；对于每一个技术人员而言，则应该重新审视自己究竟能够为市场解决什么问题。

技术不会消失，但仅仅掌握技术，可能已经不够了。

这或许才是软件行业正在经历的，最值得我们认真思考的一次变化。