古罗马人在建造道路时,会先挖一条深沟,铺上多层砂石和碎石,最后才铺上平整的石板。他们知道:路能走多远,取决于地基有多深。今天,你的代码库就是那条路——而 CLAUDE.md 就是你的地基剖面图。


两种技术债

不是所有技术债都一样。理解这一点,是 Scale 阶段的第一课。

有意技术债。 你在充分知情的情况下,选择用代码质量换取速度。你知道这笔债的存在、它的规模、以及什么时候该还。这种债是投资——你借了时间,计划在某个 sprint 里连本带息还清。

无意技术债。 你不知道它的存在,或者你知道但不知道它有多大。它来自"先这样吧"的临时方案、来自"以后再重构"的承诺、来自那些"能跑就不要动"的模块。这种债是高利贷——利息在暗处累积,直到某天你发现已经还不起了。

在 AI 原型的场景里,The Founder’s Playbook 指出了一个特有的风险:Agentic 技术债是一种"超级无意债"。

为什么?因为 agentic coding 工具移除了所有曾经控制什么进入生产的自然瓶颈。过去,代码要经过设计审查、代码审查、测试——每一步都是制衡。现在,一个提示词就能让代码进入生产。速度是保证了,但质量控制的责任完全落到了创始人身上。


架构审计:看见你的地基

The Founder’s Playbook 建议在 Scale 阶段做一次完整的架构审计。

具体操作:让 Claude Code 审计你的代码库,产出一份结构脆弱性清单——哪里是脆的捷径、哪里测试覆盖不足、哪里模块边界模糊。然后让 Claude 对这份清单做优先级排序:什么会拖累下次发布,什么可以并行处理,什么是当前阶段可以接受的。

这个审计的价值不只是"修 bug"。它强迫你看见你的代码库——不是作为一个个文件,而是一个系统。大多数创始人在 Scale 阶段第一次真正"看见"自己的代码库,就像第一次站在高楼上俯瞰自己住了多年的城市。


从"能跑"到"能扛"

Scale 阶段的技术工作不只是修代码——它是围绕代码构建基础设施

企业买家在签多年合同之前,要看的不是你的产品功能,而是你的组织能不能成为一个可靠的基础设施合作伙伴。他们要看产品文档、支持 playbook、SLA 承诺。签了之后,他们会要求你兑现。

The Founder’s Playbook 给出了一个三层方案:

用 Claude 起草和维护文档。 产品文档、支持 playbook、SLA——这些是企业采购团队期望看到的。AI 帮你起草和更新,但内容需要你的领域知识来校准。

用 Claude Code 加固代码库。 审计和加固代码库,针对企业合同要求的特定可靠性和安全标准。构建日志、监控、事件响应工具、可观测性层——让 SLA 真正可执行。

用 Claude Cowork 运行企业支持运营层。 工单路由、升级工作流、文档更新(随产品变化自动触发)、续约追踪、企业客户成功依赖的报告节奏。

三个工具协同,让一个小团队能展示出比自身规模大得多的组织成熟度。


知识编码:把你的脑子变成系统

Scale 阶段最容易被低估的挑战是:创始人的制度知识。

你脑子里装了大量关于这个产品的隐性知识——为什么选了这条路而不是那条、哪些边缘 case 是坑、哪些用户反馈是噪音。这些知识从未被写下来,因为它"一直在你脑子里"。

但 Scale 阶段,你的知识需要从你的脑子里转移到系统里。否则,你不在的时候,关键决策就会因为缺乏上下文而做错。

The Founder’s Playbook 的做法是:用 Claude 来捕获、组织和精炼你的领域知识。通过长期对话、项目和记忆,把你的行业知识——行规、监管陷阱、边缘 case、为什么显而易见的答案行不通——放进一个结构化的、AI 能访问的上下文里。

然后把这些编码成 Skills,让 Claude 每次都以同样的方式执行。几个月后,这就变成了一种专有的知识基底,通用 AI 做不到。


我的反思

技术债这个话题让我想到一个关于古罗马的有趣事实:罗马的道路系统如此精良,以至于有些道路在两千年后仍然可以使用。但罗马不是一天建成的——每一条路都有多层地基,从下到上分别是 statumen(基石)、rudus(碎石层)、nucleus(混凝土层)、和 summa crusta(表面石板)。

AI 原生公司面临一个诱惑:跳过地基,直接铺表面石板。因为 AI 让"铺表面"变得如此之快,你几乎感觉不到跳过地基的代价——直到你要在上面跑重载交通。很多创始人在第三个月就遇到了这个问题:代码能跑,但每次加新功能都要拆东墙补西墙。

The Founder’s Playbook 的核心信息是:AI 让"快"变得容易,但"快"和"稳"不是对立的——它们是同一个系统的两个维度。 关键在于你在快的时候有意识地记录你的决策、维护你的架构文档、定期做审计。不是要慢下来,是要在跑的时候知道自己往哪跑。

下一篇,我们来聊 Scale 阶段最激动人心的话题:构建护城河。


系列阅读快速跳转

日期 篇目 核心问题
06-03 从福特流水线到 AI 原生:范式转移 什么是 AI Native?为什么是现在?
06-05 找到你的问题域:从"能做"到"该做" 如何在无限可能中找到值得解决的问题
06-06 用 AI 做压力测试:让魔鬼代言人替你思考 如何用 AI 反驳自己,避免确认偏误
06-07 构建第一个 AI 原生产品:从 CLAUDE.md 开始 写代码之前先写文档的逆向思维
06-10 MVP 的四个暗礁:速度与陷阱的博弈 AI 加速下最容易踩的四个坑
06-11 产品市场契合的谎言与真相 如何识别假信号,找到真契合
06-12 从创始人驱动到系统化运营 建立不依赖创始人的运营机器
06-22 技术债与架构决策:为 Scale 打下地基 如何在快与稳之间找到平衡
06-23 构建护城河:数据、知识与锁定 AI 时代的三种防御体系
06-25 Same Job, New Rules:创始人的不变与变 什么变了,什么没变

引用