Claude Code 把「读文件、跑命令、改代码」塞进同一条对话里——窗口越满，越容易忘指令。文档的底线就一句话：让模型能自证（测试、截图、期望输出），别让你当唯一反馈环。Plan Mode、短 CLAUDE.md、Hooks/Skills 分工，都是在这条主线上的减负手段；细节以文档为准。[1]
原文：Best Practices for Claude Code（Claude Code 文档）。[1]
先扫一眼
- 主线：窗口约束 → 自证 → 工作流 → 配置与沟通 意味着什么。
- 深度：文内
### 深度解析与 继承关系与未公开细节；文末 结论与讨论 与 延伸阅读。
一、底层约束：上下文窗口
Claude Code 是 agentic 编程环境：读文件、跑命令、改代码、多轮推进。对话里累积每条消息、每次读文件、每条命令输出——单轮调试就可能数万 token；窗口越满，越容易忘指令、犯错。[1]
建议：持续盯用量（如文档中的 status line），并配合 Reduce token usage 等策略。[1]
二、最高杠杆：让 Claude 能「自证」
文档强调：测试、截图、期望输出——没有明确成功标准时，你只能当唯一反馈环。[1]
| 方向 | 要点 |
|---|---|
| 验收标准 | 从「实现校验邮箱」升级到「给出用例 + 跑测」 |
| UI | 贴设计图，要求截图对比差异并迭代（可配合 Claude in Chrome） |
| 根因 | 贴报错，要求修到 build 通过且不治标 |
验证也可以是 lint、单条脚本——把「可验证」做成习惯。[1]
深度解析：可验证闭环与「验收权」在谁手里
事实：文档强调测试、截图、期望输出。[1]
原文观点：避免你当唯一反馈环。[1]
本文解读：若团队把「合并」权只放在人手里而测试未进 CI，模型仍会 对着绿字撒谎——要把 最小自动化验收 写进分支策略。
深度解析：Plan Mode 与「做错题」的元问题
事实：文档推荐 Explore→Plan→Implement。[1]
原文观点：分离调研与实现。[1]
本文解读：若 Plan 基于 过时文件树（未 pull）或 错误根因，后续只是在加速错误——Plan 前应固定 可重复复现步骤。
三、先探索 → 再计划 → 再写码 → 再提交
用 Plan Mode 把调研/规划与写代码分离，避免做错题。推荐四步：Explore → Plan（可 Ctrl+G 编辑计划）→ Implement（对照计划 + 自测）→ Commit/PR。[1]
小改（拼写、单行日志）可直接做；不确定架构、多文件、陌生模块再计划。[1]
四、提示要具体
限定文件/场景/测试偏好；指向 git 历史或现有模式文件；写清症状、位置、什么叫修好。[1]
富内容：@ 引用文件、贴图、给文档 URL（/permissions 配域名）、cat log | claude 管道输入，或让 Claude 自己 bash/MCP 拉上下文。[1]
五、环境配置（压缩清单）
CLAUDE.md：/init生成草稿； 短、可执行（命令、风格、测试约定、仓库习惯）；不要塞满可读代码即知的废话；可@import其他文件；位置含~/.claude/、项目根、子目录等。[1]- 权限：
/permissions白名单；/sandbox系统级隔离；--dangerously-skip-permissions仅在可信沙箱且断网等场景（文档有 Warning）。[1] - CLI：优先
gh、aws等——比裸 API 更省上下文、少踩限流。[1] - MCP：
claude mcp add接 Notion/Figma/DB 等。[1] - Hooks：必须每次执行、零例外时用 hooks（与 CLAUDE.md「建议」相对）。[1]
- Skills：
.claude/skills/.../SKILL.md按需加载领域知识。[1] - Subagents：
.claude/agents/独立上下文、可限工具。[1] - Plugins：
/plugin市场一键装能力包。[1]
六、沟通与会话
- 像问资深工程师一样问代码库问题。
- 大功能先 Interview（AskUserQuestion） 再写 SPEC.md，再新开会话执行，避免实现与调研抢上下文。[1]
- 早纠偏：
Esc停、/rewind、口头 undo、同问题纠两次以上则/clear重开 并带更具体 prompt。[1] - 主动管上下文：
/clear、自动 compact、/compact指令、/btw侧栏不污染历史；大调研用 subagent 省主会话。[1] - Checkpoint：双 Esc；非 git 替代；外部进程变更不纳入 checkpoint 叙事。[1]
- 续聊：
claude --continue/--resume，/rename会话名。[1]
七、自动化与扩展
- 非交互：
claude -p "..."，--output-format json/json-stream接 CI。[1] - 并行：桌面多会话、Web、Agent teams；Writer/Reviewer 分会话做 review。[1]
- Fan-out：循环
claude -p+--allowedTools做批量迁移（先小样本再放大）。[1]
八、常见失败模式（文档列的）
「一锅炖会话」、反复纠正不 clear、CLAUDE.md 过长被忽略、无验证就上线、无边界探索读爆上下文——对策对应 /clear / 精简 / 验证 / subagent 或收窄范围。[1]
继承关系与未公开细节：官方文档 vs 你的版本钉选
事实：文档随 Claude Code 版本迭代。[1]
原文观点：最佳实践清单。[1]
本文解读（推断） ：--dangerously-skip-permissions 等开关的 语义与默认值 可能变更——团队应把 「允许的 CLI 标志」 写入内部 runbook，而非只收藏一篇导读。
结论与讨论
技术坐标
Claude Code 最佳实践把 「对话式编程」 约束为 可验证、可分段、可清理上下文 的工程习惯——与 Effective context engineering、沙箱、长程 harness 同一价值观：状态要么可证，要么外化。
批判性问题
- 团队是否把 截图/测试 写进 Definition of Done？
- Hooks vs CLAUDE.md 的边界是否吵清楚？
- CI 里
claude -p的 非交互 任务是否与交互会话 共享 同一套权限？
独立判断（事实 / 原文观点 / 本文解读）
| 类型 | 内容 |
|---|---|
| 事实 | 文档 URL；功能名以 code.claude.com 为准。[1] |
| 原文观点 | 上下文第一资源；自证；Plan Mode；权限与沙箱。[1] |
| 本文解读 | 最大杠杆仍是 把验收标准写进任务，而不是更长对话。 |
参考文献与延伸阅读
- [1] Best Practices for Claude Code — 原文档
- Claude Code sandboxing（工程博文）
- 若第一次用 Claude Code：先通读文档 Reduce token usage 与 失败模式 两节，再长聊。
扫描二维码，关注公众号IchbinDerek
