用途：在生成代码未通过测试或未满足需求时，先系统诊断失败根因，再按失败类型匹配最有效的修复策略，避免盲目重试。资料基于对25个GitHub项目的实证研究（Shen, Peng & Owen, 2026）。
主要能力与决策框架： 逻辑错误（算法错误、边界偏移、条件判断错误）→ 自我批评：逐行对照规范，明确差异，生成最小针对性修改。 规范缺失（需求模糊、细节遗漏）→ 渐进式提示：拆分为有序子任务，逐步澄清并生成代码。 模式缺口（API用法、库惯例、框架约定不熟）→ RAG：检索文档、示例或已有方案，据正确模式改写。 低置信度或复合失败（根因不明、多缺陷交织）→ 多模型推理：生成多种实现，比较后综合最优解。
使用方式：先用渐进式提示完成初版生成（数据模型→核心逻辑→边界情况→集成→输出格式），再对测试、类型检查收集失败清单并逐个分类；按分类施加对应修复，每次修复后重新验证，记录哪类失败由哪种方法解决，最终做端到端集成测试。
关键结论：渐进式提示可将平均任务完成率从80.5%提升到96.9%（Cohen's d=1.63，p<0.001）；自我批评对外部服务集成失败提升为0%，应改用RAG；RAG在各失败类型中完成率最高且效率更优。
适用场景：生成代码测试失败需先定根因、用户反馈代码未处理某情况、初版遗漏需求、集成外部API或数据库、反复重试仍报同样错误等。
限制：四类失败并非总能清晰区分，不确定时默认用RAG；RAG效果依赖检索质量，闭源或文档缺失时代之以多模型推理；研究样本为25个GitHub项目，未必适用于嵌入式、GPU内核或特定DSL；渐进式提示增加延迟，简单明确任务可直接生成；自我批评无法发现未说明的隐含需求。