聊一个常被问的问题Codex 插件到底怎么选我见过太多人一上来就把 VS Code 插件列表装到几十个结果真正每天用到的没几个反而把 Codex 的上下文、快捷键和诊断信息全搞乱了。我自己是从 Codex CLI 刚开放那阵开始用的中间换过不少 IDE、试过十几种扩展和 MCP 工具最后留在手里的就这 10 个。它们不是什么热门排行榜纯粹是满足我的工作方式先用 Codex 解决真实需求再让插件补齐它够不到的地方。文末我会把日常喂给 Codex 的提示词模板也放出来直接抄就行。1. 先说清楚Codex 的“插件”有三层别搞混1.1 IDE 扩展层官方扩展和社区轮子很多人一听到 Codex 插件第一反应是去 VS Code 插件市场搜“codex”然后看到一堆名字差不多的扩展选择困难症当场发作。这里要先把概念分清楚。我理解的“插件”不是一个单一的东西而是三层IDE 扩展层、MCP 工具层、提示词层。IDE 扩展层负责把 Codex 从终端搬进编辑器让你不用切窗口MCP 工具层负责给 Codex 插上文件和网络的手脚提示词层决定 Codex 到底是“一个会写代码的聊天机器人”还是“一个懂你项目的老工程师”。这三层里最容易装错的是第一层。官方扩展只有一个叫 OpenAI Codex其他的社区扩展很多是从 CLI 包了一层壳功能可能更花哨但维护质量参差不齐。我后来把社区壳基本都卸了只留官方扩展原因后面细说。1.2 工具层MCP Server 是给 Codex 装“外设”MCP 全称是 Model Context Protocol你可以把它理解成 AI 的 USB 接口Codex 本身只有一个大脑能读文件、写文件、跑命令但如果你希望它操作 GitHub、查网页、批量检索项目文件最好给它插上对应的“外设”。这些外设就是 MCP Server。装完之后Codex 就能在任务里调用这些工具而不是只靠上下文里的那几段代码瞎猜。对一个把 Codex 当主力开发助手的人来说MCP 的价值比多装十个花哨扩展要大得多。1.3 提示词层AGENTS.md 和预设 Prompt 才是灵魂插件选得再好Codex 看不到你项目的来龙去脉写出来的代码还是“看起来像那么回事实际改不动”。GitHub 上很多高性能 Codex 用法都在强调AGENTS.md文件这个文件相当于你给 Codex 写的入职手册。我会把项目的编码规范、目录结构、测试命令、禁止事项全写进去再配合一套固定提示词模板。这套组合才是真正的“隐藏插件”所以这篇文章的提示词部分不是凑字数是我实际在用的配置。2. 10 个我装完就没卸过的插件清单插件类型定位适合谁OpenAI CodexIDE 扩展主入口所有用 VS Code 的人Codex MCP ServerMCP 工具给 Codex 加文件/GitHub/网络能力需要 Codex 跨工具干活的人ContinueIDE 扩展多模型对照想对比不同模型结果的人GitLensIDE 扩展看提交历史经常接盘老项目的人Error LensIDE 扩展行内报错想让 Codex 精准修 bug 的人Todo TreeIDE 扩展整理 TODO/FIXME喜欢用 TODO 管理需求的人Markdown All in OneIDE 扩展维护文档写 AGENTS.md 和 README 的人Path IntellisenseIDE 扩展路径补全写提示词时要贴文件路径的人Prettier ESLintIDE 扩展自动格式化/检查所有让 AI 改代码的人Code Spell CheckerIDE 扩展拼写检查被变量命名拼错坑过的人下面展开讲几个重点剩下的一句话心得也一起放在里面。2.1 两个“不能没有”的官方扩展和 MCP ServerOpenAI Codex 官方扩展就是我所有操作的主界面。装好之后VS Code 里会多一个 Codex 面板可以直接选中代码片段发指令也可以让它读整个工作区。官方扩展的好处是和 CLI 配置共用一套登录态和模型配置不会出现“终端里能用、面板里突然失联”的问题。Codex MCP Server单独说。很多人装了官方扩展就觉得完事了但真正跑项目时你会发现Codex 偶尔会卡在“找不到某个文件”或者“没法查 GitHub 上的历史 commit”。MCP Server 就是把这些问题解决掉的那一层。我目前挂的最多的是 filesystem、GitHub 和 fetch 三类工具filesystem 让它能按目录结构检索GitHub 让它可以读 issue 和 PRfetch 让它能抓取外部文档。这一步配置稍微有点门槛但值得花十分钟。装完之后 Codex 的可用性会上一个台阶不是“能写代码”而是“能帮你在真实项目里查资料、做修改、验证结果”。2.2 三个“帮我看清代码”的GitLens、Error Lens、Todo TreeGitLens看着和 Codex 没关系实际上配合起来很好用。Codex 修 bug 的时候最缺的不是代码而是“这段代码为什么变成这样”的上下文。GitLens 会在代码行内显示最近的提交记录和作者我只要在提示词里加一句“结合 Git 历史判断最近改动”Codex 拿到 blame 信息后给出的排查方向会准很多。Error Lens把错误信息直接显示在代码行尾不用等编译或调试。对 Codex 工作流来说这等于把“报错现场”直接喂到模型眼前。我发现让 Codex 修 bug最怕它“脑补报错”而 Error Lens 能强制它面对真实的 error message。Todo Tree则是给 Codex 指路。很多老项目里散落着几十个 TODO、FIXME、HACKCodex 如果只靠 grep 找效率很低。装完 Todo Tree 后我能瞬间看到所有待办点再让 Codex 按优先级处理。它本身不动代码但帮我省掉了大量“提示词里写不清位置在哪”的沟通成本。2.3 三个“让输出更干净”的Markdown All in One、Path Intellisense、Prettier ESLintMarkdown All in One看起来是写文档用的但我的真实用途是维护AGENTS.md。这个插件能自动生成目录、维护表格、格式化 Markdown写项目说明的时候顺手很多。Codex 会频繁读AGENTS.md如果这个文件乱成一团模型的理解也会打折扣。Path Intellisense解决一个很实际的问题我在提示词里贴文件路径时经常手滑写错。Codex 一读路径不对就开始猜一猜就会绕远路。装完这个插件路径有自动补全提示词的准确率明显提升。Prettier ESLint我是当作一组装的。Codex 改完代码后经常出现缩进不统一、单引号双引号混用、还有几个 lint warning。手去收拾太浪费时间干脆让格式化工具和 Lint 自动收尾。重点是别在提示词里反复叮嘱“注意格式化”那会浪费上下文直接在保存时自动处理才是干净的做法。2.4 两个“查漏补缺”的Continue 和 Code Spell CheckerContinue是我用来做“第二意见”的扩展。Codex 给方案后我会把同一个 prompt 丢给 Continue 里的另一个模型让它俩各出一版再对比差异。这个习惯帮我抓出好几次 Codex 过度自信的误判。Continue 本身不是必需但如果你和我一样对重要重构不放心它可以当个免费评审。Code Spell Checker看起来最不起眼但在真实项目里救过我很多次。变量名拼错一个字母Codex 经常发现不了因为模型看词义不看拼写。这个插件会在拼错的地方画波浪线我只要把提示词写成“修掉所有拼写错误附带变更说明”就能把肉眼容易漏掉的小错统一清掉。3. 实操记录从零配一套 Codex 工作流3.1 第一步装 CLI 和官方扩展如果你还没用过 Codex我建议先装 CLI再装 VS Code 扩展。CLI 是基础扩展是界面。官方文档里有安装命令装完跑一句codex login登录再在 VS Code 扩展市场搜 “OpenAI Codex” 安装。装完之后先别急着写业务代码做一次冒烟测试在终端跑codex随便问一个“这个项目是干什么的”之类的问题看能不能正常响应。这一步确认登录态和网络链路没问题再进 IDE。3.2 第二步配置模型供应商比如接入 DeepSeekCodex 不一定要用默认模型。我就经常把本地 Codex 切到 DeepSeek 的接口因为有些任务不需要最强模型用轻量模型跑反而更快、更省。配置方式是在~/.codex/config.toml里加一个 provider下面是我这里常见的写法具体字段以你装的版本为准# ~/.codex/config.toml 示例 model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY注意env_key的意思是让 Codex 从环境变量里读 API Key别写死在配置里。换其他 OpenAI 兼容服务也是一样的套路改base_url和env_key就行。3.3 第三步挂上 MCP ServerMCP Server 的配置可以写在 Codex 的全局配置里也可以写在项目级的.mcp.json。我习惯按项目维护因为不同项目需要的工具不一样。比如写前端项目时我会挂浏览器相关工具写后端时我更多挂数据库和文件系统工具。一个简单的 filesystem MCP 配置长这样{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /path/to/your/project ] } } }配置完记得重载窗口然后在 Codex 里问一句“你现在能用哪些工具”看它能不能正确列出工具列表。不能列出来就是没挂上直接检查路径和 npx 能不能跑。3.4 第四步写第一份 AGENTS.md项目根目录放一个AGENTS.md这比任何插件都重要。我的模板一般包含这几部分项目简介、常用命令、目录结构、代码规范、禁止事项。不用写长三四十行足够。# AGENTS.md ## 项目简介 这是一个面向中小团队的报表系统前端 Vue 3后端 Node.js。 ## 常用命令 - 本地启动npm run dev - 跑测试npm test - 构建产物npm run build ## 目录结构 - src/api 放接口请求 - src/components 放通用组件 - src/pages 放页面 - scripts 放工具脚本 ## 规范 - 接口返回统一用 { code, data, message } 结构 - 组件 props 要写类型注释 - 不要修改 src/lib 下的文件除非有明确需求 ## 禁止事项 - 不要把环境变量写到代码里 - 不要大规模重命名 - 不要擅自引入新的依赖有了这个文件Codex 每次进入项目都会自动读一遍写出来的代码至少不会跑偏到“随便建个新目录把代码塞进去”的程度。3.5 第五步用一套提示词模板跑通第一个任务配置归配置真正决定 Codex 好不好用的是你每次发出去的指令。我日常用的提示词见第五部分你可以在跑通第一个任务时直接复制。4. 常见问题与排查实录现象可能原因解法官方扩展装完没反应没装 CLI 或登录态过期先跑codex login再在 VS Code 里重载窗口请求一直转圈或报接口错误模型供应商的 base_url 和 Key 不匹配检查 config.toml 和对应环境变量是否配对MCP Server 看不到工具配置没生效或路径不对确认.mcp.json位置重载窗口后重新询问工具列表上下文不够提示词被截断一次塞了太多代码拆分任务让 Codex 先读目录再读指定文件插件快捷键冲突多个扩展都绑定同一个键在 VS Code 快捷键设置里手动改掉保留 Codex 主入口这里多说两句。第一Codex 报接口错误时很多人第一反应是“网络不行”但在我遇到的情况里八成是base_url写错或者环境变量没生效。先确认 Key 能不能从这个网络环境访问到服务商接口再查配置别瞎折腾。第二MCP Server 挂不上时一定先去终端手动跑一遍npx -y 包名看它有没有报错。很多时候不是 Codex 的问题是 npx 下载包的时候失败了单独跑一遍就能看到真实原因。5. 我日常工作流里的提示词模板可直接抄5.1 初始化项目先读后写喂给 Codex 的第一条提示词我会把它当成“入职培训”先不要写任何代码。 读一下项目根目录的 AGENTS.md 和 README.md然后告诉我 1. 这个项目是做什么的 2. 用到了哪些主要技术栈 3. 目录结构里你最关注哪几个文件 4. 如果要做一个新功能你会先看哪些文件 确认我给的答案没问题后再给我一份实施计划。这条提示词的核心是“先读后写”。直接让 Codex 干活很容易翻车但让它先复述项目背景能逼它把上下文读进去。5.2 修 bug给足三个现场不要说“帮我修 bug”要说清复现路径、期望结果、实际结果。标准模板我用了很久项目里有一个 bug我希望你按排查流程走。 复现路径打开 /src/pages/order/list.vue点击“导出”按钮。 期望结果浏览器下载一个 CSV 文件。 实际结果点击后控制台报错页面白屏。 请你 1. 先列出 3 个最可能的原因按概率排序 2. 结合 Git 历史判断最近一次相关改动 3. 做一个最小改动不要顺手重构 4. 告诉我你改了哪些文件以及为什么这么改这个模板最关键的是“先列原因再动手”。Codex 推理能力强但也容易跳步骤给它固定输出顺序大部分 bug 都能一次定位。5.3 写测试让 Codex 自己找边界让 Codex 写测试时如果只说“补测试”它大概率会写一堆 happy path。我常用的模板是为 src/pricing/calculator.ts 写单元测试。 要求 1. 不要只测正常输入覆盖 0、负数、折扣叠加、四舍五入边界 2. 每个用例注释里写明它防御的是哪个 bug 3. 测试命名用 given_when_then 风格 4. 写完后运行一遍告诉我哪些用例失败了重点在后面那句“跑一遍”。很多 AI 给代码时会默认“我写的肯定能过”但你让它跑一遍它才会认真检查。5.4 画 SVG用鹈鹕骑自行车测模型想象力这个是我最近常用来测模型 SVG 能力的提示词网上很多人叫它“鹈鹕测试”用纯 SVG 画一只鹈鹕骑自行车要求 1. 鹈鹕要有标志性的大嘴和翅膀 2. 自行车要能动起来轮子、脚踏、身体有关键帧动画 3. 布局简洁配色不超过 4 种 4. 生成代码要能直接保存成 .svg 文件运行别小看这个题目它要同时处理图形结构、动画逻辑和代码可运行性。Codex 如果连这个都能跑出像样的结果至少说明它对代码和视觉的协调能力在线。5.5 终极兜底先问清楚再动手Codex 最容易犯的毛病是“自以为懂了”。所以我自己设了一个兜底提示词在写代码之前先问我三个问题 1. 这个需求的验收标准是什么 2. 有没有不能改的历史包袱 3. 这次改动希望影响哪些模块 等我回答完这些问题再出方案最后再动手。这条模板适合所有重要任务也是我建议每个人都要配的“安全阀”。6. 到底该装几个我的取舍标准最后说一下选型逻辑。现在插件市场里每天都有新东西但我不建议追新。我的标准只有三条第一能不能补上 Codex 的短板第二社区维护是否还活着第三装完会不会每天都要调。按这个标准工具类只留了 MCP ServerIDE 扩展也只留了围绕“读代码、看报错、收尾格式化”这几件事的。如果你刚开始用 Codex不用一次装齐先装官方扩展和 GitLens把提示词模板跑顺再慢慢加 MCP 工具。插件是手段不是目的。最后再分享一个小技巧每过两周我会打开插件列表把“这半个月一次都没打开”的插件直接卸掉。别心疼真正好用的工具不需要仪式感你会在每个任务里自动想起它。我这份 10 个清单就是一轮轮卸完之后剩下的东西照着抄不会踩太多坑。 Codex插件怎么选？10个必备插件与完整工作流配置
聊一个常被问的问题Codex 插件到底怎么选我见过太多人一上来就把 VS Code 插件列表装到几十个结果真正每天用到的没几个反而把 Codex 的上下文、快捷键和诊断信息全搞乱了。我自己是从 Codex CLI 刚开放那阵开始用的中间换过不少 IDE、试过十几种扩展和 MCP 工具最后留在手里的就这 10 个。它们不是什么热门排行榜纯粹是满足我的工作方式先用 Codex 解决真实需求再让插件补齐它够不到的地方。文末我会把日常喂给 Codex 的提示词模板也放出来直接抄就行。1. 先说清楚Codex 的“插件”有三层别搞混1.1 IDE 扩展层官方扩展和社区轮子很多人一听到 Codex 插件第一反应是去 VS Code 插件市场搜“codex”然后看到一堆名字差不多的扩展选择困难症当场发作。这里要先把概念分清楚。我理解的“插件”不是一个单一的东西而是三层IDE 扩展层、MCP 工具层、提示词层。IDE 扩展层负责把 Codex 从终端搬进编辑器让你不用切窗口MCP 工具层负责给 Codex 插上文件和网络的手脚提示词层决定 Codex 到底是“一个会写代码的聊天机器人”还是“一个懂你项目的老工程师”。这三层里最容易装错的是第一层。官方扩展只有一个叫 OpenAI Codex其他的社区扩展很多是从 CLI 包了一层壳功能可能更花哨但维护质量参差不齐。我后来把社区壳基本都卸了只留官方扩展原因后面细说。1.2 工具层MCP Server 是给 Codex 装“外设”MCP 全称是 Model Context Protocol你可以把它理解成 AI 的 USB 接口Codex 本身只有一个大脑能读文件、写文件、跑命令但如果你希望它操作 GitHub、查网页、批量检索项目文件最好给它插上对应的“外设”。这些外设就是 MCP Server。装完之后Codex 就能在任务里调用这些工具而不是只靠上下文里的那几段代码瞎猜。对一个把 Codex 当主力开发助手的人来说MCP 的价值比多装十个花哨扩展要大得多。1.3 提示词层AGENTS.md 和预设 Prompt 才是灵魂插件选得再好Codex 看不到你项目的来龙去脉写出来的代码还是“看起来像那么回事实际改不动”。GitHub 上很多高性能 Codex 用法都在强调AGENTS.md文件这个文件相当于你给 Codex 写的入职手册。我会把项目的编码规范、目录结构、测试命令、禁止事项全写进去再配合一套固定提示词模板。这套组合才是真正的“隐藏插件”所以这篇文章的提示词部分不是凑字数是我实际在用的配置。2. 10 个我装完就没卸过的插件清单插件类型定位适合谁OpenAI CodexIDE 扩展主入口所有用 VS Code 的人Codex MCP ServerMCP 工具给 Codex 加文件/GitHub/网络能力需要 Codex 跨工具干活的人ContinueIDE 扩展多模型对照想对比不同模型结果的人GitLensIDE 扩展看提交历史经常接盘老项目的人Error LensIDE 扩展行内报错想让 Codex 精准修 bug 的人Todo TreeIDE 扩展整理 TODO/FIXME喜欢用 TODO 管理需求的人Markdown All in OneIDE 扩展维护文档写 AGENTS.md 和 README 的人Path IntellisenseIDE 扩展路径补全写提示词时要贴文件路径的人Prettier ESLintIDE 扩展自动格式化/检查所有让 AI 改代码的人Code Spell CheckerIDE 扩展拼写检查被变量命名拼错坑过的人下面展开讲几个重点剩下的一句话心得也一起放在里面。2.1 两个“不能没有”的官方扩展和 MCP ServerOpenAI Codex 官方扩展就是我所有操作的主界面。装好之后VS Code 里会多一个 Codex 面板可以直接选中代码片段发指令也可以让它读整个工作区。官方扩展的好处是和 CLI 配置共用一套登录态和模型配置不会出现“终端里能用、面板里突然失联”的问题。Codex MCP Server单独说。很多人装了官方扩展就觉得完事了但真正跑项目时你会发现Codex 偶尔会卡在“找不到某个文件”或者“没法查 GitHub 上的历史 commit”。MCP Server 就是把这些问题解决掉的那一层。我目前挂的最多的是 filesystem、GitHub 和 fetch 三类工具filesystem 让它能按目录结构检索GitHub 让它可以读 issue 和 PRfetch 让它能抓取外部文档。这一步配置稍微有点门槛但值得花十分钟。装完之后 Codex 的可用性会上一个台阶不是“能写代码”而是“能帮你在真实项目里查资料、做修改、验证结果”。2.2 三个“帮我看清代码”的GitLens、Error Lens、Todo TreeGitLens看着和 Codex 没关系实际上配合起来很好用。Codex 修 bug 的时候最缺的不是代码而是“这段代码为什么变成这样”的上下文。GitLens 会在代码行内显示最近的提交记录和作者我只要在提示词里加一句“结合 Git 历史判断最近改动”Codex 拿到 blame 信息后给出的排查方向会准很多。Error Lens把错误信息直接显示在代码行尾不用等编译或调试。对 Codex 工作流来说这等于把“报错现场”直接喂到模型眼前。我发现让 Codex 修 bug最怕它“脑补报错”而 Error Lens 能强制它面对真实的 error message。Todo Tree则是给 Codex 指路。很多老项目里散落着几十个 TODO、FIXME、HACKCodex 如果只靠 grep 找效率很低。装完 Todo Tree 后我能瞬间看到所有待办点再让 Codex 按优先级处理。它本身不动代码但帮我省掉了大量“提示词里写不清位置在哪”的沟通成本。2.3 三个“让输出更干净”的Markdown All in One、Path Intellisense、Prettier ESLintMarkdown All in One看起来是写文档用的但我的真实用途是维护AGENTS.md。这个插件能自动生成目录、维护表格、格式化 Markdown写项目说明的时候顺手很多。Codex 会频繁读AGENTS.md如果这个文件乱成一团模型的理解也会打折扣。Path Intellisense解决一个很实际的问题我在提示词里贴文件路径时经常手滑写错。Codex 一读路径不对就开始猜一猜就会绕远路。装完这个插件路径有自动补全提示词的准确率明显提升。Prettier ESLint我是当作一组装的。Codex 改完代码后经常出现缩进不统一、单引号双引号混用、还有几个 lint warning。手去收拾太浪费时间干脆让格式化工具和 Lint 自动收尾。重点是别在提示词里反复叮嘱“注意格式化”那会浪费上下文直接在保存时自动处理才是干净的做法。2.4 两个“查漏补缺”的Continue 和 Code Spell CheckerContinue是我用来做“第二意见”的扩展。Codex 给方案后我会把同一个 prompt 丢给 Continue 里的另一个模型让它俩各出一版再对比差异。这个习惯帮我抓出好几次 Codex 过度自信的误判。Continue 本身不是必需但如果你和我一样对重要重构不放心它可以当个免费评审。Code Spell Checker看起来最不起眼但在真实项目里救过我很多次。变量名拼错一个字母Codex 经常发现不了因为模型看词义不看拼写。这个插件会在拼错的地方画波浪线我只要把提示词写成“修掉所有拼写错误附带变更说明”就能把肉眼容易漏掉的小错统一清掉。3. 实操记录从零配一套 Codex 工作流3.1 第一步装 CLI 和官方扩展如果你还没用过 Codex我建议先装 CLI再装 VS Code 扩展。CLI 是基础扩展是界面。官方文档里有安装命令装完跑一句codex login登录再在 VS Code 扩展市场搜 “OpenAI Codex” 安装。装完之后先别急着写业务代码做一次冒烟测试在终端跑codex随便问一个“这个项目是干什么的”之类的问题看能不能正常响应。这一步确认登录态和网络链路没问题再进 IDE。3.2 第二步配置模型供应商比如接入 DeepSeekCodex 不一定要用默认模型。我就经常把本地 Codex 切到 DeepSeek 的接口因为有些任务不需要最强模型用轻量模型跑反而更快、更省。配置方式是在~/.codex/config.toml里加一个 provider下面是我这里常见的写法具体字段以你装的版本为准# ~/.codex/config.toml 示例 model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY注意env_key的意思是让 Codex 从环境变量里读 API Key别写死在配置里。换其他 OpenAI 兼容服务也是一样的套路改base_url和env_key就行。3.3 第三步挂上 MCP ServerMCP Server 的配置可以写在 Codex 的全局配置里也可以写在项目级的.mcp.json。我习惯按项目维护因为不同项目需要的工具不一样。比如写前端项目时我会挂浏览器相关工具写后端时我更多挂数据库和文件系统工具。一个简单的 filesystem MCP 配置长这样{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /path/to/your/project ] } } }配置完记得重载窗口然后在 Codex 里问一句“你现在能用哪些工具”看它能不能正确列出工具列表。不能列出来就是没挂上直接检查路径和 npx 能不能跑。3.4 第四步写第一份 AGENTS.md项目根目录放一个AGENTS.md这比任何插件都重要。我的模板一般包含这几部分项目简介、常用命令、目录结构、代码规范、禁止事项。不用写长三四十行足够。# AGENTS.md ## 项目简介 这是一个面向中小团队的报表系统前端 Vue 3后端 Node.js。 ## 常用命令 - 本地启动npm run dev - 跑测试npm test - 构建产物npm run build ## 目录结构 - src/api 放接口请求 - src/components 放通用组件 - src/pages 放页面 - scripts 放工具脚本 ## 规范 - 接口返回统一用 { code, data, message } 结构 - 组件 props 要写类型注释 - 不要修改 src/lib 下的文件除非有明确需求 ## 禁止事项 - 不要把环境变量写到代码里 - 不要大规模重命名 - 不要擅自引入新的依赖有了这个文件Codex 每次进入项目都会自动读一遍写出来的代码至少不会跑偏到“随便建个新目录把代码塞进去”的程度。3.5 第五步用一套提示词模板跑通第一个任务配置归配置真正决定 Codex 好不好用的是你每次发出去的指令。我日常用的提示词见第五部分你可以在跑通第一个任务时直接复制。4. 常见问题与排查实录现象可能原因解法官方扩展装完没反应没装 CLI 或登录态过期先跑codex login再在 VS Code 里重载窗口请求一直转圈或报接口错误模型供应商的 base_url 和 Key 不匹配检查 config.toml 和对应环境变量是否配对MCP Server 看不到工具配置没生效或路径不对确认.mcp.json位置重载窗口后重新询问工具列表上下文不够提示词被截断一次塞了太多代码拆分任务让 Codex 先读目录再读指定文件插件快捷键冲突多个扩展都绑定同一个键在 VS Code 快捷键设置里手动改掉保留 Codex 主入口这里多说两句。第一Codex 报接口错误时很多人第一反应是“网络不行”但在我遇到的情况里八成是base_url写错或者环境变量没生效。先确认 Key 能不能从这个网络环境访问到服务商接口再查配置别瞎折腾。第二MCP Server 挂不上时一定先去终端手动跑一遍npx -y 包名看它有没有报错。很多时候不是 Codex 的问题是 npx 下载包的时候失败了单独跑一遍就能看到真实原因。5. 我日常工作流里的提示词模板可直接抄5.1 初始化项目先读后写喂给 Codex 的第一条提示词我会把它当成“入职培训”先不要写任何代码。 读一下项目根目录的 AGENTS.md 和 README.md然后告诉我 1. 这个项目是做什么的 2. 用到了哪些主要技术栈 3. 目录结构里你最关注哪几个文件 4. 如果要做一个新功能你会先看哪些文件 确认我给的答案没问题后再给我一份实施计划。这条提示词的核心是“先读后写”。直接让 Codex 干活很容易翻车但让它先复述项目背景能逼它把上下文读进去。5.2 修 bug给足三个现场不要说“帮我修 bug”要说清复现路径、期望结果、实际结果。标准模板我用了很久项目里有一个 bug我希望你按排查流程走。 复现路径打开 /src/pages/order/list.vue点击“导出”按钮。 期望结果浏览器下载一个 CSV 文件。 实际结果点击后控制台报错页面白屏。 请你 1. 先列出 3 个最可能的原因按概率排序 2. 结合 Git 历史判断最近一次相关改动 3. 做一个最小改动不要顺手重构 4. 告诉我你改了哪些文件以及为什么这么改这个模板最关键的是“先列原因再动手”。Codex 推理能力强但也容易跳步骤给它固定输出顺序大部分 bug 都能一次定位。5.3 写测试让 Codex 自己找边界让 Codex 写测试时如果只说“补测试”它大概率会写一堆 happy path。我常用的模板是为 src/pricing/calculator.ts 写单元测试。 要求 1. 不要只测正常输入覆盖 0、负数、折扣叠加、四舍五入边界 2. 每个用例注释里写明它防御的是哪个 bug 3. 测试命名用 given_when_then 风格 4. 写完后运行一遍告诉我哪些用例失败了重点在后面那句“跑一遍”。很多 AI 给代码时会默认“我写的肯定能过”但你让它跑一遍它才会认真检查。5.4 画 SVG用鹈鹕骑自行车测模型想象力这个是我最近常用来测模型 SVG 能力的提示词网上很多人叫它“鹈鹕测试”用纯 SVG 画一只鹈鹕骑自行车要求 1. 鹈鹕要有标志性的大嘴和翅膀 2. 自行车要能动起来轮子、脚踏、身体有关键帧动画 3. 布局简洁配色不超过 4 种 4. 生成代码要能直接保存成 .svg 文件运行别小看这个题目它要同时处理图形结构、动画逻辑和代码可运行性。Codex 如果连这个都能跑出像样的结果至少说明它对代码和视觉的协调能力在线。5.5 终极兜底先问清楚再动手Codex 最容易犯的毛病是“自以为懂了”。所以我自己设了一个兜底提示词在写代码之前先问我三个问题 1. 这个需求的验收标准是什么 2. 有没有不能改的历史包袱 3. 这次改动希望影响哪些模块 等我回答完这些问题再出方案最后再动手。这条模板适合所有重要任务也是我建议每个人都要配的“安全阀”。6. 到底该装几个我的取舍标准最后说一下选型逻辑。现在插件市场里每天都有新东西但我不建议追新。我的标准只有三条第一能不能补上 Codex 的短板第二社区维护是否还活着第三装完会不会每天都要调。按这个标准工具类只留了 MCP ServerIDE 扩展也只留了围绕“读代码、看报错、收尾格式化”这几件事的。如果你刚开始用 Codex不用一次装齐先装官方扩展和 GitLens把提示词模板跑顺再慢慢加 MCP 工具。插件是手段不是目的。最后再分享一个小技巧每过两周我会打开插件列表把“这半个月一次都没打开”的插件直接卸掉。别心疼真正好用的工具不需要仪式感你会在每个任务里自动想起它。我这份 10 个清单就是一轮轮卸完之后剩下的东西照着抄不会踩太多坑。