文艺复兴时期的大师在动笔之前，先画几百张草图。达·芬奇的笔记本里全是未完成的想法——不是因为他不擅长完成，而是因为他深知：思考的结构决定了作品的结构。今天，CLAUDE.md 就是你的草图。

先写文档，再写代码

这个建议反直觉到几乎冒犯。

你是创始人，你有一个经过验证的问题，你迫不及待要动手做产品。The Founder’s Playbook 却让你在写任何一行代码之前，先坐下来，和 Claude 一起定义并记录架构决策：遵循什么模式、避免什么依赖、接受什么权衡、为什么。

这不是官僚主义，这是防止 AI 把你的代码库变成巴别塔。

想想巴别塔的隐喻。如果每个 AI 会话都是一个工人，每个工人都说自己的语言、按自己的方式砌砖，最终的结果不是塔，而是废墟。CLAUDE.md 就是你的通用语——它告诉每一个进入这个项目的 AI：这个系统为什么这样设计、哪些边界不能碰、哪些权衡是刻意的。

为什么这件事在 AI 时代如此关键

传统团队里，架构知识通过代码审查、站会、文档、以及最重要的——人与人之间的隐性传递来维护。一个新工程师加入团队，通过和老工程师配对编程、一起吃午饭、在 Slack 上问"为什么"来学习系统的设计逻辑。

在 AI 原生团队里，你的"新工程师"是每一个新的 Claude Code 会话。它没有上下文——除非你给它。没有 CLAUDE.md，每次会话都从零开始推断结构假设。它能生成能跑的代码，但生成的代码没有连贯的心智模型支撑。

这就像让十个建筑师各自设计一栋楼的一层，但没人见过总平面图。每一层单独看都没问题，但它们合在一起会怎样？门可能开在承重墙上，水管可能穿过电线管道。

The Founder’s Playbook 把这种现象叫做"结构性不连贯"（structural incoherence）。代码能跑，能过测试，但背后没有一个统一的设计意图。问题不在任何一段代码，而在于所有代码从未被设计成能协同工作。

CLAUDE.md 里应该写什么

不是完整的规格书。你不需要在这个阶段写一份 IEEE 830 标准的需求文档。

你需要写的是决策和理由。为什么选 PostgreSQL 而不是 MongoDB？为什么接受这个技术债？为什么这个模块的边界划在这里而不是那里？

举个例子，你可能会写：

“我们选择 Next.js 而不是纯 React，因为我们预计未来三个月需要 SSR 来支持 SEO。这是一个刻意的选择，即使它增加了部署复杂度。如果三个月后 SEO 不再是优先级，可以重新评估。”

这段话告诉 AI 的不只是"用什么"，还有"为什么用"和"什么情况下可以改"。

范围文档：AI 时代的疫苗

和架构文档同等重要的是范围文档。

在 AI 时代，范围蔓延（scope creep）是一种全新的危险。过去，加一个功能需要一个 sprint 的工程师时间——这个成本本身就是一种制衡。现在，加一个功能只要一个下午。每一项单独看都理所当然：当然产品应该处理这个边缘 case，当然用户会想要那个工作流。

但当你的产品开始越过原来的边界，方向感就悄悄溜走了。

范围文档的格式很简单：产品做什么、不做什么、以及什么情况下才应该加新功能。 最后一条是关键——它把决策从"我们应该做这个吗"转成了"有足够多的用户告诉我们，没有这个功能他们就拿不到价值"。

前者是创始人热情，后者是用户信号。

安全：最低限度的责任

在 MVP 阶段谈安全审查，听起来像是在酒驾检查站谈安全带——多余但必要。

The Founder’s Playbook 的态度很务实：AI 生成的代码是"能跑的代码"，不是"安全的代码"。功能代码要么能跑要么不能跑，反馈是即时的。安全漏洞在被利用之前是看不见的——对第一次创业的人来说，没有天然的反馈循环提醒你出了问题。

但你的用户信任你。在代码部署给任何真实用户之前，让 Claude 做一次安全审查：认证和会话处理、API 响应中的数据暴露、输入验证和注入风险、有已知漏洞的依赖。认真对待每一个发现。

这不是要替代安全工具或人类审查员。但它是最低负责任门槛。

一个实操模板

书中给出了一个 Claude Code 会话模板：

  1. 每个会话开始：回顾范围文档 + 提供 CLAUDE.md 架构上下文
  2. 每个会话结束：更新上下文文档，记录这个会话做了什么、做了什么决策、引入了什么假设

“每会话五分钟文档”——这是防止架构漂移的廉价保险。五分钟的记录，换来的是几个月后你还能理解自己代码的能力。

我的反思

先写文档再写代码，这个理念让我想到一个更大的问题：AI 改变了"写代码"的含义。

过去，写代码就是写代码——你用一门语言告诉计算机做什么。现在，写代码是"你告诉 AI 你想要什么，AI 告诉计算机做什么"。这个过程中多了一层间接性，而间接性需要更清晰的意图表达。

CLAUDE.md 不是写给机器看的——在这个意义上，它和你写给联合创始人的产品愿景文档没有区别。它是你对"我们要做什么、为什么、怎么做"的清晰表达。如果你的表达不够清晰，AI 会替你补全——但它补全的不一定是你要的。

下一篇，我们进入 MVP 的深水区：速度与陷阱的博弈。

系列阅读快速跳转

日期 篇目 核心问题
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：创始人的不变与变 什么变了，什么没变

引用