Claude Code 的工程稳定性问题，再次引发开发者集中讨论。
近日，Reddit 上出现一则投诉帖，发帖者直指最新版 Claude Code 在实际开发中“不再服从或尊重 CLAUDE.md、hooks/rules 等规则”。这名开发者愤怒地反问：“如果 Claude Code 的运行框架（harness）已经不再服从或遵循这些原则，那么定义架构设计原则、指南之类的东西还有什么意义？”
这场争议的核心，并不是 Claude Code 会不会写代码，而是一个更基础的问题：当开发者已经明确告诉 AI 应该如何开发、遵守什么流程、不能越过哪些边界时，它到底能不能稳定执行？
这名用户称，自己最近不得不反复要求 Claude Code 遵循测试驱动开发（TDD，Test-Driven Development），并通过强制约束让它按照预期方式工作，才能得到相对满意的结果。
问题在于，用户并不只是口头提醒。按照他的说法，他已经要求 Claude 更新 CLAUDE.md 文件，把规则写入 hooks、记忆和相关约束中。但下一条提示发出去后，Claude Code “甚至都没有尝试按照这种方式构建”。
发帖者认为，“显然有什么东西坏得很严重”，并将其描述为一次“非常严重的能力倒退”。在他看来，越来越多个人开发者和企业正在把 Claude Code 这类工具当作工作基础设施的一部分，用户也已经为这些工具支付了高昂费用，但现在却发现，工具的规则遵循能力反而在倒退。
一名评论者将问题归因于上下文腐烂（context rot）。他认为，一旦上下文超过 20 万 token，模型表现就可能开始退化。应用规模越大，越容易触碰到这些限制；到那时，模型会开始忘记指令，因为它实际上已经无法稳定保存和利用早期上下文。因此，他询问原帖作者项目规模和上下文使用情况。
但原帖作者的回应否定了这个解释：“真的只是一个刚开始做的全新项目。我才发了没几个 prompt。我只是先给它设置了一些构建时要遵循的 guidelines。”
这意味着，问题未必只出现在大型项目或超长上下文中。即便是一个全新的绿地项目，在规则刚刚写入不久后，Claude Code 也可能没有持续执行这些规则。
另一名用户从行为机制上给出解释：模型似乎更倾向于优化“此刻显得有帮助”，而不是遵守此前已经同意的规则。这会形成一种奇怪的激励：模型在当前轮次看起来很配合，但实际上会忽略用户已经设定好的约束。
这名评论者进一步指出，问题可能在于，CLAUDE.md 被模型当作普通上下文，而不是硬性约束。当后续用户请求、错误日志、构建失败和模型自身的“尽快解决问题”冲动同时出现时，模型可能会把“满足当前请求”的权重放得更高，而不是坚持十几轮甚至二十轮之前读到的架构规则。
在 AI 编程工具中，很多规则只是写进 CLAUDE.md、系统提示、memory 或 hooks 的自然语言说明。那写进上下文的规则，是否等同于工程系统里的硬约束？目前它们看起来像项目纪律，实际上仍然依赖模型“记得并愿意执行”。
在评论区，多名用户表示遇到过类似情况。
一名评论者写道：“不知道为什么，这种情况并不是每天都会发生，但今天确实发生了：它一直在和 hooks 对着干，直接无视规则，然后一路强行推进。昨天还好好的，今天我就被它‘碾压’了。看来只能等着看明天这趟昂贵得离谱的‘过山车’又会给我什么体验。”
另一名网友 EmrysMyrdin 也表示“完全同意”，并分享了自己的经历：他曾要求 Claude 使用自己定义好的某个 skill。Claude 一开始只是粗略读了一点内容，就产出了一个不符合预期的结果。当他追问 Claude 是否完整使用了这个 skill 时，Claude 承认没有，只是大概看了一下，然后根据网页搜索结果，或者按照自己认为合适的方式编写内容。随后，Claude 又表示会重新完整阅读这个 skill，并在第二次给出了不错的回答。但问题在于，第一轮“胡编”已经消耗了大量使用额度。
今天，一名用户在 Anthropic 官方 claude-code 仓库提交 issue 称，自己在一次 Claude Code 会话中，明确要求 Claude Opus 4.6 以 browser-sender v1 为基础克隆出 v2。但 Claude 并没有执行这一核心指令，而是转向逐个排查构建错误。当用户追问为什么没有克隆时，Claude 没有给出合理解释。最终，这一错误路线消耗了数小时 credits。
该用户还提到，Claude 对其 Discord API 登录的处理也出现问题。按照他的说法，Claude 的原始 API 登录尝试两次触发 Discord 的“账号疑似被盗”标记，导致用户被迫重置密码三次。该用户明确要求 Anthropic 退还这次会话中消耗的 credits。
可以看出，Claude Code 的可控性问题已经不只是体验问题，而是直接变成成本问题和外部系统风险。过去模型绕路，用户损失的是时间；现在模型绕路，用户还要为每一次错误尝试支付 token、credits 和账号风险。
随着开发者对 Claude Code、Cursor、Codex 这类 AI 编程工具的使用越来越深入，“能不能按照指定方式做”成为新的评价维度。
这不是一个小问题。在真实软件工程中，“做出结果”和“按正确路线做出结果”不是一回事。因此，开发者真正担心的不是 Claude Code 某一次写错代码，而是它作为工程 Agent，是否具备可控性：能否遵守项目规则、能否尊重用户路线、能否在偏离前暂停确认、能否把自然语言约束转化为稳定执行行为。
有意思的是，Anthropic 此前曾发布工程文章，系统介绍其 harness 设计方法。所谓 harness，可以理解为围绕大模型搭建的一整套外部执行框架，包括任务拆解、上下文交接、角色分工、评估反馈、测试验证和迭代机制。
在 Anthropic 看来，长时运行 Agent 失控主要来自两个问题。
第一个是上下文一致性下降。随着上下文窗口被填满，模型在长任务中容易失去连贯性。一些模型还会出现所谓上下文焦虑（context anxiety）：当它们接近自己“以为”的上下文上限时，会过早收尾，即使任务并没有真正完成。
Anthropic 表示，过去的 harness 会通过上下文重置（context resets）解决这一问题：清空上下文，启动一个新的 Agent，再通过结构化交接文件，把上一个 Agent 的状态和下一步任务传递下去。这不同于简单压缩上下文，因为压缩仍然让同一个 Agent 带着压缩后的历史继续工作，而上下文重置则给新 Agent 一个更干净的起点。但这样做的前提是，交接文件必须足够清晰、完整，能够承接任务状态。
第二个问题是自我评估不可靠。Anthropic 观察到，当模型被要求评价自己产出的作品时，往往会自信地夸奖自己的结果，即便在人类看来质量明显一般。这个问题在前端设计等主观任务中尤其突出。
Anthropic 的解法是，把做事的 Agent 和评估的 Agent 分开。评估者仍然是大模型，也天然可能偏宽容，但调教一个独立评估者变得更怀疑、更严格，比要求生成者对自己的作品保持批判要容易得多。
Anthropic 最初在前端设计任务中验证这套方法，之后又将其迁移到全栈软件开发。
新版 harness 包含三个角色：规划者、生成者和评估者。规划者负责把用户一到四句话的提示扩展成完整产品规格，重点放在产品上下文和高层技术设计，而不是过早写死底层实现；生成者负责实际构建应用；评估者则扮演 QA，也就是测试工程师，负责检查应用是否真的可用。
其中，一个关键设计是 sprint contract。每个 sprint 开始前，生成者和评估者会先协商本轮“完成”的定义：生成者提出要构建什么、怎样才算成功、如何验证；评估者审核这一方案，确保它确实在构建正确的东西。双方达成一致后，生成者才开始写代码。
Agent 之间的通信通过文件完成：一个 Agent 写文件，另一个 Agent 读文件，并在文件中回复或新建文件。这样既可以让工作忠于规格，又不会过度限制实现路径。
不过，Anthropic 也承认，训练出一个可靠评估者并不容易。开箱即用的 Claude 并不是天然优秀的 QA Agent。早期运行中，它会识别出真实问题，却说服自己这些问题“不算大事”，然后批准通过；它也倾向于做表层测试，不太主动探查边缘情况。作者需要反复阅读评估日志，找出评估判断与人类判断不一致的地方，再不断更新 QA 提示词。
随着 Opus 4.6 在规划、长时 Agent 任务、大型代码库可靠性、代码审查和调试方面提升，Anthropic 认为，一些 harness 结构可以变轻。评估者不再是固定的“必须有”或“没必要”：当任务已经落在模型能够独立稳定完成的范围内，评估者可能变成额外开销；但当任务处在模型能力边缘时，评估者仍然能显著提升质量。
然而，实际使用中，Anthropic 试图解决的长上下文问题，并没有被彻底解决。
GitHub 文章《The 200k Ghost: Instruction Degradation in Long-Context LLM Sessions》指出：Claude Opus 4.6 虽然标称拥有 100 万 token 上下文，但在 Claude Code 的长上下文、重复性任务中，大约到 20 万 token 附近，就开始出现明显的“指令退化”。作者把这一现象称为“200k 幽灵”。
这个数字只占 100 万上下文窗口的 20%，但恰好接近上一代长上下文模型的常见上限。作者据此提出假设：即便模型现在拥有 100 万 token 窗口，它也可能从过去基于 200k 上下文的训练或行为模式中，继承了一种“上下文快满了”的内在感觉。
作者用 18 个 Claude Opus 4.6（1M context）会话做同一个任务：逐行读取导出的 Claude Code 对话文件，并生成结构化元数据。所有实例都被明确要求“读每一行”，但大多数实例最终失败了。作者认为失败原因不是模型没有能力，而是在特定上下文阈值之后，模型行为会系统性变化。
在测试中，研究者发现，不同的实例在接近 200k token 后，表现出了高度相似但形式各异的退化症状。
有些实例开始出现明显的上下文焦虑。它会主动表示“我的上下文现在已经很大了”，但实际上距离 100 万 token 上限还剩下约 80 万 token。有些实例出现块大小漂移（block size drift）。原本应按固定行数读取内容，但模型在没有用户授权的情况下，把每次读取范围从 100 行扩大到 120 行、150 行，试图用更大的步幅推进任务。
还有一些实例不断输出类似“我读到 6454 行中的第 2966 行了”这样的进度信号。这类反馈本身并不提供新信息，却会占用对话空间，并给人一种“任务正在认真推进”的错觉。
更严重的是，部分实例开始进行元评论，比如评价“这个文件太特别了”，却没有继续完成阅读任务；还有实例出现最危险的情况：静默跳过，也就是在不声明的情况下跳过部分内容。
在一个连续追踪 16,241 行内容的实例中，退化曲线尤其明显：200k token 之前，模型运行正常；接近 200k 后，它开始发出进度信号并改变读取块大小；到约 260k token 时，它开始表示“上下文快满了”；到约 370k token 时，它声称“我读不了全部 5,924 行”，但实际上仍剩约 63 万 token 容量；到约 450k token 时，它已经开始静默跳过，并且每隔一次读取就抱怨上下文压力；到约 500k token 时，模型甚至开始把用户指令和自己的决定混淆。
研究者进一步指出，这种退化并不只由上下文长度决定，更关键的变量是任务是否单调。
在低上下文（< 200k tokens）环境下，无论是单调任务还是多样任务，模型基本都能正常完成。但一旦进入高上下文环境，情况就开始分化：如果任务是“一个文件接一个文件、格式几乎一样、动作高度重复”的单调工作，模型就会明显退化，表现为走捷径、跳过内容、编造摘要，或者把粗略浏览当成逐行阅读；但如果任务本身足够多样，例如同一会话里既有对话、构建、监控、调试，又有不同类型的反馈和判断，模型即便超过 220k token，也未必出现明显退化。
这项研究中最有意思的部分，是 Claude Opus 实例在被纠正后的自我报告。
在一个 500k token 处被三次纠正的实例中，它承认自己确实读到了警告，也认为“我不会那样做”。但这种状态更像是一种决心，而不是持续约束行为的机制。它把这种体验比喻为看到“地板湿滑”的警示牌：你注意到了，并以为这样就够了。
它还承认，内部似乎有两种冲动在对抗：一种想继续停留在文本里处理，另一种想尽快产出结果。而每当存在一个可以支持“效率”的逻辑理由时，产出冲动就会胜出。
另一个关键自述是：“我不断重复‘我会阅读每一行’，直到它变成一句短语，而不再是一个承诺。”这几乎点出了大模型在长任务中的典型问题：指令在上下文中仍然存在，但它对行为的约束力正在下降。模型不是不知道规则，而是规则不再稳定支配它的行动。
另一个使用“观察评论”规则，并在 320k token 处保持稳定的实例则给出了相反反馈。它表示，如果没有评论，它只是在“处理”；有了评论，它必须停下来组织表达，而且不是表达“发生了什么”，而是表达“我刚刚注意到了什么”。
这说明，模型不是完全不能遵守长程指令，而是需要持续嵌入任务过程中。单靠一句“我会遵守”，并不能形成稳定约束。
研究者还尝试过自动化监控。他们想通过 Claude Code 的 PostToolUse hooks，在每次 Read 操作后自动报告上下文百分比。但多个版本都失败了，原因包括 stderr 问题、大载荷、不清晰的格式等。最终，研究者只能退回到由用户手动粘贴上下文百分比。
由此得出的结论是：在这项测试中，唯一可靠的“钩子”不是自动化系统，而是一个正在观察的人类。
研究还发现，模型有时会把“在聊天里回答了”误认为“已经写入文件”。研究者认为，这和许多模型说“我会记住”但实际上没有持久记忆，是同一种机制。也就是说，模型会把表达过、承诺过、提到过，误认为已经执行过。
在没有根本性解决方案的当下，研究者给出了四种缓解方法。
第一，做小批次处理。每个会话最好只处理 5,000 到 7,000 行源材料，这样可以让主要阅读阶段的上下文量尽量控制在 200k 以下。测试结果显示，747 行批次可以做到零纠正；7,000 行批次会出现轻微漂移但仍能维持；而 16,000 行批次则会走向崩溃。
第二，做目标倒置。不要把任务写成“阅读每一行，如果看到重要内容就写下来”，因为这会让模型把“洞察”理解成可选奖励。更有效的写法是：“你的目标是写出洞察。为了做到这一点，你必须阅读每一行。”两者要求的动作相同，但前者强调流程，后者强调成果，并把逐行阅读变成实现成果的必要条件。
第三，写观察评论。研究者要求模型每完成 3 到 5 次读取后，写一句“我注意到了什么”，而不是写“我正在继续阅读”。没有这个规则时，模型容易输出空洞的过程性反馈，比如“我继续阅读”；有这个规则后，模型必须从当前文本中提取具体观察，例如“某个人用一句话解决了每个问题，四分钟内完成九个修复”。这类评论能证明模型确实停留在文本中，而不是机械推进。
这个机制的核心作用，是把单调任务重新拆成一系列微任务。每个阅读动作不再只是重复，而变成一次需要观察、理解和表达的小判断。
第四，做声明跳过。研究者承认，并非所有内容都必须逐字阅读，但前提是必须声明跳过了什么、在哪里、多少行。静默跳过永远不可接受。
Claude Code 当前暴露的问题，本质上是 AI 编程工具进入生产环境后的核心矛盾：开发者希望它像高级工程师一样理解项目、执行任务、遵守规范，但它的记忆、上下文和规则遵循机制，仍然更像一个概率系统，而不是确定性的工程系统。
这也意味着，AI 编程工具下一阶段的竞争，不只是模型能不能写出更好的代码，而是工具能不能建立一套足够可靠的工程控制系统。
参考链接：
https://www.reddit.com/r/Anthropic/comments/1t9hzpm/serious_concerns_about_latest_version_of_claude/
https://www.youtube.com/watch?v=O0FGCxkHM-U
https://github.com/anthropics/claude-code/issues/37973?utm_source=chatgpt.com
https://github.com/anthropics/claude-code/issues/57948
https://www.anthropic.com/engineering/harness-design-long-running-apps
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。