构建第一个 AI 原生产品:从 CLAUDE.md 开始
文艺复兴时期的大师在动笔之前,先画几百张草图。达·芬奇的笔记本里全是未完成的想法——不是因为他不擅长完成,而是因为他深知:思考的结构决定了作品的结构。今天,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,当然用户会想要那个工作流。 ...