刚好在啃OD 收藏了
点赞 1

相关推荐

在我来鹅之后,接到的第一个完整大需求就是需要编写一个skill,之前的实习也写过一些skill,但是在我的理解中skill就是跟提示词没差,把你需要的目标全写上就好了,所以第一次mr我提交了一个超过1200行的md,被mt打了回去,为了完成这个需求,我又赶紧请教了我身边的大神同学,获取一些写skill的经验,将原先1200行的md进行了对应的references拆封,又通过我朋友教我的验证机制验证这个skill的效果,最后完成了我的第一个需求。正好前两篇文章给大家分享了写好的用来包装简历的skill,那么今天来给大家分享怎么去写一个好的,可以实际用来工作的skill,摆脱只会写提示词的尴尬。构建 Skill 的五个步骤Step 0:先写 EvalsEval(Evaluation,评估)是一套结构化的、可重复运行的测试用例集,用来判断 Skill 的表现是否符合预期。它不是泛指"测试一下",而是开发 Skill 的前提条件。一个典型的 Skill eval 集至少包含三类用例:- 正例(Positive):用户说“帮我看一下这个 PR 能不能合”,验证 Skill 应该被加载- 负例(Negative):用户说“帮我把代码格式化一下”,验证 Skill 不该被加载——路由别跑偏到不该触发的地方- 边界(Edge):“这个 PR 改了一行日志,要不要审”,验证边界情况下的路由行为正例和负例都要写,而且负例往往比正例更值钱——误触发是 Skill 路由的头号失败模式。Eval 不只是测一次。Perplexity 的 eval 分三个层次:如下图每种都要在 GPT、Claude Opus、Claude Sonnet 不同的 orchestration 模型上分别跑——Sonnet 和 GPT 的 Skill 行为差异很大,只在一种模型上过了不够。没有 evals,你改 description 就是在盲改,一个新 Skill 也可能悄悄搞坏已有的十个 Skill。Step 1:写 Description(最难的一行)description 是路由触发器,不是文档。写好它不需要关心 Skill 的内容,只需要关心能不能在正确的时间加载、有没有意外触发到不应该触发的地方——误触发是头号失败模式,每加一个 Skill 都有可能让其他 Skill 变差。糟糕的 description 描述 Skill 做什么,好的 description 说什么时候加载。举个监控 PR 的例子:不要写这个 Skill 做什么,要写工程师感到焦虑时会说什么——"babysit"、"watch CI"、"make sure this lands"。快速检查清单:- 以"Load when…"开头- 控制在 50 词以内- 描述用户意图,最好来自真实查询- 不总结工作流程Step 2:写 Body跟同事讲工作流程和跟 LLM 讲工作流程完全是两回事。对几乎任何面世超过一年的软件工具,只要提名字,模型已经知道怎么用。所以跳过模型已经懂的部分。不用写出每一步命令。比如不要写 git log → git checkout main → git checkout -b clean-branch → git cherry-pick commit。写 "Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why." 模型在后者上表现好得多,尤其是事情不按预期走的时候。太规定的指令比灵活的指令更脆弱。然后聚焦 gotchas 和反例,它们是最高信噪比的内容。每次 Agent 搞砸了就加一条,gotcha 会自然地累积起来。条件逻辑或内容太重的东西移出 SKILL.md,放到 accessory file 里渐进加载。Step 3:用层级结构- scripts/ —— 确定性逻辑,模型不用每次重新发明- references/ —— 重型文档,条件触发才读("如果 API 返回非 200,读 api-errors.md")- assets/ —— 输出模板,模型直接复制填充- config.json —— 首次运行设置,问一次保存下来对于极其复杂的 Skill,进一步考虑是否应该拆成一组 Skill,用 depends: 声明加载关系。Step 4:迭代切分支出来,在无 Skill 的状态下跑 hero query(核心用户场景查询),建 eval 集,反复调。提交 review 时最好一个 changeset 里自带 eval 集。Description 里的小词改动对路由影响很大,甚至会 spillover(溢出)到其他 Skill,所以这些在 Step 5 之前做完。Step 5:发布大家快把这5步实行起来,成为写skill专家吧!
琉璃梦忆:直接skill creator 管你这那的
AI了,我在打一种很新的...
点赞 评论 收藏
分享
一、机位调试(双机位监考!第一机位、第二机位都一样重要)* 第一机位设备调试(打开电脑摄像头,拍摄调试;共享屏幕录制)1、要求:第一机位需要完整拍摄全脸正脸,否则成绩无效,半年内无二次机考机会2、易出现的问题及解决方法:①第一机位摄像头异常——如果不是硬件问题的话一般是有其他软件和牛客客户端有冲突②第一机位没有拍到全脸——考前调试好第一机位,完整拍摄全脸正脸* 第二机位调试(手机或者iPad扫描二维码,开启摄像头,如第二机位摆放不符合要求,则成绩作废,无二次机考机会)1、要求(见p1):露出上半身,且需要完整看到双手、键盘、以及电脑屏幕(手机支架:横屏拍摄、一臂距离、电脑屏幕微微倾斜)2、易出现的问题及解决方法(第二机位出问题不会提醒,所以一般都是第二机位出问题,要特别注意):①第二机位不规范,例如没拍到屏幕、没拍到键盘、没拍到人的半身——考前调试好第二机位,一定要将电脑屏幕、键盘、考生的上半身和双手都要拍进去②第二机位拍摄图片较少(一般是第二机位断连了一段时间,无法过筛)——考试时随时关注第二机位情况,出现问题及时解决③第二机位熄屏——开启常亮④第二机位被其他应用程序打断录像(例如电话)——开启飞行模式⑤第二机位没电——持续充电二、考试注意事项(可以在系统里看到详细考前须知)1.请使用最新版chrome浏览器作答(72 版本以上) ,考试需开启摄像头,请确保电脑带有摄像头。2.考生只能在笔试页面在线编写和调试代码,手机监控、电脑摄像头都要打开,考试过程中不要故意取消监控。3.考试答题时间150分钟。4.考试共3道题,可从任一部分(一星题或二星题)开始作答。进入考试界面后,每进入一题型均有输入输出规范例题供参考,例题学习时间计入考试时间。一二星题目均可随意切换顺序作答,就算有其中一题暂时做不出来也可以先提交,继续完成其他题型,后续回来重新修改答案。5.程序开发:不要紧张,将工具调整为最合适的宽度(当鼠标悬停在下图红框处鼠标变为“*”时直接拖拽左侧的文本框即可,也可点击右上角的全屏,进行全屏编码),保证编码舒适性。(见p2)6.程序调试:当代码完成一部分时,如需调试,请点击自测运行。自测输出框可以拉升,方便查询输出及错误信息,根据输出及错误信息调整代码即可。(见p3)7. 提交作答:程序基本开发完成后记得点击右下角“保存提交”按钮,否则答案不作保存,不限制提交运行次数(以提交中最高得分计分),调试完成点击左下角【提交本题型】按钮(见p4)。所有题型均完成作答后,点击【我要交卷】(见p5)。
点赞 评论 收藏
分享
牛客52338264...:我也专升本 别写专科了 只写本科 有问再说 没问都不要提专科经历, 然后赶紧去学一个项目,把这个项目包装成实习经验 再学一个项目当做项目经验
点赞 评论 收藏
分享
牛客网
牛客网在线编程
牛客网题解
牛客企业服务