codex多任务并行不会搞乱代码吗

最近有个说法挺刺激， codex 更新之后，有些能力已经超过 cloud code 了。真的假的？我觉得这个问题不能直接回答， 因为你先得问清楚，你比的是谁更会写代码，还是谁更像一个工程团队的操作台。接下来几分钟，我们不站队，拆开看，看完你大概就知道为什么这次 codex 的 变化不只是模型变强了。 以前聊 ai 编程，很多人默认 cloud code 是 标杆。它在终端里很顺，能读代码库，能改文件、能跑测试，开发者的心智负担很小，你让它修一个 bug， 它真的像坐在你旁边的工程师。 但最近 cloud code 新后，社区里开始冒出另一种声音，怎么感觉 cloud code 某些地方更爽了？有人拿它和 cloud code 对 比，有人说自己被 cloud code 搞崩后换了工具。先别急着下结论。 这个争议真正有意思的地方，不是 cloud code 赢没赢，而是大家发现 ai 编程工具已经不是一个命令行聊天框了。 如果只拿一个 bug、 一个重构、一个 delete code 题去比，你很容易比错，因为那是在比底层模型的局部能力。这个当然重要，但它不是全部。 现在的 coding agent 更像一个小型工程流程，它要理解需求，要改代码，要跑命令，要看浏览器，要处理 pr， 还要知道什么时候该停下来让人确认。你看，问题一下就变了，不是谁补全的更准，而是谁能把一件工程任务从头推到尾。 这也是为什么很多人会觉得 codex 这次不一样，它不是只在代码框里变强，而是在代码框外面长出了手脚。 codex 最近最关键的变化是产品形态变大了， openai 官方把它讲成一个可以委派真实工作的 agent， 它不只是改文件，还强调多 agent 工作流，内置 worktree、 skills、 automations、 pr review、 多文件、多终端、远程 devbox， 内置浏览器，甚至电脑操作。 注意这些功能单看都不神奇，但放在一起，味道就变了。以前你让 ai 写代码，更像叫一个人坐到你的电脑前。 现在你可以把任务拆成几路，让不同 agent 同时跑，一个修 bug， 一个写测试，一个看前端页面，一个整理发布。说明，这就不是代码助手了，它更像一个工程指挥台。这个词有点大，但很贴切啊。克拉多瑞弱了吗？不是，克拉多瑞的基本盘还是很硬， 它的优势是终端原声跟开发者每天用的工具贴得很近。你在项目里打开它，它读代码，跑命令，用 git 接 m c p， 很多动作都在你熟悉的命令流里发生。它还有一个很重要的，气质，谨慎， 默认，会问你哪些命令能跑，哪些文件能改。这对真实项目很关键，尤其是老项目、大代码库、线上事故这种场景，你不一定想要一个到处乱点的全能 agent， 你想要的是一个懂代码、懂命令，还愿意听你刹车的人。 cloud 会有，在这块儿还是很舒服。 codex 更容易赢的地方是任务开始变宽的时候。 比如你不是只要修一个函数，而是要做一整个小功能，先看需求，再开分支，再改前端，再跑测试，再打开浏览器确认视觉，再写 p r 描述。这里 codex 的 优势就出来了，它可以把文件、终端、浏览器、工作区放在一个工作台里，还能让多个 agent 并行。更关键的是， 它不止服务程序员，文档、表格演示、自动化检查，这些原本不算写代码的东西，也能被放进同一个流程。说白了， codex 强的不是某一权特别重，而是它开始会组织一套组合权。 这是很多人突然觉得它反超的原因。但如果你的工作方式很终端很连续很工程师， cloud code 还是会让人上头。 你在一个复杂仓库里追依赖，看日制、改测试、处理 c i， 它的节奏很自然，它不像一个大平台，而像一个强力命令行同伴。还有一点容易被忽略， cloud code 的 简单反而是优势，入口少，心智清楚。很多时候，你不用管理一堆 agent， 也不用想工作台怎么摆， 你只要说帮我把这个问题修掉，它就顺着代码库往下钻。所以我不认为 codex 全面超过 cloud code。 更准确的说法是， codex 在 工程流程组织上开始领先，而 cloud code 在 终端深度开发上仍然很强。所以这次真正值得关注的不是 codex 有 没有把 cloud code 打趴下，这个说法太粗糙了。 真正的变化是， ai 编程工具正在换赛道，第一代比谁更会补代码，第二代比谁更懂代码酷。现在开始比谁能组织工作，谁能并行，谁能跨工具，谁能长期跑，谁能在关键时刻把权限交还给人。 以后程序员可能不只是写代码的人，而是调度一组 ai 工程师的人。听起来有点夸张，但说实话，这一天来的比我想象中快。

我用了 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？ 下一期我们继续。

很多人用 cloud code， 只会让他在一个绘画里单打独斗，一旦项目变大，需求变复杂，同时要做好几件事，就容易漏功能，逻辑混乱，任务做不全，越写越乱。 其实 cloud code 藏着一个被严重低估的高阶神迹，就是 sub agent 子 agent 分 身能力给新手讲的通俗易懂。主 agent 负责调度项目整体架构，然后自动分出多个子 agent 分 身，各自认领，独立任务，分开并行干活。 用你手动拆任务，也不用自己分配模块，它会自动把大型需求拆分到位，有的搭建项目目录，有的编辑业务功能，有的优化代码逻辑，还有的专门整理注视编辑文档，检查漏洞 bug。 每个子 agent 只专注自己负责的模块，互不干扰，不乱改代码，不打乱整体逻辑。做完之后再由主 agent 统一整合、梳理、收尾。想直接起用也很简单，你直接复制这句话发给他就行。 帮我启动 safari 的 子分身，把当前项目需求拆分成多个独立子，任务分配，不同子 a 整的分头并行开发，各司其职，互不干扰。 最后统一整合代码和结构，开启之后再也不用一个绘画扛下所有任务，简单需求随便聊，复杂项目一定要开子 a 整，结构更清晰，代码更规范，功能不遗漏，开发效率直接拉高一个档次。真正吃透这个热门技能，才算把 cloud code 的 高阶生产力彻底用到位。关注我，带你解锁更多 cloud code 的 实用干货！

别再把它当补全工具了， codex 已经能像工程团队一样并行干活。近日，在 open i i 开发者体验团队的一场工作坊里， katerina gilgameshman 和 vipav srva staff 把 codex 重新定义了一遍。它不再是在终端里帮你写几行代码的工具，而是一个开放的软件工程 ai agent。 他能做的事很工程化，跑命令、跑测试，探索整个代码库，在不同入口里协作 codex 应用、 ide、 扩展 c o i， 甚至还能在 slack 里 at 他， 在 github 里让他直接参与流程。底 层模型也在飞快迭代，从 gpt 五点二到 gpt 五点三 codex， 再到与 siribras 合作的 gpt 五点三 codex spark 最近是 gpt 五点四，还发布了 mini 和 nano 版本， 专门照顾短任务和子 agent 这种多线城活儿。更关键的是速度，通过 web sock 把 token 吞吐提升到约一点七五倍，再叠加 fast mode 还能再快一截。 真正让人有系统感的是 codex 应用的工作方式，它把跨项目和同一项目多功能并行，做成了原生能力。核心就是 work trees， 你 可以把一个项目拆成多个工作树，一个做功能，一个修 bug， 一个只做问答，互不干扰， 还能配合更顺手的 get 支持。再往上走就是两套自动加速器。第一套叫 prgames， 把 skills apps、 mcp、 服务器、提示词等打包成可附用工作流。 skills 可以 理解成你常用 s o p 的 封装，避免反复口述。 apps 是 连接 notion、 linear 这类外部服务， m c p 服务器则是把外部系统的工具能力暴露给 codex 调用。第二套叫 automations， 本质就是把一次对话变成后台定时任务。 最直观的例子是每天早上九点自动汇总 slack 里需要回复的消息，标记是否紧急按主题分桶。再比如连接 gmail， 从海量邮件里筛出真该回的和看起来不靠谱的。这种自动化不炫技，但非常贴近日常，省下的是碎片时间和注意力。 现场还有两个很能打的演示，一个是用 google drive 插件把代码库里 yaml 维护的活动信息自动同步到表格里。 codex 用了大约两分钟分析代码库，然后一次性写入五十七行活动数据。另一个更直观，用游戏开发插件，调用 imagegen 生成精灵图，再用 play white interactive 在 可点击的沙箱浏览器里边跑边看边截图分析，最后做出一个平台跳跃小游戏。 他强调自己几乎没给额外输入，只提了砖块平台的需求，其余素材和组合都由 codex 完成。这样的越把活交给 ai agent， 越绕不开质量控制。 webapp 给了一个很硬的标准，当你同时让它跑多个功能、多个项目，人类不可能逐行看代码，最需要的是可靠的第一道闸门，代码审查。 codex 的 代码审查可以直接接入 github， 给每个 p r 自动打出 p 零、 p 一、 p 二级别的问题提示。 在 codex 应用或 c o i 里，也能用斜杠命令出发审查，甚至还能在 cloud code 的 绘画里调用同级别审查能力 最冲击的一句话是， openai 内部所有代码库员工提交的 pr， 默认百分之百会先过一遍 codex 代码审查，当做第一道机器同事的把关， 接下来才是像团队一样工作的关键。 sub agent 子 agent 思路很像把一个主任务拆成多个可并行、相互独立的子任务，然后把它们分发给不同子 agent 去去做。 最后在汇总结果演示里，他让系统开二十个子 agent 去审四十五个 persona 配置文件，虽然它的环境并发症只有六个，但你能看到子 agent 被分配了明确的文件切片，明确的检查依据， 跑完之后汇总出哪些 persona 权限过大，哪些沙箱模式不匹配等结论。更重要的是，子 agent 不是 同一个模板复制粘贴，你可以给每个子 agent 指定不同模型、不同 reasoning effort、 不 同 sandbox 权限，甚至接入不同 m c p 工具。比如审查类子 agent 最好永远 read only， 安全分析也是 read only， 但写文档、写 bug 报告这类就可以给 right 权限。 vipop 还演示了让 codex 自己生成一个文档。研究员子 agent 自动创建 t o m l 文件，挂上 docs 的 m c p 服务器， 让他在回答如何使用 gpt、 五点四配合 web sock 这类问题时，能引用完整文档与指南。 最后，他们把可控讲得很直白，别再优漏模式全放全。 guardian approvals 会在遇到高风险动作时，先拉起一个专门的子 agent 做验证，减少人类反复点确认造成的疲劳。 hooks 能在绘画开始，每次工具调用后，绘画结束时自动触发脚本，比如开局先拉取 github 最新代码， 或者长任务结束时自动再跑一轮验证再停。再加上 kodak security 用于漏洞扫描与修补，整体就变成一套能干活、能并行、也能被约束的工程系统。如果你现在就能用，你最想让它接管哪件事？

codex 不 止会写代码了，现在还会点浏览器，可以直接进谷歌浏览器 com 工作，查网页，看后台，填表单，整理数据。很多原来要你手点的事， 它现在都能接上，具体能干什么，可以看下以下三个场景。第一个，整理你登录过的网页信息，它可以进入你 com 里已经登录好的网站，读取页面上的数据，帮你筛选和整理。比如从邮件里找出差报销记录，或者从后台把一场订单归类汇总。 我的看法是，这个登录太是关键，以前你让 ai 帮你做这类事，要么导出数据再粘进去，要么这张 a p i， 现在他直接进你已经登录的页面，省掉了这一步。第二个，多标签页后台并行处理， 他可以同时在多个扩容标签页里后台工作，任务之间互不干扰，也不会卡住你的浏览器。比如同时打开几个系统，分别处理不同的任务，我觉得这个能力被低估了。以前 a 阵操作浏览器分别处理不同的任务，我觉得这个能力被低估了。以前 a 阵操作浏览器就全卡， 现在并行跑，效率差距很明显。第三个，自动判断用什么工具。如果一个任务同时涉及浏览器插件、代码仓库，他会自己判断每一步用什么工具，不需要你指定。比如从网页读数据，处理完再写为代码，他自己串起来。这才是这次更新真正的变化， 它不是一个会点浏览器的脚本，而是一个会自己拆任务选工具的 a 阵边界，从 id 扩到了真实工作流。如果你的 codebox 如果找不到这个插件的话，可以把你 codebox 更新为最新版本， 然后重新退出登录在插件菜单就可以找到 chrome 插件了。我 windows 跟 mac 亲测是没有问题。装完这个插件之后，你还需要安装一个浏览器 codex 插件。完成这两个插件安装之后的你就可以让你的 codex 输入 iphone 进行在浏览器干活。我是 sami， 我 们下期见。

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 是 我过去几个月高频使用的 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 能跑长任务的轮次会明显拉长。 第一招，主动压缩，每隔一段时间让 codex 自己出一份摘要，讲清当前在做什么决策，记录还剩什么没做。摘要存到本地一个进度文件里，下次接着干的时候把这份摘要塞回去，等于把前面的后记忆压成一页纸。 第二招，关键信息外存，代码片段接口文档设计稿别放在对话里，反复重复，让 codex 记住路径，需要的时候自己去读，对话窗口里只留他正在动手的那一小段。 第三招，任务分块，一上来就别给他一整个大目标，先切成三到五块，每块单独开一个绘画来跑，每块跑完归档主线，只保留摘药，这样每个绘画的上下文都是干净的，跑长任务也不会堵。 把这三招配上之前讲过的 agents， md， codex 能撑过相当长的工作流。我自己改一个老项目，这套打法配合下来中间没断过线。评论区聊聊你的 codex 最长撑过多少轮，没换会换。

codex 不是 不能接项目，大部分人翻车是因为前面没加 hermans 这层管家。我以前最怕的不是他写错代码，是一个长任务，跑起来以后越改越散，窗口一关回来根本接不上，你让他直接吃一整团需求，他看起来很猛，实际特别容易失控。 我后来把流程改了，只多加一层 hermes， 效果完全不一样。第一步， hermes 不 让 codex 直接开干，先把任务拆成三段，已完成进行中下一步，这样 codex 每次拿到的不是一个模糊大需求，而是一段明确的小任务。 第二步， hermes 强制留进度，我现在都会让他写 progress dmd， 里面只记四个东西，改了哪些文件，最后一个成功命令现在卡在哪，下一步跑什么。所以就算任务中断也不是重来，而是打开 progressmd 继续接。第三步，危险动作，不让 codex 自己排版， 像删文件装依赖改大范围代码， hermes 会先拦一下让我确认。这一步特别关键，因为 codex 最怕的不是不会写，是你给他太大自由，他就容易越改越乱。所以我现在的感觉很直接， codex 负责执行， hermes 负责拆任务，管状态，拦风险。 这样 ai 才不像一个会聊天的写马工具，而是真的开始像一个能接项目的执行员。如果你也想看我这套 codex 加 hermes 的 项目管家结构评论区打项目管家，我把我现在用的 progress 打 md 模板发你。

codex 跑长任务总在最后一步崩，很多人以为是模型的问题，其实是任务没有结构解法，就一步在项目根目录建一个点 hermes 文件夹，里面放一个 task e m l， 把长任务拆成有依赖关系的子任务列表， codex 每完成一步就打勾，下次续跑从断点开始，不用从头来。这个工具叫 hermes， 定位是 codex 的 项目管家，专门解决 codex 跑长任务没有记忆中途崩了不知道跑到哪的问题。核心配置只有三个字，断。 第一个是 task 任务列表，每条任务写清楚做什么，验证标准是什么，依赖哪个前置任务完成。第二个是 risk flags， 提前定义高风险操作，比如删除文件，修改 config 目录，改数据库 schema， 触发这些 hermes 暂停，让你确认 block code 自己闯。第三个是 progress report， 指向一个 progress md hermes 每完成一个子任务，写一条日记，早上起来不是对着一团改动，猜昨晚发生了什么，而是一份清单，告诉你每步做了什么，结果是什么。 我现在跑超过三步的任务，全部先写 task em， 再交给 codex， 翻车率直接调到接近零一人。公司用 codex 干长活，缺的不是模型能力，是任务管理层， hermes 就是 那一层。你的 codex 现在跑长任务吗？评论区聊聊。

hello， 大家好，我是 fred， 专注从普通小白的视角去分享怎么从零开始用 ai 和 web coding， 提升自己生活和工作效率。很多人装完 codex 第一反应就是马上去让他写代码，但我会让他做另外一件事情，也就是 给他写好 hmd。 因为 ai 其实不怕复杂的任务，怕的是一开始没有规则，没有规则的时候他可能讲太多，改太多，甚至把你不想动的地方也顺手动的。所以说我们这期会先讲怎么让 codex 在 动手之前先知道你的规矩。 第一，什么是 a g m d？ 大家可以把 a g m d 理解成 ai 的 一个写作的说明书，它会告诉 codex 这个项目怎么沟通，怎么写代码，哪些安全底线不能碰，哪些操作必须先问 以前这些要求，你可能要每次重复的去讲，去写进这个文件以后，它就会变成一个默认的规则，你不用每次去教 codex 怎么去配合你。 然后第一部分，其就是他的整个的语言的使用规范，因为我日常沟通就用中文嘛，这样去讨论需求和复盘问题其实更顺的。 但是像在代码，包括命令行啊、变量名啊、日制和报错，其还是要保留英文的。原因很简单，就是因为 英文报错可以直接去搜索，方便去定位问题，如果全翻译成中文，反而会降低排查的效率。所以说我的原则是解释用中文，哎，记住信息，保留原样。 第二部分就是它的代码和提交的规范。虽然我们大家都看不懂代码，但是我也不希望 ai 为了去显得完整，去提前写一堆复杂抽象的东西，其当前需要什么东西，就把当前的问题解决干净，如果单个文件太长， 那就去拆主键，拆函数，去拆模块，每次改动尽量小一些，提交清楚啊，每一次的记录，这样后面口袋再去维护的时候，才不会被一大堆的这种十三代码去劝退，对吧？ 第三个最核心的点就是安全，与红线类似，像这种密码啊，密钥啊， a p r key 啊，这种是不能够直接写进代码的，然后包括像点 e n v 这种本地配置的文件，也不能提交到仓库，包括日期，也不要输出一些隐私的信息。 像日常的一些小改动，其实可以用一些低摩擦的去执行，但比如涉及到一些接口的结构啊，数据库的制段啊，批量去删除一些文件啊，或者说一些外部的账号和数据，就必须天 先让他停下来跟我确认。其实这不是去增加一些流程啊，而是防止一次自动执行，把一些项目改到不可控的状态。 然后第四个就是它的整个的执行与测试的工作流。就很多时候 ai 说，诶，我已经修好了，其实不重要，就验证通过才重要，你知道吧？ 所以说如果命令报错，要如实的去上 ai 报告，然后包括测试失败也不能查，包括修 bug 的 时候，最好去先写一个能够复现问题的测试，再去改代码，就跑完以后能跑测试就跑测试，能跑 nin 就 跑 nin， 这样才能够减少 ai 的 整个的一个幻觉， 想让他看起来完成，但实际上不能用的这种情况。然后最呃第五个呢，是我自己的一个用户习惯，因为我会要求他叫我 fred， 包括我自己的偏好去直奔主题，找一些形式化的确认，能够直接做的就日常 直接做啊，但涉及到一些可能删除啊，密钥啊，权限啊，上传啊，账号操作这种风险点啊，就必须还是跟我确认，这样应该就不是机械的去回复我，而是更贴近我自己的一个工作节奏。 然后像呃目前我的这个 a g m e a i 的 一个工作模式的话，就是遇到熟悉的问题，他会去用一些内置的 skills， 而不是每次都从零开始去乱试，包括改完源码之后去默认跑测试，降低一些低级的语法错误，也不会去做一些多余的发散。 真正高效的写作不是让 ai 写得越多越好，而是在正确正确的这种边界里面把当前的问题解决掉。 所以说我可以给大家看一下当前我整个的一个 h m d 啊，包括刚刚所说到的语言的问题，安全红线的问题，工作流程的问题以及代码标准的问题，和我自己的一些用户偏好，其实跟刚刚讲的是完全一致的， ok。 最后总结一下就是， agent m d 的 本质就是把你反复叮嘱 codex 的 话一次性写清楚，语言怎么用，代码怎么写，安全边界在哪里，什么时候要去验证，什么时候要去确认，都放进去， 它不是让流程变得复杂，而是去减少废话，减少返工。所以说 codex 安装好以后，我建议不要第一时间让它去写功能，先把规矩建立起来，先定规矩，再让 ai 去干活。规则清楚之后，你只需要告诉它目标， 剩下的就是让他按规则去执行。 ok， 我是 fred， 后面我会持续用真实的案例告诉大家怎么把 ai 用进自己的工作流。这就是本期的分享，我们下期再见。

程序员注意，现在手机也支持 codex 了，但重点不是让你在手机上写代码，真正重要的是，你可以随时随地控制电脑上的 codex。 以前 codex 跑到一半问你要不要继续，要不要执行命令，你人不在任务就停住。 现在你在手机上就能看进度，批操作、改方向。过去的 ai 编程工作流有一个很大的问题，人必须跟着 agent 的 节奏走。 他问你要不要继续，你不在，他停，他问方案选 a 还是 b， 你 不回，他停，他要执行测试或者高风险命令，你没批准，他还是停， 这不是能力问题，是协助半径太短。 agent 很 强，但他被锁在电脑前。 openai， 把 codex 放进 chat gpt 手机 app， 但重点不是在手机上跑代码， 真正干活的还是你的 mac、 mac mini、 devbox 或者远程开发机。手机只负责看批改方向，文件、凭证、权限都还留在原来的机器上。这件事真正改变的是 agent 工作方式。 以前你在陪 agent 跑，现在是 agent 跟着你的节奏跑。你在地铁上可以看他跑到哪一步，你在开会时可以审一眼 diff， 你 在吃饭时可以批准他继续测试。你在路上发现方向错了，可以直接打一行字让他改。 你看官方信息里真正关键的表述，在 chat gpt 移动应用中开始新工作，查看输出结果，控制执行进度并批准后续步骤。 这句话的重点不是移动端，而是控制执行进度和批准后续步骤。也就是说，手机端承担的是 agent 工作流理的控制面，而不是代码运行面。具体怎么用？第一步，电脑上先跑 codex， 目前主要支持 macos、 windows， 还要等。 第二步，手机更新 chat gpt app， ios 和安卓都已经有 preview。 第三步，在 chat gpt 里打开 codex， 你 就能看到正在跑的任务线程。 第四步，在手机上看 beef， 看测试结果，回复新指令，批准高风险操作，甚至新建任务，继续跑。 这次更新不是让程序员在手机上写完整项目，他更像是给你的 ai 程序员加了一个随身遥控器，你不用把文件凭证、开发环境搬到手机上，你只需要在他需要判断、批准和纠篇的时候能立刻出现。 所以这次更新不是 codex 多了个手机版，而是你的 ai 程序员终于有了一个随身遥控器。对程序员来说，这比手机写代码重要得多。因为真正的效率提升不是你在哪里敲字，而是 agent 卡住的时候，你能不能立刻让他继续往前跑。

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

今天我要介绍一个能彻底改变 ai 工作流的开越项目，让 ai 互相审计。你想想，单个 agent 告诉你任务完成了，你真的能信吗？遗漏、隐藏的错误，甚至幻觉都可能被轻易放过。 所以我们引入了第二个模型，由克拉执行， codex 专门审计，再通过一个叫 breach 的 模块进行桥接，克拉完成后发出 handoff， codex 立即返回详细的 audit 报告，整个过程完全可追溯。 这实现了真正的双向审计，在同一个绘画里就能拿到结果，所有记录都会持久化存正。而且项目本身零依赖，上手只需要四步克隆操控安装，依赖运行倒插检查环境，然后一句话就能调用。

很多人用 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 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 开始，等你能清楚拆分任务，再尝试让多个代理并行改代码。

前面八期我们一直在聊 ai coding 为什么会越来越乱，比如上下文污染、 bug 越修越乱，项目风格漂移， prompt 控制力下降。所以这一期我不想继续对着 ppt 讲了， 我直接打开 cortex， 聊聊我们现在到底是怎么样用 cortex 的。 因为我越来越明显地感觉到， cortex 已经不是一个聊天工具了，它更像是一个 ai 工程工作台。我现在用 cortex 做复杂任务，第一件事通常不是让它写代码，而是先开一个 plan 模式， 这个就是一个 plan 模式。以前我们要靠 prompt 去约束 ai， 先分析项目结构，嗯，不要直接改代码，先给我计划。现在 cortex 已经把这个动作产品化了，这说明 ai coding 正在从靠 prompt 约束 ai 变成靠 workflow 约束 ai。 plan 模式的价值不是多写一份文档，而是先让 ai 明确当前目标是什么，设计哪些模块，修改范围在哪里， 后续应该分几步执行。所以复杂任务里，我现在会让 codex 先做 plan plan 合理之后再进入执行，这比直接 coding 稳很多。第二个变化是，我现在会用多个 thread， 而且不只是同一个项目里面开多个 thread， 有 时候是跨项目并行。 比如一个 thread 在 这个项目里面做 agent ron time 的 设计，在这个项目里面做标注的功能，在这个项目里面整理啊， adence 的 文件 啊，然后在另外一个项目里面专门分析 bug 啊。这时候你会发现， ai coding 已经不是我和 ai 的 一个聊天窗口，而更像是我在管理多个 ai 窗口，而更像是我在管理多个 ai 边界。 染不同项目的上下文很容易互相污染，这也是为什么后面我们会越来越多讲 workspace、 engineering agents， coordinates， ignore skills。 第三个我，我想重点讲的是 memory。 很多人可能会问， cortex 不是 本来就有很长的上下文吗？比如二百五十六 k 上下文，那 memory 又有什么区别？我的理解是， cortex 的 长上下文解决的是当前这个 thread 里， ai 一 次能看到多少内容，它更像是当前任务的短期连续性。 而 memory 解决的是跨 thread 的 长期工程信息。也就是说， memory 不是 简单把二百五十六 k 变得更长，而是让 cortex 尝试从历史聊天里沉淀一些 长期有价值的信息，并带到新的聊天里。比如你的工程篇号、项目篇号、架构、约束、命名规则，哪些做法不要再用？不过 memory 也不是越多越好， 你看这个设置，跳过工具辅助对话，也就是不要从使用 m c p 工具或网页搜索的对话中深层记忆。 这设置很关键，因为 memory 最大的问题不是记太少，而是记错、记脏、记过期。所以 memory 也需要治理，必要的时候也是需要重置的。 回过头来看这几期，其实我们一直在讲同一件事情，就是 ai coding 的 时代正在发生变化，它不再只是 prompt 到 code， 而是变成 work space、 plan thread、 memory、 work flow。 所以 ai 编程真正的竞争力已已经不只是会不会写 prompt， 而是会不会工程化地管理 ai。 你 要管理它看到什么，它记住什么，它在 哪个 work space 这种工作他怎么做 plan， 他 在哪个 thread 里面执行。这一期也算是第一阶段的收尾，下一期我们正式进入 ai engineering， 会继续聊 agents skills cortex， ignore work space engineering， agent workflow memory 等等等等。

今天这期视频我就带大家完整拆解一下 codex 前端的一个交互界面，然后足够去讲清楚每一个功能按钮，它的作用，切换逻辑以及不同场景下我们该如何去搭配设置。学会之后你就能精准把控工具的权限，按需调配参数，把这款智能工具用出最佳的一个效果。 首先我们来看一下 codex 它前端交互界面的一个整体布局，那么在左侧呢是我们的一个菜单栏，在这里我们可以去发起新对话，搜索历史对话以及安装插件，还有就是设置自动化的一些任务，以及和移动端去进行一个打通，那么在这一块呢，我就不做过多的一个讲解。下面是我们项目展示一个区域，我们可以把自己的每次对话都 归类到不同的这样一个项目当中，便于我们后续的一个调用和查看。好，那我们来重点看一下在对话框这里的一个参数设置。 首先我们来看一下权限设置，这里分为四种方式，第一个是默认权限，那这个方式的话，对于我们来说他的安全等级是最高的，风险是最低的。如果说我们是刚开始使用 codex 的 话，那建议我们就直接选择默认权限就可以了。那第二种自动审查的话呢，他是在 codex 运行一些有风险的 任务的时候，他需要我们人为的去授权。第三个就是完全访问权限，那这个方式他的风险等级是最高的。 最后一个是自定义权限规则，我们可以在这个文件当中去自定义，我们对于 codex 在 运行任务的时候必须要遵循哪些安全的一个 原则，这是在这一块。第二个呢，我们是要去选择它的一个智能程度，那这里从低到中到高到超高，它的这种运行速度是越来越慢的，但是它的智能程度是越来越高的，所以在这里啊，对于我们普通 日常办公来说，我们就直接选择中就可以了。还有就是下面的模型，我们可以直接选择这个 g p t 五点五的一个模型。在速度这里呢，我们 建议大家可以直接选标准就可以了，所以呢这里的参数就直接大家在刚开始使用的时候，在权限这里就直接选择默认权限，然后呢智能这里选中 g p t 选五点五的模型，速度选标准就可以了。在下面我们可以选择本次对话 沉淀到哪一个项目当中，这里我们可以根据自己的实际情况选择，那么在后面的它的一个本地模式以及它的一个分支，我们直接默认就可以了。 接下来再给大家分享一个比较重要的 codex 啊，任务执行的一个逻辑，那分三种场景，第一个场景就是我们给他一个任务，他已经在执行当中了，但是呢我们发现之前给他的指令缺少了一些这个要求， 这个时候呢我想加入一些新的要求，让他在输出的时候也要考虑到我新加的要求。那比如说以我刚才这里的为例，我让他帮我整理成一个 word 文档，但是呢我缺少了一个要求，我可以直接在这里添加进去， 直接点击发送。然后呢我们如果想他这一轮的输出，把我这个需求考虑进去的话，直接点击引导，那他就会直接把我新的这一个要求给考虑进去，这是第一种场景，第二种场景就是当他这个任务执行完过后， 我想要它继续执行下一个任务，那这个时候呢，我们就直接在这里输入新的一个任务要求。 好，这个时候我们就可以不用点引导，它在执行上一个任务完成过后，就会自动去执行帮我生成一份 pdf 的 这一个任务。那这里就讲到两个场景，第一个是对于我现有任务的一个补充，它可以把我新的要求考虑进去。第二个呢就是我 给他再给一个新的要求，让他在上一个任务执行完过后，继续去执行我的下一个任务。还有一种场景就是希望他并行去执行我们的任务，那这个时候呢，我们就只需要最简单的在这里去打开一个新的对话， 然后点击提交就可以了，你会发现这个时候系统他会去并行执行我不同的一个任务，那么这个就是我们 codex 在 前端执行任务的时候，他有三种不同的一个方式。 好，那么本期的视频就先到这里，今天给大家分享重点内容就是如何去设置我们的安全等级，选择智能程度以及我们的模型和我们的一个速度。大家有任何疑问也可以在评论区留言， 后续我会推出更加实，后续我也会持续推出在办公场景下一些好用的 ai 使用小技巧，欢迎大家点赞关注加收藏。

codex 的 这波福利实在是太爽了，那些被 cloud 进行 kyc 阻拦的中国开发者可以换阵营了。昨天， openair 发布了 codex 的 重大桌面端更新，这次更新的版本叫做 codex almost everything。 这个版本的 codex， 它说几乎可以完成任何任务，它能够操作 mac 上面所有的应用程序，记住用户的工作习惯和偏好，并且能够跨天跨周期地持续完成任务。 这标志是什么？ ai 的 代理技术已经从简单的 ide 插件的拓展，正式升级到了操作系统的层面。昨天我在朋友圈发了这张照片，有的观众留言说，没看懂， 看了今天的新闻，我觉得你一定会懂。一开始以为不会怎么样，当你真正了用上了 codex， 那 种很爽的感觉就会让你欲罢不能。你就知道，一开始以为只是一次不会怎么样，但是你真正用上之后，你就无法失去它。其实刚刚的那张梗图是来源于这张图。原来大部分开发者是离不开 cloud 的， 哎。现在 opus 四点七刚发，山姆奥特曼就紧跟着把 codix 这个早就准备好的这个更新来推上来，看看谁卷得过谁，都是两百美金的 pro。 codix pro 和 cloud pro 它的使用体验是相差 n 倍的。 codix pro 呢，是量大管饱，而且可以开加速模式。 cloud ops 每次 去开这个模型使用的时候，都要去思考一下这一次任务它的消耗要花多少 token。 我 相信 cloud 刚刚更新的四点七， opus 的 模型是真的强，但是如果希望是使用轻松，不要老是考虑充值的问题。我认为 codex pro 是 一个非常好的选择， 而且再加上对于中国开发者不太友好的 k y c 验证，现在真的可以转移阵营去 codex 了。我们一起看一下 openai 的 官网是怎么说的，你看它怎么说的。 codex for 它为了严谨 almost everything， 它这是一个重大版本的更新啊，它这里说了三个方面的更新，第一个就是将 codex 拓展为 code 之外，它要除了做 ide 之外，未来很可能是想做一个超级应用。它之前向奥特曼在采访的时候就说，希望把 gbt， codex 还有 atlus 三个整合成一个超级的 app， 整合一个应用在这里呢，它增加了一个重大的功能，就是 computer use context， 把 opencloud 的 创始人招进去，绝对不是白招的。 现在 context 可以 协调操作 mac 电脑，配合使用生成图像，生成视频等等操作。而且它有一个内置的浏览器， 它可以在这个内置的浏览器和 web 端进行原声的交互操作。而且它这次也说了，它发布了九十多个新增插件，给大家演示一下怎么打开 context 的 computer use 的 功能。我们点开 context， 在 左边这个位置啊，有一个插件，点击一下 这里啊，选择 open ai 按钮，好，这里就是 computer use， 我 们点击加号安装插件， 点击安装 computer use。 好， 已经安装完成了，现在点击进来我们就可以调用 computer use 进行抽象了。 现在 codex 的 桌面端是最先可以在 mac os 系统上面使用，因为在苹果的系统上面的调试会相对简单和容易的。这也是为什么那个时候我在推荐大家买硬件的时候，大家可以去买一个 mac mini m 四或者是 mac 的 pro 笔记本电脑， 你看优势就在这里。所有大部分功能都会优先在 mac os 上面先推出，因为 windows 的 版本啊，系统啊，确实会比较多，它适配封装啊，事情比较多，一般都会先上 mac os。 除了 computer use 这个功能之外，我觉得这一次更新还有一个非常重要的点， 就是它增加了记忆功能，你看它这里说个性化功能里面增加了 memory 的 记忆功能，这个非常重要。你想有了 computer use， 有 了 memory 的 功能，那未来其他的 agent 还远吗？如果说它再上一个 i m 的 功能， 那我觉得真的可以一定程度上去替代小龙虾了。大家看到我这个 context 的 界面啊，你看这里会弹出一个个性化 context 的 引导，我这里点击 ok， 点击右下角的设置，再点击下设置，点击这里的个性化， 看到下方这个位置有个 memory 的 选项，可以选择这里的 enable memories。 这个功能对于开发者也是非常友好的，它能够记住你的历史篇号，你的纠篇信息，还有你的历史的上下文。第三个我觉得它的重要更新是它的这个自动化能力提升了， 它除了保留之前的上下文，而且它可以自动唤醒，自动续跑去执行这种长期任务。妈呀，我感觉这个 codex 简直是让人有这个恋爱的感觉了，是一个一直成长的陪伴型的伴侣啊， 就是未来啊。如果说它真的把 i m 街上真的是可以替代小龙虾的，现在我是把 openclaw 作为一个总的编排型的 agent 来使用的，它可以去驱动 codex， 驱动爱马仕这样的 agent， 它是可以给我去对话的，而且它的自由度，它的开放度很高。那么如果未来 codex 它的整个的 agent 整个的体验做得很好，而且可以通过 i m 去对话，我远程啊不在电脑边的时候，它也能够帮我去高效地去驱动这种长任务，它的这个未来是真的可以期待的。 而且现在 codex 的 增长数据正在说明这一点，它在今年年初的时候周活用户也就一百六十万左右，现在每周的周活用户是三百万用户，而且山姆奥特曼它的野心是直指我要做到一千万的用户， 不管未来怎么发展，至少这一段时间大家用 context 一定是非常爽的。太多的话我也不想说了，我赶紧去打开，我在 context 去接住这波稳稳的福利。更多的精彩请看玲姐说 ai 的 频道，我们下期再见！拜拜！

代码的目标功能怎么开？什么样的任务适合开？用第三方模型能不能用这个功能？怎么保证目标模式完成的任务的质量？怎么给他权限？ 这是我上个视频评论区关注最多的一些问题。哈喽，大家好，上个视频我发了关于 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 技巧。