定制系统技术债：为什么半年后没人敢改

先给结论：定制系统不是越用越顺，而是越用越僵、直到没人敢碰。根因不在程序员，而在系统的“形态”：业务规则被埋进代码，而不是沉淀成可审查、可迁移、AI 能读懂的元数据。

先说个扎心的事实：很多公司花大价钱定制的内部系统，真正”好用”的时间，往往只有半年。

不是它坏了，是没人敢动了。

加个字段、改个审批、对接个新工具——你一开口，技术那边就皱眉：“这个改起来有点麻烦。” 报个价、排个期，一来二去你也懒得提了。系统就这么定格在了第一版，像一栋盖好就再也不许动的房子，你住在里面，却连挂幅画都要先打报告。

这篇文章想说清三件事：系统是怎么一步步僵死的、这背后你没算过的一笔账，以及为什么在 AI 时代，这个老问题会更早暴露。

一个你大概率似曾相识的场景

某家做贸易的公司，2019 年花了三十多万，定制了一套订单管理系统。上线那阵子老板很满意：下单、对账、库存联动，比 Excel 强太多了。

五年过去，业务变了：多了几条产品线，加了经销商分级，财务想要一个新口径的报表。老板找回当年那家外包，对方报价：改造 18 万，工期两个月，“而且有些地方耦合太深，建议干脆重做。”

老板懵了。当年三十多万买的东西，现在想往前挪一步，要再花一半的钱、等两个月，还被劝重做。 更要命的是，当初写这套系统的那个工程师，早就离职了，没人说得清里面到底是怎么转的。

这不是个例。我们见过太多这样的公司——区别只是金额和行业。

系统是怎么一步步”僵死”的

几乎每套定制系统，都会走完这四步：

第一阶段：上线，真香。 流程跑通，老板满意，团队省事。这是蜜月期，通常持续不到半年。

第二阶段：开始打补丁。 业务在变，需求不断来。这里加个判断、那里塞个特例，系统里慢慢长出一堆”只有当时那个人知道为什么”的逻辑。每个补丁单看都合理，叠在一起就成了一团乱麻。

第三阶段：那个人走了。 外包结项、员工离职、技术换岗。代码还在硬盘上，但真正的那套规则，是装在他脑子里的，他一走就带走了。 留下的注释和文档，常常停留在三年前的版本。

第四阶段：没人敢动。 新来的人接手，改一个地方，不知道会牵连哪三个地方，越改越虚。最后大家达成默契：能不动就不动。于是系统从”资产”彻底变成了”负债”——你离不开它，又升级不动它，每年还得为它的服务器和维护持续付钱。

算一笔很多老板没算过的账

大多数老板只记得第一笔：定制花了多少钱。但一套僵死的系统，真正贵在后面那些没记进账本的地方：

• 改动成本越来越高：第一年加个功能也许几千块，第三年同样的改动报价翻几倍——不是变难了，是没人敢保证不出事，于是把风险打进了报价。
• 等待的代价：一个本该当天上线的小调整，排期两周。这两周里，业务在用变通办法、人工补差错，这些时间没人计入系统成本，但它实实在在地烧钱。
• 绑定一个人的风险：整套系统只有一个人能改，这个人就成了公司的”单点故障”。他要离职、要加薪、要请假，你都得看系统的脸色。
• 错过的机会：竞争对手三天能上线的新玩法，你因为”系统改不动”要两个月——有些窗口，错过就没了。这笔账最大，也最隐形。

把这些加起来你会发现：定制系统真正的成本，不是你付出去的那几十万，而是它僵死之后，每一年都在悄悄收的”过路费”。

根因不在程序员，在系统的”形态”

你可能会想：是不是当初找的人不行？换个更牛的团队就好了？

大概率一样。因为问题不出在某个人的水平，而出在传统系统天生的形态：

它的本质，是一大堆只有写的人才看得懂的代码，业务规则深埋其中。这种形态决定了三件事必然发生——

• 难传承：规则藏在代码里，等于把公司的业务知识”私有化”进了某个工程师的大脑。人走了，知识就断了。
• 难修改：没有人能一眼看清全貌，改动就成了拆违章建筑，拆哪根柱子都心惊胆战。
• 难被理解：不只是人难懂，任何后来者——包括 AI——接手时都一样懵。

记住这第三点，因为它正是接下来这场变化的关键。

AI 时代，这个老问题会更早暴露

现在每个老板都想给业务加上 AI。于是你回头看自己这套系统，想接个 AI 进去帮忙——

结果发现：AI 也读不懂它。

那一团缠在一起的代码，AI 接手时和一个刚入职的程序员一样，看不懂、不敢动。所以很多公司的 AI 项目，最后都卡在同一句话上：“你这个系统，得先重做。”

这就引出一个残酷但越来越真实的判断：

未来 AI 能不能帮到你，很大程度上取决于一件事——你的系统，它读不读得懂。

读得懂的公司，AI 能在权限之下查数据、建议流程改动、生成可审查的差异；读不懂的公司，AI 往往只能停在外围问答。同样的行业、同样的预算，两类公司会逐渐拉开差距。

解法：把系统从”一堆代码”变成”一份说明书”

那有没有别的活法？有。关键只有一句话：

别再把业务规则埋进代码里，而是把它写成一份人和 AI 都能读懂的、清清楚楚的”说明书”。

听起来抽象，但落到日常，差别是肉眼可见的：

• 过去：想知道”超过 10 万的订单要谁审批”，得让工程师翻代码、半天给你答复。
• 现在：这条规则就明明白白写在一处，业务的人能看懂，新来的人能接手，AI 也能读到——于是它能直接帮你改。

当系统是这种形态时，前面那三个”死结”会逐一松开：

• 换谁接手都看得懂，不再绑定某一个程序员，外包跑了也不慌；
• 改一处不用动全身，加字段、调流程是分钟级的事，不必排期两周、提心吊胆；
• AI 真的能进入系统协作——因为它读得懂整套系统，所以能生成可审查的改动、解释影响范围，而不只是一个外围聊天框。

这正是 ObjectStack 的出发点：把一整套业务系统，做成 AI 和人都能读懂、能安全修改的结构。它让业务对象、权限、流程和动作成为可审查的定义，而不是散落在几十处代码里的隐含规则。

直观的对比是：过去你想加个新模块，要先找回原作者、排期、反复测试；在这种新形态下，AI 先生成一份小的元数据 diff，人审查字段、权限和流程影响，再由运行时执行。交付可能更轻，但真正的关键是：负责人看得懂，也敢签字。

“那是不是又要推翻重来？“——恰恰相反

聊到这，很多老板的第一反应是：“道理我懂，但我不可能把现在的系统全推翻重做。”

完全不需要。事实上，最务实的路，是不动你的老系统，在它之上叠一层 AI 能读懂的结构——数据不搬家、原系统照常跑，却能让 AI 在上面工作，并且守住你原有的权限和规矩。换句话说，你不是再赌一次”推倒重来”，而是给现有系统补上一层可读、可审、可治理的业务定义。

给老板的一张「系统健康自查表」

对照下面几条，给自己的系统打个分（中一条记一分）：

• 加一个字段，排期常常超过 3 天；
• 整套系统，只有 1 个人能改、改之前你会紧张；
• 想接 AI，被告知”得先重做”；
• 所谓的文档，其实就是”那个人的脑子”；
• 换过一次外包之后，旧系统几乎直接报废；
• 你已经记不清，每年为这套系统持续花了多少维护和改动的钱。

3 分以上，说明你的系统已经在”僵死”的路上——它还能跑，但已经停止生长。5 分以上，它大概率正在悄悄变成你最贵的那笔负债。

---

软件正在从”做一次就定型的产品”，变成”能持续演进的资产”。这一轮 AI，真正改变的不是多一个功能，而是重新决定一件事：哪些公司的系统能被 AI 读懂、被负责人审查、被运行时治理，哪些只能继续停在没人敢改的状态。

把一套现有系统先建成对象、字段、权限和动作的定义，再让 agent 生成小 diff 给人审查，是比“推倒重来”更现实的起点。