S24-B03 · 提示词、规则与配置：把要求"固化"下来

适用读者：每次都要重复交代"用我们的规范"的人。
前置：S24-B01、S19-B02（提示词结构）。
口径：各工具的文件名/字段不同，机制一致：规则文件 + 钩子 + 配置。
覆盖旧文：676(198) 687(287) 675(205) 681(195) + 提示词类 = 1,339 点。
覆盖扩展：E-S24-003（规则与钩子的"卡点/扳机"）。
上一篇：S24-B02 · 跑通第一个任务：安装、CLI/IDE/桌面/云端
下一篇：S24-J01 · 工具链。

1. 一句话结论

规则文件解决"每次重复交代"，钩子解决"必须在某一步执行检查"。前者是约束，后者是强制执行点（卡点与扳机）。

机制	作用	类比
规则文件（`CLAUDE.md` 类）	常驻约束（风格/命令/禁区）	团队规范文档
钩子（Hooks）	在特定时机强制运行（提交前跑 lint）	Git hook / CI 门禁
配置（`config.toml` 类）	模型/权限/工具开关	应用配置

2. 规则文件该写什么（E-S24-003）

该写	不该写
构建/测试命令（怎么跑）	大段业务背景
代码风格与命名	可从代码看出的结构
禁区（别动 `vendor/`、别改 `pom.xml`）	一次性的任务说明
提交信息格式	常识性建议

判据："这条要求下次还会用到吗？" 会 → 写进规则；一次性 → 会话里说。

"为什么禁区比建议更重要"：模型不会自动知道"这个目录不能碰"——明确的禁止项能避免大部分越界改动。

3. 钩子：把检查变成"强制"

时机	典型钩子
改文件后	自动格式化
提交前	lint + 单测
工具调用前	权限校验/审计

"规则 vs 钩子的区别"：

	规则	钩子
执行方式	模型"尽量遵守"	代码强制运行
可靠性	中	高
适用	约定、风格	必须执行的检查

判据："这条不执行会出事吗？" 会 → 钩子（不能只靠规则）。

4. 配置文件的三个关键项

项	影响
模型选择	成本与能力
权限/审批模式	能不能自动执行命令（A01）
MCP/工具开关	能接哪些外部能力（J01）

"配置为什么要进版本库"：团队要一致——但密钥绝不能提交（S20-A02）。

5. 五个误区

误区	真相
"规则写得越多越好"	太长会被忽略
"规则能替代钩子"	规则是"尽量"，钩子是"强制"
"配置只写本地"	团队应统一
"规则里可以写密钥"	绝不能
"钩子会拖慢流程"	但它挡的是真事故

6. 自检

规则文件与钩子的分工？
规则该写什么、不该写什么？
为什么"禁区"比"建议"重要？
三种钩子时机？
配置文件该进版本库吗？密钥呢？

7. 下一篇

S24-J01 · 工具链：MCP、Git/PR、外部集成与 Computer Use

规则讲完，进阶层开始：它怎么"看见"和"动手"。

本篇属于系列《S24 · AI 编程工具》。旧文来源：A-676/687/675/681 + 提示词类卡；扩展点 E-S24-003。