今天在给自己项目的 CLAUDE.md 补一段写作规则，顺手去 claude-code 的仓库里翻翻别人都是怎么写的，翻到 issue #77136。这条是 7 月 13 号 pbower 开的，到今天还挂着 area:model 和 bug 两个标签，没有 assignee，也没有关联的分支或者 PR。讲的是 Claude 4.7 之后几个版本，4.8、5.0、Fable 都在内，默认文风越来越容易滑进一套固定的修辞套路，连在 system prompt 里写清楚风格要求也压不太住，用户会反复重读一个句子才能把意思抠出来。
这条 issue 本身对不对，我不在这里评价，里面的细节比我这几句转述多得多。我想做的只是把它那份 workaround 清单拆开看看，挑出一条自己试过、确实有用的记下来：想让输出变清楚，别写"简洁一点"，去写禁止清单。读完这篇你能拿到一份可以直接贴进自己规则文件的最小清单，外加一个验证它到底有没有生效的笨办法。
为什么"简洁一点"这四个字基本没用
原理我理解成这样。模型拿到"简洁"这个词的时候，并不知道你要的是哪一种简洁。它手上能用的信号里，"每个句子里塞进更多信息"是最容易被执行成简洁的那一种 → 结果句子确实短了，但每句话里堆的名词更多，读起来反而更费劲。issue 里有一句我印象挺深，大意是用户要求简洁之后，拿到的往往是更短但更晦涩的文本，而不是更清楚的文本，跟上面这个机制是能对上的。
禁止清单给的是另一类东西：一批能逐条比对的硬条件。哪一句里出现了某个词，哪一个段落用了一个需要解码才能看懂的比喻，都是能指出来、能删掉的动作，不需要模型去猜你的口味。这个差别我自己的体感很清楚：写"简洁一点"，下一轮输出只是变短；写"不要用比喻、不要自造术语、结论放第一句"，下一轮输出是真的变清楚了。这个对比前后跑了大概三四次，结果都一样。
我现在那几条规则，大概长这样
## 写作规则
- 结论或判断放第一句；支撑细节只在会改变结论的时候才写
- 不要用比喻、格言、自造术语；行业里已有的说法就用已有的说法
- 不要用"这不是 X"开头，先说它是什么
- 不确定就直接写"不确定"，不要写防御性的铺垫句
- 禁用词：load-bearing、prose、hand-waving、oracle、constellation、honest framing
前四条是行为约束，最后一条是词表。词表这条看着最笨，却是最好使的，因为词是能直接 grep 的，不用靠感觉判断。我顺手写了个只有一行的检查塞进 CI：
grep -niE 'load-bearing|prose|hand-?waving|oracle|constellation' docs/**/*.md
命中就改，不改就过不了。一开始我把这条挂成了 pre-commit hook，提交前扫一遍，后来发现太吵，改一行文档也要等它跑完，才挪到 CI 上去。这一步看着很不技术，但它把"文风"这种本来全靠主观判断的事情，变成了一个能通过或者不通过的检查，至少在我这里，比在提示词里反复强调"请简明扼要"有用得多。
验证这一步别省，而且要隔几轮再验一次
规则写完不等于生效，得跑一遍才知道。我是按这个顺序试的：
- 新开一个会话，不要在当前已经聊过几十轮的会话里测，那个上下文早被前面几轮的回答染过了。
- 丢一个你平时最容易读晕的问题进去，我一般用"这两个方案选哪个"。
- 只看第一句。第一句是结论或者判断，就算过；第一句是"这是个复杂的问题，取决于……"，就算没过。
- 再聊四五轮别的，回来重问一次同一个问题，看文风有没有漂回去。
💡 小技巧：第四步比前两步重要。很多规则文件在前两轮是有效的，聊到后面就失效了，这条 issue 里也提到用户自己设定的风格指令不会一直保持，几轮之后语气会自己漂回来。
如果第四步真的漂回去了，第一件要怀疑的事不是规则写得不够狠，而是它没有放在每次会话都会被读到的位置。写进 CLAUDE.md 比在对话中间临时叮嘱一句靠谱得多，后者基本上管不了几轮。这个坑我绕了两次才躲开，第一次一直以为是自己那几条写得不够明确，其实放错地方了。
一个我自己先踩了的坑
这条 issue 里提了一句我一开始没当回事的话：把文风限制压进 system prompt，有可能会损伤推理质量。理由我觉得挺合理——模型是靠写来想事情的，你把它推理过程中本来要写出来的那部分文字砍掉，很可能连带着把那部分思考也砍掉了。这一点我手上没有能拿出来的对照实验，所以不敢说它一定成立，写在这里只是当个提醒。
但它确实改变了我写规则的方式。我现在只禁表达层的东西：禁词、禁句式、禁比喻、禁开场方式，不去禁"想的过程"。比如我不会写"不要犹豫"，而是写"不确定就一句话说清楚"，重点是让犹豫压成一句话，不是让它从输出里消失。这一条我也是先写错了一版才调过来的，第一版直接把"不要出现任何不确定的表达"写进去了，结果它开始在明显没把握的地方也硬给结论。
还有一条别人的 workaround 我没抄：有人会把输出再过一遍更小的模型，拿一个平实的摘要出来。绕一层是有代价的，这条 issue 里也算了这笔账，反复走 hook 会把 token 成本往上翻。我暂时宁愿在源头把规则写对，也不想给自己加一条一直在跑的流水线。以后要是规则怎么调都不够用，再回头考虑这条路。
划重点
- "简洁一点"换来的通常是更短但更晦涩的输出；换成三到五条能逐条比对的禁止项，换来的才是真的更清楚。
- 禁表达层的东西，别禁思考过程。推理质量比文风更容易被顺手误伤。
- 规则写完要验证，而且要隔几轮再验证一次；漂回去了，先怀疑规则放的位置，不是规则本身写得不够狠。
可以拿你手上那份规则文件试一遍：把里面"简洁一点""简明扼要"这类话删掉，换成三到五条能逐条比对的禁止项，同一组问题前后各跑一遍，对比着看。踩到别的坑欢迎回来留言，我一起补一条。