Claude Code多数抱怨实为上下文问题

大多数 Claude Code 的抱怨都是上下文问题，不是模型问题

我最近花了一些时间泡在 Claude Code 社区里，读了很多抱怨的帖子。模型被削弱了。Token 用量暴涨。它不理会我的 CLAUDE.md。它说得很模糊，不肯解释自己。

其中有些确实是真问题。但读多了之后，一个规律浮现出来：同样的底层问题不断披着不同的外衣出现。它几乎总是跟上下文有关——窗口里有什么、模型被要求去推断什么、以及没人明确告诉它的东西。

下面是四个我反复碰到的版本，以及真正管用的修复方法。

"Token 用量突然暴涨"

抱怨：工作量没变，用量却翻倍了。

通常的原因：会话太长了。每一轮都会重新发送完整的对话历史。一个跑了两小时的会话，代价不只算你最后那条消息，而是从开始到现在每一条消息在每一轮都被重新发送。

修复方法很朴素：结束会话，重新开始。把持久状态存在文件里（PROJECT.md、便签文件），而不是让它们堆积在对话里。这样每个新会话一开始就是精简的，只读它需要的东西。

一个有用的信号：如果你想不起会话开头问了什么，说明会话已经太长了。

"它不理会我的 CLAUDE.md"

抱怨：规则写好了，模型却不遵守。

通常的原因：文件太长了，而且规则只是干巴巴的断言。

有两件事一贯有效。第一，更短。四十条被稀释的规则不如十二条被执行的规则。第二，附上原因。对比一下：

Never use raw SQL string concatenation.

Never use raw SQL string concatenation, injection risk.

第一条是模型逐字执行的规则，只针对命名的那个确切模式。第二条是一个原则，模型会把它推广到整个类别：参数化查询、ORM 误用、任何存在相同风险的地方。模型从原因中推导的能力远比从列表中顺从的能力强得多。

"它说得很模糊，不肯解释自己"

抱怨：它说"有一些问题需要处理"，你花三轮才把意思套出来。

通常的原因：你要求的是清晰——这是一个形容词，而不是约束。

让模型"表述清晰"或"像高级工程师一样思考"，是给了它一个人设，而不是规格。它没有办法知道你所说的清晰是什么意思，所以默认会用带修饰的、安全的措辞。

把形容词换成结构。不说"清晰解释问题"，试试：

对每个问题，声明：
- 文件和行号
- 哪里坏了
- 你提出的具体修复方案

如果填不满所有三项，据实说明，不要猜测。

这样会产生两个效果。模糊无处藏身，因为每个格子都必须填满。当模型真的不知道某件事时，你会立刻看到，而不是收到一段言之无物的自信段落。

这和技能描述的教训相同，我之前写过：形容词是愿望，约束是指令。

"输出质量感觉不稳定"

抱怨：同一类任务，每天的质量差异巨大。

通常的原因：输入比感觉上的差异大得多。不同的会话长度、不同的前置上下文量、不同的措辞、不同的代码库起始状态。

如果你想知道某样东西是否真的变了，需要一个固定的参照。从你的实际工作中保留两三个提示词作为基准。用相同的提示词、相同的起始状态，每隔几周跑一次，对比输出。

没有这个，你就是在把今天令人沮丧的会话和一个记忆中的好会话做比较，而记忆是个糟糕的比较工具。

它们的共同点

四个问题都是同一错误穿着不同的外衣：假设模型拥有它实际上没有被给予的上下文。

它不知道你的会话变长了。它不知道你四十条规则里哪条最重要。它不知道在你的代码库里"清晰"意味着什么。它不知道上周的输出长什么样。

这些并不意味着模型是完美的，或者抱怨永远是用户的错。真正的退步确实会发生，供应商应该为此负责。但在断定模型变差之前，值得检查一下发生变化的是不是它周围的上下文。

检查成本更低，而且今天就能修复。