约束沉淀 | 与 AI 协作 | 做产品

约束沉淀

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

你会遇到的现象

• 每开一个新会话都要重新交代一遍项目规矩

• 约束文件越写越长，最后它开始不遵守了

• 文件里还留着三个月前的规矩，现在早就不这么做了

哪些该沉淀

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

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

怎么写

• 写成祈使句，不写成描述。「间距只用 4 的倍数」是约束，「本项目采用 4px 网格体系」是介绍。后者不改变它的行为。

• **用标题分区，用短句列条。**清晰的分节让它能定位到相关的那一段，而不是每次通读。

• **关键的地方补一句为什么。**知道理由，它在边界情况下才能正确推广这条规则。但只补关键的几条，不要每条都写。

• **放最前面。**上下文的开头和结尾最容易被记住，中间最容易被忽略。

约束文件不是硬性开关，模型是按概率遵守的

每条被 遵守的 概率

控制在两百行以内

0 200 行 越写越长

逐行审的那个问题 删掉这一行，它会不会犯错？不会，就删。

过时的约束比没有约束更糟 它会让 AI 稳定地做出你已经不想要的东西

这个筛子能砍掉大半内容——多数人写的约束文件里，一半是在描述项目而不是在约束行为。「本项目采用 4px 网格体系」是介绍，「间距只用 4 的倍数」才是约束，后者才会改变它的行为。

怎么防止它膨胀

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

逐行审的问题

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

几条硬指标

· 控制在两百行以内 · 每条都能对应一个具体行为 · 每月删一次过时的 · 加新条目前先看能不能合并已有的

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

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

再上一层：技能

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

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

接着看

规格、提示、约束的分工 三层的完整关系。同一句话该写在哪，取决于它要管多久。

上下文预算 约束文件占的是宝贵的上下文额度。保持薄不只是为了被遵守，也是为了给别的内容留位置。

反面清单 最值得沉淀的内容之一。不写下来，AI 每次都会顺手补齐你不要的东西。