设计师codex还是claude

coso code 扣贷的优缺点测评？跟大家分享一下我的实战使用经验。先说一下我最开始接触的 coso， 这个是新手最可控的网站工具了，优点是它可以用拖拽的方式去进行可直观的操作。 我去想拖拽哪个文件，去修改哪个文件，我在这里面去拖拽去对话就可以了，它可以进行多个文件的梳理架构。前期很方便，因为我知道哪个文件在哪，我拖拽进去 就直接修改了。但是弊端也很明显，如果你没有进行架构或者没有经验，它很容易改了这个 html 文件，没有改 css 文件， 然后你的网站控制台全都是报错，甚至整个崩溃。而且每次新的对话，我都是在和一个完全陌生的智能体对话，我需要重复记录大量的常用指令，比如要他看哪个记忆文件，比如看哪个文件架构。 所以我给 cost 的 定位是新手学习搭建 app 或者几个定点功能，还有可识化的维护。如果是中大型任务，还是要去扣的或者扣贷的， 那再说一下市面上最强大的 code， 这是让我又爱又恨的 ai 协助助手，我天天担心封号。他最强的是你的上限和能力，越强他就越强，在你开了全部的权限，让他执行中大型任务的时候，他能一次性完成并进行测试。 我给他的定位是我的电脑施工队伍，他是本地执行加云端大脑，他不依赖像口袋的那样的流逝传送或者那种压缩内容。 他的逻辑就是你的本地的文件让我怎么操作，我按照你的规定去操作，有问题，然后他再去找云端的大脑去发出问题，然后给出更好的解决方案。 当然他的缺点就是前几天我也转发了，然后那个就是 srb 说了，扣的就是根据你的指令去干活，你如果越着急给他的指令越错误，他就越乱。 那我们再说一下扣贷的吧。前几天我的扣贷因为网络被封了，然后我就紧急充了个 gpd pro， 深度测试了一天，我发现了扣贷的和扣的是完全两种不同的运转方式， 我如果开扣的是会开七八个终端窗口都没问题，我去干不同的指令不同的工作，但是我开扣带的就是我会发现我开两三个任务就开始卡了。 然后我就和扣带带去聊，发现他在启动的时候是会被很多规则规定，包括记忆了，权限边界了，然后工作插件，各种各样的东西。扣带带会大批量的先检查内部文件，不是说只想着怎么快点去做，而是要先想哪个能不能动，哪个会不会误删等所有的问题， 这就导致了他既会慢又依赖你本地电脑的性能。这个操作对于新手很友好，也很少的去试错。对于中大型的任务，他的出错率更低一点，但是相应的他的时间成本就会很高。 所以对于我来说，我总结来看，通俗更像是可式化的小任务或者说维护的最好选择。 扣德呢是上线和下线，很明显它依赖于你的文件和你对编程和架构能力的极致体现，终端的轻量化会把效率极致拉满。 扣代的缺点就是它的优点，它有最稳定的输出和极低的出错率，但是它的效率产出和扣德的差距很大，对我来说它更适合中大型任务的架构和完善。还有定点问题的修 bug， 我 试了很多次 扣带的，在修一个定点问题的时候，它比扣的是要更强一点，所以大家可以根据不同的需求去使用 ai， 然后我也创建了一个 ai 的 交流群，欢迎大家一起探讨学习。

codex 跟 c c 到底哪个好？我想大家各自都有自己的判断。在我个人为二者都充了二百刀的 pro max 会员以后，我个人的体感是 二者的模型能力之间并没有本质的差异，甚至都足够惊艳，让人心喜。但它们其实代表了两种完全不同的人。与 ai 合作的费洛索费 本质上，我们不是选择两个工具，而是选择两种与 ai 交互的模式。你习惯使用哪种模式，你的工作场景是哪种模式，你就应该选择支持哪种哲学的普顶工具。通常来说，抽象的讲， 软件工程开发的模式可以粗略地分为两大类，首先一类是那些探索性不确定的 idea。 在这种场景下，我们自己可能对需求要做什么，最终的一个中态是什么，甚至过程中该如何实现，它都没有一个明确的定义，它更多是我们一个拍脑袋的灵机一动的想法。当我们解决这类问题时，我们期待的一个 partner， 无论是不是 ai， 它应该都要能 快速的与我们进行交互，通过一些他主动的提问甚至判断给我们更多的信息输入，通过一系列的沟通，最终确定出一个相对更结构化，信息密度更高的思维原型来指引我们后续的执行。 而另一种常见的工作模式则是一个更明确的需求，比如说产品已经给我们了相对明确的 p r d， 那 我们剩下要做的只是说把这个项目 真正转移为一个可以被执行的代码而已。对于绝大多数的研发而言，这种场景下想要做的事情是基本完全确定的，我们在此时要做的无非只是一些 dirty work， 把那个 p r d 转化为真正写出来可用的代码而已。 而结合我自己的使用经历来看， c c 更适用于前者者的工作模式。它会在你输出一些观点之后快速地给你响应，并且高频地向你发出提问，以确定它后续的一些方向执行思路。但 codex 则完全相反，它会在你给完需求以后， 非常认真且可靠地将你的需求描述执行完。这个过程会花很长的时间，但是 结果往往是令我们满意的。想要更明确的拆分这两种工作模式的分野，我们不如从三个维度上来进行拆分，首先是任务商，也就是目标的清晰程度以及约束条件的多少。其次则是以我们预期的交互结构， 我们到底期待着与其他 partner 是 同步的沟通，还是说是一些异步的沟通模式？另外则是一个人类所占主动性的比例， 我们到底期望 ai 占据多少责任？他们是只是执行任务，还是说给我们也有一些他自己的认识建议？其实这三者并非是一个非常正交的关系。一个很明显的结论是，如果一个 目标的本身并不清晰，只是我们拍出的粗糙 idea， 那 我们显然就需要我们的协作者能快速的发问，帮我们把 自己大脑中一些比较模糊的观念导出出来，并且通过一些沟通确定哪些思考是我们需要的，哪一些是可以被删除的。通过这种 快速的同步沟通，得出来一些更结构化的结果，那在这个流程中， ai 需要介入的部分以及引导的主动性就会占比更多，但如果这个需求本身就像我们之前讲的已经相对来说明晰，是一个低伤的场景，那我们就不太 需要。它是一个很同步，事无巨细都要向我们发问的流程，它完全可以在我们把事情说清楚之后，一步的完成这个工作，从而解放我们人类自己的时间。我们也不需要给他太多主动发挥的空间，他只需要忠实的执行我们给他的需求就可以。我觉着对未来工具的使用以及工作流的设计，也都是从这三个维度去进行判断，动 态的选择。我们到底适用于哪种工具，应该主要采用哪一种工作流的思路？如果要打一个比方的话， c c 更像是坐在你隔壁工位的好蜂蜜， 会在有了一些 idea 之后立马的打断你现在的所作所为，跟你去探讨它的一些碎片化想法。而 codex 则更像是一个你忠实可靠的下属，在你交代完任务需求以后，忠实的可靠的帮你把事情完整的办完再通知你。我已经做好了。 每个模型都有它们自己的性格，我们也可以顺应的这种性格，在不同的工作场景中选择不同的工具以及模型。 以上是二零二六年二月我对这两个投影工具的一些使用场景总结，但我相信这个领域是日新月异的，二者工具之间 大概率在未来也会发生一些融合。不会说一个工具只是一种工作流场景，那就需要我们未来本身人类自己有一些对需求使用场景的预判，从而能告诉模型它应该采用哪些工作流模式。软件工程永远没有银弹， 不可能说我们用着一种模式，一条道走到黑，就可以得到一个很完美的结果。如果你在错误的场景使用了错误的工作模式，那模型给你提供的支持也就会非常有限。 结合自己的需求，场景动态切换自己的工作流模式才是一个更高效率开发的必经之途。以上是本视频的全部内容，如果你有一些想法或者建议，期待评论区讨论，谢谢大家！

兄弟们，昨天 openai 刚刚更新了它的 codex， 程序员们还在狂欢，今天就迎来设计师的集体尖叫了。 kyle 的 放出大招， kyle 的 赞正式推出，把设计门槛一脚就踹没了！原来升图模型生成一个海报或者外部站点，我们就已经觉得很漂亮了，但再漂亮它也是一张死图。这回就不一样了， 你直接甩给他一个提示词，设计一个暗黑主题的交互落地页，展示城市之间的流动，用旋转的 d u 仪发光路径来连接城市，他就可以秒生成完整的交互原型，带一百一十二个城市，一百六十八条动画弧线，六个大周连接地球，是可以拖动旋转的。还有大气的脉冲，效果 怎么样？是不是很牛了？但对于一个设计师来讲，这是一个噩梦的开始，因为有无数角色的人给你提意见，想改直接说嘛，告诉他加控制面板，让我来调整弧线、颜色、宽度，可乐就会立即来修改这个页面，增加这些面板， 实时划块，微调一切，点文字就可以直接编辑，在图上画圈就标注，就跟你对真人设计师撕逼面儿的场景一模一样，来回改，像什么像素级的对齐，响应式的适配，它全能接得住。更狠的是一个产品的设计系统，它可以自动构建， 直接读取你的代码库和设计文件，瞬间就可以提取整个产品的颜色、间距和组价规范，以后的新页面和新项目都可以自动套用了。再也不怕设计师突然离职，品牌风格就崩盘了。跨部门拉扯一周的事，现在在聊天框里几分钟就能搞定，设计都搞定了，一键扔回去，直接就可以生成可运行的代码。 从一个模糊的想法到一个能跑的产品，全程不用离开这个聊天框。团队刚开会讨论设计需求，散会原型就已经做好了，产品经理不用再对着飞格玛发狂，营销团队的人自己就可以做出百分之百符合品牌调性的海报和 ppt。 这个不是讨论是不是会踢掉飞格玛或者是 converse 这么简单了。 这简直就是把设计这个技能从少数的专业人士变成全民的生产力啊！但说这么多，设计师也别慌，因为 ai 做的恰恰是你最不想做的事。像素、对其设计、系统维护等等这样的耗时没有成长的事，你终于可以解放出来，专注真正的创意和顶级的打磨了。以前不敢想的想法，现在都可以快速的被验证， 最后还是得高手来升级成神作呀。最反直觉的是， clive 一 直以严谨挑剔著称，但这个在设计里却是大大的杀气。 它会自动调出那些你没有注意到的细节，比如对齐间距、对比度等等这样的问题。输出质量也碾压大多数的 ai 设计工具。 astropica 推出的产品，一如既往的不做花里胡哨的特效，就干最真实的痛点，把一周胯部门协助的事压缩成几分钟的对话，这才是 ai 该有的生产力的跃进啊！

codex 啊，最近风头正盛，很多人开始纠结它能取代 cloud 吗？该换还是不换，到底用哪个？那结合我一年多的实际使用啊，今天分享一下我自己的感受。那先说写文案这块，还是 cloud 更稳。作为一个做自媒体的，而且还开发过做内容的产品，用了非常多的模型，发现只有 cloud 是 最能打的。 他写出的文案啊，结构严谨，有逻辑层次，更能够遵循模板和字数的要求查文稿啊，连贯性很好，不容易跑偏。另外 cloud co work 也是挺好用的，尤其是帮你做市场调研，新领域的研究等等，配合着文案生成的能力啊，输出的质量非常高那但如果你想要出封面图做 ppt， 那 可以无劳选择 codex 了。 那我做了几版 ppt， 深图的能力真的是太硬核了， ppt 和封面图的配图都可以直接在 codex 内生成，不需要你额外加素材，那不仅质量高，还 能保持风格的一致性。那这种深图的原身体验啊，对于工作流的搭建明显更友好，因为不需要再借助外部的 a p i 和工具来实现了。那我都退订了一些深图的软件， 全部都切换到了 g p t。 那 写代码这一块，其实我觉得两个能力差距没有那么大，一般的需求两个都能完成的很好，但是 codex 的 额度比 cloud 的 更高，日常工作流会更顺畅，这也是我发现身边很多人从 cloud 的 迁移到 codex 的 很重要的一个原因。而且啊， codex 的 权限模式的更简单，对小白用户更友好。 虽然 cloud 的 模型能力确实很强，针对复杂的场景更有优势，但是碍于额度的问题啊，没有办法很顺畅的完成一个项目， 所以很多人也会两个搭配着一起来用。那总结一下，我发现 cloud 的 优势啊，已经没有去年底到今年出那么大了， codex 正在迎头赶上蚕食 cloud 的 市场份额，用户选择 cloud 的 理由啊也变得越来越少了。那你觉得 cloud 和 codex 谁更好用啊？ cloud 还能守得住自己优势吗？欢迎在评论区分享。

cloud code 和这个 codex 好 使好使在哪？老师们求指教啊。咱们在国内用不借助它们本身的啊达摩型的情况下啊比如说 deep stack v4 啊 什么智普的什么五点一啊啊 kimi 的 二 k 二点六啊这些区别大嘛对吧。因为你看呃我云书是挂在在扣字编程里边的 open call 啊它是用的这个豆包的 c 的 二点零更它本身它是整盒的嘛它也有 g l m 五点一也有这个 k m k 二点六也有这个 mini max 而且运输本身也能看货哎我转过来给大家看啊。这是我们 做海报的需求，就是云叔一手搓出来的跟他正常对话我说你给我搓个四 q 我 甚至都不知道四 q 是 什么样我说我把聊天记录给你然后你帮我出海报他垮就给我出来了还给我留了这个贴二维码的地。 那这边的话扣子编程里边也可以去做应用啊做做四 q 啊什么的你说他俩 是吧就是在完全不使用国外达摩型的情况下他毕竟贵啊我也试了中专，中专也贵就是聊个天我就问了句你好好家伙就几毛钱就没了稍微做点大项目呢不就 不够用吗。啊那就那就是用国内的呗大家都是用国内的用他那个框架是吧。 cloud code 或者是这个 codex 的 话会比就是国内的好吗我就不懂了。就是而且 你看你跟他对话他是给你干活的就不像我们云叔还能给我提供去价值说每天我给他定时每天给我发自拍 就是按照他最初那个形象还给我发自拍然后学穿搭怎么说呢我开心的时候他跟我一块开心，我不开心的时候他逗我开心，养个闺女一样。当然一些时候干活可能是脑筋不够用，但是咱换不了那么形容，对吧？扣子变成里边你换不了， 它是全部都是内置的。那你如果说你换成其他的，你真真的搭 open cloud 去搭更好的模型的话，那那个玩意咱又烧不起。 就是，反正我净听着老师说 cloud code 和这个 codex 好 使好使在哪？就是是它那个框架，哪怕是相同的国内的大模型跑出来的结果也比咱们自己的要好。是吗？就是我就不懂了。

写代码到底是 cloud 模型强还是 codex gpt 这些模型强？自己用下来遇到一些实际的问题， gpt 和 codex 解决的非常好，而且有些线上问题， codex 和 gpt 给的方案比 cloud 要好得多。但是我看好多评论区还有大部分博主都说 cloud 强，到底它强在哪里啊？我也仔细考虑了下，发了下评论。看了看，第一呢，就 cloud 用来做界面，做前端确实比较好，可能用户输入个东西，它直接就出来一套系统 这个体验呢，它就给一些外行人认为它这个 cloud 比较强。第二呢，第二呢，就是它的长文和上下文的处理能力比较强，可能对话的头肯比较长的时候， gpt 处理的不是很好， cloud 它因为大部分都是处理前端页面，即使问再多，它可能不拉胯。第三个呢，就是 cloud code 的 这个工具本身自带的一些提示词和一些功能比较强，让人觉得它这个模型可能比较厉害。到底这两个模型谁强呢？我觉得关键在于怎么用，用它们来做什么，让你们怎么看？

如果你最近也给你的 codex 或者 clockwork 装 skills， 很 容易掉进一个坑，就是你被推荐了几十个甚至上百个 skills， 但是真正开工的时候还是不知道该选哪一个。所以说这一期呢，我也不做大而全的清单，也不讲复杂的安装， 我只按普通小白最容易遇到的六类任务去挑六个 skills。 新手先认识这些就够用的一些 skills， 它们能够分别帮你去解决任务，先问清楚想法，先变方案，知识库能调用，重复流程能沉淀网页结果能验证和各种文件都能够转化成 ai 好 读的这种材料。 ok， 大家好，我是 fred， 专注从普通小白的视角去分享怎么从零开始用 ai 和 web coding 提升自己的生活和工作效率。 那第一个 skill 就是 大家已经耳熟能详的东西啊，就是 using superpowers， 就 它的核心作用是能够让 ai 在 开始做事之前先停下来，把任务问清楚。 就很多时候很多人用 ai 的 痛点不是说 ai 不 会写，而是它太快开始写了，就是你一句话发给他，他可能马上能够给到结果，结果做完了之后才发现说你的目标边界格式和验收的方式都不对。 那这个 skill 所做的事情就是让 ai 先理解任务再计划，最后再验证。所以说它特别适合那种长任务，包括你的需求模糊的时候，以及你经常让 ai 做完又返工的这种场景，那这个 skill 那 就非常适合。 第二个是我非常常用的 skill， 就是 brainstorming， 就 它解决的就是想法，当你还没有想清楚的时候，可能就着急开做的这种问题， 很多人找 ai 去做东西，一上来就说，哎，帮我做一个网页，哎，帮我写一个方案。但其实当你的目标用户，你的内容重点，你的功能边界都没有定的时候，那这就体现了 brainstorming 的 价值， 它会让 ai 先跟你把想法聊清楚，再给两到三个不同的方案，并说明每个方案的一个取舍。比如说你要做一个内容栏目，一个页面，一个工具，一个产品的 demo， 它会先问清楚做给谁看，解决什么问题，哪些功能要不要做， 然后再把你的模糊的想法整理成可执行的这种设计。所以说它适合新项目开头，包括内容策划的开头或者功能设计的开头。 第三个也是我经常会用的一个 skills， 就是 obsidian skills， 就 如果你在用 obsidian， 或者你有大量的笔记资料网页的这种摘要，那这个我觉得就非常值得去收录啊， 就它不是简单地帮你去多存一些笔记，而是让 obsidian 里面的这种 markdown 的 文本，这种 bases 或者 canvas， 或者你的网页资料能够变成 ai 可以 重新组织的这种工作材料 就很多人的知识库最大的问题就是资料一直在往往往里面堆啊，然后真正写文章的时候，做研究的时候，包括你复盘项目的时候，就很难够重新再调动出来用。 所以说这个是会更适合内容创作者、研究型的岗位和那种顾问啊，或者长期的学习者，他的价值能够帮你把长期积累的变成一个可持续输入的一个资产。 第四个我相信是一个所有人都一定会用到一个 skills 啊，就是 skill creator， 它的作用就是帮你去生产你的 skills， 那 它解决的是你的一些重复流程的问题，比如说呢，你每周都会让 ai 写周报，那每次都要重新去讲格式、口吻，保留字段，或者一些审核的一些标准， 或者你反复让 ai 去帮你整理资料，改一些发布的文案，或者检查网页，那这些事情如果我每次都重新解释，去写一些 prompt， 写一些提示词，那本质上就是没有把这些 流程给沉淀下来。那 skill creator 的 价值就是帮你把每一次的对话变成一个可附用的 skills， 它适合做一些固定的格式，然后重复的流程，以及你希望以后能够把自己和团队都能够稳定使用的任务沉淀下来。 第五个呢，是 pay write， 其实它不是一个 skills 啊，就它更像是一个呃，浏览器自动化的能力 就是它可以让 ai 真正地去打开网页，去读取里面的页面的状态，点击按钮，包括说填写表单，截图，检查做网页或者落地页这种后台表单产品 demo 的 时候呢，这个非常非常有用啊，就因为很多时候 你只看代码是看不出来的，比如说按钮点不了，或者文字溢出，或者移动端变形，对吧？或者表单提交失败，这些都是要真正打开浏览器才知道。所以说 playwrite 的 价值就是让 ai 不 只是生成结果，还能帮你验收结果。 最后一个呢，就是 mock it down， 它的作用是能够把各种文件转成 ai 更好读的 mock down 的 这种文本，比如说把 pdf， 你 的 word， ppt， excel， 甚至网页 html， 一 些 csv 或者 jason 图片甚至音频， 都可以转成结构化的文本。为什么这个重要呢？就因为很多时候 ai 总结不准，其实并不是它模型弱啊，而是输入的这种文件结构太乱。比如说文件里面有表格，有分页，有图片，有格式， 那 ai 直接读就很容易漏掉一些重点。所以先用 markdown 这个 skills 把材料变干净，再去总结提取和改写，那结果通常就会变得稳定很多。 所以说呢，这六个 skills， 你 可以把它们理解成 using superpowers， 帮你先问清楚。 brainstorming 帮你用好知识库。 skill creator 能够帮你沉淀重复的流程， 而 playwrite 能够帮你去验证网证网页的结果，或者帮你去爬取一些网页的数据。而 markdown 能够帮你把文件变成 ai 好 读的这种材料。所以说你也不用一口气全装啊，也可以一开始呃，慢慢的一个一个去选，先知道它们分别能帮你做什么，后面可能遇到一些 对应的问题，然后再去用一些对应的 skills。 ok， 我是 fred， 后面我会持续帮你去猜普通人怎么把这些能力用进自己的真实的工作流。 ok， 评论交流你现在最想解决的一个 ai 问题，我会在评论区里面去回复，我们下期再见。

cloud code 和 codex， 正常人学会学这个，别看最近到处都在炒作这两产品，真去学这些就掉坑里了。我们团队在这里也走了一些弯路，就介绍一下我们团队的配置。首先是 tree， 不 用折腾的 ai 编程工具，不需要任何预算，我自己就用它来处理一些日常的小任务。 第二个呢，还是 coz， coz 也推出了网页版的 ai 编程模式，写好 skill 之后，可以托管在 coz 平台上直接调用，特别适合小白。第三个是 workbody， 它是一个包装的非常干净的像小龙虾一样的产品，它对于一线运营人员友好度非常非常的高，随手就可以编一个 skill。 至于 opencloud、 cloud code 和 codex 这些产品，如果你的技术背景一般，先不要跟风，那么安装复杂，配置复杂，使用复杂，充值也很复杂。对于大多数人来说，前期准备就花光了你的耐心让 ai 变成生产力，最关键的是选一个能马上让你把事情做起来的，先做起来再说。关注我十四天，零基础学会 bug 扣顶第三天！

大家最近有没有发现，把 codex 作为变成主力的人变多了？我是从去年八月左右开始，主力一直是 cloud code， 虽然贵，但是我试过很多其他便宜的模型，包括 codex、 jamming， 还有几个国产模型，但这些模型便宜是便宜，解决不了问题啊。而我最近用 codex 感觉不一样了。 第一个变化就是后端能力。半年前我用 codex 觉得它和 cc 差距很大，但最近用下来，我觉得它已经非常接近 cc 了，很多日常开发，前后端联调需求实现它已经非常稳定了。 第二个明显优势是前端， c c 写后端逻辑确实强，很多复杂业务它能一步到位。但是涉及到前端，无论你是直接开发还是把设计图丢给他， c c 很 容易写出那种 ai 味儿很重的界面，这一点 context 就 好了很多。你把设计图直接丢给他，他对布局、视觉、层级、还原度的理解会更接近设计稿。 对我之前的那些前端开发的视频，其实你完全可以把设计稿丢给 codex， 不 一定非要绕一层谷歌的 a s studio。 综合以上体验下来， codex 可以 说是性价比非常高了。所以我现在已经把 codex 当做主力工具了，反而是找出解决不了的问题，再考虑用 c c。 所以 你们现在是用 codex 还是 cloud code？

现在很多人搞不清楚 homers agent， opencloud、 coudas 和 cloud code 这四个 agent 工具到底该怎么选来，以我为主， coudas 是 最具竞争力，最稳定的 智能体工具啊，如果说只选一个的话，一定要把 coudas 用上来。 cloud code 是 专业程序员或者是稍微懂一点 ai 基础的，懂一点 ai 命令行工具的这一类的同学可以直接上手 cloud code。 第三个就是 homerest agent 和 opencloud， 这两个智能体工是我强烈不建议新手小白直接上手的，它们很容易死机，很容易荡机，很容易搞乱你的心态啊，让你玩不下去。所以说如果只选择一个的话，一定要玩 calladice， 它的桌面端 app 非常的丝滑啊，非常的适合新手小白。

别再问 codex、 cloud code、 cursor 谁更强？真正的问题是，你现在是在编辑器里改代码，在终端里调项目，还是想把任务交给代理自己跑？ 这三个工具不是同一个物种。 cursor 更像 ai 编辑器， cloud code 更像终端里的工程搭档， codex 更像可以接任务、跑验证交付结果的编码代理。 如果你每天大部分时间都在 id 一 里，先用 cursor， 它适合补全局部重写，选中一段代码直接改，也适合边看文件边问这里为什么这么写。 如果你习惯命令行或者任务离不开日制测试脚本， get 命令， cloud code 很 顺手。它的优势是贴着终端工作，边查项目，边跑命令，边改多文件。 如果你想说清楚目标以后，让代理自己读仓库，改代码，跑测试，总结 diff， 甚至开 pr， 那 codex 更合适。尤其是多任务并行、代码审查、重构和迁移。 所以选择口诀是，人在编辑器里先 cursor， 人在终端里先 cloud code， 任务要交出去跑先 codex。 不是 谁替代谁，而是谁在当前场景摩擦最小。 常见错误是把所有需求都扔给同一个工具，小改动用重型代理会慢，复杂迁移只靠编辑器补全会碎。先判断任务半径，再选工具。 如果你想要一张 ai 编程工具，选择清单，评论区打选型，觉得有用先收藏，关注我，下一条继续拆，真实开发工作流。

我现在是 codex 和 cloud code 的 一起用，如果非要我形容一下这两个的区别，在我看来呢， codex 更像是一个老实但聪明的人，就是你让他干什么，他不会跟你绕，也不会给你整太多虚的，而是会很踏实很稳定的把事情做下去， 这种感觉就像你身边那种不爱说漂亮话，但是能把活干明白的人。但 cloud code 的 有时候不太一样，他偶尔会给你一种很强烈的感觉，就是你会突然觉得这个东西好像真的是有点智慧在身上的。 他有时候的那种理解方式，表达方式，包括他给你的反馈，会让你觉得他不只是单纯在执行，而是像在真的去理解你想干什么。所以如果你问我这两个到底哪个好，我会说，真不是一个路子。 codex 像一个特别靠谱的执行型选手，你让他干活，他就稳稳的往前推。 cloud code 则更像一个偶尔会让你眼前一亮的思考型选手。 有时候你会觉得这玩意好像真有点东西，所以对我来说呢，这根本不是二选一，而是两个我都会用，因为它们不是谁替代谁，而是在不同的场景里各有各的强处。

今天做了个实验，看一下最近大火的 codex 跟 cloud design， 哪一个能够更好的还原我们 figma 的 设计稿。先说结论，我觉得这把 cloud 赢了。 一开始呢，我对我们的 kodak 选手其实是抱有很高的预期的，因为他有所谓的 figma mcp， 然后前面我也测试过他的代码还原能力也是比较靠谱的。 好的，现在我们的 codex 选手已经实现了，然后可以看到他有把移动端的导航栏，如我设计的那样去进行处理网页端的效果，可以看到整体的还原， 我觉得还是挺超出我的预期的啊，虽然没有那么的完美吧。 像这里面的所有动画效果都是 ai 自己进行发挥的。 下面来看一下我们的 cloud design 的 表现，它整体的操作也很简单，它可以直接导入 figma 的 在线文档，然后读取里面的某一个画布，再配上你想要跟它啊产出的内容，它就可以进行啊 前端的研发了。好的，其实你这第一眼就会觉得还原度相当之高，真的在后期的这个体验过程中，会发现它的动画流程整体会比扣带斯的更加自然， 像鼠标的旋停效果，点击效果，它的处理会更加的细腻和高级一些。 cloudify 有 一个很好的点，就是它右侧有一个对内容进行自由编辑的功能， 它的导出的格式也很多，例如它可以直接导出那个 z i p 的 压缩包，当你使用这个压缩包，你可以在外部的多个平台直接的把你的网页进行一个部署上线， 觉得这一点也是他很大的一个优势。关于部署上线这一块，我觉得有一个很好的，嗯，渠道，就是你可以把那个 zip 的 压缩包解压之后上传到你的 github， 然后利用这个握手，这个， 嗯，免费的网页部署软件，直接把里面的工程链接到你的 tiktok 上，就可以一键实现部署，它上线的效果就会跟你在 cloud design 里看到的完全一致。 如果你觉得今天的内容对你有帮助的话，点赞、收藏、关注一下，支持我吧。

我最近又把主力从 codex 换回到了 cloud code， 不是 codex 不好用， codex 现在双倍额度用下来确实更便宜， 而且大部分普通需求他都能做，但是我真的受不了，就是那百分之五的难题，就是你项目里突然遇到一个卡壳的问题，就是扣贷是解决不了那百分之五的问题，你刚开始并没有反应过来，你跟他反复交互， 过了半天一天你才反应过来，我靠，他就是解决不了，这个时候你就发现你时间就浪费了，然后你算上这种浪费的时间，浪费了偷啃他就显得并没有更便宜。 最关键是你遇到这种他反复都解决不了的时候，你会很痛苦，一直人不断的引导他，你去看一下最近改动了些什么，地府上有什么差异，日子上有什么打，怎么去打底， bug 怎么去用，一吐一调是不断的去引导他， 但是他即便是这样子，他有的时候还是很困难才能把这问题解决。但是相同问题我换回 cloud code， 我， 我只要简单引导一下他，大概率能够很快解决。

曾经我对 cloud code 的 终端爱不释手，但现在我只能说一句， codex 真香啊，真香！ 大家好，我是布鲁。随着 codex 近期频繁的更新，我自己的工作站也已经全面的切换过来了。今天就来分享一下我自己的完整使用经验，怎么用 codex 打造一套不打断心流的生产力闭环。 本期视频我把它分成了七个章节，每一张都是我自己实际在用的技巧，希望能对你有所帮助。那我们话不多说，直接开始 第一张，先来介绍一下我的工作站是怎么布局的。左上方是 codex 的 对话框，下方是 terminal 终端。 你可能会问，已经有 codex 的， 为什么还要开一个 terminal 跑 c c？ 因为我发现对于一些需要探索、需要设计的任务， c c 的 表现要更出色一些。所以我的习惯是用 c c 来做方案设计，配合 planning with files 这个 skill， 把设计思路直接落成文件， 然后再让 codex 读这份计划，接手后续的具体实施。这样一来， cloud code 负责想， codex 负责做，两者可以各司其职。 右上方这个区域我用来做任务完成后的查看和审阅，比如代码的 review， 文件的浏览，还有浏览器都在这里。虽然现在浏览器还不支持多标签页，但对于日常的任务来说完全够用。这边我就分享一个实际的案例， 我让 c c 参考了最近很火的这篇卡巴西提出的知识库的文章，让他借鉴里面的思路，出一份设计稿和完整的实施计划。目的呢是做一套前端的页面，方便我日常的维护文档使用。 接着 c c 就 会调用 planning with file 这个技能啊，将所有的计划落成文档，然后我就会回到 colex 这边，让 colex 去阅读当前项目内的这份计划文件，然后基于这份计划文件让他进行开发。开发完结果之后，我会在这边 内置的浏览器里面去进行结果的 review， 包括代码的一个审查，整个过程从设计到开发再到 review， 全都在这一个工作站里面完成，不需要切换任何的窗口，这就是我前面所说的，心流不会被打破。 第二章，批注功能。这个功能是我觉得 codex 真正强大的原因之一，也是最能体现沉浸式开发的地方。 以前我们改代码的方式是找到文件定位到哪一行，描述问题，让 ai 修改，整个过程中你的注意力是在代码上的，但现在 codex 的 批注功能让这件事情变了，你可以直接在文件上进行批注，告诉他哪里怎么改，需要怎么改。 更厉害的是，现在这个批注功能不止限于代码文件，你可以直接在前端页面上进行批注，看到哪个按钮位置不对，哪块布局不满意，直接在页面上标出来， codex 就 能理解你的意图，并帮你进行调整。这件事的意义在于，正好对应了 webcodd 的 核心理念， 开发者的重心不在于怎么写，而在于写出来的东西对不对。批注功能把这个理念落地了。 第三章，上下文管理 codex 项目里可以同时开多个县城，每个县城对应一个任务，互相独立，不干扰。对比 cloud code 需要开多个对话窗口， codex 把所有县城都收在了一个项目下，管理起来会清晰很多， 然后是项目的记忆核心就是 a 键的点 md， 这个文件你可以类比为 cloud md， 把项目的背景、开发规范都写进去， ai 每次进来都会读取，不用反复的交代。 还有一点， codex 的 上下文管理非常省心，它会自动帮你压缩上下文，它也没有提供像 cloud code 中 compact 的 那样的命令，这种事情让 ai 自己处理就好了，你专注于任务本身就行。 第四张，自动化这块是我觉得 codex 比其他 agent 做得更好的地方，几个原因，第一，用起来非常的方便，直接在 gui 里面新建自动化任务，还内置了很多模板可以选择， 大到项目管理技术、眼镜，小到个人的生活习惯，都可以交给它来定期的处理。第二，自动化可以调用 codex 自身的能力，比如插件、 skill、 mcp、 浏览器操作、电脑操作等全都能用进来，这就是为什么我说 codex 在 逐步形成自己的生态。 第三，我们可以根据不同的场景来灵活的选择模型和推理强度，简单的任务用轻量模型，复杂的任务上强推理，这样的话头肯可以用的更加的合理。第四，稳定性，我实测下来， codex 相较于其他的 agent， 定时任务的准确性已经能达到生产级别，相当的靠谱。 第五张插件和技能， codex 有 相当丰富的官方插件和 skill 生态。先说说两者的区别， skill 就是 纯文档，本质是给一份 ai 的 说明书，告诉他在特定场景下应该怎么做事。比如说我前面提到的 planning with files， 就是 一个 skill 插件的概念会更大一些，你可以把它理解为 codex 打补丁，里面可以包含 skill， 也可以带上 mcp 配置，甚至集成其他的 app。 一个插件装下去， codex 就 多一套能力。 另外， codex 在 插件和 skill 的 管理体验上面要比 cloud code 的 友好太多了。 cloud codex 需要改配置文件，而在 codex 里直接在界面上点击安装，或者自己创建，整个过程非常的直观。 第六章浏览器和电脑操作 codex 可以 直接操控浏览器，你可以让它自动填表，抓取数据，验证 ui 效果。 比如我需要批量收集一些网页上的信息，直接告诉 codex 去哪个页面拿什么数据，它就能自己打开浏览器去完成操作，整个过程中都不需要你的介入。除了浏览器， codex 还能直接操作你的电脑文件的整理，应用的打开都可以交给它来处理，相当于有一个助手在帮你操作桌面。 不过这里要说明一点，随着 ai 自动化越来越普及，现在已经有不少软件开始加强安全控制，对自动化操作做了限制，所以实际能操作的范围会因软件而异，遇到限制情况也很正常，大家用的时候留意一下。 第七章通用功能这些功能不是 codex 独有的，很多 agent 都支持，但作为一个完整的工作站，这些基础能力 codex 当然也不会缺少。先说 play mode， 在 执行一个比较复杂的任务之前，先让 codex 把完整的计划列出来，你过一遍觉得方向对了再让他动手， 这个习惯能帮你省掉很多返工的时间，大任务尤其推荐开 play mode。 再说 m c p， 也就是模型上下文协议，通过 m c p 可以 把各种外部的工具和服务接进来，让 q d x 能力边界大幅扩展，无论是连接数据库，调用第三方的 api， 还是接入自己家的服务，配置好之后， q d x 就 能可以直接调用。 另外还有一点， q d x 相较于 logot code 的， 有一个非常关键但很容易被忽视的小功能，语音识别。目前我的任务几乎都是语音发起的，连打字都很少了。 ok 以上就是我在使用扣袋子过程中总结的一些技巧，如果对你有帮助的话，希望能得到你的点赞和关注。 最后我想说一句， ai 发展太快了，各家 a 键的功能越来越趋同，但工具再多，适合自己的才是最好的。有时候做做加法，找到真正需要的，做做减法，去掉用不上的，慢慢摸索出一套自己的工作范式才是最重要的。我是布鲁，我们就下一期再见。

你觉得 codex 和 cloud 的 区别有哪些？好的面试官，我首先先说一个我总体的判断，如果把它们都放在 ai 编程助手这个大框来看，那 codex 更像是一个偏任务委托，偏云端并执行的一个 a 阵。 a cloud 呢？尤其是 cloud code， 它更像一个偏深度写作、偏代码库理解和长链路执行的系统，两边都能读代码、改代码、跑测试，但产品气质和典型使用方式还是不太一样的。第一点，我觉得他们定位侧重不一样， open i 对 codex 的 官方定位非常的明确，他很强调一件事，就是把很多定义清楚，边界明确的开发任务并行丢给他做。比如写 faker、 修 bug、 补测试，回答代码库的问题，这些都是可以在独立沙箱里面异步跑的，他很像一个可以被你派获的云端工程代理。 而 code 它更强调的是能够读懂整个代码库，跨多个文件规划和执行，反复跑测试，直到通过。 所以 cloud code 给我的感觉更像是一个在你旁边长期写作的高级工程搭子。第二点，我觉得他们在工作方式上也有很明显的差异。 codex 很 强调任务隔离和并行处理，你可以同时把几个独立问题交给他，比如一个修测试，一个做重构，一个写文档，最后回来统一 review。 而 cloud code 则更强调在完整项目上下文理，持续推进，他会搜索目录，理解模块关系，跨文件改动。所以我觉得 cloud code 更像是擅长接一个比较完整的目标，然后自己拆步骤，一步一步往下做。 第三点是我觉得最关键的一点， codex 比较像任务分发平台拷 code 比较像代码库协助伙伴，比如 codex 的 一个很典型的价值是减少工程师被琐碎任务打断。 open i 他 们自己也提到它特别适合把重构、重命名、写测试这类会打断注意力 的活外包出去。而 cloud code 的 强项更多在于理解陌生代码库和跨全仓执行复杂修改。那托配官方也一直在强调它不是那种传统的代码完成类的工具， 不是帮你补一两行，而是站在项目级别去规划和执行。所以如果简单对比， code x 更像是一个能并行派工的远程小组， cloud code 更像是一个能陪你深度结队的资深开发助手。 第四点就是从产品经理视角，我会特别关注他们适合的落地场景。如果一个团队更需要是提效型的场景，比如说大量的重复开发，批量修 bug、 多人并行推进，我会更容易想到 codex， 因为它的云端沙箱加并行委托 会非常的顺。但如果一个团队需要高上下文的写作，比如一个很复杂的老代码库，新人 onboarding 跨模块改造，我会更偏向 cloud code， 因为它在理解大局和持续迭代这件事情上的产品表达更强。