你给 Codex 丢了一个 FastAPI 服务文件它很快补出了几十个test_*.py。pytest -v一片绿但打开覆盖率报告未覆盖的行号依然集中在except块、if边界和外部回调里。更糟的是生产环境一个422校验错误直接崩了——因为 Codex 写的所有测试都只传了合法参数。测试数量多不代表测试有效。作为 ChatGPT Plus 或 Pro 用户如果你发现 Codex 生成的单元测试只围着已有代码打转说明你遇到了下面 4 个典型陷阱。1. 只围绕已有实现“翻译”测试异常分支永远是死角Codex 默认的补全逻辑是“看到函数体生成调用它的用例”。对于 FastAPI 接口它通常会照着路由函数里的try生成正常流程但完全忽略except里的逻辑。如何检查打开覆盖率报告htmlcov看红色行是否集中在raise HTTPException或except后面。如果是说明 Codex 没主动构造异常触发条件。真实场景你的 FastAPI 依赖项里有一个get_current_user如果 token 无效会抛出401。Codex 大概率只生成Authorization头正确的用例从不传fake_token。2. 断言过弱只验证“没报错”不验证“数据内容”这是最隐蔽的陷阱。Codex 常生成这种测试pythonresponse client.get(/items/1) assert response.status_code 200覆盖率算这行代码被执行了但业务覆盖是零——它没检查返回的id、price是否匹配数据库也没检查null字段的处理。如何检查全局搜索assert response.status_code 。如果这类断言占比超过 60%你的测试集是“假绿”。用 ChatGPT Plus 跑出来的覆盖率虚高变更时毫无安全感。3. Mock 满天飞关键依赖行为从未被验证在 FastAPI pytest 里为了测 Service 层Codex 会把db.session、redis_client、第三方 API 全用mocker.patch替换。这本身没问题但 Codex 往往只 Mock 成功返回值从不断言“外部依赖是否被正确调用”。如何检查看测试里有没有assert mock_save.call_count 1或mock_pay.assert_called_with(order_id...)。如果没有你的测试只验证了“Mock 对象存在”没验证业务交互逻辑。4. 没有先列业务边界AI 只能靠猜这是根源。不给 Codex 场景清单时它默认按“最常见的入参”生成测试。它不知道你的price字段不能为负数也不知道page_size最大限制是 100。如何检查看测试文件里有没有pytest.mark.parametrize。如果参数化测试寥寥无几说明 Codex 没被引导去覆盖边界和异常值。改法两个改变协作方式的提示词模板不要上来就让 Codex 写代码。先让它做“测试设计”。以下两个模板针对 ChatGPT Pro 和 Plus 的上下文长度做了优化可直接复制。模板 A设计阶段——让 Codex 先列场景和遗漏边界不写代码“我现在有一个 FastAPI 接口文件附上代码。请先不要写任何测试代码。请帮我列出针对这个接口的测试场景清单必须包含以下三类正常业务路径Happy Path的三种不同入参组合依赖项Depends失效时的异常路径401/403/404Pydantic 模型校验的边界条件空字符串、负整数、超长字段。清单中每个场景注明预期 HTTP 状态码和关键响应字段的断言点。”模板 B执行阶段——按场景补测试并说明验证意图“根据上一步的清单按顺序生成 pytest 测试用例。要求使用TestClient发送请求每个测试函数的 docstring 必须写明‘该用例验证了哪个业务规则’对于所有 Mock 对象必须使用assert_called_once_with校验关键参数不要忽略422和500的构造用例。”验证用“突变测试”心态看结果改完提示词后手动做两件事手动改源码把接口里一个if条件反转如if not user:改成if user:看测试是否会失败。如果测试全绿说明断言依然太弱。检查pytest --cov --branch重点关注Missing列是否集中在逻辑判断分支。AI 生成的测试本质是“辅助脚手架”ChatGPT Plus 和 Pro 提供的长上下文能力更适合让它记住你定义的全局测试规范而不是直接生成所有用例。永远记得不要把生产数据库连接串、用户隐私或内部密钥粘贴到对话框本地脱敏后再给 Codex 分析。