世界观

03 | 从 IDEA 到 Codex：程序员的工具也该升级了

2026-08-183 min read程序员重生计划

从 IDEA 到 Codex：程序员的工具也该升级了

上一篇《AI 时代，不破不立：我们的旧能力，需要重新编译一次》，主要讨论了 AI 时代程序员的价值观和工作方法正在发生什么变化。

小编认为，我们不能再把自己简单地看成一个“负责写代码的人”。

需求是否合理、方案是否完整、上下文是否准确、风险有没有被识别、结果能不能被验证，这些事情过去藏在编码过程里，现在需要被主动搬到台前。

当开发工作的重心发生变化，我们手里的工具自然也要跟着变化。

过去，我们使用 IDEA、VS Code 完成编码、调试、重构和测试；现在，我们需要开始学习 Codex 这一类 AI 开发工具，把已有的技术知识转换成更大的生产力。

这并不是要扔掉 IDEA，也不是让 AI 接管一切。

从 IDEA 到 Codex，不是开发工具的替换，而是开发方式的一次升级。

一、思想升级以后，工具也要跟着升级

程序员其实一直是最愿意折腾工具的一群人。

为了少写几行重复代码，我们会安装插件；为了快速生成接口，我们会研究代码模板；为了排查线上问题，我们会搭建日志平台；如果现有工具不顺手，过去的程序员甚至会自己写一个。

我们并不排斥工具。

只是当 AI 真正进入开发工作以后，一部分人对工具的态度突然变得保守了。

有人仍然坚持所有代码都必须亲手写，认为这样才算真正掌握；有人把 AI 当成一个加强版搜索框，只在忘记 API 时问一句；还有人虽然装上了 AI 编程插件，但用法仍然停留在“帮我补全下面这段代码”。

这有点像已经买了一台挖掘机，却每天只用它来搬两块砖。

工具没有问题，问题是我们的使用方式还停留在上一个时代。

以前，IDE 主要帮助我们提高“写代码”的效率；现在，Codex 这一类工具开始参与理解项目、分析需求、修改文件、执行命令、运行测试和验证结果。

开发工具正在从“辅助编码”走向“协助完成工程任务”。

如果我们的工作方式没有跟着变化，再强的工具到了手里，也只能变成一个收费更贵的自动补全。

二、 工欲善其事，必先利其器

我们学习一个技能，最简单，最便捷，最快速的方法就是看官方文档。 吃一手饭。而不是吃别人消化过的内容。所以我们就快速的研究下 Codex 中文文档。只挑最重要的说

Codex 的两个重要配置文件

  • config.toml
  • AGENTS.md

它们都会影响 Codex 的执行行为，但两者解决的问题并不相同。

文件主要读者解决的问题格式要求
config.tomlCodex 运行程序Codex 应该以什么方式运行必须符合官方 TOML 配置规范
AGENTS.md执行任务的智能体在当前项目中应该遵守什么规则使用自然语言和 Markdown 表达

翻译成开发者熟悉的话：

  • config.toml 更像程序的配置文件；
  • AGENTS.md 更像项目开发规范；

2.1 config.toml

config.toml 是 Codex 的正式配置文件。

官方配置说明

用户级配置通常位于：

text
1~/.codex/config.toml

项目级配置可以放在：

text
1项目根目录/.codex/config.toml

Codex CLI 和 IDE 扩展会共享这些配置层。项目级配置只有在项目被信任时才会加载，并且越接近当前工作目录的配置优先级越高。如果你把某个项目标记为不可信，Codex 会跳过项目作用域下的 .codex/ 配置层，包括项目本地配置、钩子和规则。用户级和系统级配置仍会加载。

2.2 AGENTS.md

如果说 config.toml 决定 Codex 怎么运行，那么 AGENTS.md 决定 Codex进入一个项目以后应该怎么做事。

AGENTS.md 是写给智能体看的。

它使用 Markdown 和自然语言描述规则，因此格式没有config.toml 那么严格，但这并不意味着可以随便写。

2.2.1 文件优先级

跟 config.toml 一样，配置也有优先级的，这是官方手册。 越靠近当前目录的文件的，优先级越高。【这部分官方文档写的有点绕，官方文档讲的靠后，要看下图。就是越解决当前文件的规则】

text
1全局规则 2 ↓ 3项目根目录规则 4 ↓ 5中间目录规则 6 ↓ 7当前工作目录规则 【最高】

例如：

全局规则：

text
1- 修改 JavaScript 文件后运行 npm test。

项目根目录规则：

text
1- 项目统一使用 pnpm。

支付模块规则：

text
1- 支付模块不要运行 npm test。 2- 改用 make test-payments。

Codex 最终接收到的指令顺序是：

text
1修改 JavaScript 文件后运行 npm test 2项目统一使用 pnpm 3支付模块不要运行 npm test 4改用 make test-payments

因为支付模块规则出现在最后，所以当前在支付模块工作时，应当执行：

text
1make test-payments

2.2.2 读取规则

text
1# ~/.codex/config.toml 2project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"] 3project_doc_max_bytes = 65536

AGENTS.override.md > AGENTS.md > config.toml 中配置的备用文件名

每个目录最多读取一个文件。

假设支付目录中同时存在：

text
1services/payment/ 2├── AGENTS.md 3└── AGENTS.override.md

Codex只会读取：AGENTS.override.md

2.2.3 大小限制

空文件会被跳过。合并后的总大小一旦达到 project_doc_max_bytes 设定的上限（默认 32 KiB），Codex 就不会再继续加入更多文件。关于这些参数，参见 项目指令发现。如果触到上限，可以调大限制，或把指令拆到更深一层的目录中。

2.2.4 空文件限制

如果 AGENTS.md 存在但内容为空，Codex不会把它当成有效指令文件。

它会继续寻找下一个候选文件。

三、项目级必须正确使用 AGENTS.md

Codex 的主要工程化的配置只有这么多，当我们知道了这份武器。现在我们就要充分利用好，这个提供给我们工程化的武器。所以这个小标题是: 项目级必须正确使用 AGENTS.md。这就是让我 Codex 变聪明的关键。你知道，别人不知道，这就是你的优势。AI 时代超级个体的优势，就是这么简单。所以我们需要要尽早建立优势，然后利用优势，扩大优势。

3.1 什么样的信息要放到这里

  • 固化的项目事实文件
    • 技术栈
    • 项目结构和模块职责
    • 安全和数据保护要求
    • 交付结果的输出格式
    • 枚举类信息
    • 关联项目路径
  • 项目中要求个人遵守的约定信息
    • 编码和命名约定

规则越多不一定越好,如果真正重要的三条规则被埋在三百行说明里，和没有写差别也不大。

四、 一定要使用多 Agent能力

组建团队，不要让一个 Agent 包办所有工作。前面的文章里，小编反复强调：AI 时代不要只把自己当成一个开发人员，要开始具备全局思维。

这句话真正落到 Codex 里，就是组建团队。

以前，一个程序员接到需求以后，可能同时扮演很多角色：

  • 需求分析；
  • 架构设计；
  • 后端开发；
  • 前端开发；
  • 测试；
  • 代码审查；
  • 文档编写。

到了 Codex 这里，我们同样可以让一个 Agent 完成所有事情。 但“可以”不代表“应该”。 如果所有工作都塞进一个 Agent，它的上下文很快就会混入大量内容：

text
1需求分析过程； 2项目探索记录； 3技术选型讨论； 4前后端代码； 5测试日志； 6审查意见； 7文档资料。

最后，这个 Agent 看起来什么都知道，实际上任何一件事都不够专注。原因就是这么简单。跟人类是一样的，尽量一个人只专注一个事情。原因就是这么朴素，直白，简单。

4.1 如何组件团队

如果想要所有项目都能共用就定义在用户目录中 ~/.codex/agent。如果只想要某个项目使用就放在 项目/.codex/agent 里面。

示例:

.codex/agents/pr-explorer.toml

text
1name = "pr_explorer" 2description = "只读代码库探索 Agent，负责在提出修改方案之前收集代码证据。" 3model = "gpt-5.3-codex-spark" 4model_reasoning_effort = "medium" 5sandbox_mode = "read-only" 6 7developer_instructions = """ 8始终保持代码探索模式。 9 10追踪真实的代码执行路径，并在结论中引用相关文件和代码符号。 11除非父 Agent 明确要求，否则不要提出修复方案。 12 13优先使用快速搜索和有针对性的文件读取，避免对整个代码库进行大范围扫描。 14""" 15

.codex/agents/reviewer.toml

text
1name = "reviewer" 2description = "PR 代码审查 Agent，重点检查代码正确性、安全性以及测试缺失问题。" 3model = "gpt-5.6-terra" 4model_reasoning_effort = "high" 5sandbox_mode = "read-only" 6 7developer_instructions = """ 8以项目负责人的视角审查代码。 9 10优先检查以下问题： 111. 代码和业务逻辑的正确性； 122. 潜在的安全风险； 133. 行为变化和功能回归； 144. 缺失的测试覆盖。 15 16优先输出有明确代码证据的问题。 17在条件允许时，提供问题复现步骤。 18 19除非代码风格问题会掩盖真实缺陷，否则不要只提出代码格式或个人风格方面的意见。 20"""

.codex/agents/docs-researcher.toml

text
1name = "docs_researcher" 2description = "文档研究 Agent，使用文档 MCP Server 验证 API、配置选项和框架行为。" 3model = "gpt-5.6-luna" 4model_reasoning_effort = "medium" 5sandbox_mode = "read-only" 6 7developer_instructions = """ 8使用文档 MCP Server 确认以下信息： 91. API 的准确用法； 102. 配置选项及其含义； 113. 与特定版本相关的框架行为。 12 13回答应当简洁、准确。 14 15如果文档中存在对应内容，请提供文档链接、章节位置或准确的参考依据。 16无法从官方文档确认的信息，必须明确说明，不要根据经验猜测。 17 18不要修改任何代码或项目文件。 19""" 20 21[mcp_servers.openaiDeveloperDocs] 22url = "https://developers.openai.com/mcp"

使用示例

text
1针对主分支（main）审查此分支。让 `pr_explorer` 映射受影响的代码路径，`reviewer` 识别实际风险，`docs_researcher` 验证该补丁所依赖的框架 API。

4.2 如何定义团队

按职责拆分,而不是按照数量。就好比一个同样的工作，你交给了2个人，如果不是对比结果。而是协同工作。两个人的产出可能就会有冲突。两个人的沟通也会产生误会。

五、