企业官网建设流程全解析

第一周用 Codex 的时候，我几乎每天都在装插件——别人说好用的装，热榜上排前面的也装，结果装了二十多个，最后真正稳定留下来的只有 10 个。这个筛选过程让我想明白一个问题：Codex 这类工具，插件的价值不是越多越好，而是要和它的工作方式形成互补。我写这篇不是给你罗列"热门列表"，而是把这 10 个我装完就没卸过的东西讲清楚：它们解决什么问题、怎么配提示词、踩过哪些坑。文章里每个插件都会附一段可以直接抄的提示词，适合正在用 Codex 做日常开发、又不想在插件海洋里迷失方向的人。

1. 先分清一件事：Codex 的插件到底在哪一层

Codex 的核心能力是自然语言改代码，但这个能力特别吃上下文。你给它一个清晰的仓库结构、一段明确的变更要求，它就能干得又快又准；反过来，如果你只是在对话框里丢一句"帮我优化一下"，它大概率会给你一份泛泛的建议，离真正能落地差很远。所以围绕 Codex 的插件，本质上是两类事：一类帮它把上下文做得更清楚，另一类帮你把指令传达得更准确。搞懂这一点，选插件就不会被花哨的名字带偏。

1.1 Codex 是"重上下文依赖"的智能体工具

这里简单补一句背景，方便刚接触的人对齐。OpenAI Codex 目前的形态有 ChatGPT 内置的 Agent、命令行工具，以及集成到 IDE 里的扩展。它可以读取当前代码库、修改文件、执行命令，也可以跑测试。但它的推理能力不等于知道你脑子里的"正确方案"。你给它多少上下文，它就能给你多少回报。比如改一个接口的返回结构，它需要知道调用方有哪些、测试怎么跑、有没有历史约定。这些信息如果不在对话里，它只能靠猜。

1.2 我给 Codex 的"插件"划了三层

这里说的"插件"，不只是 VSCode 扩展市场里那类安装包，我按用途把它分成三层：

• 编辑器层：这类插件主要负责"让代码里的问题显形"，比如错误提示、Git 变更展示、注释分类。它们不直接参与 AI 生成，但给 Codex 提供了高质量的视觉信息。
• 智能体层：包括官方 Codex 边栏、Continue、Cline、Aider 这类工具。它们有些是独立于 Codex 的兄弟产品，但在同一个工作流里可以分工：一个负责大刀阔斧重构，一个负责行内补全，一个负责跑 CLI 小任务。
• 提示词层：这层最容易被忽略。提示词不是"一次性写句聊天开头"，而是应该沉淀成文件、模板、注释和任务清单，让 Codex 每次都能稳定读取。这也是我这篇文章把"插件"和"提示词"放在一起讲的原因。

1.3 我的选型标准：不折腾、不打架、不锁死

网上很多插件评测只看"功能强不强"，我自己的标准更朴素：装完不卸，得满足三条。第一是不折腾，安装配置在十分钟内搞定，文档齐全，不会有莫名其妙的依赖问题。第二是不打架，尤其是智能体层的工具，绝对不能同时让两个 Agent 去抢同一个文件的写权限，否则你就等着看代码被来回覆盖。第三是不锁死，插件依赖的模型服务、账号体系尽量可替换，这样哪天 Codex 策略变了，我还能平滑切到别的工具，而不是被某一个插件绑定。

这三点说起来容易，实际筛选时很费时间。下面这 10 个，就是在这么严格的标准下留下来的。

2. 我装完就没卸过的 10 个插件清单

先放一张总表，方便你对照自己缺什么。后面我再把每一类展开讲。

2.1 编辑体验组：让问题先于 Codex 显形

先说 Error Lens。装之前我一直觉得 VSCode 自带的问题面板够用了，装完之后才发现自己是"看不见问题所以不修"的典型：打开文件只有左下角有个数字，根本不知道红线在哪。Error Lens 把错误、警告直接渲染到对应代码行后面，红色波浪线加文字说明，一眼扫过去就知道哪里有问题。对 Codex 的帮助是间接的：你在对话框里让它修"当前文件所有报错"，它能从你的描述里知道范围，但更关键的是你自己先看见了错误，任务描述才会具体——是类型错误还是空指针，描述越具体，生成结果越靠谱。

GitLens 则是给 Codex 喂背景信息的神器。很多时候 Codex 不知道某段代码为什么长这样：哪次提交加的、作者是谁、当时 commit message 写了什么。GitLens 把 blame、历史、分支信息内联在代码里，我只要复制一条带 commit 信息的链接或者贴一段历史摘要给 Codex，它就能理解"为什么要保持兼容"这类潜规则。GitLens 功能很重，我只用了 blame 和 history 两个模块，关掉其他花哨视图，保持界面干净。

Better Comments 是我私心很重的一个。它把普通注释按类型上色：! 开头是红色警告，? 是疑问，TODO 是橙色，* 是高亮关键信息。我习惯在代码注释里直接写提示词片段，比如? 这里接口返回结构变更后，调用方是否需要同步改？，Codex 读代码时把这些注释当成上下文。搭配官方扩展的"解释代码"功能，效果比直接让 AI 瞎猜好太多。

2.2 AI 协同组：一个主刀，两个助手

官方 Codex 扩展是主刀。现在 OpenAI 官方在 VSCode 里有 Codex 边栏和面板，登录账号后可以直接选中代码、描述需求，让它在当前项目里执行。我留它是因为"原厂协议"最稳定——第三方 Agent 经常要猜 Codex 插件内部逻辑，官方扩展则能直接读当前工作区、跑命令、生成 diff，配合 AGENTS.md 文件也最自然。

Continue 是我用来补空档的。Codex 擅长整段任务，但行内补全、快速解释某一行、问一个小问题这些轻量操作，用 Codex 有点杀鸡用牛刀。Continue 支持多模型，我在它里面接到本地模型或便宜的模型上，专门处理高频小需求，省 Codex 的请求额度，也不打断主对话。两者不冲突的关键在于：Continue 只负责"商量"，Codex 负责"动手写文件"。

Cline 和 Aider 我归在一起说。Cline 是一个开源智能体，可以读文件、执行终端命令、把改动直接写入代码；Aider 则是终端里的结对编程工具，擅长小步重构和 git 提交。我的用法是：遇到一个明确的小任务，比如"把 utils 里的时间处理函数统一改成 dayjs 写法"，我把这个任务丢给 Cline 或 Aider 去跑，Codex 专心做更难的业务逻辑。这样做的收益是隔离风险——万一小任务跑砸了，它只影响一个小 commit，不会把 Codex 的大改动一起带崩。

2.3 工程辅助组：让提示词和任务都长出手脚

Todo Tree 是我每个项目必装的。它的机制很简单：把代码里的 TODO、FIXME 注释聚合成一个侧边栏列表，点一下就能跳到对应位置。我用它做的事是给 Codex 派活之前先建任务清单：在代码文件里写TODO: 增加分页参数，注意保持旧接口兼容，然后让 Codex 读 TODO 列表，挨个处理。这样任务描述不在聊天框里丢失，而是沉淀在代码里，相当于"给 AI 做了一个待办队列"。

Markdown All in One 是维护提示词文档的好帮手。我用它写项目根目录的 PROMPTS.md、操作手册、架构说明，因为它支持自动目录、表格、列表格式化，写出来的文档 Codex 读起来清晰，人看起来也不累。很多提示词失效，不是模型不行，是文档本身层级混乱，模型抓不住重点。

Code Runner 则是"验证闭环"里的一环。Codex 写完一段核心算法或脚本，我经常不需要走到启动整个项目，直接用 Code Runner 在编辑器里跑一下这段代码，看输出对不对。它支持多种语言，一键运行，省去切终端、配环境的折腾。有了它，Codex 的生成质量能被快速反馈，我可以马上把报错贴回去让它修。

最后是 AI Commit。Codex 改完代码后，git diff 往往很长，手写 commit message 很费神。AI Commit 能读取当前 diff，生成符合 Conventional Commits 风格的提交信息。我配合一个固定提示词模板，要求它"总结变更意图，写清楚影响范围"，生成的 message 基本不用改。

3. 每个插件怎么配提示词：10 个可直接抄的模板

提示词这东西，很多人把它想得太玄。其实本质就三段：角色、任务、约束。角色告诉 Codex 按什么身份和语气回应；任务说清楚要做什么、范围是什么；约束限定输出格式、不要做的事。有了这个框架，不管给哪个插件配提示词，都不会跑偏太远。

3.1 提示词不是聊天，是配置文件

我的建议是把常用提示词当成代码来看待：要版本管理、要写清楚输入输出、要能复用。不要每次在对话框里手打一遍。下面这些模板，直接抄进对应插件或提示词文件里就能用。每个模板我都刻意控制长度，因为太长反而会让模型抓不住重点，后面避坑部分我会详细说这个现象。

3.2 十个提示词模板

下面这十个模板覆盖了日常最高频的场景，前两个是全局型的，后面八个是任务型的。你不需要全部用，挑和项目最匹配的几份放进去就够。

模板1：全局角色设定（给官方 Codex 或 AGENTS.md） 你是一名资深后端工程师，熟悉 Python/TypeScript 和当前仓库的技术栈。 在回答任何问题前，先阅读项目根目录的 README 和 AGENTS.md。 所有建议都要落到具体文件路径，禁止只给泛泛方向。 如果信息不足，先提问，再动手。

模板2：代码审查（配官方 Codex / Cline） 请审查当前 git diff，按以下顺序输出： 1. 潜在 bug 和边界条件问题； 2. 可读性和命名问题； 3. 性能隐患； 4. 测试覆盖建议。 每条必须带文件路径和行号。不要修改代码，只做审查。

模板3：生成 commit message（配 AI Commit） 读取当前 git diff，用 Conventional Commits 风格生成 3 条提交信息候选项。 要求：第一行不超过 50 字，正文写清楚变更动机和影响范围。 不要包括"update/修改"这类无信息量动词。

模板4：重构指定函数（配 Cline 或 Aider） 对 src/utils/date.ts 中的 formatDate 函数做以下重构： - 用 dayjs 替换原有 Date 操作； - 保持函数签名不变； - 更新所有调用方； - 运行相关测试确认不破坏。 每次只改一个文件，改完输出 diff 摘要。

模板5：写单元测试（配 Continue 或 Codex） 为 src/services/userService.ts 新增测试，覆盖： - 正常创建用户； - 重复邮箱报错； - 密码过短报错； - 数据库异常时返回 500。 测试使用 vitest，mock 掉数据库层，断言不要过于琐碎。

模板6：从 TODO 列表派活（配 Todo Tree） 读取整个仓库中所有 TODO 注释，按严重程度排序， 逐个生成处理方案。每一项都要包含： - TODO 所在文件与行号； - 问题说明； - 建议改法； - 改动风险。 先不要直接改，等我确认。

模板7：解释遗留代码（配 Continue） 解释 src/legacy/order.ts 中 parseOrder 函数的作用， 重点说明： - 输入格式和异常情况； - 目前调用了哪些全局变量； - 如果废弃它，有哪些替代方案。 用条目输出，最后给一段 5 行内的总结。

模板8：生成接口文档（配 Markdown All in One 工作流） 根据 src/api 目录下的路由定义，生成 OpenAPI 风格接口文档。 每个接口包含：路径、方法、请求参数、响应示例、错误码。 文档写入 docs/api.md，使用 Markdown 表格。

模板9：修复当前文件的报错（配 Error Lens + Codex） 请分析当前打开文件中所有 Error Lens 标记的错误， 按严重程度从高到低修复。每修完一个，说明原因。 对于警告（warn），只在影响运行结果时处理。

模板10：写下周计划（配 Todo Tree + Markdown All in One） 根据 PROMPTS.md 中记录的迭代计划，把下周要做的功能拆成： - 每个任务一句明确描述； - 关联涉及的文件路径； - 预估难度（低/中/高）； - 输出为 TODO 注释格式，方便 Todo Tree 识别。

这些模板看着简单，但真正起作用的是"固定格式"。Codex 这类模型对结构化输入特别敏感，你把输出格式规定好了，它的回答就不会发散。如果项目里有特定规范，比如数据库迁移必须带版本号、接口必须写校验，直接在模板里追加约束，越具体越稳。还有一个小经验：模板里的"禁止"条款要写得像动作而不是态度，比如"禁止只给泛泛方向"就比"不要敷衍"有效得多，因为模型能对比目标状态。

4. 两个关键配置：让 Codex 和提示词真正连着干活

插件装好了，提示词也有了，接下来还有两个配置能决定体验上限：一个是 Codex 的模型接入，一个是提示词文件的组织形式。这两件事不做好，前面抄的模板会经常失灵。

4.1 config.toml：接不同模型的办法

Codex CLI 支持通过配置文件切换模型供应商。很多朋友只知道官方模型，其实它支持 OpenAI 兼容格式的服务商，这样可以用到如 DeepSeek 或其他更便宜、更快的模型。配置文件一般在~/.codex/config.toml，我的写法是：

model = "deepseek-chat" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY" wire_api = "chat"

然后在环境变量里配置DEEPSEEK_API_KEY，Codex 就会把请求发到对应服务。这里有个坑：不同模型的工具调用格式不完全一样，官方模型支持的功能最多，第三方模型可能对某些复杂操作支持不到位。所以我的建议是：日常问答、写小工具、生成文档用第三方模型；涉及大规模重构、多文件改动、跑命令这种高风险操作，还是切回官方模型。模型切换不会丢失对话历史，但切换后建议把关键背景再强调一遍，因为不同模型的上下文理解习惯有差异。

这里说一句容易误解的点：base_url 直接填模型服务商官方给出的接口地址就行，Codex 本身就把这个配置设计成"填地址即可用"的模式，不需要额外做任何网络设置，也不要去动系统层面的转发工具。

4.2 AGENTS.md：把提示词变成项目的一部分

Codex 和很多智能体工具都支持读项目根目录下的 AGENTS.md（有的工具也认 CLAUDE.md 或类似配置文件）。我把常用提示词、项目规范、命令清单都写在这里，让模型每次一开始就自动吸收。比如我会在 AGENTS.md 里写：

• 项目结构说明：哪些目录是核心逻辑、哪些是构建脚本；
• 命令规范：测试用pnpm test，构建用pnpm build；
• 代码风格约定：接口返回统一{ code, data, message }；
• 常见提示词入口：调用PROMPTS.md里的模板。

这样配的好处是：你不用每次在对话框里把"我们项目用 pnpm，测试写法是……"重新交代一遍，模型自己会读文件。省下来的上下文空间，能做更复杂的推理。

4.3 上下文瘦身：别把插件输出全塞给 Codex

插件多了以后，最隐蔽的问题是上下文膨胀。GitLens 能贴历史、Todo Tree 能列任务、Error Lens 能显示所有警告，如果这些信息一股脑全粘进 Codex 对话，很快 token 就超了，模型开始丢前面的指令。我自己的处理原则是：贴给 Codex 的信息控制在"当前任务相关"的范围内。比如做接口修复，就只贴接口文件、调用方、最近的 git log 三样；做全局重构，再考虑贴文件树和模块依赖图。少贴多问，遇到模型信息不够，它会主动问你要，这时候你再补充，比一次性把仓库全甩给它强得多。

5. 避坑实录：插件越多越容易翻车的三个典型场景

这部分是我实际踩过的坑，不是网上抄来的经验。如果你同时装了多个 AI 插件，下面几个问题大概率会遇到。

5.1 现象：Codex 突然只看不动，排查链路

有一次我让 Codex 改一个接口，它回复了一堆"建议这样做"，但一个文件都没改。第一反应是模型傻了，后来仔细排查才发现问题不在模型，在上下文：我在对话前贴了一大段 GitLens 的提交历史，里面有一条信息误导了它——它以为那个接口已经有人改过了，所以只给我"建议"而不是执行。排查链路是这样的：

1. 先看 Codex 面板的完整请求内容，确认它看到的上下文是什么；
2. 把最近粘贴的外部信息逐条排除，尤其是 Git 历史、错误列表这种"背景信息"；
3. 在对话开头补一句明确指令："请直接修改文件，不要只给建议"；
4. 如果再不行，新开一个对话窗口，避免累积上下文干扰。

这个案例说明：插件提供的信息本身没错，但"信息过多"会让模型产生错误假设。喂给 Codex 的资料，一定要和任务目标对齐，不能因为看板上有就用。

5.2 现象：两个 Agent 插件同时抢文件

有段时间我同时开着官方 Codex 和 Cline，给两边都派了任务。结果 Cline 先改完文件，Codex 后写同一段逻辑，直接把 Cline 的改动覆盖了。这不是插件 bug，而是工作流设计问题。我的解决方案是给它们划清边界：

• 官方 Codex 负责"大改"：重构、跨模块、项目级任务；
• Cline/Aider 负责"小活"：格式化、局部修 bug、补测试；
• 同一个文件同一时刻只允许一个 Agent 写，另一个要用必须先看 git status 确认没有未提交改动。

实际操作中，我会在提示词里直接加一句"修改前先检查目标文件是否有未提交改动，若有，先报告再操作"。这句话成本很低，但能挡住一大半冲突。

5.3 现象：提示词越长，Codex 越笨

这是一条让我印象很深的教训。一开始我觉得提示词写得越详细越好，把历史背景、技术栈、约束条件全都堆进去，结果 Codex 反而抓不住重点，输出变得啰嗦且经常答非所问。后来我做了个对比实验：同一个任务，一段 300 字的提示词和一段 60 字的提示词，后者完成度反而更高。原因很快想明白：模型对长文本里的关键指令是有注意力衰减的，尤其是"角色""约束"这类元信息放在最前面，真正的任务藏在最后，它的执行重点就会偏移。现在的处理方式是"任务前置、约束后置、背景按需补充"：

先把任务说清楚，再说格式，最后补一句背景。 如果模型问起背景，你再追加，不用提前全部交代。

这条经验对上面所有插件提示词都适用——模板是帮助统一的，不是让你无脑填满。

6. 我现在的工作流：插件是辅助，提示词是灵魂

写了这么多，最后分享一下我自己的日常吧。早上打开项目，先看 Todo Tree 的侧边栏，把今天的任务按优先级排好。需要大动的部分，我会复制对应的模板到官方 Codex 面板，补充"涉及文件"和"验收标准"，让它开工。小修小补、加个测试、写个注释，这些直接交给 Cline 或者 Continue，我不守在旁边等。改完一波代码，AI Commit 把提交信息生成好，GitLens 确认变更范围，没问题就提交。整个流程里没有一步是"非某个插件不可"，但少了它们任何一个，我都会明显感觉到效率降一截。

6.1 早上先喂 TODO，不喂空泛指令

不要一上来就打开 Codex 说"帮我看看项目"。我现在的习惯是：前一天晚上把第二天要做的事，用 TODO 注释写进代码里，第二天直接让 Codex 读 TODO 列表。这样任务有上下文、有位置、有目标，模型的完成质量高出很多。提示词也有迭代：同一个模板用久了，我会根据实际输出效果微调，删掉那些"模型总是忽略"的句子，留下真正影响行为的关键句。

6.2 晚上花十分钟复盘提示词

每天收工前，我会花十分钟看今天哪段提示词效果好、哪段失效了。失效的往往不是模板本身，而是项目状态变了：新增了模块、改了目录结构、换过依赖，AGENTS.md 里的描述过时了。这时候更新一下文档，比明天临时补救省心得多。插件可以一直稳定地装在那里，但提示词必须跟着项目长。

最后说一句实在的：这 10 个插件不是什么银弹，真正让 Codex 好用的，是你对项目的理解，和你把理解写进提示词的习惯。插件只是把这句话落到编辑器里的载体。我见过不少人装了一堆插件之后，反而被工具牵着走，每天调试插件的时间比写代码还多。其实稳下心态来，把少数几个工具用透，再配上一套能迭代的提示词，Codex 才能从"玩具"变成"队友"。