← सभी गाइड पर लौटें

从提示词到 CI：降低代码生成幻觉的生产实战指南

先定义什么是代码幻觉

代码生成中的幻觉不是单纯的语法错误，而是模型自信地引用不存在的 API、虚构依赖版本、误解项目约束，或给出无法在当前仓库运行的实现。生产环境中，最危险的情况通常是“看起来合理”：代码能通过局部审查，却绕过鉴权、破坏数据一致性，或在边界条件下失败。降低幻觉的目标不是让模型永远不犯错，而是把它限制在可验证、可回滚的工程流程里。

第一步：给模型可执行的上下文

不要只输入“帮我实现用户导出功能”。先提供任务边界：目标文件、现有接口、语言版本、允许使用的依赖、输入输出示例和验收条件。例如明确说明项目使用 Node.js 20、TypeScript 5、不得新增 npm 包、导出结果必须流式返回，并要求复用现有的权限中间件。上下文应来自仓库真实内容，而不是人工概述；优先让 Claude Code 或 Codex 读取 package.json、类型定义、相邻模块和测试文件。

• 限制修改范围：指定允许修改的目录和禁止触碰的配置文件。
• 提供事实来源：粘贴接口类型、数据库 schema 或官方文档片段，不要求模型凭记忆猜测。
• 写出验收标准：列出成功响应、失败响应、权限场景和性能上限。

第二步：把一次生成拆成四个关卡

将“直接写完整功能”改为规划、实现、审查、验证四步。先要求模型只输出实现计划和不确定项；确认计划后，再让它修改最少的文件。完成后，使用独立提示要求它审查自己的改动，重点寻找不存在的 API、未处理异常、类型逃逸和安全问题。最后，要求它执行或生成针对性的测试，而不是仅声称“应该可以运行”。这种分阶段方式会显著减少模型将猜测包装成结论的机会。

提示中可以加入一条硬规则：遇到仓库中无法确认的函数、配置或业务规则时，必须标注 UNKNOWN，并先请求文件或信息，不得自行编造。这比泛泛要求“不要幻觉”更容易被执行和审计。

第三步：让验证工具替代信任

在本地和 CI 中固定运行格式化、类型检查、单元测试、集成测试及安全扫描。对于 AI 修改的代码，额外检查依赖锁文件是否出现非必要变化、SQL 是否参数化、权限校验是否仍在请求入口执行。若项目支持，给关键路径增加契约测试：用真实接口 schema 校验请求和响应，能快速暴露模型虚构字段或错误参数。

• 编译层：运行 TypeScript、Go、Java 等语言的正式编译或静态检查。
• 行为层：为正常、空值、越权和重复请求至少各写一个测试。
• 变更层：人工查看 diff，确认模型没有顺手重构无关模块。

第四步：用多模型交叉审查控制成本

高难度设计可以由能力更强的模型完成，再用更经济的模型做测试补全和 diff 审查。59API 提供按量付费的 Claude Opus、Sonnet、Haiku、Fable 与 GPT 模型，API 基地址为 https://api.59api.com，并兼容 Claude Code、Codex 和任何 OpenAI SDK。开发团队可以保留现有工具链：用 Sonnet 或 GPT 生成实现，用 Haiku 批量检查 PR 和补测试，仅在架构决策时调用 Opus，从而避免每一步都使用高价模型。59API 使用官方质量模型而非降级版本，适合把“生成后验证”纳入日常 CI，而不是因成本放弃审查。

上线前的最小清单

上线前确认模型引用的每个库和方法都能在锁定版本中找到；确认测试覆盖新增分支；确认日志不含密钥和用户敏感数据；确认失败路径可观测且可回滚。把这些检查写成 PR 模板和 CI 门禁后，团队依赖的将是证据而非模型自信度。需要以较低成本接入多种原生模型并在现有 SDK 中实践这套流程时，可以注册 59API，按实际调用量开始验证。

मूल्य · दस्तावेज़