Codex API 实战指南:从命令行到 VS Code 的 Vibe Coding 工作流

Codex API 实战指南:从命令行到 VS Code 的 Vibe Coding 工作流
1. 项目概述Codex 与 Vibe Coding 不是“新模型”而是开发者工作流的重构Codex 这个名字2023年之前在程序员圈子里几乎无人不晓——它是 OpenAI 在 2021 年底发布的、专为代码生成而微调的 GPT-3 变体底层架构仍是 transformer但训练语料全部来自 GitHub 上数十亿行公开代码。它不是独立产品而是一套 API 能力它没有网页界面不提供“登录即用”的傻瓜式体验它的核心价值从来不在“写 hello world”而在于把自然语言指令精准映射为可运行、可调试、可集成的生产级代码片段。很多人看到“Codex 入门教程”就下意识点开结果发现教程里全是 curl 命令、API Key 配置、JSON 请求体构造——这不是门槛高而是它压根就不是给“零基础小白”设计的入门玩具而是给已有 Python/JS/Shell 基础、正在被重复性编码拖慢交付节奏的工程师准备的“第二双手”。而 Vibe Coding这个词根本不是 OpenAI 官方术语也不是某个开源项目的正式名称。它是在 2024 年中后期由一批国内独立开发者和小团队在实践 Codex API 接入过程中自发形成的社区黑话。所谓“vibe”指的是一种高度依赖上下文感知、强调意图对齐、弱化语法细节、追求开发直觉流畅度的工作状态。“Vibe Coding” 的本质是把 Codex 当作一个嵌入本地开发环境的“智能协作者”而不是一个远程调用的“代码生成器”。它要求你熟悉自己项目的目录结构和命名习惯比如你知道utils/下永远放工具函数core/下是业务主逻辑能用一句话精准描述“我此刻想做什么”而不是罗列技术名词说“给用户注册接口加手机号格式校验”比说“用正则匹配 11 位数字并调用 django.core.validators”更符合 vibe接受生成结果需要人工 review 和微调但拒绝从头手写样板代码。所以“全网最详细的 Codex 入门教程手把手教你玩转 Vibe Coding”这个标题真正要解决的问题不是“怎么装软件”而是如何把一个纯文本 API变成你 VS Code 里按 CtrlEnter 就能弹出精准建议、改两行就能跑通的“活搭档”。它面向的是已经会写 Python 函数、能看懂 Git diff、知道 pip install 是干啥的那群人——不是教你怎么安装 Python而是教你怎么让 Codex 成为你写 Python 时的“条件反射”。关键词里的 “gpt-5.3-codex” 实际上是个误导性标签OpenAI 官方从未发布过该型号网络上所有提及此名称的教程基本都指向对code-davinci-002或gpt-3.5-turbo-instruct的误标或魔改封装。真正的 Codex API 核心模型只有两个code-davinci-002已逐步退役和当前主力gpt-3.5-turbo-instruct虽名含 turbo但专为补全类任务优化非聊天模型。理解这一点是避开 90% 假教程的第一步。提示如果你在搜索“codex安装”“vibe coding下载”时页面跳转到某个非 openai.com 域名的“一键安装包”或“中文汉化版”请立刻关闭。Codex 没有客户端、没有安装包、没有离线版本。所有声称提供“codex离线安装包”的链接要么是钓鱼页面要么是把其他 LLM 模型包装成 Codex 名义的误导行为。它的唯一合法接入方式是通过 OpenAI 官方 API使用你的 API Key 发送标准 HTTP 请求。2. 核心原理拆解Codex 不是“写代码的 AI”而是“代码世界的翻译官”要真正用好 Codex必须扔掉“AI 写代码”的幻想建立“翻译官”的认知模型。Codex 的本质是把人类用自然语言表达的开发意图intent翻译成符合特定编程语言语法、符合当前项目上下文约束、符合工程规范的可执行代码artifact。这个过程包含三个不可跳过的层级2.1 意图层为什么“写个登录接口”不如“给 user_service 添加 JWT 认证入口”Codex 对模糊指令的容忍度极低。输入 “写个登录接口”它可能返回一个 Flask 示例、一个 FastAPI 片段、甚至一段 Node.js Express 代码——因为它无法判断你的技术栈。而输入 “在user_service/auth.py中为login_user函数添加 JWT token 生成逻辑token 有效期设为 24 小时密钥从os.environ[JWT_SECRET]读取”它就能精准定位文件、函数、变量并生成可直接粘贴的代码。这背后是 Codex 的 prompt engineering 机制在起作用它把你的输入当作“补全提示prompt”然后基于海量代码训练出的概率分布预测下一个最可能的 token 序列。你的输入越像一个真实开发者在 IDE 里写注释时的自言自语Codex 的输出就越接近你想要的结果。这就是“vibe”的来源——它依赖你作为开发者的专业语感而不是替代你。2.2 语法层Codex 的“母语”是 Python但能“说”十几种语言官方文档明确列出 Codex 支持的语言包括Python、JavaScript/TypeScript、Go、Ruby、Perl、PHP、Rust、SQL、Shell、C#、Java、C/C、Swift、Kotlin、Scala、Haskell、Lua、R、Fortran、COBOL、Pascal、Ada、Erlang、Elixir、Clojure、F#、OCaml、Julia、Dart、Objective-C、Groovy、VB.NET、PowerShell、Terraform、Ansible、Dockerfile、Kubernetes YAML、HTML、CSS、LaTeX。但支持 ≠ 同等质量。实测下来Python 的生成准确率稳定在 82% 以上指生成代码无语法错误且逻辑基本正确JavaScript 次之约 76%而像 COBOL 或 Fortran 这类小众语言错误率超过 40%常出现虚构函数名或过时语法。原因很简单Codex 的训练数据中Python 代码占比超 35%JavaScript 约 22%其余语言呈断崖式下降。因此当你看到“codex支持所有编程语言”的宣传时要自动在心里打个折——它支持“识别和生成”但不保证“工业级可用”。2.3 上下文层为什么 Codex 需要你提供“前情提要”Codex API 的请求体中prompt字段不是单行指令而是一段带缩进、带注释、带部分已有代码的“上下文快照”。例如你想让 Codex 续写一个函数最佳做法不是只发函数名而是把整个函数签名、docstring、以及你已经写好的前几行比如参数校验部分一起发过去。这是因为 Codex 的上下文窗口有限code-davinci-002为 8000 tokensgpt-3.5-turbo-instruct为 4096 tokens它无法“记住”你上一次的请求。每一次调用都是全新的、孤立的翻译任务。所以“vibe coding”的核心技巧之一就是学会“喂上下文”在 VS Code 插件里它会自动截取光标所在函数的前后 20 行在命令行工具里你需要用cat file.py | head -n 50手动拼接。这解释了为什么很多教程强调“vibe coding 一人团队项目开发实战”——因为只有当你完全掌控项目结构、能快速提取关键上下文时这种工作流才真正高效。注意网络热词里反复出现的 “codex设置中文不生效”根源就在这里。Codex 的 tokenizer 是基于英文语料训练的对中文分词效果差。当你输入大段中文描述时它实际看到的是一堆低频 token导致注意力机制失效。正确做法是用中文写需求但用英文写函数名、变量名、注释关键词如# Validate phone number format形成“中英混排 prompt”这是社区验证最有效的 workaround。3. 实操环境搭建从零配置一个可立即使用的 Codex 开发终端别被“openai注册教程”“api key获取方法”这类标题吓住。整个流程熟练后 3 分钟内可完成。关键不是步骤多而是每一步背后的“为什么”必须清晰。下面以 macOS/Linux 为例Windows 用户请将pip3替换为py -m pip路径分隔符\替换为/全程使用原生命令行不依赖任何图形化安装包。3.1 第一步确认 Python 环境——不是“安装 Python”而是“确认你用的是哪个 Python”很多新手卡在第一步不是因为不会安装而是因为系统里存在多个 Python 版本系统自带的、Homebrew 装的、pyenv 管理的导致 pip 安装的包在另一个 Python 解释器里找不到。执行以下命令which python3 python3 --version which pip3理想输出应类似/usr/local/bin/python3 Python 3.11.8 /usr/local/bin/pip3如果which python3返回/usr/bin/python3macOS 系统自带强烈建议不要用它。系统 Python 受 SIP 保护pip 安装易失败且版本老旧macOS 14 自带的是 3.9。正确做法是用 Homebrew 重装brew install python3.11 # 此时 which python3 应返回 /opt/homebrew/bin/python3Apple Silicon或 /usr/local/bin/python3Intel实操心得我踩过的最大坑是某次用sudo pip3 install openai强行往系统 Python 里装包结果导致pip3 list显示 openai 已安装但python3 -c import openai却报ModuleNotFoundError。原因sudo pip3安装到了/Library/Python/3.9/site-packages/而python3默认查找/usr/lib/python3.9/site-packages/。解决方案永远是用which python3找到你的主 Python然后用对应的pip3安装。3.2 第二步获取并安全存储 OpenAI API Key——不是“复制粘贴”而是“环境变量隔离”访问 https://platform.openai.com/api-keys点击 “Create new secret key”复制生成的 key形如sk-...。绝对不要把它硬编码在 Python 脚本里正确做法是存入 shell 环境变量# 编辑你的 shell 配置文件zsh 用户编辑 ~/.zshrcbash 用户编辑 ~/.bash_profile echo export OPENAI_API_KEYsk-你的key ~/.zshrc source ~/.zshrc # 验证是否生效 echo $OPENAI_API_KEY # 应输出你的 key且不带引号为什么必须用环境变量因为避免代码泄露.gitignore可以忽略.env文件但无法阻止你一不小心把api_key sk-...提交到 GitHub多环境切换你在本地用sk-dev-xxx测试服用sk-test-yyy只需改一行环境变量符合 OpenAI SDK 最佳实践openaiPython 包会自动读取OPENAI_API_KEY环境变量无需在代码里client OpenAI(api_key...)。提示网络热词里高频出现的 “openai api key分享”是严重违规行为。每个 key 绑定账户、有调用配额、可被随时吊销。分享 key 等同于分享你的银行账户密码。所有提供“免费 key”的网站要么是钓鱼要么是盗用他人 key 的黑产。3.3 第三步安装核心依赖——只装两个包但选对版本是关键执行pip3 install openai1.35.1 python-dotenv1.0.1这里锁定了两个关键版本openai1.35.1这是最后一个全面支持code-davinci-002且兼容gpt-3.5-turbo-instruct的稳定版。新版 SDK1.40已移除对旧 Codex 模型的显式支持强制转向 chat 模型会破坏原有工作流。python-dotenv1.0.1用于加载.env文件虽然我们用环境变量但后续扩展如多模型切换会用到。验证安装python3 -c import openai; print(openai.__version__) # 应输出 1.35.13.4 第四步编写第一个 Codex 调用脚本——不是“Hello World”而是“真实场景模拟”创建文件codex_first.pyimport openai import os # 1. 从环境变量读取 keySDK 自动处理此处仅为演示 client openai.OpenAI() # 2. 构造一个真实的开发 prompt # 注意这不是“写个排序函数”而是模拟你在 debug 时的真实需求 prompt # Python 3.11 # 项目电商后台订单服务 # 文件order_service/utils.py # 需求写一个函数接收订单 ID 列表批量查询数据库并返回订单状态字典 # 要求 # - 使用 SQLAlchemy ORMsession 已通过 dependency 注入 # - 查询字段id, status, created_at # - 返回格式{order_id: {status: paid, created_at: datetime}} # - 忽略不存在的 order_id不报错 def get_orders_status(order_ids: List[str]) - Dict[str, Dict]: # 3. 调用 Codex API注意model 参数必须精确 response client.completions.create( modelgpt-3.5-turbo-instruct, # 关键不是 gpt-3.5-turbo promptprompt, temperature0.2, # 低温度保证确定性 max_tokens300, # 预估生成长度避免截断 top_p1.0, frequency_penalty0.0, presence_penalty0.0, ) # 4. 提取并打印结果 generated_code response.choices[0].text.strip() print(Codex 生成的代码) print(generated_code)运行python3 codex_first.py你会看到一段结构清晰、带类型注解、符合 SQLAlchemy 最佳实践的 Python 代码。它甚至会自动 importList,Dict,datetime—— 因为 prompt 里写了List[str]和Dict[str, Dict]Codex 从上下文推断出了所需模块。实操心得第一次运行如果报错openai.RateLimitError别慌。这是 OpenAI 的免费额度用完了新账号默认 $5 试用金约够 500 次调用。解决方案不是找“免费 key”而是去 https://platform.openai.com/account/billing/overview 绑定信用卡仅用于超限计费不收年费或者降低max_tokens到 150 先测试。我建议新手先用temperature0.0完全确定性跑 10 次感受它的风格再逐步放开。4. Vibe Coding 工作流落地从命令行到 VS Code 插件的无缝衔接“手把手教你玩转 Vibe Coding”的核心是把 Codex API 调用变成你日常开发中“肌肉记忆”的一部分。这分为三个阶段命令行快速验证 → 本地脚本自动化 → IDE 深度集成。每个阶段解决不同痛点。4.1 阶段一codex-cli —— 5 行命令搞定任意文件补全很多人以为 Codex 必须写 Python 脚本其实用curl一行就能调。但为了可复用我写了一个极简的 Bash 脚本codex-cli#!/bin/bash # 保存为 /usr/local/bin/codex-clichmod x if [ $# -eq 0 ]; then echo 用法: codex-cli 文件路径 [行号] exit 1 fi FILE$1 LINE${2:-$(wc -l $FILE)} # 默认取最后一行 # 提取文件前 LINE 行作为 prompt 上下文 PROMPT$(head -n $LINE $FILE | sed s/^/# /)$\n# 请续写 # 调用 API使用 jq 解析 JSON需提前 brew install jq RESPONSE$(curl -s https://api.openai.com/v1/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $OPENAI_API_KEY \ -d { model: gpt-3.5-turbo-instruct, prompt: ${PROMPT}, max_tokens: 250, temperature: 0.1 } | jq -r .choices[0].text) echo $RESPONSE用法示例# 续写当前文件最后一行 codex-cli my_script.py # 续写第 42 行之后的内容光标停在 42 行末尾时 codex-cli my_script.py 42这个脚本的价值在于它把“上下文提取”自动化了。你不再需要手动复制粘贴代码片段head -n就是你的“智能剪刀”。我每天用它补全日志打印、异常处理、单元测试 setup平均每次节省 30 秒——一年就是 2.5 小时。4.2 阶段二VS Code 插件深度定制——不是装插件而是改插件VS Code 商店里有几十个 “Codex” 插件但 90% 都是调用gpt-3.5-turbo聊天模型生成的代码像作文不像程序。真正做 Vibe Coding必须用支持completions接口的插件。我推荐 fork 并修改 TabNine 的开源版本或使用轻量级的 CodeWhisperer AWS 提供免费支持 Codex 类似模式。但更推荐的做法是自己写一个 20 行的 VS Code 插件。核心逻辑只有三步监听editor.onDidChangeTextDocument事件捕获用户输入当检测到用户输入# TODO:或# FIXME:时自动提取光标所在函数的上下文调用 Codex API将生成结果插入光标位置。关键代码片段extension.jsvscode.workspace.onDidChangeTextDocument(async (e) { const editor vscode.window.activeTextEditor; if (!editor || e.document ! editor.document) return; const cursorPos editor.selection.active; const lineText e.document.lineAt(cursorPos).text; // 触发条件行首有 TODO 且光标在行尾 if (lineText.trim().startsWith(# TODO:) cursorPos.character lineText.length) { const context await extractFunctionContext(e.document, cursorPos); const completion await callCodexAPI(context); editor.edit(editBuilder { editBuilder.insert(cursorPos, \n completion); }); } });extractFunctionContext函数会向上扫描找到最近的def或class向下扫描到def或空行提取完整块。这就是“vibe”的技术实现——它不等你按快捷键而是在你写下# TODO:的瞬间就预判你要什么。4.3 阶段三构建个人 Codex Prompt 库——不是背模板而是建“开发方言词典”所有高效 Vibe Coding 者都有一个私有的prompts.md文件里面不是通用模板而是针对自己项目定制的“方言”。例如## Django Model 字段生成 # 用法在 models.py 中光标放在 class 后输入此 prompt # prompt: # Django 4.2, Python 3.11 # 项目SaaS 客户管理 # 文件customers/models.py # 需求为 Customer 模型添加字段 # 要求 # - name: CharField, max_length100, db_indexTrue # - email: EmailField, uniqueTrue, nullTrue # - is_active: BooleanField, defaultTrue # - created_at: DateTimeField, auto_now_addTrue # - updated_at: DateTimeField, auto_nowTrue # 请生成完整的 Customer 模型定义包含 Meta 类和 __str__ 方法 ## FastAPI 路由错误处理 # 用法在 routers/user.py 中光标放在路由函数内输入此 prompt # prompt: # FastAPI 0.104, Python 3.11 # 项目用户中心 API # 文件routers/user.py # 需求为 get_user_by_id 路由添加 404 错误处理 # 要求 # - 如果 user_id 不存在抛出 HTTPException(status_code404, detailUser not found) # - 使用 try/except 包裹数据库查询 # - 保持原有函数签名不变 # 请只返回 try/except 块不要重复函数定义 这个库的价值在于它把“自然语言需求”标准化为“可复用的 prompt 片段”。新人加入团队不用从头学 Codex只要 clone 这个prompts.md就能立刻产出符合团队风格的代码。这才是“一人团队项目开发实战”的底层支撑。注意网络热词里 “vibe coding除了mcp和skill还有什么”其中 MCPModel Control Protocol和 Skill 是某些商业 IDE 插件的私有概念与 Codex 无关。真正的 Vibe Coding只依赖三个东西你的领域知识、Codex 的 prompt 工程能力、以及一套属于你自己的上下文提取逻辑。别被营销术语带偏。5. 常见问题排查与避坑指南那些官方文档不会告诉你的真相在真实项目中用 Codex90% 的问题不是 API 调不通而是“生成结果不符合预期”。以下是我在 37 个不同项目中总结的 7 个最高频问题及根治方案附带真实日志和修复对比。5.1 问题一“生成的代码有语法错误”——根源是 prompt 的缩进和空格现象Codex 返回的 Python 代码if块里return语句缩进 2 个空格导致IndentationError。日志还原def validate_phone(phone: str) - bool: if len(phone) ! 11: return False if not phone.isdigit(): return False return True根因分析Codex 的 tokenizer 对空格极其敏感。你在 prompt 里写if len(phone) ! 11:4 空格它就认为“标准缩进是 4 空格”但如果你 prompt 里混用了 tab 和空格它会学习到混乱的缩进模式。实测发现当 prompt 中存在# 用 4 空格缩进这样的显式说明时错误率下降 65%。根治方案在所有 prompt 开头强制声明缩进规则# Python 3.11, 4 空格缩进无 tab # 项目...5.2 问题二“生成的函数名和变量名不符合项目规范”——根源是未提供命名上下文现象项目里所有工具函数都以util_开头如util_parse_date但 Codex 生成了parse_date_helper。根因分析Codex 不会主动学习你的命名习惯除非你把它写进 prompt。它看到def parse_date就认为这是标准命名。根治方案在 prompt 中加入“命名约定”段落# 命名约定 # - 工具函数util_前缀如 util_format_currency # - 数据模型CamelCase如 UserProfile # - 配置常量UPPER_SNAKE_CASE如 MAX_RETRY_ATTEMPTS5.3 问题三“调用 API 返回 empty response”——根源是 prompt 中包含不可见字符现象response.choices[0].text为空字符串但 HTTP 状态码是 200。根因分析从网页复制的 prompt常含 Unicode 零宽空格U200B、软连字符U00AD等不可见字符。Codex 的 tokenizer 会把这些当作有效 token导致 prompt 被截断或解析失败。排查命令# 查看文件十六进制搜索 200B xxd your_prompt.txt | grep 200b # 或用 Python 检测 python3 -c print([ord(c) for c in open(prompt.txt).read()[:100]])根治方案所有 prompt 文件用 VS Code 保存为 UTF-8 without BOM并在设置中开启editor.renderWhitespace: all让空格和制表符可见。5.4 问题四“生成的代码调用了不存在的第三方库”——根源是 prompt 中暗示了错误依赖现象prompt 里写了# 使用 pandas 处理 CSV但项目实际用csv标准库Codex 却生成了import pandas as pd。根因分析Codex 的训练数据中pandas 相关代码远多于 csv 标准库。当你提到“处理 CSV”它优先匹配高频模式。根治方案在 prompt 中显式声明技术栈限制# 技术栈限制 # - 禁止使用 pandas, numpy, requests # - 仅允许使用 Python 标准库和项目已安装的包django, psycopg2, celery5.5 问题五“同一 prompt 多次调用结果不一致”——根源是 temperature 参数未锁定现象第一次调用生成 A 版本第二次调用生成 B 版本两者逻辑冲突。根因分析temperature控制随机性。0.8时Codex 会探索多种可能0.0时它总是选择概率最高的那个 token。Vibe Coding 要求可重现性必须用0.0。根治方案在所有生产环境调用中固定temperature0.0。仅在探索式开发如写 PoC时用0.3寻找灵感。5.6 问题六“生成的 SQL 语句有注入风险”——根源是未启用安全防护层现象Codex 生成fSELECT * FROM users WHERE id {user_id}直接拼接变量。根因分析Codex 不理解 SQL 注入概念它只是模仿训练数据中的常见写法。而训练数据里大量存在不安全的字符串拼接。根治方案绝不直接使用 Codex 生成的 SQL。必须经过一层“安全网关”def safe_sql_query(template: str, params: dict) - str: # 用 sqlparse 解析 template检查是否有 {var} 形式 # 强制替换为 %s 占位符并返回 (sql, tuple(params.values())) pass5.7 问题七“API 调用频繁超时”——根源是未实现请求队列和重试现象批量处理 100 个文件时前 20 个成功后 80 个ReadTimeout。根因分析OpenAI API 有并发连接数限制默认 10 QPS。连续发送 100 个请求后 80 个会排队超时。根治方案用asyncio.Semaphore限流import asyncio semaphore asyncio.Semaphore(5) # 限制 5 个并发 async def call_codex(prompt): async with semaphore: return await client.completions.create(...) # 批量调用 results await asyncio.gather(*[call_codex(p) for p in prompts])实操心得我曾在一个数据迁移项目中用 Codex 自动生成 2000 行 SQL 转换脚本。最初没加限流跑了 2 小时只完成 300 行还触发了 OpenAI 的风控。加上Semaphore(3)后45 分钟全部完成且成功率 100%。技术细节决定成败不是玄学。6. 进阶实战用 Codex 实现一个“自动补全单元测试”的 CLI 工具现在我们把前面所有知识点整合成一个可立即投入生产的工具testgen。它的目标很明确——给任意 Python 函数自动生成覆盖边界条件的 pytest 测试用例。这不是玩具而是我在上一个 SaaS 项目中每天都在用的生产力工具。6.1 需求分析为什么需要它手动写单元测试80% 的时间花在“构造测试数据”和“写 assert 语句”上。比如一个calculate_discount(price: float, coupon: str) - float函数你需要构造price0.0,price100.0,price-10.0构造couponWELCOME,couponINVALID,coupon写assert calculate_discount(100.0, WELCOME) 90.0。Codex 擅长这种模式化工作。关键是我们要让它生成的测试能直接pytest test_module.py运行无需修改。6.2 核心 Prompt 设计让 Codex “懂” pytesttestgen的灵魂在于这个 prompt 模板# pytest 7.4, Python 3.11 # 项目电商折扣引擎 # 文件discount/calculator.py # 函数calculate_discount # 签名def calculate_discount(price: float, coupon: str) - float: # 文档计算商品最终价格。price 必须 0coupon 为空或有效码。 # 要求 # - 生成一个名为 test_calculate_discount 的 pytest 函数 # - 使用 pytest.mark.parametrize 覆盖至少 5 个测试用例 # - 测试用例必须包含正常值、边界值price0, price0、无效 coupon、空 coupon # - assert 语句必须精确到小数点后 2 位 # - 不要 import pytest假设已在文件顶部 # - 不要写 if __name__ __main__: # 请只返回测试函数定义不要任何额外文本注意几个关键设计点明确指定 pytest 版本避免生成parameterize旧版或pytest.param()新版混淆给出函数签名和文档让 Codex 理解参数类型和业务规则强制pytest.mark.parametrize这是生成可维护测试的核心比写 5 个独立函数更高效禁止 import因为生成的测试会插入到现有 test 文件中重复 import 会报错。6.3 完整 CLI 工具实现创建testgen.py#!/usr/bin/env python3 import argparse import ast import re from pathlib import Path import openai def extract_function_info(file_path: str, func_name: str): 从 Python 文件中提取函数签名和 docstring with open(file_path, r) as f: tree ast.parse(f.read()) for node in ast.walk(tree): if isinstance(node, ast.FunctionDef) and node.name func_name: sig ast.unparse(node).split(\n)[0] # 第一行是 def ... docstring ast.get_docstring(node) or return sig, docstring raise ValueError(fFunction {func_name} not found in {file_path}) def generate_test_prompt(file_path: str, func_name: str): sig, doc extract_function_info(file_path, func_name) return f# pytest 7.4, Python 3.11 # 项目{Path(file_path).parent.name} # 文件{file_path} # 函数{func_name} # 签名{sig} # 文档{doc} # 要求 # - 生成一个名为 test_{func_name} 的 pytest 函数 # - 使用 pytest.mark.parametrize 覆盖至少 5 个测试用例 # - 测试用例必须包含正常值、边界值、异常值 # - assert 语句必须精确到小数点后 2 位 # - 不要 import pytest假设已在文件顶部 # - 不要写 if __name__ __main__: # 请只返回测试函数定义不要任何额外文本 def main(): parser argparse.ArgumentParser(descriptionAuto-generate pytest tests with Codex) parser.add_argument(file