波仔
🧡 第五章 CLAUDE.md：给AI一张地图
📄 一句话概括

六类必写：技术栈与运行环境、项目结构、代码风格、验证方式、红线、这个项目特有的坑；四类不写：历史八卦、完整接口文档、通用教程、你的待办清单。

📝 本节和前面几节的关系

上一节说了从护栏开始，这一节给出具体的条目清单，以及唯一需要记住的判据。

一、六类必写

技术栈与运行环境——它不知道你的机器上装了什么；项目结构与关键路径——它不知道哪个目录是主战场。 代码风格约定——缩进、引号、命名，它默认不是你那一套；验证方式——没写就等于没有，它不知道你要跑什么。 红线——不许删、不许推送、不许动配置；这个项目特有的坑——那些它猜不到、你也踩过一次的事。

二、四类不写

项目历史与团队八卦；完整的接口文档（它能自己读代码）；通用编程教程；你自己写的待办清单。 这四类有一个共同点：写进去不改变它的行为。

三、只需要记住一条判据

这条信息，它能不能靠读你的项目自己得到？ 能，就别写；不能，就一定要写。 按这条判据，上面六类全部入选（它拿不到），四类全部落选（它拿得到）。

四、把口语要求改写成规则条目

好的规则条目具备三个特征：具体、可验证、不重复。 比如【代码要规范】不行——不可验证；【新增函数必须有中文注释说明输入输出】可以——可验证。 本节末尾的演示给了一次改写示范：四条口语要求，逐条变成能进文件的话。

五、动手 Demo：到底该写什么——六该四不该

下面把六类必写与判据摆开。

should = [(u"技术栈与运行环境", u"它不知道你的机器上装了什么"),
          (u"项目结构与关键路径", u"它不知道哪个目录是主战场"),
          (u"代码风格约定", u"它默认不是你那一套"),
          (u"验证方式", u"没写就等于没有"),
          (u"红线", u"不许删、不许推送"),
          (u"常见坑", u"它猜不到的那些")]

实跑输出：

--------------------------------------------------------------------
到底该写什么——六该四不该
--------------------------------------------------------------------

  该写                   为什么必须写
  --------------------------------------------------------------
  技术栈与运行环境       它不知道你的机器上装了什么
  项目结构与关键路径     它不知道哪个目录是主战场
  代码风格约定           缩进、引号、命名，它默认不是你那一套
  验证方式               没写就等于默认没有，它不知道你要跑什么
  红线                   不许删、不许推送、不许动配置
  常见坑                 这个项目特有的、它猜不到的那些

不该写：
    - 项目历史与八卦
    - 完整的接口文档（它能自己读代码）
    - 通用编程教程
    - 写给自己看的待办清单

判据只有一条：**这条信息，它能不能靠读你的项目自己得到？**
能，就别写；不能，就一定要写。

六条的理由都是同一个：它拿不到。所以判据一立，列表不用背。 不写那四类的理由也同一个：它读得到。

30 秒实验

  1. 用那条判据审一遍你现有的规则文件：每一行问一次【它拿得到吗】。
  2. 把下一句要说的话改写成规则条目试试：【代码要规范】改成可验证的说法。

常见误区

  1. 把接口文档整份复制进去。它读得到，而且读得比你复制的那份还准。
  2. 写不可验证的条目。【要专业】不是规则，因为没法判断它有没有做到。
自测三问（点开对答案） 1. 唯一需要记住的判据是什么？ —— 这条信息它能不能靠读你的项目自己得到——能就别写。 2. 六类必写分别是什么？ —— 技术栈与运行环境、项目结构、代码风格、验证方式、红线、项目特有的坑。 3. 一条好规则的三个特征是什么？ —— 具体、可验证、不重复。

相关笔记