约束沉淀
反复要重申的规矩，写进 CLAUDE.md 和 Skill。
反复要说的规矩写进项目文件，之后不必再说。但这份文件要一直保持精简，否则它自己会变成噪音。
你会遇到的现象：
- 每开一个新会话都要重新交代一遍项目规矩
- 约束文件越写越长，最后它开始不遵守了
- 文件里还留着三个月前的规矩，现在早就不这么做了
哪些该沉淀
| 类型 | 例子 |
|---|---|
| 会导致返工的技术规矩 | 权限一律后端校验、金额在后端算、密钥不能进代码 |
| 全站统一的设计约定 | 间距只用这六个值、颜色只用令牌、组件必须实现四态 |
| 明确不做的范围 | 不做团队协作、不做移动端。挡住「顺手补齐」 |
| 协作方式 | 先给方案再写代码、改动前先更新规格文件、做完自检并报告 |
| 项目的入口信息 | 目录结构约定、命令怎么跑、组件放在哪 |
反过来，不该沉淀的是：只在某个模块成立的规则（那属于规格）、描述性的项目介绍（它不约束任何行为）、以及一次性的临时要求。
怎么写
- 写成祈使句，不写成描述。「间距只用 4 的倍数」是约束，「本项目采用 4px 网格体系」是介绍。后者不改变它的行为。
- **用标题分区，用短句列条。**清晰的分节让它能定位到相关的那一段，而不是每次通读。
- **关键的地方补一句为什么。**知道理由，它在边界情况下才能正确推广这条规则。但只补关键的几条，不要每条都写。
- **放最前面。**上下文的开头和结尾最容易被记住，中间最容易被忽略。
怎么防止它膨胀
约束文件不是硬性开关，模型是按概率遵守的。写得越长，每一条被认真对待的概率越低——这决定了它必须一直保持薄。上下文工程的实践也指向同一个结论：上下文是有限的稀缺资源，文件越薄，关键规则被记住的概率越高；加新内容前先问它是否值得占用额度。context-eng
维护时用「逐行审」这个筛子：**删掉这一行，它会不会犯错？不会，就删。**多数人写的约束文件里，一半是在描述项目而不是在约束行为。几条硬指标：控制在两百行以内、每条都能对应一个具体行为、每月删一次过时的、加新条目前先看能不能合并已有的。
还有一条实践：**约束写完之后，关键的几条仍然要在当下的指令里重申一次。**文件负责长期基线，指令负责这一次的重点，两者不是替代关系。
再上一层：技能
约束管的是「做事要遵守什么」，再往上还有一层是「某类任务怎么做」——比如一套固定的发版流程、一份走查清单的执行方式。这类内容比约束更长、更像流程，适合单独放成一个文件，需要时再调用，而不是每次都占着上下文。
判断标准很简单：**每次都要生效的写进约束，偶尔才用到的做成可调用的文件。**这样约束文件能一直保持薄，而复杂流程也不会丢。反过来也成立：发现某个约束只在特定任务里出现，就把它从约束文件挪进技能文件，别让它占着每次都要读的上下文。