最大化 Claude Code 会话的价值

原文 ↗ Hacker News 讨论 ↗

Anthropic 关于如何“最大化” Claude Code 会话价值的建议，引发了开发者的复杂反应；他们试图控制 token 使用、缓存行为和成本，而这是一款不透明且变化很快的工具。许多人欢迎关于提示缓存、上下文管理和子代理的具体技巧，但也有人认为这些优化应由产品自动处理，而不该转嫁给现在需要按任务直接付费的用户。这场讨论凸显了人们对厂商激励、托管 AI 服务频繁行为变化，以及与更便宜的竞争对手和更透明的自托管方案之间比较的普遍不安。

Claude Code 中感知到的低效与 Bug

  • 一些用户反馈，Claude Code 比替代方案（例如 Codex/Copilot）更慢、目标性更差，会过度读取文件和目录，而不是专注于给定文件。
  • 意外的提示缓存重写和很高的缓存写入次数，导致一些人的账单非常高，即使他们认为自己遵循了最佳实践也是如此。
  • 文中提到了多个 GitHub issue（缓存 bug、/clear 影响到下一次会话、新会话没有命中完整缓存），这些都引发了挫败感以及对该工具的不信任。
  • 桌面应用中的 @ 文件搜索被认为有 bug，或者不如 CLI。

Token 成本、缓存行为与激励机制

  • 许多评论都聚焦于提示缓存：TTL 差异（5 分钟 vs 1 小时）、模型/effort 变更导致的缓存失效、使用 /compact，以及对缓存何时重置的困惑。
  • 有人认为 Anthropic 与用户的利益是一致的，希望使用更少的 token（计算成本很高；订阅制限制使用量）；也有人反驳说，企业按 token 计费会激励更多 token 使用。
  • 对“cache-busting”行为以及优化到底是偏向用户节省还是提供方利润，存在怀疑。

产品设计 vs. “你用错了”

  • 很多人强烈认为，这篇博文把复杂性（上下文管理、压缩、缓存 TTL、effort 级别）推给了用户，而不是构建更智能的默认设置。
  • 不少人把这份指南看作 AI 版的“你用错了”：如果误用很常见，他们认为这是产品设计失败。
  • 也有人为这篇文章辩护，认为它只是“如何高效使用强大工具”的正常指南，类似于 AWS 或数据库的成本优化指南。

与其他 LLM 和本地 Harness 的比较

  • 有些人表示，使用其他 LLM（OpenAI、DeepSeek、Kimi、Qwen）或自定义 harness，并配合版本锁定配置以及本地/云托管模型，成本/性能更好。
  • 使用限制，以及对 Claude Code 更高成本/更高延迟的感受，是许多人倾向于竞争对手的重要原因。

工作流、命令与技能

  • 用户分享了高级实践：短会话、频繁使用 /clear 或 /compact、将任务 /handoff 到新会话或其他模型、“docset-driven” 开发，以及外部规划文档。
  • 对于用 @ 引用大型文件到底是好是坏存在争论（可缓存、始终可用 vs. 强制完整读取）。
  • 还有人困惑并不满于更改“effort level”会导致缓存失效；有人推测这可能是通过隐藏的系统提示实现的。

对不透明、不断变化工具的更广泛担忧

  • 一些人希望工具可检查、稳定，并对托管 AI 服务中快速且不透明的变化感到不满。
  • 也有人接受这种频繁变化是快速演进的 agentic 工具的必然结果，认为在当前阶段期待稳定并不现实。