28. 常见工作流
本章你将学到
- 8 种高频开发场景的标准工作流
- 每种场景的推荐提示词模板
- 技巧和注意事项
22.1 理解陌生代码库
这个项目是做什么的？
使用了哪些主要技术栈和框架？
入口文件在哪里？主要的代码流程是什么？
然后给我讲讲 src/auth/session.ts 第 134 行的 async move 是什么意思进阶：用计划模式深度理解
bash
claude --permission-mode plan阅读 src/ 目录，理解整体架构。
重点关注：
1. 主要模块及其职责
2. 模块间的依赖关系
3. 数据流向（从请求进来到响应出去）
最后用一张 ASCII 图展示架构。22.2 修 Bug
标准流程：
用户反馈：[具体症状]
相关代码应该在 [文件路径]。
步骤：
1. 读相关代码，理解根本原因
2. 写一个能复现 bug 的失败测试
3. 修复 bug
4. 验证测试通过
修根因，不要压错误或绕过检查。有错误日志时：
生产报错如下：
[粘贴完整的错误栈]
发生条件：[什么时候出现]
分析原因，写失败测试复现，然后修复。22.3 加新功能
分阶段实现：
加一个用户头像上传功能。
阶段 1（后端）：
- POST /api/users/avatar 端点
- 接受 multipart/form-data
- 验证文件类型（jpg/png/gif）和大小（< 5MB）
- 存到 public/uploads/avatars/
- 返回文件 URL
后端做完跑测试验证，然后我来确认再做前端。22.4 代码审查
# 审查当前分支改动
/review
# 更具体的审查
审查 src/api/orders.ts 的改动，重点关注：
1. 是否有 SQL 注入风险
2. 错误处理是否完整
3. 是否有边界情况没处理
# 让子代理做无偏见审查
用 security-reviewer 子代理审查刚才写的代码22.5 Git 操作
# 查看状态
我改了哪些文件？有什么没提交的改动？
# 提交
把我的改动 commit，写一个描述性的 commit 信息
（说清楚做了什么，为什么这么做）
# 分支管理
新建分支 feature/user-profile
把这些 commits 变基到最新的 main
帮我解决 merge conflict（保留我的改动为主）
# PR
开一个 PR，描述里包含：
- 这次改动做了什么
- 为什么这么改
- 如何测试22.6 重构
安全重构三步法：
重构目标：把 src/services/ 里所有 callback 改成 async/await。
先不要改任何代码，只做：
1. 分析需要改的文件列表
2. 识别依赖关系（哪个先改）
3. 评估风险点
分析完给我计划，我确认后再开始。开始重构 userService.ts（第一个文件）：
- 改成 async/await
- 保持接口不变
- 改完跑测试验证行为不变
- 测试通过后告诉我，我确认再继续下一个22.7 依赖升级
把 React 从 17 升到 18，步骤：
1. 更新 package.json 里的版本
2. 查找所有 17→18 的 breaking changes
3. 更新代码解决 breaking changes
4. 跑测试，修复所有失败
5. 告诉我做了哪些改动，哪些需要我关注
分步骤做，每步告诉我进展。22.8 生成文档
# API 文档
根据 src/api/ 的代码生成 OpenAPI 3.0 规范（YAML 格式）
保存到 docs/openapi.yaml
# README 更新
根据当前代码更新 README.md 的「安装」和「使用」部分
保持其他部分不变
# 代码注释
给 src/utils/crypto.ts 里的所有公开函数加 JSDoc 注释
只在原因不显而易见的地方加注释，不要废话注释