怎么让agent编译中文码
警告，本视频耗时一个月，制作共计七百二十小时，主要是针对向转业的程序员学习的，这应该是抖音仅有全套系统猜大模型教程。今天讲让 agent 写的代码上生产。 agent 写的代码 为什么很多时候能翻译却还是不能上线？我今天就想围绕这个问题跟大家讲一讲，怎么让 agent 写的代码真正能够运用于生产环境，更多 ai 大 模型学习物料可在这拿走。大家好，我是彭宇。 我们先看第一个最关键的点， agent 的 能力大家其实都见过，他很擅长什么呢？他很擅长快速生成代码，股价补一些常见逻辑，按照语法规范把代码写出来， 甚至局部效率提升的非常明显。可是问题就在这，生产环境真正关心的从来不只是能不能变异。生产环境关心的是业务语义对不对，项目里的那些隐性规则有没有遵守，异常和边界是不是完整， 最后是不是还具备测试、回退和追踪的能力？也就是说， agent 可能把代码写出来了，但这个代码是不是对的，是不是稳的，是不是可交付的，这才是更大的问题。 那为什么会这样？原因其实不复杂，很多 agent 的 失败不是语法失败，而是几类更隐蔽的失败。第一种，规则不知道，他不懂这个项目里那些没写在文档里的约定，不懂业务边界。第二种，上下文漂移，刚开始还挺对，做着做着就偏了，前面讲过的约束，后面就忘了。 第三种，自我审查盲区，他写完再看一遍，觉得没问题，但其实逻辑漏洞已经埋下去了。第四种，反馈不闭环，出错了以后，没有一套结构化的定位、修复和回退路径，结果就变成反复式、反复错。所以你会发现，问题根本不在于 agent 不 会写代码，而在于他缺少一套外部的约束验证和反馈系统。 那怎么解决？核心思路就是一句话，让生产级 agent 等于 model， 加上 harness。 什么意思呢？模型负责生成，但 harness 负责把生成变成可控交付。 harness 里面包含什么？包含约束验证、反馈、沉淀，也就是说，不是让 agent 自由发挥，而是让它按工程化的方式做事。模型像发动机， harness 才像整车的底盘、方向盘、刹车和仪表盘，只有发动机没有这些结构，车是跑不稳的。 再往下看，这套 harness 怎么搭？比较典型的做法是在项目根目录下建立一个点 harness 目录，把 整个工程里的 ai 协助能力变成一个结构化资产。这里面会有几块？第一块是 rules， 也就是规则，像工程结构架构、约束、业务边界，这些必须明确下来。第二块是 skills， 也就是一组结构化的 sop， 差不多九个左右， 让 agent 知道不同场景下怎么做。第三块是 knowledge， 知识库，按需查，不是一次性全塞进去。第四块是 change log， 变更记录，全流程留痕，后面每一步为什么做，出了什么问题都能追踪。在网上会定义一个 application owner agent， 它相当于整个编排中书，负责把规则、技能、知识库、变更、记录、质量、门禁这些东西全部串起来。这样一来， agent 就 不是单点写代码，而是在一个系统里完成开发。 接着说流程，真正要让 agent 生产可用，就不能只靠一次性的生成，而是要把开发拆成十个阶段。比如先做需求理解，再加载上下文，然后做方案设计、任务拆解编码，实现自测，构建独立评审，质量门禁修复回退， 最后把变更沉淀下来。这里最关键的不是有十步，而是每一步都要有明确的出发条件，要加载什么 skill， 要过什么，质量门禁失败后怎么回退？这样一来，出问题的时候，不是整条链路一起崩，而是能精确定位到某一阶段。 还有一个很重要的设计，就是编码和凭证分离。为什么要分开？因为如果同一个 agent 既写又闪，他很容易陷入自我确认的盲区，自己觉得对， 实际上漏了逻辑问题。分离之后，一个负责实线，一个负责审查，再配合质量门禁，整个链路就更稳。那质量门禁怎么做才有效？关键是四个字，机器可验。不要停留在我觉得差不多看起来没问题， 而是要让门禁变成可以程序化验证的东西。比如编辑必须通过，单元测试必须通过，接口契约要对，静态扫描也要过，这样才能把感觉对了，变成机器验证过了。你看右边那个流程图，本质上就是在说， coding agent 负责写 review， agent 负责独立审，最后再交给 quality gates 去自动验证。这个设计特别重要，因为它把写代码和确认代码正确彻底分开了。 再往下就要讲上下文管理这个地方很多人容易忽略，但其实非常关键，上下文不是越多越好，而是要分层管理。 第一层是绘画常驻上下文，这里放的是身份、总目标、大局约束和核心原则。第二层是阶段触发上下文，比如一进入设计阶段、编码阶段、评审阶段，就加载当前阶段需要的 skill。 第三层是按需查询上下文，也就是知识库和历史案例，不是一直塞在 prompt 里，而是需要的时候再查。这样做的好处是什么？就是减少噪声，保留约束， agent 该看到什么，在什么阶段看到什么，都被控制住了，它就更不容易跑偏。 然后说落地经验，这个体系真正跑起来有四个动作特别关键。第一，先用虚拟需求空跑，不要一上来就拿真实需求硬上，先把整个流程跑一遍，排查流程里的缺陷。 第二，质量门禁必须可验证，也就是说验收条件不能只写成人工判断，必须能被测试、扫描脚本检查出来。第三，小需求也走全流程，这个特别重要，因为一旦小需求开始跳流程，整个体系很快就会失真。 第四，文档要随着实战问题持续迭代，每次真实问题出来之后，都要沉淀成规则、 skill、 返利或者知识库内容。所以这套体系不是写一份静态文档就完了，它更像一个随着项目不断进化的工程操作系统。 再看效果，这个案例里，项目的 ai 代码率从百分之二十四点八六提升到了百分之九十点五四，但更重要的不是这个数字本身，而是它带来的结果，返工明显减少，人工确认轮次也降下来了。最后，项目知识还沉淀成了一个活的开发手册。所以你会发现，真正提升的不是代码生成量， 而是整个交付链路的质量。代码写出来之后，能不能更少返工，能不能更少人工盯着，能不能形成可付用的经验，这才是 harness 的 价值。 最后我们做个总结，如果你想让 agent 写的代码真正上生产，不是单纯去追求它更会写，而是要让它在一个可控的系统里写。这个系统要有约束，要有验证，要有闭环。也就是说，错误要能提前拦住，错误要能被发现，错误还要能被修复。所以，生产可用的本质就一句话， 不是让 agent 变得更自由，而是让它在工程化约束下变得更可靠。 agent 的 上限不只取决于模型能力，更取决于 harness 设计。
粉丝5456获赞2.9万
相关视频
02:56查看AI文稿AI文稿兄弟们，我又来了，我是没有想到呀，昨天我发了一个抖音，没想到评论区惊现了一位大佬在推广他的编程智能体，我就下载了， 于是我今天就试了一下，就是他 deepsea renaissance， 他 是 deepsea 原生的代码智能体，这个作者游戏出身，代码功底应该非常的扎实， 整个架构也非常非常的厉害。他有一个非常省钱的技术，就是可以让大量 token 乖乖的命中缓存。而这边呢，就是这两天比较火的 deepsea， 它虽然支持中文，但是呢不是原生中文，有的时候呢会不太方便。另外我使用下来，这个 token 消耗还是比较大的，我甚至都不敢用 pro 模型， 但是他从设置到配置全部都是中文的。他有一个我非常喜欢的地方，就是这里有一个 web 界面，我打开给大家看一下， 在这里大家看到了吗？这里我的对话是同步的，这里 这里是一个突兀的镜像，这边这里也可以实时的去调整一些强度啊，模式啊之类的， 然后这里有很多的，你可以去设置，这里可以获取余额啊，比如说像这里，我今天小跑了一下，那缓存的命中率是百分之九十五， 非常的强大。还有工具啊，基本上呃该有的都有了，非常好用， 虽然没那么火，但是我觉得这个项目的潜力也是非常巨大的。另外给大家看一下这两个呃， get up 的 地址，这个是兔翼的， 这个是 reasonx 的， 我个人觉得这个名字取得非常的不好，如果叫做 deep sea， cold 之类的名字，可能会比现在要火的多啊。哦，这是吐译作者，这是经常出现在新闻上 这个 reason 的 作者主页，他，他是游戏出身的，这是他做的一个框架，应该是一个关于游戏的，这是一个游戏框架， 这个作者大部分项目都是 ps 研，推荐给大家，大家可以试一试，支持国产作者。
330生活的临时工
00:48查看AI文稿AI文稿想不想让你的 codex 越用越聪明，越用越懂？你把这段提示词发给你的 codex， 它的效果啊，是经过 openid 总裁认证的，算是官方认可的优化方式。它的核心的优势是让你从给一个任务，让它帮你完成这个阶段，变成让它自主的去进化。这个提示词可以让 codex 回过头来去看你这段时间的一个工作记录，你最近让他干什么活， 哪些事情是反复出现的，哪些流程每次都差不多，哪些任务明明是可以不用手动重复。结合这个提示词，它自动可以把这个工作分类，有适合它自动帮你做成 still 的， 比如说你固定的内容创作流程，资料的整理流程， ppt 的 生成流程。还有一些适合做自动化的任务， 比如每天定时收集些信息，整理日报，生成代办。所以这个提示词真正有价值的地方，它不是让 callles 再帮你完成某一次任务，而是让它反过来去分析你的工作方式，帮你发现哪些事情以后可以流程化、标准化、自动化，相当于针对你这个助手完成一次整体的系统升级。
8051六叔ultra
08:33查看AI文稿AI文稿今天咱们要聊的是 cloud code 里面的一个新功能，叫做 workflow， 嗯，这个功能可以把企业的标准操作流程 直接变成 javascript 的 控制脚本。错了，这个功能其实还挺有意思的，那我们就直接开始今天的讨论吧。咱们先来说说这个 workflows 最早是怎么被发现的，因为它一开始其实没打算公开亮相的。对，那它到底是怎么被大家发现的呢？ 其实最早是在 cloud code 的 v 二点一，一四七和一四八这两个版本的更新日期里面，短暂的出现过 worksloads 的 描述，但是很快就被删掉了。嗯，不过还是被一些比较细心的用户发现了。 哎，那看来还是逃不过大家的火眼金睛啊。除此之外，还有哪些比较关键的节点让他曝光了呢？对，就是有一个 github 的 用户叫 ray mjed， 他 还专门发布了一个仓库，叫做 workflow creator。 嗯，里面就是说这是一个预览版的还没有发布的功能。 然后还有一个叫 ai 超元域的用户，他是做了一个全球手册的视频哦，然后包括一些安全研究员，比如说 daniel missler 都在 x， 也就是以前的推特上面进行了讨论。明白了，那现在这个 workflows， 它到底处于一个什么样的阶段呢？ 现在还是处于一个预览的阶段，就是没有任何的官方文档，然后也没有正式发布 ga， 所以 大家想要去玩的话，可能还是要多摸索一下。 好的，那这个 workflows 在 整个 cloud code 的 生态里面到底是处于一个什么样的位置？它跟之前的 skills 和 calwork 还有 mcp 相比，有什么独特的定位吗？可以这么说， skills 和 calwork， 其实它们已经是在往步骤化的工作这个方向去努力了。对，但是 workflows 它更进了一步，它主要的目标是把企业里面那些经常会重复出现的，有标准流程的这样的一些工作，变成一种非常规范的， 可以重复执行的确定性的这样的一个流程。没错，它强调的是把企业的 sop 真正地落地到每一个细节里面。 这么说的话，感觉它确实比其他的那些工具更适合用来做这种企业级的自动化的场景啊。 是的是的，然后 mcp 它解决的是如何连外部工具的问题，而 workflows 它解决的是如何让 ai 有 纪律可重复的执行问题。没错， 如果我们再拿 sub agent 和 skill 来做比较的话， sub agent 它是属于那种，你把任务丢给它，它就立刻开始做，而 skill 它是把一些能力打包起来。那 workflows 它更像是一个指挥家，它会按照一个设定好的剧本去调度这些能力 哦，所以它的整个定位是非常不一样的。懂了懂了，那接下来我们就来看看这个 workflows 要怎么激活现在这个预览版，它的激活方式有什么特别的地方吗？其实很简单，你只需要在你的环境变量里面， exports， cloud underscore， code underscore， workflows 等于一，然后你打开终端，输入 ultra work， 它就会出现一个彩色闪烁的提示，你就可以启动了。 嗯，但是要注意哦，这个环境变量和这个 u x， 它可能在未来的版本里面会有一些变化。好的，那 workflows 和 sub agent 相比，在技术实现上面最大的差别是什么？最大的不同就是 workflows， 它不会马上就开始执行， 它是先暂停，然后它会在本地生成一个 context 的 点。 md， 它会把你的任务的分析都写在这个文件里面。嗯，你可以看到整个的上下文和步骤， 所以说它是一个先规划再执行的这样的一个方式。对，挺不一样的。没错没错，然后最有意思的是，它会让你现场一行行的去写 javascript 的 控制脚本。哦，你保存好之后，它就会用 node js 去执行，所以它更像是一个架构师 agent， 它会把你的自然语言的需求翻译成一个多节点多阶段的这样的一个控制脚本。对，所以它会更灵活，也更适合这种复杂的企业级的场景。 确实，那有没有实际的测试过，这个 workflows 在 一些具体的任务当中到底表现怎么样？有啊，就是那个 ai 超元域，他们团队就用真实的开源的 pr 做了一个测试，他们写了大概三百行左右的 javascript 的 代码。嗯，然后分成了三个阶段， 第一个阶段是审查代码，第二个阶段是验证结果，第三个阶段是生成报告。它是一个非常复杂的任务。听起来就很厉害，那它这个过程当中是怎么执行的？ 它会自动地去调动多个专业的审查器，然后在后台反复的运行，整个的流程一共是走了九十七个 agent 的 轮次。嗯，但是这些并不是同时进行的，这些数据都是来自于第三方的视频。嗯，并不是 esotope 官方公布的。 好的，那这个 workflow 它有一个 t u i 的 仪表盘，它到底有哪些功能？然后它的设计是针对什么样的使用场景的？ 你在终端里面输入 workflow， 它就会弹出一个全交互的仪表盘，你可以用键盘的上下键和 enter 还有 esc 来操作。 然后它会显示每个 agent 的 状态，运行了多久，消耗了多少 token， 调用了哪些 mcp， 它整个的成熟度感觉已经非常高了，就很像是 htp 或者说那种高级的 icd 面板。对， 它是专门为需要实时监控和精细控制的这种复杂的自动化任务设计的。我很好奇这个 deep research 工作流到底是怎么运行的？它到底有哪些步骤？然后它是怎么来完成一个比较复杂的调研任务的？这个 deep research 它其实是分成三大步，第一步它会去搜索，第二步它会去交叉验证， 第三步它会去合成报告。它每一步都分工非常明确。感觉这分工确实很细致啊。那具体到每一步它会调用哪些 sub agent？ 比如说它会有四个 applet 同时在跑，第一个 applet， 它是专门去查官方文档的。第二个 applet 它是只看论文的， 第三个 applet 它是专注于社区讨论的。然后第四个 applet， 它是去钻研原码的。嗯，它会把这些结果都汇总起来，而且它的这个脚本是可以附用的。下次你要做类似的调研，直接跑这个脚本就可以了，它整个的效率是非常高的。 好的，那我们现在再切换到企业的视角，就是说像 workflows 这样的一个自动化的工具，它在落地的时候会碰到哪些时机的挑战？其实很多企业它不是没有技术实力，它是缺乏一种纪律， 就是它很多的任务都是重复的，但是它没有一个标准的流程，所以它会导致很多的错误，然后效率也很低。嗯，那 workflows 它就是把这些重复的任务变成 sop， 然后自动地去执行， 所以它是真正的把企业的这个纪律和效率都提升了。那具体来说，企业在使用这个 workflows 做自动化的时候，有哪些可以借鉴的最佳实践？主要有三点，第一点就是先编辑后执行， 就是你要把你的流程先翻译成控制脚本，这样的话它就会留下一个非常清晰的记录。对，然后第二点就是要把可观测性产品化， 就是你要通过 t u i 这样的方式把它的运行状态实时地展现出来，就像我们的 ci 工具，或者说我们的 h t p 一 样。嗯，那第三点就是要让你的脚本可以附用， 就像我们的 deep research 这种脚本，你可以在不同的类似的项目里面直接去用，这样的话可以大大减少你的开发成本。哎，说回来，现在这个 workflows 预览版它有哪些风险是企业需要去注意的？目前最大的风险就是它没有 sla 的 保证，然后它的 api 和它的 ux 可能随时都会发生变化， 所以它比较适合那种先锋型的团队在 sandbox 环境里面去使用。明白了，那如果企业现在有各种各样的自动化的需求，那到底该怎么去选？是选 sabotage 还是选 skill 还是选 workflow？ 如果你的任务是一次性的、探索性的，那你用 skeleton 是 最方便的。嗯，那如果你是要把一些能力打包起来给其他的流程来调用，那你应该用 skill， 那如果你的任务是反复出现的 s o p， 那 你一定要用 workflow。 对， 这个其实是我们自己总结的，并不是官方的一个选型矩阵。好的，那能不能再给我们梳理一下这个 workflows， 它整个的从想法到执行的核心的步骤？当然可以，它其实就是用户用自然语言提出一个需求， 然后 workflows 会把它解析，并且生成一个 context 点 m d， 之后再转成 javascript 代码，用 node js 去执行。并且你可以通过 workflows 这个命令去实时的观测整个的运行状态，整个的链路非常的清晰。 ok， 今天我们其实就是带大家提前体验了一下这个 cloud code 里面的 workflows， 这个新的功能确实让企业级的自动化变得更加的规范，更加的灵活，而且更可观测。好了，那这期节目咱们就到这里了，然后感谢大家的收听，咱们下期再见，拜拜。拜拜。
984大厂吾师兄（AI篇）
05:30查看AI文稿AI文稿ai 越聊越蠢不是错觉，超过十万 token， 他 就开始做蠢决定了。 近日，在一场 ai 编程工作坊里，讲师马特波科克把用 ai 写代码讲得很直白， 别把 ai 当许愿机，更别指望他把一份规格文档直接翻译成代码。真正能交付的流程反而更像传统软件工程， 而且每一步都在对抗大语言模型两个硬限制，第一，他有智能区和愚蠢区。第二，他像记忆碎片里的主角一样，会不断忘记 所谓智能区和愚蠢区。他的比喻很狠，对话越长大语言模型要维护的注意力关系会平方级爆炸。就像足球联赛，每加一支队比赛数量暴增。结果就是不管你给他二十万还是一百万，上下文窗口到某个比例之后，他都会变笨。 他自己的经验域值大约在十万 token 附近，再继续往同一个上下文里塞东西，他就越来越容易做蠢决定。 结论很现实，任务必须被切小，尽量让 ai 一 直待在智能区里完成工作。 接下来最关键的是别规格到代码。马克波克克直接批判了规格到代码这套想法，写个 p r d 丢给 ai 生成代码，错了就回去改规格，反复迭代，却不看代码本身，这本质就是另一种 web 编码。最后一定失控， 因为代码才是战场，你必须持续掌控代码结构。那怎么把一个含糊需求变成 ai 能稳定执行的任务？ 他给了第一招 grill me skill， 中文可以理解成考打我技能流程是清空上下文，从零开始把客户简报。比如 slack 里一句想做课程平台的游戏化提高留存丢给 ai， 然后让 ai 一个问题一个问题把你问到对齐为止。积分从哪儿来？要不要追溯历史记录等级曲线？怎么算？ ui 放哪儿？这些问题很多时候客户根本没想过，但如果不提前定，后面实现一定扯皮。 这一步他明确说只能人类再还，也就是 human in the loop。 规划阶段必须有人拍板，因为这是定义边界、风险取舍的阶段。 你可以让 ai 给推荐答案，但最终决策必须有人类负责。等考打完成，你得到的不是一份漂亮计划，而是一份共同的设计概念资产， 有了对其资产。第二步才是写 prd， 它只是目的地，文档负责把问题解决方案、用户故事实现决策、测试决策写清楚。 这里他又讲了一个反直觉，他往往不仔细读 a i 写出来的 p r d。 原因很工程化，你已经通过考打对齐了 p r d 更多是在考 a i 的 总结能力，而不是在帮你做关键决策。 第三步是把 prd 拆成看板任务，但拆法必须是可追踪子弹或者垂直切片。他观察到 ai 最爱水平，写代码，先把数据库或者 schema 写完，再写 api， 再写前端。问题是直到最后一层你才拿到反馈，等于 ai 一 路猛眼狂奔。 更好的拆法是垂直切片，第一刀就让它从 skinma 到服务到最小前端展示都跑通，哪怕功能很薄，但能立刻集成，立刻验证，立刻 q a。 当你把工单拆成彼此依赖清晰的看板后，就可以开始并行，把可独立抓取的任务交给多个 ai agent 同时做。玛特波克克把，这叫白班或者夜班。 白班是人类做对齐，做拆分，做架构边界。夜班是 ai agent， 在 你离开键盘 afk 之后，按功单推进。 真正让夜班靠谱的是第四步，用 tdd 把反馈回路盯死。它强调测试驱动开发 tdd 的 红绿虫垢对 ai agents 极其重要，先写一个会失败的测试，再补实现让它通过。 这样做的好处有两个，一是强迫 ai 把可验证的行为说清楚。二是更难在测试里耍赖，因为测试先于实现出现。他还提醒一个容易踩的坑，让 ai 自评选是有用的，但要注意，上下文 实现往往已经消耗了不少 token。 如果你在同意上下文里让他做 review， review 会落在愚蠢区，评审者反而比实现者更笨。 更好的做法是清空上下文，再在智能区做评选。最后一件事是让代码库本身适合 ai。 它引用约翰奥斯特豪特软件设计的哲学里的概念，深模块与浅模块。 浅模块是很多小文件到处互相引用， ai 很 难追踪依赖，也很难划清测试边界。深模块是接口小，内部实线多，把复杂性封装进去。测试可以围绕模块外部行为来写， 你甚至可以只牢牢记住模块接口与形状，把内部实线交给 ai， 这样既能跑得快，又不至于对代码库失控。 整体听下来，他想表达的其实是， ai 不是 替你跳过软件工程，而是逼你把软件工程做的更扎实。你现在写需求更头疼，还是代码频审更头疼？
120GenAI动力
01:06查看AI文稿AI文稿欢迎来到 p r c i 高保真 ppt 翻译平台，让 ppt 翻译达到可交付级别。 ai 翻译同时守护版式稳定，手机号快速登录，即刻开启翻译之旅。新用户注册即免费赠送六百点流量，可翻译六十页 ppt， 上传 ppt 文件，自动解析复杂文档结构，选择目标语言，支持数十种语言和 rtl 方向适配。点击开始翻译 run 即精准映射，支持断点续跑，复杂对象稳定处理，翻译完成一键下载， 质量校验，确保交付及水准来看实际效果。这是原始中文 ppt 页面，包含标题、正文和图标，英文翻译结果版式完全一致，加粗和颜色全部保留，阿拉伯语翻译结果 自动适配，从右到左排版版面依然稳定。扫码获取一对一技术支持， p r s a i 翻完即交付！
2鹤鸣九皋
01:55查看AI文稿AI文稿今天咱们来硬核拆解百度 renderflow， 看它怎么彻底颠覆代码交付。你猜猜看，在复杂的系统里更新一条搜索结果到底要多久过去？得熬上好几周。但有了 renderflow， 只要短短几分钟， 速度这么快啊？秘诀是， agentic 交付闭环儿，绝对不是不同的 ai 程程执行、反馈、修复发布。这套全自动闭环直接解放了程序员双手。它的底座是可执行隐形，能在系统运行时像读配置一样动态加载代码。 这可是个大招，直接免翻译、免起重启，把繁琐发布变成了极速更新。这点为啥？关键因为它能隔离错误代码，写挂了也绝不会拖垮整个服务。不过大模型也会翻车，实际上首轮代码的通过率只有百分之八十二， 剩下的 bug 咋办？这时候，多轮自动修复这个黄金搭档就出场了。 coder 负责敲代码， reviewer 只提自然语言约束，绝不直接打补丁。 这些约束会累积成单调记忆，不仅逼着 ai 重构，还能死死防住旧 bug 复发。线上环境太脆弱，所以系统设了三道自动化防线，发布前中后全程死守， 就算大模型突然抽风，自动快照也能瞬间回滚，保住业务的绝对稳定。看看这效率，有了这套闭环，人工介入的比例直接砸到了百分之五以下。 这可不是实验室玩具，它已经在支撑近一千个真实复杂的线上搜索场景了。所以核心价值根本不是 ai 写代码，而是跑通了一个完整的交付闭环。 从手敲代码到玩转 agentic 闭环，这行已经变天了，你准备好进化了吗？
01:33查看AI文稿AI文稿瞬间就不担心我的 cloud skills 学习了，谁懂啊！最近吴恩达联合 ant hr、 opic 低调上线的这门新课 agent skills with the ants are opic， 在 全网都被讨论疯了，我必须给大家好好安利一波。课习不长，总共就一个小时，但我消完后发现，这可能是目前系面向关于 ai 智能题技能最清晰的一次官方科普。 如果你对 cloud 最近更新的各种生产力工具感兴趣，或者想知道未来的 ai 到底怎么更高效率的干活，这门课非常值得利用，周末刷一遍。 为什么这门课值得看？第一，官方下场制定标准。这次是 ntropik 官方的教育负责人出镜，它们并不是在泛泛而谈，而是直接把 cloud 内部定义 a j skill 的 那套标准格式 skill md 开源了出来。这意味着你学到的不是屠龙记，而是未来通用的工业标准。 第二，机器不写代码也能看懂。虽然题目带有 agent， 但课程门槛很低，它没有讲复杂的拍放架构，而是侧重于讲逻辑。 ai 怎么理解一个工具？为什么要把复杂的 prompt 拆解成一个个小技能？如何让 ai 只在需要的时候才去加载机器、渐进式批录？ 这些逻辑对于产品经理或者普通用户理解 ai 的 工作流都非常有帮助，无人打扰。习的课一向一把复杂便简单就成。在一个大家都急着把 ai 往复杂里做的时代，官方出来教大家如何用最简单文本来构建强大的 agent， 这件事本身就很值得学习。
115狠狠学编程
