codex能处理很复杂的任务吗

代码的目标功能怎么开？什么样的任务适合开？用第三方模型能不能用这个功能？怎么保证目标模式完成的任务的质量？怎么给他权限？ 这是我上个视频评论区关注最多的一些问题。哈喽，大家好，上个视频我发了关于 codex 的 后功能的使用体验，收到了大家很多的关注。今天我会一个视频，讲清楚 codex 的 目标功能到底怎么用，什么时候用， 如何高质量的用。希望大家帮忙点赞评论关注。首先需要说明， codex 的 go 不是 让模型突然变聪明，也不是你丢一句话它就可以无限的自动驾驶 go， 它本身是和模型无关的，并不是模型的功能，而是 agent hines 同面实现的一个机制，是 codex 的 产品和运行环境这一层的能力。所以首先第一个问题， 用第三方模型到底能不能用这个功能？答案是可以的，只要你是通过扣代词使用这功能，再更新到最新版的 app 都是可以使用的，但是效果就不一定有 g p u 五点五那么好了。 官方对目标的定义是给扣代词一个持续存在的目标，这个目标既是他开始工作的指令，也是他判断到底做完没有的标准。所以 go 最重要的不是跑的久，而是有一个清楚完成的标准。所以第二个问题，什么样的任务适合开 go？ 答案是，如果你只是改一个按钮的颜色，或者修一个很小的 bug， 实现一个很简单的需求，其实没必要上钩。当然，如果你是给他一个 ui， 让他完全对齐这个 ui 设计稿去实现你的 ui 页面，那还是可以的， 真正适合构的是那种多步骤会中途跑，测试会反复修，而且你不想一直在旁边盯着打 continue 的 任务，比如说迁移一个项目，重构一块模块，修一批测试，做性能优化这种任务，你可以给他一个明确的目标，他就可以围绕这个目标去持续的推进。 再比如前面讲的，你给他一个 ui 稿，我个人感觉扣代词在审美这块还是差点意思的，但是你给了他明确的标准，对其 ui 设计稿去实现 ui 页面，他就会一直修改，并且修改完之后去启动项目对比 ui 稿，做到像素级的还原。甚至你都可以用 gpt 一 米二去生成一个精美的页面， 毕竟 gpd 一 米二的生普能力大家是有目共睹的。评论区有人说只有十个小时，最后写出一坨，其实这个问题不是 go 本身能解决的，而是你给的 go 太空了。 go 的 核心是有一个明确的目标加验收标准，不要写帮我优化一下这个项目，优化这个动作本身是没有一个明确的验收标准的，也就不是一个明确的目标，优化哪个方向，功能交互还是性能优化到什么程度才算是完成？这些都没有一个明确的标准。那第三个问题，应该怎么使用 go 呢？ 特别是你没办法明确说出你的目标和验收标准的时候。其实有两种办法，第一种是先 plan， 再去用 go 去执行， 提出你的需求，先让 codex 把任务拆清楚，你确认验收范围没有跑偏，再把这个 plan 去变成 go。 第二种，如果你的 codex 已安装上了 superpower 插件，那么你可以直接开启目标模式，你可以说出你模糊的目标，这个时候他前几步会主动的去跟你澄清，直到明确为止才真的去执行这个目标。 也有人问死停完怎么办？比如他用方法 a 跑不通过，一会又用方法 b。 也有人问做科研做复旦任务能不能一阶段一阶段的验收。这里就聊到了第四个问题，如何高质量的用目标功能去提高产物的质量。这里有几个技巧。 第一个就是构力最好加上停止条件，同一个方案失败两次就必须换方案，或者停下来报告原因，不要让他在错误的路径上你去预谋。注意，这里并不是停止你的目标， 在没有满足你的目标之前， codex 是 不会给这个目标去标记上已完成的标志的，它只是暂停了，等你澄清或者纠正之后，是可以点击继续目标去执行的。 第二个技巧， go 不是 让你完全不看了，而是让你不用每分钟问一句继续，不用中间持续的去给他解释上下文，但是中间你随时可以插话纠正。阶段性的去看 def， 看测试，看结果。你仔细观察就会发现， codex 的 go 并不是想象中的，你给他一个 query， 他 一直跑，中间不停止， 反而更像是他自己把围绕这个目标的实现拆解成了很多的小步骤，并且每实现一个小步骤，他都会做充分的测试和验收， 验收通过了这小步骤就会被提交。那他是怎么继续开始新的小步骤的呢？其实更像是完成一个小步骤之后，他自行判断这个目标是否完成了，然后判断下一步该做什么，给自己了一个下一步骤的新宽瑞。 只不过之前这个昆瑞是需要人觉得上一个步骤没问题了，人去判断下一步应该做什么。了解了这个机制，在他执行某个步骤的过程中，你就随时可以点击停止目标，并且对他进行纠错或者提问，确认没问题了，再点击继续目标即可。最后再说一个额外不算技巧的内容。 很多人对目标都是小心翼翼的，开了一个目标之后不敢随便乱点，不敢电脑合上，不敢重启 app， 会担心中间网断了怎么办？账号额度没了怎么办？ 答案就是这些都不会影响目标。你的网断了，在网络恢复的时候，可以重新进到那个规划去点击恢复目标，你账号额度没了。一般情况下，在这个账号额度恢复的时候，目标都会自动的继续，但如果没有的话，你也可以手动点击继续。 像我的 pro 账号是五倍的订阅，经常会在五个小时额度重置之前额度消耗完。我这个时候就会用一个账号切换器去切换账号，切换完 app 是 要重启的，重启完之后我就会去点击这个规划里面去继续目标。最后，关于权限这个问题，官方确实支持减少 approval， 比如不想他每一步都问你。 首先说明一下我自己，其实是开的完全的权限，但是是建立在一个干净的分支可信项目的基础上，确保它有 get 记录。此外，再通过外的 hux 机制去保证不操作项目之外的内容上的。 最后总结一句， go 的 价值不是让 codex 永远跑下去，而是让 codex 不 在每一步等你。推一下智能用法，不是让它干活，认清楚什么叫干完。关注我，了解更多 ai 技巧。

很多人用 codex 做复杂任务时，都会先说一句，你先帮我做个计划。这个习惯当然是对的，但问题是，很多计划最后只留在对话里。一开始， ai 可能会规划得很清楚，第一步做什么，第二步做什么，风险在哪里，测试怎么跑？但等你中间补了几次测试， 测试失败了几轮对话越来越长之后，经常会出现一个问题， ai 好 像又偏离了最初的计划。所以这一期我想聊一个非常实用的思路，别把复杂任务的计划只留在对话里。 对话里的计划本质上还是上下文，上下文很适合保存当前这次交流的信息，但它不一定适合保存一个复杂任务的完整状态，尤其是这些任务。比如一次比较大的重构， 比如跨多个文件的功能开发，比如需要先读代码，再设计方案，再分阶段执行。再比如测试失败后需要反复修复。这时候，计划如果只存在聊天记录里，就很容易出现三个问题， 第一，早期计划被后续对话冲淡。第二，关键发现散落在聊天记录里。第三，如果任务跨绘画继续， ai 不 一定还能完 完整知道之前做到哪一步。所以我越来越觉得，如果计划只留在对话框里，它不是项目资产，它只是临时上下文。复杂任务的计划最好能进项目文件系统，这就是 planning wins files 这个 skill 想解决的问题，它解决的不是 ai 会不会做计划的问题。 cortex 本来就可以， plan 科室也有自己的 计划模式，很多 ai 编程工具也都可以先规划再执行。但普通 plan 最大的问题是，它通常还停留在当前工具、当前绘画、当前上下纹理。而 planning with files 的 思路不一样，它会为一次复 杂的任务在项目组里面生成一组 planning 文件，包括 task plan， confidings， progress。 task plan 用来记录任务目标、阶段拆分 执行计划。 firing plans 用来记录调研过程中的发现，比如关键代码位置、项目结构、分线点和设计判断。 progress 用来记录当前做到哪一步， 哪些已经完成，哪些测试已经通过，还有哪些问题没有解决。所以它不是简单地让 ai 写一个计划，它更像是给这次复杂任务创建一个小型任务工作区。我个人觉得， planning with files 和普通 plan 模式最大的区别就在这里。普通 plan 模式是让 ai 在 这次对话里想清楚， planning with files 是 让项目把这次记录任务记下来， 这意味着什么？假设我今天用 cortex 做了一个重构任务， cortex 生成了这些文件，明 我不想继续用 context 换成 ctrl 或者其他 ai 编程工具。他只要读取这些文件，他就可以知道这次任务的目标是什么，之前做过哪些判断，哪些文件已经读过，哪些代码已经改过，哪些测试已经通过，还有哪些问题没有解决？这点很关键， 因为复杂任务的状态不再被锁在某一个 agent 的 上下文里，而是沉淀到项目文件系统里。当计划进入文件系统，任务状态就不再属于某一个 agent， 而是属于这个项目。 不过这里也要注意，不是所有任务都需要这个 planning with files 这个 skill。 如果只改一个变量名，补一个小函数，做一个简单的功能，那完全没必要，小任务直接做效率更高。 planning with files 这个 skill 更适合快 多个文件的修改，比较大的重构，需要先调研再开发，需要多轮测试和修复，或者是今天可能做不完，后续还要继续，甚至中途换不同 agent 来接手。简单地说就是小任务靠对话，复杂任务靠文件。 实际使用的时候，我因为还装了别的 skill， 我 会明确告诉 codex 我 大概是这么做的， 然后再加上需求，我将是显示地告诉那个 cortex， 我 要调用这个 skill。 它会为呃任务创建 task， plan， findings， progress 这些文件，这组文件就变成这次任务的入口。下次继续做的时候，不管你用 cortex， cursor 还是其他的 ai agent， 都可以先让它 读取这几个文件再继续执行。这和普通 plan 的 模式的区别就很明显了，普通 plan 更像是一次对话里的临时计划， planning with files 更像项目里的任务状态文件所。 所以这一期我想表达的是，复杂任务不要只留在聊天里，要变成项目里面的任务资产。 planning with files 的 价值不只是让 cortex 写计划，更重要的是它把计划发现进度都放到项目文件系统里，这样复杂任务就有一个可恢复，可以追踪，甚至可以被其他 ai agent 继续接手的工作区。不过这也会引出下一个问题，如果我同时安装了 planning with files， superpowers， 甚至还有自己写的 planning skill， cortex 到底应该听谁的？同类 skill 装太多会不会冲突？会不会增加 token 消耗？这个问题我们下期继续聊，这里是 cortex 共创实践，下期我们继续。

这是一条 codex 从零到一完整的新手入门教程。如果你之前完全没用过 codex， 或者只是听说过，但不知道它到底能干什么， 怎么装，怎么用，那这条视频你就可以收藏了。我会按照一个新手真正上手的顺序，带你从 codex 试什么，讲到安装、使用、主界面、怎么操作、基础功能和进阶技巧、 skills 插件、浏览器终端和自动化任务等等，让这个目前全球最顶级的 a 阵的工具真正为你所用，创造价值。 我也会把整个流程整理成文档，打一句 codex， 方便对照，一边看一边选。你可以先把它理解成一个装在电脑里的 ai 工作助手，他不是单纯陪你聊天的工具，而是可以进到一个具体的工作文件夹，帮你读取文件、修改内容、运行命令、调用工具，甚至按步骤完成复杂任务。 举个最简单的例子，像 chat、 gpt、 豆包这一类工具，更像是你问他答，你自己去做。比如你想做一个网页，他通常只会给你一段代码，接下来你还要自己复制代码、创建文件、运行、检查报错等等。而 codex 是 你问他，他理解他还做，他会从零到一帮你创建好这个网页。 目前最适合新手小白的上手方式呢，是桌面端 app， 我 们可以直接在官网开始，根据你的系统选版本， windows 或者 mac os 都可以。安装之后有两种登录方式，一种是官方 chad gpt 账号登录，另一种是用 apikey， 可以 是官方的，也可以用中转站。两种方式各有利弊。综合来看，还是建议第一种，直接官方账号登录， 省心省事。对于 codex 的 界面，新手可以先关注三个核心区域，最左侧是一些常见功能入口和聊天记录管理区，你可以理解为导航栏加历史记录。这里需要重点讲一下对话和项目的区别。对话最好理解就是普通聊天嘛，你甚至可以把它直接理解为 chat、 gpt 或者豆包， 适合随便问一些小问题，帮你写文案、查资料之类的。它不跟具体的文件夹绑定，而项目就涉及到了具体的生成式任务，比如 如飞哥之前开发的工具箱网站，飞剪一触即达这种软件，他们有大量的编程代码文件，就需要一个专用的项目文件夹。你在这里可以新建空白项目，也可以打开现有文件夹，直接选择路径，或者直接把文件夹拖进来也行。鼠标悬停在项目名上，也能看到这个文件夹在电脑中的 底位置。而对于重要的常用的项目和对话，右键就可以置顶，方便快速切换和查看。左侧下方还有设置入口，在设置里你可以修改 codex 的 使用偏好、外观和配置等等。其中个性化需要重点说一下， 如你想给他一个全局指令，就在自定义这里直接写，比如他要怎么称呼你，固定用中文回答问题，设定一些底线原则或者开发习惯，设置完之后对所有项目都会生效，相当于让这个员工摸清楚你这个老板的脾气，投你所好。这里还有一个很有意思的小功能，叫桌面宠物， 他提供了很多默认的宠物形象，你也可以根据自己的喜好让他帮你创建一个，比如我这个就是给了一张参考图，让他自己做出来的，他会实时显示当前任务的一些简单状态，还是挺好玩的。 在首页设置这里还能看到剩余用量，你可以清晰的看到五小时用量和一周用量，做到心中有数。中间这块就是你和 codex 的 主要沟通区域。首先是这个加号里面有两个非常重要的功能，一个是计划模式， 比如你让他开发一个个人博客网站，不要上来就直接让他干，而是让他先列出计划。相当于你给员工一个项目，得先让他出方案，看看他打算怎么做，这样能有效减少返工，既省精力又省 tokyo。 看啊，他会主动问我们这些具体细节，我们按选项敲定，不满意的或者他没提到的就补充一下，让他重新规划， 这才是一个合格的领导该干的事。而目标模式就更厉害了，刚上线的新功能就是你给他设定一个目标，越具体越好，他会自己拆解分析。执行审查，有一种不达目的不罢休的意思，这样就避免了一个很烦的问题，执行一个任务的时候，他每完成一步就要停下来问你。 比如我正在跑的一个很复杂的大项目，目前已经连续跑了三十多个小时，如果正常一步一步改的话，我可能要好几天才能做完这些进度。右边这个权限设置呢，分成三档，默认是最保守的，像是联网修改文件都需要你的授权，自动审查会开放一部分权限，关键节点还需要你把控。 而完全访问就是最激进的，它几乎可以完全操控你的电脑，创建文件、删文件、跑命令，全都自己干。新手，我不建议一上来就开完全访问，刚开始用默认或者自动审查更稳，等你确认这个项目没问题，也知道它要做什么，再考虑给更高权限。我自己是在非常熟悉项目和流程的情况下才会开完全访问。 右边这里还可以切换模型，选模型版本、智能程度和推理速度。如果不是特别复杂的任务呢？不建议开超高，因为它有可能会出现过度思考，而导致你花了更多的 token， 反而干的不好。 这是血淋淋的实战经验教训，一般来说默认高就可以了。这个麦克风是语音输入，但是体验目前并不是很丝滑，我们可以直接用语音输入法。 codex 还有一个和普通聊天很不一样的地方，任务可以排队，他正在执行的时候，你可以继续补充，要求这些新消息会一个一个排在后面，等他处理完当前步骤之后继续执行。比如他正在做网页，你可以接着说，页面再简洁一些，按钮换成黑色，先不要做登录功能等等。 而如果你忽然发现他理解错了你的意思，或者做了一半有点跑偏了，可以直接选择引导，强行把方向盘掰回来。所以用 codex 的 时候不一定要追求第一条提示词写的特别完美，你可以边看他做边补 充，边纠正边引导。真正好用的方式是把他当成一个正在干活的助手，而不是一个只负责回答问题的聊天框。这个思维一定要转变过来。 最右侧的区域目前包括三个功能，侧边聊天就是当前任务的一个临时讨论区。因为有时候 codex 正在执行一个主任务，但你中途想问点小问题，或者单独讨论某 个细节，就可以用它，它不会打断主对话的节奏。浏览器主要是 codex 打开网页查资料测试页面，比如你做了一个网站，可以让他直接打开本地页面，帮你检查布局按钮、交互有没有问题。如果你对某个地方不满意，还可以让他直接打开本地页面，帮你检查布局按钮、交互有没有问题。如果你对某个地方不满意，还可以让他直接打哪的感觉， 口头描述半天要精准的多。终端的话呢，其实你不需要了解太多，因为它主要是给 codex 执行命令用的。到这里，其实你已经看到了 codex 最核心的几种能力，它可以进入项目，读取和修改本地文件，可以用计划模式先想清楚怎么做，可以通过浏览器查资料测试网页，也可以通过终端运行命令检查结果。 所以 codex 真正厉害的地方不是某一个单独按钮，而是它能把这些能力组合起来，帮你完成一个完整任务。理解了这一点，后面的 skill 插件和自动化任务就很好懂了。 因为前面这些能力呢，解决的是 codex 自己怎么干活的问题。但如果你想让他干的更稳定，更像一个熟悉你习惯的助手，就需要用到 skill。 如果你想让他连接更多外部工具，就要用到插件。 这里很多新手分不清 skill 和插件，其实用一句话就能记住， skill 是 方法，插件是工具。 skill 可以 理解成一套可以附用的工作流，或者说给 codex 的 一份工作方法说明书。比如一家公司做项目，通常都有一套标准流程，第一步做什么，第二步做什么，输出格式是什么，有哪些注意事项，哪些地方不能乱改。 这些东西如果每次都重新告诉 ai 一 遍就很麻烦，而且 ai 它还可能每次理解的不一样。所以更好的方式是把这套工作流程固定沉淀成一个 skill。 这样 codex 下次遇到同类任务时，就不用像一个新员工一样重新摸索，而是直接按照你写的流程和标准来做。 比如我自己的飞鸽工具箱里就有很多专属 skill。 比如把好用的软件保存入库到本地，同步到我正在做商单推广的几个云盘，生成下载链接，再同步到正式站，这些流程全都是固定的。 我把它们写成 skill 之后， codex 就 可以按这套流程稳定执行，不会每次都跑偏。再比如，你经常写短视频文案，也可以让 codex 帮你做一个短视频文案 skill， 把你之前写过的大量文案喂给他，让他总结你的开头风格、结构、习惯语言表达、结尾方式，然后形成一个专属文案助手 后，再写类似内容的时候， codex 就 会优先按照这套方法来。插件就不一样了，插件更像是给 codex 装上外部工具，解决的是它能不能操作某个平台，处理某种文件，连接某个服务。 比如浏览器插件，可以让 codex 打开网页查资料、测试页面表格插件可以让它处理 excel、 ppt 插件可以让它生成演示文稿。 gmail 插件可以让它整理游戏， camera 插件可以把生成的内容导入到设计工具里继续编辑，所以不要把他们想的太复杂。 skill 解决，怎么做插件解决用什么工具做？一个是工作流程，一个是工具能力。 codex 目前已经集成了很多实用的插件和 skill， 我 也整理了几个比较常用的，大家可以截图保存，后面自己试试看。 最后我们再来看一个比较进阶但非常有想象力的功能，自动化任务。你可以先理解成让 codex 在 固定的时间、固定的项目里自动帮你做一件事，但它和普通题型软件不一样，它们最多告诉你该干什么了。 而 codex 的 自动化任务是真的可以帮你执行一整套流程。比如你是做内容创作的，你可以让他定期帮你收集某个领域的热门选择题，整理成标题、角度、参考链接和可以拍摄的脚本。而飞哥最常用的就是每天固定时间设置一个今日任务清单，划掉昨天已经做完的，生成当天新的任务， 就像一个机器人一样按清单执行。这也是为啥有人说我效率那么高，一个人干八个人的事情。除了 ai 的 强大助力之外，任务规划本身也非常重要。所以自动化任务真正厉害的地方不是定时提醒，而是定时让 ai 按你的要求去干活。 最后再补充一个很多人会关心的问题， codex 能不能在手机上用？据我所知有三种方式，最早大家都是用 happy 这种开源项目，它可以连接 codex cloud code， 电脑上开个任务就能通过手机和 agent 的 沟通，但始终不太方便，相当于只是给你安排了一个传话筒。 而 codex 的 mac 版本最近更新了手机端的入口， chat gpt app 里面就有 codex 可以 完整读取你的聊天记录。在手机里聊天和电脑端的消息是完全同步的，本质上是远程链接，相当于把你的电脑版正在跑的 codex 搬到了手机里。而最近我发现了一种非常爽的方式，就是网易的优优远程， 出门的时候手机直接远程连电脑，操作起来很方便，最关键的是你能同时测试它的改动，这就相当于把你整个电脑都装进了手机，所以功能最完整。 好，最后我们来个回顾，总结一下你都学了什么。如果你是第一次接触 codex， 其实今天不用记住所有按钮，也不用一上来就研究特别复杂的自动化和插件，你只要先记住这条主线就够了。第一， codex 不是 普通聊天工具，它更像是一个能进入你电脑工作区的 ai 助手。第二，临时问问题，用普 对话，真正要处理文件、项目代码、文档就用项目。第三，复杂任务不要直接让它开干，先用计划模式让它列方案，如果是一个长期目标，再考虑用目标模式让它持续推进。第四， skill 是 方法，插件是工具。 skill 负责告诉 codex 怎么做事儿，插件负责让 codex 连接浏览器、表格、 ppt 邮箱这些外部工具。第五，自动化任务不是简单提醒，而是让 codex 在 固定时间按照你设定好的流程自动干活儿。 所以新手今天先做三件事就够了。第一，安装并登录 codex 桌面端。第二，建立你的第一个项目，找一个真实的小任务试一下，比如整理一个文件夹，总结几篇文案，或者生成一个简单网页。第三，让 codex 帮你写一份自己的 agents， 点 m d 就是 我们刚才提到的个性化。现在你让他自己干，把你的 称呼、语言、习惯、输出格式、工作偏好都写进去。当你把这三件事跑通之后，你就不只是会用一个 ai 工具了，而是开始拥有一个真正属于你自己的 ai 工作站。祝你越来越牛逼！

codex 是 我过去几个月高频使用的 ai 助手之一，我用它做研究，写文档、做 ppt， 整理内容灵感，做网页原型。上个视频讲了 codex 基础，这期视频讲一个今年很值得先搞懂的 ai 概念 skill， 因为它决定了 codex 到底只是陪你聊天，还是能按你的工作方式反复干活。简单理解一份可以重复使用的工作说明书， 你可以把某类任务的流程规则、检查标准提前写进去，下次再让 codex 做类似的事，他就不用每次重新听你解释一遍。比如你经常让 codex 做网页，你不想每次都重复说页面不要太 ai 味，不要蓝紫配色， 这些都可以写进一个设计类 skill 里。以后你只要让 codex 用这个 skill 检查页面，他就会按那套规则去看代码、改样式，再告诉你改了哪里。 这就是 skill 最实用的地方。把你反复说的要求变成一套固定流程，那么在哪里看和怎么用 skill， 可以 去 codex 的 侧边栏这个入口里看，里面会有一个 skill 子页面， 已经添加或创建过的 skill 会出现在这个列表里。使用的时候，通常可以在聊天里输入 skill 名称，或者用斜杠跳出来。比如你有一个 find skill， 就 可以直接斜杠选中，帮我找一个适合做 ppt 的 skill， codex 就 会按 skill 里的流程去跑。那怎么创建 skill？ 有 两种方法， 第一种最简单直接这样说，请创建一个 skill 以后，我给你一个网页项目时，你要先检查移动端排版按钮样式、文字层级、颜色是否太乱，最后输出修改文件和检查结果。这种叫 prompt skill， 但我更推荐第二种，先把流程跑通，再把流程固化成 skill。 举个我刚实测的例子，我想做一种白板手绘风讲解图，我先给他一个参考图，让 codex 按我的要求生成讲解图 第一版如果不满意我就继续改，比如少一点黄色纸张质感画面更像课堂白板。等到有一版我觉得可以附用，我再说。把它固化成一个 skill， 这时候 codex 会反推刚才的流程，它会把这次反复调整出来的规则写进一个 skill。 md， 这样下次我再用白板手绘讲解图， 就不用重新解释一遍审美和结构，直接调用这个 skill 就 行。如果你想让 codex 使用 skill creator， 它会按更标准的格式帮你生成可附用 skill。 我是 ai 知识派，我们下期见。

很多人用 codex 第一步就错了，前两天我发了一条用 codex 做标书的视频评论区，最让我意外的不是大家不会用，而是很多人还在研究怎么去接这个中转站，怎么去用这个便宜的模型啊。我的观点很简单，就是 你用 ai 去做正经的任务，最不该省的就是模型钱，因为真正贵的它不是调用的，这个费用是返工的成本。 好的模型，你十次里面可能错一次，你检查一下，修复一下就 ok 了。但是你差一点的模型，你十次里面可能会错三次，甚至错五次，每错一次，你都要重新去判断这个逻辑对不对啊？结果能不能交付啊？后面还有没有坑 对吧？就是这里可以看一下啊科特官方的这个 benchmark 的 图，它不是为了证明某个模型永远是第一，而是说明了一件事情，就是在真实的编码的这个场景下，就长模型之间的差距都很明显了，更别说你用这个便宜的模型去代替。 所以如果你只是玩一玩的话，用什么都可以。但是如果你要写方案，要要写代码，去做商业的分析，甚至是你呃，要任何交付给这个别人的东西，你都要用， 就是你直接能用最好的模型就用最好的模型啊。再说 codex 跟 cloud code， 如果你是中文用户，尤其是在国内使用的这个环境下，我会更加偏向 codex， 因为 astropica 它对这个中国的用户限制更加的多，然后它的表述也不是很友好。 而 codex 在 我的使用体验里面的话，它不管是成本啊，能力啊，还是这个中文场景的平衡，它要做的更好一些。就如果说只是国内的 ai， 那 我推荐豆包，而如果是复杂的任务，我还是推荐 codex。 就是 最后一句话， ai 工具它不是说谁单次调用更便宜，它就它就是更便宜的，而是能够让你去少返工，更少的犯错，稳定的能够去交付，所以才是真正的便宜。

他在不停的修正错误啊，因为给他权限挺高的，他是完全允许访问的， 你看他就像个程序员，他会给你写个文字，装好鸡蛋啊，到时候看效果。嗯，看一下，这次消耗了五百九十个头坑，他要给你深吐啊。他说预览你生成的， 嗯，他说我看纯纯的 cd 是 怎样，他现在用我的默认的 cd 打开，因为我双手在拍摄视频，我没有动手，背对着头，来来来，开始跳，你看这性质变成新的文件了，新这个文件呢？看这新键 啊。好，终于结束了，看一下结果。阿迪叉 f 其实是已经升成这个零分零五了文件，但是我打不开，我要求把它换成 dwg 格式，然后它现在在运行， 自动在电脑上运行安装软件，直接给你转换成二零一零版的 cd 啊，大家看一下，来告诉你二零一零版，二零一八版它是复制出来的，给你改的，所以说你就有两份文件并存，开始好了，它生成了 他，这他这样生成好了，可以了，你看他刷好了，我们说放下看一下。哇塞，他是帮你填充全部填充好的，然后我们看一下，我们直接给他截图啊，对比一下 效果。可以啊，一模一样，然后我的文字这是没有乱码，我们这一样的尺寸。

我用了 superpowers 一 段时间之后，最大的感受它不是让 cortex 更快写代码，恰恰相反，它是在让 cortex 不要太快写代码。因为现在 ai coding 里一个常见的问题是，需求还没有澄清，边界还没有确认， 测试还没有想好， cortex 已经开始改文件了。小任务这样做还行，但一旦任务变复杂，这种直接开写的方式很容易出问题。所以这一期我们聊聊 superpowers 到底解决了什么问题。 先简单说一下 superpowers 是 什么，它不是一个单独的 skill， 而是一套给 coding agent 使用的软件开发方法论。在 codex 里面安装很简单，如果 是 codex c r i， 打开 plug ins， 搜索 superpowers， 选择安装就可以了。如果是桌面版的 app， 在 侧边栏 plug ins 或者是那个插件里面找到 superpowers， 点加号安装就可以了。 插件我找到 superpowers 点安装就可以了，因为我已经装过了，所以这边不是加号了。装好之后，它就会作为一组 skills 在 cortex 里面使用。这也是我觉得它很适合 cortex 的 地方。它不是让你每次手动复制一堆 prompt， 而是把一套软件工程流程变成 cortex 可以 按需使用的 skills。 我 理解 superpowers 的 核心就是把 ai coding 拆成 七个顺序执行的步骤。第一步就是头脑风暴，在写代码之前先澄清需求，探索方案，确认边界。第二步就是创建独立工作区，不要直接在当前工作区里乱改， 而是创造一个更安全的独立开发环境。第三步是写实施计划，把任务拆成小步骤，明确要改哪些文件，怎么实现，怎么验证。第四步是指代理开发， 把具体任务交给 subdivision 去执行，让主流程可以更清楚的组织和检查。第五步是 tdd 测试，驱动开发，先考虑怎么证明它是对的，再写实现，而不是先写一堆代码再说。第六步是代码审查，改完不是马上说完成，而是让另一个审查视角检查问题。 第七步是完成分支，最后做验证，收尾、合并或保留分支。所以它的流程不是需求到写代码，而是这一套头脑风暴，到独立工作区域，到实施计划，到代理开发，到 t d d， 到代码审查，再到完成分支，每一步都是一个独立的 skill。 这就是 superpowers 最核心的地方，它把软件工程流程拆成了 ai 可以 执行的一组 skills。 我在 codex 里用下来，感觉它是比较无缝的，尤其是装成插件之后，它不像一个你每次都需要手动调用的命令集合， 更像是给 codex 加了一套开发习惯。比如需求不清楚的时候， codex 会先倾向进头脑风暴，先问问题，探讨边界，确认需求，而不是直接开始改代码。准备实现之前，它会更容易进 writing plans， 设计代码质量时，它会提醒 pdd review 和验证。这就是我觉得就 pos 很 有价值的地方，不是每次靠你提醒 cortex 守流程，而是让 cortex 默认更容易按照工程流程工作。这里也放一个 sdd 的 背景在里面， s d d， 也就是 spec driven development。 规范驱动开发，它的核心思想是不要一上来就写代码，而是先把要做什么说清楚，比如 open spec， 它更偏规范管理，它关注的是把需求变更约定整理成可维护的规范。 spec kit 更偏规范驱动开发流程，它通常会通过一组命令模板，引导 ai 从 需求深层规范计划任务再去实现。而 superpowers 更偏工程纪律和 skills 集合。所以我会这样理解， s d d 解决的是先要把做什么想清楚， superpowers 解决的是做的过程中怎么守流程。最后说一个大家可能关心的问题， token 消耗，而我自己用下来。 superpowers 在 cortex 里的题感是比较轻的，因为它不是每次 都把一大堆规范文档塞进上下文，而是通过一个个 skill 在 需要的时候触发对应流程。当然，它也会消耗 token 头脑风暴，它要讨论需求， writing plans 要写生成计划 review 要读取代码和分析问题， 都不是免费的，但它的消耗更像是按阶段按 skill 触发。而 openstack 和 stackkit 这类的 sdd 工具通常会生成更多的规范计划任务文档，好处呢是结构更完整，坏处是文档越多，后续带入上下文的 token 压力也可能更大。我 之前看到 speckey 的 社区里面有人反馈过类似的问题，有依据里估算，在 cloud code 里，一组 speckey 个 months 可能占用大约十八点六 k 的 tokens， 在 codex c i 的 上下文窗口里面大概占百分之七到百分之十。这个不是官方的 benchmark， 但它说明一件事，流程工具本身也有上下文成本。所以我的判断是， opens back backit 更适合强规范、强文档、强交付约束的任务。 superpowers 更适合日常 ai coding， 因为它更像一层工程流程约束 动成本更低，体感也更自然。所以这一期的结论是， superpowers 不是 给 ai 加超能力，而是给 ai 加工程纪律。它解决的不是 ai 不 会写代码，而是 ai 太容易跳过软件工程流程模型提供能力， superpowers 提供纪律。 下来几期我们会继续拆开看。为什么先要头脑风暴？为什么要写 plans？ 为什么 ai 写代码需要 pdd？ 以及为什么 ai 也需要 code review？ 下一期我们继续。

剪映真的要被干掉了吗？就是刚刚测试了一下 codex 剪辑视频的水平，虽然我只是做刚才做了一个简单的视频剪辑，做的还行，但是怎么说呢？他未来如果变得越来越强的话，那基本上就不用剪映了，因为我要用这个进行批量生成视频， 刚做了一个测试一下，那么其实他的方法也是很多，做很多复杂的任务，比如说 ai 自动剪辑，根据这种分镜生成，根据文案生成分镜，然后提取高光，什么都可以，应该也可以做一些复杂的。不过我这个视频比较简单， 我只用了音频和视频拼接，然后我就跟他说这个在哪个文件夹里面，然后他自己去拿就可以了。但是他这个模仿声音没给我做好，就是我要固定一个音色，然后用素材和语音拼接成一个视频，直接发给我就可以了。然后他最后呢，他做了， 他就做了，做了一个他自己带这个就这样的，就是把这个，就是把这个素材都放在这里面，然后他生成好的话，他就可以直接发给我，然后这个输出样片他就放在这个里面了。然后这是他做的视频，他这个他这个，嗯，他这个视频生成的就是他的识别字幕的错别字，是比剪辑要多一些的， 不过也还可以了，批量批量做的话问题不大，可以再加入一些操作，让他变得更加的复杂。或者你找个参考视频，让他参考一下，然后做成一个差不多的啊，那会比较更更厉害。就是其实都不需要去用别人的插件，你就用 codex 把一个视频放进去，然后让他给你剪一个差不多的， 然后你把他给他素材，或者让他自己生成素材，就是生成好素材，在这个准备好素材以后，然后让他自己剪辑。哇，以后真的去人工化了，他现在干的还不错。

大家好，我是郑一环，今天我们看一下扣代词自动化任务，扣代词可以把重复工作封装成自动化任务，并且定时自动执行。 比如我每天早上都需要看 ai 热门资讯，用来做自媒体选择题，这件事每天都要做，并且流程完全一样，很适合做成自动化。具体步骤就是我先跟扣代词说， 帮我搜索今天全网关于 ai 方面最热门的资讯，挑选十条发给他。内容生成以后，我们先确认一下内容有没有问题， 没有问题的话我们再给 codex 下新的指令，就是把搜索当日最热门的十条 ai 资讯做成自动化任务，每天早上九点执行，然后发给他。 我们可以看到 codex 已经创建好了任务，后续的话我们可以在左上角的自动化这里查看和管理我们的自动化任务，可以修改自动化任务的内容，也能修改执行时间等等。

推荐所有刚刚 codex 的 朋友啊，都去跑下这个任务，告诉 codex 你 是谁，你的工作是什么？职业是什么？你在工作当中有哪些非常烦的点？有哪些重复性的工作？你最不舒坦的流程是哪些？最后让 codex 帮你梳理一份它可以帮助你去完成的十项任务清单。 跑完这个任务了之后，你会非常清楚 codex 究竟能帮你在工作当中完成哪些事情和任务，推荐你去跑它。

这条视频讲 codex a subagent， 小 白也能听懂的版本。它不是一个新软件，也不是神秘功能，而是 codex 处理复杂任务的一种用法， 你会看到它什么时候该用，什么时候别用，以及怎么用它。 review 一个真实项目，先给 subagent 下一个最朴素的定义。一个复杂任务，你可以让 codex 拆成几块，分别交给几个子代理并行处理。 每个子代理跑在自己的 agent thread 里，最后只把结论交回主线成汇总。官方术语听起来会正式一点。 sub agent workflow 指同时跑多个并行代理在汇总。 sub agent 是 被派出去做某件事的代理， agent， thread 则是每个代理自己的线程，你可以在 cli 里查看和切换。 sub agent 主要解决两件事，第一， context 被污染，读文件跑命令看报错，猜原因，全塞进主线城，后面判断就容易乱。 第二，该病型的事被串行，做安全测试风格可维护性本来可以同时看，却被一个代理从头查到尾。判断要不要开 sub agent。 可以 先问一个问题，任务能不能拆成几块？互不依赖的小事， 能拆就适合试，拆不开就别硬上。任务很小，子任务紧咬在一起，写入范围重叠，或者你自己都还没想清楚怎么拆，这些情况开了反而添乱。不适合的情况也要记住，任务本身很小，没必要开多个代理。 几个子任务互相咬的很紧，并行也不省时间。最危险的是多个代理同时改同一篇文件，这时候省下来的时间很可能被冲突和反攻吃掉。 真正适合练手的场景大多是 rate heavy， 比如大型代码库探索 pr， 多维 review 几个 bug 方向， b 型排查，长文档和长日制分块分析。官方也建议新手起步时先选探索测试、 treeash 和总结这类任务。 codex 默认不会主动开 sub agent， 你 要在 prompt 里讲清楚。常见说法包括 spawn two agents， delegate this work in parallel use one agent per point。 中文直接说启动三个 sub agent， 分 别检查安全测试和可维护性也可以。如果拿来 review pr， 可以 直接用这个模板，一个 sub agent 检查潜在 bug， 一个检查测试覆盖，一个检查代码质量和可维护性， 最后要求主线程等三个都完成后再输出高风险、中风险可选优化，以及建议优先修什么。 这个模板真正值钱的不是文字本身，而是里面的控制点。每个子代理的职责不重叠，避免大家都泛泛 review 一 遍，明确等全部完成再汇总，可以避免主代理拿着半成品就下结论。最后加一句，优先修什么，可以把排序工作也交给主县城。 接下来用 ship ready 这个小项目做例子，它是一个 s s landing page audit 的 mvp， 后端 api 在 s r c app 点 js， 审计规则和 rewrite 在 s r c audit 点 js， 存储是 s r c store 点 js， 前端是 publ i c 斜杠 app 点 js。 代码量不大，正好适合演示怎么稳妥的开 sub agent。 在这个项目里，最稳的开法不是让三个 agent 一 起改代码，而是启动三个 read only sub agent runtime risk agent 看运行风险 q a coverage agent 看测试缺口， architecture agent 看模块边界， 所有子弹里都不要改文件，等全部完成后，主线程再决定要不要修。三个结论里， round time risk agent 最有价值。他发现 handle request 里 in sync 路由没有 await， 外层 try catch 接不住 a sync handler 抛出的错。 这种 bug 在 happy pass 测试里不容易暴露，但线上可能表现成请求挂住或者 unhandle rejection qa coverage agent 的 结论也很实用。 他没有泛泛说测试不够，而是列出 invalid json 未付费 share 过早 follow up。 若 brief 绕过 rewrite 这些副路径， 这些用力不一定都要立刻补，但摆在面前，主县城就能快速挑出最该锁住的状态流。 architecture agent 的 结论最容易让人冲动， 他说 src app 点 js 可以 拆成 page extract checks brief 和 rewrite 几块 判断没错，但这次目标是写测试加修 bug， 不是 重构 auditing， 所以 这部分建议最后先记下来，不立刻动。三个 sub agent 的 优先级其实不一样， round time risks 想让你先修服务端 qa coverage 想让你先补测试， architecture 想让你先理边界。主县城不能给三票打平均分，而是要挑确定性高、改动小、能被测试所注的事情先做，最后真正落地的改动其实很克制， 异步路由统一加 await， 让外层错误处理生效。 rewrite 必须 brief ready 才能解锁， follow up 增加还没提交 brief 和非法字段校验。 read json 加 body size 限制 invalid json 返回四百，最后补 note test 回归测试。 这个案例最有意思的一课是两个代理的结论拼在了一起， round time risk agent 告诉你哪里坏了。 q a coverage agent 告诉你怎么用副路径测试把它锁住， 这就是 sub agent 真正的价值，不是替主线城做决定，而是把几个方向的结论同时端上桌。跑起来之后也要会管理 agent thread codex c l i 里可以用 slash agent 查看和切换线程，如果某个子任务偏离方向，可以让 codex 停掉那个负责性能分析的 sub agent 跑完的线程，也可以让它关闭已经完成的 agent threads。 给新手的练手顺序，不建议一上来就五个 agent 一 起改权。项目先并行阅读，让多个 sub agent 各自理解不同模块，再并行 review， 把 bug 安全测试，可维护性分头看。 第三步是单写，多审一个代理或主线成改代码，其他子代理做 review， 最后才是小范围并行修改。 下一次让 codex review pr， 你 可以直接从这个短 prompt 开始。请使用三个 sub agent 并行检查，当前 pr， 一个看 bug， 一个，看测试一个看可维护性， 等全部完成后，按风险等级汇总给我。就这几句话，已经够你完成第一次 sub agent 练习。 最后记住， sub agent 不是 替主线城做决定，他真正干的活是把几个方向的判断同时端到桌面上，让主线城更快做取舍。新手先从 rate heavy 的 探索和 review 开始，等你能清楚拆分任务，再尝试让多个代理并行改代码。

codex 是 openai 推出的 ai 编程伙伴，可以帮助我们开发功能、修复 bug、 重构代码、做代码审核等。 openai 官方也提到， codex 可以 处理从功能开发到代码 review， 发布相关的工程任务。 但对孩子说，我们不用一上来就讲那么复杂，我们可以把它想象成一个把想法变成作品的 ai 助手。比如说我想做一个数学错题的讲解器，我不会直接说 帮我写代码，这样太空了，我会说，请帮我做一个适合三年级小学生使用的数学错题讲解网页功能包括，学生可以输入一道数学错题 e i 页面，提示学生先分析题目条件， 在引导学生写出题解之后，再举一反三。应用风格要可爱清楚，适合孩子，这就叫任务拆解。这我也给大家进行干货总结。给 codex 写提示词有一个万能的公式，角色加目标加用户，加功能，加风格加输出形 式。比如说角色是，你是一个 ai 编程助手，目标是帮我做一个教学错题分布讲解， 生成类似体，风格是卡通，也要简洁，适合孩子。初初就是做成网页。在 ai 时代，孩子真正要学的不是复制答案，而是把自己的想法讲清楚，因为你讲的越清楚， ai 做出来的作品就越接近你想要的样子。

今天是一条适合小白的保姆级 codex 教程，如果你之前只用过聊天式的 ai， 可以 先把 codex 理解成能帮你执行任务的 ai 助手，它不只是回答问题，还可以在你授权的范围内帮你处理文件、生成内容、运行工具、预览结果。 那这期呢，我会从基础使用、真实案例、高级功能等三个方面给大家拆解。 codex 里面会包含三个案例，也会讲到一些插件和特色功能的使用。 那第一次打开 codex 的 时候，你按照界面的提示登录账号就可以了。登录完成之后呢，你会进入 codex 的 主界面，新手先不用纠结各种设置，因为这些后续都可以再改，我们可以先把界面看明白。 那我们现在已经进到 codex 这个页面呢，你只需要理解三块区域就够了。左边是项目和任务列表，你可以在这里切换项目，查看历史对话，也能看到有哪些任务正在跑。 中间呢是聊天和任务输入区，你要做什么就直接用自然语言告诉他，和之前咱们用的 ai 对 话型产品其实是一样的。 那右边呢，是执行过程和结果区， codex 改了哪些文件，跑了什么命令，生成了什么样的结果，网页预览长什么样子，通常都会在这里展示。然后呢，我们来讲几个新手比较容易混的名词。第一个是项目， 那项目就是你给 codex 选中的本地文件夹，你选了哪个文件夹，它就能够围绕这个文件夹读文件、改文件，生成内容。项目呢，也有两种使用方式，一种呢是根据任务类型创建一个项目文件夹， 以后同类的任务可以都放在这个项目里，比如说我自己每天都要做的 ai 新闻板块，我给他建了一个独立的文件夹，叫 daily ai news。 另外一种呢是打开现有的文件夹，那 codex 就 可以处理这个文件夹内的文件了。 第二个需要理解的名词是上下文，上下文可以理解成 codex 当前知道的信息，比如你跟他说过的一些需求，他已经看过的文件，当前任务进行到哪一步，都会影响他接下来该怎么去做。 第三个是模型智能程度和速度，普通任务直接用默认的中度就可以了，比如整理文件，写文案，改一点简单的内容，不用上来就拉满 那复杂任务，比如要跨很多文件，规划项目，排查问题，你可以再把智能程度调高，然后模型这里可以切换不同的 gpt 模型，速度这里直接用默认就可以了。 最后呢是权限，这个非常非常重要，默认权限就是 codex 主要围绕当前的项目文件加工作，遇到联网安装工具，访问项目外的文件的时候，一般都会先来问你。那自动审查呢？是我比较推荐新手日常使用的， 它会根据操作风险来做判断，低风险的时候自动操作，敏感操作的时候就需要你人工审核了。 那最后这个呢，顾名思义就是给 codex 所有的权限，这个只建议你非常明确的任务，也信任当前操作的时候再用好。以上呢，就是一些 codex 的 基础使用内容。

codex 帮我重构了一个多小时，我手电关错窗口，四十多个文件的进度啪一下全没了。那次之后我不敢再裸跑长任务，不是模型不行，是 codex 默认根本没有进度这个概念，而每一轮都活在当下， 窗口一关，记忆为零。我现在跑长任务只靠一个机制，在 ajax 点 md 里写死一段规则，让 codex 每走一步就把状态落到一个叫 progress 点 md 的 文件里。这一段规则就三条，你直接抄。第一条，每完成一个子任务更新 progress 点 md， 里面就三行，已完成进行中。下一步不是写心得，是写状态。比如已完成拆出 os 模块的五个函数， 进行中再重写 login handler。 下一步跑 past tests 斜线 os。 第二条，每条状态后面必须挂一个可跑的命令，不是基本完成这种废话是 past test 斜线 os 通过 npm test 还剩两个失败。 没有命令等于没有证据，你重启之后就接不上。第三条，重启会话，第一句话不要说，继续说，继续，它会自己脑补，越脑补越离谱。 正确的开场白是读 progress 点 md， 从进行中接着干，不要重做已完成。就这一句。 这套规则最关键的地方在哪？ agents 点 md 是 codex 每次绘画都会自动读的文件，你写一次，他每次都记得你不用每次开任务都重新交代规则。我自己加了这段之后，上周跑了一个四十分钟的批量改动， 中间 vpn 断了一次，我重开绘画，发了那一句开场白，他接着第七个文件继续改，没重做一次长任务保命不是靠模型更强，也不是靠你不关窗口， 是靠你把状态落到文件规则写进 agent， 点 md 评论区打 checkpoint。 我 把这段 agent 点 md 规则原文加 progress， 点 md 模板一起发你。

大家好，今天分享一下 codex 命令，学会四十二个命令，完全可以改变你使用 codex 的 方式，从模型切换、绘画管理、代码审查。今天这期视频我会逐一讲解每个命令，告诉你它们是什么，什么时候用，怎么用。 如果你还在低效的使用 codex， 看完这期视频会让你的工作效率翻倍。模型与配置相关命令第一个，使用 model 快 速切换当前绘画的模型， 确认后就会弹出可选模型列表，选择后，后续对话和代码操作都会使用新的模型。它适合在不同任务间切换，比如日常改代码，用速度更快的模型，复杂架构分析、疑难 bug 排查时切换到推理能力更强的模型。第二个， 如果你想让它响应更快，可以输入 fast， 速度是一点五倍。这个命令会把当前绘画切换到更偏速度优先的工作模式， 适合处理简单修改，查文件、跑命令，解释这类代码低风险任务。它的重点是减少等待时间，让 codex 更快地出结果。适合快问快改，不适合重度分析。再次，使用 fast 的 命令可以切换标准速度。第三个可以使用 personality 调整它的沟通风格， 主要有两种， friendly 和 pragmatic。 第一个更像一个耐心的合作伙伴，语气更轻松，会解释多一点过程，适合学习、探讨和头脑风暴。第二个更像资深工程师，表达更直接，重点放在结论、风险和下一步。 适合修改 bug， 改代码，做工程决策。 personality 不 会改变模型能力、权限或者项目文件，只是改变 codex 和你的沟通方式。 第四个 experiment 是 一个实验性开关，这些开关会保存到 config 二 m l 文件里面，影响之后的使用体验。比如 terminal resize 会在终端宽度变化时重排 codex 的 聊天记录。 memories 允许 codex 从对话中建立记忆，并在新绘画里带入相关记忆。 prevent sleep while running 则是在现程运行时防止电脑休眠。实验性功能适合愿意尝鲜的人，稳定性可能会发生变化。权限与安全相关命令 第一个 permission 用来设置当前绘画的操作权限，打开后你会看到三个选项， default、 auto view for access。 defort 是 常用的安全模式， codex 可以 读取和修改当前 workspace 里面的文件，也可以运行命令。 但如果需要访问互联网或者修改当前项目之外的文件，就必须向你审批。日常写代码，修 bug 跑测试用这个模式就足够了。 auto view 和 default 基础权限一致，也是 workspace 可写，它会限制互联网和外部文件访问。区别在于符合条件的审批请求优先交给 auto view 子代理判断。一些需要 on request 的 操作不一定直接弹给你， 而是先经过自动审查。它适合希望减少手动确认，但又不想直接放开全部权限的场景。 for access 是 最高权限， codex 可以 修改 workspacey 的 文件，也可以不经过你的确认访问互联网。这个模式效率最高，但风险也最大，因为它可以直接影响你的系统环境、用户目录 下载或执行外部内容。只有你明确知道任务需要这些权限，并且信任当前操作时再开启。第二个 approve 是 处理自动审查拒绝的动作，所以没有什么可批准的 绘画管理相关命令。第一个 new， new 相当于是开启一个新的绘画，它不会退出 codex， 也不会换你的项目目录，只是把当前的上下文清空，重新开始一个新的任务。比如刚才让 codex 改完一个 bug。 接下来想问一个完全不相关的问题，可以用 new， 这样上一段任务里的讨论文件决策就不会干扰新的任务。我们可以通过这个 space 命令来查看一下当前绘画。 当前绘画 id 二八零使用 new 命令，我们来再创建一个新的绘画。我们通过 states 来看一下绘画 id 跟当前的绘画 id 是 不是不一样。我们看到是八二一，这就是 new 命令。 第二个是 resume， 恢复历史绘画，并继续使用当时的上下文。如果你昨天让 codex 分 析过一个项目，今天接着干，就不需要把背景重新给 codex 讲一遍。通过当前这个命令，从历史绘画中 选择一条 codex， 就 可以沿着之前的上下文继续往下做，就相当于切换到上一次绘画中。第三个命令 fork。 fork 就是 把当前绘画复制出一份新的分支，保留所有上下文，后续修改互不影响。 它适合你想尝试另一种方案，但又不想破坏当前这个对话的时候用。比如当前的方案用的是 rack 实现。你突然想试试路由一，这个时候 fork 出一个新的绘画，原来的对话还是存在，新的绘画就可以大胆地尝试。第四个 side， side 是 开启一个 临时的旁路对话，它适合处理一些小问题，但不想打断主任务。比如 codex 正在帮我们改代码， 你想顺手问一句刚才这个报错是什么意思，我们就可以通过这个 set 命令问完之后，我们再切回主绘画，主绘画不会被这个临时打断打扰。第五个 rename。 rename 是 用来给当前绘画改名字。当前历史绘画越来越多，默认标题可能不够清楚，我们就可以通过 rename 命令 来把它修改一个名字。以后我们通过 resume 就 可以找回来是哪一个绘画。例如我们通过 space 命令来查看当前绘画， 我们可以通过 state 命令查看当前绘画的名字。当前绘画的名字，比如说是这个设置一个名字，我们通过 rename 命令可以来修改。给它改一个名字，我们再次通过 state 命令可以查看一下，它的名字就发生了变化。第六个 agent， 它是用来切换当前活跃的 agent。 如果你开启了子代理， 比如第一个 agent 是 负责读代码，另外一个 agent 负责跑测试，还有一个 agent 负责 code review， 那 我们通过这个 agent 的 命令就可以在这一些 agent 之间进行切换，查看它们各自任务的进展，或者继续跟一个 agent 对 话。当前我这里只有一个 agent。 第七个 sub agents， 这个命令是子代理入口相关的命令，你可以把它理解成，当一个任务比较复杂时， excel 不 一定只靠主 agent 来做，可以把一部分工作拆分给子代理来做，比如子代理专门做分析代码结构，还有一个子代理可以做测试风险，主代理最后做一个任务汇总，这种特别适合大型项目分析，因为这里没有创建子 agent。 最后一个 go， 这是给当前任务设置一个持续目标，它不像我们普通的一问一答，但 go 更像适合告 codex， 你 接下来围绕一个目标工作，直到它完成为止。比如说 token 消耗了， token 用完了， 或者任务执行完了，是一个长期目标。比如你可以设置把这个项目跑起来，修复启动中相关的错误，并确保测试通过。我们通过这个 go 命令，这样 codex 它就会持续地围绕我们这个目标来完成。 中间我们也可以自己检查进度。如果这个任务执行的时间太长了，我们也可以暂停，继续调整目标都是可以的。现在我们用一个真实的案例来把刚才讲的绘画相关的命令我们来串一下。假设我有一个需求是让 codex 帮我创建一个个人博课 技术站，用的是 v u e， 并且不止让一个 agent 从头写到尾，而是启动三个子代理来完成写作。一个负责写代码，一个负责测试，一个负责 code roo。 第一步，我们通过一个 new 命令，这是因为是一个全新的项目任务，我希望它是一个干净的上下文，不要被前面的掩饰 内容所影响。第二步，我们用 rename 命令来给当前绘画改一个名字，例如我叫 u e。 个人博课，我们可以通过 permissions 来确保当前项目的权限模式，我这里选择 auto view。 接下来，我们通过 go 命令给 codex 设置一个持续的目标。我们看一下提示词我们的目标，然后里面有一个启动三个子代理来完成一个 code review， 一个 code write， 一个 test runner， 还有一个 code review， 我 们复制提示词， 使用 go 命令，我们一起来看一下，然后发送。 我们看到它的要求是启动了三个子代理， 我们再来看一下，刚才我们有一个 agent 命令，我们刚才启动了代理，我们看一下有没有 agent， 这是我们默认的主代理。我们看到我们要求的一个 code write， 它已经给我创建好了，我们可以切换到子代理上面， 子代理已经在开始工作了，这个时间比较长，我们稍等一下，刚才不小心打断了，我们再来结合一个命令 fast， 我们把它速度切换到一点五倍速度，消耗两倍 token， 让它继续写代码。我们可以看到我们刚才起用的是子代理来写代码，现在我们的主 agent 在稍等，待我们这个紫 agent 完成任务。我这里整理了一份命令文档，如果大家需要，大家可以三连，然后我给大家发文档。我们接着刚才的演示，我们来看一下，他已经把刚才我定义的这些 agent 都创建出来了，自己跑了一个浏览器在这里做测试。这个紫代理 review 他发现了一些问题，然后他现在在给我们做一个修改好，我们看到他已经把我们的这个目标给完成了，我们一起来看一下效果，这就是他刚才写的一个简单的页面代码与工作区相关命令。 接下来这几个命令更像是 codex 做项目时的辅助工具。第一个是应逆时命令，它是创建一个 agent 点 md 文件，我们可以把它理解成给 codex 写一份项目说明书，我们来执行一下 当前的这个目录，还是我们昨天做的一个个人簿刻这个页面，我们通过 uscode 的 辅助插件，我们可以看到他昨天写的代码，在这个区域，我们看到他正在给我们写这个 ajax 点 md 文件，我们看到他已经给我们写完了 ajax 点 md 文件，我们一起来看一下。 都是英文的，我们可以把它改变成中文， 我们直接通过 ide 来查看比较方便。我们看一下它有项目结构和模块组织，然后构建测试和本地开发的一些规范，怎么测试，还有 pr 规范， 还有 agent 的 专用说明，它都已经给我写好了。这个 agent 点 m d 文件相当于是给 codex 写了一份我们当前项目的一个说明书， 这样以后 codex 进入这个项目都会优先参考我们这个 agent dmd 文件里面的规范，不需要反复解释项目约定。第二个命令是 plan， 在 真正开始写代码之前，我们可以输入 plan 切换成 plan 模式，它的作用是 先拆任务，不着急写代码。比如我要创建一个个人博克，它会先规划项目的结构，需要哪些页面，文章的数据怎么放， 会先做规划，规划完成以后它才开始写代码。这个命令适合在复杂任务面前，我们可以通过快捷键 shift 加 table 来关闭这个 plan mode， 也可以通过快捷键 shift 加 table 快 速开启 plan mode。 我 们来演示一下这个 plan 命令。我们通过斜杠 plan， 现在大家可以看到它不是直接写代码，而是它向我提出的一些问题，你希望关于我页面主要强化哪些？感觉 我们可以自己选，它不是直接的写代码，也就是说我们通过 plan 命令把我们提示词中的任务进行拆解确认以后，它才会开始给我们写代码。第三个命令 mention， mention 是 用来把指定文件或目录带入当前绘画。比如我想让它重点来查看一个文件， 我们就可以通过这个 mention 来选择这个文件。比如说 index 点 s t m r， 它就会重点地去查看这一个文件。这样做的好处是我们不用在提示词里面手动去复制一堆代码，也不需要它去查找对应的代码。这个比较适合当前页面，有一些 bug 我 们自己知道， 我们可以指定它来这个文件中查找。我们通过 man 审核这个命令，指定到对应的文件给它的提示词，查看一下当前页面的代码。 他收到这个指令后，他只会去查看当前这个类的代码。我按照你点名的这个要求来查看这个。第四个是 skills， 是 选择和使用本地技能的入口。比如我现在做的是一个前端项目，如果我本地有前端相关的 skill， 我 们可以通过 skills 让 codex 使用它，我们一起来执行一下它有两个，第一个列出当前的 skill， 第二个，开启和关闭 skill 我们确定。例如我这里安装了浏览器的 chrome 的， 还有 computer user fig 码之类的，我们就可以使用这个 skill 来做一些事情。我们可以看一下我这里用了这个 documents， 让他帮我写一个项目文档。 skills 是 给 context 加一套更专业的工作方法和技能。第五个 default， 当 context 写完代码以后， 我们可以输入 default 命令， default 会展示当前工作区发生了哪些改动，比如新增了哪一些文件，修改了哪一些文件。这一步非常重要，因为在真正运行或者提交之前，我们应该先看一眼它做了哪些改变。我们通过一个案例来演示一下这个 default 命令，给他一条指令， 我让他把关于我页面这关于我这三个字改成红色，他已经修改完了，我们看一下，我们看到他已经是红色的了。我们再来试一下刚才的 default 命令， 我们可以看到他改动的文件，这就是 default 命令，就是会展示工作区发生了哪一些改动。第六个是 review 命令， review 是 让 codex 对 当前工作区做一次代码审查，我们一起来看一下， 我们通过 luul， 然后它有四个选项，第一个这个 pr 审查，也就是会把当前分支和某一个 base 分 支做一个对比。第二个就是审查当前还没有提交的本地改动， codex 刚改完代码以后，最常用的是这个。 第三个是针对某一次 commit 做一个审查。第四个是自定义审查，我们选择第三个，我这里有两个提交。我们看到这个 code luul 已经结束了， 这个初设版本是一个 v u e 项目，可以成功构建路由页面和数据流也是一致的，我没有发现值得代码审查里面需要提出来的明确问题，这就演示了我们这一个 rule 命令。我们把代码工作区的这六个命令串一下， 我们先用 easy 命令建立项目规则，再通过 skill 命令选择自己的这一个技能。我们要开发的时候，我们可以通过 plan 命令先做一个规划， 把任务做一个拆解。我们可以通过 minsh 命令来对指定的类进行一个修改。写完代码以后，我们可以通过 default 命令查看改动。最后我们可以通过 review 命令来做一个代码审查使用，这就是我们代码和工作区六个命令正常使用的一个顺序。 上下文，记忆相关命令这里主要有三个命令，主要解决的是上下文问题，也就是 codex 怎么知道我们在看什么，以及当前绘画太长的时候怎么保持清晰。第一个 id 一 命令，它主要解决的是把 id 一 里面的上下文带给我们。 codex， 我 们通过 id 一 命令，它这里提示 id 一 contacts is on， 说明我们这个 id 一， 我们选中这个字段， 问他这是什么意思，我们可以看到他直接读取到我们 i d e 里面这个字断了，我这里刚才选中的，他解释了这是什么意思。这样相当于是把我们 i d e 里面相关的代码的上下文，我们可以直接带到这个 c r i 中， 它是把我们这一些代码编辑器里面的上下文带到我们当前的终端里面来，可以解决我们不想手动复制粘贴的问题，也特别适合来做一些局部 bug 的 调整。第二个命令 compact 压缩，它是用来压缩当前对话的上下文。当一个任务跑得很久以后，整个记录 上下文会比较长，模型需要处理的信息也会变得更多，重点可能不够集中，有可能这个时候就会产生一些幻觉。这个时候我们就可以通过这个 compact 的 命令把当前可见的对话 总结压缩成一个更精版的，保留更关键的决定。我们这里可以看到已经使用了百分之二十三，我们来试一下这个命令，我们看到压缩还是比较厉害的， 当前上下文占用减少了，所以 compact 的 命令适合是长任务中途，比如项目做到一半，我们感觉到上下文很长了， 我们又不想重新开一个绘画，我们就可以先压缩一下。第三个 memory， 它是用来管理记忆相关的功能， 我们先执行一下。第一个是以后开了新绘画 codex 是 否读取已有的记忆。第二个是 codex 是 否从绘画中生成新的记忆。第三个就是一个重置，它主要是用来控制 codex 要不要使用这个记忆，以及要不要从绘画里面来生成新的记忆。 所以这三个命令分别对应着三种上下文。第一个 id 是 当前编辑器的上下文。第二个 compact 是 当前常对话的上下文。第三个 memorize 也是跨绘画的一个长期上下文状态与调试相关命令。接下来这几个命令主要是查看 context 当前的状态， 调整终端的显示以及管理后台运行的任务。第一个 state 用来查看当前绘画的状态，例如当前使用的模型目录 权限，绘画 id， 还有上下文限制之类的。第二个 slide 主要用来配置底部状态栏，就是我选中的这个地方，我们一起来看一下。比如说主题的颜色，我们看到这里使用了九十点七 k， 我们可以切换来控制它显不显示模型的名字。 g p t 五点五控制显不显示项目的名字，这里已经显示不下了，我把模型关了，使用托管关了项目的名字，还有当前所在的分支运行的状态，当前的这个模式，我这里是 auto view， 我 们可以通过 statline 来配置底部状态栏 的一个显示情况。第三个 title， 我 们可以通过 title 命令来配置终端，这个标题页的一个显示，我们来试一下，我们可以看到这里有个 codex c l i， 也就是项目的名字，在这里可以控制它显不显示。 这一个是当前的目录，比如说斜杠， codex c l i 这一些，根据自己的需要进行灵活配置。第四个 ps， 用来查看后台的一个终端任务。有些命令可能在后台持续运行，比如说 开发服务器测试监听长时间的一个构建任务，我们可以通过 ps 命令来查看。最后一个 stop， stop 是 用来停止后台的一个终端任务，比如开发服务器已经用不了，或者某个命令卡住了，我们可以通过 stop 来暂停。这就是我们状态和调试的一个相关命令工具与扩展相关命令。 第一个 m c p， 我 们通过这个命令可以列出当前所安装的 m c p 服务，我们可以看到我这里安装了 chrome， d v tools， 还 codex app 相关的服务， computer user， 这些都是 m c p。 我 们一起来添加一个 m c p 服务，我们这里来安装一个 figma m c p。 复制 m c p 的 地址，我们通过这个命令就可以添加一个 figma m c p。 我 们看到已经添加成功了， 我们来看一下在这里面能不能看见刚才我们添加的 figma mcp， 我 们这里已经看到了显示了 figma mcp 了， 所以我们通过 mcp 命令，我们可以看到当前绘画里可以调用哪一些外部工具。第二个是 hux， 它是用来查看和管理生命周期的钩子，钩子就是在关键时刻会自动触发，疑问表示触发时机。 in store 表示安装了多少个 hook active 标记，当前激活了多少个。这个是一个描述，这个是工具执行前开始触发，这一个是请求权限触发，比如让 codex 联网或者修改一些外部文件。 工具执行后开始触发上下文压缩触发等等之类的。我们可以通过命令来查看当前配置了哪一些钩子，哪些是可信的。 我们也有一些应用场景，比如说我们执行一些长任务，比如说通过 grow 命令执行一些长任务。执行完之后，我们希望他提醒我，我不可能时时刻刻的 待在这里，看着他有没有执行完。我们可以让他执行完之后，比如播放一个音乐。第三个 plug in， 它是用来查看或者已经安装的插件，这里可以看到这都是我安装的一些插件，例如编辑文档的 连接， figma 及 mail 相关的一些插件。插件通常会给 codex 增加一些新的能力，例如我们点击 document， 我 们可以来卸载它。这个插件里面使用了哪一些 skill， 这里都可以能显示。 我们返回最后一个 keymap， 这个了解一下，其实就是更改快捷键的一个指令界面，显示相关命令。第一个 then 用来选择高量主题，我们试一下， 这里有很多主题，我们切换可以看到代码的一个主题颜色，如果你觉得默认颜色看着不舒服，可以通过当前命令选择自己合适的主题。第二个 vm 用来切换 web 的 输入模式。 默认情况下， codex 的 输入框更像普通文本输入，我们看到它这种切换是这种模式普通文本的，如果我们通过 web 切换这种会看着比较舒服一点。这个命令适合 web 的 用户，如果你不熟悉，可以保持默认风格。第三个 row， 用来切换滚动模式，这种命令主要是为了方便复制终端中的内容，我们通过这个命令可以切换到更原始的滚动显示方式，这样复制内容 更方便。最后一个是 copy， copy 用来复制 codex 最后一条完整回复的消息，我们看到他回复了我这一段话。如果我们不想手动复制，我们可以通过 copy 命令。我们直接通过 copy 命令就把当前消息已经复制好了， 直接粘贴就可以退出。与维护相关命令，我们一起看一下。第一个 clear， 用来清空中端，开启一段新的绘画。它和 new 命令有点像，都是让你重新开始， 但 clear 更强调清理当前终端的界面。第二个 logout， 用来退出 codex 登录。如果你是在公共场所 或者临时借用别人电脑，可以通过当前命令来退出本地的一个登录凭证，让这台机器不再保持你的一个登录状态。第三个 feedback 是 用来把日制发送给 codex 开发团队。最后一个退出 codex， 它和 quit 一 样，都是离开 c r i 绘画。如果你还有重要改动没有保存或者后台任务在跑， 最好先确认再退出。到这里， c r i 里面四十多个命令我们已经讲完了，你会发现这些命令并不是让你死记硬背，我们可以把它分成类。有的是权限管理，决定 codex 能做什么。有的是绘画管理，决定任务怎么开始、 暂停、恢复和分支。有的是管理上下文，让 codex 更精准地理解你的项目。有的是辅助开发，比如 dev review 引用文件，制定计划。有的是调整终端体验。 我们在 c r i 里面用得更顺手。如果日常用来写代码，我们记住几组就足够了。 permission 权限管理 new resume fork 绘画管理 plan global 任务推进 mention idea 管上下文， def review 管代码检查 state compact 管 长任务状态。如果这期视频对你有帮助，欢迎点赞、收藏加关注，后面我会继续分享 ai 相关知识，我们下一期视频再见！

先看这个游戏，两个玩家输入同一个房间号就能实时进入同一局，攻击会同步，血量会变化，最后还能结算胜负。重点来了，这是由 ai 简编一份完整的需求文档一次性生成完成的。 但这次真正想说的不是 ai 又能写游戏了。真正让我感到意外的是，我专门做了一套 ai 长城任务工作流，结果发现不用它，强模型也能把这个游戏做出来。 我原来以为复杂的 ai 编程任务必须靠工作流才能稳。这套工作流不是随便几句提示词，它会让 ai 先补需求契约、技术方案、边界约束、验收标准，然后自动开发测试修罢，最后还要 交付测试的截图证据。自动化测试环节里面有一句很重要的话，页面能打开，只能叫开始，关键链路跑通才叫交付。 听起来很完整，对吧？但这次测的是同一个任务一次性做出一个网页在线对战游戏，不是静态的 demo， 它有前端服务端、房间号、双人实时同步攻击和血量的结算，规则也相当的严格。 提前写好需求文档，一次性丢给 ai， 中间不能补需求，不手工改代码，最后只看交付结果。反常识的地方来了，用工作流能做出来，不用工作流，只给清晰的需求文档也能做出来。虽然这不代表工作流没用， 但它能说明一件事，当模型能力足够强，需求文档足够清晰的时候，工作流不一定能决定能不能做出来，它更可能决定的是另一件事，过程能不能被验证，结果能不能复盘，后续能不能交付。所以我现在不会一上来就问 要不要给 ai 加一套复杂的工作流，我会先问这个模型和 a 准的上限在哪， 先写清楚需求文档，让墙模型跑一次，如果他已经能够做得出来，再去验证工作流能不能提升质量失败修复效率和交接成本， 这才是墙模型时代更合理的顺序。一句话，墙模型不怕提示尺短，怕需求模糊墙 a 准的不缺流程，缺清晰的目标。

如果你也想像甲方一样用截图给扣带题修改意见，又或者是让他撤回整改，最后再让他这么快处理，那么这三个小技巧一定要收藏好。 一、中途介入修改 ai 帮我预设了这个风格，但是我不想要直接在这输入你的新需求，点这里的引导， ai 就 能顺着我们的新提示来调整了。 然后接下来两步，有一个非常重要的一个前提，就是你需要有自己的 get 仓库。在个人主页里右上角的创建 new repository， 输入项目名称确认，然后这里点复制 这是你已经创建好的网页，直接帮你出场这个项目，这就出场成功了。点上方的文件夹，创建永久工作树。那我还有一个问题，我们的自己创建的永久树跟我直接在下面打开一个窗口，有什么不一样呢？我要回答你， 新窗口会共享代码，工作数是独立运行，再决定要不要合并。先左侧创建两个工作数， 依次打开网页，各自在这输入需求，出现小蓝点，就是任务完成了。来刷新看看效果吧。风格灵感加入了新标签，看看这个新的品牌故事吧。 再回到主项目看看，恭喜你已经学会了多模块处理了。再补充一个最近常用的注试，哪里不会就点哪里，真的超级方便呀！ 这里直接提交修改就好了，可又要当甲方爸爸说要用回上一版时啊，这完全不知道咋办了。没事，点右上角的 vs code， 点这里的 get， 在 这找到你要返回的版本，点击 复制提交哈希，回到聊天窗口恢复版本，并粘贴刚刚的哈希，等待执行完成就刷新看看。恭喜你学会了回退版本。

今天我们聊一下 codex 这一个月更新的八个新玩法。我以前一直觉得 codex 是 个备胎，去年四月 codex cli 刚出来那会儿， 我用了两天就回去用 cloud code 了。理由很简单， codex 当时就是个会写代码的终端 agent， 跟 cloud code 比没什么区别，模型还稍微弱一点。直到四月十六日那天， openai 发了一条公告，标题叫 codex for almost everything， 意思是 codex 不 再只是写代码的 agent。 先说最离谱的那一项， computer use codex 现在能看你屏幕点你 u i， 用它自己的光标在你电脑上打字，授权之后它可以操作你电脑上的桌面 app。 我 第一次让它做的活是把这个 figma 设计稿里的色值抓出来，写到 tailwind config 里，它打开 figma 截屏识图写入全程。我没动鼠标 这类跨 app 的 活， cloud code 作为 c l i agent， 很 难直接做 codex 这一步直接跨出了终端，代价是你给他的权限是整台电脑，不是某个项目目录。心智压力比 cloud code 大 一个量级。跟 computer use 配套的 还有一个内置浏览器。最有意思的设计是，你可以在网页上直接评论，把这个 comment 当成指令丢给 agent， 就像在 google docs 上选中一段文字加评论一样，但被评论的是网页 dom。 举个例子，你打开本地预览页，选中一个按钮，评论一句，这个按钮状态太弱，改成更明显的 primary action。 完了， 这种指着浏览器跟 agent 的 说话的交互，比 cloud code 走 mcp 接 api 那 套直觉多了。普通人不用懂什么是 api， 但真正让我有点恍惚的是， automations 是 一个持续任务系统，你给 agent 的 一个长期目标，它可以附用原来的对话上下文， 按计划自动唤醒继续做。 openai 的 原话是 potentially， across days or weeks。 比如你可以把任务写成每天监控这个开源项目的 issue， 每出现一个跟性能相关的，就帮我整理背景附线路径和可能的修复方向。它每天自己醒一次，自己扫，结果放到队列里等你看。这开始有点接近让 agent 接长期任务了。然后是 pets， 五月一日左右上线的，是这个月 codex 最初圈的更新。你输入 slash pet 就 能召唤一只虚拟宠物，浮在屏幕上做状态指示器， 它告诉你 codex 现在在跑什么任务，是不是在等你输入，是不是做完了。八只内置宠物可以选。还有一个 slash hatch， 可以 让 ai 生成自定义宠物。这设计妙在，它解决了一个我们都默默忍受的问题。 agent 在 后台跑唱任务的时候，你不知道它现在到哪了。以前要么切终端，要么挂个第二屏幕，现在屏幕上一直有只小猫，它的姿势就是状态，但是区域限制要分清。 open 官方明确说 computer use 初期不再意义。 a u k 瑞士开放 hats 这块我没核到同等强度的官方说明。所以如果你人在欧洲，并不是所有 codex 新功能都能立马可用。第二自定义宠物的画风偶尔会翻车，社区里已经有人把 clippy 动漫角色，各种像素小人都做出来了。好看的是真好看，怪的也是真怪。 但一个虚拟宠物功能能被开发者认真讨论，你就知道它戳到了什么。剩下几样我快点过。五月十四日， codex 进了 chat gpt 手机 app， 准确说是手机端可以远程接入正在运行 codex 的 mac host。 你 在地铁上，在咖啡馆， 可以用手机继续控制回答问题，批准操作，看 df 和测试结果。但电脑那边要保持在线， codex 也要再跑。这事跟 automations 配在一起威力很大。早上出门前交代一个长期任务，路上用手机补两句判断， 回家再看结果。这里要修正一下。 cloud code 也有 remote control， 可以 从 cloud app 或 cloud 网页端继续本机绘画。区别不在有没有手机入口， 而在 codex 把入口放进 chat gpt app 这条产品线里。四月十六日那波还顺手加了九十多个插件， atlanta rover、 circle shade code、 rabbit、 github issues、 microsoft suite 都在里面。 cloud code 走 mcp 也能接，但要自己配 servoach。 codex 这边是点一下装好的体验，底层也换了。 四月二十三日， openai 发布 gpt 五点五，并明确说它正在进入 chatttt 和 codex。 官方说法是， gpt 五点五在同类 codex 任务上更强，也更省 token。 它还跑在 nvidia gb 两百和 gb 三百 n v l 七十二系统上。具体到比 cloud code 省多少，社区里说法很多，我没看到一个能直接当结论引用的统一数字，但我自己的体感是，同样刨长任务 codex 的 成本焦虑确实小不少， cloud code 也没掉队。 antropica 四月十六日发布 opus 四点七 s w e bench verified 报道，百分之八十七点六。 open i 这边 gpt 五点五的 terminal 奔驰二点零是百分之八十二点七， cloud opus 四点七是百分之六十九点四。 这些 benchmark 口径不完全一样，不能简单等同于 codex 工具，打败 codecode 的 工具。我现在更愿意把它理解成 codex 在 长任务、跨 app 成本和可用性上进攻很猛。 cloudcode 在 严肃代码质量和复杂重构上仍然很有竞争力。 dv 上有篇社区余情整理，看了五百多条 reddit 评论和一些盲测，结果给了一个挺贴脸的说法， cloudcode 是 高质量但不好用， codex 是 稍低质量，但真的可用。这不是严格抽样调研，但它很像最近很多开发者的体感社区。现在很常见的一种用法是 codex for keystroke， coded code for commits。 日常输入用 codex 跑得快又省心，关键提交 code review， 复杂重构，切回 code code， 求质量。 甚至有人把同一套 skill 同时喂给两边。聊完功能再退一步看，会发现一件挺有意思的事儿。 cloud code 这一个月在生化， harness 做插件 hack worktree 和 deny rules， 把自己往 os like 做， codex 则跨出代码边界做 computer use， 内置浏览器 automations， 手机入口和虚拟宠物，把自己做成 digital co worker。 一个想做你的操作系统，一个想做你的同事。两条路都对，但两条路真的不一样了。 我现在的姿势是两个都开。 codex 跑，长任务跑，跨 app 的 活跑，需要在手机上启动的活。 codecode 跑，严肃 commit 跑，要保质量的重构跑，开源项目。那只 codex 的 小猫还浮在我屏幕右下角，告诉我它在等我。省一个 p r。 你 用 codex pets 了吗？

我一开始看到 superpowers 里面的头脑风暴 brainstorming， 以为它就是让 ai 先多问几个问题，但用了一段时间之后，我发现不是这样。头脑风暴不是闲聊，也不是让 cortex 先问我问题，它更像是 ai coding 里的一个开发前流程，先识别需求是不是模糊， 在不断追问和确认，然后探索不同方案，最后把设计方案拿给你确认，确认之后才进入后面的计划和开发。所以这期我们就聊聊为什么 ai 写代码之前应该先澄清需求。在 cortex 里面用 superpowers， 我 觉得一个很自然的体验是，很多时候你不用 手动输入，请使用 brainstorming skill， 它会根据当前任务自己判断。这个背后其实和 cortex use 的 加载机制有关。 cortex 一 开始不会把所有的 skill 完整内容都塞进上下文，而是先看到每个 skill 的 名称、描述路径，它会根据当前任务判断哪个 skill 更适合现在的这个场景。 如果你提出一个比较模糊的新功能，目标还不明确，边界还没有定，方案还需要讨论，那么头脑风暴的描述就会 配这个场景。于是 cortex 会选择它，再加载完整的 skill 点 md 这个文件，进入需求澄清和方案探索的流程。它看起来像是自动触发，但本质上不是魔法，它是 cortex 根据任务上下文选择一个合适的 skill。 brainstorming 最有价值的地方不是他问了几个问题，而是他会不断确认需求有没有对齐。他通常不是这样，问一个问题，收到回答，然后马上开始写代码。他更像是这样，先理解当前项目上下文， 再提出澄清问题，等你回答之后，他会继续判断需求是不是已经足够清楚，如果还不清楚，他会继续问。如 如果清楚了，他才开始探索可能的方案，他会比较不同方案的取舍，把推荐方案拿给你确认，如果你觉得不对，他会继续调整，等你确认之后，他才进入后面的计划和开发。这和平时我们写一句 prompt 需求不清楚就先问 我是不一样的，那是一句提醒，而 brainstorming 是 一套流程。所以 brainstorming 头脑风暴真正解决的不是让 ai 多问几个问题，他解决的是 要让 ai 一 边猜需求一边写代码。而很多 ai coding 的 时候，并不是 ai 不 会实现，而是它在需求还没有收敛的时候就已经开始动手了。 brainstorming 的 作用就是把这些不确定性提前暴露出来，目标是什么，范围是什么，哪些不做， 有哪些方案，每个方案的取舍是什么，怎么验证？最后做对了。这一步看起来会让 cortex 慢一点，但它其实是在减少后面的反攻。所以这一期的核心是 prompt， 是 提醒， skill 是 流程。你当然可以在 prompt 里写 需求不清楚先问我，但 brainstorming skill 做的是让 cortex 在 遇到模糊需求时，自动进入一个需求澄清方案，探索 设计确认的流程。这就是 superpose 的 第一个核心 skill。 下一期我们继续看 superpose 后面的流程，这里是 cortex 工程实践，下一期我们继续。