做产品 PMaker
空格的键盘
每次都要重讲
「记得加空态和错误态」
「间距用 8 的倍数」
「权限判断放后端」
「别新造按钮组件」
第五次说同样的话
说了三次
就该往上挪
CLAUDE.md
## 组件
- 异步组件必须实现四态
- 优先复用 ui/ 下的已有组件
## 样式
- 间距只用 4/8/16/24/40/64
## 安全
- 权限一律后端校验

同一句话说到第三次,说明它不属于这一次对话,属于这个项目。

Distilling rules

Rules you keep repeating go into project files, so you do not have to say them again. But that file has to stay lean — otherwise it becomes noise itself.

What you'll run into
  • 每开一个新会话都要重新交代一遍项目规矩
  • 约束文件越写越长,最后它开始不遵守了
  • 文件里还留着三个月前的规矩,现在早就不这么做了

What to distill

类型例子
会导致返工的技术规矩权限一律后端校验、金额在后端算、密钥不能进代码
全站统一的设计约定间距只用这六个值、颜色只用令牌、组件必须实现四态
明确不做的范围不做团队协作、不做移动端。挡住「顺手补齐」
协作方式先给方案再写代码、改动前先更新规格文件、做完自检并报告
项目的入口信息目录结构约定、命令怎么跑、组件放在哪
An outdated rule is worse than no rule. It will make the AI reliably produce something you no longer want, and because "that is what the file says," it is hard to spot.

How to write it

约束文件不是硬性开关,模型是按概率遵守的 每条被 遵守的 概率 控制在两百行以内 0 200 行 越写越长 逐行审的那个问题 删掉这一行,它会不会犯错?不会,就删。 过时的约束比没有约束更糟 它会让 AI 稳定地做出你已经不想要的东西
An outdated rule is worse than no rule. It will make the AI reliably produce something you no longer want, and because "that is what the file says," it is hard to spot.

How to keep it from bloating

A rules file is not a hard switch; the model follows it probabilistically. The longer it gets, the lower the chance each line is taken seriously — which is why it has to stay thin.

逐行审的问题
删掉这一行,它会不会犯错?
不会,就删掉。这个筛子能砍掉大半内容——多数人写的约束文件里,一半是在描述项目而不是在约束行为。
几条硬指标
· 控制在两百行以内
· 每条都能对应一个具体行为
· 每月删一次过时的
· 加新条目前先看能不能合并已有的
An outdated rule is worse than no rule. It will make the AI reliably produce something you no longer want, and because "that is what the file says," it is hard to spot.

One more practice: after the rules are written, restate the few key ones in the current instruction anyway. The file holds the long-term baseline; the instruction holds the focus for this run. The two are not substitutes.

One level up: skills

Rules govern "what to follow when doing the work." One level above that is "how to do a certain kind of task" — for example, a fixed release process, or the way a walkthrough checklist is run. This kind of content is longer and more process-like; it fits better as a standalone file you call in when needed, rather than something that sits in context every time.

The test is simple: what has to take effect every time goes into the rules; what you only reach for occasionally becomes a callable file. That keeps the rules file thin while the complex processes do not get lost.