Codex App 新手进阶实战：从聊天框走到真实交付

很多人用 Codex，最后还是把它当成一个更会写代码的聊天框。

会让它写文案、改标题、整理资料，也能让 Codex 跑几个小任务。

但一到真实工作流，问题就出来了：

它到底能不能交文件？ 能不能做一个能打开的网页？ 能不能留下截图、日志、修改记录？ 能不能帮我把一件事从需求推到交付？

上一篇讲的是从 0 到 1：先知道入口在哪，怎么提需求，怎么跑通一个低风险任务。

这一篇往前走一步。

这篇不讲太多概念，只讲三条能落地的训练路线：

• 怎么让 Codex 交真实文件

• 怎么用一个小游戏练完整网页流程

• 以及什么时候可以开始碰 Playwright 这类业务自动化

前两个更适合新手练手，第三个先当作进阶方向看。

你先不用急着做很大的项目。Codex 的进阶路线，最好从“它能不能交出真实东西”开始，而不是从“它能不能替我赚多少钱”开始。

一、办公交付：别只让 Codex 写文字，要让它交文件

很多人用 AI 写方案，最后还是要自己复制到 Word、PPT、表格里，再慢慢改格式。

这里别只让 Codex 给你一段文字。

你要逼它交一个能打开、能截图、能二次修改的文件包。

如果你平时要做活动方案、项目汇报、课程交付、咨询报告、员工培训材料，可以让 Codex 直接生成真实文件，而不是只给你一段 Markdown。

我做过一个演示任务，主题叫《Codex App 内容生产工作流》。提示词大概是这样：

请在当前对话里做一个办公四件套演示任务，主题是《Codex App 内容生产工作流》。要求：生成 Word 文档、PDF 文件、PPTX 演示稿、XLSX 表格四类真实文件； 每个文件都要有实际内容，不要空文件； 生成后告诉我每个文件的真实路径； 尽量生成一个预览或文件清单，方便我截图放进教程； 最后给出验收清单，确认四个文件都存在、能打开、不是占位内容。

我现在判断 Codex 有没有用，不看它回答得多漂亮。

我只看一件事：它能不能交出真实文件、真实页面、真实截图、真实日志。

我现在更建议你这样验收 Codex：

• 文件有没有真实生成；

• 路径有没有写清楚；

• 内容是不是占位符；

• 打开以后排版是否能看；

• 表格有没有真实字段和数据；

• PPT 是否真的能播放；

• PDF 是否能正常渲染。

这条链路跑通以后，很多原来要分给文案、设计、助理、运营的轻量资料生产任务，可以先丢给 Codex 跑第一版。

这组任务我实际跑了一遍。

不是让它在聊天框里说“我已经生成了”，而是看本地到底有没有文件，打开以后是不是正常，截图能不能留下来。下面这几张就是验收现场。

验收结果： 1.Word 文档验收截图：

2.PDF 文件验收截图：

3.PPT 演示稿验收截图：

4.Sheets 表格验收截图：

PPT 这里再补一句。

现在有两条路线比较值得试（当作一个课堂作业吧）：

• 图片型 PPT：让 Codex 生成一张张 16:9 视觉图，再铺进 PPT，适合视觉冲击。

• HTML 型 PPT：用 HTML、CSS、JS 写幻灯片，适合排版控制、动画、截图和录屏。

刚开始不用研究路线优劣。能不能生成一份打得开的 PPT，比“哪种方案更高级”重要得多。

再按你的反馈改三轮，它的边界很快就会露出来。

二、内容生产：从一句话做出一个能玩的网页

第二类实战场景，是内容生产。

这里我不建议一上来就做很大的官网、复杂后台或者完整 App。

更适合新手的，是一个网页小游戏。

比如贪吃蛇、打砖块、躲避障碍物。

这类东西看起来像玩，但特别适合练 Codex。因为结果非常直观，页面一打开，能不能玩，马上就知道。

这比做一个“看起来很高级但不知道怎么验收”的网页更适合入门。

第一次做网页，不要追求完美，先拿到一个能跑的版本。

小网页游戏的好处很现实：

• 反馈快：哪里不好看、哪里太快、哪里有 bug，几分钟内就能发现；

• 可控性强：通常不需要数据库、账号系统和复杂后端；

• 演示效果好：后面做教程、截图、录屏，都比抽象配置更吸引人；

• 链路完整：需求、代码、运行、测试、反馈、优化，全都能走一遍。

我会把它当成 Codex 的第一个网页实战案例。

不是因为贪吃蛇本身多重要，而是它能让你真正感受到一件事：Codex 不是只会写代码片段，它能把一个模糊想法变成可运行页面。

你可以这样给第一轮提示词：

请帮我设计一款 HTML 的贪吃蛇游戏。

要求：

1. 能够用键盘“上下左右”控制，按 Enter 键暂停；
2. 随着贪吃蛇长度变化增加速度；
3. 每次只出现一个苹果，位置随机；
4. 按空格键能加速，加速要高于当前速度等级；
5. 贪吃蛇撞到四周的墙和自己的身体都会死亡；
6. 采用波普复古风格，带运动特效和死亡爆炸特效；
7. 做成浏览器可以直接打开的网页版本。

这条提示词已经比“帮我做一个小游戏”清楚很多。

它给了 Codex 几个关键约束：玩法、按键、速度、失败条件、视觉风格、交付形式。

第一版出来以后，别急着加一堆新功能。

第一版只看四件事：

• 浏览器能不能打开；

• 游戏能不能开始；

• 方向键能不能控制；

• 死亡和重新开始是否正常。

这四件事通了，后面才值得继续加东西。

你可以继续按实际效果反馈：

• 速度太快，降低初始速度；

• 颜色太丑，改成更明显的复古撞色；

• 开始按钮不明显，放大并加状态提示；

• 分数显示不清楚，固定到右上角；

• 死亡特效太弱，补一个爆炸动画；

• 手机端不好玩，就明确只做桌面键盘版。

这里最容易翻车的地方，是改需求的节奏。

一次只改一类问题。

先改玩法，再改 UI，再加说明，最后补截图和介绍文字。不要一口气让它同时改规则、改风格、加音效、加排行榜、加移动端适配。

很多人第一次用 Codex 做网页翻车，不是因为 Codex 不行，而是需求越堆越乱。

你要让它持续往前走，而不是每一轮都推翻重来。

小游戏跑顺以后，就可以顺手把它变成教程素材。

比如让 Codex 输出：

• 本地文件结构；

• 运行方式；

• 第一版效果截图说明；

• 每一轮修改记录；

• 常见 bug 和修复方式；

• 最终版本的功能清单。

到这里，它就不只是做了一个网页。

后来我发现，真正省时间的反而不是小游戏本身，而是顺手得到了一套可复用的教程生产流程。

以前写这种教程，最烦的不是写字，而是截图、整理步骤、补说明、检查遗漏。每一件都不难，合起来很耗人。

Codex 很适合处理这种“单步不复杂，但链路很长”的任务。

如果你经常重复做某一类交付，不管是教程、活动方案，还是上架流程，都可以继续往前走一步：把它沉淀成自己的 Skill。

不是一句“写得像我一点”，而是把你的结构习惯写清楚：

• 开头先写真实人群和具体瓶颈；

• 尽早抛出加粗的核心判断；

• 复杂方法拆成编号步骤；

• 每一步写清楚判断、做法、验收；

• 少写工整的 AI 金句；

• 结尾给明确行动，而不是泛泛总结。

一次性生成，很容易变成“方向对，但味道不对”。

工作流会慢一点，但它能积累。

三、业务自动化：这是进阶教程前面理解了在来研究这里吧

最后讲一个更进阶的场景。

Codex 不适合供着研究。它适合被你拿去干活

它不是新手第一天就该碰的任务，但你需要知道 Codex 往后能走到哪里。

我之前和一个做电商的老板聊过。他主要做拼多多，店铺在扩张，后台上架和维护已经开始拖效率。

他们的痛点很典型：

• 链接数量很多；

• 一个链接下面有多个 SKU；

• 表格里有几千行数据；

• 在售链接有几百个；

• 开新店时要重新建几百个商品链接；

• 每个 SKU 都要填库存、拼单价、规格编码、商品编码、参考价；

• 日常还要维护价格和编码变化；

• 人工对着表格填后台，慢，而且容易错。

这个场景非常适合自动化。

因为它不是创意判断。

它本质上就是一句话：

把表格里的结构化数据，稳定地填进网页后台。

我最开始想到的是 Computer Use。

也就是让 Codex 看屏幕、操作电脑、打开表格、识别后台字段，再把内容填进去。

这个思路对开放网站还可以，但在拼多多这类后台上很容易遇到问题。后台会检测自动化行为，Computer Use 不一定能顺利访问。

后面真正打通的是第二条路：Playwright。

Playwright 不是看屏幕点鼠标，而是通过代码控制浏览器，直接找页面里的按钮、输入框、下拉框。

这更适合批量任务。

完整流程可以这样拆：

这里 Codex 负责的事情不止是“写一个脚本”。

它可以读 Excel，分析哪些列有用，整理成标准上架表，让你确认字段映射，再写 Playwright 自动化。

跑第一条商品时，它可以截图暂停，让人确认页面填得对不对。确认以后再批量跑。

最后它还可以输出成功日志、失败日志、错误截图，方便你回头查。

这类东西一旦稳定，就不只是一次性提效。

如果这条链路稳定下来，下一步就可以沉淀成公司内部 Skill。

从“帮我填一次表”，变成“以后这类上架任务都按这个流程跑”。

容易踩坑的地方

场景不用讲太多，但踩过的坑一定要提前说。

一、Computer Use 不是万能的

Computer Use 目前的使用环境本身也有限制，不是所有人打开 Codex 都能直接用。

Computer Use 很像一个人坐在电脑前看屏幕操作。

它适合开放网页、文档编辑、资料整理、截图类任务。

但如果你要操作电商后台、银行后台、强风控平台，它就不一定好用。因为这些平台会检查浏览器指纹、WebDriver 标记、无头模式、登录环境和行为模式。

遇到这种后台，我会优先考虑 Playwright，而且尽量复用已经登录过的浏览器环境。

思路不是绕规则，而是把自动化做得更稳定、更可控，每一步都留确认和日志。

二、Codex 不能接管你本机已经打开的终端

有些人会想：能不能让 Codex 去操作我本机已经打开的 Ghostty、Claude Code 或其他终端？

目前这条路不顺。

Codex 能看屏幕，但不能随便接管外部终端进程输入。终端界面对自动化来说也比较黑箱，光标、焦点、输入状态都不稳定。

这类事我会换一种做法：

• 能在 Codex 内置终端跑的命令，就直接让它跑；

• 想调用网页 AI，就让它打开网页端；

• 想让它完成 Claude Code 能做的事，很多时候直接在 Codex 里完成更省事。

三、只给方向，不给思路，产出一定飘

很多人会这样用：

帮我写一篇关于 XX 的文章。

或者：

帮我做一个好看的网页。

这种提示词不是不能用，但结果很容易变成一坨标准答案。

Codex 不知道你的知识结构，不知道你的审美，也不知道你的目标读者到底卡在哪里。

你给方向，它就自由发挥。

你给思路，它才是在帮你加速执行。

更好的输入应该长这样：

• 核心观点是什么；

• 目标读者是谁；

• 读者现在卡在哪里；

• 文章要解决什么问题；

• 每一节大概要讲什么；

• 哪些话不能写；

• 最终要交付什么文件；

• 怎么验收算完成。

这也是我一直建议沉淀 Skill 的原因。

你写得越清楚，它瞎猜的空间越小。

最后

真正把 Codex 放进工作流以后，最该关心的不是一次消耗了多少，而是这次有没有留下东西。

文件模板、验收清单、截图记录、可复用提示词、自动化脚本。

这些留下来，下一次才不是从零开始。

这不是劝你一上来就加码。

新手真正要算的，是一次练习有没有留下可复用的东西。

一次办公四件套任务，能不能留下文件模板和验清单。

一次网页小游戏，能不能留下需求、代码、截图和修改记录。

一次图文教程，能不能留下素材结构、步骤说明和发布版本。

这些东西积累起来，你才会慢慢知道 Codex 适合干什么，不适合干什么。

Codex 不适合供着研究。

它适合被你拿去干活。