AI 编程时代的软件护城河：谁来维护你构建的系统？

软件本身正在成为更弱的护城河。过去，企业在自建与采购之间做选择时，往往更倾向于采购。构建真正能承担业务的软件，需要专业知识、跨团队协调，以及能把明确想法落地成产品的团队。实现功能本身，就是一道不低的门槛。

AI 编程工具正在改变这个判断。我可以把一篇公开论文、一款产品或一个有用的工具交给 Claude，让它提取值得借鉴的技术和思路，再研究如何应用到我们自己的产品中。过去需要多轮交接才能完成的分析与实现，现在可以在一次连续工作中推进。

这让更多想法值得尝试，也让竞争对手已经展示出来的功能更容易被复制。我的判断是，软件中越来越多难以替代的价值，将来自对它在生产环境中的行为负责。

如果你的公司在 AI 编程出现之前，就擅长构建和可靠运行定制软件，现在可能是一个格外有利的时机。你可以把已有的工程能力应用到更多机会中。

AI 编程如何改变自建还是采购的决策？

AI 降低了定制软件的实现门槛，因此企业能否承担后续运维，在采购决策中的分量更重了。一个小型内部工具、一项特殊集成，或一个过去不值得单独投入开发预算的流程，现在可能都值得构建。

Anthropic 于 2025 年 8 月对 132 名内部工程师和研究人员开展的调查显示，受访者估计，他们借助 Claude 完成的工作中，有 27% 原本不会开展。这是受访者自我报告的估计。阅读 Anthropic 的研究。

由此可以推导出的战略含义很直接：实现成本下降，可能创造更多软件需求。过去只维护少量内部工具的团队，可能决定再构建几个。每增加一个工具，就要持续回答谁来支持、谁来更新，以及何时停用的问题。

本文讨论的是借助 AI 开发的普通业务软件。应用本身可能完全不包含 AI。用 Claude 编写的订单集成，仍然需要把正确的订单送到正确的地方。

为什么功能越来越难形成软件护城河？

软件护城河，是让一家企业难以被替代的竞争优势。过去，高昂的实现成本能提供一定保护：即使对手已经理解了某个功能，也可能需要几个月才能做出类似产品。

AI 压缩了其中一部分工作。竞争对手可以研究公开界面、理解工作流程，并更快构建替代方案。因此，功能的价值越来越取决于周围的能力：客户触达、有用数据的获取、客户关系，以及持续兑现承诺的能力。

以供应商门户为例。竞争对手可以复刻页面，但客户还需要正确的权限、可信的订单状态、准确的记录，以及故障发生后能够解决问题的支持。产品通过这套完整体验赢得信任。实现门槛与可靠运维能力，是两种不同的资产。

我们的 Laya 与 Jev 对比分析讨论了模型性能层面的类似问题。本文关注的则是围绕具体模型或编程工具构建的业务软件。

什么是软件运维护城河？

软件运维护城河，是在系统不断变化时，仍能持续让依赖软件的业务结果保持可靠的能力优势。它结合了对系统的理解、工程纪律和明确的责任归属。客户感受到的是订单正确送达、记录值得信任，以及问题能够得到解决。

基础设施是其中一部分。应用还需要合理的权限、有用的测试、可观测的工作流程、受控的发布，以及可信的恢复方案。服务器技术指标正常，系统仍然可能正在处理错误的信息。

DORA 2025 年的研究显示，AI 采用程度与更高的交付量、更好的产品表现相关，也与较低的交付稳定性相关。作者将 AI 描述为组织的放大器。这些相关关系不能确立因果关系。阅读 DORA 的研究发现。

我的理解是，实现速度越快，成熟的运行与维护实践就越有价值。团队生成变更的速度，可能超过理解这些变更如何相互影响的速度。能把更多产出转化为可靠改进的组织，才有机会获得业务优势。

AI 生成软件有哪些隐性的运维成本？

设想一家 B2B 企业要把客户门户接入 ERP 系统。这是一个假设案例。编程智能体帮助创建连接器、映射字段，并添加状态页面。第一笔订单成功通过，看起来很有说服力。

当这个流程遇到日常故障时，运行和维护的责任才会变得清晰：

无论代码由什么工具编写，这些责任都会存在。它们带来集成支持、安全更新、故障响应和后续修改的工作量。AI 生成软件的运维成本，还包括在系统行为偏离业务预期时，重新理解它所花费的时间。

在技术实施层面，我们的 AI 生成代码质量保证指南介绍了验证方法。经济决策则应更早开始：在庆祝生成速度之前，先决定公司是否愿意长期负责这个流程。

自建、采购还是混合方案：先比较长期责任

当工作流程能创造有意义的优势，而且企业有预算承担后续运维时，可以自建。如果现有产品已经能把工作做好，其持续服务也值得付费，可以采购。当特定业务逻辑需要定制，而标准能力可以直接采购时，可以将两者结合。

比较时，应使用相同的工作流程、使用量、可靠性目标和时间范围。计入开发与集成、持续发生的许可证与基础设施费用、日常工程投入、合理的故障成本情景，以及最终迁移或停用的成本。同一份人员工时不要在多个类别里重复计算。

对于不确定的故障成本，可以保留不同情景。小概率但会中断订单处理的事故，与一份内部报表延迟完成，值得讨论的重点不同。开发报价很低，仍然可能意味着需要承担不小的长期责任。

我们的定制软件与现成软件采购指南介绍了更完整的采购决策。对于 AI 辅助开发项目，还应增加一个明确的决策条件：谁负责运行和维护，拥有怎样的权限、能力、时间与预算？

AI 生成的软件应该由谁维护？

应由一个明确指定的团队对生产环境中的业务结果负责，并为它提供维护所需的权限、时间和决策权。这个团队可以来自内部、外部，也可以按清晰的约定共同承担。输入提示词、做出第一版的人，并不一定适合长期负责整个系统。

在同事或客户开始依赖一个原型之前，先回答以下七个问题。它们可以构成责任说明，但不能替代技术评审。

1. 谁来响应？明确负责人和备份负责人。约定支持时段、哪些故障需要响应，以及谁有权暂停工作流程。
2. 什么必须正常完成？定义业务结果和可接受的服务目标。订单集成应能端到端追踪和核对订单。
3. 谁可以执行什么操作？记录权限、特权访问，以及凭据如何存储、轮换和撤销。检查账户遭到入侵后的影响。
4. 怎样发现故障？监控已完成的业务结果、停滞的任务和异常变化。告警必须发送给有能力采取行动的人。
5. 怎样控制有问题的变更？根据影响安排测试并控制发布。明确如何暂停或回退部署，以及如何修复已经被修改的数据。
6. 怎样恢复？实际测试相关的恢复或重放流程。确认最多可以接受多少数据损失，以及业务最多能等待多久。
7. 变化之后，责任怎样延续？确保代码仓库、依赖信息和运行说明可供接手者使用。提前考虑人员变动、供应商变化和系统停用。

Google 的 SRE 工作手册介绍了先评估小范围生产发布、再扩大范围的方法。这样可以减小错误变更的影响。阅读其金丝雀发布指导。

流程的严格程度应与后果相匹配。只有两位同事使用的只读工具，可以有简单的负责人安排和恢复计划。支付或订单流程需要更严格的控制。两者都受益于在首次上线之后，仍然有人明确负责。

为什么经验丰富的工程团队更有机会获得优势？

已经理解部署、权限、集成故障和恢复的团队，可以把这些经验应用到 AI 让开发变得可行的更多软件中。现有的工程纪律，让组织能够接住更多工作，而不必依赖某一个人的记忆。

Google 的 SRE 指南将事故复盘与共享经验、落实改进联系起来。目的是改善系统，并把后续变更执行到位。阅读其从事故中学习的方法。

当这些经验改善下一次发布、下一项集成和下一次交接时，运维护城河才会逐步形成。存在多年的组织架构本身很难提供保护。持续学习、简化系统，并能够证明恢复能力的团队，拥有更有价值的优势。

这也解释了为什么软件更多，并不一定更好。成熟团队会移除重复工具、控制依赖数量，并停用已经不值得继续维护的流程。AI 给了他们更多实现选项，而他们的判断决定哪些选项值得长期运行。

AI 也能帮助运行和维护软件吗？

可以。AI 能辅助理解日志、起草测试、调查故障和更新运行说明。代码产出增加后，这些实践会更重要，其中一部分工作同样可以得到 AI 的帮助或实现自动化。

责任仍然需要明确归属。必须有人决定哪些结果重要、自动化系统可以采取哪些行动，以及高风险变更需要什么证据才能执行。如果智能体能够修改生产环境，这些边界就需要落实到系统权限和操作流程中。

随着工具进步，可持续的竞争优势也会继续变化。我更看好那些能够反复做出合理运维决策、把故障转化为系统改进的组织。大量工作可以得到辅助，对结果负责仍然是产品的一部分。

从你已经负责的软件开始

在委托开发下一批内部工具之前，先检查当前已经运行的软件。为每个关键业务流程记录负责人、依赖关系、故障信号、恢复流程和持续成本。那些还没有答案的地方，可能会因开发产能增加而扩大风险。

在 Wavect，我们会用这样的方式规划一个 AI 辅助定制软件开发项目：明确结果，构建有用的部分，并清楚约定运行与维护的责任。我们的已匿名处理的数据分析平台案例提供了另一项产品交付的背景。上文的订单集成是用于说明问题的假设案例。

讨论你的业务流程应该自建还是采购时，可以带上正在考虑的系统、故障可能造成的成本，以及上线后能够负责的团队。这些信息，比单独一份功能清单更适合作为决策起点。

构建软件的能力已经不再稀缺。可靠运行这些软件的能力，仍然稀缺。