从上下文管理、可验证目标、项目记忆、Subagents，到 Writer / Reviewer 协作模式。
1. 核心前提：上下文窗口会变满
Claude Code 的上下文窗口会很快被填满。
上下文里不只有你发的消息，还包括 Claude 读过的文件、命令输出、报错日志、测试结果、历史修改，以及你们讨论过的失败方案。上下文越满，Claude 越容易忘记早期要求，或者沿着错误方向继续改。
2. 给 Claude 可验证的目标
不要只告诉 Claude “做什么”，还要告诉它“怎么判断做对了”。
| 模糊说法 | 更好的说法 |
|---|
| 修复登录问题 | 用户 session 过期后登录失败。请检查 src/auth/，先写复现测试，再修复，并运行测试确认通过。 |
| 优化页面 | 按这张截图调整 UI。完成后截图对比，列出差异并继续修。 |
| 解决构建失败 | 这是构建错误日志。请找根因，不要跳过错误。修复后运行 build 确认成功。 |
一个好任务通常包含四件事：
| 目标我要实现什么 | 范围看哪些文件 / 不碰哪些文件 |
|---|
| 标准怎样算完成 | 验证跑什么测试 / 命令 / 截图 / lint |
2.1 示例
| 任务 | 请修复用户退出登录后仍能访问 dashboard 的问题。 |
|---|
| 范围 | 重点检查 src/auth/ 和 src/routes/dashboard.tsx。不要重构整个权限系统。 |
| 完成标准 | 未登录用户访问 dashboard 会跳转 login。已登录用户不受影响。 |
| 验证方式 | 先写一个失败测试复现问题。修复后运行相关测试。 |
3. 配置项目记忆：CLAUDE.md
CLAUDE.md 是 Claude Code 每次进入项目时都会读取的项目说明书。它告诉 Claude：这个项目怎么跑、怎么测、有哪些约定、哪些坑不要踩。
3.1 先用 /init 生成初稿
| 操作 | 在项目根目录输入 /init。 |
|---|
| 然后 | 删掉废话，补上真正会影响 Claude 行为的规则。 |
3.2 CLAUDE.md 可以这样写
| Commands | 安装依赖：pnpm install；类型检查：pnpm typecheck；运行测试：pnpm test。 |
|---|
| Code Style | 使用 TypeScript。使用 ES modules，不使用 CommonJS。创建新抽象前，先遵循现有模式。 |
| Workflow | 改文件前先阅读相关代码。优先做小而聚焦的修改。改完后运行 typecheck 或最近相关测试。 |
| Gotchas | Auth 状态在 src/auth/session.ts。API 错误应该使用共享的 AppError 类。 |
3.3 写什么，不写什么
| 应该写 | 不该写 |
|---|
| 项目命令 | Claude 能从代码里看出来的东西 |
| 测试方式 | 大段 API 文档 |
| 特殊代码风格 | 通用编程常识 |
| 常见坑 | 频繁变化的信息 |
| 团队约定 | “写高质量代码”这种空话 |
| 如果删掉这一行，Claude 不会因此更容易犯错，那就删掉。 |
|---|
4. 配置好工作环境
Claude Code 会读项目、跑命令、改文件。环境越清楚，它越稳定。
4.1 准备常用 CLI
| 工具 | 适合做什么 |
|---|
gh | 查看 GitHub issues、PR、CI 状态 |
pnpm / npm | 安装依赖、运行脚本、执行测试 |
pytest | Python 项目测试 |
docker | 本地服务、数据库、集成环境 |
aws / gcloud | 云服务排查和部署相关操作 |
4.2 减少重复确认
可以通过权限配置、允许列表、沙盒等方式减少重复点击，同时保留控制权。
| 可以考虑长期允许 | 不适合随便放开 |
|---|
pnpm test | rm -rf |
pnpm typecheck | 生产数据库写操作 |
pnpm lint | 未知部署命令 |
gh pr view | 涉及密钥或权限变更的命令 |
5. 像和高级工程师沟通一样使用 Claude
Claude Code 不是普通聊天机器人。你可以像给高级工程师分任务一样使用它。
5.1 先问代码库问题
| 任务 | 请阅读 src/billing/，告诉我订阅升级的完整流程。 |
|---|
| 重点 | 入口在哪里、状态如何变化、哪些地方会调用 Stripe、有哪些边界情况。 |
5.2 让它先采访你
| 背景 | 我想做一个团队邀请功能。 |
|---|
| 要求 | 请先采访我，问清楚技术实现、权限、UI、边界情况和取舍。不要急着写代码。 |
| 输出 | 问完后，把完整规格写到 SPEC.md。 |
5.3 复杂任务先计划
| 先计划 | 先进入计划模式。阅读相关代码，告诉我需要改哪些文件、为什么改、风险是什么。暂时不要修改代码。 |
|---|
| 再实现 | 按这个计划实现。实现后运行相关测试，并总结改了什么。 |
6. Subagents：把调查和审查拆出去
Subagents 可以理解成 Claude Code 里的“专门小助手”。主会话负责推进任务；subagent 负责做独立工作，比如搜索、审查、调试、分析日志。
6.1 适合交给 Subagent 的任务
| 任务 | 是否适合 |
|---|
| 全项目搜索某个模式 | 适合 |
| 安全审查 | 适合 |
| 测试失败原因分析 | 适合 |
| 性能问题调查 | 适合 |
| 一个很小的改动 | 不需要 |
| 需要持续讨论的主线实现 | 不太适合 |
6.2 创建 Project Subagent
在项目根目录创建：.claude/agents/code-reviewer.md
| name | code-reviewer |
|---|
| description | Reviews recent code changes for correctness, security, maintainability, and consistency. Use proactively after code changes. |
| tools | Read, Grep, Glob, Bash |
| model | inherit |
| 执行步骤 | 先运行 git diff；只关注改动文件；检查正确性、边界情况、安全风险、缺失测试和是否符合现有模式；不要编辑文件；按严重程度输出发现。 |
这个 subagent 没有 Edit，所以它能看代码、搜索、跑命令，但不能修改文件。适合做 reviewer。
6.3 调用 Subagent
| 代码审查 | Use the code-reviewer subagent to review my recent changes. Do not edit files. Focus on correctness, edge cases, and missing tests. |
|---|
| 调试测试 | Have the debugger subagent investigate this failing test and fix the root cause. |
7. Writer / Reviewer 模式
Writer / Reviewer 是一种协作模式，不是某个按钮。
| 不要让同一个上下文里的 Claude 写完代码后，又马上审查自己的代码。 |
|---|
因为它刚写过这段代码，容易带着自己的假设去看。更好的方式是让一个 Claude 写，另一个 Claude 用新鲜上下文审。
7.1 两个会话的做法
| Writer | Implement a rate limiter for our API endpoints. Follow existing middleware patterns. Write relevant tests. Run the nearest test suite after implementation. |
|---|
| Reviewer | Review the uncommitted changes. Focus on edge cases, race conditions, security issues, consistency with existing middleware patterns, and missing tests. Do not edit files. Return findings ordered by severity. |
| 回到 Writer | Here is reviewer feedback: [paste feedback]. Please address these issues. Run the relevant tests again. |
7.2 用 Subagent 做轻量 Reviewer
| 轻量审查 | Use the code-reviewer subagent to review my recent changes. Do not edit files. Return only actionable findings. |
|---|
这种方式更方便，但不如完全独立的新会话干净。高风险改动更推荐两个会话。
8. 最后记住这五句话
- 上下文是最贵的资源，别让噪音塞满它。
- 给 Claude 可验证目标，而不是模糊愿望。
- 用
CLAUDE.md 固化项目规则，但保持短。
- 像和高级工程师沟通一样给背景、约束和验收标准。
- 用 Subagents 和 Writer / Reviewer，把搜索、审查、调试从主会话里拆出去。
