整个软件行业几十年来，都默认一个等式：代码 = 资产。
仓库越大越值钱，行数越多越有实力，程序员产出代码越多越高效。这个等式塑造了我们的招聘、估值、架构、晋升、甚至自我认同。一个”写了很多代码”的工程师，天然被当成一个”积累了财富”的人。
这个等式在过去成立，因为它建立在一个隐含前提上：代码是稀缺的。写出来要花大量人力和时间，所以每行代码都带着沉没成本，所以代码是资产，所以越多越好。
但 AI 把这个前提打掉了。
当生成一行代码的边际成本从”一个工程师几小时”降到”一次 API 调用几分钱”，代码的稀缺性消失了。而一个东西一旦不再稀缺，它的价值符号就开始动摇。在新的条件下，多写一行代码，往往不是多积累一份资产，而是多背上一笔尚未偿还的债。
这是一次真实的资产负债表重写，只是行业还没换账本。
一、先回到会计学：一个东西是资产还是负债，由什么决定
要把这件事讲透，得先借用一点会计学的底层逻辑，因为”资产”和”负债”在会计上是有精确定义的，不是情绪词。
一个东西是资产还是负债，不取决于它”好不好”，也不取决于它”贵不贵”，而取决于一件事：
它未来带来的价值，是否持续大于维持它所需要的成本。
能持续产生超过维护成本的价值，就是资产；维持它的成本持续超过它产生的价值，就是负债。
这里有一个被忽略的关键：同一个东西，在不同条件下可以是资产，也可以是负债。
一套贷款买的大房子，如果租金能覆盖月供和物业，它是资产；如果租金覆盖不了，每个月还要贴钱养它，那它在会计上就是负债。尽管它看起来很值钱，尽管你花了很多钱买它。决定它性质的，不是它的外观，不是它的购入成本，而是它未来的现金流方向。
代码完全遵循同样的逻辑。一段代码是不是资产，不由它”写得好不好”决定，不由”花多少成本写出来”决定，而由一件事决定：
它未来持续产生的业务价值，是否大于团队为理解它、维护它、为它负责所需要的成本。
产出大于维护，它是资产；维护大于产出，它就是负债。哪怕它写得再漂亮，哪怕它每天都在跑，哪怕它是用最贵的模型生成的。
记住这个判据。后面所有的论证，都建立在它之上。
二、过去代码为什么是资产：一个被遗忘的前提
代码在过去确实是资产。但要理解它为什么现在变成负债，必须先看清它过去是资产的真正原因——因为那个原因正在被 AI 抹平。
过去代码是资产，依赖三个条件同时成立：
条件一：代码稀缺。 写代码要花大量人力时间，每行代码都带着不菲的沉没成本。稀缺的东西天然有价值，所以每多一行代码，团队就多一份财富积累。这是”代码=资产”最朴素的来源。
条件二：理解密度高。 过去写代码的人和改代码的人，往往是同一批人，或者至少在同一个团队里紧密协作。代码不只是逻辑的固化，更是团队认知的固化——谁写的，谁就理解它；谁理解它，谁就能低成本地维护它。维护成本之所以可控，是因为”理解”这个最贵的环节，已经在编写时被预付了。
条件三：维护成本可控。 系统规模有限，模块边界相对清晰，一次改动引发的连锁影响可以预期。代码越多，维护成本确实在上升，但上升速度平缓，远低于代码持续产出业务价值的速度。
三个条件叠加，代码的净价值符号是正的：产出 > 维护。在这个符号下，囤积代码就是囤积财富，”多写代码”和”积累资产”是同一件事。整个行业的激励机制——代码量、提交数、PR 数、仓库规模，都是围绕这个符号设计的。
但请注意，这三个条件里没有一个是”代码本身”的属性。它们全部是外部条件：稀缺性来自生产成本，理解密度来自协作方式，维护成本可控来自系统规模。代码是资产，从来不是因为代码天生是资产，而是因为当时的外部条件让它的净价值符号为正。
那么，当 AI 改写这些外部条件时，会发生什么？
三、AI 如何精确地翻转了这三个条件
AI 对代码资产属性的影响，不是模糊的”让代码变多”，而是精确地、逐条地打掉了上一节那三个条件。
稀缺性消失。 生成代码的边际成本趋近于零。一次 Agent 任务可以扫遍整个 monorepo，几小时内产出上千行变更。当代码可以近乎免费地大量生产时，它就不再是稀缺资源，”多一行代码就多一份财富”的逻辑直接失效。这就像印刷术普及后，抄本不再是稀缺资产。不是抄本变差了，是它不再稀缺了。
理解密度坍塌。 这是三个条件里最致命的一个，也最容易被忽视。过去代码的理解密度高，是因为写代码的人在写的过程中完成了”理解”的预付。但 AI 生成的代码，团队里没有任何一个人经历过那个”理解”的过程。代码看起来很规整（甚至比人写的还规整），但它承载的不是团队的认知，而是模型的一次性输出。代码从”团队知识的固化”变成了”外部知识的一次性注入”。 而一次性注入的知识，无法被继承。下一次有人要改这段代码，得从零开始重新理解它一遍。
维护成本不降反升。 代码量暴增，意味着要理解、审查、回归的范围同步暴增。而且 AI 生成的代码带有特有的维护负担：隐式假设、对上下文的隐式耦合、看起来对但经不起细查的实现。这些都不是”写得烂”的传统技术债，而是一种更难识别的负担。因为它外表光鲜，审查时容易放过，出问题时才暴露。
三个条件同时翻转，净价值符号就反转了：产出趋零，维护不变甚至上升，于是维护 > 产出。
按照第一节那个判据，当代码的维护成本持续超过它产生的价值时，它在会计意义上正式从资产变成了负债。
这不是危言耸听，这是条件变化后的必然推论。账本变了，符号就变了。
四、这种负债的精确形态：不是技术债，是”理解债”
讲到这里，必须澄清一个关键的区分，否则这个立意会和”技术债”混为一谈，失去锐度。
传统技术债，前提是”代码写得不够好”。代码质量差、结构混乱、缺少测试，所以需要重构偿还。技术债是质量债，你能看出来，有意识地排队偿还，偿还方式是重写。
而 AI 时代代码变成的负债，是另一种东西。它的前提不是”代码写得差”。恰恰相反，AI 写的代码往往很规整，语法漂亮，结构合理，甚至带着注释。它的负担不在质量，而在认知：
代码可能写得很好，但团队里没有任何人真正理解它。
这是一种全新的债务形态，我称之为理解债。
理解债的本质是：代码的”理解成本”从未被预付。过去人写代码，编写的过程就是理解的过程，理解被预付进了代码；现在 AI 写代码，编写的过程被跳过了，理解从未发生，于是这笔成本被全额欠下，留给了未来每一个要碰这段代码的人。
理解债有几个让人难以察觉的特性：
它外表光鲜。 技术债看起来像乱码，理解债看起来像好代码。所以它不会触发”该还债了”的警报。团队会心安理得地累积它，直到某天一个改动引发连锁故障，才发现没有人能说清这段代码到底在做什么、为什么这么做。
它的利息是复利。 每一次有人在理解债上叠加新代码（因为他没真正理解底层，只能照猫画虎地往上堆），理解债就增长一层。AI 让这种叠加变得异常容易——你不用理解就能继续生成。于是理解债不像技术债那样线性增长，它呈指数膨胀。
它无法靠重写偿还。 技术债可以重构，因为你知道目标质量是什么。理解债重写不出来，因为你重写依赖的还是 AI，而 AI 生成的新代码依然没人理解。你只是把一笔旧债换成了一笔新债。偿还理解债的唯一方式，是让人真正去读懂它，而这恰恰是 AI 时代最被省略的环节。
这里可以给出一个相当实用的判据，用来判断你仓库里的某段代码到底是资产还是负债：
如果明天把这段代码整个删掉，团队能不能在合理时间内把它重新造出来？
如果能——说明它不是资产，它只是占着位置的负债。因为它承载的东西（无论逻辑还是实现）可以被低成本再生，留着它反而要持续付维护费。
如果不能——说明它是真正的资产。因为它承载了无法被快速再生的知识，删了就真的没了，留着它是在持续兑现价值。
这个判据反直觉但精确：容易被删的代码是负债，删了会痛的代码才是资产。 而 AI 时代最大的问题正是——我们仓库里越来越多的代码，是”删了也没什么感觉”的那种。
五、那么，什么变成了新的资产
如果代码在负债化，资产去哪了？
答案藏在”为什么有些代码删了会痛”里。删了会痛的代码，痛的不是代码本身，而是代码背后承载的、无法被快速再生的东西。这些东西，才是真正的资产。
它们是：
意图。 这段代码为什么存在？它要解决什么业务问题？如果不写它，会怎样？意图是业务理解在代码世界的投影，AI 无法自动生成，因为它承载的是人对真实世界的判断。
约束。 这段代码必须满足什么边界？安全底线、性能要求、合规规则、兼容性承诺、资源限制。约束是”不能做什么”的契约，AI 不知道你的约束，除非你告诉它。
验收标准。 什么叫”做对了”？输入输出、异常处理、边界行为、可观测性要求。验收标准是”做对”的定义，定义它需要对业务和系统的判断。
上下文契约。 这段代码和系统的其他部分如何协作？它依赖谁、被谁依赖、在什么时序下运行、失败时如何影响下游？这是代码的”生态系统地图”。
决策记录。 为什么选了方案 A 而不是 B？曾经试过什么、放弃了什么？决策记录是”踩过的坑”的固化，避免团队重复交学费。
这些东西有一个共同特征：它们不可被 AI 自动生成，却能让代码被 AI 低成本再生。 只要意图、约束、验收、契约都清晰，代码本身可以随时用 AI 重新写出来。换句话说，这些资产的存在，让代码从”必须保留的资产”降级成了”可以再生的实现细节”。
于是一个彻底的坐标翻转发生了：
过去，代码是资产，文档是负债——文档要花精力维护，却不出钱，所以大家不爱写。
现在，代码是负债，意图和约束才是资产——代码随时能再生，但意图丢了就真的丢了。
这个翻转解释了一个反常现象：很多团队上了 AI 之后，代码产出暴涨，但工程能力反而下降。因为他们囤积的全是负债（代码），清空的恰好是资产（没人写意图、约束、验收了——反正 AI 会写代码，何必写这些）。他们用资产换负债，还以为自己赚了。
六、压力测试：这个判断是不是太极端了
反驳一：代码到底是在运行的，它每天都在产生业务价值，怎么能叫负债？
能产生业务价值的东西，完全可以同时是负债。会计上这太常见了：一套贷款买的生产设备，每天都在产东西，但如果贷款利息和维护费用高于它的产出，它就是负债。能产 ≠ 是资产。
代码同理。它确实在跑，确实在支撑业务，但如果团队为理解它、维护它、为它排障所付出的持续成本，超过它继续产出价值的能力，它就是负债。而且，这是关键一段没人真正理解的代码，它的维护成本会随时间上升（业务在变、依赖在变、AI 幻觉埋的雷在慢慢暴露），而它产出的边际价值会随时间下降（业务在迭代，老代码能贡献的新价值越来越少）。两条曲线一升一降，交叉之后，它就是纯负债。很多团队的代码仓库，正在大批量地越过这个交叉点。
反驳二：那是不是所有代码都是负债？显然不是。Linux 内核、优秀的开源项目，难道也是负债？
当然不是所有代码都是负债。判断标准是净价值符号，不是”代码”这个类别。
Linux 内核是资产：它被全球无数开发者深度理解（理解密度极高），持续产生巨大价值，维护成本由全球分摊。它的”维护 > 产出”不会发生，因为分摊结构把它托住了。
一个团队内部 AI 生成的业务代码是负债：只有少数人浅层理解，维护成本全由团队独自承担，业务迭代后它的产出价值快速衰减。它的符号是负的。
决定性质的变量有两个：理解密度，和维护成本的分摊结构。开源资产在这两个维度上都占优，内部 AI 代码在这两个维度上都劣势。所以这个立意不是”代码皆是负债”的虚无主义，而是”在 AI 改变条件后，内部业务代码的净价值符号系统性转负”的精确判断。
反驳三：这不就是换了说法的”技术债”吗？
不是。这个反驳必须在第三节和第四节之外再强调一次，因为它最容易让立意失焦。
技术债的前提是质量问题：代码写得不够好，需要重构。理解债的前提是认知问题：代码可能写得很好，但没有人理解它。
技术债可以靠重写偿还：你知道目标质量，重写到那个质量就行。理解债无法靠重写偿还：重写出来的还是 AI 生成的、没人理解的代码，你只是把旧债换成新债。
技术债会触发警报：代码丑，审查时会被发现。理解债不触发警报：代码漂亮，审查时会被放过。
这是两种本质不同的债务。把理解债误诊成技术债，会用错药。你以为重构一下就好了，其实重构完还是没人懂。
反驳四：代码生成成本趋零，那维护成本不也会被 AI 降低吗？符号不又翻回来了？
部分会。AI 确实能帮人理解代码、生成注释、辅助审查。但维护成本有一个无法被 AI 压低的地板：责任。
维护的真正成本，不是”改代码”，而是”为改动的后果负责”。AI 可以帮你改，但它不能替你承担改错之后的故障、赔偿、回滚、信任流失。责任不能外包，所以维护成本永远有一个 AI 触不到的下限。而代码量暴增带来的责任面扩大，是实打实在涨的。所以即使 AI 把维护成本的某些部分压低，净价值符号也很难翻回正。因为产出一侧同样趋零了。两边都趋零，但责任面在涨，符号依然是负的。
四个反驳接住之后，这个立意反而更清晰了：它不是”代码无用论”，而是”在 AI 改变生产成本和理解密度之后，内部业务代码的净价值符号系统性转负，而行业还在按旧符号决策”。
七、那么怎么办：在负债化的世界里，重新组织工程
既然代码是负债，工程的目标就不是”多产出代码”，而是“用最少的负债，换最大的资产”。这要求一系列工作方式的根本调整。
原则一：把意图、约束、验收写成一等公民，代码降级为实现细节。
过去文档是代码的附属，代码才是主体。现在反过来：意图、约束、验收是主体，代码只是它们的一种临时实现。PR 评审的首要对象不是代码，而是”这段代码对应的意图和约束有没有被清晰记录”。代码错了，AI 能改；意图丢了，谁也救不了。资产要被显式持有，负债可以随时再借。
原则二：追求”可再生的代码”，而非”可保留的代码”。
衡量一段代码价值的标准变了。过去是”它能不能稳定运行”；现在是”如果删了它，能不能低成本再生”。能再生的代码是轻负债，留着它不增加多少维护负担；不能再生、删了会痛的代码才是重资产，要重点保护。审查时多问一句：“这段代码删了，我们能多快重建它？” 答案越慢，它越是资产，越值得投入理解；答案越快，它越是负债，越应该让它保持轻量、可替换。
原则三：审查的对象，从”代码对不对”转向”资产记没记”。
代码对不对，AI 自己能修。真正稀缺的是这段代码承载的意图和约束有没有被记录下来。所以代码审查的重心要迁移：不是逐行挑代码的毛病（那是负债层面的工作，无穷无尽），而是确认这段代码背后的资产是否被固化。有没有写清楚为什么这么做、边界在哪、怎么验证。审负债容易陷入细节，审资产才能守住价值。
原则四：给代码设”折旧”，定期清偿。
资产会折旧，负债更要折旧。每一段代码都应假设它会随时间贬值。业务在变、依赖在变、它越老越可能偏离真实需求。定期评估仓库里的代码还有没有价值：还在产出价值的，保留并继续理解；已经不产出价值但还占着维护成本的，果断删除。资产持有，负债清偿。 囤积不产出的代码，就是在囤积不生息的债务。
原则五：重新定义”程序员产出”。
如果代码是负债，那么”写了多少代码”就不是产出，而是”借了多少债”。真正的产出应该是：建立了多少可再生的资产（意图、约束、契约、决策记录），以及清偿了多少负债（理解了多少别人没理解的代码、删除了多少不再产出的代码）。
这个重新定义会直接冲击现有的晋升和绩效体系。一个一年写了五万行 AI 生成代码的工程师，在旧账本里是高产，在新账本里可能是”给团队背上了五万行理解债”。而一个一年只写了一万行、但把每个模块的意图约束都记录清楚、并把过时代码大量清理掉的工程师，在旧账本里像低产，在新账本里才是真正的资产积累者。
八、结论：账本错了，所有决策都会错
回到开头那个等式：代码 = 资产。
这个等式在过去成立，因为它依赖的三个条件——稀缺、高理解密度、可控维护。AI 不是改变了代码本身，而是改变了这三个外部条件，于是等式的符号反转了。
代码正在从资产变成负债。这不是悲观，而是一次迟到的认知更新。
而认知更新的代价，在于所有基于旧账本的决策，都会系统性出错：
- 招聘会错：还在招”能写大量代码”的人，而不是”能定义资产、清偿负债”的人。
- 估值会错：还在按代码量、仓库规模、功能数量估值，而不是按可再生资产估值。
- 架构会错：还在囤积代码，把”系统很大”当实力，而不是把”意图清晰、代码可删”当健康。
- 晋升会错：还在奖励”高产代码”的人，而无视他们同时是最大的负债制造者。
AI 给这个行业最大的礼物，可能不是更快的代码生产，而是逼着我们去重新问一个早就该问、却一直被”代码=资产”的惯性掩盖的问题：
我们到底在积累什么？
如果我们还在用旧的账本，把负债当资产囤积，把负债制造者当高产者奖励，那 AI 给我们的不会是繁荣，而是一场迟早要暴雷的债务危机。
只不过这次的债主，不是银行，不是投资人，而是未来的我们自己。那些不得不去理解、维护、为这些代码负责的、未来的工程师。
他们会看着我们今天囤下的几百万行”资产”，发现那其实是一张巨大的欠条。而欠条上的利息，每天都在复利增长。
发表回复