Codex不撞墙：网页版ChatGPT与Codex混合工作流实战指南

上个星期我写一个内部小工具，写到一半，Codex 的窗口突然弹出了额度限制。盯着终端里那个半成品函数，我愣了一下，然后下意识打开了网页版 ChatGPT，把刚才的需求重新描述了一遍。这个动作如今已经成了我的肌肉记忆：Codex 负责在仓库里动手，网页版负责在对话里出代码、出方案，两边一配合，反而比以前只盯一个工具顺手得多。

这篇内容写给两类人：一类是 Codex 用得正爽、但额度总不够用的开发者；另一类是只有网页版 ChatGPT、但想用它把写代码效率拉满的朋友。我会讲清楚我的任务分流思路、提示词技巧、完整实操案例，以及这套混合工作流里我踩过的坑和排查方法。全程不聊理论，只讲能直接抄作业的东西。

1. 为什么额度总是不够用：先摸清两个工具的脾气

1.1 Codex 的优势与额度瓶颈

Codex 这类工具最吸引人的地方，是它在本地仓库里干活的能力。它能读文件、改代码、跑命令、根据测试反馈迭代，你可以直接说“帮我把这个路由加上参数校验”，它自己会去找路由文件、确认上下文、完成修改。这种感觉就像身边坐了一位能自己动手的实习生，你只需要给方向。

但代价就是额度。写代码这种需求，尤其是改动多、来回调试的任务，一次会话可能要消耗相当多的量。我之前一旦进入“重构旧代码”的状态，动不动就连续开好几个会话，经常到下午就撞上限。额度恢复又要等很久，最怕的是活干到一半卡住，那种体验比不用 AI 还难受。

我自己总结的规律是：Codex 的额度适合用来做“需要碰仓库”的收尾工作，而不是用来做头脑风暴和生成骨架。你把它的额度花在从零生成十个小函数上，那真正需要它去跨文件改代码的时候，就只能干瞪眼。

1.2 网页版 ChatGPT 的定位差异

网页版 ChatGPT 在文件操作上当然比不上 Codex，它没有仓库上下文，也不会帮你跑命令。但它在另一个维度上非常强：你给它一段需求，它就能直接产出完整可运行的代码片段；你觉得不满意，它可以重新生成、逐行解释、换一种实现方案再给你。交互成本低，反复重来也不心疼。

而且网页版通常有相对宽裕的用量窗口，至少在对话窗口里聊代码这件事，很少会因为“额度不足”而中断。对我来说，它更像是外脑和白板：先把逻辑理清楚、把代码骨架生成好，这一步消耗的是我的耐心和提示词功夫，不是 Codex 的额度。

这里有个容易忽略的点：网页版没有仓库上下文，所以在对话里生成的代码往往是“通用版本”。它的优势反而是这个——正因为不考虑你现有代码的耦合，它给出的方案更独立、更模块化，方便你拿来对比、裁剪、重新组装。

两个工具的定位差异，我列了一张表：

2. 任务分流：把活分给对的工具

2.1 适合 Codex 干的任务

我默认把三类任务留给 Codex：第一类是跨文件改动，比如把一个工具函数接入到多个路由里，或者调整某个公共组件的接口，这种任务必须基于仓库全局信息来做；第二类是依赖命令的迭代，比如跑测试、检查报错、启动服务看效果，这些是网页版替代不了的；第三类是端到端的小功能，比如“在设置页新增一个开关，并持久化配置”，涉及文件多、步骤杂，Codex 一次性完成更高效。

举一个例子：有次我需要把项目里所有硬编码的接口地址改成从配置文件读取。这个改动看起来简单，但涉及十几个文件，还有不同模块的引用方式差异。如果我用网页版，得一个个文件去拷贝、改、再验证，非常容易漏。而 Codex 可以直接说“帮我全局替换，并保留两个特殊情况的处理”，它能自己找出所有相关文件，逐个修改，最后还会帮你检查有没有遗漏。

这类任务的特征是：强依赖本地环境，需要在真实代码库中反复试探。你应该优先把额度花在它们身上。

2.2 适合网页版干的任务

网页版适合的任务更偏向“独立答案型”。最典型的是：生成一个独立的函数、写一段数据处理脚本、把一段逻辑翻译成另一种语言、写正则、写 SQL、解释一段看不懂的代码、给某个报错做排查建议。

我之前要做一批 Excel 文件的批量合并，业务很简单，但代码要从零写。这种任务丢给网页版最合适，我把列名规则、合并策略一说，它给我一份 Pandas 脚本，我在本地一跑就通过。整个过程没碰仓库任何老代码，也完全不需要 Codex 动手。

另一个很适合网页版的场景是代码审查。把一段写好的代码贴给它，让它“从性能和边界条件角度找问题”，通常能发现一些自己忽略的细节，比如空列表、文件编码、异常分支。这一步做得好，后面 Codex 落地的时候返工率会大大降低。

2.3 我的默认分流规则

时间长了，我总结出一个很简单的决策顺序：先问自己“这个任务需不需要动本地文件”。

需要动文件、需要跑命令的，直接留给 Codex；不需要动文件、只要答案的，网页版先上。如果网页版把代码生成到八十分，我再拿这个结果进 Codex 做整合。这样角色就清楚了：网页版是草稿纸，Codex 是施工队。

我现在甚至会刻意在额度充足时也这样分流，而不是等到 Codex 撞墙才切换。因为网页版生成的代码是“中立版本”，不掺入现有代码的风格包袱，有时候反而能提供更干净的实现思路。

3. 让网页版写出能直接用的代码：提示词与上下文技巧

3.1 先把项目背景交代清楚

网页版没有你的仓库文件，它就靠你给的那几段文字来猜。很多人直接丢一句“写一个下载函数”，得到的代码自然泛泛。你至少要说清楚：语言和框架、依赖版本、输入输出格式、编码风格、边界约束。

我一般会维护一段“项目背景模板”，每次开新对话先贴一遍，再讲本次需求。这个模板可能长这样：

项目说明：这是一个 Flask 后端服务，Python 3.10，代码风格遵循 PEP8，行宽 88。 关键依赖：flask、sqlalchemy、pandas、pillow。 目录结构：app/ 放业务代码，routes/ 放路由，tests/ 放测试。 现有约定：接口统一返回 JSON，错误格式为 {"code": xxx, "message": "..."}。 我需要的功能：……（这里描述本次具体需求）

背景信息越具体，生成的代码贴合度越高。之前我项目里用了 SQLAlchemy 的 declarative_base，我贴了这句之后，网页版生成的模型类代码直接用对了基类，我基本没改就能用。如果你什么都不说，它默认给你写一个遗传的示例，你反而要花更多时间改造。

3.2 分文件、分函数提问

我犯过最大的错误，就是让网页版“帮我写一个完整模块”。它确实可以生成，但代码会很长，中间只要有一个细节不符合项目结构，整个模块就废了，改起来比从头写还费劲。

正确的做法是拆碎：先让它写工具函数，再写路由，再写模板，一次只聚焦一个函数或一个文件。每轮对话只给这个函数需要的上下文，比如输入字段、预期输出、现有函数名。这样做有三个好处：准确率高，回答不会被截断，处理起来也方便。

拿生成缩略图这个需求举例，我不会说“帮我做整个图片上传流程”，而是先说“帮我写一个生成缩略图的函数”，让它聚焦在图片处理逻辑上；等这个函数满意了，再单独聊“如何接入上传路由”。每一步验证后再往前走，出错时可以清楚定位到是哪一步的问题。

3.3 代码续写和增量修改的对话策略

网页版无法直接改文件，所以你要修改代码时，得把“当前版本 + 修改目标”一起发过去。我发现一个比较稳的模板是：

当前代码： （贴代码） 需求：在以上代码中新增一个超时参数，默认 30 秒，超时后抛出 TimeoutError。 约束：保持现有函数签名兼容调用方，只输出完整的新函数，不要解释。

注意一定要加“只输出完整新函数”这类控制指令，否则它会给你一堆解释，你还要从里面挑代码，效率很低。另外，网页版在多轮对话后有“记忆漂移”的风险，如果你改到第三轮，它可能忘了第二轮改了什么。稳妥的做法是把最新版本的完整代码重新贴一遍，再提新改动，不要指望它能记住你五分钟前发的上一版。

3.4 用“再检查一遍”代替自己人肉 debug

网页版生成的代码，第一版往往有边角漏洞，比如没处理空数组、没考虑编码问题、边界值少写一个等号。我以前是拿回来后自己人肉排查，后来发现一个更省力的办法：生成之后不要立刻粘贴，而是追问一轮。

这个追问很关键：

请检查以上代码的边界条件和异常处理，列出所有潜在问题，然后输出修正后的完整版本。

这相当于让 AI 给自己做一次代码审查。我实测下来，它能发现自己第一版遗漏的很多情况，比如空列表、KeyError、文件不存在、编码不一致等。而且修正版的代码质量会明显高一个档次，省掉我不少测试时间。

4. 混合工作流实操：一个功能从需求到落地

4.1 场景设定与原始需求

我具体演示一遍我最近做的一个功能：给一个内部后台系统加上“图片上传后自动生成缩略图”的能力。技术栈是 Python 3.10 + Flask + Pillow，仓库里已经有一个上传路由，但图片处理逻辑是缺失的。那几天 Codex 的额度确实用完了，所以我从头到尾走了完整的混合工作流。

原始需求就一句话：“上传图片后，在服务器本地生成一个宽高为 800x600 的缩略图，并返回缩略图访问路径。”听起来不难，但真实落地要考虑的东西不少：图片格式兼容、EXIF 信息导致的旋转问题、缩略图是否保持比例、文件命名冲突、图片损坏时的异常处理等等。

按照我的分流规则，这个任务的第一阶段“设计函数逻辑”根本不需要动仓库，于是我打开网页版开工。

4.2 第一轮：让网页版搭出骨架

我把项目背景模板粘贴进网页版，然后附加了具体的函数需求。我把需要支持的图片格式、目标尺寸、输出目录、异常处理要求逐条列清楚，让它先输出一个独立的缩略图生成函数。

它给的第一版大概是这样的：

from PIL import Image, ImageOps def generate_thumbnail(src_path, dst_path, target_size=(800, 600)): with Image.open(src_path) as img: img = ImageOps.exif_transpose(img) img.thumbnail(target_size, Image.LANCZOS) img.save(dst_path, quality=85, optimize=True)

我一看就放心了，它用 thumbnail 而不是 resize，这点很重要：thumbnail 会自动保持图片宽高比，不会把图压变形。ImageOps.exif_transpose 处理了手机照片常见的旋转问题。

然后我又追问了一轮，让它检查边界情况。它补充了“目标目录不存在时自动创建”“遇到损坏图片时抛出业务异常”这两点，并把完整函数重新输出了一遍。这就是我之前说的“再检查一遍”的价值——第一版函数能跑，但不耐操，追问一轮之后才算是能上生产的版本。

4.3 第二轮：把骨架搬到 Codex 里精修

第二天 Codex 额度恢复后，我把网页版生成的函数代码，加上需求描述，一起丢给了 Codex：

这个函数已经验证过逻辑：generate_thumbnail(src_path, dst_path, target_size=(800, 600))。 请完成两件事： 1. 把它接入现有的 upload 路由，上传成功后调用它，并把缩略图路径加入接口返回值。 2. 写一个 pytest 测试用例，覆盖正常生成和图片损坏两种情况。

Codex 自己打开了路由文件，检查了现有的返回值结构，做了接入，还跑了一遍测试。中间遇到一个问题：现有上传接口把文件保存在 /data/original，但缩略图要放在 /data/thumb，这个目录在代码里没建。Codex 自动加了一个目录初始化逻辑，这个我在原始需求里根本没提，但它从上下文里分析出来了。

这种感觉就是网页版和 Codex 最好的配合方式：网页版把逻辑想清楚，Codex 负责让代码在真实仓库里活起来。

4.4 第三轮：联调与收尾

接入完成后，我自己跑了几遍，发现两个问题。一个是测试时我故意传了一个超出边界的尺寸，缩略图生成后没有按照预期缩放——我仔细看了下，是因为调用时传了 target_size 没注意原图本身尺寸就小于目标尺寸，Pillow 的 thumbnail 不会放大图片，这其实是合理的，但产品经理希望小图也放大。另一个问题是文件后缀大小写不一致，.JPG 的文件保存后后缀小写，导致某些静态文件服务器匹配失败。

这时候 Codex 额度又不太够了，我干脆把这两段问题描述贴回网页版，让它给修补方案。它给出的建议是：

img.thumbnail(target_size, Image.LANCZOS) # 改为强制限制最小尺寸但保持比例： img = ImageOps.fit(img, target_size, Image.LANCZOS)

ImageOps.fit 会直接裁剪到精确尺寸，但保持中心裁剪，适合“一定要铺满”的场景。后缀问题它也补了一个统一转小写的逻辑。这样处理结束后，我没有在 Codex 上消耗额外额度，就把收尾工作完成了。

整个流程走下来，时间分配大概是：网页版出函数 20 分钟，Codex 接入加测试 30 分钟，网页版修补 15 分钟。如果没有分流，全部压在 Codex 上，大概率第一天下午就撞额度了。

5. 常见问题与排查技巧实录

5.1 回答太长被截断怎么办

网页版代码生成到一半就停住，是最常见的问题。尤其是要求“生成完整模块”时，输出长度很容易触顶。解决思路有两个方向。

第一个方向是硬处理：让它“继续”或“从这里接着输出”。如果它忘了自己写到哪，就把它输出的最后一行代码贴回去，让它接着写。这个办法简单，但会话越长越不稳定。第二个方向是根本解决：提问时就限定输出范围，比如“只输出 generate 函数，不要输出导入语句”“只输出核心类，不要示例用法”。把大任务拆成多个小提问，比让它一口气输出几千行靠谱得多。

5.2 代码风格不一致怎么办

网页版不知道你的项目用什么风格，它默认输出的代码可能用双引号，你的项目是单引号；它可能用 4 空格缩进，你的项目是 2 空格。这种问题看着小，但批量改起来很烦。

我的解法是在项目背景模板里直接写清楚风格要求，比如“代码风格遵循 PEP8，行宽 88，使用单引号”。如果生成之后确实不一致，不用自己动手逐行改，直接发一句话：“以上代码请按 PEP8 和单引号风格重写一遍”，它就会重新输出一版一致的代码。

5.3 网页版改坏了代码怎么回滚

网页版没有 Git 能力，它给你的版本不会自动保存。如果你把每次生成的代码直接覆盖进文件，改坏了想回退，会很被动。

我的习惯是：从网页版拿到代码后，先在对话里跟它确认改动的 diff，理解它改了哪些地方，再手动应用到文件里。如果改动比较大，先提交一次 Git，再应用新代码，这样即使改坏了，一条 git checkout 就能回到改前状态。把这个当成固定流程之后，翻车概率低了很多。

5.4 额度恢复后的衔接问题

Codex 额度恢复后，需要把网页版阶段的讨论结果衔接到 Codex。这时候有个容易踩的坑：Codex 看不到你网页版的对话内容，你在网页版聊出的结论、确认过的约束，Codex 一概不知道。如果你只是简单说“按前面讨论的写”，它只能靠猜。

正确做法是把网页版对话里确认过的关键信息整理成一段任务说明，一起丢给 Codex。包括：函数签名、已确认的实现方案、需要接入的文件、需要处理的边界情况。Codex 拿到这些，就能直接干活，不用重新理解需求。

我整理了这张速查表，方便排查时对照：

我个人在实际操作中的体会是：工具本身不是瓶颈，任务分配才是。网页版并不是一个低配的 Codex，它是一个职责不同的角色——一个用来把想法转化成代码原型的白板，一个随叫随到的讨论对象。Codex 则是那个把原型变成工程实现的施工队。把这两者当成一整条流水线来用，而不是互相替代，额度不够用这个问题就会从“灾难”变成“日常流程的一环”。

最后再分享一个小技巧：我在网页版每个会话的开头，都会先写一段“项目背景 + 本次任务清单”，后面再贴代码。这样哪怕聊了几十轮，回头翻聊天记录也知道当时在做什么、结论是什么。这套方法不依赖任何特殊配置，但确实让我的排错效率高了不少。