一条核心约束
上下文窗口很快就会满，性能随之下降。
所有最佳实践都围绕这一个约束展开。上下文窗口容纳你的对话、文件内容、命令输出——一次调试会话可能消耗数万 token。当窗口快满时，Claude 可能”忘记”早期指令或犯更多错误。
五条黄金法则
1. 给 Claude 验证手段（最高杠杆）
Claude 能自验证工作时表现显著提升。没有验证标准，它可能产出”看起来对但实际不对”的东西。
| 差的做法 | 好的做法 |
|---|---|
| ”实现邮箱验证函数" | "实现 validateEmail。测试用例：user@example.com → true, invalid → false。实现后跑测试" |
| "让仪表盘更好看" | "[贴截图] 实现这个设计，截图对比原图，列出差异并修复" |
| "构建失败了" | "构建失败，错误信息：[贴错误]。修复并确认构建成功。解决根因，不要压制错误” |
2. 先探索，再计划，再编码
[Plan Mode] 读 src/auth/，理解会话处理
↓
[Plan Mode] 我想加 OAuth，哪些文件要改？创建计划
↓
（Ctrl+G 在编辑器中编辑计划）
↓
[Normal Mode] 按计划实现，写测试，跑测试修复
↓
[Normal Mode] 用描述性消息提交，开 PR什么时候跳过计划：改动明确且小（改个 typo、加行日志、重命名变量）。如果你能一句话描述 diff，就直接做。
3. 给具体上下文
| 策略 | 差 | 好 |
|---|---|---|
| 限定范围 | ”给 foo.py 加测试" | "给 foo.py 写测试，覆盖用户登出的边界情况。不用 mock” |
| 指向来源 | ”ExecutionFactory 的 API 为什么这么奇怪？" | "看 ExecutionFactory 的 git 历史，总结它的 API 是怎么演变的” |
| 参考模式 | ”加个日历组件" | "看首页现有组件的实现模式，HotDogWidget.php 是好例子。按同样模式实现日历组件” |
4. 积极管理上下文
/clear：无关任务之间清理上下文/compact <focus>：手动压缩，指定保留焦点- SubAgent：用于大量文件读取的调查任务
/btw：快速小问题，不进入历史
何时 /clear：
- 任务之间切换时
- 纠正 Claude 超过两次后（上下文被失败尝试污染了）
5. 及早纠正
Esc：停止当前动作，保留上下文Esc+Esc或/rewind：回滚到之前的检查点- “撤销那个”：让 Claude 恢复更改
/clear：彻底重新开始
如果纠正了两次还不对：/clear，用更好的初始 prompt 重新开始。干净的会话 + 好 prompt > 长会话 + 累积的纠正。
五个常见反模式
| 反模式 | 症状 | 解决 |
|---|---|---|
| 厨房水槽会话 | 一个会话里做了三件不相关的事 | /clear 分隔不同任务 |
| 反复纠正 | 修了两次还是错 | /clear + 更好的初始 prompt |
| 过长的 CLAUDE.md | Claude 忽略一些规则 | 精简，重要规则转成 Hook |
| 信任后验证缺口 | 看起来对但边界情况没处理 | 始终提供验证手段 |
| 无限探索 | ”调查一下”没有范围限制 | 限定范围或用 SubAgent |
实用工作流
探索新代码库
"给我这个代码库的概览"
→ "解释主要的架构模式"
→ "认证是怎么处理的？"修 Bug
"npm test 有错误"
→ "建议几种修复 user.ts 里 @ts-ignore 的方法"
→ "用你建议的 null check 更新 user.ts"让 Claude 采访你（大型特性）
"我想做 [简要描述]。用 AskUserQuestion 工具详细采访我。
问技术实现、UI/UX、边界情况、权衡。
不要问显而易见的问题，深入我可能没考虑到的难点。
采访结束后写完整 spec 到 SPEC.md。"然后新建会话执行 spec——新会话有干净的上下文专注实现。
并行会话
- Desktop App：可视化管理多个本地会话
- Web：在 Anthropic 云端运行
- Git Worktree：
claude --worktree feature-auth创建隔离的工作副本
批量操作
for file in $(cat files.txt); do
claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
--allowedTools "Edit,Bash(git commit *)"
done知识检测
概念理解题
-
为什么”给 Claude 验证手段”被称为最高杠杆？没有验证时 Claude 的行为模式是什么？
-
“干净的会话 + 好 prompt > 长会话 + 累积的纠正”——为什么？这和上下文窗口有什么关系？
-
Plan Mode 的核心价值是什么？它和直接让 Claude 编码相比，浪费的是什么、节省的是什么？
应用题
-
你要用 Claude Code 把一个 JavaScript 项目逐步迁移到 TypeScript。设计一个工作流，考虑：如何分批、如何验证、如何管理上下文。
-
你的 CLAUDE.md 里有一条规则”所有 API 响应要包含 requestId 字段”，但 Claude 经常忘记。分析可能的原因，提出三种解决方案。
参见
- 01-AI-Agent-架构原理 — 理解为什么上下文是核心约束
- 02-上下文与记忆系统 — CLAUDE.md 的详细规范
- 03-扩展体系总览 — 何时用 Skill/Hook/SubAgent
参考答案
1. “给 Claude 验证手段”是最高杠杆
没有验证时，Claude 只能靠自己的推理判断结果正确性——而 LLM 的推理是概率性的，“看起来对”不等于”真的对”。有了验证手段（测试套件、lint、截图对比），Claude 可以观察到客观事实然后自我修正。这把 Agent 从”盲飞”变成”有仪表盘的飞行”——从依赖模型判断力变成依赖工具反馈，质量飞跃。
2. 干净会话 > 长会话 + 纠正
长会话积累了大量失败尝试和纠正——这些都是”噪音”，占用上下文空间并干扰模型判断。模型可能在纠正中建立错误的关联（“上次这个方法不行，但这次可能又试了”）。干净的会话没有这些包袱——200 行的 CLAUDE.md + 一个清晰的初始 prompt 比 2000 token 的纠正历史更有效。上下文窗口角度：纠正历史浪费的空间本可以用于实际工作。
3. Plan Mode 的核心价值
Plan Mode 浪费的是”执行速度”——你多花一步来规划而非直接动手。节省的是”返工成本”——一个好的计划避免了多次错误实现和回滚。对于复杂任务（跨多文件重构、架构变更），Plan Mode 的 ROI 极高；对于简单任务（改 typo），跳过计划直接做。Ctrl+G 可以在编辑器中修改计划——这意味着你可以精确控制 Claude 的行动路径。
4. JS→TS 迁移工作流
(1) Plan Mode 做整体评估：哪些文件可以独立迁移、哪些有依赖、tsconfig.json 配置策略 (2) 按依赖图从底层开始（utils → services → routes），每次迁移一个文件——/clear 分隔每个文件的迁移任务（避免上下文膨胀）(3) 每次迁移后跑 tsc --noEmit（验证手段）(4) 用 CLAUDE.md 记录迁移规范（类型定义约定、any 使用策略、已迁移文件列表）(5) 复杂文件用 SubAgent 先分析再迁移。
5. Claude 忽略 API requestId 规则
可能原因：(1) 规则表述太笼统（“所有 API 响应”没有指定具体文件和函数）(2) CLAUDE.md 过长导致遵守率下降 (3) 规则和其他指令冲突。解决：(a) 把规则改得更具体：“在 src/api/handlers/ 下所有 handler 的返回值中必须包含 requestId: crypto.randomUUID()” (b) 迁移到 .claude/rules/api-handlers.md 并设 paths: ["src/api/**/*.ts"]（条件加载减少噪音）(c) 用 PostToolUse Hook 在编辑后自动检查是否包含 requestId（确定性验证）。