技术债不是新概念。传统的技术债是线性的：你为了赶进度走了几条捷径，它一点点累积，你心里有数，找个 sprint 集中还掉就行。
AI 写出来的技术债不一样。它复利。
原因不在单行代码的质量——AI 生成的代码往往单看都没问题。问题在于：如果架构决策没有写在 AI 能读到的地方，每一次新会话都会从零重新推断结构假设。 而这些假设，每次都会漂移一点。
漂移累积起来，你最终得到的，是一个背后没有连贯心智模型的代码库。不是因为哪一块写得差，而是因为这些部件从来没有被设计成能拼在一起。每一块都是在略微不同的假设下生成的。
更糟的是，这种债往往很晚才浮现——通常是在真实用户开始大量涌入、你最没空重构的那一刻。
解药不复杂，但需要纪律：把架构决策写下来，放在 AI 读得到的地方。
这就是 CLAUDE.md 的作用。它是你项目的持久记忆：要遵循的模式、要避免的依赖、做过的权衡和原因。它不是「可选的最佳实践」，在 AI-native 的开发里，它是地基。
我的具体流程：
- 每次会话开头：把
CLAUDE.md（架构上下文）和当前的范围文档喂给模型。 - 每次会话结尾：把这次会话浮现出来的新决策写回去。
- 目标是一个我能讲清它结构的代码库，而不只是一个能跑的代码库。
每次会话花五分钟做这件事，是对抗「复利成无法收拾的代码库」最廉价的保险。跳过它，你省下的是当下的五分钟，欠下的是未来某次从零重建的几周。
判断、验证、范围之后，上下文是 Founder OS 里最容易被跳过、代价又最隐蔽的一层。别跳。