这篇文章不讲基础操作，讲的是经过验证的工作流模式——从「功能需求到合并 PR」完整路径上每个节点，Claude Code 应该怎么用才最有效。
工作流 1：全流程功能开发
适合：从需求到实现的完整功能
第一步：先面试你
text
"I want to build a user notification system.
Interview me using AskUserQuestion tool.
Ask about delivery channels, read/unread tracking, types, real-time vs batch.
Keep asking until we've covered all edge cases, then write SPEC.md."这一步的价值：把你脑子里模糊的想法变成精确的规格书，消灭「蝴蝶效应」的根源。
第二步：Plan Mode 分析影响
text
[切换到 plan 模式]
"Based on SPEC.md, analyze the implementation plan:
- Which files need to change
- New files to create
- Database schema changes
- API changes
- Estimated complexity"确认方向没问题后再切换执行。
第三步：实现
text
"Implement the notification system per SPEC.md.
Follow patterns in @src/features/messaging/ for reference.
After each major step, run tests to verify."第四步：测试和验证
text
"Write comprehensive tests for the notification system:
- Unit tests for NotificationService
- Integration tests for delivery
- Edge cases: empty recipient list, delivery failure, rate limiting
Run all tests and confirm they pass."工作流 2：代码重构
适合：需要改动多个文件的重构
标准重构流程
text
# Step 1: 分析（plan 模式）
"Analyze impact of refactoring src/auth/ from callbacks to async/await:
- List all affected files
- Identify risky parts (especially concurrent operations)
- Propose step-by-step plan"
# Step 2: 确认方案没问题后开始执行
"Start with Step 1: refactor login.ts.
Run tests after each file to catch regressions early."
# Step 3: 渐进式推进，随时能停
"Continue with session.ts. Verify tests pass."关键原则：每改一个文件就跑一次测试，不要等全部改完再测。早发现早修复。
大型迁移（JS → TS 等）
text
# 用 Fan-out 并行处理
"Create a migration plan for converting the entire src/ to TypeScript.
List all files, group by directory, propose parallel execution order.
Start with utils/ as it has fewest dependencies."工作流 3：测试覆盖补全
适合：新增测试或补齐覆盖率
text
"Look at @src/api/payments.ts and @src/api/payments.test.ts.
The current tests cover happy paths but miss:
- What happens when payment processor returns timeout
- Concurrent duplicate payment requests
- Partial refund after full refund
Write tests for all three cases. Follow the existing test patterns."好测试提示的特点：
- 引用现有测试文件（让 Claude 遵循风格）
- 明确说出要覆盖的 edge case
- 不要说「写更多测试」，要说「写这些具体场景的测试」
工作流 4：PR 代码审查
适合：在合并前发现问题
自审（用不同会话）
text
# 新开一个干净会话（不是写这段代码的那个会话）
"Review the changes in this PR: [git diff 或 @文件]
Focus on:
- Logic errors and edge cases
- Security vulnerabilities (injection, auth, sensitive data in logs)
- Race conditions in async code
- Consistency with existing patterns in @src/
List issues with file:line references and suggested fixes."为什么要用不同的会话：在写代码的会话里 review，Claude 会有「自己孩子」的偏见，不够客观。干净会话没有这个问题。
安全专项审查
text
"Security review of @src/api/users.ts:
- Any SQL injection risks? (parameterized queries?)
- Are all endpoints properly authenticated?
- Is any sensitive data (passwords, tokens) logged?
- CSRF protection in place?
Report with severity (critical/high/medium/low) and fix suggestions."工作流 5：技术债清理
适合：定期的代码质量改善
text
# 先分析，不动手（plan 模式）
"Analyze src/utils/ for code quality issues:
- Functions longer than 50 lines
- Duplicate logic across files
- Missing type annotations in TypeScript strict mode
- Unused exports
Create a prioritized list with effort estimates."然后按优先级逐项处理，不要一次性全改。
工作流 6：新人 Onboarding
适合：快速熟悉陌生代码库
text
"I'm new to this codebase. Help me understand it:
1. What does this project do?
2. What's the overall architecture?
3. How does a typical user request flow through the system?
4. What are the key design patterns used?
5. What should I know before making any changes?"这比看文档快得多，还能问跟进问题。
选对工作流的判断树
任务是新功能？
└── 是 → 先 Interview + Plan → 然后实现
任务是改已有代码？
└── 改多个文件？
├── 是 → Plan Mode 看影响范围
└── 否 → 直接执行，精确指向文件和行号
任务是找 bug？
└── 位置明确？
├── 是 → @ 引用文件，先写失败测试
└── 否 → 用子 Agent 搜索，告诉它方向
任务是写测试？
└── 引用现有测试 + 列出具体 edge case
任务是 review？
└── 开新会话（保持上下文干净）
来源：Claude Code 官方 Common Workflows | morphllm.com | 整理：ClaudeEagle