Codex 生成代码不等于交付用测试和审查识别 AI 编程幻觉OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。AI 编程最危险的时刻往往不是它明显报错而是代码看起来非常专业类型标注齐全、注释流畅、函数命名合理甚至还能跑起来但业务含义是错的。这篇文章不用抽象口号而是用一个折扣计算函数做边界实测先明确业务契约再检查差异、运行测试、做人工裁决。最终目标不是证明 Codex 会不会犯错而是建立一条“即使 AI 犯错错误也难以进入交付物”的工程链路。来源与证据知识依据RuyiBookCourse 中《Codex 智能体工程》“AI 代码审查与责任边界”和“用 Codex 建立 Python 交付闭环”用于确定审查、测试和人工责任边界。实践依据本文的折扣函数与边界测试已在本地执行pytest结果为3 passed不是仅凭代码外观推断正确性。官方资料OpenAI Codex 开发者文档。什么才算 AI 编程幻觉在编码场景里幻觉不只是假造不存在的 API。以下情况都值得警惕编造仓库中并不存在的函数、配置或文件路径误解金额、时间、权限等业务语义为了让测试变绿而删除关键断言修改了需求之外的模块给出“已验证”结论却没有运行对应命令忽略版本差异套用过期参数把静态检查通过等同于业务正确。这些问题有一个共同点输出形式像答案但证据不足。先写业务契约再让 AI 写代码假设需求是“计算折扣后的价格”至少要先确定price不能为负数discount_rate使用0到1的比例20% 折扣表示支付原价的 80%金额统一保留两位小数非法输入必须明确失败。如果只说“写一个折扣函数”AI 可能把discount_rate20理解成 20%也可能把折扣金额直接累加到总价。需求没有表达清楚时错误不全是模型问题还是任务契约把关键判断权让了出去。一个看起来合理的错误实现fromdecimalimportDecimaldeffinal_price(price:Decimal,discount_rate:Decimal)-Decimal:returnprice*discount_rate函数能运行类型也没有报错。但输入100和0.20时得到20这到底是折扣金额还是最终应付金额如果业务要的是最终价格正确结果应该是80。这种错误靠语法检查发现不了因为代码在语法层面完全成立。修复后的实现fromdecimalimportDecimaldeffinal_price(price:Decimal,discount_rate:Decimal)-Decimal:ifprice0:raiseValueError(price must be non-negative)ifnotDecimal(0)discount_rateDecimal(1):raiseValueError(discount_rate must be between 0 and 1)return(price*(Decimal(1)-discount_rate)).quantize(Decimal(0.01))这里没有追求复杂而是把业务边界直接写进代码输入范围明确公式明确金额精度明确。测试不能只覆盖快乐路径第一条测试验证核心业务含义fromdecimalimportDecimalfromdiscountimportfinal_pricedeftest_twenty_percent_discount()-None:assert(final_price(Decimal(100),Decimal(0.20))Decimal(80.00))再补充非法边界importpytestpytest.mark.parametrize(rate,[Decimal(-0.01),Decimal(1.01)],)deftest_rejects_invalid_discount_rate(rate:Decimal)-None:withpytest.raises(ValueError):final_price(Decimal(100),rate)本地真实运行$ python -m pytest -q test_discount.py ... [100%] 3 passed三条测试并不多却分别保护了核心结果与上下边界。测试的价值不在数量而在是否对应真实风险。测试通过仍然不代表可以交付AI 可能通过改变测试来“解决”失败。例如把期望值从80.00改为20.00流水线会变绿但业务错误被合法化了。因此测试结果必须和代码差异一起审查gitdiff-- discount.py test_discount.py python-mpytest-qtest_discount.py审查时至少回答代码变化是否只在授权范围内测试断言是否仍然表达原始业务要求是否新增了没有解释的依赖或网络访问是否处理了边界值和异常路径命令输出能否证明文章声称的结果用四层测试覆盖不同风险真实项目可以把验证分成四层单元测试验证纯业务规则和边界契约测试验证模块、API 或制品字段的兼容性集成测试验证数据库、文件系统和外部适配器端到端测试验证少量关键业务闭环。不要为了显得“工程化”而把所有情况都塞进端到端测试。测试越接近底层业务规则通常越快、越稳定也越容易定位问题。端到端测试只保留最关键的成功与失败路径。建立可审计的验证记录让 Codex 完成任务时不要只要一句“已修复”。要求它保留修改了哪些文件差异为什么符合需求新增或更新了哪些测试实际运行的命令和退出码关键输出尚存风险哪些判断需要人工批准。一个可用的完成报告可以是修改discount.py、test_discount.py 验证python -m pytest -q test_discount.py 结果3 passed退出码 0 未验证未连接真实订单数据库 人工检查确认 discount_rate 的业务定义为比例这比“测试都通过了”多不了几行却能让下一位审查者知道证据覆盖到哪里、没有覆盖到哪里。权限边界也是幻觉控制的一部分如果 AI 可以任意修改文件、访问网络、读取凭据并直接发布那么一次错误判断的影响会被放大。更稳妥的做法是按任务开放最小权限代码审查默认只读本地开发只写当前工作区网络访问按域名或任务开放凭据不进入提示词、日志和测试夹具发布、付款、删除数据等高影响动作保留人工批准测试失败时停止而不是自动放宽边界。权限不是用来阻止 AI 工作而是把错误限制在可恢复范围内。三类常见误区误区一让同一个 AI 生成、审查并批准生成者天然容易沿用自己的假设。至少要把“生成”和“最终裁决”分开关键变更由人确认。误区二没有发现就等于没有问题一次 AI 审查没有输出发现只能说明它在当前上下文中没有识别到问题不能证明系统安全或业务完全正确。误区三用 Linter 重复替代业务审查格式、未使用变量和简单类型问题交给确定性工具AI 审查应关注跨文件语义、错误路径、权限和需求偏差。可以直接复用的交付门每次 AI 编程完成后按顺序检查固定需求和不可改变的边界查看最终差异而不是只看 AI 摘要运行聚焦测试运行静态检查和必要的完整测试检查日志中是否包含秘密记录未验证项由责任人决定是否发布。其中任何一步缺少证据就应该把状态写成“未验证”或“需要确认”而不是“完成”。总结Codex 生成代码不是交付终点而是验证流程的输入。识别 AI 编程幻觉的核心不是猜模型什么时候会错而是用业务契约、差异审查、分层测试、最小权限和人工批准建立证据链。只要每个结论都能追溯到代码、命令输出和责任人即使模型偶尔犯错错误也很难悄悄穿过发布门。参考资料RuyiBookCourse《AI 代码审查与责任边界》“修复与验证”RuyiBookCourse《用 Codex 建立 Python 交付闭环》“测试金字塔要对应风险层级”OpenAI Codex 文档https://developers.openai.com/codex/