本文来自微信公众号： AI前线 ，作者：褚杏娟，原文标题：《Anthropic的Harness工程白做了？Claude Code被曝不遵守CLAUDE.md，开发者烧光credits怒喊退钱！》
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的治理重点：
上下文和自我评估
有意思的是，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结构可以变轻。评估者不再是固定的“必须有”或“没必要”：当任务已经落在模型能够独立稳定完成的范围内，评估者可能变成额外开销；但当任务处在模型能力边缘时，评估者仍然能显著提升质量。
长上下文“幽灵”：百万上下文
20%就开始“以为自己快满了”
然而，实际使用中，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上下文的训练或行为模式中，继承了一种“上下文快满了”的内在感觉。
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承认：
会把“说过”当成“做过”
这项研究中最有意思的部分，是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