AI 生成代码不符合预期时如何改进并提效？

先把“不符合预期”变成具体、可复现的差异，再判断是需求、上下文、实现还是验证出了问题。向AI提供目标、实际行为、最小复现、相关代码与错误输出，让它修正对应原因；反复追加“再好一点”或整段重写，通常会增加试错。

提效的关键是减少无效生成：用现有模式和验收例子缩小范围，小步修改后立即检查，保留已证实的结论与失败原因。需要时换方案或人工处理局部，不必让模型在同一个错误思路里无限循环。

需求没讲清时，明确输入输出、对象和边界，例如“空列表显示什么”“新增字段放在哪里”；上下文不对时，补调用方、接口类型、相似实现和项目版本，检查是否读了旧文件或错误模块。

实现错误时，用失败输入、堆栈或测试定位具体分支。引用不存在的API，先查当前官方文档与依赖版本；性能问题则给出测量和热点，而不是只要求“优化”。如果测试期望写错，应先回到需求核对，不能为了变绿去迁就错误断言。

假设AI实现的订单筛选会清空分页条件，可以说明：原来按状态切换时应回到第一页，但页大小保持不变；现在页大小也被重置。附触发步骤、当前状态结构和对应处理函数，要求沿现有更新方式做局部修正，并验证分页与筛选组合。

这种反馈把结果差异、原因线索和验证方式连起来，比“逻辑不对，重写”更容易收敛。若原因未知，先让AI列出可用证据和少量假设，再用检查排除；不是每次都需要另写设计文档。

把常用命令、目录边界和稳定代码模式保存在项目可发现的位置；复杂任务拆成可独立验证的步骤，输入里明确本次非目标。保留小范围diff，出现退化时选择性撤回本次变更，保护其他已有修改。

验证根据影响选择：局部界面看实际交互，纯函数看边界输入，跨模块接口看契约和集成。AI生成测试可以辅助，但结果还要有独立期望；同一模型的解释不能代替运行结果。

连续修不好要不要换模型？ 先检查错误是否来自缺证据、错误约束或环境。模型能力确实不足时再换；缺少关键代码时，换大模型也可能只是更流畅地猜错。

如何评价提效？ 看解决时间、重试、返工和遗留缺陷，不能只看生成速度。

国内：JavaGuide：Spec Coding规范驱动编程：借鉴目标、约束和验收示例的组织方法，说明正文中如何明确输入输出与边界，减少需求层的偏差。
国内：zero2Agent：工程级代码上下文与增量分析：参考代码上下文与依赖分析的方法，说明正文中补充调用方、接口类型、相似实现及版本信息的做法。
国内：WeThinkIn：编码Agent运行架构：采用工具执行与反馈分层的职责划分，说明正文中生成结果、运行错误及验证证据应如何分别检查。
国外：Anthropic：Best practices for Claude Code：借鉴提供可执行检查与具体错误的反馈方式，组织正文中订单筛选问题的触发步骤、局部修复和验证示例。
国外：Aider：Repository map：参考符号地图与按需读取的方法，说明正文中如何提供相关代码与项目模式，避免让 AI 在缺少关键上下文时猜测。