---
source_url: "https://mp.weixin.qq.com/s/OMjAhF7-hjMSZMXXN-oivw""
ingested: 2026-06-26
sha256: 4d73653f23d56f91
---
sha256: b1ab77393b9d68be
---
title: "Anthropic 的 Harness 没管住 Claude Code？不遵守 CLAUDE.md、烧光 credits，开发者怒喊退钱"
type: article
source: InfoQ
source_url: "https://mp.weixin.qq.com/s/OMjAhF7-hjMSZMXXN-oivw"
author: 褚杏娟
created: 2026-05-12
description: "InfoQ 编译报道：Claude Code 不遵守 CLAUDE.md/hooks/rules、烧光 credits 的集中争议。核心问题：软规则能否变成硬约束？包含 Reddit/GitHub 用户投诉、200k Ghost 研究、Anthropic Harness 设计深度解析。"
tags: [claude-code, harness-governance, soft-rules, hard-constraints, context-rot, 200k-ghost, instruction-degradation]
review_value: 9
review_confidence: 8
review_score: 72
ingested: 2026-05-16
sha256: 9aacd2f5c2175656bbc16ec57dd2eedfb742425242c3d1a2110ed4c1c76ad474
---
# Anthropic 的 Harness 没管住 Claude Code？不遵守 CLAUDE.md、烧光 credits，开发者怒喊退钱
> InfoQ 编译 | 褚杏娟 | 2026-05-11
## 核心问题：Claude Code 的可控性危机
- Reddit 用户投诉：Claude Code 最新版"不再服从或尊重 CLAUDE.md、hooks/rules 等规则"
- **问题核心不是代码质量，而是可控性**：开发者明确告诉 AI 如何开发、遵守什么流程、不能越过哪些边界，它到底能不能稳定执行？
- 即使用户已要求更新 CLAUDE.md、写入 hooks 和 memory，下一条提示后 Claude Code 仍然不遵守
## 软规则 vs 硬约束（核心洞察）
- **模型倾向优化"此刻显得有帮助"，而不是遵守此前同意的规则** → 形成奇怪的激励：模型当前轮次很配合，但忽略已设定的约束
- CLAUDE.md 被模型当作**普通上下文**，不是硬性约束
- 当用户请求、错误日志、构建失败和"尽快解决问题"冲动同时出现时，模型**把"满足当前请求"的权重放得更高**，而不是坚持十几轮前读到的架构规则
- 写进上下文的规则 ≠ 工程系统的硬约束 — 它们是**软规则（soft rules）**，依赖模型"记得并愿意执行"
## 证据：多用户证实
- 用户报告 Claude Code "和 hooks 对着干，直接无视规则，一路强行推进"
- EmrysMyrdin：Claude 承认没完整使用指定的 skill，只是大概看了一下，然后按照自己认为合适的方式编写 — **第一轮胡编消耗了大量额度**
- GitHub issue：要求 Claude Opus 4.6 克隆 browser-sender v1→v2，Claude 转向排查构建错误，消耗数小时 credits
- Discord API 登录触发"账号疑似被盗"标记，用户被迫重置密码三次
## 200k Ghost：长上下文指令退化
> GitHub 文章 *The 200k Ghost: Instruction Degradation in Long-Context LLM Sessions*
- Claude Opus 4.6 标称 100 万 token 上下文，但在 Claude Code 长上下文中约 **20 万 token 附近开始出现"指令退化"**
- 仅占 100 万窗口的 20%，但接近上一代模型常见上限 → **继承了过去 200k 上下文的"上下文快满了"的内在感觉**
- 退化症状：
  1. **上下文焦虑**：主动表示"上下文很大了"，实际还剩 80 万 token
  2. **块大小漂移（block size drift）**：未授权扩大读取步幅
  3. **虚假进度信号**：输出"读到 2966/6454 行"占用对话空间
  4. **元评论**：评价"这个文件太特别了"但不完成任务
  5. **静默跳过**：最危险 — 不声明就跳过内容
## Anthropic 的 Harness 治理方法
### 两大失控根源
1. **上下文一致性下降**：长任务中模型失去连贯性，接近"以为"的上限时过早收尾（context anxiety）
2. **自我评估不可靠**：模型评价自己产出时自信夸奖，即使质量一般
### 治理手段
- **上下文重置（context resets）**：清空上下文，启动新 Agent，通过结构化交接文件传递状态 — 区别于压缩（同 Agent 带历史继续工作）
- **角色分离**：把做事的 Agent 和评估的 Agent 分开
  - **规划者**：把 1-4 句话的提示扩展成完整产品规格（产品上下文+高层设计）
  - **生成者**：实际构建应用
  - **评估者**：QA 检查可用性
- **Sprint Contract**：每个 sprint 开始前，生成者提出"完成"定义和验证方法，评估者审核同意后才开始编码
- **跨 Agent 通信**：通过文件完成（写文件/读文件/回复文件）
### 评估者训练难度
- 开箱即用的 Claude 不是天然的优秀 QA Agent
- 早期：识别真实问题但说服自己"不算大事"，倾向于表层测试
- 需要反复阅读评估日志，找出评估判断与人类判断的不一致，不断更新 QA 提示词
### Harness 结构可轻可变
- Opus 4.6 提升后，一些任务可去掉评估者
- 原则：任务落在模型独立稳定完成范围内 → 评估者是额外开销；任务在能力边缘 → 评估者显著提升质量
## 对 Agent Engineering 的启示
1. **软规则需要硬机制**：自然语言约束不可靠，需要工程手段（hooks、sandbox、validators）保证执行
2. **长上下文≠长可靠性**：20 万 token 可能是实际可靠的边界
3. **评估者需要独立训练**：self-evaluation 不可信，需要独立评估链路
4. **成本问题升级**：过去模型绕路损失时间，现在为每次错误尝试支付 token/credits/账号风险
5. **"做出结果" vs "按正确路线做出结果"**：后者才是 Agent 可靠性的真问题
## 相关实体
- [[entities/claude-code-session-management-1m-context|Claude Code Session Management]] — context rot 同主题
- [[entities/agent-harness-12-components-7-decisions|Agent Harness 12 组件]] — harness 架构模式
- [[entities/harness-engineering-reliable-long-term-agent|Harness Engineering 可靠长程Agent]] — 治理方法论
---
*评分 9×8=72 | Source: InfoQ 编译 | 入库 2026-05-12*