约束沉淀

反复要说的规矩写进项目文件，之后不必再说。但这份文件要一直保持精简，否则它自己会变成噪音。

你会遇到的现象

哪些该沉淀

类型	例子
会导致返工的技术规矩	权限一律后端校验、金额在后端算、密钥不能进代码
全站统一的设计约定	间距只用这六个值、颜色只用令牌、组件必须实现四态
明确不做的范围	不做团队协作、不做移动端。挡住「顺手补齐」
协作方式	先给方案再写代码、改动前先更新规格文件、做完自检并报告
项目的入口信息	目录结构约定、命令怎么跑、组件放在哪

反过来，不该沉淀的是：只在某个模块成立的规则（那属于规格）、描述性的项目介绍（它不约束任何行为）、以及一次性的临时要求。

约束文件不是硬性开关，模型是按概率遵守的。写得越长，每一条被认真对待的概率越低——这决定了它必须一直保持薄。

逐行审的问题

删掉这一行，它会不会犯错？

不会，就删掉。这个筛子能砍掉大半内容——多数人写的约束文件里，一半是在描述项目而不是在约束行为。

几条硬指标

· 控制在两百行以内

· 每条都能对应一个具体行为

· 每月删一次过时的

· 加新条目前先看能不能合并已有的

过时的约束比没有约束更糟。它会让 AI 稳定地做出你已经不想要的东西，而且因为「文件里就是这么写的」，很难被发现。

还有一条实践：约束写完之后，关键的几条仍然要在当下的指令里重申一次。文件负责长期基线，指令负责这一次的重点，两者不是替代关系。

约束管的是「做事要遵守什么」，再往上还有一层是「某类任务怎么做」——比如一套固定的发版流程、一份走查清单的执行方式。这类内容比约束更长、更像流程，适合单独放成一个文件，需要时再调用，而不是每次都占着上下文。

判断标准很简单：每次都要生效的写进约束，偶尔才用到的做成可调用的文件。这样约束文件能一直保持薄，而复杂流程也不会丢。