摘要：给 AI 助手（Roo Code / Cursor / Claude Code）扩展能力时，「每次都必须做的事」到底该写进规则文件，还是做成 Skill？我踩了个「自己写的规则互相打架」的坑之后，想明白了一个「意图 vs 执行」的双层模型。
标签：
AIPrompt工程Roo CodeCursorLLM工程实践适用对象：用规则文件（rules）或 Skill 扩展 AI 助手的开发者
关于作者：我是一名在校大学生，平时喜欢折腾 AI 助手、自动化脚本这类东西。这篇文章是我踩了「自己写的规则互相打架」的坑之后的一点思考，纯属个人经验，不一定对——欢迎评论区一起讨论，也欢迎指正。
系列说明：这是「折腾 AI 助手」系列的第二篇。 上一篇 [《我的 QQ 机器人被腾讯反复踢下线，折腾了半个月才搞明白》] 讲的是「怎么让机器人稳定活着」——排查掉线、加固守护脚本； 这一篇换个方向，讲「怎么让 AI 助手真正听话」——规则文件和 Skill 到底该用哪个。 两篇的共同点就一句话：别迷信工具，先搞清楚它到底在干嘛。
开头：先别急着装 Skill
如果你也是刚接触 AI 的小白——就像我一样——那你大概率经历过这么一幕：
打开短视频，一个博主甩出十个「神仙 Skill」，说装上之后 AI 直接起飞；划到下一个，另一个博主又甩出十个，说这才是真正的效率神器。一百个博主，一百套推荐，看得你眼花缭乱，啥都想要，结果啥也没搞懂。
我特别理解那种感觉。因为我也这么过来的。
所以这篇文章，我不做任何 Skill 推荐。我只想聊一件事——
Skill 和规则文件，到底该用哪个？
而且我想先抛一个可能有点反直觉的观点：很多时候，你直接给 AI 下一道死命令、把这条命令刻进它的记忆里，可能比装一个 Skill 更省事、更可靠，甚至更省 Token。
别急着反驳，往下看。
先说个我自己的糗事。
我给自己的 AI 助手写规则文件，写着写着，顶部写了一句「成品放桌面根目录」，底部又写了一句「所有文件放测试文件夹」。两条规则直接打架。结果就是——AI 每次执行的时候，随机命中一条，行为完全不可预测。我盯着它一会儿把文件放桌面、一会儿放测试文件夹，愣了半天才反应过来：是我自己写的规则在互相拆台。
这件事让我意识到，规则文件这东西，不是「写得越多越保险」，恰恰相反。
下面聊聊我踩坑之后想明白的东西。
一、问题其实是个伪命题
一开始我纠结的是：「每次任务都必须做的事」（比如读记忆、按固定格式交付、任务后复盘），到底该放规则文件，还是做成 Skill？
我一度给出过一个自认为很干净的答案：
强制行为放规则，可选能力放 Skill。
听起来很对，对吧？但这个二分法有漏洞。
举个反例：
「每次提交代码前，必须跑一遍
npm test。」
这是个强制动作，按上面的二分法，它「该放规则」。可是——规则文件是纯静态文本，它根本没法执行测试啊。 真正跑测试的只能是 Skill（终端执行工具）。
所以这条强制行为「该放规则」，但规则又执行不了，自相矛盾。
我卡在这儿想了挺久，后来才想通：我把「意图」和「执行」这两件事混在一起了。
二、想通之后：规则管「什么时候」，Skill 管「怎么做」
正确的拆法是这样：
| 维度 | 归谁 | 回答什么问题 |
|---|---|---|
| 意图与触发时机（When & Must） | 规则文件 | 「什么时候、必须做什么」 |
| 执行能力（How） | Skill | 「具体怎么做到」 |
说白了，规则文件就是用来喊口号的——它规定「必须干嘛、什么时候干」；真要动手干活（查库、编译、跑测试），还得靠 Skill 把具体的工具挂载上去。
规则文件是发号施令的，Skill 是干活的。规则喊「必须开火」，但扣扳机的是 Skill。
三、为什么「强制行为」不能只靠 Skill？
你可能会问：既然 Skill 能干活，那我把所有东西都塞进 Skill 不就行了？
不行。原因有两个，第二个特别隐蔽。
第一个：Token 会被撑爆
如果不把行为抽离成 Skill，而是把几千字的「复盘标准、格式要求、检查清单」全塞进规则文件，那么每一次对话都要背着这份庞大的上下文。
我实测过，挺夸张的：把所有规范全塞进 rules，系统提示词直接干到 3000+ Token；一旦把执行逻辑抽离到 Skill，rules 只留「触发条件」，瞬间瘦身到 200 Token 左右。
按每天 100 次对话算，光这一项，每天就白烧掉一大截上下文。
第二个：注意力会被稀释（这个更坑）
更隐蔽的代价是注意力失焦。
LLM 有个著名的毛病叫 「Lost in the Middle」——上下文一长，模型对中段信息的注意力就明显下降。
后果就是：前置规则写太长，模型反而会忽视你当前说的话。
你以为「规则写得越全越保险」，实际是「规则越长，越容易被无视」。这个反直觉的点，我是被坑了好几次才信的。
那 Skill 到底强在哪？
Skill 的核心价值不是「多一个工具」，而是**「按需挂载上下文」**——只在真正需要的时候，才把那几千字的详细流程注入进来，平时不占额度、不干扰注意力。
效果有多明显？我自己的体感是：全塞进 rules 的时候，AI 经常忘东忘西，执行成功率也就及格线水平；一旦把执行逻辑抽离到 Skill，rules 瘦到 200 Token 左右，只要触发条件写对了，AI 执行起来几乎百发百中。
（具体数字我就不编了，反正差距大到肉眼可见。）
四、规则文件最大的坑：自己跟自己打架
回到开头那个糗事。
规则文件越写越多，极易出现「新旧规则打架」：
- 真实案例：我的规则文件顶部写「成品放桌面根目录」，底部写「所有文件放测试文件夹」——自相矛盾。AI 每次执行随机命中一条，行为不可预测。
- 根因：新规则覆盖旧规则的时候，旧规则没删。
- 对策：新增规则时，必须检查并删掉/修正冲突的旧规则；定期审计。
这就是工程实践里典型的「屎山」问题，很痛，但特别容易被忽视——因为你自己写的时候，两条规则看起来都「挺对的」。
五、我现在的维护原则
被坑够了，我给自己定了几条：
- 规则文件保持精简，只放「意图与触发时机」，不放「执行细节」；
- 新增规则前先查有没有跟旧规则冲突；
- 定期审计规则文件，删掉过时的；
- 规则文件是「手术刀」，不是「杂物箱」；
- 可选能力一律放 Skill，别污染规则文件。
六、Skill 该怎么用
- 放「按需调用」的能力：比如「生成 MCP 服务器」「创建自定义模式」；
- 放「低频但复杂」的流程：比如「发布文章到掘金」「跑完整测试套件」；
- 不放「每次都要」的强制行为本身——但可以在规则文件里写死「必须调用该 Skill」的触发条件。
七、一个能直接抄的混合写法
光讲理论没意思，给个我自己在用的写法。
规则文件（比如 .roo/rules/工作流.md）
【强制工作流】
1. 需求分析阶段：必须调用 `read_memory_skill` 获取用户偏好。
—— 触发条件：任何新任务开始时。
2. 代码完成阶段：严禁直接提交！
必须先调用 `lint_check_skill` 自检。
如果检查未通过，自行修复直到通过为止。
—— 触发条件：任何代码修改完成后、提交前。
3. 任务结束阶段：必须调用 `archive_memory_skill` 归档。
—— 触发条件：任务完成时。
对应的 Skill（按需挂载的详细流程）
# read_memory_skill
1. 读取 D:/记忆库/索引文件.md
2. 按关键词匹配相关会话
3. 返回命中的偏好条目
# lint_check_skill
1. 运行 eslint / prettier
2. 若报错，返回错误列表
3. 修复后重新运行，直到通过
关键点：规则文件里只写「必须调用」和「触发条件」（大概 200 Token），详细步骤全部沉到 Skill 里按需挂载。这样既保证了「强制」，又避免了上下文膨胀。
八、最后抄个作业
嫌长不看的，记住这三条就够了：
- 静态的约束（格式、语气、规避词）：放规则文件。
- 动态的动作（查库、测试、发帖）：必须写成 Skill。
- 两者怎么连？ 在规则文件里写死一句：「完成代码后，必须调用 xxx Skill 进行自检」。
一句话：规则文件管「意图与触发时机（When & Must）」，Skill 管「具体执行（How）」。
别再把规则文件当杂物箱了，它越干净，AI 越听话。
