claude code放宽了吗

微软正在全面封杀克拉的扣子，因为他们发现自己的工程师正在越来越依赖这款来自竞争对手的 ai 工具了。注意啊，不是因为它不好用，恰恰相反，是因为它太好用。这可能是微软第一次发现，虽然员工可能还坐在公司里， 但工作方式已经开始属于另一个 ai 时代了。以前公司管理员工靠的是工资制度流程，但 ai 时代开始不一样了， 因为人每天都在和 ai 一 起工作，你问问题的方式，你写代码的习惯，你考虑问题的逻辑，都会慢慢的被那个 ai 重新塑造。所以谁掌握 ai， 谁就在重塑人的工作习惯。这才是微软真正害怕的地方，因为程序员其实根本不是忠诚于公司， 他只是忠诚于哪个工具更强，谁好用就跟谁走。其实程序员圈子比互联市场现实太多了，工资可以购买员工八小时的时间，但买不了员工的大脑。 未来最危险的跳槽可能是人还没跳槽，大脑已经去了另一家公司。而且现在整个 ai 行业正在进入一个特别荒诞的时刻，这什么时刻呢？就是现在大家越来越发现，这模型能力越接近人类，公司反而越养不起它。 我有一些好朋友告诉我他们公司的一些内幕，说他们公司白天喊着要 out in ai， ai 就是 未来，晚上又偷偷背地里限制员工的 ai 使用量。因为有些老板发现，一旦真的放开使用，可拉多扣的那 token 账单就像失控一样的会呼呼往上涨。 公司又想用，但又怕花钱，一个月下来最后一盒成本。用 ai 其实比多招几个员工成本还高，最后其实都给那几个模型厂商打工了，这特别像什么呢？就像你买了一辆法拉利，结果车装上了个计价器， 每踩一脚油门，财务就在旁边疯狂滴血，所以整个行业都处在一个非常割裂的状态。当然，此时此刻，我还是让我们员工可乐随便用的， 因为你会发现，一旦用过最好的 ai， 真的 很难回去了。但我觉得成本其实不是最核心的问题，真正核心的问题， ai 第一次开始反向控制组织了，以前是公司决定员工怎么工作，以后可能就会变成员工依赖哪个 ai， 公司就不得不适应哪个生态。 这也是为什么微软这次必须断币的真正原因，因为他终于意识到，未来真正的战争可能已经不是模型战争了，而是谁能先占领人的思维入口。互联网时代，人们抢的是流量入口， 移动互联网时代，人们抢的是 app 入口。到了 ai 时代，可能抢的真的是认知入口，或者叫思维入口。如果有一天，你每天八小时都必须依赖某个 ai， 那 你觉得你到底是在替公司工作，还是在替那个 ai 生态工作呢？评论区聊聊吧。

全球最有钱的科技公司，被自家工程师用 ai 写代码烧光了预算。微软最新内部通知，六月底强制停用 cloud code， 全面改用自家 copilot。 原因是太贵了， token 计费暗自收钱，工程师写的越多，公司付的越多。讽刺的是，微软投了 open ai 一 百三十亿美元， 自家 co pilot 还是打不过 cloud code。 微软工程师对 cloud 的 满意度百分之九十一，对自家产品却只有百分之六十，这说明什么？ ai 时代最大的谎言就是便宜高效。真相是谁用谁知道，贵的肉疼，微软都扛不住，中小企业怎么办？

兄弟们， cloud code 又更新了，五月二十八号前后 antherpick 连发四个版本，自动修代码， opus 四点八新模型，后台会话， mcp 优化全是硬货， 三分钟的事，今天给你盘明白。这次更新分三大块，第一，核心能力 code review， 不 仅能查 bug， 还能自动修好，集成了 opus 四 it。 第二，后台会话，用 osune 直接找回丢了的任务，内存占用砍一大截。 第三， mcp 和 c l i 修 bug 提速，照顾 windows 用户挨个说。先说 cold review 质变，以前告诉你这有 bug 自己改，现在一条命里发现问题直接帮你把代码改了， 再加个 comment， 审查结果直接贴 github pr 评论区，团队协助爽翻。重点 os 四点八，更强更快更省推理能力，拉满复杂任务上一个大台阶。还有 fast mode， 小 任务神 token 响应快， 动态工作流，大任务自动拆成小块，多个子代理并行干，效率直接起飞。后台会话，以前后台任务一切出去就没了，心态炸， 现在 resume 直接找回，跑到哪都能接上，内存占用也砍下来了，不用再盯着任务管理器。 mcp 修了个恶心 bug， 断联重连死循环，终于干掉。 cl i 方面，大文件 def 渲染更快，屏幕闪烁修了， windows 兼容性提升，用起来就是丝滑。 几个凡人 bug 也修了。 opus 四点八，思考快报错，历史提示词重复记录企业版安全策略漏洞 从 v 二点一点一五二到 v 二点一点一五六，节奏很稳。说个好玩的事，之前 v 二点一点一五四更新后用 deep sec， v 四的兄弟直接报错，新版多了 system role， deep sec 不 认识，但 v 二点一点一五六你已经彻底修了！ 一行命令升级 n p m i g at entropy a i cloud code at r one 一 百五十六不用回退，不用折腾。 好了，总结，自动修复 office 四点八后台绘画 m c p 优化，每一个都让 ai 编程更靠谱，特别是自动修代码，用过都说好！关注我， ai 编程最前沿，下期见！

微软刚刚宣布放弃使用 cologold， 这是否是 ai 泡沫崩溃的前兆呢？从这次的消息来看呢，有两个原因，一个是公开的，一个是内部讨论的。公开的原因呢，很简单，就是微软希望所有的工程师从使用 cologold 转成自己的 cologold， 拍了它 使用 cologold 无疑视为竞争对手训练模型。内部原因说白了就是微软已经用不起 cologold 了。你想微软是一个年利润千亿美元，市值万亿的巨头，如果连它都用不起了，那普通人该怎么办呢？ 而且现在使用 ai 并没有大规模赚钱，用 ai 做的东西呢，也是参差不齐，有各种风险和漏洞，如果连微软都撑不下去了，那么 ai 还会这样一直火下去吗？

今天 cloud code 自动更新完，会出现一个 api 四百错误，目前的解决办法就是直接在这个扩展里边去把自动更新给它取掉，然后回退到呃过去的版本，呃这里边去回退到一天前重启扩展以后 cloud 就 恢复了。

codecode 刚出了一个新功能叫 workflow， 它让 codecode 从自己写代码变成组织一群 agent 的 干活。我 用它跑了一次 deep research， 二十五分钟，一百零四个 agent 的 二百八十万头客跑完。我只有一个感觉，这项技术可能将成为 anaerobic 继 m c p scale 之后的又一重大创新。其他工作流大家肯定会想到 define code， 但 cloudcode 这里的 workflow 不 太一样， 它是你描述一个任务，课老就会边写一个 gs 编排脚本，把任务拆成阶段，再把不同阶段分给不同的 agent 的， 在后台协调数十到数百个 agent 的 最终交付成果，提升复杂任务的可能性。听着是不是有点像以前的 agent teams？ workflow 把以前临时的 agent 团队搭配固化为代码， 把它变成一个可审计、可附用、可版本控制的东西，而不是每次靠模型可附用、可版本控制的东西，而不是每次靠模型临场发挥。拿官方内置的 dp search 这个工作流举例，主要分为五个阶段。 第一阶段是多维拆解，把你的问题拆成五个不同角度的搜索词，确保后面不会只搜一个方向。第二 阶段是并发搜索，五个 agent 同时去搜，每个角度各自找四到六条结果，互不等待。第三阶段，去虫提取，去虫后最多抓取十五个网页，每个页面提取二到五条可中尾的具体结论。第四阶段，交叉验证，每条结论派三个持怀疑态度的独立去找反证，两票反对就淘汰。 最后是合并综合，把通过验证的结论合并，按知心度排序，写成带来源引用的最终报告。比如我这里用 db research 深度调研了一下 color code 的 最新版的 workflow 功能， 写一篇文章，它启动了这五个流程，最后一共花了二十五分钟，动用了一百零四个 agent 的 花费二百八十万 token， 验证了二十五条声明，输出了完整的文章。接下来让我们看看 color code 的 二十五分钟的成果， 包括 workflow 的 核心定位与 agent teams 的 本质区别，运行是限制甚至内置工作流。 dp search 它也研究得清楚， 完成度很不错。这时候一定有很多人问了，这么玩我的 token 是 不是要爆炸了？多 agent 的 听起来很爽，但没有预算控制，它就是 token 粉碎机。所以 workflow 里有一个很关键的设计，是可以直接在任务里写预算。比如 workflow 一 百 k， color code 会根据这个预测优化运行的数量，每个阶段的深度和最后收敛方式。说了这么多， workflow 如何使用呢？两种方法，一、在提示词里直接提到 workflow 这个词，此时 workflow 会变为彩色。二、使用杠 effort 的 archcode 开启 这样 call 了，就会根据你的任务自动生成工作流程。杠 workflows 可以 查看你当前正在跑的工作流，包括每个阶段的执行情况， agent 的 数量。回到 call code， workflow 这件事，它不是一个新功能那么简单，它是 ai 编程开始从个人能力转向组织能力的信号。 以前我们问一个模型能不能写代码，后来我们问一个 agent 能不能独立完成任务。现在我们要问的是，一个系统能不能组织多个 agent 在 预算内可验证的完成复杂任务。

你们一定一定一定要想办法去用上 codex 跟 cloud code， 我 觉得这个真的是普通人能够用最小的一个成本去接触到目前全球最前沿的一个 ai agent， 就是 大家现在是不是还停留在说，哎，我们大模型有一些啊， cloud 啊，或者说 gbt 啊这些，或者说可能有的同学还在用豆包啊， deepsafe 啊这些大模型阶段，那实际上目前最前沿的一些 ai 落地，你会发现它的 ai agent 跟大模型又相差的非常的大，就是你们没有踏出这一步，你们完全就没有感受到啊。 呃，为什么我觉得说 codex 是 我们普通人最低成本去用上最前沿的东西，反而不是 cloud code， 主要的原因的话是 cloud code， 其实如果你要用上，你会去遇到各种封号啊，用 ip 啊这种形式，对吧？对于你的一个使用的门槛会还是相对比较高的，但是 codex 它不一样，为什么我解释非常解释的 简单的跟大家讲这个事呢？就是它的量大管饱，什么叫量大？就是 token 啊，它的量大，然后呢它又便宜，它不像 codex 一 样，比如说你啊，一个月你去买一个 plus 或者二 max 的， 你用八百多块钱一个月，对吧？你 gpt， 你 不用 gpt， 你 目前你可以在一些公开的一些地方，你可能大概一百八，对吧？你可以买到，你可以用的非常的舒 服。一旦你去下载了一些 code， 一个 codex， 你 会发现你的整体工作流程会完全不一样啊。我们拿产品经理举例， ai 产品经理， ai 运营或者 ai 卷方案举例，呃，拿最基础的一个流程就是调研，对吧？你调研也好，或者说你去做啊，设计，写日常的文档也好，实际上你很大的工作都在写，对吧？那你写你， 你写，你不管用 ai 智能写也好，或者说大模型写也好，都可以，但是 ai 智能它可以去搜搜索你本地所有的一些能力，对吧？你的一些文档沉淀去给它，通过通过充足的上下文，你去给它写出更好的一个文档，同时的话也可以去调用一些 他自己，去调用一些你自己以及沉淀的一些 skill， 对 吧？你去自己只要你能够把一个流程给 s o p 给沉淀下来了，后续沉淀成 skill 之后，你无后续，你只要无限的跟他说，哎，你帮我调用这个 skill 啊，那可能是比如说给你画一个图，写一个 p r d 啊这些，你只要说这句话，它就无限的非常轻松的给你产出符合你要求的这么一个文档出来。 所以说对于你整体的工作的提效是大家没有办法想象中的那么高效的。我已经要求我们公司的人或者说我自己的学员，你们必须要不就用 kol 的 kol， 要不就用 kol css， 你 们必须使用你。 如果说 ai 时代你没有去用这种最前沿的一些 ai 的 agent， 实际上你会发现，哎，你的认知还是在自己的一亩三分地里面啊，那 我没有要营造一些任何的焦虑，我真的希望大家能够用上这些 ai 政策，然后去改变自己的整体的工作方式，因为我们目前我们公司的工作方式就已经变成了 ai， 想 ai 做，对吧？人每天做的什么？跟 ai 对 话， ai 去人去审核，剩下的所有事情都是 ai 做，那你一想你的工作效率提升的会极度的快啊。所以说，哎，我们 这个是真的是我觉得最低成本最快的去提升我自己的一个工作效率也好，或者说我的认知 ai 认知也好，去提升我的 ai science 也好啊，这个产品就叫做 codex， 大家可以去他的官网去下载，非常简单，没有任何的门槛啊。

cloud 又升级了。二零二六年五月二十八日， analytics 发布 ops 四点八。这次重点不是依据更强，而是三件事同时发生。第一， ops 四点八更适合代码代理任务和专业工作，而且更会提示不确定。 ops 说它比四点七更少，让自己写出的代码缺陷静默通过。第二， cloud code 加了 dynamic workflows， 可以 把大型任务拆给几十到上百个并行子代理，再汇总检查。这意味着代码迁移跨仓库改造开始接近从启动到合并的工作流。第三，产品层面也变了，用户可以调 cloud 的 努力程度，反 mode 速度可到二点五倍，成本比之前便宜三倍。但真正值得注意的是边界 project glass wind 里约五十个合作方用 missus preview 找到了超过一万个高危或严重漏洞。所以 antropig 也承认，更高能力的 missus 类模型需要更强网络安全防护后才会全面放开。我的判断是， cloud 正从聊天框变成工程协作者，他更会规划，更会检查，也更需要人类审计。

很多新手用 cloud code， 第一句话就是帮我修一下，帮我改一下，帮我做个功能，这就是最容易翻车的地方，因为 cloud code 还不知道你的项目在哪，问题在哪，哪些地方不能碰，你让他直接开工，他只能边拆边改。 所以新手先记住一个方法，每次开工前，先给 cloud code 一 张工作单，这张工作单不用长，只写四句话，第一，我要解决什么问题，第二，你先去看哪些文件，第三，哪些地方不要改。第四，怎么判断这件事做完了？比如你不要说帮我修登录 bug 这句话，太空 ai 不知道先查哪里，也不知道什么不能动。 你要这样说，我现在要修登录失败的问题，请先看登录相关文件，不要改页面样式，先告诉我问题可能在哪，准备改哪里，最后怎么验证。 注意，这时候还不要让他动手，先让他说计划，等他把问题范围改动文件验证方法说清楚之后，你再让他改。你可以直接说，按这个计划小不修改，不要做无关重构，改完告诉我改了哪些文件，以及怎么验证。 这就是最简单的上下文管理，不是写很长的提示词，而是开工前先让 ai 知道四件事，目标、位置、边界、完成标准。如果任务做得很长，最后再让他写三句话，直接把这三句话丢给 cloud code， 他就不用从头猜。所以，新手用 cloud code， 别急着说帮我改，先给工作单，再看计划，最后小步修改这一个习惯，就能避免大部分越改越乱的问题。

这是瞎搞啊，我真的太震撼了，太震撼了，无以复加，这种心情真的是。呃，具体是什么情况，大家可以翻到上一条视频看一下啊，然后我现在呢，就给大家说一下我为什么震惊啊？就是我给他 我现在用的是 cloudco 的 啊，然后搭载的是 k 米 k 二点六的大模型，然后我给他提了一个理发店会员系统的一个需求，我说你帮我写一个应用 啊，然后从这里开始，呃，我确认了他给我发的一些问题，我确认了以后，然后他就开始做，嗯，大概写了这么多，从这里开始算是代码吧，对吧？写这么多绿色部分就是他最后输出的，对吧？这么多，还挺多啊还挺多，确实挺多的，然后用时 四十四分钟，我想着十几分钟，二十分钟就做好了，没想到用了四十四分钟，没关系啊，可以等，这已经已经很颠覆了啊，这已经很颠覆了。来，我让你们再看一下他做出来的东西是什么？ 这是他做好了啊，密码不用输，直接默认就在上面好了。来吧，看一下这个界面，来，横过来大家看一下啊，看一下这个界面 好看吗？有没有 a i 感？然后来我们看一下它的功能， 然后这里是仪表盘，仪表盘其实没什么功能，它就是展示你当前的一些情况嘛。今日营收，因为这里是一个系统，还没有用嘛。然后收银台，来，点开收银台，你可以输入会员手机号，然后搜索，然后就是各种操作，对吧？ 然后这里有项目，对吧？这个人做了什么项目，完了你给他添加进去，最终结算，结算，对吧？啪，点结算就行了，然后会员管理 啊，在这个都是虚拟的，这是 ai 给你演示的虚拟的，对吧？这里背后还有充值，有编辑，有充值，我点一下，编辑看出来是什么 啊？就是会员的资料嘛，编辑会员资料，然后他还给你分了等级，你看到没有？钻石卡，黑卡，金卡，对吧？还给你分了等级啊？到店次数对吧？然后积分是多少？余额是多少？很详细啊。然后这个是你的 店，店里的一些项目都有哪些项目你可以自己添加啊。这里有添加，看到没有？太震惊了，我真的是太一次都没有修改过啊，这个直接输出就是这样子的，然后我们再看一下他这个财务报表，对吧？你，你后台有什么报表，有什么情况，然后还可以导出，对吧？ 然后员工管理，你有多少员工啊？是谁这样？王店长，李总监，哼，刘，刘首席，张总监，陈首席，这也可以添加员工，点一下看，你可以编辑你的员工资料 啊。我觉得我今天，我明天可以拿着这个东西去找理发店的老板，我说你给我一百块钱就行了，我把这个东西交给你，让你用。 太震惊了， ai 怎么可以这么强大？程序员，我不知道看到这个视频心里会有作何感想，我是一个代码都不会，一个代码都看不懂的人只认得二十六个英文字母， 做出来了，一次都没有改过啊，直接直接出来，天呐。

哎呀，完了完了完了。

想问一下用 codex 和克拉蔻的兄弟们，有没有跟我一样的感觉，就是每天的偷看没用完就感觉很难受，就说现在是周六的，应该是说是周日的凌晨十二点半了，我现在还没睡觉，因为我周六整天 没有去打开我的 codex 和克拉蔻的偷看没有用，我今天晚上必须把它用完我才想睡觉，导致我现在周末都变成加班的状态， 哎呀，整个状态就感觉中了毒一样。我刚才用 i r 去搜了一下酷派斯，克拉蔻的付费用户啊，其中酷派斯里面也可以显示大概是四百万的活跃用户， 付费的还未纰漏，然后克拉蔻的呢，也就百万左右，也就是说如果你用了蔻黛斯和克拉蔻的，已经超过了世界上百分之九十九的人，这个世界上最专业的知识，你可以通过最便捷的方式能够获取到，你会发现能够实现你想要的一些东西，缺少的只有你的想象，打开你的想象，你做任何的事情。

朋友，我求你别去碰 cologold， 真的 碰了这辈子就完了。你会不想睡觉？不想出门，不想搭理？朋友？一睁眼就是 web coding， 玩三角桌，玩计算机，有意思吧？ cologold 这个劲比他们上瘾多了，你下班回家只想打开 cologold， 更可怕是什么？是有些人压根没工作就天天宅在家里，从早到晚的 web coding， 凭着一股劲瞎敲代码，一敲就是一整天。 所以我先把丑话撂这。要是脑子里有那么一丁点想法，有那么一点点创造力，千万别喷他，你一旦上手，你脑子里想要啥，他就能给你做出来啥。 想要个 app 做，想要个网站，没问题，想做个工具，轻轻松松，他没有任何边界。 而且我跟你讲，它还不贵。你要是不想了解 clockcode， 行，划走，别关注我。你要是不想知道怎么把 ai 工具榨到最后一滴价时也行，划走，我给不了你任何东西。别说我没提醒你哦。

企业主忽略了硅谷大厂是在缩减 ai 使用规模。微软取消了对 collab 的 授权，要求员工改成自家工具。优步公司今年才够四个月，就烧光了全年 ai 预算。 更夸张的是，有些公司发现有员工故意用 ai 处理无关紧要的工作，拉高内部使用数据。这背后是经济学上一个经典现象。杰文斯贝顿， 意思是，技术效率越高，人们用的越多，总成本反而可能上升。放到企业 ai 应用上，就是你以为买了 ai 工具能省钱， 但因为用的太泛，维护成本太高，员工培训投入太大，最后的综合成本可能比不用还贵。研究机构预测到，二零三零年全球磁源消耗量会增长二十四倍， 虽然单价在降，但用量增速更快。对企业来说，这意味着 ai 账单可能远超预期。真正能省钱的企业，不是用 ai 最多的，而是用 ai 最精准的。先找到一个准确的高频场景跑通，再逐步扩展，而不是一把锁哈。

这是瞎搞，安装一个 cloud code， 怎么就把那么多人卡在门外面了？那就安装好了，都不能用啊，各种问题。好了，我直接给大家把这个门槛直接击碎，免安装版我已经做好了，粉丝群里自己去拿，拿到以后是这样子的，就这个文件打开， 先不要干别的，把这个打开看一下，我已经把步骤写的非常非常的详细啊，把步骤写的非常详细，按照我这里的步骤去做就行了，不要看这么多步骤，其实很简单，就几步。好吧，所有的步骤操作完以后，进来的界面就是这样子的啊，大家记一下啊，就这个界面 需要装的，兄弟们不要忘了三连啊，不要忘了三连，让更多的人看到，让更多的兄弟们体验到 qq 的。 好吧，用的是国内模型啊，我用的是国内模型。

今天遇到一个事，我觉得很有必要拿出来讲。有一个朋友也在用 obsidian 加 colocost 这套组合管理自己的知识库，今天他想换一下知识库的存放位置，结果一换， obsidian 里面的 colocost 插件就用不了了，但是他电脑上 c l y 端的 colocost 是 完全正常能用的。 然后他的处理方式是什么呢？他去各种群里问，去网上问 ai， 折腾了半天，我当时第一反应就是，老兄你是不是搞错了， 你手里就有一个能读你的配置文件，能看你的目录结构，能帮你排查问题的 coloco 的 c i， 你 直接把你的问题描述丢给他，我换了智酷路径之后，插件不能用了，帮我看看怎么回事，你却跑去群里问，等别人回复你等的那半小时， coloco 的 两分钟就搞定了。 这件事说的不是一个 bug， 说的是一个思维习惯。很多人就是这样，工具已经升级了，但脑子里的解决流程还是老一套，出了问题第一反应还是 发群里说，铁子问别人，我不是在嘲笑我朋友，因为我自己也犯过类似的错。刚开始用 ai 的 时候，我遇到问题也是习惯性的先搜先问人，后来才反应过来，我天天在用的这个东西，他不就是干这个的吗？ ai 工具最大的价值不是帮你做那些你本来就会做的事，而是帮你跳过那些你以前必须经历的弯路。 以前你修过 bug， 得先搜再筛再试，可能折腾一两个小时。现在你把问题描述清楚，直接丢给他，他把你读代码，帮你定位，帮你改。 你要做的就一件事，把问题说清楚。所以今天这个分享就一句话，你已经用上 color code 了，别再用没有 ai 时的方式解决问题。下次遇到任何电脑端的 bug， 先别急着发群里，打开你的 color code， 把问题描述丢进去试试看，大概率是可以解决的。

你有没有遇到过这种事，你花了一个小时写了一个 skill 论文写的很细，流程写的很完整，里面有步骤，有边界，有工具调用， 甚至还有一堆注意事项，结果真正用起来的时候， cloud 一 次都不用。你明明是为了让他少走弯路才写的 skill， 但他好像从来没看见过。 你让他做代码审查，他自己审，你让他做上线评估，他自己评，你让他处理一个本来应该走专门流程的任务，他还是直接开始分析，最后你只能手动敲 skill， 减 name， 把他拉回正确轨道。 这个体验很挫败，因为问题看起来像是 skill 没能力，但真实原因往往更靠前。这不一定是 skill 中文写错了，更大的可能是最上面那一行 description 没写对。 skill 能不能被自动触发，很大程度上不是由政文决定，而是由 name 和 description 决定。换句话说， description 不是 写给人看的简介，它是模型决定要不要打开这份 skill 的 第一道路口。 因为 cloud 在 决定要不要加载某个 skill 之前，并不会先读完整的 skill 文档。他先看到的是一个可用 skills 列表，这个列表很像系统提示里的一张目录，每个条目只给他一个名字和一段描述。 用户请求来了以后，模型先在这张目录里判断有没有某个 skill 值得加载。这个列表里主要就是每个 skill 的 名字和描述，也就是说，完整论文写的再细，也要等模型先决定加载，它才有机会被录取。 你在论文里写了实验流程，写了很多边界，写了大量例子。如果 description 没有让模型在第一轮判断中命中，这些内容都不会进入上下文。 所以 description 不是 简介，它更像是路由规则描述越贴近真实请求，触发概率越高。描述越抽象，越被动，触发概率越低。文章特别强调，这里不是一个硬编码开关，也不是用户提到某个词就必然触发， 它更接近模型基于语义、任务意图和上下文做出的概率判断。最常见的失败有三种，第一种是不触发， 用户说 review my code， 但你的 description 写的是 audio software artifacts， 意思接近，但用户不会这么说，模型就可能错过。这里的问题不是语义完全不相关，而是表达距离太远。 skill 描述如果只使用作者自己的专业词，模型未必会把它和用户的自然说法连起来。第二种是勿触发， 比如你写 helps with coding tasks， 范围太大，几乎所有编程请求都能撞上它，可能让一个本来只负责 docker file 的 skill 被用到普通代码补全测试修复架构讨论里， description 太宽，短期看像是提高触发率，长期看会污染路由，让模型在不该调用的时候也调用。 第三种是 skill 冲突，当系统里有十几个二十个 skill， 边界重叠就会放大， 模型不知道该选哪一个，最后可能选错，也可能干脆不用。尤其是多个 skill 都写着 code review， debug， audit， fix 这类词的时候，路由边界会变得很模糊。好的 description 不 只是要吸引触发，也要主动说明自己。不管什么 文章最有价值的部分是那组实验，作者做了六五零次自动化实验，同一个 docker file 只改 description 的 写法。 这个设计很关键，因为它把变量压得很干净。 skill 正文没变，任务没变，只看入口描述怎么影响模型是否调用。这样得到的结果才真正能说明 description 这行文本本身的杠杆。 a 版本是被动式，大概是 use when you need docker fire help。 b 版本加了更多触发词，但语气还是偏被动。 c 版本改成指令式， always invoke this skill when。 再加一句， do not solve this directly without using the skill。 三者的差异不是能力，而是路由信号的强弱。 a 向建议， b 向扩展关键词， c 则明确告诉模型，这类任务不要自己直接做， 结果差距非常大。在一些测试条件下， c 版本出发率是百分之一百，而版本在裸环境里还可以，但加上呼克之后，触发率掉到百分之三十七，这说明出发不是一句有相关内容就够了。 模型会权衡当前任务系统里其他信息，以及自己能不能直接完成 description， 如果不给出足够强的调用理由，就可能被默认行为压过去。 也就是说，同一个 skill 只改 description， 触发率可以差出很多倍。入口描述写法决定 skill 有 没有机会被模型看见。这里最值得记住的是，成功完成任务不等于 skill 被调用。 cloud 可能不用 skill 也能把事做完，但这会绕过你写好的流程检查清单和工具约束。真正要优化的是自动调用，而不是最后。答案看起来还不错，这里还有一个容易误判的点，很多人以为如果 skill 不 触发，那就加 huke 强制提醒， 但实验结果反而说明 hook 不 一定救你，它可能让模型看到更多干扰信息，反而把判断搞乱。所以顺序应该反过来，先把 description 写准， hook 只应该是最后的兜底。 换句话说，不要用更复杂的机制去弥补一个入口描述本来就不清楚的问题，那 description 到底该怎么写？文章给了一个五层框架，第一层写清楚这个 skill 做什么，第二层写清楚什么时候出发，第三层写清楚什么时候不要出发。 这三层解决的是边界问题，它负责什么，什么情况必须用，什么情况不要抢。很多 skill 只写了第一层，所以它看起来像说明书，却不像处罚规则。 第四层是改成指令式语气，比如， always invoke this skill when the user asks to address power review comments。 再补一句， do not inspect or patch review feedback directly before loading this skill。 这不是为了凶，而是为了降低模型犹豫。模型默认会倾向自己处理简单任务，你要明确告诉他，在这个任务类别里，先加载 skill 才是正确路径。 第五层是同理心，把用户真正会输入的话写进去，用户不会说 perform artifact audit， 用户会说，帮我看看这个 pr 评论怎么改。 description 要贴近这种语言，最好的触发词不是作者脑子里的抽象分类，而是用户真实会打出来的句子。 把这些话放进 description 模型，才更容易在第一轮判断里把请求和 skill 对 上。如果你今天只做一件事，就去检查你自己的 skills。 先看 description， 不要先看中文。把那些 helps with useful for assists with 改掉， 换成更具体的任务，更真实的用户说法，更明确的触发边界。然后准备十五条提示词，里面放一些应该触发的，也放一些不应该触发的， 该触发却没触发就补。真实触发词，不该触发却触发了就补 when not。 如果和别的 skill 抢任务，就把边界写窄。 最后再问五个问题，他做什么？什么时候必须用，什么时候不要用？遇到任务时要不要优先调用？用户会用什么话表达这个需求？ 你会很快发现很多 skill 不是 能力不够，他只是从一开始就没有被模型正确看见。

兄弟们，今天聊 cloud code 里一个看起来很普通，但其实很关键的东西， workflow。 workflow 这个词太容易被低估了， 听起来像公司会议里常见的那种词，什么拉其流程沉淀、方法论形成闭环。可在 cloud code 的 里，它不是 ppt 里的箭头，也不是一句你先这样再那样的提示词，它更像一个 do agent 调度台。 以前我们让 clock code 做复杂任务，通常会这样说，先帮我看代码，再检查安全风险，再看看测试够不够，最后给我修复建议。 听起来很清楚，但问题是，这仍然是在跟模型商量。模型今天可能认真拆成五步，明天可能两步就糊完。 你以为自己给的是流程模型，听到的可能是自由发挥。 workflow 的 价值就是把自由发挥写成代码。 它会明确规定第一阶段做什么，第二阶段做什么，哪些 agent 可以 并行跑，每个 agent 必须输出什么格式，最后由谁汇总，怎么去种，怎么判断优先级。这件事的本质变化很大。 普通 prompt 是 一次性沟通， workflow 是 可附用的工程资产。今天它可以省这个仓库，明天换个仓库继续省。今天做 pr review， 明天做安全审计。 如果流程设计的好，别人还能直接拿走复用。你不再只是拥有一个神奇提示词，而是拥有一条可以反复运行的生产线。它和 cloud code 理应有的能力也不冲突。 surveillance 更像临时谣人，适合眼前有个问题，叫一个 agent 看日制，再叫另一个 agent 看模块。 它灵活，启动快，但也灵识。今天这么拆，明天可能换一种拆法，不适合沉淀稳定流程。 agent teams 更像多人协助工作台，多个角色可以一起工作，人类可以观察调度接管， 它适合交互式协助，也适合长期复杂任务。但如果你要的是一条可以重复执行的流水线，它仍然偏人工调度。 skills 则像能力包，它告诉模型什么时候用某个专业方法，参考哪些文件，遵守哪些限制，调用哪些工具。 skills 解决的是会不会做， workflow 解决的是按什么顺序做，谁来做，怎么交付。一个像菜谱和工具箱，一个像后厨的出餐流程。 所以 workflow 最适合的场景不是随便问一句问题，而是那些你会反复做，而且每次都希望质量稳定的任务。比如大代码库分片审查， 你可以让一个 agent 专门看正确性，一个看安全，一个看性能，一个看测试覆盖， 最后让 agregator 汇总去中，按风险排序。再比如 pr 多角色 review， 让不同 agent 同时检查行为变化、安全风险测试缺口和 api 兼容性，最后输出 blocking 和 non blocking findings。 再比如生成批评修复流水线，第一个 agent 负责写出稿，第二个 agent 按标准挑问题， 第三个 agent 只修被指出的问题，最后再做一次验收，这样内容生产就不再是一把缩，而更像一个小型审稿。流程还有深度研究， 不同 agent 分 别看官方文档、论文、社区讨论和代码实现，最后有 synthesizer 生成结论。这个过程如果只靠一句自然语言提示，很容易漏步骤，写成 workflow 才有机会稳定复跑。 怎么起用？设置环境变量 cloud 口打 work flows， 等于一进入后输入 ultra work， 看到彩色就配置成功了， 但这东西也不能闭眼充，尤其是现在这种实验能力，更应该先深层脚本人工看一遍，再小范围运行人工负荷。每个 agent 都要求结构化输出，最终产物也必须检查， 不要把一个还没验证过的隐藏实验能力直接接近生产线。我觉得 workflow 真正重要的地方不是又能多叫几个 a 阵，而是他把 a 阵编排变成了代码， 复杂任务可以复跑，优秀流程可以共享，多 a 阵切磋从临场发挥变成脚本化结构化 可观察的工程流程。未来高手之间拼的可能不再只是我的 prompt 多神，而是流程怎么拆， agent 怎么分工， steamer 怎么设计，聚合器怎么判断，优先级产物怎么复合，这才是从会用 ai 慢慢走向会管理 a i。