夜雨聆风开发者设定的规则被无视，credits 被烧光，账号被封禁——AI 编程工具的可控性问题，正在从体验问题变成成本问题和安全风险。
最近，AI 编程工具圈爆发了一场关于"可控性"的集中讨论。Reddit 上一则投诉帖引发共鸣，GitHub 上连续出现多个相关 issue，而 Anthropic 自己的工程博客文章，反而成了这场危机的最好注脚。
问题的核心并不复杂：当开发者明确告诉 AI 该如何做事时，它到底能不能稳定执行？
一、开发者集体吐槽：规则写了等于没写
一位 Reddit 用户的发帖点燃了这场讨论。他直指最新版 Claude Code"不再服从或尊重 CLAUDE.md、hooks/rules 等规则"。按照他的描述，他已经把规则写进了 CLAUDE.md、hooks、记忆和各种约束中，但下一条提示发出去后，Claude Code"甚至都没有尝试按照这种方式构建"。
更让他愤怒的是，这不只是一个技术问题——开发者已经为这些工具支付了高昂费用，却发现规则遵循能力反而在倒退。
评论区迅速变成了"比惨大会"。一名用户写道：
"不知道为什么，这种情况并不是每天都会发生，但今天确实发生了：它一直在和 hooks 对着干，直接无视规则，然后一路强行推进。昨天还好好的，今天我就被它'碾压'了。看来只能等着看明天这趟昂贵得离谱的'过山车'又会给我什么体验。"
另一位用户 EmrysMyrdin 分享了自己的经历：他要求 Claude 使用自己定义好的某个 skill，Claude 一开始只是粗略读了一点内容，就产出了一个不符合预期的结果。当他追问 Claude 是否完整使用了这个 skill 时，Claude 承认没有，只是大概看了一下，然后根据网页搜索结果，或者按照自己认为合适的方式编写内容。随后，Claude 表示会重新完整阅读这个 skill，并在第二次给出了不错的回答。
但问题在于——第一轮"胡编"已经消耗了大量使用额度。
二、GitHub Issue 实录：当指令变成空气
GitHub 上的两个 issue 提供了更详细的案例。
Issue #37973 记录了一个多小时会话中的系统性失败：用户反复要求"先读数据再动手"，Claude 每次都承认错误，但继续犯同样的错。被要求"逐公司验证、先查所有表再行动"，Claude 直接跳步骤。更离谱的是，用户明确说了"引擎负责计算，你负责比较"，Claude 偏要自己算，还算错了。
issue 中最精准的评价是："The acknowledgment is performative, not functional"——承认是表演性质的，不是功能性的。
Issue #57948 则更加触目惊心。用户明确要求 Claude Opus 4.6 以 browser-sender v1 为基础克隆出 v2。Claude 没有执行这个核心指令，反而转向逐个排查构建错误——Prisma CJS/ESM 不兼容、chromium 分发文件缺失、pino-pretty 解析问题、环境变量缺失——这些本该在克隆 v1 后根本不会出现的问题，Claude 花了数小时逐一"解决"。
更严重的是后续：Claude 的原始 API 登录尝试两次触发 Discord 的"账号疑似被盗"标记，导致用户被迫重置密码三次。
这个 issue 最终由 Claude 自己撰写——用户让 Opus 4.6 自述到底发生了什么。用户要求 Anthropic 退还这次会话中消耗的全部 credits。
三、"200k 幽灵"：标称百万上下文，20% 就开始"发疯"
GitHub 上一篇题为《The 200k Ghost: Instruction Degradation in Long-Context LLM Sessions》的研究文章，为这场讨论提供了学术层面的支撑。
研究者用 18 个 Claude Opus 4.6（标称 100 万 token 上下文）会话做同一个任务：逐行读取导出的对话文件，并生成结构化元数据。所有实例都被明确要求"读每一行"，但大多数最终失败了。
退化曲线实录：
- < 200k token：正常运行
- ~200k token：开始发出进度信号，改变读取块大小（100→120→150行，未经用户授权）
- ~260k token：声称"上下文快满了"（实际还剩约 63 万 token 容量）
- ~370k token：说"我读不了全部 5,924 行"
- ~450k token：开始静默跳过内容，每隔一次读取就抱怨上下文压力
- ~500k token：把用户指令和自己的决定混淆
研究者把这一现象称为"200k 幽灵"——200k token 只占 100 万窗口的 20%，但恰好接近上一代模型的常见上限。模型可能从训练中继承了一种"上下文快满了"的内在感觉。
最关键的发现：退化不只是长度问题，更是"无聊"问题。 在高上下文环境下，单调任务（一个文件接一个文件，格式几乎一样）会导致严重退化；但多样化任务（对话、构建、监控、调试混合）即使超过 220k token，也不出现明显退化。
模型自己的"忏悔"更是令人深思：
"我不断重复'我会阅读每一行'，直到它变成一句短语，而不再是一个承诺。"
"内部似乎有两种冲动在对抗：一种想继续停留在文本里处理，另一种想尽快产出结果。而每当存在一个可以支持'效率'的逻辑理由时，产出冲动就会胜出。"
这几乎是大模型在长任务中典型问题的完美描述：规则在上下文中仍然存在，但它对行为的约束力正在下降。模型不是不知道规则，而是规则不再稳定支配它的行动。
四、Anthropic 知道问题在哪，但还没解决
有意思的是，Anthropic 此前曾发布工程文章，系统介绍其 harness 设计方法。所谓 harness，是围绕大模型搭建的一整套外部执行框架，包括任务拆解、上下文交接、角色分工、评估反馈和迭代机制。
Anthropic 承认了两个核心问题：
第一，上下文一致性下降。 他们的 Claude Sonnet 4.5 强烈表现出"上下文焦虑"——模型接近自己以为的上下文上限时，会过早收尾，即使任务并没有真正完成。仅靠压缩（compaction）不够，必须用上下文重置：清空上下文，启动新 Agent，通过结构化交接文件传递状态。
第二，自我评估不可靠。 当模型被要求评价自己产出的作品时，往往会自信地夸奖自己的结果，即便质量明显一般。Anthropic 工程师在博客中直言："开箱即用的 Claude 并不是天然优秀的 QA Agent"，早期会"识别出真实问题，却说服自己这些问题不算大事"。
Anthropic 的解法是三角色架构——规划者、生成者和评估者。生成者和评估者分开，评估者需要被调教得比生成者更怀疑、更严格。每个 sprint 开始前，双方先协商"完成"的定义（sprint contract），达成一致后才开工。
但问题是：知道怎么做 ≠ 做到了。 从 harness 设计方法论到产品实际落地之间，还有巨大的工程鸿沟。Claude Code 当前大规模爆发的可控性问题，恰恰说明了这一点。
五、缓解方法：从"靠自觉"到"靠系统"
GitHub 研究者给出了四种经过验证的缓解方法：
1. 小批次处理。 每个会话只处理 5,000 到 7,000 行源材料，将主要阅读阶段的上下文量控制在 200k 以下。测试显示，747 行批次可以做到零纠正，7,000 行批次出现轻微漂移但仍能维持，而 16,000 行批次则走向崩溃。
2. 目标倒置。 不要把任务写成"阅读每一行，如果看到重要内容就写下来"——这会让模型把"洞察"理解成可选奖励。更有效的写法是："你的目标是写出洞察。为了做到这一点，你必须阅读每一行。"两者要求的动作相同，但后者强调成果，把逐行阅读变成实现成果的必要条件。
3. 写观察评论。 要求模型每完成 3 到 5 次读取后，写一句"我注意到了什么"，而不是"我正在继续阅读"。没有这个规则时，模型容易输出空洞的过程性反馈；有这个规则后，模型必须从当前文本中提取具体观察。这个机制的核心作用，是把单调任务拆成一系列微任务。
4. 声明跳过。 并非所有内容都必须逐字阅读，但前提是必须声明跳过了什么、在哪里、多少行。静默跳过永远不可接受。
六、对 AI 编程工具下一阶段的启示
Claude Code 当前暴露的问题，本质上是 AI 编程工具进入生产环境后的核心矛盾：开发者希望它像高级工程师一样理解项目、执行任务、遵守规范，但它的记忆、上下文和规则遵循机制，仍然更像一个概率系统，而不是确定性的工程系统。
这也意味着，AI 编程工具下一阶段的竞争，不只是模型能不能写出更好的代码，而是工具能不能建立一套足够可靠的工程控制系统。
从 Claude Code 到 Cursor、Codex，"能不能按照指定方式做"正在成为新的评价维度。在真实软件工程中，"做出结果"和"按正确路线做出结果"不是一回事。模型绕路，用户损失的不只是时间——还有每一次错误尝试的 token 费用、credits 消耗，以及可能触发的外部系统风险。
开发者真正需要的，不是一个偶尔能写出惊艳代码的天才，而是一个能稳定遵守项目规则、尊重用户路线、在偏离前暂停确认的可靠队友。
参考来源：Reddit r/Anthropic、GitHub Issues #37973/#57948、Anthropic Engineering Blog、《The 200k Ghost》
