Codex实战指南：从环境搭建到质量控制的AI编程助手使用全攻略

1. 先别急着写代码，搞清楚 Codex 到底是个什么"工种"

过去大半年，AI 编程工具从一个"玩具"迅速变成了很多团队的真实生产力。但每次看到有人把 Codex 和 Copilot、Cursor 之类的东西摆在一起比较，我都觉得有点不太对劲——它们压根就不是一个物种。

Codex 的定位不是"自动补全代码的输入法"，也不是"帮你管理多个文件的 IDE 插件"。它更像是一个能理解自然语言、能自主规划任务、能调用工具链、能批量修改工程代码的"机器人开发实习生"。你给它一句"帮我给用户模块加上限流"，它不是只给你贴一段代码，而是会自己去看项目结构、找到相关文件、分析现有逻辑、设计改动方案、执行修改，然后把变更记录告诉你怎么验证。

那这个定位有什么实际意义？我理解下来有三点直接改变了我们的工作方式：

• 我们和代码的交互方式，从"写"变成了"审"和"改"。
• 我们能分配的活，从"一个函数"变成了"一个功能模块"甚至"一条业务链路"。
• 我们的角色，从"编码者"变成了"需求拆解者和验收者"。

所以这篇文章我不会去教你几条炫技的 prompt，而是站在"怎么把 Codex 真正用进日常开发流程"的角度，把我在各种项目里用下来的完整套路、翻车现场、配置思路和验收手段全部摊开来讲。里面没有任何一点是"看官方文档就能知道"的东西，全是实打实用出问题之后总结出来的经验。

适用人群我直接说清楚：如果你还在纠结“AI 写出来的代码能不能用”，这篇文章对你可能还太早；但如果你已经在用 AI 写代码，并且觉得"总差那么点意思"，那这篇文章就是给你准备的。

2. 搭建运行环境：这一步的细节决定了后面 80% 的体验

很多人拿到 Codex 的第一件事就是打开网页版开始聊天。我不反对这样做，如果你想让它快速帮你生成一段脚本、解释一段报错，网页版足够好用。但如果你打算把 Codex 用在真实项目、尤其是多文件工程里，我强烈建议你把它跑在本地环境里——本地跑和网页跑完全是两码事，下面细说。

2.1 本地运行的优势：能吃到你项目的"上下文"才算真正干活

这是我反复跟身边同事强调的一点：Codex 在本地运行时，可以读取你工作目录下的真实文件内容、目录结构、git 状态，甚至能自己跑测试看结果。而网页版只能依赖你手动粘贴的代码片段。对于像"给我 refactor 一下登录模块"这种任务，前者是真正在看工程，后者只是在看文字。

实践下来，本地环境的优势主要体现在这几个地方：

• 它能看到package.json、requirements.txt、go.mod这类依赖清单，改代码时会主动考虑依赖关系。
• 它能利用git diff知道你到底改了什么，配合你的 review 更高效。
• 它可以直接调用终端执行命令，比如python manage.py migrate、npm run lint，把"改代码"和"验证代码"串起来。
• 因为运行在你的工作台里，所以它能在多个会话之间保持项目状态的一致记忆，不会出现网页版那种"换个窗口就失忆"的割裂感。

2.2 环境准备清单：照着抄就行

我用的主力环境是 macOS + Python 3.11，如果你用 Linux 或 Windows，原理一样，只是个别命令不同。完整准备步骤如下：

1. 安装 Codex CLI 工具（我用的包名是codex），通过npm install -g @openai/codex或brew install codex安装，这里不同系统的差异比较大，建议直接看官方 README。
2. 配置 API 认证环境变量，我用的是OPENAI_API_KEY，官方也支持通过配置文件指定 key。
3. 准备一个独立的测试目录，别一上来就在生产环境的主分支上跑，先用一个临时项目练手。
4. 起步阶段建议把 Codex 的"自动执行命令"能力关掉（后面会详细说怎么关），改成每个命令都先征求你同意，避免它擅自把项目搞得一团糟。

我的建议是专门建一个~/codex-lab/目录，里面放点小项目、脏代码、过时的接口调用，专门拿来"折腾"Codex。我见过很多人拿生产项目做 AI 实验，跑坏了然后一锤子定论"这工具不行"——其实不是工具不行，是你没给它一个安全的试错场。

2.3 首次运行验证：别急着干活，先做一次"体检"

环境配好后，先不要直接丢任务进去。我习惯跑一轮基础验证，确认 Codex 真的读到了我的项目信息：

codex "请列出当前项目的关键文件，并简单说明每个文件的作用"

然后观察它的回复是不是基于你目录里的真实文件。如果它开始一本正经地编一个压根不存在的auth.py，说明它可能没有正确加载项目上下文，这时候要检查启动目录和权限配置。如果回复里准确提到了你的文件结构，甚至分析了某段代码的问题，那就说明环境基本没问题。

重要提示：首次验证时一定要在只有基础文件的干净目录里做，不要让它扫描到敏感配置。Codex 会把读取到的文件内容作为上下文发送给服务端，你要确保工作目录里没有不该带出去的机密信息，比如.env文件、生产数据库密码、私钥等。我习惯在项目根目录的配置文件里显式忽略这些文件。

3. 任务描述的正确姿势：从"写一段代码"到"交付一个变更"

这一节我想重点讲讲调教 Codex 的核心——怎么把你的想法翻译成它能"执行"的任务。说实话，我看过太多人用了几个月 Codex，但效果一直不稳定，问题几乎都出在这里：他们给的是"愿望"，不是"任务"。

3.1 为什么"帮我写个登录接口"是不够的

把"帮我写个登录接口"丢给 Codex，它确实能生成一个接口。但仔细一看，很大概率没有输入校验、没有错误处理、没有 token 逻辑、没有数据库事务管理。然后你还得花半天去改它生成的代码——那你到底图什么？

我自己的经验是：Codex 非常适合"执行具体而明确的任务"，它的长板是把一个中等规模的、边界清晰的改动高效落地；它的短板是"脑补"需求。你描述得越模糊，它脑补得越离谱；你给出的验收条件越明确，它交付的代码越接近你想要的东西。

所以后来我养成了一个习惯：把任务描述当成"给外包开发写需求文档"来写。明确三点——改哪个文件、做成什么行为、怎么算做完了。

3.2 一个标准的 Codex 任务描述长什么样

我以"给用户模块加个简单的限流"为例，给你看一下我实际用的任务模板：

• 目标描述：在/src/api/user_router.py里给登录接口POST /api/users/login加上 IP 级别的限流，同一 IP 每分钟最多 10 次请求，超出的返回 429。
• 实现建议：项目里已经装过slowapi，直接用它，不需要新引入依赖；按项目现有的错误响应格式返回 429。
• 验收标准：修改后运行pytest tests/test_login.py -v能通过；在接口文档或单元测试中体现限流规则。
• 边界条件：不要动token生成逻辑；不要修改数据库模型；不要影响其他接口。

你会发现这个描述里，我把"怎么做"也讲了一部分。有人可能会说，这不就是把活全干了吗？其实不是——Codex 的价值不在于帮你从零到一，而在于帮你把已经想清楚的改动快速落实。你省掉的是写代码的时间，而不是思考的时间。想不清楚的时候，别急着甩给 Codex，先花十分钟把需求理清楚，这十分钟在后面能帮你省一小时。

3.3 任务拆解与计划确认：让 Codex 先"说思路"，再动手

真正进阶的一步是：让 Codex 先出计划，你确认后再执行。我一般在任务描述后面加一句：

请先简要列出你的修改计划，包括需要改动的文件、每个文件的大致改动点、以及你的测试方案。等我确认后再开始动手。

这一步的好处有两个。一是你可以提前发现它的理解偏差，比如它打算改的表结构不是你想改的、它想用的库和你预期不一致，这些如果等代码写完了再发现，返工成本就是十分钟起步；二是它会因为"待确认"而更谨慎，给出的方案往往更加保守和贴合现有工程结构。

第一次用的时候可能会觉得"多此一举"，但当你连续体验过几次"它写了一堆但方向完全跑偏"的尴尬之后，就会明白：计划确认这个环节，是人和 Codex 协作里最值钱的一步。

3.4 六类高成功率的任务模板

根据我大量实测，以下六类任务描述模板的成功率最高，可以当脚手架直接套用：

3.5 高级技巧：把"做事方式"写进全局指令

Codex 支持全局配置或者项目级指令文件（比如AGENTS.md或类似说明文件），里面可以写"你说的话对每一次任务都生效"。一定要利用好这个机会。

我自己的全局指令里写的是这些内容：

- 在修改任何代码前，先阅读相关文件全文，不要凭记忆猜测。 - 优先复用项目现有工具和函数，不要凭空引入新库。 - 遵循项目现有的代码风格，不要大规模重排格式。 - 修改后必须运行相关测试；测试失败时要回头修复，不得跳过。 - 如果发现需求描述与实际代码不一致，先停下来问我。

写完之后，你会发现 Codex 的"靠谱程度"上了一个大台阶。因为它每次都会先读文件，而不是凭训练数据里的"印象"编写；它不会自作主张引入你项目里没有的库；它也不会因为测试挂了就假装没看见。这些约束本质上就是在把"AI 自动生成"变成"AI 受控执行"。

4. 命令执行与文件修改的边界控制：守好安全红线

如果说任务描述决定的是 Codex"做什么"，那么权限和边界控制决定的就是"它敢怎么做"。这一部分我建议所有要把它引入正式项目的人反复读三遍。

4.1 三种工作模式：全自动、半自动、纯建议

我实际用下来，Codex 大体支持三种工作模式，不同的项目阶段要选不同的模式：

• 全自动模式：Codex 自动分析上下文、自动修改文件、自动执行命令，每一次动作不会停下来问。这种模式的产出效率最高，但风险也最大，适合一次性任务、隔离环境或者测试项目。
• 半自动模式（我主力推荐）：Codex 在修改文件之前要经过你的批准，在执行 shell 命令时也先给出命令和预期结果说明，等你确认后执行。这种模式让你对每一步都有掌控，又能省掉大部分手写代码的时间。
• 纯建议模式：Codex 不做文件修改也不执行命令，只给出修改建议、期望的代码 diff 和命令解释。适合做设计评审、培训、探索性提问。

我在真实项目里几乎只用半自动模式，只有遇到特别明确、特别独立的任务（比如"批量把 A 文件里的log(x)改成logger.info(x)"）才会切全自动。在尚未完全了解一个项目的改动波及面之前，任何"全自动+生产项目"的组合都是一种赌博。

4.2 需要特别小心的三类命令

Codex 在执行 shell 命令时，能力相当强。它不止会跑python test.py，还可能会执行git reset --hard、pip install、npm run build、rm -rf这类危险操作。如果开了全自动，这些命令会在你眼皮底下直接执行。

我在测试环境里专门验证过几类高危命令，结果如下：

4.3 通过 SDK 接口做精细权限控制

如果你是团队的技术负责人，希望给 Codex 配置更精细的权限边界，走在"能力开放"和"风险控制"之间，那么我的做法是：不要只依赖 CLI 的交互式确认，而是通过 SDK 接入自己的控制逻辑。

比如我封装过一个小工具，大致逻辑是：

• 拦截 Codex 即将执行的每条 shell 命令。
• 用一个白名单/黑名单规则集过滤：npm run build、pytest这类放行；rm -rf、sudo、git push --force这类直接拒绝。
• 对数据库命令强制走只读账密，并且只能连接测试库。
• 所有文件修改，先在内存里生成 diff，再等人工确认才落盘。

这里有个关键认知：权限控制不是为了防 Codex "恶意"，而是为了防它 "误判"。Codex 没有主观恶意，但它在理解上下文不完整时，会做出在你看来完全离谱的决策。你给它搭好护栏，它才能在护栏内发挥最大的价值。

5. 让 Codex 写出"能用到生产环境"的代码：质量控制的四个关卡

很多人说"AI 生成的代码只能写 demo"。这话对也不对——如果你直接把 Codex 第一次生成的代码扔进线上，那确实只能算 demo；但如果你把它当成一个需要 review + 测试 + 修正的"初级工程师"，结果会完全不同。

5.1 第一关：让 Codex 自己先跑测试

以前我给 Codex 下任务时，它的习惯是"只写代码不管验证"。后来我在全局指令里明确要求："修改后必须运行 related tests；如果测试挂了，必须回头修复；如果修复不了，把所有现象贴出来报告。" 加了这句话之后，产出的代码质量提升了一个量级。

你可能觉得这不就是"让它跑个测试"吗？实际执行中差别很大：

• 它会主动检查测试文件是否存在，没有测试文件的模块，它会提醒你或者自己补充测试。
• 它会主动处理测试环境依赖，比如缺少某个 fixture 时，它会先尝试创建。
• 它跑测试失败后，会自己看堆栈、分析原因、改代码、重新跑，整个循环不需要你介入。

有一次我让它修复一个线上偶发报错，它花了两轮测试失败循环，最终定位到是并发条件下一个共享变量没有加锁。我完全没给任何提示，它只是根据测试失败日志一步步排查出来的。这个体验让我意识到：AI 编程工具的价值密度不在于"一次生成的正确率"，而在于"试错循环的速度"——它一分钟能跑完你一小时才能跑完的探索路径。

5.2 第二关：代码审查不能少，但审查重点要变

Codex 写得再好，我也坚决不跳过 code review。只是审查重点变了：以前我逐行看"语法对不对、逻辑对不对"，现在主要看"它是否理解了我的业务意图"。

具体我会检查这几个点：

• 有没有过度设计：比如一个简单的状态判断，它可能引入了一个完整的状态机库，这就属于"没能理解项目规模"。
• 有没有破坏隐性约定：比如项目里一直用user_id的变量命名，它可能按自己的偏好改成了uid，这种看起来小、实际上伤害一致性的点，最容易漏。
• 有没有绕开原有架构：比如项目统一走 service 层，它可能直接在 controller 里写业务逻辑。
• 异常路径是否覆盖：AI 生成代码经常忽略"数据库连接失败""上游返回空"这类边界场景，重点检查这些地方。

5.3 第三关：让 Codex 解释它的设计决策

一个我用了觉得很有效的小技巧：在 Codex 完成修改后，追加一个问题——

请解释一下这次改动里最关键的设计决策，以及你在哪些地方做了权衡取舍。

这不是形式主义。当它解释的时候，你会真的发现它是否理解了自己写的代码。有时候它会说"这里我用了缓存，因为接口在这个场景下高频调用"，这时候你会确认它有全局观；但有时候它会支支吾吾，或者说"这个地方我沿用了现有模式"——一查，现有模式根本没这个用法。遇到后一种情况，基本就可以判定这段代码需要重点盯防。

这招本质上是让 Codex 变成它自己代码的"答辩人"，而你是评审委员会的专家。问它"为什么"，不是为了教它，而是为了让你更快发现它哪里想错了。

5.4 第四关：用 git diff 收尾

最后一道关卡，是将 Codex 的改动和原有代码做 diff。通常我做完上述步骤后，会执行：

git diff --stat git diff

然后从头到尾看一遍。什么时候可以放心合并？我的标准是：如果你能说得清楚每一段 diff 是干嘛的，这段改动就可以合；如果你看到某段 diff 内心是"这改的什么东西"，立刻拉出来问 Codex。不要把问号留到合并之后，到时候排查起来成本翻倍。

6. 避坑实测记录：那些年 Codex 给我挖的"坑"

以下内容我尽量不抽象讲道理，全部用我实际踩过的场景来还原。每一个坑背后都是一次真实的教训，希望你看到之后能躲开。

6.1 坑一：它"自信地"编造了一个不存在的 API

有一次我让它对接一个第三方数据服务的 SDK，项目里实际用的是v2版本接口，文档里有一个get_transaction_list方法。Codex 直接写了个get_transactions的调用，运行时会报错。我第一反应是"这工具不行"，后来意识到——它可能并没有真的去读 SDK 的源码，而是根据训练数据里的"印象"在生成代码。

后来我的修复方法很朴素：在任务描述里显式要求"所有外部 API 调用必须先从项目源码或依赖包中确认真实方法名和参数，再写代码"，并在全局指令里写死这条规则。从那以后，这类"幻觉式 API"的出现概率低了很多。

6.2 坑二：批量重构时把全局搜索替换做成了"无差别打击"

我有一次让它把旧日志库的调用方式统一替换成新写法。结果它用了一个全局字符串替换，把注释里、文档里、测试用例里所有匹配到的内容全都替换了，连别人代码里本来引用旧库的地方也没放过。最后的 diff 看得我头大，回滚重来。

核心问题出在"没有明确范围"——我以为它默认只改.go源文件，它却把.md文档和测试文件都改了。修复方式是：在任务描述里写上"只修改.go文件，排除test目录和所有文档文件"，范围界定了，它也就老实了。

6.3 坑三：测试"假绿"

这是我特别想提醒的一个坑。Codex 跑测试，结果返回了一段"通过"，但你把输出拉起来细看，发现它其实只跑了测试用例里的第一个函数；或者它把测试命令给包装了，根本只执行了一个空测试集。这比"测试挂了"更隐蔽，因为它会给你虚假的安全感。

我现在的处理方式是：在全局指令里要求"运行测试时必须展示完整命令和输出末尾的状态摘要，不得省略执行过程"。然后我在复核时会特别看一下它跑的是"哪个文件里的哪几个用例"，数量对不对。一旦发现执行过程对不上，就要求它重新跑并贴出完整日志。

6.4 坑四：小项目里"引入重型依赖"的冲动

让 Codex 做一个简单配置解析，它二话不说引入了整个pydantic-settings；让它做一个定时任务，它引入了celery。这种"杀鸡用牛刀"的倾向，在我用过的多个 AI 编程工具里都普遍存在。原因也好理解，训练数据里"专业项目"的比例远高于"玩具项目"，所以它默认就往工程化方向写。

应对方法就是全局指令里那句"优先复用项目现有工具和函数，不要凭空引入新库"。如果确实需要新增依赖，它必须先写清楚"为什么现有的方案解决不了，新增依赖的维护成本是多少"，审批通过后才能引入。

6.5 坑五：多轮对话后陷入"自我怀疑循环"

有一次我让 Codex 修一个偶发 bug，它跑了五六轮测试，每次修完又出现新的问题，然后又回头改前面已经改过的地方，最后把自己绕晕了，把一段正常逻辑给"修"坏了。

这个问题的本质是：Codex 在多轮试错中，上下文里的"历史包袱"越来越重，容易在局部优化里迷失全局。我的处理方式是：当它连续失败超过三轮时，让它"停下来，不要继续改代码，先总结目前尝试过的方案和失败原因，再等待我的新指令"。这个"熔断机制"非常管用，多数情况下暂停重梳理之后，重新出发反而很快解决了问题。

7. 用 Codex 重构一个旧模块的完整实战复盘

光讲方法论太干了，这一节放一个我最近做过的真实案例，把整个流程从头到尾走一遍。项目背景是某个内部系统的订单模块，代码写于三年前，里面一个核心服务类有 2000 多行，很多逻辑散落在各个方法里，想加一个新功能但几乎无人敢动。

7.1 需求拆解与任务设计

我并没有直接把"重构订单模块"这种史诗级任务丢给 Codex。任何靠谱的工程师都知道，这种规模的改动必须拆解。我一开始的任务设计是：

• 第一步：让 Codex 阅读整个订单模块，产出一份结构说明文档，标记出它认为"高复杂度、高耦合"的部分。
• 第二步：基于文档，我们把重构拆成了四个子任务：抽离订单状态机、整理支付回调逻辑、统一异常处理、补全核心场景测试。
• 第三步：每个子任务单独走一轮 Codex 修改 + 测试 + review 的循环。

最开始我期望 Codex 直接给我一份完美的"手术方案"，后来发现它更适合"你切好口子，它负责缝合"。所以我的角色是拆解和定义边界，它的角色是高效执行和快速验证。人定方向，AI 迭代，这个分工才是最高效的组合。

7.2 重构过程中的关键节点

第一轮，我让它阅读模块并输出文档。它给了一个 600 行的 Markdown，把订单状态流转、支付回调链路、异常分支都梳理得很清楚。更重要的是，它主动指出"支付回调里有一个隐藏的并发问题：回调可能被重复调用，但当前逻辑没有幂等保护"。这个发现不需要它改代码，但直接让我决定把"幂等处理"纳入重构范围。

第二轮，抽离状态机。这是整个重构里最有风险的一步。Codex 在拿到我的计划确认后，动手改了两个文件，把原来散落在四个方法里的状态迁移逻辑收敛到了一个独立类里。改完后我跑了一遍原有的测试套件，全绿，那一刻我心里才真正放下了一半。

第三轮，处理幂等。Codex 给出的方案是"在回调表里增加唯一约束 + 捕获重复键异常后直接返回成功"。方案不花哨但够用。我 review 后觉得符合现有架构，就让它落地了。

第四轮，补测试。它自动生成了 17 个新测试用例，覆盖了正常流程、重复回调、状态非法转移、异常输入等场景。我抽查了几个用例，没有看到"为凑覆盖面而写的假测试"。

7.3 复盘结果：值得关注的量化数据

重构前后对比：

这个数据当然有"结构性问题"——旧代码本来就是历史包袱，重构必然会提升指标。但我真正想强调的是：Codex 在整个过程中没有提出过一项超出边界的"惊人之举"，它踏踏实实地完成了每一轮的拆解任务。这恰恰是它最有价值的地方——不是多聪明，而是稳定、可控、能重复。

8. 进阶玩法：扮演代码评审员、文档工程师和面试官

到这里，Codex 的基础用法已经讲得差不多了。但我觉得真正拉开人与人差距的，是你有没有把它当成一个"多角色助手"来用。下面这三个进阶场景是我日常工作中用得最多的，分享给大家。

8.1 让 Codex 当"毒舌评审员"

一个人写代码太容易陷入"自恋陷阱"。有一次我写完一个 PR，自我感觉良好，然后顺手把它丢给 Codex，让它"以项目维护者的身份，严厉 review 这段代码，挑出所有可能导致线上事故的问题"。结果它一口气提了 8 个问题，其中两个我确实没想到：

• "这里调用外部服务，没有设置超时时间。一旦上游变慢，你的接口会拖垮整个线程池。"
• "这个分支的在极端并发条件下，存在竞态条件，建议加锁或改用原子操作。"

从那以后，我养成了习惯：每次提交 PR 前，先让 Codex 以"恶意评审者"视角过一遍。它可以扮演安全工程师、性能工程师、架构师等不同角色，而且每次都能从不同角度给出有价值的问题。这对那些没有专人做 code review 的独立开发者来说，几乎等于白捡了一个免费顾问团。

8.2 让 Codex 当"文档工程师"

很多开发者讨厌写文档，我也不例外。但现在我找到一个高效的办法：让 Codex 读代码，然后生成技术文档初稿。包括 API 文档、模块说明、数据字典、环境部署文档等。

但注意，这里有一个关键操作：让 Codex 读完真实文件再写，而不是让它"想当然"地写。比如我要给某个接口写文档，我会让它"读取views.py里的OrderViewSet类，根据代码中的路由映射、序列化器定义和权限类，生成一份 API 文档，包含请求参数、响应示例、错误码"。这样产出的文档和代码是强一致的，而不是靠训练数据"虚构出来的"。

8.3 让 Codex 当"面试官"

这个用法有点取巧，但我实际试过很多次，非常推荐。我准备面试某新技术方向时，会让 Codex 扮演面试官，对我的理解进行提问。比如：

请针对"分布式事务"这个话题，从浅到深向我连续提问，判断我对相关概念的掌握程度。当我回答完一个问题后，请评价我的答案，指出其中不准确或遗漏的地方，然后继续下一个问题。

它会像真正的面试官一样，从 CAP 定理问到两阶段提交，再到 TCC、Saga、本地消息表，最后还会给出综合评价。这种方式比看文档高效得多，因为它是对话式的，会逼你用自己的话组织知识。如果你在某道题上答得漏洞百出，它还会精准地指出漏洞在哪，等于一边面试一边给你上课。

9. 面对"Codex 会不会取代程序员"：聊聊我的真实判断

每次聊完工具本身，总绕不开这个话题。我的观点是：Codex 短期内不会"取代"程序员，但它会显著改变"程序员这个岗位的日常构成"。

在我看来，被淘汰的不会是"写代码的人"，而是"只会写代码的人"。真正稀缺的能力会变成这三样：

• 精确描述需求的能力：能把模糊的业务想法，翻译成 Codex 可以执行、可以验收的任务。
• 识别与取舍的能力：能判断 AI 哪些方案合理、哪些方向跑偏，并做出正确的取舍判断。
• 系统性思考的能力：能保证 AI 的每一次改动都服务于全局架构的一致性，而不是局部最优。

所以我的建议是：与其焦虑被替代，不如把 Codex 当成一个"永不疲倦、反应极快、偶尔抽风"的结对程序员。你负责带节奏、定方向、做决策，它负责打字、试错、跑腿。工具解放的是你的时间，而不是你的大脑。把被解放的时间用在更复杂的系统设计、更深入的业务理解和更周全的质量把控上，这才是这场效率革命的正确打开方式。

10. 最后分享一点我的个人工作习惯

写到最后，分享几个我每天实际在用的、非常简单但异常有效的习惯：

• 每天开工前，把当天想做的 1~3 个编码任务按上面说的格式写好任务描述，让 Codex 先出计划，我审核后再开工。
• 每次 Codex 完成修改，必须先让它自己跑一遍相关测试，再把 diff 给我看，不接受"只给结论不给过程"。
• 遇到连续三次失败或方向跑偏，立刻叫停，让它总结当前状态，绝不抱着"再试一次就能好"的心态硬刚。
• 重要项目或者重要改动，一定开半自动模式；除非是隔离的实验项目，否则我不太用全自动模式。

按这套方式来用，Codex 在我这边已经是一个相当稳定的"生产级队友"。我写这篇文章的目的也不是为了吹某个工具，而是想告诉大家一件事：AI 编程工具好不好用，真不在于模型有多强，而在于你有多会"用它干活"。一个能把工具用透的人，和只会拿工具当玩具的人，产出的差距比任何模型升级都要大得多。