Claude Code 在两种状态下使用效果差别巨大：偶尔用一次感觉很神奇，每天依赖感觉很平常——但平常状态下效率其实更高。差别在于有没有把它真正嵌进日常工作流，而不是每次从零开始。
这篇文章讲的是那些每天都在用 Claude Code 的开发者真正的工作方式。
早晨 10 分钟日常：启动工作日
第一步：读昨天（2 分钟）
总结昨天的 git log（main 和我的 feature 分支），
有没有影响我今天工作的改动？
有没有我应该 review 的 PR？
这个步骤替代了手动 git log 然后自己看——Claude Code 直接给你"有无影响我今天的东西"的判断，不只是列清单。
第二步：规划今天（3 分钟）
基于 CLAUDE.md 里的项目上下文和 todo.md 里的任务列表，
帮我规划今天的工作：
- 有没有技术债值得今天顺手处理？
- 有没有关联的任务可以批量解决？
- 有没有我可能忽略的依赖关系？
第三步：清理收件箱（5 分钟）
检查开放的 GitHub Issues 和 PR 评论，
有没有需要我今天回应的？
有没有超过 48 小时没有更新的 PR（可能被卡住了）？
开发中：减少上下文切换
模式：一个 Session 专注一个任务
每个独立任务开一个新 Session，不要在同一个 Session 里混做不同事。
好的方式：
- Session 1：专注实现 auth 模块
- Session 2：专注修复 bug #234
- Session 3：专注写 API 文档
不好的方式：在一个 Session 里从 auth 跳到 bug 修复跳到文档
原因：上下文干净时，Claude Code 对当前任务的判断更准确，也更不容易把不同任务的代码混淆。
模式：CLAUDE.md 存项目上下文，不要每次说
每次都说"我们用 TypeScript 严格模式，用 Prisma ORM，不用 any 类型"是在浪费你的时间。把这些全部写进 CLAUDE.md：
## 开发约定
- TypeScript 严格模式，禁止 any（需要时必须注释原因）
- ORM：Prisma，禁止裸 SQL
- 测试框架：Vitest，覆盖率要求 80%
- 提交规范：Conventional Commits
- 错误处理：统一用 AppError 类，不抛原始 Error
## 常见命令
- 运行：pnpm dev
- 测试：pnpm test
- 类型检查：pnpm typecheck
- 部署 staging：make deploy ENV=staging代码 Review 工作流
作者视角：提交前自检
Review 这次 diff（相比 main 分支）：
1. 有没有我可能忽略的边界情况？
2. 有没有比现在更简洁的实现方式？
3. 有没有需要补充的测试？
4. 生成 PR 描述草稿
Reviewer 视角：快速上下文建立
这个 PR 改了 auth 模块（附 diff），
帮我：
1. 理解改动的意图和主要变化
2. 找出潜在的安全问题
3. 检查有没有影响现有功能的变动（尤其是 token 过期处理）
4. 给出 2-3 个具体的审查重点建议
Debug 工作流
系统化排查，不要碰运气
这个 500 错误出现在生产环境，复现率约 10%：
[粘贴错误堆栈]
[粘贴相关代码]
帮我：
1. 找出最可能的原因（按概率排序，不只是第一个猜测）
2. 对每个原因给出验证方法（用什么命令或日志可以确认）
3. 如果是并发问题，描述怎么重现
关键：让 Claude Code 给出多个候选原因按概率排序，不只是第一个猜测。大多数时候你也不知道真正原因，多个候选比只有一个更有价值。
用日志追踪，不要只靠代码分析
这是相关的日志文件（error.log），
结合代码，找出：
1. 错误第一次出现是在哪个操作之后？
2. 有没有规律性（特定用户、特定时间段、特定操作）？
3. 日志里有没有更早期的警告被忽略了？
重构工作流
渐进式重构，不要大爆炸
我想重构 src/payment/ 模块，
但不能破坏现有功能，也不能影响其他团队正在合并的 PR。
先帮我：
1. 分析这个模块的主要问题（技术债在哪里）
2. 设计一个可以分 5-10 个小 PR 完成的渐进式重构路径
3. 每个 PR 应该是独立、可测试、不破坏功能的
从最低风险的改动开始
不推荐的做法：让 Claude Code 一次性重构整个模块，生成一个 1000 行的 diff。
文档工作流
代码驱动文档，不手动写
基于 src/api/ 下的所有 route 文件，
生成 OpenAPI 3.0 规范文档（docs/api.yaml）：
- 从 Zod schema 推断参数类型
- 从代码注释提取描述
- 从错误处理代码推断可能的错误响应
如果某个端点信息不足，标注「需要补充」
保持文档与代码同步
对比 docs/api.yaml 和 src/routes/ 下的实际代码，
找出：
1. 文档里有但代码里已经删除的端点
2. 代码里有但文档里没有的端点
3. 参数类型不一致的地方
下班前：整理和交接
今天的工作快结束了，帮我：
1. 提交有意义的 git commit message（基于今天的改动）
2. 更新 todo.md：标记完成的，添加明天的接续点
3. 如果有未完成的任务，记录当前进展和下次继续的起点
4. 有没有需要告知团队的内容（影响他人的改动）
让 Claude Code 越用越顺手的三个习惯
1. 用完就记录：重要的决策、踩过的坑、找到的好方法——让 Claude Code 帮你更新 CLAUDE.md 或 README。不记录等于没有发生。
2. 从具体问题开始：不要说"帮我优化代码"，要说"这个函数有 N+1 查询，帮我优化数据库调用方式，保持现有接口不变"。越具体输出越准。
3. 把好用的流程变成 Routine：第一次做完感觉好的工作流，马上写进 CLAUDE.md 的 Routines 部分，下次一行调用。
来源：medium.com/@richardhightower Claude Code 每日工作流 | 整理：ClaudeEagle