Anthropic的Harness工程白做了？Claude Code被曝晒不CLAUDE.md，开发者烧光积分怒喊退钱

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 分开