📄 本页由源文件
skills/dev-flow/references/flow-retrospective.md自动投影生成（单一权威源）。请勿直接编辑本页。
流程自我反思规范
每次需求开发完成后，对 dev-flow 执行过程进行自我反思，识别流程中的问题、缺陷和改进机会，持续优化开发工作流。
核心原则
- 反思对象是流程本身，不是代码质量（代码经验由步骤 9a 负责）
- 建议只输出不执行——所有优化建议呈现给用户，由用户决策是否采纳和如何调整
- 诚实评估——不回避问题，不美化评分，真实反映执行质量
- 聚焦可改进项——一切顺利的步骤简要带过，把篇幅留给有问题的环节
触发策略
| 模式 | 触发点 | 反思深度 | 加载本文件 |
|---|---|---|---|
| 完整执行 | 步骤 9b（步骤 9 的第二部分） | 🔴 深度反思 | 是 |
| 标准执行 | 步骤 7 末尾（commit 后、devlog 后） | 🟡 数据驱动反思（精简版） | 否（内联 3 问模板） |
跳过条件
以下情况可精简或跳过反思，避免浪费 Token：
| 条件 | 处理 |
|---|---|
| 完整执行全程无回退、无卡顿、无用户纠正 | 精简为 3 行总结（"本次流程执行顺畅，无优化建议"） |
| 标准执行对话 Token > 50 轮 | 精简为一行摘要（不再因"改动≤2文件"跳过） |
| 对话 Token 已进入后期（轮数 > 50） | 跳过反思，优先保护上下文 |
深度反思（完整执行）
评估维度
对 dev-flow 每个已执行步骤，从以下 5 个维度评估：
| 维度 | 说明 | 评分标准 |
|---|---|---|
| 执行质量 | 该步骤是否按规范完整执行 | ⭐1~5，5 = 完美执行 |
| 耗时效率 | 相对于任务复杂度，该步骤耗时是否合理 | 偏快 / 正常 / 偏长 / 过长 |
| 信息充分度 | 进入该步骤时，所需信息是否充足 | 充足 / 部分缺失 / 严重不足 |
| 衔接流畅度 | 与上一步骤的衔接是否顺畅 | 顺畅 / 有断层 / 需回退 |
| 产出价值 | 该步骤的输出对后续步骤的帮助程度 | 高 / 中 / 低 / 无效 |
输出模板
使用以下结构输出深度反思报告：
🔄 流程自我反思（深度）
一、步骤执行评估
| 步骤 | 执行质量 | 耗时效率 | 问题/改进点 |
|---|---|---|---|
| 阶段 0 需求理解 | ⭐⭐⭐⭐⭐ | 正常 | — |
| 步骤 1 研究定位 | ⭐⭐⭐⭐ | 偏长 | 搜索策略待优化： |
| 步骤 2 确认范围 | ... | ... | ... |
| 步骤 3 方案制定 | ... | ... | ... |
| 步骤 4 用户决策 | ... | ... | ... |
| 步骤 5 执行修改 | ... | ... | ... |
| 步骤 5.5 编码后置 | ... | ... | ... |
| 步骤 6 系统验证 | ... | ... | ... |
| 步骤 7 清理检查 | ... | ... | ... |
| 步骤 8 代码审查 | ... | ... | ... |
| 步骤 9a 经验提炼 | ... | ... | ... |
二、流程问题诊断
发现的问题：
| # | 问题描述 | 发生在哪个步骤 | 影响程度 | 根因分析 |
|---|---|---|---|---|
| 1 | 步骤 X | 高/中/低 |
缺失的环节：
- 是否有某些场景没有被现有步骤覆盖？
- 是否有某些检查项被遗漏？
冗余的环节：
- 是否有某些步骤在本次场景中是多余的？
- 是否有重复执行的检查？
三、优化建议
⚠️ 以下建议仅供用户评估，不会自动执行任何修改。
| # | 建议内容 | 涉及文件 | 优先级 | 预期收益 |
|---|---|---|---|---|
| 1 | {相对路径} | 🔴 HIGH | ||
| 2 | {相对路径} | 🟡 MEDIUM | ||
| 3 | {相对路径} | 🟢 LOW |
📌 「涉及文件」列按
~/.codebuddy/rules/AI行为规范.mdc的「文件/代码位置引用」规范使用反引号包裹相对路径格式（`相对路径`），用户可直接点击跳转到对应文件。
四、本次反思总结
- 整体流程评分：⭐X / 5
- 最大亮点：
- 最大改进点：
- 一句话总结：
深度反思执行规则
- 逐步骤回顾：只评估实际执行过的步骤，跳过的步骤标注"已跳过"
- 回退必记录：任何步骤回退都必须在问题诊断中记录，分析回退原因
- 用户纠正必记录：用户的任何纠正/修改意见都反映为流程问题
- 并行调度评估：如果本次使用了并行调度，评估调度模式和效果是否合理
- 跨步骤关联：关注步骤间的信息传递是否有断层
数据驱动反思（标准执行）
标准执行不加载本文件，反思逻辑内联在
closeout-flow.md环节 I 中。 本章节仅作为规范说明，描述标准执行下的反思行为。
标准执行反思内容（步骤 7 环节 I）
标准执行在步骤 7 环节 I 执行数据驱动反思，包含以下子环节：
- 度量数据引用：引用步骤 7 完成钩子中已采集的度量数据
- L1 即时反思：按
metrics-rules.md「L1 即时反思」模板输出（含执行深度对比） - 经验提炼（精简版）：有高价值教训时写入规则/learnings，无则跳过
- L2 阶段报告：满足条件时自动追加（与完整执行共享同一触发逻辑）
数据驱动反思执行规则
- 不加载本文件——反思逻辑内联在
closeout-flow.md环节 I，零额外 Token 消耗 - 以度量数据为依据——所有反思结论必须基于采集的度量数据，禁止主观臆断
- 含执行深度对比——L1 反思必须包含本次执行深度与同深度历史均值的对比
- 跳过条件——所有指标在历史平均 ±30% 范围内且 first_time_right=true 时，精简为一行摘要
优化建议的处理规则
用户决策流程
AI 输出优化建议后，用户评估每条建议并决策：
- ✅ 采纳 → 用户指示 AI 修改对应 Skill 文件
- 📌 记录 → 记录到工作上下文备注区块，后续再处理
- ⏭️ 跳过 → 不处理
- ❌ 否决 → 不处理，AI 记住此类建议不再重复提出
建议质量标准
每条建议必须满足：
- 具体可执行——明确说明要改什么文件的什么内容，而非泛泛而谈
- 有根据支撑——基于本次实际执行中的观察，而非假设
- 标注影响范围——涉及哪些模式、哪些步骤、哪些文件
- 预期收益明确——优化后能带来什么改善（效率/质量/覆盖度）
禁止行为
- ❌ 禁止 AI 自行修改 Skill 文件（即使建议优先级为 HIGH）
- ❌ 禁止输出模糊建议（如"流程可以更好"）
- ❌ 禁止重复提出用户已否决的建议
- ❌ 禁止为了"有建议可写"而编造不存在的问题