我把AI写后端代码的"规则"从200行砍到60行，它反而更靠谱了

这事儿得从一次"翻车"说起

上个月我加了50条规则进Trae的Rules，心想这下AI写后端总该懂我了吧？结果我明确说了"用Yii2的ActiveRecord"，它啪一下给我整了个原生PDO::query()。我说"业务逻辑放Service层"，它把SQL塞Controller里，胖成球。

最气的是，这些我都写进规则了啊！

后来才发现，是我把它的"脑子"塞爆了。规则不是越多越有效。

我也曾是个"规则狂魔"

刚用Trae那会儿特兴奋，能写代码、能重构，简直神器。

但爽了没两天，AI总按自己的"老习惯"来。你让它用ActiveRecord，它给你写原生SQL。你让它Controller只做校验，它把DB查询全怼进去。气得血压高。

我的第一反应：规则不够细，继续加！

从30行一路干到200多行。技术栈、命名规范、路由、Controller写法、Service层、Model关联、ActiveRecord用法、返回格式……能塞的全塞了。

结果呢？该犯的错一个没少。原生SQL照用，Controller照胖，N+1查询满天飞。

我开始怀疑人生。

真相扎心了：AI的"注意力预算"就那么多

后来我才弄明白。Anthropic官方说了：AI在读到你的规则之前，系统提示词已经吃了三分之一"注意力预算" 。Claude Code自带约50条指令，剩下那点额度，你塞100多条规则进去，它根本记不住。

更扎心的是，Rules文件不是"圣旨"。它会被塞进上下文，带着一句潜台词："这些内容不一定跟当前任务有关，不太相关的话可以不管。 "

你写的规范，AI觉得跟你现在要写的登录接口关系不大，它就真敢跳过。

痛定思痛，我把规则从200行砍到60行

研究了Karpathy的配置，就65行，又扒了Trae官方文档的最佳实践，才恍然大悟——好规则是"养"出来的，不是"写"出来的。

第一步：让AI自己"摸底"，你来删减

别自己脑补规则。让AI扫描整个代码库自动生成初稿——Trae里有这个能力。

这一步产出的内容通常偏长，需要你大幅删减。但它的价值在于，AI"看"出来的项目结构比你凭感觉写的准得多。比如它会发现："哦，路由在config/routes.php里配的。"这些细节你自己写很容易漏。

删减标准就一条：去掉这条规则，AI会犯错吗？ 会就留，不会就删。

留3-5条核心的足以开局：技术栈、数据库操作方式、分层约定。

第二步：哪儿疼治哪儿，让AI自己补规则

用了一两周，AI老在同一个地方翻车。这时候两个办法：

办法一：你手动加。
同一个错误纠正了第三遍，就写进Skill。比如AI老是不用with()预加载导致N+1，纠正三遍就该写进去了。Anthropic官方也说了，Claude犯同一个错第二次就该考虑加规则。

办法二：让它自己补。
这是更省力的玩法。你直接跟AI说：

"你刚才又忘了用with()预加载，这已经是第三次了。把这个规则补充到Rules文件里，确保下次不会再犯。补充完给我确认。"

AI会自己把规则写出来。你只需要看一眼，确认"禁止N+1，必须用with()"这个核心意思对了，就让它写入。它自己写的规则，它自己记得更牢——听起来玄学，但实测有效。

两种办法结合着用，一天最多加2-3条新规则，别贪多。

第三步：到点儿就砍

文件膨胀到100行以上，效果开始打折扣。
60-100行效果最好，超过200行基本是花钱买噪音。

怎么砍？开个新会话，让AI光凭Rules内容列出你们项目的10条规范。它列得出来的，是真正被记住的；列不出来的，早被淹没了——直接删。

删掉的规则挪哪儿去？Trae支持按需加载：

• 每次会话都需要 → 留在主文件
• 碰特定文件才需要 → 挪到子目录规则文件里
• 特定工作流才需要 → 做成独立子Skill

我现在稳定在60行，AI反而听话多了。

让AI听话的四个"咒语"

咒语一：禁止 + 替代（效果立竿见影）

❌ "用ActiveRecord操作数据库"
✅ "禁止使用原生PDO::query()，一律用ActiveRecord或QueryBuilder"

AI读过的代码里原生SQL太多了，光说"用ActiveRecord"它手一滑还是老习惯。先说"禁止用PDO"，它每一步都会刻意避开。

咒语二：具体到能判对错

❌ "Controller写规范点"
✅ "Controller只做参数校验和Service调用，不允许直接出现Model::find()->where()"

前者AI自己解读，每次不一样。后者做没做到一眼就能看出来——翻Controller里有没有ActiveRecord查询就行。能不能判对错，是衡量规则质量的唯一标准。

咒语三：关键规则加粗放顶部

对真正不能违反的规则，加粗大写：YOU MUST，放文件最顶部。

但每条都加粗等于每条都没加粗，最多2-3条用这个待遇。

咒语四：只写"地图"，不写"百科全书"

别把表结构、接口文档全贴进去。Rules里面加一个入口就行，详细资料拆成独立文件，AI需要时自己去读。

表结构见 common/models/
API文档见 docs/api/

不相关的任务不占上下文预算，省下的留给真正重要的规范。

进阶玩法：把流程固化成Skill

Skill不只是"规则文件"，更是可执行的专业能力包。

我写了个"API开发"Skill，定义完整工作流：

> Step 1：确认请求方法、参数、鉴权  
> Step 2：建Model/迁移文件  
> Step 3：Service层实现业务逻辑  
> Step 4：Controller调Service，统一格式返回  
> Step 5：配路由  
> Step 6：验N+1——所有关联有没有用`with()`

AI按流水线走，不会东一榔头西一棒槌。

现在我的Rules长这样

# 核心原则（放顶部，2条，带YOU MUST）
**YOU MUST** 禁止N+1查询，所有关联必须用with()预加载
**YOU MUST** API返回格式：['code' => int, 'data' => mixed, 'msg' => string]

# 架构约束（3条，定义边界，不定义实现）
- 分层边界：Controller→Service→Model，单向依赖，禁止跨层调用
- 数据库：禁止原生SQL，用AR或QueryBuilder，复杂查询走Repository
- 事务边界：事务放在Service层，Controller不开启事务

# 设计原则（3条，防AI过度设计）
- 新增字段先确认是否有现成Model，禁止重复建表
- 缓存策略统一用Cache组件，禁止直接操作Redis
- 配置项集中管理，禁止硬编码

# 代码规范（引用外部，不重复写）
命名规范：https://www.yiiframework.com/doc/guide/2.0/zh-cn/...

仔细看，这份Skill里没有任何"怎么做"的内容：

• 不写ActiveRecord怎么用——AI本来就会
• 不写Controller怎么写——AI本来就会
• 不写路由怎么配——AI本来就会
• 不写迁移文件长什么样——AI本来就会

它只做三件事：拦住AI的坏习惯、守住架构边界、防止过度设计。
AI缺的不是说明书，是"什么不能做"的禁令。你把"怎么做"写得越细，它越像在背课文，一遇到实际情况就卡壳。但你给它划好边界，它在边界内的发挥反而更稳定。

Karpathy那65行Rules的核心逻辑就是这个——全是行为准则，没有操作手册。
"Think Before Coding"、"Simplicity First"、"Surgical Changes"，每一条都在约束AI的行为惯性，而不是教它怎么写代码。

写Rules的最高境界，是让AI感觉不到规则的存在，但又处处被规则约束。

总结经验教训后的三句话

规则不是越多越好，是越精准越好。

好的Rules是"养"出来的，不是写出来的。 写代码要迭代，写规则也一样。

AI犯错，别急着加规则——先看看是不是写太多了。 砍掉一半试试，可能它反而记住了。

你那个Rules规则现在多少行？要不要试试砍一半？

参考来源：

Karpathy
https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md?plain=1

Trae官方文档最佳实践
https://docs.trae.cn/ide_best-practice-for-how-to-write-a-good-skill