为什么AI几分钟就能写完代码，改系统却要三周？

有个老板最近问我们：“现在 AI 写代码这么快，为什么我们改个预留库存的功能，还是要两三周？”

这是个好问题，但是问反了。

AI 确实能在三分钟内写出一个“预留”按钮，连前端带后端，还能自动生成测试用例。但这家企业系统缺的不是代码，而是业务规则还没被翻译成机器能读懂的语言。AI 再快，也快不过“这个需求到底谁拍板”的会议。

新增一个销售渠道，要改订单、改库存，还要确认采购和财务会不会受影响。业务等着上线，开发迟迟给不出日期。这时候会议很容易变成对 IT 的追问：系统是我们自己做的，为什么连自己的需求都改不动？

对于已经做出海多年、手里有一批自研系统的企业，在决定下一笔钱投在哪里之前，最好先弄清楚：一个看起来简单的需求，到底在哪一步变复杂了。

否则今天被归结为“自研不行”的问题，换了 AI 工具、换了开发团队，几年后可能还会回来，而且可能回来得更快。

01

先看一笔本来很普通的订单

一家做平台零售的企业，开始接经销商订单。海外仓有 1000 件货，经销商要预留 300 件，下周提货。

销售觉得，加个“预留”状态就行。可这批货还在仓库里，其他渠道还能卖多少？如果仍按仓库实物数推库存，平台上继续显示 1000 件。经销商的货已经答应出去，零售订单又把同一批货卖了一遍。

零售可用量要从 1000 里减去预留的 300，剩 700。经销商取消 100 件，可用量回到 800。最后 200 件出库，实物库存降到 800，预留结束，可用量还是 800。

算术很简单，难的是让所有系统一直按同一套规则算。

订单取消了 100 件，库存端有没有释放？仓库出库后，预留有没有同步核销？原来的平台库存同步程序，能不能识别已经被占用的数量？采购算补货时，是不是又把这笔需求算了一遍？

一个“预留”按钮，背后连着一组需要共同成立的业务关系。ChatGPT 或者 Claude 能把这个按钮的代码写得漂漂亮亮，但它不知道的是，在经营过程中，经销商取消订单时要不要通知采购，也不知道仓库出库后预留该不该自动过期。这些规则从没有人写清楚过。

02

AI越能写代码，人越懒得写文档

一个反直觉的现实：AI 让写代码的成本趋近于零，反而可能让系统更难维护。

以前改一个功能，至少要写设计文档、画流程图、开会确认影响范围。现在有了 AI，一个人半天就能改完代码部署上去“试试”。试成功了，规则就多了一条没人记得的例外；试出了问题，再让 AI 修。几轮下来，系统里堆满了“当时能跑”的逻辑，却没有人能说清楚全貌。

企业内部那些真正值钱的知识——哪些客户可以提前锁货，预留多久，旺季怎么分配——在老员工的脑子里，在某个微信群的历史记录里，或者在飞书某个再也没人打开的文档中。它们没有流动起来，没有形成 SOP，更没有成为 AI 可以检索的上下文。

换句话说，如果企业没有将业务沉淀成文档，AI 在写代码时检索不到上下文，只能去猜最通用的做法。但对于大多数已经形成独特路径的企业来说，“通用做法”反而是最致命的。

03

需求只提了一次，规则可能要改很多遍

早期只做平台零售，直接把仓库库存同步到渠道，够用了。后来加了经销商、独立站、线下，库存用途变多，最初那条简单规则就不够用了。

如果每次扩展业务，都由当时的开发在系统各处加一段判断，同一项库存分配规则就可能散落在订单系统、库存接口、补货程序和运营报表里。新需求一来，团队先要找齐这些地方，再确认谁还在用旧算法。

AI 当然可以“找齐这些地方”，甚至能生成影响分析文档。但它分析的前提是：这些规则曾经被写进过某个它能读到的地方。现实中，大量的判断写在代码注释里、写在临时的 Excel 里、或者根本没写，只靠当事人记得。

一天能写完的代码，可能要几周才能确认影响。时间花在查依赖、找业务确认、补历史数据上。这不是 AI 不够聪明，是业务知识还没有被结构化。

还有一种等待发生在开发动手之前。经销商预留了 300 件，平台马上要做促销，两个渠道都要求优先供货。经销商还没付款，预留是否继续有效？零售毛利更高，能不能临时拿走这批货？

这些问题需要企业做经营决定。系统可以实现七天预留，也可以实现付款后锁货，但它无法代替销售、运营和财务决定哪种安排更合适。

如果每次冲突都由某个开发临时找负责人拍板，系统里很快会留下更多互相例外的规定。下一次改动，团队又得重新找人解释。业务规则迟迟定不下来，也会表现为“研发交付慢”。

AI 能加速“写代码”这一步，但它加速不了“想清楚规则”这一步。甚至在某些团队，AI 让写代码太快了，快到“想清楚”这一步被直接跳过。

所以整理系统时，要明确划分已经确认的业务规则、尚待决定的经营选择，以及确实需要改造的程序。前两项可以请合作团队协助梳理，但决策仍需由企业作出。责任说清之后，才好判断需要多少开发工作，也才能看出成熟产品究竟可以接走哪一部分。

讨论重做系统容易走向两个极端：一边觉得多年代码都是资产，舍不得动；另一边觉得历史包袱太重，最好全部清掉。

代码写了多少年，无法单独回答它值不值得保留。

仍以前面的经销商业务为例。哪些客户可以提前锁货，预留多久，超过期限能不能自动释放，旺季是否优先保障已承诺客户——这些决定包含了企业的客户关系、服务承诺和渠道策略。它们需要被准确带进下一阶段。

当年为了赶上线写在某个接口里的特殊判断，可能已经找不到保留的理由。有些规则甚至早已失效，只是没人敢删。

梳理自研资产时，要把业务理由找回来。每条特殊规则服务谁、现在是否还用、由谁决定修改，应该能够说清楚。有效的规则留下来，过时的做法一并清理。

这里有一个关键动作：把规则写下来，变成企业的内部知识库。不是为了AI，是为了让下一次改动时，不需要再靠老员工回忆。这件事本身，就是在为企业构建RAG的素材。

要解决这个问题，企业不必把下一轮建设全部交给内部团队从头完成，也不必全部买断现成软件。

行业里一种已被验证的模式是“深度共建”——不是简单买一套标准软件，也不是完全从零自己开发，而是各取所长：复用成熟底座的通用能力，只开发企业特有的规则。例如彬匠科技的数字经营底座，就是将商品、订单、库存等通用能力模块化输出，企业只需专注于共建自身的核心差异化逻辑，再与需要保留的旧系统连接起来。

但一个方案能否减轻维护压力，不能只看功能清单。

同样写着“库存管理”，有的产品已经处理了预留、部分释放和出库核销；有的只提供库存数字，相关业务仍需重新开发。两者演示时可能都有漂亮页面，项目工作量却相差很大。

比较方案时，可以把前面那 300 件预留订单完整走一遍。预留后，零售端收到什么数量？取消 100 件，哪里发生变化？剩余 200 件出库后，哪些记录结束，哪些保留？再追问一句：如果下个月改成“不同等级客户有不同预留期限”，需要改哪些地方？

这能看出产品已有的能力，也能看出企业的特殊要求将放在哪里。如果接入新产品后，仍要在多个外围系统复制同一条规则，后续维护压力就没有消失。

06

共建之后，内部IT要更清楚地掌握什么

引入合作团队以后，内部 IT 仍需要掌握企业的业务规则，以及这些规则在系统中的实现位置。业务提出改变时，要能判断影响，知道该找谁实施，也知道怎样验收。

日常处理同样如此。平台库存推送失败，业务首先联系谁？谁查订单，谁查仓库回传，谁负责把正确数量重新送出去？如果这些工作只能靠临时拉群，企业依然要投入大量精力维持系统运转。

产品升级也值得提前走一遍。底座升级之后，定制的客户预留规则怎样继续生效？原有业务由谁检查？发生异常，谁决定暂停升级或恢复旧版本？

谈到源码时，也应该沿着同一条线追问。企业能拿到哪些代码，授权允许做什么，开发环境能否重建，关键业务有没有说明，离开原团队后由谁接手。

重构方案不能只说明新系统上线那一天是什么样。企业还要看上线之后，下一次业务变化会怎样发生。

第一阶段可以先做通经销商预留到仓库出库这一条链，同时检查平台零售有没有受到影响。系统切换时，还没提走的预留订单如何迁移，已取消的数量怎样核对，旧接口什么时候停，都需要与功能一起安排。

如果现有自研只需整理少数模块就能做到，继续改造有充分理由。如果通用能力长期占用研发资源，而成熟产品经过验证确实能够承担这部分工作，共建就有了可以比较的价值。

在决定“继续自研还是推倒重来”之前，不妨先拿出最近一次拖了很久的需求。把业务的原话、实际改动和受影响的系统放在一起，看看时间究竟耗在了哪里。

同时，也看看内部那些“只能问老张才知道”的规则，有没有被写下来。

这比买任何一个 AI 工具都重要。

彬匠科技 · 企业数字化深度诊断

面向业务复杂度已超出标准化系统边界的企业，彬匠科技以一体化中台、BI与AI为核心，贯通全球市场、渠道、供应链、财务与组织协同，构建支撑可持续增长的数字经营底座。从深度咨询、方案设计到持续迭代，提供长期的经营工程服务，让系统适应企业，而不是让企业适应系统。

欢迎扫码添加资深顾问微信，预约 1 对 1 企业数字化架构与业财体系深度诊断。

关注彬匠科技，获取更多数字化转型方案与企业赋能干货