一、 核心模式转变：从编码者到审查者与决策者
随着 AI 承担越来越多的代码生成工作，开发者的核心职责发生了根本性位移：
- 旧模式：调研目标 → 能否实现（聚焦可行性）。
- 新模式：决策选型 → 如何更优实现（聚焦架构、性能与可维护性）。
两大主要心力消耗点：
- 方案决策成本：AI 提供多路径方案，需投入精力评估权衡。
- 代码审查密度：需快速阅读并理解 AI 生成逻辑，指导下一步修改，导致单次交互时间延长。
二、 AIDR 闭环工作流 SOP
本工作流对标质量管理中的 PDCA 循环，将一次标准的 AI 辅助开发流程拆解为以下四个阶段：
| 阶段 | PDCA 对标 | 核心动作 | 产出物/目标 |
|---|---|---|---|
| A - 分析阶段 | P (Plan) | 描述需求 → AI 梳理旧代码改动点 → 多轮交互获取 N 种方案 → 人工决策。 | 确定最优技术方案与风险评估报告。 |
| I - 实现阶段 | D (Do) | 依据选定方案生成代码 → 根据 UI 微调样式 → 根据 PRD 修正交互逻辑。 | 功能可用且符合用户习惯的 MVP。 |
| D - 诊断阶段 | C (Check) | 视角切换：要求 AI 以 P8 架构师视角 审查改动。 | 识别隐藏风险、性能瓶颈、代码坏味道及优化建议清单。 |
| R - 精炼阶段 | A (Act) | 人工筛选风险点（忽略/处理）→ AI 针对高优先级问题进行修复与优化。 | 代码闭环：消除潜在 Bug，提升鲁棒性。 |
三、 详细执行步骤解析
第一步：分析 (Analyze) —— 谋定而后动
- 输入：明确的业务需求描述。
- AI 角色：资深代码阅读助手。
- 流程：
- 指令 AI 扫描现有代码库关联模块。
- 要求 AI 输出 改动影响面 与 潜在冲突点。
- 要求 AI 提供 2-3 个实现思路（如：重构式实现 vs 补丁式实现）。
- 人工介入：对比方案优劣，做出 架构级决策。
第二步：实现 (Implement) —— 交互式塑形
- 输入：选定的技术方案。
- AI 角色：初级至中级开发工程师。
- 流程：
- 生成核心业务逻辑代码。
- 微调循环：通过一系列小对话调整 UI 像素级还原与 PRD 交互细节，使产品体验自然贴合用户习惯。
- 注意：此阶段通常是开发者过去习惯的终点，但 AIDR 模式要求继续推进至后两步。
第三步：诊断 (Diagnose) —— 架构师视角的 Check
- 输入：已完成的代码变更集 (Diff)。
- AI 角色：P8 架构师 / 技术委员会成员。
- 关键 Prompt 示例：“请以 P8 级别后端/前端架构师的视角，审查本次改动。重点分析：并发场景下的线程安全、对原有模块的耦合度破坏、极端异常处理缺失以及 SQL 查询性能隐患。”
- 价值：弥补个人经验盲区。AI 会提出开发者未考虑到的边缘情况或长期维护隐患，实现 前置风险清理。
第四步：精炼 (Refine) —— 选择性优化与闭环
- 输入：诊断阶段生成的“风险与优化清单”。
- AI 角色：代码修复助手。
- 流程：
- 人工过滤：并非所有风险都需修复（如：极低频场景的过度防御）。
- 定向修复：将确定的“必须修复项”交还 AI 进行处理。
- 闭环确认：代码健壮性达到交付标准。
四、 总结与洞察
- 工作形态的变化：开发者会出现 “一上午一行代码未写，全在沟通方案” 的现象。这是 AI 时代效率提升的必然代价——将调试时间前置为决策时间。
- AIDR 的本质：这是软件开发领域的 PDCA 持续改进循环。过去可能止步于 Do（实现），现在必须强制走完 Check（诊断） 与 Act（精炼） 才能保证 AI 生成代码的工业化质量。
- 核心竞争力迁移：开发者的能力要求已从“打字速度和 API 记忆”转变为 “快速阅读理解他人（AI）代码的能力” 与 “架构级方案权衡能力”。
