AI每次都犯同一个错?规则文件十分钟从零搭

上一篇五段式结尾留了个钩子：我把五段式写进了规则文件，现在每次新任务，AI会反过来问我缺什么。好几个人问这是怎么做到的，这篇就把规则文件拆开讲：全局规则和项目规则各放什么、怎么从零搭起来、搭完不生效怎么排查。文末有我的真实规则脱敏版，可以直接抄结构。

先说口径：我的编码基本全交给AI，我只管审。规则文件就是我"只管审"的底气——把口头重复超过两次的要求沉淀下来，让它从"每次都说"变成"开局自带"。

一、先立一个认知：规则文件不是配置，是说明书

大多数人第一反应是把它当配置文件——像 .gitignore 一样写几行就完事。

错了。规则文件的每一行，都是你在跟AI说"以后遇到这类事，按这个来"。它是你给AI的岗位说明书：这人是谁、怎么跟他配合、什么事别碰。

还有一个反直觉的点，官方文档写得直白：规则文件是上下文，不是强制约束。AI会"尽量遵守"，但你写一条"不要删数据库"，真到执行的时候它还是可能手滑——真正卡死动作要用钩子（hook）那一层。所以规则文件的正确预期是：把你口头重复超过两次的要求沉淀下来，让它从"每次都说"变成"开局自带"。

二、两级结构：全局管性格，项目管地形

​​

规则文件分两级，分工完全不同。

全局规则（跟着你走，所有项目共用）——放你的工作方式：

全局规则（~/.claude/CLAUDE.md）

• 动手前列计划，等我确认再改代码
• 任务做完，汇报改了哪些文件，不漏报
• 不确定的决策列成选项让我挑，不要自作主张
• 我的领域背景：8年嵌入式，看不懂的前端黑话要解释

这层决定AI的"性格"——它是什么风格的协作者。

项目规则（跟着仓库走，进版本库团队共享）——放这个项目的地形：

项目规则（./CLAUDE.md）

• 命令：构建 make build，不要直接跑gcc，参数在Makefile里；自检 make check-style，告警必须清零再交付
• 结构：通信协议解析全在 protocol/ 目录，改协议先看 protocol/README.md；数据上报走统一入口 report.c，别绕过它直连socket
• 约束：禁止修改已量产设备在用的通信协议格式，存量固件会解析失败；禁止引入新第三方依赖，除非我明确要求

这层决定AI的"地形感知"——它不再满仓库找文件，开工直接钻进该去的地方。

分级的判断标准一句话：换个项目还成立的，进全局；只在这个仓库成立的，进项目级。"先列计划再动手"放全局，"禁止动协议格式"放项目级——写反了就是全局文件里一堆别的项目用不上的噪音。

还有个中间态：只想对某个项目生效又不想提交给团队的，放 CLAUDE.local.md，记得加进 .gitignore。

三、从零搭：三个动作，十分钟

动作一：先让AI自己起个底。空文件最难写，所以第一版不是你写的——在项目根目录跑 /init，AI会扫一遍代码库，自动生成一份带构建命令、目录结构、命名惯例的初稿。这份初稿的定位是"AI自己能发现的事"，它是地板，不是天花板。

动作二：把你的重复劳动写进去。这才是规则文件的价值所在。判断一条该不该写，就一个标准：这句话你是不是已经对AI说过两遍以上？说过两遍，写进去。对照着挑：

• 你每次都口头交代的流程（"改完跑一下自检"）
• 你每次都要纠正的错误（"导出用Excel别用CSV"）
• 新同事来了也要交代一遍的约定（"上报必须走report.c"）

动作三：用两周，让规则自己长。规则文件不是一次写完的，是养出来的。每次你发现自己在打字纠正AI，停一秒——这句话是不是该进规则文件？写进去，然后这条纠正以后就再也不用打了。我的规则文件里最值钱的几条，全是这么长出来的。

四、三条写法铁律，决定规则听不听话

铁律一：写决策，不写陈述。"本项目是嵌入式Linux项目，用C语言"——废话，AI开仓库十秒就知道了。要写的是你希望它做的判断："改公共库函数前，先检查所有调用方"。

铁律二：可验证，带命令。"代码风格保持一致"没法执行；"命名遵循 module_action 格式，改完跑 make check-style 清零告警"才能执行。给规则配一个能跑的验证命令，AI从"大概遵守"变成"强制自检"。

铁律三：负面清单值钱。"禁止顺手重构无关代码"这条救过我很多次——AI有个美德叫热情，你让它修一个函数，它能把半个仓库重构了，每处都"更好了"，合起来没法review。负面清单是给热情装刹车。

五、文件多大了怎么办：拆，别堆

规则文件每个会话开局都会整份进上下文，吃token还稀释注意力——官方建议单文件不超过200行，超了遵守率明显往下掉。

我的处理方式：主文件只留"每个会话都必须在"的，主题性的内容拆出去。比如协议兼容的细节规则，拆成按路径生效的规则文件——只在AI碰到 protocol/ 目录的文件时才加载。多步流程（比如完整的发版流程）别塞规则文件，做成skill，要用的时候才调。

六、搭完不生效？三步排查

写进去没反应，别急着怀疑人生，按顺序查：

第一步，/context：看内存文件列表里有没有你的文件。没有=没加载，查路径（项目规则必须在项目根目录或 .claude/ 下；子目录里的规则文件是碰到那目录的文件才加载的，不是开局就加载）。

第二步，/doctor：查配置健康度——它会揪出无效设置文件、重复配置，还有一条挺贴心：能从代码里直接推出来的内容它也提示你删掉（比如你写了"用C语言"而仓库满地是.c文件）。

第三步，还在失效？大概率是写法问题不是加载问题：指令太模糊（"保持一致"）、两个文件打架（全局和项目规则冲突）、文件太长稀释了每条规则的权重。按铁律一到三重写那条规则。

最后再压一遍预期：规则文件是"说服"，钩子是"强制"。要卡死的动作上钩子，要引导的行为进规则文件——别让说明书干门禁的活。

七、我的真实规则文件（脱敏版）

全局规则（节选）

• 先计划后动手；计划被否两次以上的方案直接放弃
• 交付时附"改了什么/没改什么/需要你验什么"三段汇报
• 对我的领域（嵌入式/智能硬件）不用科普口吻，直接上术语

项目规则（节选，物业小程序）

• 构建/自检命令、目录职责表（约15行）
• 禁止动存量接口格式：小程序端已发布版本还在调它
• 导出一律Excel（xlsx）不接受CSV：运营要中文表头+筛选
• 报警推送只能走现有自建通道，禁止引入第三方SDK

就这么朴素。规则文件的价值不在写得漂亮，在每一条都来自一次真实的返工——它是你踩坑史的压缩包。

写在最后（此行后台手动加粗）

我是AI工具人手账，8年嵌入式工程师，编码基本全交给AI，我只管审。这个号记录我用AI干活的真实过程——包括踩的坑。

下一篇还是教程线：四条审查清单+打回案例——AI交活之后我怎么审，四条清单每条配一个真实的打回案例，感兴趣点个关注。