AI能写代码了，软件护城河还在吗？

又一份商业计划书摆上桌。又一家创业公司承诺"取代定制软件开发"。又一位分析师宣称编程已成大宗商品。又一位LinkedIn意见领袖宣布开发者即将失业。

这套话听了十八个月。然而——企业软件支出并未崩盘。专业服务公司持续招人。COBOL程序员照样拿高薪。

认知偏差出在哪？

被忽视的护城河

传统软件护城河围绕代码构建：专有算法、累积功能、工程纪律、复制所需的纯苦力。两年加两千万美元才能造出等价物？这就是你的护城河。

AI压缩了这条时间线——针对绿地开发，从零开始。但大多数企业软件是棕地：数十年累积的代码、无文档的业务逻辑、只有深度参与的某个开发者才理解的集成点……或是退休工程师写的黑箱，没人完全懂。AI在棕地撞上了硬限制。这是本文焦点。

上下文困境（暂时的）

AI助手在固定"上下文窗口"内运作——工作记忆约20万到100万token（1个token约等于3/4个单词）。听着宽裕，直到你意识到企业系统横跨数百万行、数千文件。上下文管理当下是大问题——智能体当前任务所需的一切（文件、提示、工具指令等）必须同时塞进上下文窗口……否则智能体根本不知道其存在。更糟的是，上下文窗口首尾元素被赋予更高权重（类似人类认知的首因效应和近因效应），中间混乱部分会被淡化。会话运行越久，性能越差，因为东西被丢弃腾空间或干脆丢失……这状况有时叫"上下文腐烂"。这会严重拖累表现。

现在，让AI修改一个涉及七个服务、三个数据库、两个外部API的计费计算。你会得到自信满满的建议，愉快忽略大部分未被显式提及的复杂度。AI不知道自己不知道——这毛病人类也有，但它执行烂方案更快。

这个上下文挑战是今天的问题，但解法正在路上。递归语言模型（RLM）现已能分解任意规模的代码库，分析片段，跨整体综合理解。18到36个月内，"代码库太大"不再构成护城河。（注意RLM听起来像个物件，实则是种策略，任何大语言模型都能用）

即便上下文问题解决了，还有更顽固的障碍。

集成泥潭

典型企业系统不是单体应用，是几十个系统的纠缠网络。SAP实例与1990年代定制的COBOL模块对话，通过2010年代的中间件层，连到去年买的SaaS工具。文档？部分有。准确？从不。理解这一切的人？退休了，或在竞争对手那，或两者兼具。

AI能写集成代码。它读不懂组织为何以这种特定方式配置SAP，因为十五年前某次收购的税务原因，且没人敢动。它看不到部门A和部门B用同一字段存不同含义数据，因为2008年合并时没统一。

这些不是技术问题，是组织考古学。AI没有 shovel。

合规与审计轨迹

金融服务、医疗健康、政府——受监管行业需要可审计的决策轨迹。不是"AI建议我们这样做"，而是"人类在2023年3月批准此逻辑，基于当时有效的监管解释，由合规官X签字"。

AI生成的代码可以正确，但无法携带这段历史。替换遗留系统意味着重建审计轨迹，这常比重写代码更贵。

变更管理的真实成本

最被低估的护城河：企业软件的真正成本不在构建，在变更管理。部署新系统意味着重新培训数千用户、重写内部文档、调整下游流程、处理十八个月的例外情况。

AI加速代码生成，不加速组织学习。事实上，它可能拖慢：当代码生成太快，文档和培训材料跟不上，你得到的是没人懂如何维护的系统。

什么真正可防御

既然代码生成正在商品化，护城河转向别处：

数据网络效应：系统使用越多，数据越好，产品越难替代。不是训练AI的数据，是客户实际业务数据——配置、工作流、集成模式。

组织嵌入：软件深度嵌入客户运营节奏，替换成本远超许可费。是流程、习惯、 muscle memory。

合规认证：特定行业的认证和审计关系，建立耗时数年，AI无法加速。

人机混合服务：最持久的模式可能是软件加专业服务——AI处理常规，人类处理异常和关系。纯AI产品竞争的是边际成本趋零；混合模式竞争的是信任和持续服务。

代码正在民主化。但软件业务从未真正关于代码——它关于解决组织问题，而组织问题 stubbornly 保持非线性、非文档化、非自动化。AI是强大工具，不是替代架构。护城河变了位置，没消失。