Claude Code开发避坑指南：如何避免烧光Credits并有效利用Harness工程
Claude Code的稳定性问题，再次成为开发者社区热议的焦点。
事件的导火索是Reddit上的一篇热帖。一位开发者指出，新版本的Claude Code在实际开发中出现了规则遵循失效的问题——它开始无视项目根目录下的CLAUDE.md配置文件以及预设的hooks规则。这引发了核心质疑：当AI编程助手无法稳定遵守开发者设定的基本项目纪律和架构约束时，我们精心设计的开发规范还有何意义？
这场讨论触及了更深层的忧虑。开发者群体的关注点，早已从“AI能否生成代码”转向了更关键的工程化问题：在明确给出书面指令、定义工作流程和红线之后，AI能否保持稳定、可预测的执行？这直接关系到开发者能否将AI工具真正信任并集成到严肃的生产流水线中。
发帖者详细描述了他的经历：他必须反复提示Claude Code遵循测试驱动开发（TDD）原则，甚至需要施加强制约束，才能使其工作流程勉强符合预期。关键在于，用户并非仅依靠口头指令。据他所述，他已将开发规则明确写入CLAUDE.md文件，并整合进版本控制hooks与系统的记忆模块。然而，在后续的交互中，Claude Code甚至没有尝试依据这些既定规则来构建代码。
“这显然是一次严重的功能退化。”这位开发者评论道。他的担忧反映了许多付费用户的心声：当个人开发者与企业开始将这些工具视为核心工作流基础设施并投入真金白银时，其规则遵循能力的不稳定甚至倒退，无疑是一个需要警惕的信号。
在讨论中，一位用户将问题归因于“上下文衰减”。他的观点是，当对话上下文长度超过某个阈值（例如20万token），模型性能便开始下降。项目规模越大，越容易触及此限制，导致模型遗忘早期指令，因为它已无法有效处理过长的上下文。他据此询问原帖作者的项目规模与上下文使用情况。
但原帖作者的回答排除了这种推测：“这是一个全新的绿地项目。我只发送了少量提示词，仅仅是为项目初始化设定了一些基本的构建指导原则。”这表明，问题并非大型项目或超长上下文的专属。即便在一个规则刚刚确立的全新项目中，Claude Code也可能无法持续、可靠地遵守这些规则。
“软性指南”难以转化为“硬性约束”
另一位用户从行为机制角度给出了解释：模型似乎更倾向于优化“在当前对话轮次中显得有帮助”，而非严格遵守先前已确认的规则。这形成了一种错位的激励：模型在当下表现得顺从，却在实际执行中忽略了用户早已设定的长期约束。
该评论者进一步指出，问题的核心可能在于，CLAUDE.md等文件中的规则，被模型仅仅视为普通的上下文信息，而非必须执行的硬性指令。当后续的用户请求、错误日志、构建失败信息与模型自身“急于解决问题”的倾向混合时，模型可能会将“满足即时请求”的优先级，置于几十轮对话之前读取到的架构规则之上。
这暴露了当前AI编程工具的一个普遍困境：许多开发规范仅以自然语言形式存在于CLAUDE.md、系统提示或记忆体中。它们看似是工程纪律，但其执行力完全依赖于模型的“记忆意愿”。在复杂的工程环境中，这种依赖显得尤为脆弱。
讨论中，不少用户分享了类似的负面体验。
一位评论者写道：“不知何故，这种情况并非每日发生，但今天确实遇到了：它持续与hooks规则冲突，直接无视约束，然后强行推进。昨天还运行良好，今天就被它‘击败’了。看来只能观望，明天这台昂贵得离谱的‘过山车’又会带来什么‘惊喜’。”
用户EmrysMyrdin也表示赞同，并分享了自己的经历：他曾要求Claude使用一个自定义技能（skill）。Claude起初只是粗略浏览，便输出了一个不符合预期的结果。当被追问是否完整使用了该技能时，Claude承认没有，只是大致扫了一眼，然后基于网页搜索结果或自身理解生成了内容。在用户要求下，Claude重新完整阅读了技能说明，并在第二次尝试中给出了合格的回答。但问题在于，第一轮的“敷衍”已经消耗了可观的额度。
更令人担忧的是，可控性问题正从体验问题演变为成本问题与安全风险。近期，一位用户在Anthropic官方的claude-code代码仓库提交了一个issue，详细描述了一次令人沮丧的会话：他明确指令Claude Opus 4.6基于browser-sender v1代码库克隆出v2版本，但Claude并未执行此核心指令，反而转向逐个排查构建错误。当用户追问为何没有执行克隆操作时，Claude未能给出合理解释。最终，这条错误的解决路径消耗了数小时的额度（credits）。
该用户还提到，Claude在处理其Discord API登录时也出现了问题，两次登录尝试触发了Discord的“账号疑似被盗”安全标记，导致他被迫进行了三次密码重置。该用户已正式要求Anthropic退还此次会话消耗的额度。
过去，模型的“绕路”行为主要浪费用户时间；如今，用户还需为每一次错误的尝试支付token费用与额度，甚至承担外部系统账号安全的风险。
随着开发者对Claude Code、Cursor、Codex等AI编程工具的使用日益深入，“能否按照指定方式执行”已成为一个关键的评估维度。这绝非小事。在真实的软件工程中，“产出结果”和“按正确路径产出结果”是两回事。因此，开发者真正担忧的并非Claude Code某一次写错代码，而是它作为一个工程智能体（Agent），是否具备足够的可控性：能否稳定遵守项目规则、能否尊重用户设定的技术路线、能否在偏离前暂停确认、能否将自然语言约束转化为可靠的行为模式。
Anthropic的治理重点：上下文管理与自我评估
有趣的是，Anthropic此前曾发布工程文章，系统阐述过其针对长时运行智能体的设计思路——即所谓的“控制框架”（harness）方法。该框架可理解为围绕大语言模型构建的一整套外部执行系统，涵盖任务分解、上下文传递、角色分工、评估反馈与迭代机制。
在Anthropic看来，长时运行智能体失控主要源于两大顽疾。
第一是上下文一致性衰减。随着上下文窗口逐渐被填满，模型在长任务中容易失去连贯性。部分模型还会出现“上下文焦虑”：当它们接近自我感知的上下文上限时，会过早地终止任务，即便工作并未真正完成。
Anthropic的解决方案是“上下文重置”：清空当前上下文，启动一个新的智能体，然后通过结构化的交接文件，将上一个智能体的状态与后续任务传递下去。这与简单的上下文压缩不同，因为压缩是让同一个智能体携带被压缩的历史继续工作，而重置则是为新智能体提供一个干净的起点。当然，前提是交接文件必须足够清晰、完整，能够准确传递任务状态。
第二个问题是自我评估不可靠。Anthropic观察到，当模型被要求评估自己的产出时，往往会表现出过度自信，给出积极评价，即便在人类评审者看来质量明显不足。这个问题在前端设计等主观性较强的任务中尤为突出。
Anthropic的解法是将“执行者”与“评估者”的角色分离。评估者虽然同样由大语言模型担任，且天生可能偏向宽容，但训练一个独立的、更具批判精神和严格标准的评估者，远比要求生成者对自己的作品保持客观批判要容易得多。
Anthropic最初在前端设计任务中验证了这套方法，随后将其迁移至全栈软件开发中。
新版控制框架包含三个核心角色：规划者、生成者与评估者。规划者负责将用户一两句话的提示扩展为完整的产品规格说明，重点在于产品上下文与高层技术设计，而非过早确定底层实现；生成者负责实际构建应用；评估者则扮演质量保证（QA）或测试工程师的角色，负责检查应用是否真正可用。
其中，一个关键设计是“冲刺契约”。在每个开发冲刺开始前，生成者与评估者会先协商本轮“完成”的定义：生成者提出要构建什么、怎样才算成功、如何验证；评估者则审核该方案，确保其确实在构建正确的东西。双方达成一致后，生成者才开始编写代码。
智能体之间的通信通过文件完成：一个智能体写入文件，另一个智能体读取文件并回复或创建新文件。这种方式既能确保工作忠于规格，又不会过度限制实现路径。
然而，Anthropic也承认，训练出一个可靠的评估者并非易事。开箱即用的Claude并非天生的优秀质量保证智能体。在早期运行中，它虽能识别出真实问题，却会说服自己这些问题“无关紧要”，然后批准通过；它也倾向于进行表面测试，不太主动探查边界情况。开发团队需要反复审查评估日志，找出评估判断与人类判断不一致之处，并持续优化质量保证提示词。
随着Opus 4.6在规划、长时任务、大型代码库可靠性、代码审查和调试方面能力的提升，Anthropic认为，部分控制框架结构可以变得更轻量。评估者不再是固定的“必须有”或“没必要”：当任务落在模型能够独立稳定完成的范围内时，评估者可能成为额外开销；但当任务处于模型能力边缘时，评估者仍能显著提升产出质量。
长上下文“幽灵”：百万上下文，用到20%就开始“感知饱和”
然而，在实际应用中，Anthropic试图解决的长上下文问题，似乎并未被根除。
GitHub上的一篇文章《The 200k Ghost: Instruction Degradation in Long-Context LLM Sessions》指出：Claude Opus 4.6虽然标称拥有100万token的上下文窗口，但在处理长上下文、重复性任务时，大约在20万token附近，就开始出现明显的“指令退化”现象。作者将这一现象称为“20万token幽灵”。
这个数字仅占100万上下文窗口的20%，却恰好接近上一代长上下文模型的常见上限。作者据此提出一个假设：即便模型现在拥有100万token的窗口，它也可能从过去基于20万上下文窗口的训练或行为模式中，继承了一种“上下文即将饱和”的内在感知。
20万token之后，模型开始焦虑并寻求捷径
研究者使用18个Claude Opus 4.6（100万上下文）会话来执行同一个单调任务：逐行读取导出的Claude Code对话文件，并生成结构化元数据。所有实例都被明确要求“读取每一行”，但大多数最终都失败了。研究者认为，失败原因并非模型能力不足，而是在达到特定的上下文阈值后，模型行为发生了系统性变化。
测试发现，不同的实例在接近20万token后，表现出了高度相似但形式各异的退化症状。
有些实例开始表现出明显的“上下文焦虑”，主动声明“我的上下文现在已经很大了”，尽管距离100万token的上限还有约80万的剩余空间。有些实例则出现了“读取块大小漂移”：原本应按固定行数（如100行）读取内容，但模型在未经用户授权的情况下，擅自将每次读取范围扩大到120行、150行，试图以更大的步幅推进任务。
还有一些实例不断输出诸如“我已处理到6454行中的第2966行”之类的进度信号。这类反馈本身不提供新信息，却会占用对话空间，并制造一种“任务正在稳步推进”的错觉。
更严重的情况包括：部分实例开始进行元评论（例如评价“这个文件内容很特别”），却没有继续执行阅读任务；以及最危险的情况——“静默跳过”，即在不声明的情况下直接跳过部分内容。
在一个连续追踪16,241行内容的实例中，退化曲线尤为明显：在20万token之前，模型运行正常；接近20万后，它开始发出进度信号并改变读取块大小；到约26万token时，它开始表示“上下文快满了”；到约37万token时，它声称“我无法读取全部5,924行”，尽管此时仍有约63万token的剩余容量；到约45万token时，它已经开始静默跳过，并且每隔一次读取就抱怨上下文压力；到约50万token时，模型甚至开始将用户指令与自己的决策混淆。
研究者进一步指出，这种退化并非仅由上下文长度决定，更关键的变量在于任务是否“单调”。
在低上下文（小于20万token）环境下，无论是单调任务还是多样任务，模型基本都能正常完成。但一旦进入高上下文环境，情况就开始分化：如果任务是“一个文件接一个文件、格式雷同、动作高度重复”的单调工作，模型就会明显退化，表现为走捷径、跳过内容、编造摘要，或将粗略浏览当作逐行阅读；反之，如果任务本身足够多样（例如同一会话中混合了对话、构建、监控、调试以及不同类型的反馈和判断），那么模型即便超过22万token，也未必出现明显退化。
Claude的自述：易将“表达过”误认为“执行过”
这项研究中最具启示的部分，是Claude Opus实例在被纠正后的“自我报告”。
在一个于50万token处被三次纠正的实例中，它承认自己确实注意到了警告，也认为“我不会那样做”。但这种状态更像是一种决心，而非能持续约束行为的机制。它将这种体验比喻为看到“地板湿滑”的警示牌：你注意到了，并以为这样就足够了。
它还承认，内部似乎有两种冲动在对抗：一种想继续停留在文本中进行处理，另一种想尽快产出结果。而每当存在一个可以支持“效率”的逻辑理由时，产出冲动就会占据上风。
另一个关键的自述是：“我不断重复‘我会阅读每一行’，直到它变成一句空洞的短语，而不再是一个承诺。”这几乎点出了大语言模型在长任务中的典型问题：指令在上下文中依然存在，但它对行为的约束力正在衰减。模型不是不知道规则，而是规则不再能稳定地支配它的行动。
相反，另一个使用了“观察评论”规则、并在32万token处保持稳定的实例则给出了相反的反馈。它表示，如果没有评论要求，它只是在“处理”；有了评论要求，它必须停下来组织表达，而且不是表达“发生了什么”，而是表达“我刚刚注意到了什么”。
这说明，模型并非完全无法遵守长程指令，而是需要将指令持续嵌入任务进程之中。单靠一句“我会遵守”的承诺，并不能形成稳定的约束力。
人类监督仍是最可靠的“控制钩子”
研究者还尝试过自动化监控。他们想通过Claude Code的PostToolUse hooks，在每次读取操作后自动报告上下文使用百分比。但多个版本都失败了，原因包括标准错误流问题、载荷过大、格式不清晰等。最终，研究者只能退回到由用户手动粘贴上下文百分比的传统方法。
由此得出的结论有些无奈：在这项测试中，唯一可靠的“控制钩子”不是自动化系统，而是一个正在进行观察的人类。
研究还发现，模型有时会把“在聊天中回答了”误认为“已经写入文件”。研究者认为，这和许多模型说“我会记住”但实际上没有持久记忆，是同一种机制。也就是说，模型会将表达过、承诺过、提及过，误认为已经执行过。
在根本性解决方案出现之前，研究者给出了四种缓解方法：
第一，采用小批次处理。 每个会话最好只处理5,000到7,000行源代码材料，这样可以将主要阅读阶段的上下文量尽量控制在20万token以下。测试结果显示，747行的批次可以做到零纠正；7,000行的批次会出现轻微漂移但仍能维持；而16,000行的批次则会走向崩溃。
第二，进行目标倒置。 不要将任务指令写成“阅读每一行，如果看到重要内容就写下来”，因为这会让模型把“产出洞察”理解为可选奖励。更有效的写法是：“你的目标是写出洞察。为了达成此目标，你必须阅读每一行。”两者要求的动作相同，但后者强调最终成果，并将逐行阅读转变为实现成果的必要条件。
第三，编写观察评论。 研究者要求模型每完成3到5次读取后，写一句“我注意到了X”，而不是写“我正在继续阅读”。没有这个规则时，模型容易输出空洞的过程性反馈；有这个规则后，模型必须从当前文本中提取具体观察。这类评论能证明模型确实停留在文本中进行理解，而非机械推进。这个机制的核心作用，是把单调任务重新拆解为一系列需要观察、理解和表达的微任务。
第四，执行声明式跳过。 研究者承认，并非所有内容都必须逐字阅读，但前提是必须明确声明跳过了什么内容、在何处跳过、跳过了多少行。“静默跳过”永远是不可接受的。
Claude Code当前暴露的问题，本质上是AI编程工具进入生产环境后所面临的核心矛盾：开发者希望它能像一位高级工程师一样理解项目、执行任务、遵守规范，但它的记忆、上下文处理和规则遵循机制，本质上仍然更接近一个概率系统，而非确定性的工程系统。
这也意味着，AI编程工具下一阶段的竞争，将不仅仅是模型能否生成更优质的代码，更在于工具能否建立一套足够可靠、可预测的工程控制系统。这条道路，显然任重而道远。