先思考，后编码

这条看起来是废话，但确实是拉开差距最大的地方。连按两次 Shift + Tab 可以进入计划模式（Plan Mode），花 5 分钟把架构理清楚，能省掉后面几个小时的调试。

关键在于输入的精确度。如果你只说"建一个认证系统"，输出质量大概率不会好；但如果你能指定数据模型、存储方式、中间件选型，结果会完全不同。说白了，拿到烂代码，先反思自己的提示词和规划够不够具体。

把 CLAUDE.md 当成项目指南来维护

CLAUDE.md 是 Claude 每次会话开始前都会读的文件，相当于给它的"入职材料"。这个文件写得好不好，直接影响项目质量。

几个实操要点：

  • 控制篇幅：Claude 每次只能可靠遵循大约 150-200 条指令，写太长它会随机忽略一部分
  • 解释原因：不要只写"使用 TypeScript 严格模式"，加上为什么——比如"因为我们曾因隐式类型出过线上事故"。有了上下文，Claude 的判断力会更好
  • 持续迭代：这是一个活文档。每当你需要纠正 Claude 两次以上的同一个问题，就按 # 键把指令加进去

上下文窗口没你想的那么大

虽然模型标称支持 200k token 的上下文窗口，但实际上远没到上限，输出质量就开始下降了。根据 Eyad 的经验，大约在 20-40% 的上下文使用率时，退化就已经开始。

应对方法其实不复杂：

  • 限定范围：每个对话只做一件事，一个功能或一个任务
  • 外部记忆：用 SCRATCHPAD.md 或 plan.md 之类的文件记录进度，跨会话时可以快速恢复上下文
  • 主动重置：当上下文变臃肿时，复制关键信息，执行 /compact 压缩，再 /clear 清除，然后把关键信息粘贴回来。这比在退化的上下文里硬撑有效得多

一旦发现对话开始跑偏，果断清除重来，不要犹豫。

提示词工程和模型分工

写提示词时一个容易忽略的技巧是：不光要说清楚你要什么，还要明确告诉它不要做什么。比如"不要过度设计"、"不要增加不必要的抽象层"，这类负向约束往往比正向要求更能避免翻车。

模型选择上也有讲究：

  • Opus：适合复杂推理、架构规划、方案设计
  • Sonnet：更快更便宜，适合架构确定后的具体编码执行

实际工作流是：用 Opus 做规划，按 Shift+Tab 切换到 Sonnet 写代码。这个分工在成本和质量之间找到了不错的平衡。

善用高级功能做自动化

Claude Code 有几个进阶能力值得花时间研究：

  • MCP：连接 GitHub、数据库等外部服务，让 Claude 能直接操作这些资源
  • Hooks：在代码更改前后自动运行 Prettier 格式化或类型检查，省去手动操作
  • 自定义斜杠命令：把常用的提示词模板打包成命令，重复工作一键触发
  • 无头模式：用 -p 标志在非交互模式下运行 Claude，可以集成到自动化脚本中，比如自动 PR 审查、changelog 更新

陷入死循环时怎么办

遇到 Claude 反复出错或兜圈子的情况，最差的做法是继续加指令、施压——这只会让上下文更乱。

正确的做法是换思路：执行 /clear 清除上下文，把任务拆得更小更简单，或者干脆自己写一段最小化的示例代码给它看。Show instead of tell，比长篇大论的描述有效得多。这一步很多人不愿意做，但往往是最快的解法。

对于独立开发者来说，Claude Code 的价值不仅在于写代码，更在于它能接管大量重复性的工程工作。但前提是你得学会"管理"它——像带一个能力很强但需要明确指令的队友。把 CLAUDE.md 维护好、上下文控制住、模型分工用起来，效率提升是实实在在的。