09 常见工作流——从探索到交付

原文：Common Workflows

七个核心工作流

1. 探索新代码库

"给我这个代码库的概览"
→ "解释主要的架构模式"
→ "关键的数据模型有哪些？"
→ "认证是怎么处理的？"

要点：从宽到窄，先全景后细节。

2. 修 Bug

"运行 npm test，有报错"
→ "建议修复 user.ts 里那个 @ts-ignore 的方法"
→ "用 null check 方案修改 user.ts"

要点：让 Claude 亲眼看到错误输出，比你描述错误更有效。

3. 重构

"找出代码库中已废弃的 API 用法"
→ "建议如何用现代 JS 特性重构 utils.js"
→ "重构并保持相同的行为"
→ "跑测试验证"

要点：小步前进，每步测试。

4. 写测试

"找出 NotificationsService 中没有测试覆盖的函数"
→ "为通知服务添加测试"
→ "添加边界条件的测试用例"
→ "运行并修复失败的测试"

要点：Claude 会模仿你已有的测试风格。告诉它你要验证什么行为。

5. 创建 PR

"总结我对认证模块的修改"
→ "创建 PR"
→ "在 PR 描述中加入安全改进的上下文"

要点：通过 gh pr create 创建的 PR 会自动关联会话，之后可用 claude --from-pr <number> 恢复。

6. Plan Mode 做规划

claude --permission-mode plan

"我需要把认证系统重构为 OAuth2，写一个详细的迁移计划"
→ "向后兼容怎么处理？"
→ "数据库迁移怎么做？"

然后 Ctrl+G 在编辑器中编辑计划，确认后切回 Normal Mode 实现。

7. Unix 管道集成

# 管道输入输出
cat build-error.txt | claude -p '简明解释这个构建错误的根因' > output.txt

# 作为 linter
npm run lint:claude  # 在 package.json 中定义的 claude -p 命令

# 结构化输出
claude -p 'analyze this code' --output-format json

会话管理进阶

命名和恢复

claude -n auth-refactor        # 启动时命名
/rename auth-refactor          # 运行中重命名
claude --resume auth-refactor  # 按名恢复
claude --continue              # 恢复最近会话

`/resume` 选择器快捷键

快捷键	操作
`↑/↓`	导航
`P`	预览会话内容
`R`	重命名
`/`	搜索
`A`	切换当前目录/所有项目
`B`	过滤当前分支

Git Worktree 并行工作

claude --worktree feature-auth    # 创建隔离工作副本
claude --worktree bugfix-123      # 另一个隔离副本

每个 worktree 有独立的文件和分支。退出时无更改自动清理，有更改则提示保留。

Extended Thinking（深度推理）

默认开启。对复杂架构决策、多步实现规划、权衡评估特别有用。

控制方式	方法
Effort level	`/effort` 调整（low/medium/high）
ultrathink	prompt 中加 “ultrathink” 临时启用高强度
切换	`Option+T` / `Alt+T`
查看过程	`Ctrl+O` 开启 verbose 模式

让 Claude 采访你（大型特性推荐）

"我想做 [简要描述]。用 AskUserQuestion 工具详细采访我。
问技术实现、UI/UX、边界情况、权衡。
不要问显而易见的问题，深入我可能没考虑到的难点。
采访结束后写完整 spec 到 SPEC.md。"

然后新建会话执行 spec——新会话有干净的上下文专注实现。

知识检测

应用题

你接手一个有 200+ 文件的 Ruby on Rails 项目，之前从没接触过 Rails。设计一个用 Claude Code 探索和理解这个项目的步骤序列（不超过 5 步）。
你有一个复杂的跨 3 个微服务的 bug。每个服务有自己的仓库。你会怎么组织 Claude Code 的会话来排查？
团队里有 5 个人同时用 Claude Code 开发同一个项目。你会设置哪些 CLAUDE.md 规则和 Hook 来避免冲突？

参见

08-最佳实践与工作模式 — 底层原则
07-SubAgent-子代理系统 — 并行任务的另一种方式

参考答案

1. 探索 200+ 文件的 Rails 项目

(1) "给我这个项目的整体架构和主要模块概览"——建立全景图 (2) "解释路由结构（config/routes.rb），找出核心 controller"——理解入口 (3) "追踪一个典型请求（如用户登录）从 route 到 controller 到 model 到 view 的完整流程"——理解数据流 (4) "项目用了哪些 gem？有没有非标准的架构模式？"——理解依赖和特殊约定 (5) "找出测试覆盖最薄弱的模块"——知道风险区域。从宽到窄，先流程后细节。

2. 跨 3 个微服务排查 bug

(1) 每个服务一个 Git Worktree：claude --worktree svc-auth、claude --worktree svc-api、claude --worktree svc-gateway (2) 主会话做协调——收集三个 worktree 的发现，分析跨服务的数据流 (3) 或者用一个 Plan Mode 会话先分析日志/错误信息，确定问题最可能在哪个服务 (4) 然后开 SubAgent 深入该服务排查。关键是不要把三个服务的代码都塞进同一个上下文。

3. 5 人团队的 CLAUDE.md 和 Hook

CLAUDE.md：(1) 代码规范和 PR 模板 (2) 分支命名约定 (3) 测试要求（哪些文件必须有测试）(4) 禁止直接 push main。Hook：(1) PreToolUse + Bash matcher：阻止 git push origin main (2) PostToolUse + Edit/Write matcher：自动跑 prettier/eslint (3) Stop hook：提交前检查是否有未通过的测试。把这些打成 Plugin 让每个人安装。