开篇
学了很多 Prompt，真正写代码时却还是只会问：
帮我实现这个功能。
问题不在于 Prompt 不够高级，而在于缺少一套稳定流程。
一个可复用的 AI 编程工作流，至少要包含三件事：
输入上下文
↓
分阶段协作
↓
验证输出
这篇文章不讲复杂理论，只分享 3 个我认为最值得保存的工作流：
- 从模糊需求到任务清单。
- 从异常现象到根因定位。
- 从能运行的代码到可维护代码。
每一个都可以直接复制到日常开发中。
一、需求拆解工作流
适用场景
产品只给了一句话，需求边界、异常流程和验收标准都不清楚。
例如：
给订单列表增加导出功能。
此时不要让 AI 直接写代码，先让它补全问题。
工作流
原始需求
↓
识别歧义和风险
↓
提出澄清问题
↓
整理验收标准
↓
拆成开发任务
可复制 Prompt
你是一名负责需求分析的高级开发者，请先不要写代码。
原始需求：
给订单列表增加导出功能。
已知上下文：
- 后端使用 Spring Boot。
- 订单列表已有分页和筛选功能。
- 导出文件为 Excel。
请输出：
1. 当前需求中的歧义和风险。
2. 需要向产品确认的问题，按优先级排序。
3. 正常流程、异常流程和权限边界。
4. 可验证的验收标准。
5. 前端、后端、测试和配置任务清单。
不确定的内容标记为“待确认”，不要自行假设。
验收点
- 是否覆盖权限、数据量、筛选条件和导出失败？
- 每个任务是否足够小，并且有明确产物？
- “待确认”内容是否已经由真实负责人确认？
二、故障排查工作流
适用场景
接口报错、任务超时或线上数据异常，但根因还不明确。
不要只把一段报错丢给 AI。它至少需要：
- 预期结果和实际结果。
- 完整错误信息与关键日志。
- 相关代码和调用链。
- 最近的代码、配置或数据变更。
- 已经验证过的现象。
工作流
整理事实
↓
列出根因假设
↓
设计最小验证
↓
根据证据排除
↓
修复并补回归测试
可复制 Prompt
请协助定位下面的问题，先不要直接修改代码。
现象：订单查询接口偶发超时。
预期：请求在 500ms 内返回。
实际：部分请求超过 5 秒后失败。
范围：只发生在按手机号筛选时。
最近变更：昨天新增了手机号模糊查询。
我会继续提供日志、SQL 和相关代码。
请按下面格式分析：
1. 已确认事实。
2. 缺失信息。
3. 按可能性排序的根因假设。
4. 每个假设的最小验证步骤。
5. 验证时需要观察的日志或指标。
没有证据时不要直接下结论。
验收点
- 结论是否有日志、SQL、指标或测试支撑？
- 修复是否只针对已经确认的根因？
- 是否增加了能够复现故障的回归测试？
三、代码审查工作流
适用场景
AI 已经生成代码，功能看起来能跑，但还没有经过正式审查。
与其问“这段代码有没有问题”，不如让 AI 按风险逐层检查。
工作流
确认需求和改动范围
↓
检查正确性与边界
↓
检查安全、性能和维护性
↓
按严重级别列问题
↓
最小修改并运行测试
可复制 Prompt
请审查下面的代码变更，先不要重写整个文件。
背景：
- 本次改动用于新增订单导出接口。
- 只能导出当前用户有权限查看的订单。
- 单次最多导出 1 万条。
请重点检查：
1. 功能正确性和边界条件。
2. 权限校验与敏感数据泄露。
3. 内存、数据库查询和并发风险。
4. 异常处理与资源释放。
5. 测试是否覆盖关键风险。
请按严重程度输出：阻断、重要、建议。
每个问题包含：位置、触发条件、影响、修改建议和验证方法。
如果没有证据，请不要把个人偏好列为缺陷。
验收点
- 高风险问题是否优先处理？
- 建议是否基于需求，而不是单纯追求复杂架构？
- 修改后是否重新运行单测、集成测试和静态检查？
四、让工作流真正可复用的 4 个原则
Prompt 可以修改，但下面四个部分尽量不要省略：
| 部分 | 作用 |
|---|---|
| 背景 | 告诉 AI 当前系统和业务约束 |
| 任务 | 明确这次只解决什么问题 |
| 限制 | 防止扩大修改范围或擅自假设 |
| 验证 | 判断输出是否真的可用 |
我通常还会加上三句话：
先不要直接写代码。
不确定的内容标记为“待确认”。
给出结论时，请同时给出证据和验证方法。
这三句话看起来简单，却能明显减少 AI 自信地猜测。
五、选择工作流，而不是堆叠 Prompt
可以根据当前任务快速选择：
| 当前问题 | 推荐工作流 | 最终产物 |
|---|---|---|
| 不知道要做什么 | 需求拆解 | 验收标准和任务清单 |
| 不知道为什么出错 | 故障排查 | 根因证据和修复方案 |
| 不知道代码是否可靠 | 代码审查 | 风险清单和验证结果 |
三个工作流的共同点是：
AI 负责扩大分析范围，开发者负责确认事实、做出决策并完成验收。
总结
今天的 3 个工作流，可以浓缩成三个闭环：
需求：澄清 → 验收 → 拆解
排障：假设 → 验证 → 根因
审查：风险 → 修改 → 测试
- 需求不清时，先补问题，不要急着生成代码。
- 出现故障时，先整理证据，不要让 AI 猜答案。
- 审查代码时，按风险排序，不要纠结无关的风格偏好。
- 每一次 AI 输出，都应该有明确的人工验收动作。
下一篇文章，我们将继续学习：
《周复盘：过去三周，我的开发效率真正提升在哪》
✍坚持原创，求关注，点赞，收藏
