这篇只讲一件事：AI 让系统开发变快了，但一批项目在半年后卡在同一个地方——没人敢改。
适合两类人：正在做系统建设的甲方负责人，和需要向老板解释"为什么这个需求做不了"的 IT 负责人。全文约 2400 字，读完 7 分钟。
先把结论放前面：AI 降低的是"把东西做出来"的成本，没有降低"把东西改下去"的成本。这两件事在项目里是两笔账，而多数合同只算了前一笔。
「这套系统是去年上的，现在没人敢动。」
说这句话的是一位运营负责人。他不是在抱怨供应商，他是在解释一个明显该改的流程，为什么拖了四个月还没改。
具体是这样：想加一个字段，报价三周；想改一个审批节点，对方说要评估；原来做这个项目的团队已经换人，新接手的工程师第一句话是"我先读一遍代码"。他甚至不确定读完之后能不能改。
他最后补了一句：这套系统能用，但不能碰。
「能用但不能碰」这个说法，我们今年听到的次数比去年多。原因不在供应商变差了。原因是开发方式变了，验收方式没变。
过去两年，AI 编程工具把"从零到能演示"的成本压得很低。有开发者在公开记录里写过：用 AI 代码智能体独立做完一款小游戏，188 个测试全部通过，工期压到原来的四分之一。
这是个人项目。边界清楚，需求不变，一个人说了算。企业系统不是这个形状：需求会变，参与的人会换，用的人不读代码。
所以真实的成本结构是这样的：第一版是一次性投入，从第二版开始是复利。每改一次，如果改动落在没人理解的地方，系统就多一层补丁。补丁叠到第三层，改动成本会超过重写——但重写没人敢提，因为业务正在上面跑。
AI 压的是第一版的成本。它把第一版做快了，同时把第二版的理解成本推高了。因为它写代码的时候不需要理解你的业务，只需要让代码跑通。
不是所有 AI 参与的项目都会变成黑盒。判断标准也不复杂，看三个信号就够。
信号一：改动报价里出现"重构"两个字。一个字段、一个节点、一张报表，本来是小改动。如果回复里出现"这块要重构一下"，意思通常是现有结构撑不住这个改动。第一次出现可以理解，第二次、第三次出现，说明结构已经不是这次需求的问题了。
信号二：业务方开始用 Excel 打补丁。系统里改不动，人就绕过去。你在系统外看到一张每月手工维护的表，那多半是系统的一个缺口。缺口会自己长大，因为用得顺手的东西，人不会再交回去。
信号三：接手的人要先"读一遍代码"。正常的系统，新工程师看结构和文档就能上手。如果接手的第一个动作是通读源码，说明文档和代码已经不一致，或者从来没有过。这时候系统唯一的说明书就是源码本身，而这份源码可能是 AI 和人混着写的。
为什么会这样。要讲清楚，得说一件不太技术的事。
人写代码的时候，很多决定是在代码之外的：为什么这个字段叫这个名字，为什么这个判断放在这一层，为什么这里特意留了一个空。这些决定背后是对业务的理解。写的人当时知道，读的人后来能猜出来。
AI 生成代码时，这些理解不存在。它按概率选一个看起来合理的写法。语法对，能跑，边界情况不一定对。它没有"为什么"，只有"通常这样"。
结果就是：AI 生成的代码，写起来便宜，读起来贵。这个差距在第一版看不出来——那时候所有人都在看功能跑通没有。它要到第二版才显形，而第二版通常已经是半年后，人已经换了一轮。
有一个细节能说明这类风险长什么样。InfoQ 前段时间发过一篇文章，标题本身就是一个问题：Agent 删库的事故反复出现，几十年前就有的数据库防呆机制为什么不管用了。
答案不复杂。那些机制设计的前提，是操作的人会犹豫一下。二次确认、软删除、权限分级，本质上都是给"犹豫"留出时间。Agent 不犹豫，它按指令连续执行。
这不是说 Agent 危险。它说明一件事：过去很多安全设计，依赖的是人的谨慎。当执行者不再谨慎，边界就必须写在系统里，而不是写在流程里、写在培训里、写在"大家注意一下"里。
系统的可维护性也是同一个道理。过去它依赖"写代码的人还在"。当写代码的可能是 AI，或者是一个已经离场的团队，可维护性就必须变成合同里能验收的一条，而不是一句期待。
说回能操作的部分。下面四件事，甲方在合同和验收阶段就能做，不需要懂技术。
一、合同里写"可维护性"，不只写"源码交付"。源码给了不等于能改。可以加一句能被验收的表述：交付物应支持第三方在无原团队参与的情况下完成常规需求变更。这句话不解决全部问题，但它把"能不能改"从一个主观判断，变成了有争议时能拿出来说的条款。
二、验收时做一次"陌生人改造测试"。找一个没参与过这个项目的人，可以是你们自己的 IT，也可以是另一家供应商。限时两小时，让他加一个字段、改一个审批节点。做不到，就是不能改。这个动作比看一百页功能清单有用，也比任何承诺可靠。
三、关键路径要有自动化测试，不是覆盖率数字。不用追求覆盖率。只问四条：下单、扣库存、对账、审批，这四件事有没有能自动跑一遍的测试。有，改动就有安全网；没有，每次改都是在没人知道后果的情况下动一条正在跑的业务。
四、把 AI 用在错得起的地方。生成测试用例、生成接口文档、生成数据迁移脚本、清洗历史数据——这些错了代价低，能回滚，能重来。不要让 AI 直接决定扣多少库存、这笔钱记到哪个科目、这个客户能不能放账。这些地方要的是确定，不是概率。
最后一句话可以直接用：下一次验收，别只看功能清单跑通没有。加一个动作——让一个没参与过这个项目的人，当场改一个字段。
改得动，这套系统是你的。改不动，你只是租了一个能用但不能碰的东西，而且租金已经付完了。
一句话总结：AI 让第一版更便宜，让第二版更贵。判断一个项目值不值，看第二版。
你们的系统，上一次改动花了多久？加一个字段、改一个节点，从提需求到上线，用了几天。留言说说，我一条条回。
如果这个时间超过两周，可以约一次「AI 落地可行性诊断」。一个小时，我们先把这套系统的改动成本拆开算一遍，分清是该补结构，还是该重做。
