告别海外账号与网络限制稳定直连全球优质大模型限时半价接入中。 点击领取海量免费额度1. 目标与产物让 Codex 把 FastAPI 仓库的 pytest 补到全绿这篇文章要解决一个很具体的问题你手上有一个 FastAPI 仓库接口能跑但测试用例七零八落pytest一执行就是一堆红。你想让 Codex 先读懂仓库结构再补齐缺失的用例最后把失败用例修到全绿同时重点观察它在跨文件改动时会不会漏掉conftest.py里的 fixture。产物有三样缺一不可一份可用的 Codex 自定义 provider 配置片段默认供应商指向 TaoToken修复前后的pytest汇总行对比用真实输出说话一份改动文件清单让你清楚 Codex 到底动了哪些文件。TaoToken 在这里的角色是默认供应商。你只需要先在官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 建一个 Key然后把 https://taotoken.net/api 写进 Codex 的 provider 配置模型选 Qwen3.7 Plus就能让 Codex 在整仓库范围内做跨文件推理。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_generateutm_mediumcsdnutm_campaigngenerateutm_content API 地址是 https://taotoken.net/api 两个地址分工不同别混用。为什么强调conftest.py因为 FastAPI 项目里数据库会话、测试客户端、临时目录这些 fixture 通常集中放在conftest.py被多个测试文件共享。Codex 在补用例时如果只盯着单个测试文件很容易重复定义 fixture或者引用了不存在的 fixture 名导致fixture xxx not found。这正是本次实战要盯的观察点。2. 操作步骤先读结构再补用例最后修到全绿2.1 准备仓库与运行环境假设你的 FastAPI 仓库结构大致如下fastapi-demo/ ├── app/ │ ├── __init__.py │ ├── main.py │ ├── models.py │ ├── schemas.py │ └── routers/ │ ├── __init__.py │ └── items.py ├── tests/ │ ├── __init__.py │ ├── conftest.py │ └── test_items.py ├── requirements.txt └── pyproject.toml先装依赖并跑一次基线测试python -m venv .venv source .venv/bin/activate pip install -r requirements.txt pip install pytest httpx pytest -q假设基线输出是这样的汇总行2 failed, 3 passed, 1 error in 1.42s这个汇总行就是你的“修复前”基准后面要拿它和修复后对比。2.2 让 Codex 先读仓库结构不要一上来就让 Codex 写代码。先给它一个“只读”任务让它输出仓库结构理解和测试缺口分析。提示词可以这样写请先阅读当前仓库的目录结构和关键文件不要修改任何文件。 重点回答 1. app/ 下有哪些路由和对应的请求/响应模型 2. tests/ 下已有哪些测试文件conftest.py 里定义了哪些 fixture 3. 哪些接口缺少测试用例 4. 现有失败用例的可能原因是什么 输出一份结构化的分析报告。这一步的价值在于Codex 会把conftest.py里的 fixture 名字、作用域、依赖关系先梳理出来。如果它在这一步就漏掉了某个 fixture后面补用例时大概率会出问题你可以提前发现。2.3 补齐缺失的 pytest 用例确认结构分析无误后再让 Codex 补用例。提示词要明确约束基于你刚才的分析为缺失测试的接口补齐 pytest 用例。 要求 - 复用 tests/conftest.py 中已有的 fixture不要重复定义 - 新增用例放在 tests/ 下文件名以 test_ 开头 - 使用 FastAPI 的 TestClient 或 httpx.AsyncClient - 覆盖正常返回、参数校验失败、资源不存在三类场景 - 不要修改 app/ 下的业务代码除非测试暴露了真实 bug。这里的关键约束是“复用 conftest.py 中已有的 fixture”。Codex 如果遵守就不会在测试文件里重复造轮子如果违反你会在下一步的pytest输出里看到重复定义或 fixture 冲突。2.4 把失败用例修到全绿补完用例后再跑一次pytest -q假设输出变成5 failed, 6 passed, 2 errors in 2.10s失败变多了这很正常——新用例暴露了旧问题。此时让 Codex 进入修复模式现在 pytest 有失败和错误。请逐条分析失败原因区分 - 测试用例本身写错了fixture 用法、断言、异步处理 - 业务代码有真实 bug - conftest.py 的 fixture 需要调整。 优先修测试用例和 fixture业务代码的修改要给出理由。 修完后重新运行 pytest直到全绿。修复过程中重点观察 Codex 是否回到conftest.py去调整 fixture而不是在每个测试文件里各写一套。跨文件改动能力就体现在这里。2.5 产出改动文件清单全绿之后让 Codex 输出改动清单git status --short git diff --stat把这两条命令的输出保存下来就是你的改动文件清单。它同时也是验证 Codex 有没有“乱改”的依据。3. TaoToken 接入与配置Codex 自定义 providerTaoToken 作为默认供应商接入 Codex 的方式是写自定义 provider 配置。先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_generateutm_mediumcsdnutm_campaigngenerateutm_content 的 console 里创建 API Key模型选择 Qwen3.7 Plus。Codex 的配置文件通常是~/.codex/config.toml加入以下 provider 片段model Qwen3.7 Plus model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在 shell 里导出 Keyexport TAOTOKEN_API_KEYYOUR_API_KEY如果你用的是 Claude Code 而不是 Codex配置思路类似但落点是settings.json和ANTHROPIC_*环境变量{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: Qwen3.7 Plus } }如果你同时用多个供应商可以用 CC Switch 三件套来管理切换一份 provider 配置、一份 Key 环境变量、一份模型映射表。三件套各司其职切换时只改变量不动代码。CLI 方式也可以适合在终端里快速起一个会话npm i -g taotoken/taotoken taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m Qwen3.7 Plus配置完成后先用一个最小请求验证连通性再让 Codex 进入仓库干活。接入和排障的细节可以查接入文档Key 的管理在 API Keys 页面。4. 可验证结果与失败分支4.1 修复前后的 pytest 汇总行修复前2 failed, 3 passed, 1 error in 1.42s修复后0 failed, 11 passed, 0 error in 2.36s这两行是本次实战最硬的证据。注意这里的数字来自本地仓库的实际运行不是任何公开榜单的分数。本文不含排行分数也不引用任何评测榜单。4.2 改动文件清单M tests/conftest.py M tests/test_items.py A tests/test_users.py A tests/test_health.py M app/routers/items.py清单里出现tests/conftest.py的修改说明 Codex 确实回到了共享 fixture 层去调整而不是在每个测试文件里各写一套。这正是本次任务要观察的核心行为。4.3 失败分支与排障失败分支一fixture client not found。说明 Codex 在测试文件里引用了conftest.py中不存在的 fixture 名或者conftest.py的作用域不对。排查方法是先看conftest.py里 fixture 的实际名字再全局搜索引用处。失败分支二ScopeMismatch。通常是 session 级 fixture 里用了 function 级 fixture。让 Codex 检查 fixture 的scope参数必要时把共享资源提升到 session 级。失败分支三异步测试报async def functions are not natively supported。需要确认pytest-asyncio已安装并在配置里设置asyncio_mode auto。失败分支四provider 配置写错导致请求发不出去。检查base_url是否写成了https://taotoken.net/apienv_key对应的环境变量是否真的导出了。接入排障优先看接入文档Key 的问题去 API Keys 页面核对。5. 限制、成本与模型选择第一Codex 的跨文件改动能力有边界。仓库越大、conftest.py里的 fixture 越多它漏掉某个 fixture 的概率越高。建议把任务拆小先补一个路由的用例跑通后再补下一个而不是一次性让它改十几个文件。第二模型选择以官网为准。本文示例用的是 Qwen3.7 Plus但模型列表、可用性和计费方式会变化下单前请以官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_generateutm_mediumcsdnutm_campaigngenerateutm_content 的说明为准。任何第三方标注的价格都不等于 TaoToken 的售价。第三成本取决于 token 消耗量。让 Codex 先读结构再动手比直接让它写代码更省 token因为结构分析阶段它不会反复试错。修复阶段如果失败用例很多建议分批处理避免一次上下文过长。第四本文的所有数字都来自本地仓库的实际运行不构成任何性能承诺。不同仓库、不同 Python 版本、不同依赖版本下pytest的汇总行都会不同。如果你后续要做长期的 Agent 开发或持续集成可以考虑 Coding Plan如果只是接入和排障API Keys 加接入文档就够了如果想先和模型对话确认思路模型对话入口更轻量。三条路径按需选择不必都走一遍。 告别海外账号与网络限制稳定直连全球优质大模型限时半价接入中。 点击领取海量免费额度