用AI写软件之后明白的事(一):为什么项目、公司和组织,都会不受控制地走向膨胀?

第一次打开Claude Code的时候，我心里有一种说不清的疑惑。

网上都在传Claude Code泄露了50万行代码，你想一个命令行工具能有多复杂，打开一看界面却简洁得不像话，黑底白字，几行文字一个光标，连个像样的按钮都没有，我当时脑子里冒出一个问题——那50万行代码，到底藏在哪里。

但这个问题一闪就过去了。我没多想，就开始用它写我自己的项目了。

我写的软件叫墨帆助手，一款用于知识管理和智能写作的工具，纯业余时间用AI搞的，这两天我让AI分析了一下项目，AI告诉我共有7万多行代码，盯着屏幕上的数字，然后那个问题突然又回来了。

Claude Code的50万行，到底藏在哪里。Claude这样级别的产品到底强在哪里？

那个问题在我脑子里盘旋了很久，直到我认真去了解Claude Code到底在做什么，才发现那个答案比我想象的要深得多。

50万行代码，有很大一部分是Harness Engineering (驾驭工程)和围绕Harness Engineering构建的一系列基础设施。

我们看到的简洁界面，是冰山的一角，水面之下，是极其复杂的工程化体系——它要做上下文管理，确保每一次对话AI都不会遗忘之前的约定；它要做输出校验，确保AI生成的代码能通过基本的语法和逻辑检查；它要做权限隔离，确保AI的操作不会越界；它要做回滚机制，确保AI搞砸了能恢复；它要做测试注入，确保AI写的代码真的能跑；它要做依赖分析，确保AI引入的库不会把整个项目拖垮。

这50万行，是"管AI"和服务"管AI"的代码。

我突然明白，Claude Code背后真正的技术路线，不是更复杂的大模型，不是更聪明的算法，而是把人类社会积淀了几千年的社会治理和管理学知识，搬到了AI管理里。

管人，中国人有两千年的历史经验。

怎么让一群人朝着同一个方向用力，怎么在授权和约束之间找到平衡，怎么在效率和风险之间做取舍——这些东西，写进了《孙子兵法》，写进了《资治通鉴》，写进了每一本认真讨论"怎么管理人"的书里，而Claude Code做的事情，本质上就是把"管人"的这套方法论，用来"管AI"。

管一个员工，你需要给他目标、给他边界、给他检查机制、给他反馈回路。管一个AI，你需要给它上下文、给它输出约束、给它校验规则、给它回滚机制。结构上完全一样。

"管"AI，就像管一个能力很强但偶尔会犯致命错误的员工。

你需要一套工程化的体系来约束它，你需要代码审查机制，你需要自动测试注入，你需要权限边界，你需要输出格式约束，你需要失败回滚，你需要人工确认节点，这些东西单拿出来都不性感，都不会出现在产品宣传页的封面图上，但正是这些东西，决定了这个工具能不能被真正放心地用在严肃的生产环境里，而Claude Code的50万行，有很大一部分堆在这些"不性感但决定性"的事情上。

这个发现，对墨帆助手来说是一个极大的启示，我做的是一个知识管理和智能写作的工具，这个方向现在也很卷，每天都有新的AI写作工具冒出来，有的界面做得特别漂亮，有的营销做得特别响，有的功能列表特别长。

但看完Claude Code的50万行真相之后，我觉得方向清楚了。

不需要花里胡哨的界面，不需要把功能列表堆到五十项，只需要在知识管理和智能写作的准确性、可靠性上死磕，一切围绕用工程化的方法来推动这两件事，在这一块做强了，未来一定有立足之地。

知识管理这件事，用户最核心的需求其实只有一个。

智能写作这件事，用户最核心的需求也只有一个。

这两个需求，归根到底都是"准确性"和"可靠性"的问题，界面漂不漂亮，是第二位的，功能多不多，也是第二位的，用户愿不愿意留下来，归根到底取决于一件事：这个工具能不能稳定地、可预期地帮他把事情做成。所以墨帆助手接下来的路，不是去做更多的功能，不是去追上每一个热点，而是把"知识管理的准确性"和"智能写作的可靠性"这两件事，用工程化的方法做到极致。

这是Claude Code用50万行代码教给我的事。

我想先从最表层的现象说起，也就是需求是怎么异化的，因为在很多人的经验里，项目膨胀的直觉解释就是"需求越来越多"，这是对的，但还不够准确，需求不是凭空变多的，它有自己的生长逻辑，理解了这个逻辑，你才不会在项目变复杂的时候觉得是自己规划失败了。

每一个问题被解决之后，它会孵化出新的问题，这是软件开发里几乎铁律般的现象，你解决了用户手动整理笔记的问题，他就会来问你能不能自动打标签，你帮他实现了自动打标签，他就会问标签能不能联动搜索，你实现了联动搜索，他就会问搜索结果能不能导出成报告，每一个"好用"的功能都会成为下一个需求的起点，它不是需求的终点，它是需求的孵化器。

这不是用户贪心，这是人类认知的正常工作方式——你只有用过了一件工具，才能想到它还缺什么。

当一个目标无法简单实现的时候，你会发现自己开始绕路，比如你想让用户的笔记能够"智能推荐相关内容"，但直接实现这个功能技术门槛太高，你就会先做一个"相似标签聚合"来替代它，这就是替代性目标，而为了让这个替代性目标稳定运行，你还需要一套可靠的标签系统，这就是保障性目标。

替代性目标是你绕的那条路。保障性目标是你为了走那条路修的基础设施。

这两者都会生长出自己的子目标，而且往往比原始目标复杂得多，因为原始目标是你想要到达的山顶，但你修的路和桥，永远比山顶本身占地面积更大。

一旦替代性目标和保障性目标开始运转，它们自己也会开始繁殖下一代目标，因为它们也有自己的"解决了问题就会孵化新问题"的逻辑，于是整个系统就进入了一个无法自然停止的扩张循环，这不是管理失控，这是复杂系统的内在属性，它的名字叫做"涌现"。

一家今天拥有数万员工的大公司，最初往往只有几个人围坐在一张桌子旁边，解决一个具体的问题，卖一个具体的产品，它没有HR部门，因为五个人不需要HR，它没有法务部门，因为没有什么合同需要审查，它没有公关部门，因为没有人认识它，这时候的组织是一把手术刀，锋利，精准，低耗。

然后它开始成长。

HR部门出现了，因为招人和留人成了问题，法务部门出现了，因为合同纠纷开始出现，公关部门出现了，因为外部形象开始影响业务，信息安全、战略研究、企业文化，每一个新部门的诞生都有一个合理的理由，都是组织在应对更复杂的处境时长出的"器官"。

但这些器官，不直接参与生产。它们是组织的"基础设施"，是保障性目标的实体化。

一个公司的"非生产性成本"从创立初期的几乎为零，到成熟期的占比超过一半，这个过程正是替代性目标和保障性目标体系不断扩张的过程，而且这个扩张一旦开始，就难以逆转，因为每一个部门都有它存在的正当性，你很难说哪一个是"多余的"，但把它们加在一起，你会发现这个组织已经变成了一个主要靠维持自身运转而存在的庞然大物。

好，以上说的都是现象和逻辑，但我还没有说到最关键的部分。系统为什么会膨胀？

Windows从几兆膨胀到几十GB，根本原因不是需求变多，而是微软有能力持续向Windows项目投入数以千计的工程师，维持他们工作的是微软的商业收入，维持微软商业收入的是操作系统的市场垄断地位，所以你看到的代码膨胀，本质上是能量流动的物质化结果。

这就解释了为什么"断粮"是历史上任何大型组织最致命的威胁，军队断粮，不是慢慢衰弱，是迅速崩溃，企业现金流断裂，不是慢慢经营困难，是在某个具体的日期无法发出工资，然后所有事情同时停止，庞然大物的倒塌是一瞬间的事。因为它的存在，本质上是持续能量输入的结果。一旦能量停止，熵增立刻接管一切。

想清楚了这一点，很多关于组织竞争的判断就变得清晰了。我们通常说企业竞争是产品竞争、人才竞争、技术竞争，这些都对，但它们都是表象，竞争的底层，是系统从外部环境汲取能量的能力的竞争。

产品好，意味着能以更高的效率从市场中换取收入；人才强，意味着能把同样的能量转化成更多的价值；技术领先，意味着能用更低的能量成本完成同样的任务，所有你能想到的竞争维度，最终都会换算成一个问题——在同样的外部条件下，这个系统能吃进多少能量，又能把多少能量转化成竞争优势。

一个系统能成长到多大的上限，不是由它的创始人有多聪明决定的，也不是由它的产品有多好决定的，而是由它的基础架构所允许的能量转化效率决定的。

架构不对，规模越大越低效。

底层架构决定上限。这不是鸡汤，这是系统动力学。

这一句话，说的不是节俭，说的是能量储备。

一个系统维持运转的不只是当下的能量输入，还有它的能量储备，当外部能量供给充足的时候，系统有两个选择，一是把能量全部转化为当下的规模扩张，二是在扩张的同时保留一部分能量储备，前者在顺境中扩张更快，但一旦外部条件变化，能量供给出现缺口，储备不足的系统会迅速崩溃，而后者虽然在顺境中看起来扩张更慢，但它拥有抵抗逆境的韧性。

"寅吃卯粮"的中文表达太精准了。

寅时吃了卯时的粮，是用未来的能量储备支撑当下的消耗，这个逻辑在个人财务上叫做"超前消费"，在企业运营上叫做"过度杠杆"，在国家层面叫做"财政赤字"，它在顺境中能制造出一种欣欣向荣的假象，但它把风险完全积压到了未来。

中国传统商业智慧反对寅吃卯粮，不是保守，是对系统崩溃有深刻的历史记忆。

这九个字用系统论的语言翻译一下，就是先优化系统的防御架构（高筑墙），再积累能量储备（广积粮），最后才是在拥有了结构优势和能量优势之后，再去扩大系统的影响范围和规模（缓称王）。

称王是目标，但称王是最后一步，不是第一步。

说了这么多，回到我自己的事情上来。墨帆助手现在七万多行代码，短期内不宜再做功能的拓展和叠加。

这个判断，最初是从系统论的角度得出来的，不是因为我累了，也不是因为没有新想法，而是因为一个系统在经历了快速膨胀之后，需要进行一次结构性的整理，否则后续所有的新功能都会建立在一个混乱的地基上，每增加一行新代码，维护成本就会成倍上升，这不是线性增长，这是指数增长。但现在，这个判断多了一层来自Claude Code的启示。

每一行冗余的代码，每一段逻辑不清晰的函数，每一个当时为了快速实现而做的妥协，都是在降低系统把输入转化为产出的效率。这个时候需要做的，是"高筑墙"——不是不扩张，是先把现有的架构整理清楚，把技术债务偿还掉。

"做精现有功能"，听起来像是一个退守的姿态，但它其实是一个进攻的准备。精简，是为了更快。整理，是为了走更远。

而所谓"深度打磨"，用Claude Code教会我的语言来说，就是：一切围绕准确性和可靠性，用工程化的方法来做，不做花哨的东西，不做看起来很炫但不可靠的东西，把最朴素、最基础、最决定性的事情做到极致。知识管理的准确性，就是让用户存进去的东西一定能找到。智能写作的可靠性，就是让用户拿到手的文字是真的能用的。

这两件事做好了，墨帆助手就有一席之地。

我知道这篇文章里有很多独立开发者，或者正在做一件自己的事的人，我想跟你说几句真话。

我说这件事让我"忽然明白了"，不是说我学到了一个道理，而是说我第一次在自己亲手操作的系统里，亲眼看见了一个道理从理论变成了真实。Windows的膨胀，曾经对我来说是一个宏大叙事里的例子，是教科书里的插图，但当墨帆助手的代码从几百行增长到七万行，我忽然觉得自己理解了微软那些工程师的感受。

每一行代码都是有来历的，每一个部门都是有来历的。它们是问题被解决之后孵化出新问题的产物，是系统在持续能量输入下的自然生长。

人类社会的一切组织，都是这个逻辑。家庭是这个逻辑，国家是这个逻辑，企业是这个逻辑，一段关系是这个逻辑。只要有持续的能量投入，系统就会生长，这是一个持续运转的循环，它的名字叫做"活着"。

理解这个循环，不是为了对抗它。是为了在它当中，做一个清醒的操盘手。

知道自己的能量在哪里，知道系统的优先级是什么，知道什么时候该扩张，什么时候该收缩，什么时候该高筑墙，什么时候该缓称王。这些判断，是独立开发路上最值钱的东西。

这是我做墨帆助手以来，觉得最有收获的一次思考。不是因为解决了一个问题，是因为它让我看见了一个原来就在那里，但我之前没有看见的世界。