从需求到回归测试：降低代码生成幻觉的实战工作流
先把“幻觉”定义为可验证的问题
代码生成中的幻觉并不只是语法错误，更常见的是模型编造不存在的 SDK 方法、误用已废弃参数、假设项目中有某个服务，或修改了不该触碰的文件。要降低这类问题，关键不是反复要求“认真一点”，而是建立一套从需求、上下文、生成到验证的闭环。以下是一套适用于 Claude Code、Codex 和 OpenAI SDK 工作流的实际做法。
第一步：把任务拆成可验收的输入
每次让模型写代码前，先写一份简短的任务卡。它应明确目标文件、允许修改的目录、运行环境、依赖版本、接口输入输出，以及不可破坏的行为。例如，不要只说“增加用户导出功能”，而应说明导出路由位置、数据库表字段、日期格式、最大数据量、权限规则和现有测试文件位置。
- 提供事实来源：附上相关类型定义、现有接口、数据库 schema 和相邻模块，而不是让模型猜测。
- 写明边界：例如“不新增依赖”“仅修改 src/export 和对应测试”“不得改动鉴权中间件”。
- 定义验收条件：包括编译命令、测试命令、预期响应样例及错误处理要求。
上下文应优先使用仓库中的真实文件内容。对于大型项目，可先让模型只输出“需要阅读的文件清单和原因”，确认后再提供文件，避免一次塞入无关代码导致注意力分散。
第二步：要求先分析，再生成最小补丁
将一次性“直接实现”改为两阶段任务。第一轮要求模型列出实现计划、涉及文件、可能存在的不确定项，以及它依据了哪些现有函数。第二轮再要求输出最小改动方案。若它声称某个方法或配置存在，但无法指出文件和行号，应视为高风险信号，先补充上下文或人工核对。
提示词中可以加入明确约束：不得编造 API、依赖、环境变量或文件；信息不足时必须提出问题；所有调用必须来自提供的代码或官方文档。这会让模型把“不确定”显式暴露出来，而不是用看似合理的代码填补空白。
第三步：用结构化输出控制修改范围
不要让模型返回一大段混杂解释与代码的内容。要求其按固定顺序输出：修改文件列表、每个文件的修改理由、补丁内容、需要执行的命令、风险说明。对于工具调用型代理，还应限制其每轮最多修改的文件数，并要求每次写入后立即运行格式化、类型检查或局部测试。
在生产团队中，可将“新增依赖”“修改数据库迁移”“删除文件”“改动权限逻辑”设为人工确认点。模型即使生成了正确代码，也不应自动越过这些高影响操作。
第四步：把验证命令纳入生成循环
降低幻觉最有效的方式，是让代码接受真实环境的快速反馈。推荐顺序是：先运行格式化与静态检查，再执行类型检查，然后跑相关单元测试，最后进行接口级验证。失败后不要简单让模型“修复所有错误”，而要把完整错误日志、当前 diff 和原始验收条件一并传回，并限制它只处理本轮失败项。
- 编译失败时，优先确认导入路径、类型签名和依赖版本。
- 测试失败时，区分实现错误、测试假设过期与测试环境问题。
- 接口通过后，检查空值、权限不足、分页边界和重复请求等反例。
建议设置最多两到三轮自动修复。超过阈值仍失败时转人工审查，避免代理在错误假设上不断扩大改动范围。
第五步：按任务难度分层使用模型并控制成本
模型选择也会影响幻觉率。简单的文件定位、日志归类和测试补全可使用速度更快、成本更低的模型；涉及跨模块重构、复杂类型推理或安全逻辑时，再使用更强模型进行规划和最终审查。59API 提供 Claude Opus、Sonnet、Haiku、Fable 及 GPT 模型的按量访问，并兼容 Claude Code、Codex 和 OpenAI SDK。将 API Base URL 配置为 https://api.59api.com 后，团队可以在不改变常用工具链的前提下做模型分层，用较低成本保留原生官方质量模型的验证流程。
第六步：沉淀失败案例，形成团队规则
每次发现幻觉，都记录“模型错误假设、缺失上下文、最终拦截手段”三项内容。例如“误用旧版 ORM 方法”可转化为版本清单检查；“虚构内部服务地址”可转化为服务目录检索步骤。两周后回看这些记录，通常能发现最常缺失的项目知识，并将其加入任务模板或仓库说明。
当需求卡、上下文引用、最小补丁、自动验证和人工关卡成为固定流程后，AI 生成代码会从不可控的猜测变成可审计的协作。若你希望以较低成本接入多种主流模型并实践这套流程，可以注册 59API，先从一个有完整测试覆盖的小模块开始验证效果。