开发skill怎么写
如果你正在写 ai agent 的 skill， 但只是把一大段 prompt 塞进 skill， 那 你可能还没真正理解 skill。 今天分享一套写出工业级 skill 的 方法。不管你用的是 codex、 cloud code， 还是其他支持 skill agent 工作流的平台，它的核心都不是让 ai 多记几条规则， 还是把你的经验固化成一个能自动触发、稳定执行、持续迭代的工作流。第一步，先别急着写文件，先定义用力。一个真正值得做成 still 的 需求至少要有两到三个具体场景，比如用户什么时候会触发它，它要做哪几步？需要调用哪些工具，最后交付什么结果。如果你连具体用力都说不清，那它大概率只是一段一次性 prompt to skill。 第二步，写好描述 skill 的 论文通常不会一直加载，但描述会长期参与匹配。也就是说 agent 能不能在正确场景自动调用它，主要看描述写的准不准。一个好的描述要说清楚三件事，它做什么，什么时候用，关键能力是什么。 不要写处理选择题这种空话要写当用户说定下周选择题，这周写什么时，规划公众号选择题并输出后选标题和接脚。第三步，限制工具边界。工业级 skill 不是 权限越大越好，而是只给它完成任务所需的最小权限。只读分析类 skill， 就 不要默认允许 修改文件。只负责生成建议的 skill， 就 别让他随便执行命令。工具边界越清楚，误触发和危险操作的风险就越低。第四步，别把所有内容塞进主文件。工业级 skill 要用渐进式， 譬如主文件只放触发条件，核心流程工具要求验证方式长，案例放到 references， 稳定操作写成 scripts， 模板和样例放到 assets， 这样 agent 需要什么再读什么，不浪费上下文，也不容易迷路。第五步，根据任务选择合适的模型和思考深度。写文章，做设计，跑数据分析，整理资料，本来就不该默认用同一个模型， 复杂任务用强模型，简单批处理用便宜模型，关键决策提高思考深度。成熟的 skill 系统，本质上是在做任务编排，不是无脑堆最强模型。第六步，写完一定要测试一个 skill 能不能用，至少要测三件事，能不能跑，能不能正确触发结果是不是比不用 skill 更好，尤其是触发测试，不能只测，请运行磨磨 skill 要模拟真实用户会怎么说？ 该触发的不触发就补描述，不该触发去触发就收窄边界。第七步，也是最关键的一步，做评测闭环，准备测试，用力跑一遍，给结果打分，找失败点再修改 skill。 触发失败就改描述流程，漏步就改工作流，输出不稳定就加模板确定性，操作不稳就写脚本。这个循环跑完， skill 才从看起来能用变成真的可靠。 所以 prompt 解决的是这一次对话 skill 解决的是之后一百次类似任务。工业级 skill 的 核心不是写的长，而是能被正确触发，按流程执行，权限可控，结果可验证，还能不断进化。如果你想让 ai agent 不 只是一个听话的工具，而是越来越懂你工作方式的队友，那就别只写 prompt， 开始把你的经验做成真正的 skill。 这里是 v to a g i。 我 们下周继续。
粉丝5.0万获赞14.2万
相关视频
08:24查看AI文稿AI文稿这期视频我们学习怎么写一个属于自己的 html 生成 skill， 不是 写一句帮我做个好看的网页，而是做一个可以稳定生成某类 html 的 skill。 比如网页 ppt、 某书、卡片、公众号封面、报告页、作品及页面活动页，都可以变成一个专门的 html skill。 为了讲清楚这件事，我会拆三个县城项目。第一个是 test skill， 它主要靠 skill 点 md 里的规则， 让 ai 生成更有设计感的前端页面。第二个是龟三杠 ppt skill， 它可以生成横向翻页的 html 网页 ppt， 而且里面真的带 html 模板、主题和布局。第三个是 gaizing social card skill， 它可以生成某书、图文、公众号封面。这类社交图片 本质上是先生成 html， 再截图导出图片。这三个项目刚好代表三种层级的 html skill。 taste skill 是 清亮规则型， guisheng 杠 ppt 杠 skill 是 html 模板型， guisheng social card skill 是 卡片生产系统型。所以这期的重点不是评价谁更好，而是看他们怎么设计， 然后反推我们自己的 html skill 应该怎么写。你可以把 skill 理解成给 agent 装上的一套专业工作方式，普通提示词通常只影响这一次对话。 skill 则把一套固定流程沉淀下来，让 a g t 下次遇到类似任务时，还能按同样的方法做一个 skill 最核心的文件是 skill 点 md， 它会告诉 agent 这个 skill 是 干什么的，什么时候使用，使用时按什么步骤做，哪些东西可以用，哪些东西不能做。但如果你要做 html 生成 skill， 只写 skill 点 md 往往不够， 因为 html 页面最重要的是稳定，如果每次都让 ai 从零发挥，结构风格组建都会飘。所以复杂一点的 html skill 通常还会有 references， assets 和 scripts。 references 放规则，比如主题布局组建检查清单， assets 放真实资产，比如 html 模板、背景图、视力文件。 script 放脚本，比如校验导出、检查尺寸。安装 skills 非常简单，找到 github 开源地址，复制一键安装命令，在你的 a 件替助手里运行，比如 codex， 然后直接用自然语言触发。接下来我们看第一个案例， test skill 的 特点是清， 它不是给你一堆 html 模板，而是通过 skill 点 m d 里的设计规则，改变 ai 生成页面时的判断。比如 gpt 杠。 test 会要求 ai 先决定几个东西， hero 怎么排，字体气质是什么组建怎么组合，动效怎么做，页面是否符合 ai d a 结构。这里的 hero 就是 网页第一屏，它可以是居中电影感，可以是非对称构图，也可以是左右分屏。 所以 tstq 的 核心不是复制一个模板，而是告诉 ai， 生成页面前要先做设计选择。它解决的问题是， ai 做网页时太容易生成普通 size 模板， 它适合做 landing page、 作品集、品牌页、活动页这类需要审美判断的 html 页面。但它也有局限， 它主要靠文字规则以自由度高，但稳定性不如硬模板。如果你想每次都生成同一种固定版式，就要看第二种。第二个案例是乖森 ppt skill。 这个 skill 的 目标很明确，生成单文件 h t m l 的 横向翻页网页 ppt， 它和 t s skill 最大的区别是，它带了 h t m l。 模板有两个大风格，第一个是电子杂志，这个风格有质感、墨色、衬线、标题、 webgl 背景， 适合人文分享、行业观察、商业发布。第二个是瑞士国际主义，这个风格无衬线、字体、网格、点阵、高对比、强调色，适合科技产品、数据汇报、工程分享。这两个风格分别对应真实模板、 template html 和 t e n p l a t e 杠 s w i s s 点 html。 它还配了主题文件和布局文件。电子杂志风有五套主题色，瑞士风有四套，电子杂志风有十个 slide。 布局瑞士风有二十二个正式版式。所以它的工作方式不是让 ai 丛林写 ppt， 它是先选风格，再复制模板，再从布局库里选每一页的页面骨架，最后把内容填进去，这就是硬模板型 html skill 的 价值，它牺牲了一点自由发挥，但换来了稳定性。第三个案例是谷微商搜索 card skill， 它和 ppt skill 一 样，也有 html 模板，但它的目标不是横向演示稿，而是社交图片。比如某书图文公众号封面、 文章封面、产品发布、卡片截图、讲解卡片，它会先生成 html， 然后用浏览器截图，把每一张卡片导出成图片。它也有两个大风格，一个是杂志风，一个是瑞士风，但它比 ppt skill 多了很多。单张图片股价原因很简单，社交平台的图片是一张一张看的， 封面要能单独吸引人，经单页要能单独读懂，证据页要能单独说明问题，总结页要能单独收束观点。 所以他准备了二十八个布局， recipe 杂志封十六个，瑞士封十二个，还有十套主题杂志封六套，瑞士封四套。所以 social card skill 可以 概括成两个大风格，十套主题，二十八个卡片骨架，再加导出和检查流程。这三个 skill 放在一起看， 差别就很清楚，不要把它们理解成谁更好。同一个主题 test skill 会做成网页 gui 森杠。 ppt skill 会做成演讲 deck gui 森。 social card skill 会把它拆成社交图片， 它们不是换了皮肤，而是换了工作方式。一个 skill 的 内部结构会决定 agent 最后把同一份内容变成什么形态。接下来讲重点，怎么写一个属于自己的 html 生成什么？ html 是 landing page 是 网页 ppt 是 某书卡片是研究报告还是某种固定风格的信息图？目标越具体，四 q 越容易稳定。第二步，写触发条件，也就是用户怎么说时， a n t 应该使用这个 skill。 比如做一个网页 ppt， 做一个 html 分享页，同时也要写什么时候不要用，比如纯代码 bug 修复不要用普通文档总结不要用。第三步，决定它是规则型还是模板型。如果你只是想控制风格 skill 点 m d 就 可以先起步。但如果你想稳定复刻某种格式，就要给它真实模板，这样 agent 不是 从零发挥，而是从你设计好的系统里选择和填充。第四步，设计页面骨架。 这是 html skill 最关键的地方，你要提前规定页面有哪些结构，比如报告型 html， 可以 有封面、核心结论、背景说明、证据页、流程页、对比页、引用页。 社交卡片可以有封面卡、观点卡、金单卡、证据卡、流程卡、总结卡。这些股价越明确， ai 越不容易生成随机页面。第五步，定义风格系统，不要只写高级好看，有设计感。你要写清楚颜色、字体布局、组件动效、图片处理方式和禁止项。 比如水墨风，不要只写水墨，要写墨黑主文字、印章式标签还要写禁止项。不要满屏毛笔字导致不可读。 第六步，准备真实模板。如果你希望稳定生成，至少准备一个可运行的 template html 模板里提前写好基础结构、字体、主题变量、通用 class、 响应式规则和占位区域。然后在 c q 点 m d 里告诉 agent 不要从零写 html， 先复制模板，再替换内容区域， 这一步会明显提高稳定性。第七步，加检查清单，可选 a、 g， t、 m、 l 容易出的问题，文字易出，图片比例乱、段位浮没替换导出尺寸不对。所以你的 skill 里要写清楚生成后必须检查什么。如果条件允许，还可以加歪了队的脚本。 最后一步，用真实任务测试，不要写完 skill 就 结束，拿三到五个真实任务跑一遍。如果他总是乱改颜色，就把颜色规则写严。如果他总是发明不存在的 class， 就 写清楚，只能使用模板已有 class。 如果他总是文字一出就加字号和行数键制 skill 是 一个会迭代的工作系统，不是一次性提示词。最后总结一下，如果你想做自己的 html skill， 至少要回答六个问题，第一，它生成什么 html？ 第二，用户怎么说时触发。第三，它是从零生成还是先复制模板？ 第四，它有哪些主题布局和组建？第五，哪些东西绝对不能做。第六，生成后怎么检查真正稳定的 html skill？ 一定要把工作方式写清楚，把模板资产准备好，把检查规则加进去。 提示词只能让 ai 这一次尽量听懂你，但一个设计好的 html skill 可以 让 ai 以后反复按你的方式生成同一类页面。
01:50查看AI文稿AI文稿最近啊，很多人问我怎么去写 skill， 最近 skill 是 特别火的，然后很多人在网上也看了，就是也用了别人的 skill 啊，所以说有些人就问这些 skill 是 怎么写出来的，我能不能把 skill 写出来 啊？当然有些人会说 skill 很 简单，其实用那个 skill creator 或者说那个 superpower 里面有一个 writing skill， 他 们就可以去写， 但是等自己真正去写的时候，你会发现自己写的东西肯定是没有别人写的好的，这个是为什么呢？ 那有什么办法可以让自己的 skill 写的特别好呢？我这里教大家一个小窍门， 这个小窍门非常简单啊，就是你把它当成一个正经的项目去做，比如说你要在网上收集资料，然后形成一份 啊科技类的日报，那么第一步你一定去找到像样的一个数据源，然后把这些数据源啊通过大模型的方式去把它抓取下来，抓取之后，然后你再通过一个什么样形式把它给形成日报啊，格式，你需要去调整，或者说你的输出啊，你需要去这样调整，那么这一个小小的项目就已经做完了。 接下来你只需要做一件事情，就是用 skill creator 或者用 superpower 里面的啊 writing skill， 然后让他把你之前所有的啊工作以及这个项目里面产生的所有资料全部总结一下，总结成 skill， 这样的话就是一个最基础版的一个 skill 了。当你使用这种方法做出来的 skill， 你 会发现你做的会比之前做的 skill 要好特别多。如果大家觉得有用的话，可以点赞、收藏、转发。
89乌卡AI笔记
03:21查看AI文稿AI文稿之前我又给大家分享一期如何去从零到一写自己第一个 skills 的 视频。后面呢，有很多学习圈的朋友都在反馈，用 cloud code 写出来的 skill 要么就是太啰嗦， 要么就是不好使。那今天我呢，来分享一下 cloud code 创始人团队亲自总结的写好 skill 的 核心技巧，帮大家呢避开去写 skill 的 雷区。 ok， 我 先破一个最常见的误区，就是很多人以为 skill 就是 一个 markdown 的 文件，写几行说明就完了。但 skill 本质是一个完整的文件夹，可以去包含脚本、数据、资产配置文件，甚至是动态钩子。搞清楚这一点，我们再来去看具体的编辑技巧。首先第一条，不要去陈述显而易见的内容， code 本身对编程啊已经非常了解了，你不需要去教他什么是函数，你要做的就是告诉他那些打破他默认思维的方式和信息。 我举个例子，比如 antispac 内部在写前端设计 skill 的 时候呢，不是去教 cloud 怎么去写 css， 而是明确告诉他不要用 enter 字体不要用紫色渐变。就这一句话，设计品味呢，立刻就不一样了。第二条呢，一定要有易错点的部分，英文叫做 gorgeous。 官方呢，透露，任何一个技能里面，最最核心价值最高的部分其实就是易错点。因为 ai 经常会在同一个地方翻车，你只要把你平时发现他最爱搞错的地方给他记下来，当成错题本塞进技能里面，而且随着日常使用，发现新坑就往里面去填，这个技能就会越来越好用。 官方呢，有很多很厉害的技能，一开始也是几行字加一个易错点，后来呢，再慢慢的去长大，变得更多的。第三条呢，就是要利用文件系统去做渐变式，譬如什么意思？就是不要把所有内容都堆在一个文件里面，你可以把详细的 api 说明放到 references 杠 api 点 m d 里面，把模板文件呢放在 excel 目录里面。 主文件只需要去告诉 cloud 这些文件在哪里，他会在需要的时候呢，主动去读，这样既保持了主文件的简洁，又不损失任何的信息。第四条就是不要去把指令给他写死。 六是要被反复使用的，每次的场景都不一样，你需要去给 cloud 提供完整的任务的核心信息，剩下的让他根据具体情况自己判断， 管太死呢，反而限制了他的能力， ok。 第五条也是很多人去忽略的一点， skill 的 一个描述字段不是给人看的，是给模型看的。每次对话开始的时候， cloud 会扫描所有 skill 的 描述，来判断当前这个请求要不要去触发某个 skill。 所以 描述字段必须精准的回答一个问题，什么情况下应该用这个 skill 写成工作总结，哎，没用，写成触发条件才有用。当然了，官方呢，也分享了很多的进阶玩法，比如说给 skill 去加记忆， 用日历文件或者 seeklight 存储历史数据，比如内置现成脚本，让 cloud 把精力放在决策，而不是写模板代码里面。 比如呢，设置按需激活的动态钩子，比如杠 careful 模式，专门去拦截 r m 杠 r f 这类的一个温写的删除命令。最后呢，官方也说了一句很实在的话，它们内部有很多强大 skill， 最开始也就只有几行指令，加一个避坑的列表，是在不断使用，不断踩坑，不断补充之后才变得越来越好用的。 所以先动手，边用边叠带才是叠好旧的一个正确姿势。 ok， 如果你对 ai 感兴趣呢，也欢迎去了解啊江学长， ai 学习圈里面呢，聚了一批真正在玩 ai 的 朋友，平时呢一起交流，一起折腾。我们也刚刚结束了我们的玩扣定的训练营打卡，目前也有两千多位新友了。那如果感兴趣呢，也可以去在评论区回复。
760清华姜学长
02:28查看AI文稿AI文稿当然在看之前呢，我们可以看一下在这个里面 skill， 我 把我把这个 skill 呢移到里面去啊， 好，同学们可以看到我那个笑话， skill 其实是已经定义出来了，我们来看一下，将中国唐诗宋词改成现代中文笑话啊，干嘛干嘛。最后呢，写写东西，马克烫，包括诗丽都有， 比如说我输入月落乌啼霜满天什么什么的啊。当然这个笑话其实也不好笑，因为我们没有去改造它 写完之后的这个创作的效果，它其实就是通过这一个 skill 来实现的。当然这种 skill 呢，它不只是文字的加工，还能够去做图片生成，还能够做视频剪辑，所有的工作，只要是以前能够脚本化的工作，现在都可以基于 skill 来做。为什么呢？因为在 skill 这一部分，我们其实可以创建一个 script， 对 吧？ script 在 script 中间，你可以定义很多的逻辑来保证你当前这个 skill 功能完整。那你还有，比如说有一些额外的依赖的一些其他东西，在 reference， references， refolios 里面啊，可以放在 references 里面，比如有些 data 有 一些额外的描述文件数据都在这个里面，那这就是一个比较完整的 skill 的 一个结构。唐宋 poetry， 什么 joe， joe， joker， generator， 叫这个名字啊，这个 skill 就 这个名字， skill 的 名称， 它的描述什么时候要用这个 skill 给它定义好，那么接下来其实就是去调用它了，那我们来试一下案例，比如说我在当前这个内容里面啊，输入了，比如说，嗯，床前明月光， 好，我就说这样一句话，看他接下来会干什么，直接通过我这一套 skill， 那 他会先去思考，对吧？你输入的内容，那直接帮我输出来。这很简单啊，因为这个工作比较简单。白话。然后呢？笑话。 我半夜差点拿拖把去擦霜，走近一看，原来是月亮把地板打高光，哎，有点押韵啊。 这个其实就是 skill 的 一个简单用法。那我们现在来看了，我们怎么样自己去调用这个 skill， 就 比如说我现在 skill 呢，一样不变，对吧？我假设也是写这样一套 skill， 我 现在可以把这个 skill 呢移到我的 open codex 里面来。那接下来我就直接用这个 skill 来调用它，看能不能生成结果，这就最重要的好。
00:36查看AI文稿AI文稿你写的前端代码是不是总有一股 ai 味儿？廉价感拉满那种？其实就差六个 skill 的是第一个属于 impeccable 的 增强版 front and design skill， 专治设计规范落地 taste skill， 提升 ai 前端审美判断 ui skills， 模块化的 ui 工程技能集合 motion ai kit 搞定动画和动效 better icons 解决图标难题， 最后再加个 design 点 m d 大 厂设计语言直接灌进去 web coding 出来的网站瞬间有质感了。你用了几个评论区说说看？
104樟池Ai大玩家
00:53查看AI文稿AI文稿如果你用 cloud code 写代码，别写完就直接合并。先装这五个 code review skill， 让它按不同维度先审一遍。第一个 code review and quality， 合并前总审它，按正确性、可读性、架构、安全性能五条线过一遍，适合任何 pr 合并前做最后检查。第二个 review and refactor， 审完顺手重构。 它会按项目自己的 coding guidelines 看代码，再给维护性和一致性建议。第三个 clean code 二，专治 ai 写出来能跑但难维护的代码。 clean code s o， a， d， d， r， y case， y， a， g， n， i 还有包幻觉吞异常测试没过却说成功，这些 ai 常见问题都会顶。第四个 open jab code review， 重点查安全和性能， obu s top ten 错误处理复杂度命名性能问题，最 后按 critical warning suggestion 分 级。第五个 review ticket， 把 pr 当需求验收。 scope 架构安全测试缺口 a c 覆盖 p r 源数据，依次给出 approve， request， changes or blocked 顺序记住先总省再重构，再守住 clean code 安全性能补一遍，最后按 p r 验收。关注我，继续猜 cloud code 的 实用 skill。
377AI编程日记（安全逆向）
01:46查看AI文稿AI文稿昨天我帮一个朋友二十分钟从零写出了他第一个 skill， 方法啊，就五步。很多人以为 skill 很 复杂，要写代码，其实不是， skill 本身就是一个文件夹，它核心只有一个，就是 skill 点 m d。 他 只做两件事， 第一定义我是谁，通过 name 和 description， 以及我要怎么做。至于脚本和 reference 文件，那只是做事情需要的材料而已。 第一步，先找问题，这步最关键，如果你每天重复的次数大于三次，那这个事情就值得做成 skill。 比如说朋友每天都要看做 a d 实验的数据分析，这种就是典型的 skill 的 应用场景。第二步，定义需求，把流程说清楚，比如说我要从 big 查数据，我用了哪些的 circle， 以及关注哪些指标和场景，让 ai 跑一遍，把不符合预期的地方直接告诉他应该怎么改。 第三步是自动生成，记住一句话，用 skill creator 这个 skill， 把刚才的整个过程封装成 skill， 这时候 ai 就 会自动帮你生成 skill， 点 md， 执行流程以及所需要的脚本，你啊基本不需要动手。 第四步就是测试加调试，用刚才生成的 skill 再跑一遍，然后看到它的执行，找到偏差，再修改这个 skill 点， md 一 边改两到三轮就稳定了，本质就是 prompt 调试加流程校准。 最后一步就是发布，把 skill 整个放到点儿 agent 的 skill 目录下，这一步很关键，你一次配置到处都能附用。 最后记住一句话， skill 就是 重复工作的 s o p， 找一个你每天都在重复做的事，花二十分钟把它变成一个 skill， 你 会发现 ai 这不是工具，它是你的执行系统。
219建斌聊AI
02:05查看AI文稿AI文稿我们去写一个 skill description， 就是 它的描述的时候，我个人通常会这么去写，我也看到社区里很多经验，大家都提倡这样去写，把它分为三个部分，第一就是这个 skill 它能做什么？它的核心价值是什么？比如说它能做的就分分析一个 figma 的 设计稿， 并深层开发交付文档，这他能做什么？第二他的核心能力，他基于做什么，他可能会罗列一二三，我具体有什么能力。 比如说从一个飞格玛中他能够设计提取设计规范组，深层组建文档，导出其中的标注，这是一个具体的能力。那第三他在模型真的没有办法基于你，前两者就很好的去理解你到底是个啥东西的情况下， 我们就要去列出来他的激活条件。我认为这第三步他是县级段模型发展没有那么到位，没有那么真正智能化的时候，他所不得不存在的一个过渡形态。但我同时也认为这个过渡形态会是一个非常长的一个时间， 一年以上的一个时间，我们不得不在 skill 里面去写，用户说什么的时候，用户干什么的时候，即将发生什么的时候，已经发生了什么的时候，你要去使用这个 skill 啊。比如说我们说当用户上传了一个飞格玛文件的时候，你一定要用把这个东西激活 来具体使用，或者用户提到了飞格玛设计稿的时候，你要去用我们的实际的观测，发现第三个在限阶段 是完全不可能省掉的。我们一直觉得这第三个阶段不就是我们把我们想到的交少量的东西交给模型，降低了模型的泛化的这种能力，但是实际上省了它，我们发现真的什么都干不了，所以缺少激活条件。 a 君是真的不知道什么时候该用 缺少能力描述呢？ a 君其实也无法判断是否匹配，所以这三者在我们的一个描述里面我们认为是非常重要的。
36CSDN
01:33查看AI文稿AI文稿写一个 scale 其实非常简单，那最近有同学问我如何去写一个 scale？ 其实我们可以用一下这款工具，这款工具呢也是开源的，我们只需要登录一下就可以使用， 然后我们找到设置，这里边找到技能与命令，然后我们去在这里有个技能，新建一个技能就可以了，比如说局或者项目，然后我们这里边写上名字，比如说 test case， 然后这里面呢加上描述，就是 type case 生成，这里面呢加上你具体要做的流程，比如说解析文档， 然后根据模板去生成，然后添加一些支持铺啊，然后去生成对应的用力啊，这就可以了，然后点确定这个 select 就 已经创建成功了啊。那如果你觉得这种方式比较繁琐呢？也可以用第二种方式，比如说我们找到啊， 这里，这里呢这个技能呢是专门通用的一个模板，他可以根据这个模板创建很多的技能，然后我们只需要用啊，也是用这个工具，我们把它搞到本地就可以了，然后我们直接把这个链接复制过来，然后放到这里，就是叫做 就可以放到自己的电脑上，然后他就可以运行，然后我们在这里面在最上面，这里面就可以找到他的安装目录，然后我们就可以直接使用了，使用的时候呢也是非常方便。然后我们只需要在这里面把这个模板就用它，然后我们直接把它这样放到这个聊天框里就可以了，就是比如说帮我生成 格式用力的四个，然后点击回车就可以生成了啊，因为我这里面已经有了，所以就不需要重复生成了，大家可以去尝试下，整体两种方式是非常简单。
191宇宙AI测试
01:57查看AI文稿AI文稿我今天把所有的开发任务，包括修 bug， 改前端 ui， 然后新增一些玩法和功能，无论是工作量大还是小，我都我都会尝，我都尝试丢给两个 skill 去解决，而且质量不错。第一个是 writing plan skill， 第二个是 sub enter the riven development。 第一个是用来干嘛呢？它是一个拆分任务然后出方案的一个 skill。 它好在哪里呢？ 他会假定工程师对我们的任务，对我们的代码库完全不了解，且其编码风格可能欠佳的前提下，记录他们可能需要的所有信息，包括什么的每个任务需要的文件，代码内容，测试的方法，可能需要查找的文档，以及具体的测试方法， 并将整个计划拆解为一个个异于执行的小任务，而且遵循以下三个开发原则。所以说它比我之前用大模型直接给方案的质量要高。同时它配合 suben 的 这个 skill， 它出来的它写的代码的质量会更高。为什么呢？我们来看 他会将他会将任务委托给具有隔离上下文的专业代理，并且通过精准拟令纸代理的指令和上下文，确保其专注于任务并成功完成。纸代理绝不能继承当前绘画的上下文和历史记录。 他的核心原则是每个纸任务分配全新的纸纸代理 agent， 并且会加上两段评分，第一个是合规性的评分， 第二个是质量的评分。所以说这个 sub agent 有 它写出来的代码的质量是要更高的，比一个模型 从出发岸到把所有的阶段的步骤全部做完，整个的质量要高很多。而且我今天不管是修 bug 还是前端 ui 的 改动啊，包括开发一些新的玩法进去基本上都是一遍过， 不用再去反复的修的这个 bug， 又又出现新的 bug， 或者说同一个 bug 反复修修不好。
46臭爸屁AI实战
04:48查看AI文稿AI文稿你给 agent 加了十几个 skill， 本来是想让他能力更强，结果发现他反而开始翻篇了。你让他润色文章，他可能去找代码相关的 skill。 你 让他整理表格，他却套用了写作模板。你让他做发布前检查，他又重新生成了一篇论文。那这时候问题不一定是模型变笨的，而是你的 skill 库没有设计好。因为 agent 在 选择 skill 的 完整内容都读一遍，然后再慢慢分析哪个最合适 他。通常会先看 skill 的 名称描述、路径、使用说明这些入口信息，再判断这个 skill 和当前任务是不是匹配。 所以一旦这些入口型的模糊， skill 数量越多，误判的概率就越高。当一个 a 技能的 skill 从十几个变成几十个甚至上百个以后， skill 命中率就会成为一个很关键的问题。 那本质上 skill 多了以后， a 级的选 skill 这件事就不再只是简单调用能力，而变成了一个路由和解锁问题。那怎么提高 skill 的 命中率？这里有四个比较实用的方法。那第一个方法是把 skill 的 描述写得更有区分度。 很多人写 skill 描述的时候，只会写这个 skill 能做什么，比如这个 skill 用来生成 ppt， 这种写法看起来没有问题，但对 a 级的来说其实不够清楚。 更好的写法是告诉他什么场景下应该使用这个 skill。 比如可以写成当用户需要制作汇报材料、融资、路演、季度总结、课程、课间或演示文稿时，使用这个 skill。 这两种写法的区别很大，前一种只是功能说明，后一种是触发场景。而 agent 在 做路由判断的时候，本质上是在做语匹配， 你把使用场景写得越明确，它越容易判断当前任务是不是应该调用这个 skill。 esploic 在 skill 的 设计里也强调过， describing 不 应该只是介绍功能，而要尽量写清楚出发条件，因为模型真正需要的不是这个 skill 是 什么，而是什么时候该用它。那第二个方法是给 skill 做分层。 很多团队一开始做 agent 的 时候，会把所有 skill 都平铺放在一起，一百多个 skill 全部摆在同一层，模型每次都要在这一百多个选项里挑一个最合适的。这就像你去一个没有分类的仓库里找东西，东西越多越容易找错。那更合理的方式是建立一个 skill tree， 也就是 skill 的 分类数。 第一层先分大类，比如研发、运营、市场、财务，然后在每个大类下面再继续细分具体能力。比如研发下面可以有代码生成，代码平手测试用力生成、接口文档生成。这样 agent 在 选择 skill 的 时候，不需要一上来就在所有 skill 里全量搜索，而是先判断当前任务属于哪个大类， 再到对应类别里找具体十六。那这样一来，搜索范围变小了，命中率自然会提升很多。大型 a 证的系统本质上也不是一次性把所有能力都丢给模型，而是通过分层路由，让模型一步一步缩小选择范围。第三个方法是增加负样本描述，这个点很多人会忽略。 大多数人在写 skill 的 时候，只会告诉模型什么情况下应该使用它，但很少有人告诉模型什么情况下不要使用它。比如一个缩口生成 skill， 你 可以写，仅用于根据业务需求生成缩口，不用于数据库表结构设计，也不用于缩口性能优化。 再比如，一个前端代码生成 skill， 你 可以写，仅用于生成前端页面和主键代码，不负责后端结果开发，也不负责数据库逻辑。 这种描述的价值非常大。因为很多 skill 的 误触发，不是因为模型不知道它能做什么，而是因为模型不知道它的边界在哪里。所以除了写 when to use， 还应该写 when not to use， 告诉模型哪些场景不要调用这个 skill 可以 明显减少误命中。 那第四个方法是用样例来教 agent。 很多人写 skill 只是写一段功能说明就觉得够了，但对大模型来说，例子非常重要，因为例子能让模型更快理解这个 skill 的 真实使用边界。 比如，你有一个深层周报的 skill， 用户说帮我整理本周工作进展，这种情况应该调用，那用户说帮我写一份周五发给领导的工作总结，这种情况也可能应该调用。但是如果用户只是问 周报一般应该怎么写，那这个时候不一定需要调用 skill， 直接回答方法就可以了。这就是正例和反例的作用。正例告诉模型这些情况要用， 反例告诉模型这些情况不要用，那尤其是反例非常关键，因为很多时候 skill 误命中，并不是因为正例不够多，而是因为边界没有讲清楚。你必须告诉 skill 什么情况下该调用，什么情况下不要调用，那最后总结一下， skill 多本身不是问题，真正的问题是 skill 没结构，没边界，没有清晰的路由规则。 想提高 skill 的 命中率，核心不是继续堆更多 skill， 而是把信用 skill 管理好。第一， skill 描述要具体，要写清楚触发场景。第二， skill 要分类分层，减少模型的选择范围。第三，要补充副料的描述，告诉模型哪些情况不要用。第四，要给 skill 配正力和反力，让模型理解边界。 最后记住一句话， skill 系统不是能力越多越强，而是能力越清楚越强。一个真正好用的 agent 不是 靠堆一堆 skill， 而是靠清晰的能力边界和精准的路由机制。
05:39查看AI文稿AI文稿想让 kloud 更听话，绕不开 skill， 但打开你的 skill 文件夹看看，写了十个 skill， kloud 真正自动触发的可能不超过三个，剩下的全在吃灰。我拆了几十个社区 skill， 又反复改了几十遍自己的之后，发现百分之九十的问题就出在七个坑上。从最容易踩的说起，第一个坑， 改完四 q 不 重启，这是最低级但最普遍的坑。你打开 s k i l l， 点 md， 改 description， 加规则，调整触发词保存，然后接着用 cloud 的 行为一点没变。为什么？因为 skill 只在 cloud code 启动的时候加载一次，你在绘画中改文件， cloud 读不到，它不是实时监控的， 所以每次改完四 q 必须关掉终端重开。听起来简单，但十个写四 q 的 人以九个踩过，改了半天，发现自己在跟旧版本较劲。第二个坑，所有内容塞一个文件。 你打开一个社区下载的 skill md 三千行，开头是规则，中间是 a p i 文档，后面塞了代码、视力和模板， cloud 要读完这三千行才能开始干活，头肯烧了一大堆，关键指令还埋在中间，找不着。 skill 不是 单个文件，它是个文件夹。正确做法是三层结构，第一层 skill 点 md， 正文只放行为规则就是 cloud 必须遵守的那些。第二层， references 文件夹，放 a p i 文档，详细视力 log， 需要的时候自己去翻。第三层， scripts 文件夹放可执行脚本。这三层是暗需加载的，启动时只载入 skill 的 名字和 description， 大 概一百个 token 出发时才读正文。 references 和 scripts 是 cloud 用到才去翻，所以你装五十个 skill 也没关系，不触发的根本不占上下文。判断标准很简单， 如果 cloud 不 看某个 reference， 就 会产出错误结果，那内容就该放 skl。 不 看某个 reference 就 会产出错误结果，那内容就该放 skl。 第三个坑，一个 skl 干了五件事，这是我见过最多的死法。 有人写了一个叫项目助手的 skill description， 写的是帮助管理项目，点进去一看，部署要管，测试要管， pr 描述要管，代码审查要管， readme 生成也要管，后果是什么。 description 为了覆盖五件事，只能写得特别泛。帮助管理项目， cloud 扫过去匹配不到任何具体场景，这个 skill 永远不会被触发。拆开部署一个 skill， 测试一个 skill， pr 一个 skill。 每个 description 精确到具体触发词社区有个数据，六万五千个字符，是 cloud 扫所有 skill description 的 上线。二十到二十五个精准 skill 的 效果远超五百个泛泛的。写完之后做一个删除测试，如果删掉这条规则，输出会变差吗？不会就删。 skill 不是 越厚越好，是越精准越好。第四个坑，措词太软，打开你的 skill， 点 md 搜一下，建议可以考虑，最好这些词的遵循率接近零。 colada 对 指令的措词强度非常敏感，建议先写测试，他大概率跳过先写测试 stop。 如果没有测试，他大概率照做，因为后者的措辞没有留下商量余地。 还有个细节，指令的摆放位置也影响遵循率。 cloud 对 文件开头百分之二十和结尾百分之二十的内容关注度最高，中间部分注意力下降，所以关键约束身份定义 核心规则，质量检查放在头尾，参考资料放中间。另外，如果你的 skill 里有一堆独立条目，比如工具列表、评分标准用 k v 格式，比用表格准确率高出八点八个百分点。表格只适合真正的二维对比，不是万能的。 第五个坑， description 写得太抽象。 description 是 整个 skill 里最重要的字段，不是之一就是最重要。为什么？因为 cloud 在 启动时会把所有 skill 的 name 和 description 扫一遍，来决定当前任务需要触发哪个 skill。 description 就是 你的 skill。 在 搜索引擎里的摘要写的不好，没人搜得到，什么叫好？ 一个公式做什么加什么时候触发部分要写具体的用户原话，坏的帮助管理项目，好的，当用户说出实话，项目搭建脚手架，创建新服务， 审计代码生成 p r 描述时，触发实测数据模糊的 description 激活率不到百分之二十，优化之后到百分之五十，加上 hux 能做到百分之八十四以上，花百分之八十的精力在 description 上，剩下的百分之二十写论文。这是社区验证过的投入产出比。 第六个坑，没有 go to x 工程团队的原话， gochaas 是 四 q 里信号密度最高的内容。什么叫 gochaas？ 就是 反直觉的 cloud， 从通用训练数据里学不到的项目特定知识。 举个例子，你的项目里有个 subscriptions 表，是 open only 的， 一个用户可能有多行记录。 cloud 不知道这件事，他可能去取 create 下划线 at 最新的那一行，但实际上你要的是 vision 字段最高的那一行，这就是一条 gauss。 再比如你们内部 api 的 posita 端点返回两百，而不是二零一， 本地兜克尔端口是三零零八零，而不是八千零八十。这些是 clod， 不 可能知道，但写错了就出 bug。 一个 skill 里最有价值的部分，不是重复一遍 clod 已经会的通用知识，而是这些反直觉的踩过坑才知的细节。 每个 skill 至少要有一条 gachs， 没有说明你还没认真用过自己的 skill。 第七个坑，把 skill 当 clod 点 m d 用。 skillcloud、 md、 hulk、 mcp 这四种机制经常被搞混。记住一个原则，每次都需要的写 clopdmd， 特定场景才触发的写 skill 必须强制执行的写后壳连接外部系统的用 mcp call 机。 md 是 全量加载的，每次对话都在上下文理，适合始终用 type script 的 代码风格，遵循 x x 规范这种局规则。 skill 是 按需加载的，适合当用户说要部署时，当用户说要发 pr 时，这种场景画工作流。 hulk 是 shell 级别的， cloud 跳不过去。适合每次写文件后自动格式化，提交前跑 link。 如果把大局规则写进 skill， cloud 只在触发时才遵守，不触发就完全无视。如果把场景化工作流写进 cloud 点 m d， 那 每次对话都占上下文。白烧 token 对 其机制是对其行为的前提。七个坑串起来，其实就一句话， skill 不是 一个文件，不是一个 prompt， 是一个按需加载的指令系统，你得用系统的思路去设计它。分层加载，精确触发、强措辞、反直觉信息优先。打开你的 skus 文件夹，对着这七条过一遍，我敢说你至少踩了三个。
253船长AI
02:14查看AI文稿AI文稿用 cloud code 做项目，如果你只想装两个 skill， 听我的，装这两个就够了。 g stack 和 superpowers， 一个管产品方向和发布，一个管工程质量和纪律，两个搭在一起，就是目前 ai 增强开发最完美的增强闭环。先说 g stack， 这是 y c 总裁 gary ten 亲自开园的虚拟工程团队，它包含二十三个 skill， 每个对应一个专业角色。运行 office hours， 会有虚拟 y c 合伙人帮你诊断产品方向。运行 q a 会有测试主管，用真实浏览器帮你跑验收，运行 ship， 直接帮你安全推代码上线。一句话，只确保的是方向和交付。再说 superpowers， 这是一套强制工程纪律的开源框架，它的核心守则极其严格， 比如写代码前必须头脑风暴，不先写测试，不准写实现代码，不找出根音，不准修 bug。 在 自动化代码审查中，它的 pr 拒绝率高达百分之九十四，质量控到极致。一句话， superpowers 管的是思考和代码质量。为什么说它们是天生一对？三个层面看互补。首先，能力不重叠。 chstack 是 产品和交付视角，管做什么？ superpowers 是 工程视角，管怎么写好。其次，触发互补。 chstack 靠你手动触发 skill， 比如你打个 q a， 它才会去测试。而 superpowers 是 完全自动发掘的， ai 检测到你在写代码或改 bug， 就会自动在后台禁默启动规范，两者完全不会打架。在实战中，我们怎么把它们组合起来？第一步，理清需求，先跑 superpowers 的 头脑风暴，然后又给 tstack 的 adversaries 反向对抗审查，从工程和产品角度帮你挑刺。第二步，拆解任务，写完计划后跑一遍 tstack 的 plan and review， 工程架构评审，把数据流和异常细节提前掐死。 第三步，开发验证，跑完 superpowers 的 测试驱动开发后，接上 tstack 的 qa， 让真实浏览器点点看，防止页面排版掰掉接口超时。 第四步，调试纠错，遇到离奇的页面或网络报错，跑 stack 的 investigate， 让 ai 打开浏览器控制台，看真实的盗墓结构去排查。第五步，发布上线代码审查通过后，由 shift 自动一键同步主干创建 pr。 当然杀机不用牛刀，普通小 bug 随手改就行， 只有大重构和跨模块的新功能才走完这套闭环。最后敲黑板，不配 cloud md 约等于白装。记得在你的 cloud md 配置文件里给它们画好分工，比如浏览器操作走 stack 的 browse， 其余编码规范全权托付给 superpowers 自动接管。去 tiktok 搜这两个 skill， 把你的 cloud code 瞬间升满级。掌握 ai 实战，下班不留遗憾！关注浣熊不加班，我们下期见！
11浣熊不加班
03:04查看AI文稿AI文稿其实我觉得很多人呢，都把 scale 想复杂了，作为一个文科生，我一开始也以为 scale 是 什么特别高级特别程序员的东西，后来才发现 scale 本质上其实就是把 把你每天重复做的事情去交给 ai， 或者说把它变成一个固定的东西，你只需要去输入你的需求，而不用重复告诉他你做这件事，你的角色是什么，目标是什么，输出要求这类重复性的东西。写 skill 的 第一步呢？其实不是呃学代码，而是先要想清楚，就是在 咱们要解决什么问题，先想一下这个问题是否经常出现，这个执行动作是否重复做，比如说你每天都要写小红书，整理会议，要分析内容，输出内容，整理新闻等这类需求。上面这些内容就是非常典型的你每天都会遇到的问题，然后又 不断的去重复需要做的一件事， ok？ 第二步就是去拆解这些重复性的动作，比如说你去想一下这个重复的步骤有哪些，每次给 ai 的 要求有哪些， 就是比如说分析标题，分析结构，整理重点输出文案，就你把这些步骤全都给他列出来。第三步， 让 jpt 去帮你整理 scale 的 逻辑，你只需要把你日常的工作流给输出出来，然后告诉 jpt 我 想要解决什么问题，我的执行流程是什么，希望 scale 最终帮我完成什么， 然后 jpt 就 会给你生成一个让 codex 去执行的 scale 的 提示词。第四步，把 scale 生成提示词丢给 codex， 就 你可以直接以对话的方式去告诉 codex 帮我创建一个 scale， 告诉我需要哪些文件，告诉我应该如何配置。第五，我们可能在这个过程中会遇到一些卡点， 比如说他写出来了 skill， 但是我们不知道怎么去用，怎么去安装。那你就可以直接问他这是什么，这个下一步怎么执行，为什么报错了，然后你可以按照 codex 的 指导去操作，完成 自己的第一个 scale。 我 可以给大家看一下我问的很多白痴的问题啊，比如说这个是它生成出来的一个 scale， 但是我完全不知道怎么用，那我会直接问他，就是我该怎么去使用这些 scale 呢？能告诉我使用方法吗？或者是这个就是我完全没有懂 怎么去调用他说的这个 scale， 然后他就会按步骤去这样子告诉你，还会告诉你方法一，方法二，方法三，你按照他给的步骤去试就好了。然后这个也是他让我在 mac 的 终端去用，然后 mac 终端其实他是一堆像代码之类的东西，我完全不懂， 然后可能就是会直接去问他，我没懂终端是要在哪用。我觉得 scale 对 一个人重复性的工作还是很有帮助，就减少了很多时间， 或者是每次都要把你的需求和标准去复制粘贴一遍，非常麻烦。所以我觉得 scale 不 难，但需要思考的点就是，呃，看 scale 可以 被运用在日常的什么地方。
90无所畏
05:45查看AI文稿AI文稿最近，我给一个零基础，完全没有技术背景的朋友，在他的电脑上装了 cloud code 和 six skill。 结果他现在每天工作，白天就抽空构思一下想法，晚上回家花一两个小时就用 web coding 把完整的项目给做出来了。 前两天，他特别空虚地对我说，现在实现 idea 太容易了，大学里的那些编程课好像没有什么必要了。 今天这期，作为一个写了二十年代码的程序员，我直接把初学者最炸最有用的三个 skill 分享给你们。只要装上它们，你 web coding 的 能力就不再只是做一个玩具，而是质的飞跃。点赞收藏，我们直接开始第一个 skill， superpowers。 很多人以为 ai 写代码是我给一句提示词，他图一堆代码给我。如果你这么想，那你永远只能做一些小玩具。科技行业什么最值钱？是 sop， 是 标准化的工作流程。 superpowers 不是 简单的提示词，它是直接给你的 ai 注入了一整套顶级的软件公司方法论。装上它， ai 就 不再只是一个只听指令的打字机，而是瞬间成为全自动运转的技术团队。 在这个生态里，包含了十四个环环相扣的技能。当你抛出一个模糊的想法，他会先出发。 brainstorming。 他 化身产品经理，用苏格拉底的提问帮你把卵脑子里的一团乱麻梳理成专业的设计文档，专治小白的，想不清楚，说不明白。 接着是 writing plans， 它像架构师一样，把大项目拆解成一个一个好落地的小任务。 最觉得是他的 sub agent driving development。 在 执行环节，他会针对每一个小任务，自动派活给不同的 ai 员工，还会严格遵循先写测试，再写代码的红绿重构标准。 他自己可以在那里干好几个小时，绝不跑偏。最后做代码审查，查 bug， 合并代码， 这全都是自动化的流程。听到这里，你可能会问，老哥，这么多高深的概念，我需要学吗？答案是，你完全不需要懂，更不需要管。 你就像一个公司老板一样，你需要亲自去画圆形写代码做测试吗？并不需要，你只需要输入需求，整个团队自己就运行起来了。你只需要坐在那里回答 ai 抛给你的几个确认问题就行。 我朋友就是这样几句话， ai 自己分工，自己设计，全自动帮他搞定了一个 a 股行情复盘系统，这就是 web coding 的 全自动发动机。第二个 skill， front and design 后台逻辑搞定了，那界面怎么办？这个时候，第二个技能 front and design 出马了，它的核心任务是把界面变得好看，彻底干掉你页面上的 ai 位。什么是 ai 位？ 万年不变的默认字体，俗气的紫色渐变，死板的居中排版，大家看了只觉得廉价，但小白又不知道怎么跟 ai 形容，我要高级感， front and design 就是 你的顶级艺术指导。你在写代码之前，它会强制你自己先做设计思考今天的网页，是走复古未来风、极简杂志风，还是旷野工业风，它自己会定基调，你不用费心描述，它会自动调用视觉武器， 抛弃烂大街的字体，换上极具性格的排版，大胆使用留白，甚至给你加上丝滑的滚动 动效和高级的造点纹理，这不仅仅是让你的项目从能跑变为能看，直接把你的野生点子包装成了过目不忘的顶级产品。第三个 skill， chrome dev tools 有了大佬执行，有了神仙颜值，一切就完美了吗？不一定，你的网页可能有 bug， chrome devtools 就是 你的全自动测试工程师。如果说前两个技能给了 ai 大 脑和画笔，那么这个基于谷歌官方 mcp 协议的神器 skill， 就是 直接给 ai 装上了眼睛和手。 以前 ai 写代码是蒙着眼睛跑，出了 bug， 你 得疯狂地复制报错信息给他。现在他能直接接管你的 chrome 浏览器， 他会像真人一样自己打开网页，点击按钮、填表单，走通整个流程。发现不对劲，他会自己去查控制台的红字报错，抓取网络请求，然后自动回去改代码。他甚至还能顺手帮你做一个加载速度和 seo 的 性能体验。 我朋友说整个流程他最震撼的就是这一步。以前听说程序员提 bug 掉头发，现在他就端着茶杯发愣，看着 ai 自己打开页面测试，自己发现错误自己修复，而他什么都不用做。各位新手想提高自己 web coding 的 能力，记住这三换神， superpowers 管大脑执行， frontend 管皮囊审美， chromevtools 管深度体验测试。 现在市场上的 agent skill 成千上百，你不用去焦虑，作为一个写了快二十年代码的程序员，我帮你验过货了。 装上这三个 skill， 再加上你的创造欲，足够你靠 web coding 做出一款商业级的产品。欢迎在评论区告诉我你有什么推荐的 skill， 这里是 acodeem， 我 会持续推荐 skill， 欢迎关注。鸡变藕不变，我们下期再见。
3872echoDM
