工作流实战：代码审查、文档生成、数据整理
三个最能立刻见效的工作流：把 diff 变成分级意见、把代码和需求变成结构文档、把脏表变成干净表和结论。每个案例都给完整提示词、检查点和输出物格式，照着改改就能用。共同点是输入要先固定、输出要先定义，否则每次都靠运气。
案例一：代码审查（拉 diff → 检查清单 → 分级意见）
先把范围固化：只看这次改了什么，不要让模型自由翻整个仓库。
git fetch origin main
git diff --stat origin/main...HEAD # 先看改了哪些文件、多少行
git diff origin/main...HEAD > /tmp/review.diff # 导出补丁，作为唯一输入
wc -l /tmp/review.diff # 超过几百行就分批审查
意见必须分级，否则你会收到二十条「建议加注释」把真问题淹掉：
| 级别 | 含义 | 处理要求 |
|---|---|---|
| 阻断 | 会导致数据错误、安全问题、线上故障 | 必须改完才能合并 |
| 重要 | 逻辑缺陷、异常漏处理、性能明显退化 | 建议本次改掉 |
| 提示 | 命名、结构、可读性 | 可记录到后续优化 |
你是一名严格的代码审查者。输入是 /tmp/review.diff，只审查这个补丁。
按下面的检查清单逐项过一遍，每条都要给出「有问题 / 无问题 / 无法判断」：
1) 正确性：边界值、空值、并发、时区与精度；
2) 错误处理：异常是否被吞掉、失败是否可重试、超时是否有兜底；
3) 安全：输入校验、SQL 拼接、越权访问、日志是否打印了敏感信息；
4) 兼容性：接口字段变更是否向后兼容、数据库变更是否可回滚；
5) 测试：新增逻辑有没有对应测试，测试是否只覆盖了顺利路径；
6) 可维护性：命名、重复代码、过长的函数。
输出格式：一张表，列 = 级别(阻断/重要/提示) | 文件与行号 | 问题 | 依据 | 建议改法。
规则：
- 每条意见必须引用具体行号与代码片段，没看到证据就不要写；
- 不要给「加注释」「加日志」这类无信息量的建议；
- 你认为没问题但需要人工确认的，单独列一节「需要作者确认」；
- 最后给出结论：可以直接合并 / 修改后合并 / 需要重新设计，并说明理由。
不要修改任何文件，只输出意见。
检查点：审查意见是建议，不是命令。合并前逐条判断，别为了「清零意见」而机械照改。
案例二：文档生成（读代码/需求 → 结构化文档）
先定输出骨架，再让它填空，这是文档能否被复用的关键。
| 输入 | 输出结构 | 验收标准 |
|---|---|---|
| 服务代码 + 配置文件 | 概览、对外接口、数据模型、依赖、部署要点 | 接口字段与代码一致，无凭空想象 |
| 需求文档 + 旧版说明 | 背景、目标、范围、流程、验收标准、未决问题 | 每条需求都能追溯到原文 |
| 事故复盘记录 | 时间线、影响面、根因、处置、改进项 | 根因与改进项一一对应 |
读这个目录下的服务代码（只看这些文件，不要看仓库其它部分），产出一份新人上手文档。
输出结构固定为六节：
1) 这个服务做什么：三句话以内，说明业务职责与不做什么；
2) 对外接口：一张表，列 = 方法 | 路径 | 入参 | 出参 | 错误码 | 调用方；
3) 数据模型：每张表一段，字段、含义、关键索引、数据量级（读不到就写「未知」）；
4) 依赖：下游服务、缓存、消息队列、第三方，注明超时与重试配置；
5) 部署与配置：需要哪些环境变量、有哪些开关、默认值是什么；
6) 风险与坑：从代码里能看出来的隐患，每条附文件与行号。
规则：
- 只写你在代码里真实看到的，猜的一律标「需确认」；
- 接口与字段名原样照抄，不要改写、不要美化；
- 不要写「本服务采用先进架构」这类没有信息量的话。
输出：Markdown，写到 docs/onboarding/<服务名>.md，并附一段「本次没写清的部分」清单。
检查点：字段名与错误码必须回代码复核。文档里错一个字段，后面所有调用方都会错。
案例三：数据整理（表格清洗 → 汇总 → 图表建议）
数据活的第一步永远是先描述现状，再谈清洗。
输入是附件里的表格。请按四步处理，每一步的输出都保留：
第一步 体检：给出一张表，列 = 字段名 | 类型推断 | 缺失率 | 唯一值个数 | 示例值(最多3个)；
第二步 清洗：列出你建议的清洗规则与影响行数，规则包括——
- 去除首尾空格、统一全角半角；
- 日期统一为 YYYY-MM-DD，无法解析的单独列出，不要瞎猜；
- 数值字段里混入的单位、千分位、百分号如何处理；
- 重复行如何判定（说明依据哪几列），保留哪一条；
- 缺失值分别处理：能确定的补上，不能确定的留空并标记。
这一步只输出规则与影响行数，等我确认后再执行；
第三步 汇总：按「地区」「月份」两个维度做汇总，给出总行数与金额合计，
并列出金额最高与最低的 5 条明细；
第四步 图表建议：给 3 个图表方案，每个写清：图表类型 | X 轴 | Y 轴 | 想回答的问题 |
你判断的适用性。不要直接画图。
约束：不要删除原始表，清洗结果另存为新表；任何无法确定的取值一律标记而不是填充。
| 清洗动作 | 安全做法 | 危险做法 |
|---|---|---|
| 去重 | 先输出重复行清单与判定依据 | 直接按整行去重删掉 |
| 补缺失 | 只补可推导的（如单位换算） | 用平均值填满缺失 |
| 类型转换 | 先统计转换失败条数 | 转换失败静默丢弃 |
| 单位统一 | 保留原列，新增标准化列 | 覆盖原列导致不可回溯 |
检查点：清洗规则确认后才允许改数据，并保留原始表与一份「被改了什么」的清单。
三个案例共用的检查点
| 位置 | 停下来做什么 | 要拿到什么 |
|---|---|---|
| 输入固定后 | 确认范围，避免它自作主张扩大 | 文件清单与总行数 |
| 分析完成后 | 确认发现的问题是真的 | 带行号/字段名的证据 |
| 写入之前 | 确认影响面与回滚办法 | 变更清单 + 备份路径 |
| 交付之前 | 确认输出格式与不确定项 | 交付物 + 「不确定清单」 |
常见坑
| 坑 | 后果 | 规避 |
|---|---|---|
| 让它审查整个仓库 | 意见泛泛而谈 | 只喂 diff，并限定行数 |
| 意见不分级 | 关键问题被淹没 | 强制分阻断/重要/提示 |
| 文档让它自由发挥 | 编出并不存在的接口 | 只让写读到的，猜的标「需确认」 |
| 清洗直接改原表 | 出错无法回溯 | 另存新表 + 保留原表 |
| 跳过检查点求快 | 错误一路带到交付物 | 范围、写入、交付三处必停 |
小结：三个工作流的结构完全一样——先把输入固定成一个可指认的对象（diff、代码目录、表格），再定义输出物格式，再设范围确认、写入前、交付前三处检查点；AI 出草稿与证据，你判断真假并负责结论。