pursue goal模式设置失败
你们用 ai 写代码的时候，是不是经常要跟他说继续完成跑单员测试 codecs 呢？最近新出了一个 go 模式，真正解决的就是这个问题。 这两天 open ai 给 codecs 发布了一个新功能，叫 go， 也就是目标模式。很多人第一眼会觉得，这不就是让 codecs 持续干活吗？比如你给他一个目标，他就一直做，不用你反复的手动去输入。哎，继续。 但我觉得这个理解还是太浅了。 go 的 真正意义是，它让 codex 从一个单轮的编程助手开始，变成了长任务工程的一个 agent。 以前我们怎么用 ai 写代码呢？你说一句它就做一轮，它改完代码就停下来等你 测试没跑的话你要提醒它，内存没过的话你要催它。 bug 还没修干净，你还得说一句继续修复。 这其实不是一个 agent， 这更像是一个很聪明的回合制的助手。但真正工程任务不是一轮完成的，比如修一个 fricky test， 优化接口，性能做依赖了迁移。这些任务的下一步啊，往往都取决于你上一轮发现了什么。 比如测试失败了要继续定位，性能没达标呢，要换一个方案，迁移报错了要找一个兼容的路径。而构模式解决的就是这个断点问题。 openahead 对 构模式的定义啊，它是 codis 里面的持久目标，可以让一个县城跨多轮持续的去推进任务，并且提前定义什么算完成，怎么验证成功，哪些约束不能被破坏？注意这个词完成 普通 prom 的是你提要求 ai 做一步给结果，然后停下来。但构模式是先定义目标，再执行，再检验证据，没完成的话就继续完成了，才停下来卡住了呢，就汇报给 broker。 所以它不是一个更长的 prompt， 它更像是一个完成的契约。这里最关键的变化是， ai 开始有了验收的意识。 以前 ai 很 容易说我已经完成了，但你一跑测试啊，发现根本没过。为什么呢？因为它是在用语言判断完成，而不是用证据来判断完成。一个好的购指令，必须提前说清楚六件事情， 最终结果是什么？用什么证据证明完成？哪些东西不能被破坏，能改哪些文件，用哪些工具？每一轮失败之后啊，该怎么去选下一步？ 如果卡住了，什么时候停下来，该汇报哪些东西？举个例子啊，你不要只写优化 check out 的 接口性能，这太虚了。你要写把去靠了接口的 p 九五延迟降低到一百二十毫秒以下， 用 benchmark 验证，同时保证呢， coretonis test 全部通过。如果 benchmark 跑不通，或者没有安全的优化路径，就停下来，并汇报给 broker， 和已经尝试的方案。 你看，这个就完全不一样了，它不是让 ai 更努力，而是让 ai 呢，被目标正据边界约束。从产品角度看呢， go 模式其实是已经把 agent harness 里面的核心能力给产品化了， 目标持久化、任务续保、工具调用、循环测试验证、预算控制和一个主色的汇报。以前这些东西啊，开发者要自己在 ai 智能框架里面去答，但现在它已经变成了 codex 的 一个入口，这说明 ai 编程的竞争逻辑已经发生了变化。 过去我们看 coding agent 问的是它能不能帮我写代码，以后真正重要的是它能不能围绕一个工程目标持续去推进，并且交付到可验收。 真正成熟的 agent 不是 永远不停地去干活，而是知道目标，尊重边界，看证据行动，并且知道什么时候该停下来。 ai 编程的下一阶段呢？不是谁更会写代码，而是谁能够把一个工程目标交付到一个可验收的一个阶段。
粉丝6024获赞2.6万
相关视频
05:16查看AI文稿AI文稿好，我们一起来看一下。 codex 在 最近的一次更新当中，更新了两个特别有用的指令，分别是 go， per side。 那 什么是 go 呢？我们这里呢和普通的模式进行了一次对比，那在正常的任务下面呢，我们知道我们向 ai 描述一个任务，然后 ai 给我们响应，就是单回合的 prompt， 那 这个 go 命令就相当于是长跨度的 prompt。 什么意思？比如说我给他一个任务，我希望他能够进行四十八小时，甚至三天六天持续去进行，持续去烧这个 token， 不 断去烧是烧 token， 注意这个词哦， 就是我们把这头啃放到火里面烧一样，很耗头啃。就是比如说我前两天安排了一个项目给大家开发，他连续跑了大概四点五天才跑完这个任务，那我可想而知就是这个模式是非常耗头啃的，所以称之为 girl， 那 我可以看到，对吧？就是这个命名的，很多人说，嗯，在扣袋子当中，这是我见过发布出来的最重要的东西， 很多人都这样描述，真的太惊艳了。那我也强烈推荐大家看我每期视频去尝试一下。那首先，嗯，你需要把你的这个项目呢更新成这个，嗯，这个最新的这个版本，对吧？这个地方有一个嗯，自然语言描述，比如说如果人家开启了，就直接把这段话复制给这个啊，这个 啊，扣代斯点克林，你就复制它，因为它这个指定是在这个文件里面去开启它开启完成之后呢，啊，就会自动的去就可以存在这一个命令，比如说你现在输入 go， 它就有这个 mini， 哎，通过这个 mini 后面就可以输入我们的提炼词了，这里的提炼词你不能输的很笼统，因为这个任务是长时间执行的，所以你要输入清楚你的交付，最终的交付物什么样才能够算是完成 啊？因为它会持续运行，所以你可以相当于理解你布置的所有任务呢，都要能够去长时间支撑你这个任务，而不是说一个笼统提炼词。帮我开发一个叉叉，对吧？你肯定是不行的，你要给他具体的验收目标，哎，验收到一个什么地步才算完成，对不对？比如说这里有个例子，比如说我希望你帮我开发一个技术项目，那呢？你这个项目就直接在这个边去进行开发， 那你什么情况下算是呃完成呢？你能够可以启动，你能够实现这些东西，并且能够生效，这时候才算完成，对吧？那这是他的一个啊，具体的这个条件相当于你要完成一个这样的具体的结构，再给他去执行，这样他会不断去执行，直到你的 token 耗尽为止。大家举例子，比如说我现在帮我开发一个圆形图，那这个圆形图已经开发完了，对吧？我们就把它打开， 打开，打开，然后再打开啊，这时候还是会去打开我们刚刚这个圆形图，当然我们也可以直接在这里去打开我们这个图图，圆形图，对不对？就是通过我们这种方式，我直接直接打开吧， 打开，你看他这个圆形图就开发完了，这是我的验收目标。很简单，就是他能够把这个圆形图打开，这是我的验收目标啊，能够去加这个图图，你看是不是？哎，比较简单啊，就是这么一个任务，那这个 go 呢？哎，我们讲完了， 我们后面可以大家自己去尝试一下，其实和普通最大不同就是你能够自动去规划，自动去执行，自动去运筹，然后呢能够进行持久化的把这个任务给它，哎，完成就这么简单。好吧，其他的我就不多说了啊，大家自行花费。因为这题的词呢，我们 并不是人去写的，而是由 ai 去写的，就包括我刚刚给大家讲的这个 go 的 题，比如说对你的条件是什么，以及你的这个范围，还有你的这些啊，什么验收标准这些东西呢？我不建议大家一个一个去写，我建议大家只用 ai 生成，比如说你可以帮我生成一个 go 指令相关的这种啊，任务题词就说你再交给这个 go， 那 就跑一天，跑一天之后，如果你觉得这个东西那一套方案行得通，你再把这一套方案附用到其他项目上，比如说我能够用它开发借势本，那我也可以用它开发这个旅游管理系统，我也可以让它开发商务事务管理系统，或者是物流管理系统。一套方案跑通之后，我们可以长期的去附用，对吧？这是我们所做的，对不对？就是 复利，是不是类似复利一样，对吧？就这个是相信自己的财富啊，对吧？不断的去增长，通过这种方式，哎，跑动这个模式。第二个是这个 side， 这 side 就是 说我们有时候在对话的时候，我们在 callix 里面可能更多的是想要临时的开一个分支，对吧？ 我们又不想去开一个工作树，所以呢，我们在不影响主任务的情况下，临时开一个啊绘画上下文的窗口啊，不进行污染原来的上下文，然后进行最小的这种改动，然后进行总结，因此啊，就称之为这两个指令啊。最后我们再总结一下 一个 go 呢，它可以帮助我们长时间去啊，根据我们输入目标去执行，那直到我们通过耗尽为止。第二个呢是 side， 这个 side 呢是临时开启一个绘画，并且呢不影响当前的主绘画进程，然后去帮助我们解答一些问题，并且它是有原来上下文的。那这是这么一个点，比如说我现在呢，哎，我开发完了，对不对？那我这边就直接开启一个 side， 我 先 重新看一下吧， codex， 大家如果注意版本啊，这个版本一定要是对的，比如说我现在这里呢，这个 codex 版本一定是幺四幺二八以上，好吧，幺二八以上，好吧，好，那本期视频全部都用了，我是小刘，我们下期再见。
649程序员晓刘
05:32查看AI文稿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 技巧。
268小梅同学
01:24查看AI文稿AI文稿呃，最近这个 codex 的 这个 go 模式挺火的啊，今天给大家讲一下怎么打开 go 模式，这样点这个左下角设置， 呃，设置进来之后点这个配置，然后点这个 config， 点这个 进来之后呢搜索 f e a t u i future， 然后呢？这这这这里是这样的，然后你把这个 goes 等于处加进去就可以了， 把这个加进去，加到这个 future 下面就可以了，然后再重启一下 codex， 重启一下它，这个它就有 go 模式了。 然后 cloud code 的 话就是你直接更新就可以，更新的话你就你就发这个 cloud update， 更新到最新版本它就有了。我们试一下 go， 就是 这个 site go。
1220李文
00:20查看AI文稿AI文稿解， u p i 发布更命令之后，可老的也迅速跟上。很多时候，我们用 ai 最大的问题是它太容易中途收工，或者让你变成 yes 工程师，任务就是点 yes 更命令就是你可以直接告诉他什么结果才算完成，他会自己做测试，测试发现还有失败就继续修，直到全部通过为止。恭喜你，你可以从左手刷视频变成两只手刷视频了。
3108yes 工程师
03:00查看AI文稿AI文稿hello， 大家好，下班了。呃，今天背景不是公司，是因为，呃，在公司的时候当然车来了，没有来得及录，然后最近一直在高新路的使用 codex， 想要说我们用 codex 尽可能的提高我们开发效率，一个人顶五个人，六个人，十个人，牛马。 呃，然后最近 q 代像现了一个新的功能，叫做 go 模， go 模式 g o a l 目标。然后首先需要你的 c o i q 代 c o i 得在零点一二八版本级以上才可以使用它，并且要在 config 点 t o m l 文件里面把 go 改成 true 才可以使用这项新功能，那这个功能还在实验阶段。然后我理解它特别像是一个升级版的 sub agent， 就是 我们之前。 呃，如果你有完，为了完成某一个目标，你需要开多个 a 阵去执行不同的任务模块，多个任务可以最终为这一个目标服务的话，我们会使用 sub a 阵的模式，但我一直感觉 sub a 阵的模式其实不是很好用。 然后我今天刚好又有一个新的需求，就比较适合，感觉比较适合使用 sub a 阵去进行，但是之前一直是 sub a 阵的效果不是很好，刚好上线了一个 go 模式，所以呢，我打算使用它。 然后我的这个任务背景是这样的，我为了实现一个目标是可以把我的 app 去的它的它的这个，呃， apk 发版去做一个自动流水线 pipeline 以及呢？呃，我的后端可以去管理。呃， 我发版的版本号，这样的话我的 app 是 可以知道我需不需要去 做本地的 apk 更新，然后去请求这个版本号做一个比较，就这个需求，然后 所以它基本上分为三个模块，第一个是 app 端要去做兼容，你得去能够自动的识别，我目前的版本是低于还是说最新的啊？然后呢去给出下载链接，然后去自己去更新下载更新，这是第一个 app 端，然后第二个呢是 后端，后端得去新增一些接口。那肯定是要啊更新我的 a p k 版本记录，然后呢去检查是否需要更新，以及我的后台界面，还需要去做一个发版记录的展示。 另外就是需要在我的云端仓库，我使用的是 git， 然后 git 有 一个 git go 功能，这个功能可以自动地去根据你啊你的，你可以在项目仓库里面去的 web flow 目录下写一个 webmail 文件，这个 webmail 文件里面就声明了你的 pipeline 是 怎么样子的， 然后基本上就是这这这三大块儿后端 app 端还有我的 pipeline 流水线的建立。然后这三个任务，我让抠带写了三份 prompt， 然后一次性发给一个 go 的 上下文，然后去执行，然后大概执行了七八分钟之后， 效果还是很好的，然后基本上就达到一个可用的状态，所以，呃，我觉得这个 go 模式大家可以多多用起来，虽然现在还是一个 experiment 的 状态。对，那今天就录到这里，拜拜。
46凌晨两点半的产物
02:24查看AI文稿AI文稿前些天 codex 新增了 go 模式，可以给他一个目标，让他持续推进。我测试了一下，让他一次新增十个新玩法，结果是新增的玩法都太过简单， 没什么可玩性。于是我又通过指定玩法让他再去新增十个，然后做了一半又卡住了。 虽然确实可以连续工作几个小时甚至更久，但总体上感觉这个模式还是不太好用。 现在来看一下这次新增的玩法。从叠排萧萧开始，一共是新增了十七种新玩法，其中有十三个玩法我都打算直接删掉，因为质量实在不行。也不是说 ai 不 能一下子做出质量可以的游戏，如果提前规划好游戏的各种细节， 应该也是可以做好的。然而规划细节也很花时间，所以我更倾向于先让 ai 做个大致的样子，再根据具体情况 慢慢优化细节，无论如何都需要很多时间才行。当前游戏的玩法已经很多了，但每个玩法的可玩性 可能都不是很高，主要还是对细节的打磨远远不够。我的想法是，在新增不同的玩法时，不同玩法之间的实现可能能互相借鉴。例如新增的玩法 b 里 实现了某个效果，而这个效果也同时适合放在已有的玩法 a， 这样不同玩法间能够互相借鉴， 不断提高游戏体验。刚刚的画面上，把 aip 亮做的玩法都点了一圈，这些都是打算删掉的玩法，因为真要一个个打磨的话， 会严重拖慢游戏更新进度。接下来简单看一下要保留的四个玩法。首先是叠排消消，本质上就是类似洋了个洋的玩法，难度上应该也差不多，大家如果感觉不合适的话我再调整下。一个是方块消除， 听说也是风靡一时的玩法，当前反馈还比较少，后续会继续优化。然后是猜数字，这是 ai 第一批做的十个玩法里的，我个人感觉也算有点意思， 所以就只保留了这一个。最后是箭头迷阵，这个好像也曾有过很高的热度， ai 在 实现时始终改不好移动的效果，还一些小细节，只能我自己想了想实现方法， 让他按照我的方法做才总算做好。从这个角度来说，完全没有编程基础的话，可能还是会比较难。
56幻の小草
05:00查看AI文稿AI文稿兄弟们，我终于找到了 co ds 购的正确使用方式。自从 co ds 上线了购模式之后，我一直在做各种尝试购模式，对头肯的消耗确实很大，我花干了三个一百刀的 pro 五倍的订阅账号跟一个二百刀的 pro 二十倍订阅账号， 然后终于摸索出了 co ds 的 购到底应该怎么用了。刷到这个视频的朋友一定不要错过，我会把我的心得摸索出来的使用方案免费分享给大家。 首先给大家讲一下 go 模式跟普通模式的区别。在普通模式，你提出需求， koether 执行一轮任务结束，等你下次提出新的需求，再开启新轮的执行任务。一般来说，你会根据任务的执行情况，在下次对话去做不同的操作。如果你发现任务执行的有问题，你会在新库页里面去提出问题，让 koether 去修改。 如果你觉得任务没问题，就可以让 codex 去提交，然后思考下一步要去做什么。在 go 模式里面是完全不同的一个状态，你发送的快手会被设成一个目标，后续每一轮 codex 任务都不需要你去关注了 codex， 它会自动一轮轮的去执行任务。在每一轮里， codex 都会去看目标是什么，现状是什么，下一步做什么，然后真的去做这一步。 我把我们平时的任务划分为短任务跟长任务。所谓短任务，顾名思义就是比较简单，耗时比较少的任务。长任务则是比较复杂，可以拆解成多个短任务的任务。 其实没有 g 模式，我们在普通模式下也能做短任务和长任务。先看短任务，在普通模式下，提出任务之后，如果发出的 query 就 只说了任务描述，那 qsort 做完之后，我们还需要自己去验证，或者发验证任务让 qsort 去做。当然，我们也可以在最开始发短任务描述的时候，一次性说清楚怎么验证，发现问题要怎么做，但是否遵循其实还是取决于模型本身。 那在 go 模式下，其实就相当于把依靠模型本身的机制，用工程的手段固定下来，把不确定变成确定。 codeys 帮你做好了状态变更和管理机制，你只需要去提出你的任务，把任务设置成目标，因为它有严格的状态变更机制，不能随便的把目标修改为完成状态。你写进了标准，在没有符合标准之前他就会一直做。 所以目标模式对于短任务来说，会让任务完成的更加稳定。再看长任务，普通模式下，你不管是通过 play 模式规划好，还是通过 openstack 或者 superpower 这种插件去澄清需求细节，然后交给 koops 去做，他往往都会很难一次性完成。 计划会被划分成多个阶段，多一篇集，需要你跟 koops 去配合，逐个去验收推进。那在 go 模式下，你可以配合各种插件或者 play 模式，澄清一些你在意的核心关键细节， 你就可以设置你的目标了。这里 codeys 不 会把你的任务拆成一个个执行清单，而是每次都会基于总目标跟验收标准以及当前已经执行的一个状态去判断下次做什么。 这个机制看着不复杂，但其实有一些问题，特别是在常任务场景下，因为 codeys 的 构模式本身的机制并不是一个突突立色的机制，它不会在底层生成第一步做 a， 第二步做 b， 第三步做 c， 更不会有一个任务队列去管理每一步完成之后自动挑下一步。那长任务越走越久，背化跟工具结果会越来越多。模型不可能把所有的细节原封不动的背在身上，中间就会进行很多次的压缩，压缩天然的就会丢失一些信息细节。 call dice 的 go， 它会提醒模型以当前的状态为准，但是它没有一个内置机制，自动地把关键事实整理进文档里，也就是说， 把关键事实落在外部证据里，主要是靠用户在目标里明确要求，或者在过程中提醒模型去做，那这里就没有那么稳定了。一旦模型没这么做，每次完成一个小步骤，推动新步骤展开的时候， ko 代斯就要重新去分析代码，梳理状态，判断做了什么，做到什么程度了，就会出现长任务后期吞失都肯失控的问题。 这样看， codex 的 构里虽然有了严格的状态变更机制、神经机制、多轮驱跑机制，但在长任务里，由于本身没有工程的机制去做进度管理，就会确实出现一些任务偏离的风险，以及会消耗更多的 token。 所以我把这套使用方式整理成了一套 codex go workflow 的 方案，也推到了 github 上，它不是替代 go 模式，而是跟 go 模式去配合使用。 go 负责让 codex 持续往前推进，这套方案负责把目标验收、标准、阶段记录跟听的条件提前固定好，让长任务跑得更稳，不容易越跑越偏。 最后跟大家实际演示一下这套模式具体怎么用。我自己做了一个 codex 管理者的项目，因为我自己开了多个账号， codex 本身账号登录换号我感觉还挺麻烦的，这项目可以去管理我的这些账号，并且在某个账号的额度用完之后，让我手动切换到另外一个账号上，也支持智能的去切换到最佳账号， 还能把 codex 的 接口去接出来。这个项目整体功能我自己测试已经没什么问题了，但目前 ui 太丑了，我目前有了 ui 设计稿去重做，所以这次打算用 codex 的 go 模式去完成这个任务。 首先打开 codex， 选择这个项目，新开一个对话，然后输入斜杠目标，切换到目标模式，这时候输入框下方会出现目标模式的状态。 接着引入这个 codex go flow 这个 skill 直接用自然语言去描述我们的需求。参照页 ui 设计图，重新开发当前项目的 ui 页面，要求修改后的页面样式组建，配色、字体颜色和出细都对齐。设计图做到像素级还原，点击发送 会生成 go 点 m d 和 go progress 点 m d， 再按照这两个文档持续执行，后续每一轮它都会先看目标和进度，再继续推进，我们等它执行一段时间，最后看一下执行的一个结果，可以看到执行之后的 ui 页面跟原始 ui 页面差别还是蛮大的，整体效果还是比较满意的。
149小梅同学
00:56查看AI文稿AI文稿很多人以为 codex 就是， 你问一句，他答一句，勾模式不一样，它更像你给 codex 一 张任务单，帮我把这个网接做完， 要求能打开按暖能点测试通过，做完再停， codex 就 会围着这个目标一步步看文件，改东西，跑，检查中间不用你每一步都催。 用法也很简单，输入出勾，加上你的目标想暂时继续清掉，就用 pause resume clear。 但记住别说，帮我优化一下，要说清楚做到什么样算完成，怎么检查，哪些地方不能乱改目标越具体， cortex 越像一个靠谱同事。详磊有关注多 ai 资讯和实用方法，记得关注我，我们下条视频见。
11:50查看AI文稿AI文稿今天我们来聊一聊如何让 codex 的 go 命令能够做到完全不需要人工干预的自主开发。是的， 然后我们会聊到像 real loop plan 模式，还有 spec driven 这些高级的技巧，是怎么帮助我们突破传统的对话模式的限制，做到常识的任务执行和复杂的任务执行呢？这个话题很有意思，那我们就直接开始吧。咱们先来说说传统的对话模式到底有哪些问题， 为什么呢？没有办法支持这种长时间运行的复杂的任务，就是在传统的对话模式下面，一旦这个 token 的 数量达到了上限，系统就会强行的压缩历史记录。嗯，那这个时候就会导致一些比较重要的关于目标的描述就会丢失掉， 然后 ai 就 会出现跑偏，或者说直接卡死，对，这是一个非常影响体验的事情。确实，那有没有什么技术可以让这个任务状态能够跳出这个上下文窗口，做到即使重启终端也不会丢失呢？当然有了， 现在的技术，可以把任务的状态保存在上下文窗口之外的一个地方哦，这样的话，不管终端重启多少次，或者说运行多长时间，这个状态都是一直存在的。没错，就真正的实现了无人值守的连续运行。 那这种 agent loop 的 机制和我们传统的这种 chat ui 相比，它到底在哪些地方做了改进？ 最明显的改进就是状态管理这方面，传统的 chat ui， 它的状态是跟着这个上下文走的，嗯，你稍微一滑动可能就找不到了，然后很容易就会断掉，需要手动地去触发，或者说写一些外部的脚本来维持。对，但是 agent loop， 它把这个状态单独地存在了外面， 所以它是支持断点续传的，也不怕重启，直接就可以恢复现场。听起来确实省心了不少。那在执行时长和开发者的操作方式上面，这两者差别大吗？差别很大，传统的 chat ui 一 般都是几分钟，然后就局限于一个短的文本的交互。对，而 agent loop 它是受限于这个 token 的 预算， 所以它可以运行很长时间。那开发者的角色也从这种不断地去发指令变成了一个监督者。 ok， 只需要在必要的时候去做一些干预就可以了。 我想知道到底在哪些场景下面是完全不需要使用这个 go 命令的？比如说我现在有一个特别小的任务，是不是就没有必要用它？ 对，如果是一个非常简单的单轮的任务，比如说你就是让他用 python 写一个冒泡排序，那你直接问就好了。没错，不需要用 agent， 用 agent 反而增加了系统的负担。那如果说我这个需求本身就特别模糊，是不是也不适合？是的，如果说你提的需求是那种极度模糊的，比如说你让他去开发一个背单词的 app， 嗯， 那这个时候 ai 就 会不断地去自询问，自扩展，然后很快就会耗尽你的预算。对，而且它的方向也很难去控制。明白了，那要是这个任务在执行的过程当中，经常需要人来做决定， 比如说涉及到一些商业策略或者用户体验的选择，是不是也不能用这个高密令？没错没错，这种需要高频的人类的输入，或者说涉及到一些商业判断交互设计的这种，嗯，那还是建议手动去做，因为他这个 agent 是 静默的执行的，没有办法实时的去跟你确认。对，可能就会导致决策失误。 如果我现在要操作一些非常危险的，比如说删除文件或者清空数据库，这种操作是不是也不能交给这个自动的系统去做？千万不要因为这种涉及到一些不可逆的操作， 或者说你在 plan 模式里面又错误的欠套了调用，嗯，就很有可能会造成数据的丢失或者说系统的崩溃，对， 这种灾难级的风险是一定要避免的。我们接下来就说一说掌控这个引擎的配置和它的生命周期的控制， 就是我们到底怎么才能通过配置文件或者自然语言的指令来开启这个 go 命令？其实很简单，你只要在这个配置文件的 features 字段里面新增一个开启的指令，或者你直接用自然语言说帮我开启 codex 新增的 go 命令，嗯，就可以了， 但是你改完之后必须要重启 cadx 引擎才会生效。哦，了解了，那如果我在运行这个 go 命令的过程当中，我想要暂停，想要恢复，或者说我想要知道它到底用了多少资源， 有没有什么简单的命令可以直接操作？有啊，你要启动的话就直接输入 go， 加上你的提示词就可以了。嗯，然后它会有一个实时的监控面板跳出来，告诉你它已经跑了多久了，用了多少 token。 对， 那如果你想要暂停的话，你就输入 go pause， 想要恢复的话，你就输入 go resume， 就 算你把这个 ide 关了，或者说你重启了电脑，它也可以从你上次断掉的地方继续跑，没错，非常的方便。 那我们再来讨论一下这个完美自制的 prompt， 它的结构。为什么我们要特别的去关注这个范围边界和严格约束这两个模块？是这样的，范围边界其实就是用来限定它的这个操作区域。嗯，比如说你可以规定它只许动某一个文件，其他的文件一个都不许碰。对， 这样的话哪怕它出了问题也不会影响到整个项目。然后严格约束，就是说你可以规定它必须要用什么版本的库， 或者说明确地写清楚他的代码风格。没错，这样的话就可以最大程度地保证他跑出来的东西是你想要的。能不能举一个例子，就是说这几个模块范围边界严格约束完成定义和垄断机制在一个实际的 prompt 里面是怎么配合工作的？ 可以啊，比如说我们现在有一个任务是要扩展 jason 的 词库到一千个唯一的词条，那这个时候我们的 prompt 就 会是这样的，首先用范围边界限定只许动这个特定的文件，嗯，然后用严格约束规定必须要用原生的 api 来解析， 再用完成定义写明当这个文件里面真的有一千个不重复的词条，并且可以被成功读取的时候才算完成。对，最后熔断机制，就是说一旦他遇到了三次 jason 解析错误，或者说 token 用完了，他就立刻停下来， 这样的话就可以保证这个任务是既安全又高效的。听起来很不错啊，那我们现在要讲的这个进阶功法一， skill 自动化的提示词生成器，它到底是怎么帮我们来解决手写 prompt 又麻烦又容易出错的这个问题的？你只需要用自然语言把你的需求极简地描述出来。嗯， 比如说你就说为项目增加 cohere rank 作为第五个 provider。 对， 然后这个 skill 引擎就会自动地帮你去查找，并且把这些参数、边界条件、完成状态等等这些东西都帮你组装好， 生成一个完整的蓝图。没错，你就再也不用去担心你会漏写一些关键的东西啊，或者说你要花很多时间去调格式啊什么之类的，真方便啊。 那我们接下来要聊的这个进阶功法二，就是这个 plan 模式，它到底是怎么做到把思考和执行分开，然后来提升我们处理这种比较模糊的、比较复杂的需求的能力的？其实 plan 模式它就相当于这个项目里面的大脑， 他专门负责跟你一起讨论，然后产出一个高层的架构设计。对，那这个时候你就可以不断的去跟他互动，把这个方案逐步的细化。嗯，等到你确定了之后，再把这些具体的任务交给购模式去执行， 这样的话就可以保证每一行代码都是在按照这个战略方向在推进，没错，就不会跑偏。那这个 plan 模式在向购模式提交任务的时候，有没有什么一定要注意的工作流？有啊， 就是你一定要先在 plan 模式下面让 ai 把这个开发清单一步一步地都列出来。嗯，然后你要确认它每一步都是你想要的， 接着你要进到这个气闸仓，就是做一个上下文的清洗。对，最后你才可以把这个任务安全地交给购物模式去执行。 如果你不做这个清洗的话，就很有可能会出现这种虚假的激活啊，或者说直接卡死啊之类的问题。没错，这个是非常关键的。我还有一个疑问，这个 spec driven 到底是在一个什么样的场景下面，会比我们传统的这种提示词的方式更有优势？嗯， 当你的这个任务是一个涉及到多个系统模块的这种长城的重构。嗯，那这个时候就算你的提示词写得再完美，也很容易会出现一些理解上的偏差。对， 那这个时候我们就需要用这个 spec driven， 就是 把我们的自然语言的需求通过这个 open spec 的 转换引擎，变成一个非常严谨的无二异性的规格描述。没错，并且我们可以明确定意这个 go 的 唯一的完成的标准。 这样的话就可以确保 ai 在 执行这种非常复杂的任务的时候，每一步都是符合这个架构的要求的。原来如此啊，那这个 openstack 到底是怎么跟这个 go 命令配合来实现这种工业级的全自动的开发流水线呢？ 首先，第一步，我们要在项目的根部路运行 openstack 的 出场的指令，它会帮你植入一个规格生成引擎，然后它会全盘的扫描你的这个项目。嗯，你只要输入一个极简的需求， 它就会自动地帮你生成一个非常严密的叫做 speck md 的 架构调整方案。对，同时它也会生成一个 open speck 的 配置文件的实历，里面详细地列出了每一个文件的修改路径和它们之间的依赖关系。没错， 最后你就可以让 go 命令完全按照这个 spec 点 m d 的 标准去自动地开发，或者说自动地重构你的整个文件架构。我想知道就是面对不同复杂度的开发任务，我们应该怎么去挑选最合适的？这个全自动的开发管线是这样的， 对于那种比较简单的，或者说只是单纯地追加一个功能，又或者是说接入一个独立的 api。 嗯，那你可以直接用 custom skill， 你 只要把你的需求用文本描述一下就可以了，它会帮你自动地补全一些边界的条件，然后直接就可以用 go 命令帮你输出结果。对， 那如果你的需求是稍微有一点模糊的，或者说你要做一些比较复杂的商业化的改造，那建议你使用 plan 模式加上 go 命令。嗯，先通过对话的方式把你的计划完善一下，然后清洗一下上下文，再用 go 命令一条一条地去实现你的需求。没错， 如果你的任务是一个系统级的重构，或者说涉及到很多模块的底层逻辑的修改，那你最好是用 openspec 加上告命令。嗯，先自动地生成一个 spec 点 md 的 规格书， 然后让构命令严格地按照这个文档的状态去逐步地推进。明白了，那我还有一个问题，为什么这三大黄金纪律可以真的让 ai 架构师做到真正的无干预的自制？这三大纪律其实是一个保障，就第一个，你要永远定义终点， 你一定要明确的告诉他什么时候该停下来。嗯，包括你要设置 token 的 预警，不然的话他就会一直跑一直跑，最后把你的预算全部都吃光。对， 然后第二个是谋定而后动，就是你一定要把这个规划和执行拆分开，让人类来负责那些模糊的战略的设计， 然后让这个持久化的 agent 来负责不知疲倦的去实现这些代码。没错，最后一个是信任外部状态，你要习惯把上下文和运行的状态彻底的分开。嗯， 你可以随时的关掉你的终端，让 rufluq 在 后台帮你默默的构建你的项目。对，等你再回来的时候，他已经帮你搞定了， 然后会输出一个 success autonomous looped establish。 好 的，今天我们聊了很多关于如何让 ai 可以 真正地做到无人执手的自主开发。嗯，从这种常识的状态管理，到这种复杂的任务的分解，再到这种全自动的流水线， 确实让我们看到了未来软件开发的一个新的方向。 ok， 那 这期节目咱们就到这里了，感谢大家的收听，咱们下次见，拜拜。拜拜。
30梦花寻影
03:24查看AI文稿AI文稿codex 周活用户四月底已破四百万， openai 新员工 jason liu 把它用成了能持续干活的工作系统。这个人不是普通用户，他是十三 k 星开源库 instructor 的 作者。刚加入 openai codex 团队不久，就公开了一套叫 codex maxing 的 玩法。 简单说，不是把 codex 当聊天窗口，而是把它当一个长期在线、能接任务、能看反馈、能自己推进下一步的 ai 同事。他最核心的做法是不轻易关掉会话。很多人用 ai 问完一个问题，改完一段代码，这个窗口就结束了。 jason 不是 这样， 会给不同工作流建立固定县城，比如一个管日程，一个管开源项目，一个盯社交平台，一个处理团队协作，然后用 command 一 到 command 九快速切换。这些县城可以连续存活几个月，里面沉淀了项目背景、个人偏好、历史决策和沟通习惯，下次再打开时， codex 不 用重新听一遍上下文，就能接着上次的状态往下走。 更有意思的是，他下任务主要靠说，不是靠反复刁 prompt。 他 认为口述能保留完整的思考过程，哪怕想法有点乱，有些细节还没想清楚，也可以直接丢给 agent。 codex 执行过程中，他还会用 steering 插入新指令，相当于人不用一直盯着屏幕想到什么。补一句， agent 继续改方向。这种工作方式的关键变化是，人不再负责把每一步都拆成完美指令，而是把目标背景和判断标准交给系统，让他持续行动。真正让 codex 从工具变成半个员工的是 heartbeats 加 a computer。 heartbeats 相当于定时任务调度器， 能让 agent 按固定频率醒来检查状态。 jason 有 一个 chief of staff 现成，每三十分钟跑一次，自动扫 slack 和 gmail， 看有没有需要处理的消息。判断优先级需要回复，事先提交草稿，但不会直接发出，最终仍由人确认。这里面最重要的边界很清楚， ai 可以 做巡检、整理草和推进，但关键动作仍然留给人审批。 他还举过一个更复杂的例子，做动画项目时，他会把视频发到 slack 审阅县城，然后让 codex 每十五分钟检查一次。如果同事提出反馈， codex 就 根据反馈重新渲染新版本，再回复到县城里。因为 slack m c p 服务器当时还不支持文件上传， agent 甚至会自己调用 add computer， 去点 add file 按钮，把渲染好的文件传上去。这个细节很关键，它说明 agent 不 只是在 api 里转数据，也开始像人一样操作图形界面，补上系统接口暂时缺失的部分。还有一次， jason 洗澡前让 codex 盯着亚马逊客服排队状态，等他洗完澡回来退款，已经到账了。听起来像段子，但他体现的是同一个方向， 只要流程里有可观察状态、有下一步动作，有明确结束条件， codex 就 可以在你离开电脑时继续推进。类似逻辑也能扩展到 google docs 评论、 get up、 pr review、 slack、 审阅邮件草稿等场景。反馈来了，他看，需要改，他改，需要人拍板，他停下来等你。但 jason 最强调的不是让 ai 一 直跑，而是必须有验证机制。 他曾经让 codex 把 python 的 rich 库完整迁移到 rust， 验收条件非常硬，必须通过原 python 库的所有单元测试，测试不过说明任务没完成， agent 继续修，测试通过才算收工。这个思路比单纯喊一句让 ai 重构项目靠谱得多。没有可验证的反馈币，还目标再大也只是愿望。 有了测试、检查、审批、评论这些信号， agent 才知道什么时候继续升收，停止。 openai 这次也把购物模式从实验板转正了，用户只要给出最终目标和验收标准，中途可以查进度、调整方向，也可以暂停。 这个功能和 jason 的 用法正好对上。未来拼的不是谁会写更花的提示词，而是谁能把工作拆成可执行、可验证、可接力的系统。换句话说， ai 想真正上岗，靠的不是一句命令，而是目标、权限、工具和验收机制都到位。 另一个重点是， jason 并不把长期记忆完全托管给平台，他的长期现成都从一个 obsidian vault 起步，里面分 tuto、 people、 projects、 agent、 notes 等目录。 顶层 a g e n t s t i m d， 会写清规则，人员信息变了要更新对应文件，项目推进了要记录进度，代办完成了要同步状态。这样做的好处是核心记忆掌握在自己手里。如果我的视频对你有帮助，请点赞加关注，感谢您的观看！
169大鲸AI
00:27查看AI文稿AI文稿faf 官网竟然连个中文模式都没有，就这还想让咱们掏高价买版权？近日，有细心网友发现，国际足联的官网有英法德日韩等十种语言，却偏偏没有十四亿人在用的中文。如果说是因为国足没进世界杯那还可以理解，但像印尼意大利这些同样没打进世界杯的国家，他们的语言都赫然在列。这难免就不让人怀疑，国际足联是不是 压根就不尊重中国球迷，一边盯着庞大的中国市场想捞钱，一边却连最基本的中文适配都不想做。眼看距离美加莫世界杯开赛还不到一个月，或许国际足联真该给中国球迷一个合理的说法。
547速说足球
01:15查看AI文稿AI文稿codex 刚刚又来了一波大更新，这五个功能是真的在把 ai 接管电脑干活往更深处推。第一，锁屏也能继续用 mac 锁屏之后， codex 还能继续工作，配合手机远程操作，人在外面也能看进度改方向。 第二， appshot 双击麦克的 command 键，就能把当前窗口直接拍给 codex， 把可用文字塞进对话上下文。第三，装面板 go 正式上线，你给 codex 一个目标，它会围绕结果持续推进，特别适合大项目跨几天慢慢跑。 第四，插件团队共享，企业用户自定义好的插件可以在团队之间附用，不用每个人重复配置。第五，高级标注模式，用内置浏览器看页面时可以拖转元素，批量打标注和评论，前端反馈更精准。 说白了， codex 这次不是在堆功能，而是在解决真实使用痛点。上下文怎么进来，任务怎么跑？九团队怎么附用，页面怎么改准。 如果你还把 codex 当成命令行写代码工具，那可能要重新认识它了，它正在变成真正能持续干活的 ai 工作代理。
30ai信息差
03:49查看AI文稿AI文稿我上一个视频说编程的下一步不是辅助编程，而是可托管执行单元。比较有意思的是，视频发出去没几天，这条线突然变得非常明显， codex、 cloud code 以及 agent 都相继上了一个名叫 go 的 功能，用来跑长任务。它们功能上的差异，我给你汇总了一张表格， 不过我发现阿里最近发布的 code 一 零才是把长任务的省略与介入做到了一个新的高度。总体感觉非常适合安排 a 证的团队干活，而且交互体验做得非常好，这可能是目前最好的国产 ai id。 一。 我对扩展一零进行了长时间的实践，两天消耗了一个 pro 账号所有的积分。下面会有四个测试。我使用的是 glm 五点一模型或扩展 auto 模式，每个任务少则二十分钟，多则四十分钟，都有完整从零到一的记录，交互不错， agent 也能力很强。用上扩展一点零的这套 agent harness， 让国产的这些模型也表现出了不俗的效果。 一个 quest 左侧栏是一个任务单元，可并行。 下面我标注了他的整体页面，左蓝导航管理，中蓝绘画流，右蓝产物区，左边能看到任务列表，中间能看他怎么推进，右边能看到知识记忆产物。 第一件我让他做的是 readme 最佳实践研究，因为如果你要做开源项目，要做产品，要把自己的工具发布出去， readme 怎么写，官网怎么写，第一评怎么让人信任，都是需要考虑的。 我们前面是使用 export 专家团队模式来完成这个任务，并且起用了 spec， 这相当于一个任务计划书， agent 会组织团队成员按照这个计划书来做这个长任务。点击 spec 运行，你会看到多个子 agent 的 创建并开始运行， 而且右边有可缩化的画布卡片。在专家全景图可以看到每个子 agent 的 状态。专家团总共有四个成员，有三个调研员，一个全站工程师。三个调研员的角色很有考究， 一个是分析 github 高薪瑞米进行对标采样，一个是搜索行业文章及指南收集，另外一个更厉害，直接去找社交平台经验帖，都是实打实的实践。这三个人组合起来，对同一维度的研究会更加深入且有价值。最后一人负责整合输出 右边子 agent 的 画布，每个上下文都相当于一个聊天窗口，可以实时看到它们的滚动。另外，你还可以切换不同的仕图，可以看到文件最终成果。这些都可以帮助我们审查整个任务执行的中间过程以及产物。 值得注意的是，左侧栏的 quest 可以 同时并行多个任务。 最终的研究报告怎么样呢？我可以很负责任的告诉你，它比任何模型的 deep research 都好得多。如果你不相信的话，可以仔细看一下这个文档， 这与大语言模型直接生成或使用一些搜索引擎生成有明显的区别。当然，能做出这样一份研究报告也并非仅靠这个 quarter agent harness， 这完全是我们最开始提示词中有一份我自己过往做各种主题研究的 md 文档， 那其实是我的一个 skills 里面抽出来的，所以我做这个 readme 研究也完全是我有这个需求。这个文档可以替我省下许多时间。 酷的，还有知识引擎，这玩意如果真的能持续积累，会很适合长线工作。打开 knowledge 面板，自动生成的知识架构规范技术栈，你知道的，写代码是长线工作，做产品是长线工作，做内容也是长线工作。 redmi 任务总共耗费了三四十分钟，后面我们还有三个任务，由于时间原因不再一一演示，因为我把这些任务包含文字和视频，从零到一的写在了一篇文章里，感兴趣的可以去看看。好了，既然看到这了，这里觉得有帮助的话，随手点赞支持一下。想继续看到更多有价值的 ai 实践更新，可以给我个关注，感谢你。看到最后， 对于这个主题有想法的，欢迎评论区交流。
01:23查看AI文稿AI文稿今天分享三个命令，用了之后啊，你的 cloud code 会循环跑，一直跑，并行跑，充分的释放你的生产力。那第一个 log 命令，比如你在用 cloud 做一个网站，不想每次手动提交改了什么，那就输入这个命令，那 cloud 每隔三十分钟就会自动跑一次，帮你去提交代码，你完全不用手动操作，那时间单位支持秒 分钟小时，不限时间的话，默认每十分钟跑一次。第二个 go 命令，这是前几天刚更新的一个命令，那普通对话是你说一步，他做一步，做完就停。而 go 啊，是你设定一个完成条件可靠的，会一轮一轮的自己跑下去，直到达成条件才结束。比如你输入这个指令，他会一直跑，一直修，一直验证， 直到测试全部通过了才停止，适合用来做有明确验收标准的事情。第三个， cloud 杠杠 bg， 以前你给 cloud 扣的一个任务啊，它在跑的时候你什么都干不了，你得等它结束，或者需要新开一个窗口，结果是啊，越加越多，完全找不着北加了。杠杠 bg 就 不一样了。比如你在终端里输入这个命令，那 cloud 会立刻扔到后台跑， 你可以在终端窗口里继续做别的事，你还可以开第二个。第三个，后台任务，步步干扰，想看进度啊，按一下左方向键，就进入了 agent。 五 u， 你可以看到每个后台任务的状态，谁在跑，谁在等你，谁跑完了，按上下方向键啊，可以选择进入任意的 agent 去看详情。按右键啊，就可以回到当前的对话。这个功能啊，可以让你在一个终端窗口里管理多个并行的 agent。 这个啊，也是最近更新的功能，只要你学会了这三个命令啊，恭喜你，你使用可拉扣的能力又进阶了。
629起哥的AI实战
