朋友们，好像标题党了，先别骂，看完指定有灵感。整了点不错的东西，这次真的可以把 PPT 做得很好看了！快放假之前给大家再分享一波，这个真的很棒的不容错过。

首先我其实是很早就想做这个的，我之前分享的 Coze 的技能那篇文章，我做了一个技能叫【PPT风格克隆】，那时候我只有一个想法雏形，就是通过提取参考图或者参考网页的视觉细节，去进行这个风格的参考，然后把风格迁移到我的 PPT 生成的流程里，完成 PPT 的输出。

当时我虽然在 Coze 也做出来了，但是操作起来还是有点困难的，要自己比较熟悉什么参考图适合什么风格，不然迁移效果就差了点。刚去看了只有 5 个人给技能评分，还都是给1分（最低1分）

而且我属于有点强迫症的那种，我不能接受它很多细节不统一，虽然它们单看都还不错，但是在一个 PPT 里的话，它们的那种视觉上的一致性是不够好的。

比如下面这两张，虽然是一组生成的，但是黑色部分的框就是一个是方框另一个是凹角边框。或者很多场景下的单页的小标题的装饰是差别有点大的。

那有没有解决办法呢？以前不那么好解决，但是现在我觉得又可以了。主要还是 Codex 支持了 Image 2 大大加强了我的探索欲，我探索出了一个很棒的可以用来做 PPT 的 Skill，可以很好地去迁移参考图的风格，做出自己想要的 PPT 效果。

几乎任何风格，都可以让 Image 2 为你迁移。

给大家先看看输出效果。这次风格参考的图片来自网站 Landbook（https://land-book.com/），虽然它主打网页设计灵感库，但是视觉的亮点都是共通的，它分享的网页图的版式效果也是非常值得学习的。

这是给到的参考图

原图链接：https://land-book.com/websites/71866-doconomy

输出 PPT 图片的时候，我的逻辑是先输出多宫格图，把基本的版式定下来，后续它再一个个放大，而 GPT Image 2 不让人失望的一点就是它放的的时候不但基本遵循了版式，在多宫格时候一些处理不好的地方它放大之后反而有可能进一步优化，这一点我觉得是 Nano Banana Pro 做得有点不如它的。但是人像和角色相关还是 Nano Banana Pro 更好。这个在最后一个案例可以看出来。

先看多宫格

再看完整的输出

这是给到的参考图

https://land-book.com/websites/93690-golive-webflow-ecommerce-website-template

这是参考参考图的输出PPT，基本都不用怎么修改。哎，你怎么知道我五一要去甘肃玩的哎嘿

这个也是。前面几组简约点，后面几组复杂点

还有这个

还有这个

虽然依然不能说很完美，但是整体的调性和细节还是不错的了。

思路分享

再和大家分享我这个 Skill 的工作过程和我的思路。

首先这个 Skill 不是做可编辑 PPT 的路线，走的路线还是“先把视觉风格资产化，再用 Image2 生成整页图，最后封装成图片版 PPTX ”。这主要还是依托 Image 2 自身强大的能力实现的。

下面是我的思路（这个风格是这个 Skill 的默认风格）

1. 判断任务类型：GPT首先会判断是提炼风格、调用风格库、文档转 PPT/图片、已有图片版 PPT 返修，还是单页视觉重做。

2. 选择或提炼风格：明确只使用一个 Style source （用于参考风格的资源）和一个 Style Lock（锁定视觉细节），防止混入历史参考图或其它风格。

3. 理解内容：从文档或主题里抽出一句话主张、受众、3-6 个核心观点、可视觉化对象和建议页数。这一块是为了PPT 的内容作准备。

4. 确认生产参数：页数、比例、输出类型、语言、文字密度、是否需要日期/作者/Logo/水印。默认是中文优先、16:9、低密度、无日期。这里是锁定视觉细节。

5. 规划页型：从封面、目录、核心观点、对比、流程、框架、时间线、数据、案例、清单、结论等页型中为每页定角色。这里也是锁定视觉细节。

6. 先产出文档：多页项目前必须先生成 outline.md（这个是内容框架） 和 prompts.md（这个是完整提示词），其中 prompts.md 要包含完整 Style Lock（这是为了统一多图的视觉细节）。

7. 两段式生成：多页项目优先先做缩略图板锁定整体节奏，再逐页生成独立成品图。这里选择了先做一张多宫格图，用于更好地保持不同页面的图片版式的一致性。

8. 用户确认图片：生成后先展示或列出图片，确认通过后才组装 PPTX 和 zip。

9. 局部返修：重做被点名的页，保留其它页和同一风格系统。

10. 最终打包质检：检查风格一致、中文可读、信息不拥挤、页型匹配、无黑色外框、无假日期、一页一图、PPTX 全屏铺图。

如何使用

推荐工具首选 Codex 。因为它足够聪明，能够很好地理解并输出我需要的文本内容，还能批量完成极高质量的带有文本的图片。如果无法使用，同样可以尝试 Lovart 、LibTV 或扣子来完成。

首先还是安装这个 Skill，或者直接把我最后的链接复制给 Codex 让它安装就行了。顺带说一句这里打码是因为是个无关的 Skill，不是特地藏私，这个调好了下下期就分享了，也是很有意思的小工具 

安装好以后，让它调用这个识别图片做PPT的 Skill 或者直接让它调用 visual-style-ppt Skill，给到它想要参考和模仿风格的图或者直接给网页链接也可以，并且和它说，提取这张图的风格 DNA ，然后它就完成了提取

原图与原图链接

https://land-book.com/websites/84950-error-the-request-could-not-be-satisfied

好，风格已经提取好了，接下来就是给到指定路径的文档，或者文档附件，让它生成 PPT。如果没有文档直接让 Codex 去找资料也一样的。

但是在这一步它还不会生成 PPT，它会首先生成第一步文件等我们确认，这一步会生成一个 outline 文件，一个 prompts 文件。

outline 文档其实就是 PPT 的文本大纲，为了内容更加可控，我的想法是把这个文档先单独输出出来进行确认，内容大纲上还有任何问题的时候，可以选中内容然后【添加到对话】修改。这个后面有截图示意。

然后是 prompts ，这个相信大家都很熟悉了，这个就是提示词，不同的是，在这个提示词前面我做了详细的制作参数标准的默认与统一，以及Style Lock，也就是将风格和层级的细节狠狠锁死。

再往后，就可以看见缩略图、每张PPT的详细提示词了，之所以这样做也是想让风格和内容在内容阶段就都更加可控。

等上面 2 个文档内细节确认了，就可以让它生成图片了。就对它说“生成图片”或者“继续”就行了。生成图片分了两步，先出多宫格，不满意就修改到满意，然后再一张一张输出。下面我这个内容很简短，所以只有 7 张图。如果是 PPT 内容比较长的，可以考虑让它分成多次去完成。

文档原文来自：https://substack.com/home/post/p-186699129

当然，如果你觉得上面这些都虚头巴脑的，费那老大劲！那也可以直接让它输出 PPT 图。这个主要还是为了细节可控。

最后的大图和九宫格的缩略图可能还是有点差别的，但是在我的尝试中，它变化的方向通常是往更好的方向，所以都还是可以接受的。

第一轮所有图片输出以后其实还是可以继续进行调整的。比如这个原图序号错了，我让它继续修改。

但是还是老问题哈 Image 2 这个人像细节。

如果还有其他文字细节要修改，可以截图框选给她让它修改。

然后图片也确认完了，可以直接让它导出 PPT，或者直接说“打包” 。它会交付最后确认的所有的图片、缩略图版、大纲、提示词文件。不要误会，这里的 PPT 其实还是那个无法修改文字的图片组合在里面的。有需要修改的，一定在前面一步修改完了再打包压缩包。

最终输出的压缩包里是这样的

其中 Style-used 是可复用的风格模板。它是给后续生成、返修、复用看的风格设定文件。它的作用如下（你看，我再次生成信息图的时候调用了同一个风格模板，它的风格一样维持得很好）也就是说，我们如果还要加 PPT 页面，直接在这个基础上补内容也是完全 OK 的，绝对不是只能九张以内的

如何使用 · 文字版

最后再次简单概括怎么使用：

第一步，在 Codex 安装这个 Skill。

第二步，给它参考图，让它提炼风格 DNA 。

第三步，给它我们的文档，让它基于文档生成 PPT 图片。这一步会生成两个文档，修改确认好以后，再进行下一步。

第四步，检查和修改图片细节，没有问题后让它打包文件。

第五步，Style-used 文件，下次还可以复用，觉得有用可以让它直接存到 Skill 里。

小结

好嘞，到这里，我的整个思路和它的操作方法也差不多分享完了，以后大家如果想迁移自己一直惯用的一些风格到要用的 PPT，或者做一些实验性的PPT 风格的尝试等等，也都非常方便了。

最后，这个 Skill 已经分享在 GitHub ，下面是链接，如果喜欢可以点亮阿真的 GitHub

如今 Codex 已经全面切换Token 按量计费模式，输入、缓存、输出三类 Token 分开计价，不少开发者反馈：明明只是日常写代码、改 BUG，月度额度短短几天就见底，续费成本居高不下。

尤其是做大型项目重构、多文件调试、长文档解读的用户，Token 消耗更是呈指数级增长。

其实 Codex 本身定价并非天价，90% 的高额花费都来自无效消耗。结合 OpenAI 官方计费规则、Token 底层逻辑、全网实测优化方案，以及 2026 年 Codex 降价窗口期福利。

本文从读懂计费规则、监控用量、基础节流、高阶优化、分场景省钱方案、账号与套餐选择、避坑雷区七大板块，手把手教你砍掉无效开销，个人、工作室、企业团队都能套用，实测可降低 50%-80% 使用成本。

一、先搞懂计费逻辑，知道钱花在哪，才能精准省钱

想要省钱，第一步必须吃透 Codex 当前计费体系。2026 年 4 月起 Codex 彻底放弃按消息扣费，统一采用三类 Token 分离计费规则，不同 Token 单价差距极大，也是成本分化的核心原因。

1. 三类 Token 扣费规则（核心重点）

补充换算参考，代码、结构化文件 Token 密度远高于普通文字，一段 JSON 配置、多行函数会快速拉高消耗；中文内容 Token 消耗也高于英文，编写指令时尽量简洁规范。

2. 额外消耗误区（多数人踩坑）

多端同步扣费

Codex 网页端、IDE 插件、CLI 命令行、移动端共享同一套额度，同时多端高频调用，额度会翻倍消耗。

自动调用隐形扣费

重试与报错扣费

3. 2026 降价窗口期福利（必领）

截至 2026 年 7 月中旬，所有 Codex 付费用户可享受基础额度永久翻倍，同时取消高峰时段调用限制。在这个阶段优化使用习惯，能把翻倍额度的价值吃到最大，相当于变相再省一半费用。

二、前置操作，开启用量监控，定位 “吞额度” 元凶

省钱的前提是找到浪费点。OpenAI 官方提供完整用量面板，能精准查看每日消耗、Token 分类占比、终端消耗分布，5 分钟就能完成配置。

1. 个人账号用量查询（Free/Go/Plus/Pro）

2. 企业 / 团队账号监控

3. 额度预警设置

在用量面板开启余额提醒，设置 20% 剩余额度预警，避免额度突然耗尽打断工作，重度用户可开启自动充值，并设置充值上限，防止超额消费。

三、基础节流：零门槛操作，新手立刻见效（立省 30%）

这部分操作简单，无需技术能力，调整使用习惯就能快速减少无效消耗，适合所有开发者。

1. 优化指令：拒绝模糊描述，让 AI“少猜、少输出”

模糊指令是 Token 最大黑洞，AI 理解偏差会导致反复生成、过度输出，消耗直接翻倍。

错误示范（高消耗）

帮我优化这个项目，检查BUG，顺便重构代码特点：任务杂乱、边界不清，AI 会读取全量文件，输出大段内容。

标准省钱指令模板（直接套用）

目标：修复XX文件登录报错；相关文件：xxx.js，约束：不修改数据库、不新增功能；输出要求：仅展示修改代码+简短说明，省略多余注释

额外技巧：

2. 关闭 IDE 隐形扣费功能

VS Code、JetBrains 等编辑器的 Codex 插件，实时代码联想是隐性消耗重灾区：

3. 单一会话复用，吃透低价缓存 Token

缓存输入 Token 价格极低，善用会话缓存是性价比最高的省钱方式。

4. 及时截断无效输出

当 AI 输出内容达到你的需求时，立刻按下 Esc 终止生成。很多时候 AI 会自动补充多余解读、拓展内容，白白消耗输出 Token。尤其代码讲解、文档总结类任务，提前截断效果显著。

四、高阶优化：针对代码 / 项目场景，再省 50%（开发者主力方案）

如果日常做脚本开发、项目重构、代码迁移、BUG 修复，仅靠基础优化远远不够。结合代码场景特性，从文件、上下文、任务拆分三大维度深度优化，大型项目降幅可达 70% 以上。

1. 过滤冗余文件，拒绝 “全量投喂”（代码项目核心）

绝大多数人会直接让 Codex 读取整个项目，而项目中 80% 的文件都是无用内容，疯狂拉高输入 Token。

操作方法:

2. 拆分长任务，拒绝 “一键全量重构”

大型项目重构、代码迁移、全量优化，是额度见底的重灾区。不要让 Codex 一次性处理整个项目，遵循 “大任务拆小任务” 原则。

3. 上下文瘦身：避免会话臃肿

长会话会累积大量历史对话，每一次调用都会加载全量上下文，Token 持续走高，推荐两种主流解法：

方法 1.会话压缩（Codex 内置指令）

阶段性任务完成后，输入 /compact 指令，系统自动压缩会话，保留核心信息、删除冗余对话，大幅减少上下文 Token 占用。

方法 2.会话交接法（大型项目首选）

当会话上下文过大、响应变慢时，执行四步操作：

4. 模型按需选择，高低搭配降本

Codex 支持多款模型，不同模型单价差距明显，简单任务用轻量模型，复杂任务用完整版，不盲目追求大模型：

五、分场景专属省钱方案（直接套用，覆盖 99% 使用场景）

结合开发者高频使用场景，整理标准化操作流程，对应不同消耗等级，精准控费。

场景 1.日常单行补全、语法调试（低消耗）

场景 2.单文件脚本、小型功能开发（中等消耗）

场景 3.多文件项目重构、代码迁移（高消耗，重点优化）

场景 4.长文档、接口文档解读（长文本输入）

六、套餐与账号规划：选对套餐，从根源降低单位成本

很多人只优化使用习惯，却忽略套餐选择，不同档位单价、额度、限速差异巨大，选对套餐能省下一大笔固定支出。

1. 个人开发者（按使用频率选择）

避坑：Free 免费版额度极低，且无法单独充值，重度使用务必升级付费套餐。

2. 团队 / 企业用户

3. 额外薅羊毛技巧

七、高频避坑：8 个看似正常、实则巨耗 Token 的行为

整理全网实测高频雷区，这些操作看似不起眼，却是长期成本居高不下的元凶，务必规避：

八、不同人群落地执行清单（每日 / 每周固定动作）

1. 个人开发者（Plus/Go 套餐）

2. 独立工作室（Pro 套餐）

3. 企业团队（Business/Enterprise）

2026 年 Codex 正处于降价 + 额度翻倍的黄金窗口期，这是降低使用成本的最佳时机。但我们要明白：省钱不是一味缩减功能、牺牲体验，而是杜绝无效消耗，让每一份 Token 都用在核心工作上。

Codex 的计费逻辑本质是 “按劳收费”：你的操作越规范、任务越清晰、上下文越精简，单位成本就越低。从基础的指令、设置优化，到高阶的文件过滤、会话管理、任务拆分，一套流程落地后，不仅能大幅降低费用，还能让 Codex 的响应速度、输出精准度同步提升，实现 “省钱 + 提效” 双赢。

最后总结三大核心省钱口诀，方便记忆：

按照本文的方案逐步调整，无论是个人日常编码，还是企业大型项目开发，都能把 Codex 的使用成本控制在合理区间，轻松玩转 AI 编程工具。

这段时间以来，Codex 在社交媒体上是好评如潮。

有网友发现，现在邀请一位朋友加入 Codex ，就可以重置速率限制。

即便邀请的用户并非新用户或订阅用户，只要受邀用户通过链接打开 Codex 后发送几条消息，就能获得一次重置的机会。

除了拉新人送福利的活动，官方的 Codex 也将迎来大降价。

根据外媒援引知情人士的消息，OpenAI 正在考虑大幅降低其向用户收取的费用，以从竞争对手 Anthropic 那边赢得客户。

报道里提到，OpenAI 可能会降低 Token 的价格，但关于大降价的讨论还在进行中。

毕竟，Codex 现在就是 OpenAI 最好的客户拉新平台。

和 OpenAI 官方披露的数据一样，ChatGPT 用户突破了 10 亿，而 Codex 的周活用户却刚刚来到 500 万，相当于 200 个 ChatGPT 用户里，只有 1 个人点开了侧边栏里面的 Codex。

「用不上」是一方面，更多地可能还是不知道怎么用，或者 Codex 能做什么，哪些是 ChatGPT 做不好，只有用 Codex 才能做到的任务。

Codex 官方也听到了用户的反馈，一边高调宣传即将并入 ChatGPT，未来我们打开全新大改版的 ChatGPT 应用时，可以选择使用 Codex 还是 ChatGPT 来回答。

另一边，他们这几天在 OpenAI 官网一口气更新了十几个真实世界的工作流程，从常见的部署网页和应用、直接构建一个 Mac 或 iOS 应用，到大型的项目管理、150 个小时的科研任务，以及各种工作中的琐碎业务，都有相应的使用案例。

这些教程大概是帮助我们快速上手 Codex 的最佳指南，很好地解决了 Codex 能做什么，如何使用 Codex 的问题。

Computer Use，让 Codex 控制电脑

Hey Siri，打开微信发消息给妈妈，说 XXXX

请先解锁 iPhone

Siri 做不到，Codex 现在也做不到操作微信。

Codex 的 Computer Use 功能，主要是允许 AI 像我们一样操作电脑界面，通过点击、查看和输入来完成任务。这项功能适合的场景包括跨应用任务，如收集笔记、更新记录、在不同位置间复制细节、回复信息等。

在官方的使用案例里，他们举的例子有简单地放首音乐，也有涉及在不同应用之间切换。

@Computer 放点音乐帮我集中注意力。

@Computer 请帮我把 Notes 里的面试笔记添加到飞书里。

@Computer 请查看我的企业微信并添加提醒，提醒我今天结束前需要完成的所有事项。

具体的使用方式，我们先要在 Codex App 里面找到 Computer Use 并确认已经开启，接着在对话框里，输入指令的开头加上 @Computer ，或者提及特定的应用程序，例如 @Slack 或 @Messages 等。

选择好 Computer Use 插件之后，描述一下任务以及我们想要的结果，当 Codex 需要访问权限时，批准访问，然后让它在后台继续执行任务。

使用 Computer Use 的几个注意事项，像是确保运行时 Mac 不会锁定，或者在 Codex 里打开「锁屏操作」功能，还有 Codex 使用电脑上的应用时，我们可以在自定义设置中，告诉 Codex 默认浏览器是哪个。

以及不要使用两个 Computer Use 的任务线程来控制同一个应用，每一个线程结束后都可以要求 Codex 总结和优化该任务，甚至是将这套工作流程变成可重复的模式。

给 Codex 一个能一直跑下去的目标

平时让 AI 干活，很需要我们站在旁边盯着，它做一小步停一下，问下一步怎么办，我们得一直搭着手。

/goal 想解决的就是这件事：给 Codex 一个长期目标，让它自己照着这个方向一直做下去，干完一轮也不停。

官方指南里，几个典型的用法是那种比一句提示词大、又比一整张待办清单小的任务，目标明确、能自己验证、做到什么程度算完都说得清。

项目迁移：不管是把游戏搬到新技术栈、把移动应用搬到新平台，还是把整个代码库换个框架，都可以用 /goal 让 Codex 把迁移一路跑完。

做原型：从零做一个新应用、新游戏或新功能时，可以用 /goal 让 Codex 交出一版打磨过的初稿。你可以写一份 PLAN.md，把想做成什么样讲清楚，让它照着做。

调提示词：手上有一套测试集，就能用 /goal 拿评测结果来优化提示词。Codex 会去看哪些案例失败了、改提示词、重跑评测，一直迭代到分数上去，或者到了你定的收尾条件为止。

对于如何写好一个能稳稳跑起来的目标，先给它一个明确目标和一个收尾条件；告诉它先去读哪些文件、文档、issue、日志或计划；定好用哪条命令、哪个产物来证明进度；让它分阶段做，顺手记一份简短的进度日志；过程里我们随时用 /goal 看状态；跑完、卡住或者要换方向时，再暂停、继续或清除。

用 GPT Image 2 来做 PPT

做 PPT 最磨人的那步，常常是排版。Codex 自带两个技能：$$slides 用 PptxGenJS 直接读写 .pptx，$$imagegen 负责生成配图。

OpenAI 官方给的参考提示词是，

使用 $$slides 和 $$imagegen 技能，按以下方式编辑此幻灯片：

– 如果存在，请在每张幻灯片的右下角添加 logo.png 文件

– 在幻灯片 X、Y 和 Z 上，将文本向左移动，并使用图像生成功能在右侧生成插图（风格：抽象、数字艺术）。

– 尽可能将文本保留为文本，将简单的图表保留为 PowerPoint 原生图表。

– 添加以下幻灯片：[在此处描述新幻灯片]

– 在新幻灯片和新文本中使用现有品牌标识（颜色、字体、布局等）。

– 将更新后的演示文稿渲染成幻灯片图像，检查输出结果，并在交付前修复布局问题。

– 在交付之前运行溢出和字体替换检查，尤其是在牌组密集的情况下。

– 创建一批相关图像时，保存可重复使用的提示或生成说明。

除了从零开始做，一页页描述内容和整体风格，有 logo、图片就丢进同一个文件夹方便它取用。

我们还可以让 Codex 来处理周报、月报、季报这种，定期更新模板，让它总结一份 guidelines.md 确定好内容、结构和更新方式，再配合别的技能拉对应的数据，比如给股东的季度汇报，换上新数字和洞察就行。

而修改现成的 PPT，也可以直接在对话框里，要求 Codex 修改间距、文字错位这类毛病。

让 Codex 照着截图做网页

手上有几张截图、一份简短的设计说明，或者几张找灵感的参考图，Codex 能照着做成响应式界面，同时顺着项目里已有的写法来，即原有框架和语言，不会另起一套。

再配上 $playwright，Codex 能在真实浏览器里打开页面，按不同屏幕尺寸跟我们上传的截图逐一对照，反复调到接近为止。

参考提示词如下，

请以我提供的屏幕截图和注释为依据，在当前项目中实现此用户界面。

要求：

– 重用现有的设计系统组件和标记。

– 将屏幕截图转换为此存储库的实用程序和组件模式，而不是发明一个并行系统。

– 间距、布局、层级和响应行为要紧密匹配。

– 尊重仓库的路由、状态和数据获取模式。

– 使页面在桌面和移动设备上都能响应。

– 如果截图中的任何细节不明确，请选择最简单但仍符合整体方向的实现方式，并简要说明假设。

验证：

– 将最终的用户界面与提供的屏幕截图进行比较，包括外观和行为。

– 使用 $playwright-interactive 检查 UI 是否与引用匹配，并根据需要进行迭代，直到匹配为止。

从零做一个在浏览器跑的游戏

做游戏大概也是能看出 Codex 不只会写代码还懂设计的场景之一。一个真正的游戏，要有写下来的玩法概念、渲染层、前端外壳、后端状态、美术素材，还得不停地调画面和手感。

动手搭架子之前，先让它写一份 PLAN.md，把游戏拆成具体几块：玩家目标、核心循环、操作和输入、胜负条件、难度和成长、视觉方向、技术栈和部署假设、里程碑的先后顺序。

再写一份 AGENTS.md，按照官方的教程，可以参考下面的写法。

游戏名

<游戏类型>

技术栈：

– 前端 NextJS（部署在 Vercel）

– 渲染用 <填技术>

– 后端 Fastify + WebSocket（部署在 <平台>）

– 数据库 Postgres，缓存和 pub/sub 用 Redis

– 生成式 AI 功能走 OpenAI

约定：

– 每做完一个功能就用 build / test 命令验一下

– 做新功能时照着 PLAN.md 来

– 把思路和决定记在 .logs 里，迭代时回头查

– 用 playwright 测画面效果，不对味就改

– 用 imagegen 出素材，每出一批就把 prompt 存进 .prompts，方便以后接着出同款

– 用 Context7 MCP 拉 <渲染框架> 的文档

把 AGENTS.md 里提到的技能都装上：$$imagegen 出美术素材，$$playwright 在真实浏览器里测游戏，$openai-docs 拉最新的 OpenAI API 文档，需要的话再加个 Context7 MCP 拉渲染框架的文档。

接下来 Codex 会照着计划先做出第一版。如果要生成的图很多，这一版可能得跑上好几个小时，Token 开始疯狂燃烧。不过借由 Playwright 的能力，Codex 可以自己在浏览器里试玩、验证游戏效果，中间基本不用我们管。计划写得越细，第一版出来就越像样。

我们让 Codex 自己写了一份游戏的 Plan.md，输入提示词， 然后生成了一个几乎是可以直接上线的小游戏。

Use $playwright-interactive, $imagegen, and $openai-docs to plan and build a browser game in this repo.Implement PLAN.md, and log your work under `.logs/`.

小的网页游戏之外，使用 Codex 提供的构建 iOS App 插件，我们一句话就能在 Codex 内查看和测试 iOS App。

让 AI 自己跑科研

Codex 能干的不止写代码，它也能在科研里当一个长期干活的研究助手。用户给出方向和判断，它去实现、取证、打分、反复迭代。

其中一个案例是改模型架构。假设手上有个蛋白质折叠的假设，「让模型多表示一些高阶的几何结构，会不会学得更好」，可这种想法一遍写不完，得反复试。

用 Codex 的 Goal Mode，给它三样东西：一个划好边界的科学方向、一个能跑的基线模型、一套能自动打分的基准，它就会照着这个目标一路爬分，实现、测试、记实验、查故障、再改。

官方给出的例子里，Codex 连着跑了 150 多个小时，产出了一个叫 SimplexFold 的实验性架构。

另一个是给药物靶点排序。类似任务的麻烦点，在于证据散在十几个数据库里，遗传学、临床、文献、表达数据各管一摊。

用 Life Science Research 插件，Codex 能并行去各家数据库取证、每条证据线各自按 1-5 分打分，最后汇成一张打分表加一份排名，还能配上热力图之类的图。

在 OpenAI 官网给出的用例还有很多，我们这里只是列举了部分热门的用法。感兴趣的朋友可以去 OpenAI 开发者官网developers.openai.com/codex/use-cases，尝试不同的案例。

作者：发现明日产品的APPSO

来源：APPSO

OpenAI刚刚给字节上了一课。

据《金融时报》披露，OpenAI正准备对ChatGPT进行自2022年推出以来规模最大的改版。新版ChatGPT会把Codex、外部合作伙伴应用和 Agent能力更深地接进来，把原本的聊天框，改造成一个能写代码、管理日程、操控软件的“超级应用”。

OpenAI的方向很清楚，要把ChatGPT从聊天框变成一个任务分发入口。用户还是从ChatGPT进来，但背后接上的东西会更多。Codex负责执行更重的任务，外部应用接入真实服务，插件和Agent把需求往下推进。

豆包在国内的位置其实和ChatGPT很像。

ChatGPT之于OpenAI，豆包之于字节，都是最大众、最容易被用户自然打开的AI入口。

与此同时，豆包正处在从免费AI助手到付费专业AI工具的关键转型期。

按照官方说明，针对专业人群的生产力需求，豆包计划推出专业版，将包含软件开发、数据分析、专业设计、流程自动化、金融分析、科学研究等专业服务。

豆包也强调，搜索问答、写作生图、语音和视频对话等日常功能，会继续保持目前的免费服务；专业版的服务，也会在一定额度内免费。

豆包收费这件事，本身并不算新奇。AI产品本来就不便宜，ChatGPT、Claude、Gemini都有付费会员，模型API也都是明码标价。字节自己旗下的Trae、扣子、即梦AI，也早就有付费选项。

但豆包的问题在于，它靠什么让别人为它付钱。

如果只是一个升级版的豆包Chatbot，“贵又难用”的评价恐怕要再次冲上热搜。尤其当它明确表示专业版瞄准的是“软件开发、数据分析、专业设计、流程自动化、金融分析、科学研究”这些生产力场景时，它要回答的，自然也不再是那些针对Chatbot的问题。

字节不缺用户入口，也不缺技术资产。豆包有入口，扣子有Agent和工作流，Trae有编程工具，飞书有企业协作场景，Seed有底层模型和多模态能力。单看每一块，字节都有东西可讲。

问题在于，这些牌能不能像ChatGPT和Codex那样串起来。

01 豆包付费版，卖的是什么？

豆包正在走到一个新阶段：从免费的AI助手，变成要收费的专业工具。

过去一年，豆包在国内AI助手里遥遥领先。

CNNIC《生成式人工智能应用发展报告（2025）》显示，截至2025年6月，我国生成式AI用户规模达到5.15亿人，普及率达到36.5%。在主要产品中，豆包的用户使用率达到72.2%，位居第一；在“首先选择使用的产品”中，豆包占比47.1%，位居第一。

QuestMobile的数据也能说明豆包的入口优势：2026年3月，豆包月活达到3.45亿，超过第二名千问1.66亿的两倍；一季度平均活跃率达到33.5%，高于千问的17.1%和DeepSeek的21%。

豆包能在普通用户里迅速推广，靠的主要是免费、好用、功能多、无门槛。用户打开豆包，可以搜索问答、写作生图，还能语音和视频对话。它像一个随手可用的AI助手，负责陪用户聊天、回答问题、处理一些轻量任务。

但这套逻辑只能支撑免费版本，一旦涉及到付费，用户的需求就会截然不同。

按照豆包官方说法，专业版面向的是专业人群的生产力需求，覆盖软件开发、数据分析、专业设计、流程自动化、金融分析、科学研究等方向。

工作场景和日常聊天不同，用户问一个日常问题，AI回错了，大不了重新问；让AI写一段文案，不满意也可以再改。但涉及到软件开发、数据分析、金融分析、科学研究，用户的容错率会低很多。效率即成本，付费产品必须给出更清楚的价值。

事实上，即使在免费阶段，豆包也已经因为“看起来能办事，但实际上没办成事”引发过争议。

比如此前的餐厅订座事件。有用户通过豆包预约餐厅，豆包生成了看起来很像预约成功的回复，甚至让用户到店报出时间和人数。但用户到店后，商家表示并没有收到有效预订，称豆包只是AI对话工具，模拟输出并不会同步到门店系统。豆包客服后来也回应称，目前无法帮用户预订或购买商品。

还有5月中旬的“豆包机票退款”事件。一名用户称，自己向豆包咨询机票退票手续费，豆包给出“仅收5%手续费”的明确回复，但实际退票时被扣除40%手续费，损失600元。随后，用户称豆包又在对话中承诺赔付，后续索赔无果，于是向法院起诉豆包运营公司。豆包相关负责人回应称，该案例相关问题已处置，之后在涉及金融、退款等场景会有风险提示。

免费阶段，用户还可以把这类问题归为AI幻觉；而一旦进入付费场景，AI产品暴露出的可靠性问题会更加严重。

但反过来看，付费版本也起到了筛选用户的作用。

免费阶段，豆包面对的是最宽泛的用户，处理的是搜索问答、写作生图、语音和视频对话等日常需求。这些功能在后续依然会保持免费服务，那些轻度的AI用户，本身其实并不受专业版的影响。

据全球人工智能市场追踪机构Aicpb.com发布的数据显示，在豆包预告专业版之后，豆包App 5月月活减少约610万，环比下降1.81%。这组数据后来被放进“豆包商业化是否过早”的讨论里，对这一点我其实持保留态度。5月月活下滑当然值得观察，但把它直接归因于“用户不愿为豆包付费”，证据并不充分——专业版都还没有正式推出。更可能的情况是模型体验感下降、竞品分流、外界对收费传闻的观感变化等多重因素共同作用。

我们有理由相信，那些轻信AI幻觉、把AI当成万能工具的用户，并不是专业版的付费受众。真正愿意为专业版付费的人，反而更清楚AI的边界，也更在意它能不能稳定完成任务。

从免费入口到付费AI工具，定位的变化同时也会带来用户结构的调整：免费阶段看的是规模，专业版阶段拼的是付费意愿和真实需求。

这对豆包是机会，也是压力。机会在于它可以从“全民尝鲜”的流量池里筛出真正有生产力需求的人，压力在于付费用户会更加挑剔。

所谓光脚的不怕穿鞋的，免费的豆包可以随时“滑跪”，通过说俏皮话的方式回避一些错误，用户顶多骂一句，骂完继续用。但在付费产品中，这种策略很难行得通。

用户为专业版付钱，可不是为了看它认错态度好，而是为了让它把事情办成。尤其在软件开发、数据分析、金融分析、流程自动化这些场景里，结果能不能用，比回答漂不漂亮重要得多。

02 OpenAI为字节打了个样

豆包专业版要解决的这个问题，OpenAI刚刚演示了一遍。

《金融时报》披露，OpenAI正准备对ChatGPT进行自2022年推出以来规模最大的改版。新版ChatGPT会把Codex、外部合作伙伴应用和Agent能力更深地接进来，把原本的聊天框，改造成一个能写代码、管理日程、操控软件的“超级应用”。

OpenAI正在把ChatGPT从一个聊天框，改造成任务分发的主入口。用户还是从ChatGPT进来，但背后接上的东西变多了：Codex负责执行更重的任务，外部应用负责接入真实服务，插件和Agent负责把需求往下推进。

据报道，改版初期，ChatGPT的网页端和移动端会增加大量提示词和功能入口，引导用户去使用编程工具、图像生成，或者调用Canva、Booking.com等外部合作伙伴应用。用户也会看到一个选项，可以手动选择让Codex还是ChatGPT来回应需求。

换句话讲，OpenAI做的不是一口气把所有东西都塞进一个聊天框里，让用户自己猜怎么用，它会在前期主动把入口摆出来，让用户知道：这里可以写代码，那里可以生成图像，也可以调用外部应用。等用户习惯之后，OpenAI再逐渐减少这些显性的提示和入口，让模型自己判断任务应该由哪个工具完成。

无论是改版还是改版方式，OpenAI的做法都很值得豆包学习。

OpenAI本质上是在把已有的两类资产接到一起：一类是ChatGPT这样的超级入口，一类是Codex这种更容易产生付费价值的工作工具。

《金融时报》援引知情人士称，Codex主要吸引的是付费客户；企业客户目前约占OpenAI收入的40%，预计年底会升至50%。与此同时，ChatGPT已经有约9亿周活用户和超过5000万付费消费者。

ChatGPT有规模，Codex有付费能力。OpenAI正在做的，是让规模入口承接更重的工作能力，再把这些能力转化成更强的付费理由。

Codex自己的增长也证明了这一点。OpenAI官方披露，Codex周活已经超过500万，自2月桌面App发布以来增长超过6倍；开发者仍然是最大用户群，但知识工作者已经占到约20%，而且增长速度是开发者的3倍以上。

可以认为，执行型AI已经开始从开发者圈层向更广泛的知识工作者扩散。

而豆包缺的正是这个环节。

字节手里其实有一套很完整的AI生态。豆包是大众入口，扣子负责Agent和工作流，Trae面向编程和开发者，飞书承接企业协作，火山引擎面向云和企业服务，即梦、星绘、小云雀、猫箱覆盖图像、视频、角色互动和内容创作，Seed则在最底层提供模型和多模态能力。

每个工具单独看都有价值，但如果要让用户为了一个任务开好几个会员、在几个产品之间来回切换，想想都觉得麻烦。

OpenAI的做法给了字节一个提醒：要真正进入工作场景，不只在于把模型做强、把工具做好，还可以打通各个环节，把入口做顺。

ChatGPT没有变成Codex，但它开始承接Codex的能力。豆包也不用变成Trae或扣子，但它应该把Trae、扣子、飞书这些能力接到自己后面。

类似的事情豆包并不是没有做过，在内容创作上，它已经接入了图像和视频生成能力。豆包专业版要做的，是把这种接入方式，从图像、视频创作，扩展到更复杂的工作工具上。

豆包专业版的想象空间就在这里，它不应该只是一个更强的聊天框，还应该成为字节AI能力的总入口。用户从豆包开始，把需求说出来，后面的Agent、代码工具、办公协作、云服务和模型能力自然接上。

比较理想的形态是，用户在豆包里提出一个开发需求，后面可以由Trae接住；提出一个自动化需求，后面可以由扣子拆任务、跑流程；涉及团队协作，结果可以进入飞书；涉及企业服务和模型调用，则可以接到火山引擎。用户看到的仍然是豆包，但背后跑起来的是字节自己的工具链。

到这一步，豆包专业版卖的就不只是“更聪明的回答”，更是把事情往前推进的能力。

03 任重而道远

字节其实没有别的路可选，豆包专业版既然要做软件开发、数据分析、流程自动化、金融分析、科学研究，就必须从聊天走向执行。

方向是清楚的，但问题也很明显：入口和工具接起来之后，背后有没有足够硬的能力。

现在看，字节手里的工具并不少。Trae面向编程和开发者任务，扣子主打Agent和工作流，飞书扎在企业协作场景里，火山引擎负责云和企业服务。它不是没有产品，也不是没有生态，但缺少一个像Codex之于ChatGPT那样清晰的执行器心智。

Codex被OpenAI“放进”ChatGPT的根本原因，在于它已经有了足够强的产品存在感。用户知道Codex能在编程和工作任务里带来效率提升，OpenAI把它接进ChatGPT，是把一个已经被市场验证过的生产力工具，放到更大的入口后面。

但Trae和扣子还没有走到这一步。Trae是字节在AI Coding上的重要产品，但在开发者心智里，它还没有像Claude Code、Codex那样成为明确的生产力符号。扣子有Agent、工作流、插件和知识库能力，很适合做豆包专业版背后的任务底座，但它目前更像一个给会搭建的人用的平台，还没有变成普通用户可以自然感知的执行能力。

豆包专业版要接入Trae和扣子，也并不是把几个产品入口摆在一起就够了。用户在豆包里提出需求后，开发、自动化、数据处理、文档协作这些能力要能顺着需求自然接上。至于背后跑的是Trae、扣子还是别的工具，用户未必需要知道。

工具层还只是第一关，再往下走，就会碰到底层模型能力。

豆包专业版瞄准的是真实工作场景，对模型的要求远高于普通聊天。尤其是Coding，软件开发可能是专业版里最容易被验证的能力。它不像普通问答可以靠语气和表达弥补，代码跑不通，结果就没有意义。

AI Coding是最早被验证的生产力场景之一，也是最容易让用户形成付费判断的场景。能不能写出可用代码，能不能完成真实开发任务，直接决定用户会不会觉得这个工具值钱。

在这一点上，字节也还没有形成明显优势。用户提到代码能力，可能会先想到DeepSeek、Kimi、智谱、MiniMax，而不是字节的编程模型。

DeepSeek最近在Agent、Coding 相关方向上的动作变得更明显，智谱也一直在强化Agent、开发者工具和企业场景，MiniMax则在多模态、Agent和工具调用上持续推进。它们都在在争夺真正能产生生产力价值的场景。

字节的优势是生态，但生态优势要变成商业优势，前提是模型能力和执行工具都要足够强。否则，入口再大，也只是把更多用户带到一个更贵的聊天框前；工具再多，也只是让用户在不同产品之间来回切换；生态再完整，也很难变成真正愿意付费的生产力系统。

或许这也是豆包专业版在当前并没有很被看好的原因，外界不是完全不理解字节为什么收费，只是在等它证明：豆包到底能不能从一个免费AI助手，变成一个付费生产力入口。

但至少方向是清晰的。模型能力可以慢慢补，工具心智可以慢慢建立，用户习惯也可以慢慢培养。字节现在最应该先做的，是学习ChatGPT的转型方式，把已有的生态打通，让豆包成为能调动扣子、Trae、飞书、火山引擎和Seed能力的总入口。

这条路不会轻松，但它必须走。

Codex 确实是软件开发工具，但它不是程序员的专属。它更像一个听得懂人话、还能自己动手干活的全能助理。整理文件、做图、写 PPT、自动填表、定时帮你跑任务，这些活它都能干，哪怕你一行代码都不会。

昨天官方还说，每周有超过 500 万人在用 Codex，过去一个月，分析师、营销人员、运营人员、设计师等非开发者，就占了新用户的 40%⁠。

我自己就是个不懂编程的 AI 产品经理，现在每天用它处理各种任务，效率直接拉满。

今天，我想手把手带你把 Codex 用起来，全程大白话，看完你也能让它替你干活。

开始前，先要搞明白第一个问题：Codex 到底是个啥？

1. Codex 是什么？又能干啥？

Codex 是 OpenAI 出的一个 AI 编程 Agent 智能体。

别一看到「编程」，就被吓退。它能干的事，远不止写代码。

最近官方频繁更新的功能，也已经拓展到通用办公场景。

现在你给它一个目标，它会自己规划、自己动手、自己检查，最后把事情做完交给你，而不只是跟你聊天。

这一点对普通人非常友好。你不用懂任何技术，只要你把需求讲清楚，剩下那些脏活累活，交给它去跑。

有人可能会好奇，那 Codex 跟之前很火的 Claude Code、OpenClaw 有什么区别呢？我让 AI 整理了个表，方便你对比。

简单来说，Codex 有一个超好用的客户端，普通用户特别容易上手。而且，它内置的模型，是目前超强的 GPT-5.5，实际效果真的能打。

Claude Code 是很强，但终端命令行的操作方式，直接劝退非技术用户，还要用 Claude 模型才有优势。

OpenClaw 要部署，消耗 token 特别多，用好的模型，长期用也顶不住。

所以，普通人闭眼选 Codex 准没错。

那它具体能干嘛呢？这里简单列几个：

• 整理电脑里的本地文件，一键归类、批量改名；
• 写文章、配图、整理表格；
• 做小红书图文笔记、自动生成 PPT；
• 操控电脑和浏览器，帮你跑各种自动化操作；
• 当然，还有它的老本行，开发网页、App 这些。

话不多说，我们赶紧上手。

2. 界面功能与基础设置

Codex 有 4 种使用方式：CLI 命令行、电脑客户端 App、网页版、编程 IDE 插件。

新手直接在官网下载电脑客户端 App 安装就行，界面跟聊天软件几乎一模一样，我也是用 App。

https://chatgpt.com/zh-Hans-CN/codex/

不过，需要说明下，Mac 版的功能会比 Windows 更全。

1）界面功能介绍

第一次打开 Codex，界面可能会有点陌生，我先带你认认路。

左边面板，是用来管理你所有任务的，包括功能区、项目对话的聊天记录和设置。

中间最大的那一块，是日常的对话工作区，与 AI 沟通，让它干活的地方。

右侧是结果预览区，查看生成的代码、文档、网页等，但无法编辑。

左边功能区比较基础，有新建对话、搜索对话、插件和自动化按钮。

聊天记录有 2 个类型，一个叫「对话」，一个叫「项目」。

这两个概念你一定要先分清，不然后面很容易乱。

对话，你跟 AI 的沟通，适合那些临时、零碎的小任务，比如随手问点东西、写个资料。

项目，是 Codex 真正的工作车间，你可以把一个项目理解成电脑上的一个文件夹，选定它之后，Codex 就以这个文件夹为工作区，这个项目生成的文件会存在这。

一个项目可以开多个对话，每个对话其实就是一个任务。

我一般习惯：同一类的事，归到同一个项目。如果是不同的任务，再单独开一个新对话，这样上下文不会互相干扰。

在项目右侧点击文件夹按钮，可新建一个空白项目，也就是一个新文件夹，也可选择一个已有的文件夹。

比如，我开发「专注时刻」App 就是一个项目；生成小红书笔记，也归为一个项目，每次要生成一个笔记，就在项目下新开一个对话。

接着，说说中间的权限和模型。

对话框左下角有个权限设置，点开有 3 种权限模式。

请求批准，最保守，它干啥都要你点确认审批；替我审批，AI 会先帮你审，检测到有风险的操作，才会让你审；完全访问权限，最宽松，放手让它自动跑。

建议新手朋友选「替我审批」。毕竟我们审的，未必有 AI 审的好。

我自己选「完全访问」，反正弹出来那些玩意我实在看不懂，干脆放开让它自己搞。

对话框右侧是模型选项。

模型直接选目前最强的 GPT-5.5 就行，每个模型可选「低、中、高、超高」4 档推理等级，等级越高，思考越久，日常任务选「高」就够了。

另外，生成速度有「标准」和「快速」，「快速」有 1.5 倍的速度，但会消耗 2 倍的 token。所以，如果不是特别着急的任务，选「标准」就行。

使用过程，我们如果想知道还剩多少额度，点击左下角「设置」，查看剩余用量。最近 OpenAI 动不动就重置额度，不让它多干点活，真有点浪费。

2）基础设置

开始实操前，有几个设置，我建议先弄好，用起来效果好很多。

点击左下角「设置」，进入设置页面，选择「常规」。

第一，「工作模式」选择「适用于日常工作」。

第二，「权限」，把前面提到的 3 种权限模式打开，对话框中才有得选。

第三，在常规中，滑动到下方的「撰写器」，把「显示上下文窗口使用情况」打开，这样每次对话能看到上下文是不是快满了，及时主动保存重要信息、压缩上下文。等上下文满了，它自动压缩，有时上下文信息不具体，会丢失一些细节。

第四，在「跟进行为」中，选择「引导」。这样你在 AI 干活时，想修改可以插队，不用等任务做完。

最后，进入「设置-个性化」页面，设置这 3 个东西：

选择 AI 回复的语气；自定义指令，相当于提前给它立规矩。比如，“请一直用中文回复”、“我是产品经理、不写代码，请尽量用大白话解释”，这样以后每一次对话都自动生效。

启用记忆，开了之后，它会自动记住你聊过的东西、你的习惯，不用每次都从头解释一遍。

哦，对了，最近 Codex 还支持手机远程控制。连接后，哪怕你人不在电脑前，也能用手机指挥它继续干活，挂着等结果就行。

3. 插件与技能Skills

Codex 强大的地方，还在于它有丰富的插件和技能，而且都是可视化界面操作。

插件，可以理解为一套整合好的工具包，包括技能、操作说明、工作流、MCP 服务等等。

技能，也就是 Skills，你自己开发的 Skill，在 Claude Code、OpenClaw、Hermes 用的Skills，都能给它安装。

点击左边面板的「插件」，进入插件市场，目前包含 62 个热门应用和 110 项技能。官方还新推出 6 种岗位工作的插件：数据分析、创意制作、销售插件、产品设计、公开股票投资、投资银行。

添加插件或技能，直接点击名称右边的「 + 」号就行。使用时，直接在对话框里输入 @，就能点名调用某个插件或 Skill。

Codex 有 2 个最实用的插件，推荐都安装：

• Computer Use（电脑操作）：它相当于给 Codex 装上了“眼睛和手”，它能直接看你的屏幕、移动鼠标、点击、打字，直接帮你操作电脑。
• Codex for Chrome（浏览器插件）：它操作你的 Chrome，自己打开网页、点击、填表单、抓数据，还能直接沿用你浏览器里已经登录好的账号状态，而且它是后台操作，不影响你正常用浏览器。

基础部分就到这，了解完这些，就算入门啦。下面进入重头戏，实用场景的使用案例。

4. 实用场景案例

1）整理电脑文件

Codex 能操作本地文件，帮我们整理文件夹自然是小菜一碟。

我的电脑「下载」文件夹常年是一团乱麻，截图、需求稿、竞品资料，还有一堆“未命名(1).png”全堆在一起，每次想整理，就劝退了。

于是，我让它帮我分析下文件，它会很聪明地先把文件扫一遍，连图片都会真的“看”一眼里面是什么，然后给我目录结构。

我确认完，再让它继续，你看，整理完是不是清爽很多？

2）安装软件

对于技术小白，在电脑上安装软件，绝对是个费时费力的事，很多时候，光安装就把我拦在门口。

有了 Codex ，我经常干的事，就是让它帮我装软件，之前很火的 OpenClaw 和 Claude Code，部署时要输入命令行，要安装依赖环境，非常麻烦。

我这台电脑的 Claude Code，就是让它安装的，虽然它卡了一会，最后还是成功了。

AI 时代，安装 AI 工具，应该让 AI 来干。

3）生成产品原型

以前出个原型，要自己 Axure 拉半天，做 UI 要排队等设计。如今我直接把想法描述给它，它就能做出一个能在浏览器里点击的高保真原型，拿给老板或开发看，比写一堆文字直观一百倍。

之前，我分享过这个用法，在 Codex 里面直接生成 UI 界面，然后再复原生成 HTML 前端页面。

这不是在“写代码”，是在用极低的成本，快速验证自己的产品想法。

当然，你还可以用 Codex 的 figma 插件，生成 figma 原型，方便团队协作。昨天 OpenAI 还推出了产品设计专用的插件，等我测完再专门分享，这里先不展开。

4）生成小红书笔记图片

我看许多做自媒体、内容创作的朋友，都把工作台迁到 Codex。

因为，它内嵌 GPT-Image-2.0 生图，把生图能力直接接进工作流，写内容和配图一口气搞定。做产品宣传物料、运营素材，简直不要太方便。

前几天，我把写好的文章，顺手扔给它生成小红书的图文笔记。

Codex 直接读我 Notion 上的文章，帮我写图片设计方案、笔记内容，我确认后，再调用技能，生成图片。

效果可以看这条内容：面试官：AI产品经理和传统产品有什么区别？

5）生成 PPT

动动嘴就能生成 PPT，这绝对是职场人的刚需。

把你想做 PPT 的内容发给它，或者跟它先沟通，生成 PPT 大纲，再 @ 一个做 PPT 的技能，它就能生成一份可用的 PPT。

这里我用了张咋啦的 Skill，它会把内容生成一个 HTML 格式的 PPT，设计和动画效果非常赞。

https://github.com/zarazhangrui/frontend-slides

你看，我把文章链接发给它，用这个 Skill 生成，它会先生成 3 个方案的封面让我选，我选完，它再继续生成。

更方便的是改稿。生成之后，在右侧预览窗口点「批注」，你可以直接在画面上圈出要改的地方写意见，比如“这里标题换成蓝色”，不用截图，批注完会自动把图片和修改意见发给 AI。

这种“对着画面指指点点”的改法，所见即所得，真的太方便了。

6）自动化填表单

第一次看到 Codex 推出 Chrome 插件时，我就惊呆了，它能自己打开网页、点击、填写表单、抓取数据，整个过程完全不用你动手。

刚好我要填一个申请表，让它试试：从打开页面，到一项一项把信息填完，全程都是它自己在操作，我在旁边看。

不过得提醒一句：操控电脑、浏览器这类能力，目前 Mac 版更完善。

我们都知道，工作中，有些不得不填的表、操作麻烦，还得头疼内容怎么写。Codex 这功能，真的是极大的释放人力。

7）定时任务，自动推送 AI 资讯

Codex 左侧还有个自动化功能，可以把我们日常重复性的事情设置为定时任务，每天自动跑。

你可以点击右上角「手动创建」，自己输入提示词设置。当然，这年头有 AI，能动嘴，就别动手。

举我自己的例子：我先安装了卡兹克大佬的 AI 资讯 Skill，再让 Codex 设置成定时任务，每天自动去抓最新的 AI 资讯日报，再推送到我的飞书。相当于雇了个不用睡觉、风雨无阻的资讯助理，每天早上打开就能看。

AI资讯Skill链接在此：https://aihot.virxact.com/aihot-skill/

你可以结合自己的需求：每天的数据汇总、定期的内容收集、固定的提醒……凡是“重复 + 定时”的事，都可以交给它。

8）开发个人作品集网站

最后一个场景，用 Codex 开发网站。

如今，有 AI 帮忙我们写代码，做一个网站门槛极低。开发个人作品集网站，对找工作、展示项目案例非常有帮助，值得大部分人尝试。

这里我演示一下，如何让 Codex 开发个人网站。至于，开发 App 应用，有兴趣可以看我之前那篇文章。

首先，开发网站或应用，稍微复杂的活，建议开启「计划模式」，点对话框左下角的「 + 」号，开启后它会先输出方案、列计划，等你点头确认它再开干。

另外，开发网页，如果想让 AI 生成好看一些，先找个前端开发的 Skill 或网站模板给它。这里我用 Codex 最新出的功能「应用快照」。

我看这个网页设计还挺舒服的，让它参考下。打开网页，同时按下两个「⌘」键（ Mac 版），它会把网页截图，并带上这个网页的信息，作为上下文给 AI。

再把我的基本介绍一起发给它，先让它做个效果出来看看，等确定风格，再给更多内容素材去填充完善。

你看，这就是生成的网站，配色风格还是模仿挺像的，但一些细节，还需要优化。通常第一次生成的结果，肯定会有问题，你可以用右侧预览区的「注释」功能，或者截图，告诉它，你想怎么修改。

最后，开发完的网页，只能在你自己电脑上看，想发给别人看，就需要部署到云服务器。

怎么办呢？我也不懂，直接问 AI，它就会给你方案，如果你不知道怎么选，跟它讲你的情况和需求，让它建议、帮你操作就行。

到这里，整个 Codex 的介绍、设置和应用场景都讲完啦。

写在最后

看到这，你应该也发现，这 8 个场景，不用写一行代码。

现在的 AI 已经强到，你只要把需求讲清楚，剩下的脏活累活它基本都能干。

当你把整理文件、做图做表、写汇报、填表单、盯日报这些杂活都交给 AI，把自己从”埋头执行”里拔出来，就有更多时间，去体验和感受生活。

AI 负责干活，人负责生活。

昨晚23:30的OpenAI直播没有发布新模型，但把Codex推到了更靠前的位置。

这场名为《工作中的智能》的直播中，OpenAI集中展示了Codex面向企业和知识工作的最新更新。其中最值得关注的有以下四点：

一、Codex将更深入ChatGPT。未来几周，OpenAI会把Codex能力接入ChatGPT，让用户在更熟悉的入口里直接调用它完成任务。

二、Codex新增了6个面向具体岗位的插件，分别覆盖数据分析、创意生产、销售、产品设计、公开股票投资和投行业务。

三、推出Sites和Annotations功能。前者可以让Codex把工作成果直接做成交互式网页、仪表盘或轻量应用，通过链接分享给团队；后者则允许用户在Codex生成的文档、图表、幻灯片和网站里直接圈选修改，像批注一样让AI继续加工。

四、OpenAI还披露了一组关键数据：Codex每周活跃用户已经超过500万，其中约五分之一来自非开发者知识工作者。Codex正在从程序员圈层向更广泛的企业岗位扩散。

AI白领工作台

这场直播最重要的信号之一，是Codex被推到了ChatGPT体系里。

此前，Codex已经以预览形式进入ChatGPT移动端，用户可以在手机上查看任务进展、批准命令、接管和调整正在运行的Codex任务。直播中，OpenAI又表示，未来还会把Codex功能更广泛地放进ChatGPT app，用户不一定要单独打开Codex，就可以在熟悉的ChatGPT入口里，直接让Codex接手更复杂的工作。

但这并不代表Codex和ChatGPT将合并成一个超级app，这次直播的新变化，也主要不是“产品合并”，而是 Codex 的定位扩大。

过去Codex主要面向开发者和工程团队，把Codex接入ChatGPT，可以理解为OpenAI在通过ChatGPT这个更大的入口，把Codex往更广泛的工作场景里推。

与此同时，OpenAI推出了6个面向具体职业场景的插件，覆盖数据分析、创意生产、销售、产品设计、公开股票投资和投行业务，把岗位所需的应用、技能和工作流打包起来，更接近真实办公场景。

这种打法并不陌生，很容易让人想到一个月前Anthropic刚刚推出过10个面向金融服务的Claude Agent。

不过Claude那套更垂直，主要围绕金融行业展开，而OpenAI这套比较横向，把Codex从编程扩展到了多个白领岗位。

其中，销售插件可以连接Salesforce、HubSpot、Slack、Outreach、Clay 等工具，帮助销售人员做客户研究、线索跟进、邮件生成和会议准备。

数据分析插件则接入Snowflake、Databricks Genie、Hex、Tableau等工具，面向的是企业内部的数据查询、报表生成、指标解释和分析结果呈现。

创意生产和产品设计插件连接Figma、Canva、Shutterstock、Picsart等工具，意味着Codex能够进入设计素材、视觉制作和产品原型的流程里，不只是“想创意”。

金融相关插件则更加直接。公开股票投资和投行业务插件接入Moody’s、FactSet、LSEG、S&P、PitchBook、Hebbia等数据和金融工具，面向研究、估值、市场分析、投行材料和投资研究等工作。

两个信息结合起来，OpenAI正在让Codex带着工具、数据和岗位流程，直接嵌进ChatGPT。

之前，ChatGPT负责对话，Codex负责执行。现在这两条线开始汇合，OpenAI想要让用户在同一个入口里，把问题、数据、文件、工具和工作结果都串起来。销售可以让它整理客户线索，分析师可以让它跑数据和做图表，设计团队可以让它生成素材和改页面，金融从业者可以让它辅助研究和建模。

换句话说，OpenAI正在重新定义Codex的边界。从一开始的AI Coding工具，变成一个更广义的AI白领工作台。

交付可用结果

除了职业插件，OpenAI 这次还推出了两个面向工作交付的新功能：Sites和Annotations。

简单理解，Sites就是让Codex把任务结果直接做成一个可以访问、可以交互、也可以分享的网页。

过去用AI做工作，很多时候得到的是一段文字、一份表格、一段代码，或者一组分析结果。按照OpenAI的介绍，Codex现在可以把工作成果直接生成为一个交互式网站、仪表盘或轻量应用，并通过链接分享给团队。

OpenAI给了几个具体例子。

比如，用户可以让Codex为即将到来的客户复盘创建一个site。Codex会生成一个交互式网页，放入相关产品更新、未解决问题、使用趋势，以及这个客户账户的下一步动作。

又比如，用户可以让Codex基于财务模型做一个情景规划器，让管理层直接比较不同假设，就不需要在文档的多个标签页里来回翻。

按照OpenAI的表述，Sites并不是一个静态页面。它可以用来跟踪重大项目进展、指导客服代表，也可以作为团队创意简报的资料库。OpenAI还表示，正在和Vercel、Wix、Base44、Replit、Lovable、Figma、Webflow、Emergent 等早期合作伙伴一起建设Sites生态。

Sites目前面向Business和Enterprise客户预览开放（毕竟是企业功能）。

Annotations，字面意思是注释功能。之前开发者就能在Codex里用它来改代码、Markdown和网站，使用方式很简单：用户指向想修改的具体部分，再告诉Codex需要改什么。

现在，这种方式会扩展到更多内容类型，比如文档、电子表格和幻灯片。

根据官方演示，用户可以选中一个site里的导航栏，让Codex更新字体；可以高亮投资观点里的一条判断，询问Codex这个判断来自哪里；也可以标出幻灯片上的一张图表，让Codex给出更清楚的标签。

两个功能放在一起看，Codex生成的结果正在变得更容易交付、分享和修改。

Sites负责把结果做成团队能打开、能查看、能互动的页面；Annotations则让用户可以直接在结果上继续反馈和修改。

对于企业工作来说，这比“生成一段内容”更接近真实流程，毕竟很多工作都需要反复迭代，先做出一个版本，再不断修改、确认。

Codex开始跑出规模

新功能背后，更重要的是一组关键数据。OpenAI披露，Codex现在每周活跃用户已经超过500万。从2月桌面app发布以来，Codex的用户规模增长超过6倍。

也就是说，Codex已经不是一个只在开发者群体里试用的新工具。它正在成为OpenAI企业产品线里增长最亮眼、也最值得被放到台前的入口之一。

按照OpenAI的说法，开发者仍然是Codex最大的用户群体。但知识工作者已经占到Codex每周活跃用户的约20%，而且增长速度是开发者的3倍以上。

如果Codex只是一个AI编程工具，它的边界就只是服务工程师、软件开发和代码仓库。但现在，Codex的用户结构已经开始发生变化，开发者之外，越来越多知识工作者开始用它处理工作。OpenAI这次推出6个具体职业场景的插件，也正是在顺应这个趋势，把用户自发生长的需求产品化。

还有一个数字也值得放在一起看：Sam Altman在这场直播中提到，OpenAI内部最大的token用户每月消耗约1000亿tokens，而且还有一些客户的消耗量比这个更高。他还说，成本已经成为客户最常提出的问题之一，仅次于“如何简化AI工作流”。

可以看出，企业正在更认真地使用AI，而且已经把AI放进了真实流程里。毕竟只有使用频率和任务复杂度足够高，才会出现每月百亿、千亿级别的token消耗。

另外，AI真正进入工作流以后，成本和复杂度也会同步放大。任务越长，调用工具越多，生成和修改越频繁，token消耗就越高。

token消耗已经开始变成企业财务和管理问题，并且在企业中并非孤例：Uber在四个月内耗尽了2026年AI编程工具预算；微软已经开始取消Claude Code许可证，推动相关团队转向GitHub Copilot CLI；Amazon在最近也关停了内部AI token排行榜KiroRank，因为这个榜单一度刺激员工追求更高token使用量，甚至让AI agent执行低价值任务来冲榜。

到现在，Codex的位置已经变成了OpenAI切入企业工作流的核心抓手，开发者仍然是基本盘，但增长最快的部分，正在来自更广泛的知识工作者。

在IPO叙事上，这次直播也是对Anthropic的一次追赶。Anthropic已经先一步把“增长、盈利预期、递表”三件事摆到了台面上，OpenAI这场直播，其实也在向市场回答：Codex也有增长，并且正在深入企业工作流。

作者：袁心玥

来源：字母AI

这篇文章的核心判断： Codex 不只是更会写代码的工具，而是 OpenAI 正在打造的 Agent 工作台样本。它真正改变的不是“代码怎么写”，而是“用户如何把真实任务交给 Agent 执行、监督、纠偏和沉淀”。

为什么产品经理值得读： 文章用一个从 0 到 1 生成 GEO 问题库 Agent PRD 的真实案例，拆出 Agent 产品从“生成内容”走向“接管工作流”的关键机制：需求澄清、边界纠偏、PRD / SDD / 原型产出、治理机制和复利沉淀。

读完你能拿走三样东西：

1. 一套判断 Agent 产品价值的五问框架；
2. 一个可复用的 PM × Agent 0-1 PRD 协作流程；
3. 一组衡量 Agent 工作台是否有效的指标口径。

一句话总结： Agent 产品不是比谁功能更多，而是比谁能更少断点地进入真实工作流，并持续提高“可托付任务”的完成率。

从一个 PRD 生成案例，看 OpenAI 如何把 Coding Agent 做成 Agent 工作台

一开始只是想让 Codex 帮我整理一份 PRD。我在做一个GEO 问题库 Agent，它要服务后面的 GEO 检测 Agent。用户可能会问大模型的问题拆出来、扩写出来、治理好，再交给检测 Agent 去判断品牌、产品或服务有没有被大模型正确提到。

现在很多工具都能生成 PRD、功能列表、用户流程和版本规划。但这次让我意识到不一样的地方，不是 Codex 写出了一份 PRD，而是它在中间经历了一次非常典型的“产品理解偏差”。

它一开始把问题库 Agent和后面的检测 Agent职责混在了一起：问题库 Agent 不应该去大模型里真实提问，也不应该判断品牌是否出现、引用了哪些信源、抖音和头条的信源偏好是什么。这些应该是下游检测 Agent 的职责。

我指出这个边界后，Codex 重新收敛了理解：

GEO 问题库 Agent 的边界，是穷举和治理用户可能会问大模型的问题，并输出可供下一个检测 Agent 使用的问题与意图字段。

这件事让我对 Codex 的判断发生了变化。

它不是一个“更会写代码的工具”，也不只是一个“能帮我生成文档的 AI”。更准确地说，它已经开始像一个能进入真实工作流的 Agent 工作台：它能读文件、理解上下文、生成文档、接受纠偏、继续修改，并把结果推进到SDD和HTML原型。

Codex 的价值是它正在把一部分真实工作流从人手里接过去。

这才是产品经理真正应该关注的地方。

如果你只想快速拿走方法，这篇文章提供三个可复用产物：

1. Agent 产品五问：用于竞品分析、PRD、产品评审，判断一个 Agent 产品是不是有长期价值；
2. 0-1 Agent 协作流程：用于 PRD 生成、内部工具和业务 Agent 设计，让 Agent 参与需求澄清、边界校准、文档和原型产出；
3. Agent 工作台指标口径：用于数据看板、版本验收和增长复盘，判断 Agent 是否真的进入工作流，而不是只产生调用量。

后面所有分析都围绕一个问题展开：怎么判断一个 Agent 产品是否值得被用户长期托付？

很多人还在比谁更会写代码，但问题已经变了

现在讨论 Codex，很多人第一反应还是把它放进 coding agent 赛道里比较：

• 它和 Claude Code 谁更强？
• 它和 Cursor / Windsurf 谁更适合开发？
• 它是不是比 Devin 更像 AI 工程师？
• 它有没有 memory、hooks、mobile、automation？

这些问题当然重要，但如果只停在这里，很容易把 Codex 看窄。

因为从产品视角看，Codex 真正的变化不是“写代码能力又强了一点”，而是 OpenAI 在把模型、文件、终端、浏览器、移动端、记忆、Skill、hooks、自动化和 review 机制，组织成一个连续的任务工作台。

这和普通 AI 工具的差别很大。

普通 AI 工具更像回答者：你问，它答；你给上下文，它生成内容。

Agent 工作台更像协作者：你给目标，它进入环境，拆任务，调用工具，执行动作，展示结果，接受监督，最后把经验沉淀下来。

这就是我认为 Codex 值得产品经理研究的原因。

它不只是一个开发工具案例，而是一个更大的 AI 产品问题：

未来 AI 产品的竞争，不是看谁接了更强的模型，而是看谁能更低摩擦地进入用户真实工作流，并持续完成可托付任务。

我用 Codex 生成 PRD：真正有价值的不是“生成”

回到我的 PRD 案例。

这个 GEO 问题库 Agent，一开始只是一个模糊产品想法：我需要一个上游 Agent，帮助我从行业、客户业务、用户场景里拆出用户可能会问大模型的问题，再生成可复用、可治理、可交付给检测 Agent 的问题库。

如果让普通 AI 直接写，它大概率会生成一份看起来完整的 PRD：背景、目标、功能、流程、指标，一个都不少。

但真正难的不是写全，而是写准。

这个产品里面有几个很容易出错的地方：

第一，不能把“问题库 Agent”和“检测 Agent”混在一起。

问题库 Agent 负责生成和治理问题；检测 Agent 才负责去真实检测大模型回答、品牌出现、引用信源和内容缺口。

第二，不能把“批量生成问题”当成核心价值。

真正的价值不是生成更多问题，而是围绕客户业务和 GEO 检测价值，生成真实用户可能会问、且能触发品牌 / 产品 / 服务曝光的问题。

第三，不能完全相信模型输出。

问题库会影响后面的检测质量，所以它需要结构化字段、自动初筛、人工判断、风险标记和规则沉淀。

如果把这次过程拆开看，它不是“一次生成 PRD”，而是经历了 4 个关键回合：

我的初始输入：先读已有说明，告诉我你理解到了什么，哪些要补，哪些要优化 Codex 第一次理解：定位基本对，但把部分下游检测职责混进了问题库 Agent 我的纠偏动作：明确问题库 Agent 只负责问题与意图字段，不负责真实检测、信源分析和内容缺口判断 Codex 修正结果：重新收敛边界，再把 PRD、SDD 和 HTML 原型继续往下推进

这个过程对 PM 很有启发。因为很多 AI 生成 PRD 的问题不是“不会写”，而是“写得很完整，但方向错了”。真正有价值的 Agent 协作是让 Agent 先暴露理解，由 PM 纠偏关键判断，最后继续推进交付物。

Codex 在这个过程中做了三件有价值的事。

它先拆需求，而不是直接写文档

Codex 先读已有说明文档，然后把产品理解拆成几个判断：

• 这个 Agent 的定位不是“批量生成问题”，而是“行业问题库生成与治理 Agent”；
• 主流程是：输入采集 → 行业理解 → 意图矩阵 → 问题扩写 → 初筛归并 → 人工标注 → 知识沉淀；
• 最关键的生成公式是：问题扩写 = 用户画像 × 决策阶段 × 问题意图；
• MVP 不应该先做完整 SaaS，而是先跑通从行业输入到问题库输出的最小闭环。

这一步很像一个产品助理在帮你把模糊想法结构化。

被纠偏后，它能重新收敛产品边界

当我指出它把下游检测职责混进来时，它能重新理解边界：

• 不负责去大模型里实际提问；
• 不负责判断客户 / 产品是否出现；
• 不负责分析引用了哪些信源；
• 不负责做后续内容缺口分析；
• 只负责输出可供检测 Agent 使用的问题与意图字段。

这对 PM 很重要。

因为 PRD 最大的问题往往不是“不够完整”，而是“边界不清”。边界不清会导致开发不知道做到哪里，后续 Agent 链路也会互相污染职责。

PRD 之后，它继续推进到 SDD 和原型

最后，Codex 不只是生成 Markdown PRD，还继续补了 SDD 开发文档和 HTML 可视化管理看板原型。

这个原型里已经有了公司信息录入、问题库、人工判断、知识库、日志版本、Prompt / Rule / Schema / KB 版本展示，以及开始搭建、回滚等操作入口。

这一步很关键。

PRD 解决“要做什么”，SDD 解决“怎么开发”，HTML 原型解决“用户如何操作”。三者连起来，才更接近一个可交付开发的 0-1 产品包。

这个案例给我的最大启发是：

Codex 不是替产品经理写文档，而是把 PM 的 0-1 产品思考过程，变成一个可执行、可检查、可复用的 Agent 工作流。

把这个案例抽象成可复用工作法

这次 PRD 生成过程，真正值得复用的不是“让 Codex 写一篇文档”，而是一套人机协作流程：

模糊想法 → 让 Agent 先复述理解 → 找出产品边界偏差 → 用户纠偏关键判断 → Agent 更新 PRD / SDD / 原型 → 把纠偏沉淀成下一次 SOP

可以把它拆成一张 PM 工作表：

这里有一个很实用的判断：Agent 写得快不重要，重要的是它能不能在被纠偏后继续沿着正确边界推进。

这里我会把自己完整的 PRD Prompt 拿出来，它不能替代 PM 的业务判断，但足够帮助读者把普通 AI 生成 PRD，从“直接写文档”提升到“先对齐理解，再生成可评审材料”。

你现在是一个产品经理助理。请不要一上来直接写 PRD。

我会给你一些业务背景、用户需求或已有材料。

你的第一步是先做“理解对齐”，输出以下内容：

1. 产品定位：这个产品 / Agent 处在什么业务链路里？上游是谁，下游是谁？

2. 核心问题：它真正要解决的业务问题是什么？不要只复述功能。

3. 目标用户与角色：谁会使用它？谁负责判断结果？谁会接收它的输出？

4. 使用场景：列出 3-5 个最核心场景，并说明每个场景的触发时刻和成功结果。

5. 做什么 / 不做什么：明确产品范围和非目标，特别是不要把上下游模块职责混进来。

6. MVP 范围：第一版只做哪些最小闭环？哪些先不做？

7. 核心流程：用“输入 → 处理 → 人工判断 → 输出 → 记录 / 沉淀”的方式描述流程。

8. 输入输出字段：列出关键输入、关键输出、状态字段、风险字段和下游需要读取的字段。

9. 人工判断点：哪些地方不能让模型自动决定，必须交给人判断？

10. 验收标准和指标：怎么判断这版产品可用？至少给出效率、质量、风险、复用四类指标。

11. 风险与边界：列出可能的误判、合规、数据、版本、下游兼容风险。

12. 需要我补充的信息：列出你无法判断、必须向我追问的问题。 先只输出“理解对齐版”，不要生成正式 PRD。

等我确认和纠偏后，你再按下面结构生成 PRD：

– 文档元信息：状态、Owner、版本、产品定位、上下游、文档边界

– 摘要：一句话说明产品解决什么问题、服务谁、输出什么

– 背景与问题定义

– 产品目标与非目标

– 目标用户与核心场景

– MVP 范围：包含 / 不包含

– 核心业务流程

– 功能需求：按模块写输入、处理、输出、异常、人工判断

– 输入输出 Schema：字段、枚举、状态、必填 / 选填、下游接口需求

– 页面或功能结构：如果需要管理台，列出页面、操作入口和关键字段

– 日志、版本与回滚

– 验收标准

– 指标体系

– 风险与应对

– 决策记录与后续待展开内容

写作要求：

– 不要写空泛愿景，要写可交付、可评审、可开发的内容；

– 不确定的地方不要编，标为“待确认”；

– 发现上下游边界不清时，先提醒我，不要自行合并职责；

– 每个模块都要说明输入、输出、失败情况和人工介入点。

这个公开版提示词的重点不是“套模板”，而是强制 Agent 先做三件事：复述理解、暴露边界、列出待确认问题。只要这三件事做到了，PRD 生成质量通常就会比直接让 AI 写正文高很多。

Codex 强的不是“有某个功能”，而是组织出一条任务链

如果只看功能名，Codex 其实没有那么“独占”。

Claude Code 有 CLI、IDE、hooks、memory、routines 和远程控制；Cursor / Windsurf 在 IDE 和 agentic coding 上很强；Devin 更像云端 AI 软件工程师；OpenClaw 强在多渠道和自托管 Gateway；Hermes 强在开源自学习、memory 和 skills。

所以这篇文章不想论证“别人没有，Codex 有”。这个论证很容易过时。

我更愿意把这些产品看成不同路线：

• Claude Code：工程师工作流路线；
• Cursor / Windsurf：agentic IDE 路线；
• Devin：云端软件工程师路线；
• OpenClaw：多渠道自托管 Gateway 路线；
• Hermes：开源自学习 Agent 路线；
• Codex：OpenAI 体系里的 Agent 工作台路线。

Codex 的机会在于，它把很多能力放进了一个更统一的任务链里：

用户提出目标 → Agent 理解上下文 → 进入文件 / 终端 / 浏览器 / 远程环境 → 执行任务 → 展示 diff / 测试 / 截图 / 结果 → 用户审批和纠偏 → 经验沉淀为记忆或 Skill → 下次任务复用

这条链路越顺，用户体感越强。

用户不会因为一个产品“有 hooks”就觉得它好用。用户真正感受到的是：危险操作有没有被拦住？改完代码有没有跑测试？结果能不能验收？下次是不是少解释一次？

用户也不会因为一个产品“有移动端”就觉得它强。真正有价值的是：手机能不能发起任务、查看状态、审批动作、验收 diff，而执行仍然发生在电脑或远程环境里。

也就是说，Agent 产品的竞争，不是功能点竞争，而是任务链组织能力竞争。

PM 怎么复用：把功能矩阵改成任务链矩阵

所以做 Agent 竞品分析时，不要只列“谁有 memory、谁有 hooks、谁有 mobile”。更有用的做法是把功能放回任务链里问：

这张表是产品经理最应该带走的部分：Agent 产品不是比功能数量，而是比谁能减少任务链里的断点。

Codex 的用户体感为什么会更强？

我认为核心有五点。

复杂工具被下沉到 Agent 执行层

CLI、终端、Git、测试、依赖、路径、权限，这些东西对工程师很高效，但对普通用户或非深度开发者来说是认知负担。

Codex 的价值不是把终端做得更漂亮，而是改变终端的位置：

复杂工具不会消失，但会从用户界面下沉到 Agent 执行层。

用户站在目标、判断和授权层，Agent 去处理执行复杂度。

这对其他 AI 产品也有启发：如果你的产品里有复杂后台、复杂配置、复杂表格、复杂命令，不一定要把所有复杂度都可视化出来。你也可以让 Agent 吸收一部分执行复杂度。

它能进入真实环境，而不是只在聊天框里给建议

很多 AI 工具的问题是：它说得对，但用户还要自己复制、粘贴、执行、验证。

Codex 的产品价值在于，它可以进入文件、终端、浏览器、本地或远程环境，把“建议”推进成“产物”。

这也是为什么我的 PRD 案例比单纯聊天更有说服力：它不是给我一段回答，而是落到了 PRD、SDD 和 HTML 原型里。

记忆和 Skill 让一次任务变成长期复利

一次任务只是交付，长期复利才是产品壁垒。

如果用户每次都要重新解释偏好、项目背景、文档结构、代码规范、风险边界，那 Agent 就只是一次性工具。

真正的好体验是：用户纠正一次，系统下次少犯一次；用户沉淀一个流程，系统下次能复用；用户形成一个判断规则，系统能把它变成 Skill 或 SOP。

这也是 Hermes 这类自学习 Agent 方向重要的原因。Codex 的意义在于，它在往同一个方向走，但更偏产品化和低门槛。

Hooks、审批和 Sandbox 解决的是“敢不敢授权”

Agent 越能干，用户越需要安全感。

在高价值场景里，用户真正担心的不是 AI 不够聪明，而是：它会不会删错文件？会不会改错配置？会不会泄露密钥？会不会绕过团队流程？

所以 hooks、权限、审批、diff、日志、review queue 这些东西，不是“高级配置”，而是 Agent 进入真实工作的门票。

治理不是拖慢自动化，而是让用户敢把真实任务交出去。

手机不是开发机，而是指挥台

移动端做 coding 这件事，天然别扭。

手机不适合敲命令、看大段日志、处理文件和调试环境。但手机很适合做四件事：发起任务、补充上下文、审批关键动作、查看结果。

所以 Codex mobile 的意义不是让手机变成开发机，而是让手机连接正在运行 Codex 的电脑或远程环境，让任务不再卡在“我现在不在电脑前”。

跨端产品设计的重点不是复制功能，而是重新分配设备角色。

产品经理真正该学的，是这套 Agent 产品设计方法

如果你不是做开发工具，这篇文章依然有价值。

因为 Codex 背后的方法可以迁移到很多 AI 产品里：SaaS、内容工具、数据分析、知识管理、客服质检、内部效率平台，都能用。

我把它总结成五个问题。

你的 Agent 服务的高密度场景是什么？

不要一上来做“全能 Agent”。

先找一个痛点强、频率高、结果可验证、早期用户愿意尝试的场景。开发者场景之所以适合 Codex 冷启动，是因为 Bug、PR、测试、代码审查都有明确结果。

迁移到其他产品也是一样。

比如客服质检、内容审核、销售线索整理、数据报表异常检查、PRD 生成，这些都比“通用办公助手”更适合做 Agent MVP。

你解决的是功能缺口，还是工作流断点？

很多 AI 产品喜欢堆功能：聊天、插件、记忆、工作流、知识库、自动化。

但用户真正痛的是工作流断点：信息在多个工具之间搬运，判断标准散在不同人脑子里，结果没有被验证，经验没有被沉淀。

产品经理应该先画用户完成任务的全链路，再找上下文断点、风险断点和验收断点。

你的 Agent 有没有进入真实环境？

只在聊天框里回答，价值是有限的。

Agent 要变成工作台，必须进入真实环境：文件、表格、浏览器、业务系统、数据库、代码仓库、知识库、审批流。

否则用户还是要自己复制粘贴、执行和验证，Agent 只是一个更聪明的说明书。

你的 Agent 有没有长期复利机制？

好产品不能每次都像第一次服务用户。

你要设计：哪些偏好要记住？哪些流程要沉淀？哪些 Bad Case 要进入规则？哪些高频任务可以变成 Skill？哪些人工判断可以变成下一次的默认策略？

这决定了 Agent 是一次性工具，还是越用越懂用户的系统。

你的 Agent 有没有治理机制？

高价值场景一定需要治理。

哪些动作必须审批？哪些输出必须验证？哪些风险必须拦截？哪些结果必须留日志？哪些错误必须能回滚？

如果没有这些机制，用户不会把真实工作交给 Agent。

一张 Agent 产品设计检查表：

如果你要设计或评审一个 Agent 产品，可以直接用下面这张表：

这张表也可以反过来用在 PRD 里：每设计一个 Agent 功能，都要能对应到其中一个检查项。对应不上，大概率就是“看起来很 AI，但不一定有产品价值”。

也要明确：哪些事情不能直接交给 Agent

强调 Agent 工作台，不等于说 PM 可以被替代。恰恰相反，越是高价值 Agent，越需要 PM 保留关键判断：

• 战略取舍不能直接交给 Agent：比如先做哪个用户、先验证哪个场景、哪些需求暂时不做；
• 业务边界不能默认相信 Agent：比如我这次案例里，Codex 就一度混淆了问题库 Agent 和检测 Agent；
• 高风险输出不能直接发布：涉及合规、品牌、客户判断、数据口径的内容，都需要人工确认；
• 指标解释不能只看表面：调用量上涨可能是用户更依赖，也可能是 Agent 没听懂导致反复追问。

所以 PM 的角色不是被 Agent 替代，而是从“手工写所有材料的人”，变成“定义边界、纠偏判断、验收结果、沉淀规则的人”。

不要用“调用量”判断 Agent，要看可托付任务

很多团队做 AI 产品，容易盯着调用次数、对话轮次、生成量。

但对 Agent 工作台来说，这些指标不够。

用户聊得越多，不一定代表产品越好。有时恰恰说明 Agent 没听懂，用户被迫反复解释。

我更建议用这个指标做北极星：

每周被用户验证通过的可托付任务数。

这个指标包含三层意思：

1. 每周：说明不是一次性尝鲜，而是持续使用；
2. 可托付任务：说明任务有明确目标、真实环境和交付结果；
3. 验证通过：说明结果被用户或系统确认可用。

再往下拆，可以看：

• 任务完成率；
• 人工接管次数；
• 重复解释次数；
• 平均执行时长；
• 高风险动作拦截次数；
• Skill 复用率；
• 相似任务成功率；
• 任务返工率。

这些指标比“生成了多少内容”更能说明 Agent 有没有真的进入工作流。

好的 Agent 工作台，不是功能最多的产品，而是能持续提高可托付任务完成率，并同时降低用户解释成本、人工接管成本和风险成本的系统。

如果要写进 PRD，我建议把指标口径写得更具体：

• 可托付任务完成率：用户交给 Agent 的任务中，最终被验收通过的比例，用来判断 Agent 是否真的能交付结果；
• 人工接管次数：任务过程中用户被迫接手的次数，用来判断自动化是否足够稳定；
• 重复解释次数：用户对同类背景、偏好、规则的重复说明次数，用来判断记忆和 Skill 是否有效；
• 高风险动作拦截次数：hooks / 权限系统拦住的危险操作，用来判断治理层是否产生价值；
• Skill 复用率：已沉淀 Skill 在相似任务中的使用比例，用来判断产品是否形成长期复利；
• 任务返工率：用户验收后要求重做或大改的比例，用来判断 Agent 输出质量是否可靠。

这类指标的价值在于，它们不只衡量“AI 有没有被使用”，而是衡量“AI 有没有减少用户完成真实任务的成本”。

所以，Codex 给 PM 的启发是什么？

如果只把 Codex 当成编程工具，你看到的是：它能写代码、跑命令、改文件、生成 PR。

但如果从产品视角看，你会看到另一件事：OpenAI 正在尝试把用户的一部分数字工作流，交给一个可监督、可复盘、可沉淀的 Agent 系统。

这才是 Codex 真正值得研究的地方。

它提醒产品经理：

• 不要只做“AI + 某个功能”，要问 AI 能不能重组任务链路；
• 不要只比较功能有无，要比较谁能形成更完整的任务闭环；
• 不要只追求全自动，要设计人工判断和治理边界；
• 不要只看模型能力，要看模型能力如何被产品化成稳定体验；
• 不要只做一次性交付，要让每次任务变成下一次的能力。

我现在越来越觉得，未来很多 AI 产品都会从“回答问题”走向“接管流程”。

而 Codex 的产品意义就在这里：

它不是一个更强的代码助手，而是一个正在成型的 Agent 工作台样本。

如果你是产品经理，真正该研究的不是 Codex 会不会写代码，而是它如何让用户愿意把真实任务交给 Agent。

这件事，可能比写代码本身重要得多。

如果你要把这篇文章用于自己的工作，可以按三个层次使用：

1. 做竞品分析时：不要先列功能有无，先画出每个产品服务的任务链。
2. 写 Agent PRD 时：先写清楚高密度场景、工作流断点、真实环境、人工纠偏、治理和指标。
3. 做产品评审时：重点问“这个功能有没有减少用户完成任务的断点”，而不是“这个功能够不够 AI”。

这才是我认为 Codex 对 PM 最大的价值：它不是告诉我们“AI 可以写代码”，而是提醒我们重新设计用户完成工作的方式。

资料与边界说明

本文是基于 2026-05-30 公开资料和个人使用案例写成的产品分析，不是最终测评结论。Agent 产品迭代非常快，发布前建议再次核验官方文档和版本信息。

主要参考：

• OpenAI：Introducing the Codex app、Work with Codex from anywhere、Codex hooks、Codex memories
• Anthropic：Claude Code overview、Claude Code changelog
• Cursor：Cursor changelog、Cursor on web and mobile
• Devin：Devin docs、Devin release notes
• Windsurf：Windsurf changelog、Cascade overview
• OpenClaw：OpenClaw docs
• Hermes：NousResearch/hermes-agent

大概是三个月前的晚上，我又一次在 Steam 库里翻来翻去，心里那个念头再也压不住了：我也想做款游戏。

从小时候的4399到长大的steam，游戏贯穿我的青春始终，作为一个持续创作者，想做属于自己思想和基调的一款游戏这个想法时常在我的脑中弹出，每次都被同一个东西挡回去——我不会写代码。准确说，是没法像程序员那样，坐下来从头搭一个可运行的东西。产品经理那点懂技术的底子，在 Godot 编辑器面前跟没有一样。

去年我在使用cursor的时候就感觉这东西太猛了——我说人话，它就吐代码，而且真能跑。它是真的能听懂“我想让这个按钮在点击之后变灰然后弹出一个确认框”这种描述，而且它吐出来的代码，你不用去改语法，直接就能用。我脑子里突然闪了一下：如果我不把它当编程工具，而当成一个听得懂需求的全栈程序员，那游戏是不是也能这么干？

然后我就干了。我决定做探案解密类型的独游，作为新手初作，游戏类型上可以尽可能保守一些，引擎我选了 Godot，理由很现实：免费开源，不用交保护费，而且它的节点系统和场景结构非常直觉，跟产品经理拆功能模块的思维方式特别对路。后来发现，Codex 配 Godot 这个组合，比我想象的还要顺滑。

我的第一个可玩版本

我开局没有去学 Godot，甚至没看教程。就直接打开 codex，新建了一个项目，然后对着对话框打字：

“帮我搭一个旅馆二楼走廊场景，2.5D 视差，分背景中景前景三层，玩家用 WASD 控制角色移动。”

十秒钟，脚本出来了。复制进去，运行，屏幕上真的出现了一条有纵深的走廊，壁灯和门在中景，栏杆在前景，一个胶囊体小人能走来走去。说实话效果挺烂的，但还是有一瞬间的爽感。

这里我必须要说一句 Godot 的好话。它的 2.5D 视差实现起来天然就比某些引擎简单——几个节点分层，摄像头不动只移动层，思路清清楚楚。Codex 显然也懂这一点，它生成出来的代码直接就是 Godot 的那套做法：用 ParallaxBackground 套 ParallaxLayer，干净利落。如果换个引擎，光视差这块我可能就要折腾一天，但在 Godot 里，AI 十秒钟搞定。

当然，问题马上来了。这个小人走到走廊尽头会穿墙。我给它加了碰撞体，没用；改了刚体设置，还是穿。最后我把报错信息连同整个移动脚本直接扔回给 AI，问了一句：“为什么碰撞检测失效？”

它告诉我：你在用 transform.position 直接位移，这种方式会绕过物理引擎，要用 Rigidbody.MovePosition。还顺带解释了物理更新应该放在 FixedUpdate 里。我一边改一边想，这不就是 Code Review 吗？Codex 最让我服气的地方就在这里——它不只帮你写代码，它还能帮你查问题。你不需要知道该查哪行，只要把症状和报错一起丢过去，它就能给你定位，顺带把原理讲清楚。一个永远在线的、不嫌我烦的高级程序员。

第一个“游戏”就这么搭起来了。没有美术，走廊是灰蒙蒙的方块拼的，可互动的门就是两个长方形叠在一起。但它是可玩的。我让朋友试了一下，她控制小人在走廊上走了两圈，打开一扇门进了一个空房间，转头跟我说：“感觉还行，当然，除了丑”

就这一句话，我觉得这事儿能继续。

我把 GDD 当需求文档写，AI 还真吃这套

产品经理的职业病在这儿彻底犯了。

稍微搭了点东西之后，我没有急着让 AI 继续生成功能，而是停下来，花了一个下午在 Notion 上写了一份游戏设计文档。就是平时写 PRD 那个路子：核心循环是什么，一共有几幕，每幕有哪些场景，场景里有哪些可交互的物体，每个物体有哪些状态变化——写清楚了，AI 才知道怎么给你写 Tween 动画。

写完以后，我就把这份文档当成需求池来用。每次跟 AI 提需求，都从文档里摘一段上下文喂给它。Codex 在这里体现出一个特别产品经理友好的优势：它的上下文窗口足够大，记忆力好。你把一大段背景设定贴进去，它真的会记住，后面生成代码的时候会自动对齐你说的那些约束，不会前面刚说了“这个抽屉需要钥匙”，后面又给你生成一个一拉就开的脚本。

AI 生成出来的代码质量，跟需求描述的清晰度完全成正比。这一点跟我们带团队一毛一样——你自己没想清楚的东西，执行的人（哪怕是 AI）做出来一定是一坨。

而且我发现一个特别顺手的技巧：用用户故事的格式描述交互逻辑。比如：“作为一名玩家，我希望当我点击抽屉时，如果身上有钥匙则播放开锁动画并打开，否则提示‘抽屉上了锁’。” AI 对这套表达方式的理解好得离谱，生成的代码状态判断、UI 弹窗、动画协程全都给你整整齐齐码好。

最爽的瞬间：让 AI 帮我干那些打死也学不会的活

我虽然是美术生出身，早年也是做的设计，但是对于游戏资产懂得真的很少。

以前这是硬门槛。你有再好的想法，角色长什么样？场景什么氛围？这些搞不定，游戏永远停在方块阶段。

但现在不一样了。我游戏的美术风格是表现主义厚涂加哥特木偶美学，角色的形象都是特殊材质。直接让 AI 出图肯定翻车，第一次给的 prompt 出来光滑得像个手游。后来我想了个招：先让 AI 出个大概造型，然后我自己在 Photoshop 里把皮肤那块用材质贴图改了，调了半天反光，再把这张图作为“种子图”喂回去，让 AI 记住这个感觉去生成其他姿态。

虽然最后的小人还有点僵硬，但整体效果已完全过得去，我盯着屏幕看了好久。那种感觉怎么形容呢，就像一个从来不会画画的人，突然看到自己脑子里的人活了。

作为一个什么都会一点、什么都不精的人，这种跨领域翻译能力简直救命。

真实的低谷

上面说的都很爽，但不代表整个过程是爽文。

大概在第四周左右，我开始搭证物系统和侦探日志。逻辑本身不复杂——收集证物，存入面板，日志里按角色分页显示线索，审讯时出示证物触发不同对话。AI 帮我把框架搭得挺干净，用 Godot 的自定义 Resource 存证物数据，信号系统做事件通知。

这里我真心想夸一句 Godot 的信号机制。它不像某些引擎里事件系统是后加的，用起来总有一种“穿靴子”的感觉。Godot 的信号是节点自带的，你在编辑器里就能看到每个节点能发什么信号，Codex 也很懂这个，生成的代码直接用 `signal` 关键字定义自定义信号，然后 `emit`，连接方用 `connect`，语法简洁得令人发指。后来重构的时候，这套信号系统救了我的命。

但当我开始配数据的时候，问题来了。哪条证物关联哪个角色、在哪个推理阶段、解锁哪条对话、骰子判定难度是多少——这些全是一张巨大的 JSON 表。我让 AI 帮我写了读取和判定的脚本，但表里的内容只能我自己填。填到一半我发现，早期 AI 帮我生成的那些脚本，因为当时赶进度没约束架构，变量命名乱七八糟，一个光照状态能被三个脚本分别修改。配上这张大表以后，整个系统耦合得跟意大利面一样。

那一刻我真的想删项目。这就是典型的产品初期为了追上线时间疯狂堆功能，最后攒出一堆技术债。只不过这次，债主是我自己，欠债方式是我纵容 AI 随便写。

后来我狠心停工一天，不写任何新功能，把所有脚本拿出来重新梳理，然后对 AI 下了一个新指令：“把现在的代码重构，引入事件总线模式，所有跨物体的状态变化必须通过信号通知，不再允许直接引用。” 它给我重构了一版，虽然过程中改崩了两次（那天晚上我的心情跟坐过山车一样），但最终稳下来了。而且因为 Godot 的节点本身就是树形结构，信号在节点间传递的路径非常清晰，AI 重构出来的事件总线代码量比我预想的少得多。这是引擎的架构本身在帮我们兜底。

这个教训我到现在都记得：**AI 能让你跑得飞快，但它不会替你考虑三个月后的事。** 你得从一开始就给它架构约束，就像你带团队时得定好规范一样。否则后面的坑，一个都不会少。那张 JSON 表我现在还在填，但至少填表的时候不用再担心改一个值崩三个地方了。

它不会懂得什么叫手感

还有一个 AI 解决不了的东西，叫“感觉”。

我让 AI 帮我做鼠标悬停物品时的高亮光圈。它很快给了我一版 Shader，但光圈边缘有一圈白边，在 Forward+ 渲染器下预乘 Alpha 有问题。它改了三次才修好。修好以后光圈的呼吸节奏我又调了很久——太快显得廉价，太慢显得迟钝。最后定下来的节奏是 0.6 秒渐入，0.2 秒微亮保持，0.4 秒渐出。AI 写对了代码，但这个节奏是我一遍一遍试出来的。

还有那个丝线提拉的数值。AI 最初给的脚本是让丝线在说话时做持续 sin 抖动，看起来像角色在蹦迪。我跟它说不要抖动，要一种“被轻轻提起来”的感觉。它不理解什么叫“轻轻提起来”。最后我只好把它翻译成它能懂的语言：Tween，向上位移 3 像素，0.3 秒，EaseInOut。它终于写对了。但定义“3 像素才有提线木偶感”的，是我的眼睛。

Codex 能把你对细节的想象翻译成精确的技术参数——前提是你自己先找到那个参数。Godot 能让你在编辑器里实时看到改参数的效果——前提是你知道该改哪个数。这两个工具一个负责翻译，一个负责呈现，但它们都替代不了你的审美判断。

80 分以下，AI 能推着你走。80 分往上，得你自己来。那些你觉得“对”的数值、节奏、材质反光度、运动的力度——这些都在你玩了二十年游戏之后身体里攒下来的“体感”里。

这也是目前大部分小白尝试vibe coding的感受，被AI带入一个全新领域，发现自己需要学习的还有很多

所以

这两个月我花了大概两百个小时，做出了一个能跑的原型。能活动的场景地图，有角色能在场景中互动，有一张我亲手在填的 JSON 配置表。朋友试玩之后说“审讯那段有点意思”，我正在一条一条改。

如果没有 AI，这个东西在第一周就会死掉——死于我完全不会写 Shader，死于我画不出任何像样的角色，死于我只能在下班后的两小时里缓慢绝望。如果没有 Godot，我可能光折腾引擎和框架选型就要花掉一半热情。

AI 帮我把做游戏这个念头，从一种遥远的、属于别人的可能性，变成了我晚上打开电脑就能往前推一点的日常。而 Godot 让我的这些笨拙的想法有一个干净、免费、不会被突然收回的容身之处。它俩加在一起，给我的感觉就是：门槛还在，但已经是一道你能迈过去的坎。

但codex不是主角，你才是。定义这个世界是什么样子、里面住着谁、他们的眼睛是什么材质、玩家触碰他们时听见什么声音的，是你。这件事从来没有被替代过，以后大概也不会。

如果你心里也藏着一个想法——不一定是游戏，可能是某个 app，某个工具，某个很早就想做的产品——但一直因为我不会而搁着。我真心建议你现在就去试试。

过去一年，我身边很多人都陷入了一种特别累的状态。

不是工作累，是学工具累。

n8n出来要学，扣子出来要学，Cursor、Windsurf、Trae，一个接一个，每次有新的出来都要去折腾，生怕落后。

有个朋友跟我说，他光是配置各种AI工具的环境，就花了好几个小时，结果用了没两个月，发现这些工具已经开始往边缘退了。

整个过程什么都没做成，只是在装工具。

这种焦虑其实是有解的。

解法不是更努力地追，而是等一等。AI工具领域有一种典型的后发优势。有时候你迟一步，你原本要解决的问题就已经不存在了。

当Claude Skill 出来之后，n8n,dify这些低代码工具其实就不太需要了。

现在Codex又来了，之前很多IDE工具覆盖的场景，基本上一个Codex就够了。

Codex是OpenAI出的桌面端agent工具。

一个ChatGPT账号就能用，免费版也行，只是额度少一点。

如果你能科学上网，这是目前新手入门AI工具最值得装的一个。Codex安装地址：https://chatgpt.com/zh-Hans-CN/codex/

01  学习AI编程最好用MacOS 系统

这一点很多人没有提前说清楚，等踩了坑才知道。

目前主流的AI编程工具，从Codex到Claude Code，底层的设计和测试都是优先考虑Mac环境的。Codex在Windows下可以用，但部分功能会有明显差异，比如computer use这个能控制本地应用的功能，目前就只有Mac版本有。手机控制Codex也主要支持Mac系统。

不只是Codex。Hermes这类新兴的agent工具，安装和运行同样对Mac更友好，依赖环境的配置在Mac上出问题的概率更低。Claude Code作为命令行工具，在Mac的终端环境下运行也比Windows顺畅得多。

背后的原因不复杂。Mac的Unix底层和大多数开发工具的设计逻辑是一脉相承的，环境变量、权限管理、命令行交互这些东西在Mac上几乎是开箱即用的状态。Windows虽然这两年通过WSL（Linux子系统）改善了很多，但对新手来说，光是搞清楚WSL怎么配置就已经够折腾了。

所以如果你正在考虑认真学AI编程，手边有Mac的话，优先用Mac。

入门款的话，Mac mini就可以，但是内存要大，AI编程非常吃内存，最低16G以上，Mac mini非常的小，你只需要配一个蓝牙键盘，鼠标，再配置一个小的显示器就行。也非常便携。

02 对于新手推荐Codex+Cursor

Claude Code、Codex、Cursor，到底有什么不一样。

这三个工具经常被放在一起说，但大多数比较都说不到点子上。

Claude Code是Anthropic出的，默认用Claude模型，各种高级功能都是它先发明的，skill、MCP、hook、远程操控，能力非常全。

上图为Mac OS 终端terminal下的Claude code编程环境。

通常大家通过AI工具的编程插件联动Claude code或者通过Mac OS 终端（terminal）来编程。这需要在Mac OS 终端中下载Claude code然后绑定你自己Claude账户。它的交互方式是在终端里打命令，黑底白字，对没有开发背景的人来说门槛确实不低。

如果你是初级AI编程用户，那么建议你放弃用terminal终端来编程。

并且用Claude的朋友反馈目前Codex在快速的赶上来，在编程上更为谨慎，效果更好，Claude容易一不注意就写出很多BUG。

为什么推荐Codex

首先，它本身付费会员的Token量足够多。并且Codex APP上就可以实时查看Token的消耗情况，这点比Claude code好很多。从目前迭代速度来看Codex并不比Claude code差。

其次，对于新手来说，它的界面也很简洁，只有三个区域：左侧的项目区、中间的对话区、以及右侧的实时状态展示区。你专注跟它说话，生成的代码和文件变化在展示区呈现最终效果。

即使是写入飞书多维表格这类需求，最右侧的实时状态展示可以展示进度。这点非常赞。

这是我写入飞书表格的一个SKILL，每天会去抓取全网的AI产品经理的知识点。它依然会给我可视化看板。

代码不会直接暴露在你面前，你不用分心去处理那些文件细节，只需要看进度、看结果。

第三点，Codex的设计逻辑不一样。它不强制你必须有一个项目。临时的任务，随时开一个对话就能干，干完就结束，没有那么多前置步骤。比如安装Hermes或者安装Openclaw，你在Cursor或者Trae装一个命令行工具、临时处理一些文件，Cursor就不太顺手了。这些AI编程平台要就需要开通一个项目，尽管整个编程并不会基于你的文件夹操作，但是Trae这类AI编程工具，就需要创建Project项目才能开始工作。

第四点，这个点很值得说：中途打断。用传统的AI编程工具，如果任务跑到一半，你发现有什么要调整的，大多数情况下你只能先暂停，重新描述清楚，让它从头来过，而且这会消耗大量的上下文token。Codex不一样，任务执行过程中，你可以随时在对话框补充新的要求，它不会立刻中断，而是把你的补充放进队列，下次调用工具的时候结合上下文一起处理，内容不会乱，也不会浪费额度。这一点在实际使用中比你想象的重要。

第五点，对于新手建议先用Codex，或者专注使用一个。

Claude code底层用的是Claude.md这个文件来维护整体的上下文质量，Codex用的是agents.md。两个工具的底层逻辑不一样，如果你同时用两个工具反复改同一个文件，底层的文件包可能会被两边改来改去，容易出问题。所以两个工具最好在独立的系统环境里用，不太适合混着来。

第六，Codex支持绑定Cursor。点击Codex右侧的实时状态展示区右上角的Cursor图标，就可以用Cursor打开这个项目。并且看到这个项目的代码。Cursor是目前最主流的AI编程IDE，适合你想认真看代码、手动调某个细节的时候用。

我的推荐是：主要用Codex，再装一个Cursor。Codex负责执行日常任务，Cursor负责在你想深入看代码细节的时候打开项目查一查。两个配合，基本覆盖了大多数场景。

03 它能做哪些事，跟普通AI有什么区别

先说最核心的一点。

以前用ChatGPT，让它看到本地内容只有两条路：复制粘贴进对话框，或者按格式上传文件。这两种方式有个共同的问题：AI处理完，结果还在AI那边，跟我们本地的世界没有连接。

Codex不一样。它可以直接访问你电脑上的文件夹。

读取内容、写文件、移动文件、重命名，不限数量，不限格式。你把一个文件夹指定给它，里面所有的内容就成了它随时可以调用的上下文。

举个实际的例子。有人本地存了八十多条视频素材，命名全是乱的，看文件名根本猜不出内容是什么。把这个文件夹交给Codex，让它根据视频画面重新命名，它自己想到用抽帧的方式提取关键画面，拼成缩略图批量判断，然后按序号、场景、行动的格式命名，全部搞定，过程中没有来问一次权限，因为操作都在授权文件夹内。

这件事ChatGPT根本做不了。

文件操作之外，Codex还可以直接使用你电脑的命令行。

原本需要打开终端、照着教程一步步抄命令才能完成的事，比如安装Node.js、下载某个新出的agent工具，你只需要告诉Codex你想装什么，它自己去搜文档、下载、验证，装好了告诉你。遇到报错，截图发给它，它帮你修。

那些之前要跟着手把手教程、照着命令一行行抄的环境配置，就这么绕过去了。

04 它记得住你，这件事比看起来更重要

AI工具有个老问题：没有记忆。每次对话都要重新交代你是谁、要求是什么、偏好是什么。

Codex用两层持久记忆解决了这个问题。

第一层叫全局记忆，文件名是agents.md。写在这里的规则对所有项目生效，比如”以后修改飞书文档，用黑色字体加删除线标注，不要直接覆盖原文”，或者”我们统一用中文沟通”。你在对话里跟它说好，让它存到全局agents.md里，以后每次打开Codex，它都先把这套规则读进去，不用再解释一遍。

第二层叫项目记忆，只在当前项目里起效。项目有了一定内容之后，让Codex根据它对项目的了解自动生成这个文件，它会把项目背景、文件结构、规则、注意事项都写进去。以后新开对话，或者聊天记录清空了，它读一遍这个文件，立刻就能接上上下文继续干。

这两层记忆存在本地，不会随对话结束消失。适合写全局记忆的，是那些你在任何项目里都希望它遵守的工作习惯和偏好；适合写项目记忆的，是这个项目特有的背景和规则。两层分开，不会互相干扰。

用久了会发现，这个设计是让Codex真正变成”你的助手”而不是”一个陌生AI”的关键所在。

05 装软件、接工具、把代码部署上线，它都能帮你做

命令行的能力，展开来说能做的事情比大多数人想象的多。

举两个具体的例子。

一个是安装Hermes。Hermes是最近比较火的一个agent工具，但安装过程对新手来说有一定门槛。以前要去找文档、搜教程，一步步照着来。现在直接告诉Codex：”最近有个叫Hermes的agent很火，帮我装一下。”不需要给它官网链接，它自己去搜索，判断是哪个，找到官方文档，照着文档把依赖装好，装完还会验证一遍确认成功。装好之后想用就用，不想用了让Codex帮你卸掉也是一句话的事。

整个过程你不用打开终端，不用抄命令，不用担心哪一步出错。

另一个是飞书CLI。飞书把它软件里几乎所有能做的操作都做成了命令，让agent可以直接调用。把飞书CLI的安装链接丢给Codex，它装好之后引导你完成授权，搞定之后Codex就可以直接帮你操作飞书了——写文档、发消息、建日历、填表格，不用你动手打开飞书去找。

这两件事放在一起，其实说明了同一个事情：以前那些”需要找教程才能完成”的环境配置类任务，现在基本上可以直接甩给Codex。

部署代码上线也是一样。以前这件事如果找外包，少说也要几百块。现在通过Codex装一个部署插件，比如Netlify，引导你完成授权，它自己跑完部署流程，最后把链接给你，别人就能访问了。全程不需要懂服务器，不需要懂命令行部署逻辑。

遇到问题也不用自己查。报错了截图发给Codex，它帮你判断是哪里出了问题，给出解决方案，或者直接帮你修。

06 从”问AI”到”管AI”，这是两件不同的事

用Codex的体感，跟用ChatGPT有个本质的不同。

以前用ChatGPT，逻辑很简单：有问题去问，得到答案，走人。现在用Codex这类agent，你要做的事情变了：帮它准备好工作环境，告诉它目标，检查它的计划，监督过程，验收结果。

这件事说出来好像不难，但很多人还是停在”问AI”的状态，没有切换过来。

区别在于，”问AI”是拿了一把更好的锤子，”管AI”是换了一种建房子的方式。前者省时间，后者改变工作结构。两件事的量级不一样。

Codex是一个比较好迈进去的起点，功能齐，门槛不高，额度也相对大方。对大多数不写代码的人来说，从这里开始是个合理的选择。

至于那些之前折腾n8n、低代码工具的经历，也没有浪费。那些思路在Codex里大多能找到更直接的实现方式，只是不再需要那么多配置了。

刷 X 的时候看到一个挺有意思的 Prompt。

发的人叫 Vaibhav（VB）Srivastav，OpenAI Codex 团队的开发者布道师，之前在 HuggingFace 干过，推上近5万粉，长期分享 Codex 用法。这条是升级版——他之前简化版，社区反馈之后迭代出了这版更完整的，被 OpenAI 联合创始人、总裁 Greg Brockman 转发了，3500赞，80万浏览。

核心思路一句话：让 Codex 审计你自己的工作流，把你反复做的事自动打包成可复用的模块。

@AI_Whisper_X 给它起了个名字叫”蒸馏自己”——蒸馏的不是模型，是你自己的工作习惯。

这段 Prompt 到底做了什么

VB 的 Prompt 让 Codex 做四件事：

1. 回顾历史，找模式

Codex 会看三个数据源：

1. 你最近的 Codex sessions 和任务摘要
2. Codex Memories 里跨 session 的重复模式
3. Chronicle（如果你开了的话）——捕捉 Codex 之外的工作重复

2. 筛选值得沉淀的事

不是所有重复都要自动化。Prompt 设了硬条件：

• 至少发生过两次，或者明显会反复出现
• 输入稳定、流程可重复、有明确的结束条件
• 做成自动化后确实能提升速度或质量

3. 选最小形式

符合条件的，选最轻量的包装方式：

• Skill：可复用的工作流或操作手册
• Subagent：一个有边界的小专家角色
• Automation：定时跑的检查、报告、提醒

一个原则：能窄就窄，能小就小，别搞大而全。

4. 先列清单，再动手

Codex 不是上来就干活。它会先给你一个清单：每条工作流有什么证据支撑、出现频率、推荐形式、值不值得做。你确认了才动手。

为什么说这是”蒸馏自己”

我们日常用 AI 工具，大部分时候是在”用完就走”——每次从零开始，prompt 重写一遍，上下文重新喂一遍。

但回头想想，上周和这周干的活，可能有不少是重复的。

重复的不是写代码，是判断、排流程、调同一个参数。这些东西散落在每次对话里，不会特意记，但每次都在消耗注意力。

这段 Prompt 的价值在于：它让 AI 去翻你的历史，把你自己都没注意到的模式找出来。

你不需要反思”我有什么可以自动化的”——你的历史记录就是最好的素材，Codex 帮你读。

怎么用

如果你在用 Codex，这段 Prompt 直接贴进去就行：

Look back over my recent work from the last 30 days, or all available history if shorter, and identify repeated manual workflows worth packaging.Use available evidence in this order:

– Recent Codex sessions and task summaries.

– Codex Memories and rollout summaries to find patterns repeated across sessions.

– Chronicle, if enabled, to spot repeated work outside Codex. Use Chronicle for discovery only; confirm important details in the relevant source system when possible.

– Existing skills, custom agents, and automations, so you reuse or extend what already exists instead of duplicating it.Look broadly for work that is repeated, time-consuming, error-prone, context-heavy, or benefits from a consistent process. Include workflows across coding, research, writing, planning, communication, operations, analysis, and personal administration.Only act on a candidate when it:

– occurred at least twice, or is clearly likely to recur and costly to repeat;

– has stable inputs, a repeatable procedure, and a clear output or stopping condition;

– would materially improve speed, quality, consistency, or reliability;

– is not already adequately covered.Choose the smallest appropriate form:

– Skill: a reusable workflow or playbook.

– Custom subagent: a bounded specialist role or investigation task suitable for delegation.

– Automation: a scheduled or recurring check, report, reminder, or monitor.

– Skip: work that is too one-off, ambiguous, sensitive, or poorly evidenced to package.First produce a compact shortlist with:

– repeated workflow

– supporting evidence and dates

– frequency/confidence

– recommended form: skill, subagent, automation, extend existing, or skip

– why it is or is not worth creatingThen create only the high-confidence missing items. Keep them narrow, practical, source-aware, and easy to validate. Do not create speculative, overlapping, or overly broad assets.Finish with:

– what you created or extended

– what you deliberately skipped

– what needs more evidence before packaging

翻译一下关键步骤：

1. 数据源优先级：先看最近的 session，再看跨 session 的记忆，最后看 Chronicle（Codex 之外的日志）
2. 筛选标准：至少重复两次 + 输入稳定 + 能提升效率 + 目前没有覆盖
3. 输出形式：skill（操作手册）、subagent（小专家）、automation（定时任务）、或者跳过
4. 先列清单：每条带证据、频率、推荐形式、值不值得做的理由
5. 最后才动手：只做高置信度的，跳过模糊的，标出需要更多证据的

评论区比正文还有意思

这条推文下面的评论质量很有意思。

有人说”这招像给自己做代码习惯体检”，有人说”这不叫蒸馏自己，这叫把班味提纯了——以后不是我干活，是我训练出来的我在替我加班”。

但最有价值的一条来自一位前端转 AI 全栈的开发者，他指出了关键：这个 Prompt 最有价值的地方是让 Codex 先做一次工作流审计，“生成 skill”反倒是其次。

他说得很到位：真正该沉淀的是你反复做、容易漏、且能被验证的事，偶发操作就算了。每个 skill 最好都带触发条件、反例和验证命令，不然很容易把偶发操作也固化成流程。

还有一位点出另一个关联：这个思路跟 Anthropic 的 dreaming 机制异曲同工——让 AI 在你不工作的时候主动回顾、主动发现可优化的地方。

看见模式，比执行模式更重要。