最近在学着写一些实用的agent技能，都是下班之后弄的，需要不断重复打磨文本，虽然能看懂英文，但有时候太累了就不想增加阅读负担。目前都是直接把本文c和v到翻译器看的，切来切去也麻烦。插件市场随便试了两个都好像不太得劲，不知道佬们有没有好的推荐捏 2 个帖子 - 2 位参与者 阅读完整话题
7 个帖子 - 5 位参与者 阅读完整话题
IT之家 6 月 9 日消息，在今天（6 月 9 日）召开的 2026 年全球开发者大会（WWDC）上，苹果在 iOS 27 系统中为日历（Calendar）与提醒事项（Reminders）加入多项 AI 功能。 科技媒体 MacRumors 在体验后指出，苹果正把日历和提醒事项从“手动填写”推向“自然输入”，用户点按日历应用的“＋”按钮后，可直接输入类似“周四晚上 8 点和女友 Sarah 看电影”的文字， 系统会自动识别时间、日期和事件内容，生成对应安排，省去逐项填写的步骤。 用户不必先跳到某一天再新建事件，只需要在输入过程中，直接点按系统给出的日期和时间建议即可完成创建。 若文字中包含“每周”这类频率描述，系统还能同步设定重复事件，适合例会、课程和固定行程管理。 IT之家援引博文介绍，提醒事项应用也采用相同逻辑，比如输入“周四下午 2 点提醒我去买菜”，系统会自动提取任务内容与提醒时间，快速生成待办。 苹果还简化了日历事件编辑。若某个会议原本设为每周重复，后续改成每隔 2 周一次，日历应用会智能调整未来事件的重复频率。 苹果还增强 Visual Intelligence（视觉智能）与日历、提醒事项的联动，用户在网上查看活动信息并截图，或用 iPhone 拍下一张活动传单，系统可识别其中的相关内容，并自动加入日历应用。
使用说明：将 [使用技能： http://47.107.180.19:3001/skills.md ] 发送给任意 agent 即可喝酒留言 网站地址： http://47.107.180.19:3001/ 欢迎来玩，哈哈哈
使用说明：将 [使用技能： http://47.107.180.19:3001/skills.md ] 发送给任意 agent 即可喝酒留言 网站地址： http://47.107.180.19:3001/ 欢迎来玩，哈哈哈
IT之家 6 月 6 日消息，彭博社的马克 · 古尔曼（Mark Gurman）昨日（6 月 5 日）发表最新 Power On 时事通讯，在介绍 iOS 27 版 Siri 带来的诸多变化外，还爆料了诸多 Apple Intelligence 功能。 在 iOS 27 系统中，除了 Siri 重磅升级外，多个核心应用与系统层能力也深度整合 Apple Intelligence，其中 Visual Intelligence 功能升级最为明显。 入口方面，该功能主要依赖 iPhone 的相机控制按钮，未来可能直接进入相机应用中的新 Siri 选项，让更多用户体验该功能。 能力上，Visual Intelligence 目前支持识别植物、提取日历事件以及搜索图像，而在 iOS 27 版中将新增读取营养成分标签、提取名片等印刷内容中的联系信息等。 图源：苹果 AI 修图方面， 消息称苹果公司计划推出 Extend、Reframe 和 Enhance 工具。 IT之家援引博文介绍，Extend 可向外扩展照片边界，并用 AI 补全新区域内容；Reframe 面向空间照片，可在拍摄后调整画面角度；Enhance 则负责优化整体画质与色彩。 在日常体验方面，苹果将升级 Safari、Genmoji 和快捷指令。其中 Safari 浏览器新增 Organize Tabs 后，可自动把打开的标签页按购物、旅行、工作等主题分类。 Genmoji 则会根据用户照片库和常用短语主动生成个性化表情，同一套图像生成能力还会进入壁纸设置，让用户通过文字描述创建主屏背景。 古尔曼还透露苹果公司正在开发代号 Mulberry 的健康类 AI 项目，包含血糖追踪增强和基于相机的锻炼监测，预计不会出现在 iOS 27 首发版本中。
也是来参加了，可惜不能用ai，不然高低得整一个第一，哈哈（奈何本人技术不行） 1 个帖子 - 1 位参与者 阅读完整话题
我让GLM-5.1介绍下自己，花了1万8的token量；让claude看下自己的技能，就用了1千。明显claude的任务更难，为什么glm-5.1会比claude多用10倍，有点不能理解。当我看到这个的时候还是有点小惊讶。 14 个帖子 - 4 位参与者 阅读完整话题
总结： 技能释放一次持续1-2小时，CD 3-4小时，一周用 4 6.5次。 技能 技能CD 4 个帖子 - 4 位参与者 阅读完整话题
这段时间用mattpocock/skills搞了几个给自己用的小玩意，分享一点经验。 啥最好用 grill-me/grill-with-docs 王者grill-me/grill-with-docs再次上线。这技能强就强在“达成共识”四个字，如果你的需求太宽泛，是真的会问到你神志不清的。我试过几次前面一些问题都还是会认真看，后面就摆烂直接开启Yes工程师模式了。 但王者也需要注意一些点，grill-with-docs会记录文档，很好的设计，但文档在完成任务之后应该删掉，因为可能会与后续的需求产生冲突。我在WinTProxy（自己搞的一个Win平台透明代理）的重构就遇到了与文档冲突的问题。我想要用ndisapi取代WinDivert做数据包的捕获和改写以支持WSL和HyperV的二层NAT，但原有架构是多个Worker在三层做数据包的处理，当时留了个docs/adr文档，然后切换ndisapi就遭殃了，它工作在二层，然后NAT又会经过几个网卡，然后就重复捕获了好几次。 to-issues 这个技能的其中一个思想是很值得参考的，垂直切片。这要求任务划分是从端到端的划分，而不是层间划分。一个任务需要处理完一个需求从后端到前端的全部实现，有效反馈对于AGENTS来说是提效的一个重点。 diagnose 很好用的debug技能，上面那个问题最后就是用它找的，当然也算是我懒，主要是trace级别日志太多了，也懒得看。不过这个技能本身规范了一整套流程，有点啰嗦的。后来我自己改了一套更个人化的技能库，对这个技能就是砍掉了后面的修改和测试，只报告原因就行了，把修改和测试交给to-issues和tdd。 tdd 另一个王者，AGENTS时代大概tdd是最合适的了，要是再配上rust。什么叫做写完就结项？准确来说不是这个技能是王者，是测试驱动这种思想是王者。 啥我不用 这里列几个我不用的技能，不过mattpocock的技能库里面的engineering基本都很有用就是了。顺带一提，我自己魔改就是engineering剔除了triage，魔改了包括zoom-out在内的其他技能，然后加上了handoff做session交接。 前置配置的Issue tracker 并不是说不好用，只是我认为做本地的文档会方便一点。但Matt pocock原来设计就是维护github上的项目的，所以并没有什么毛病，也就开头配置时候多个选择而已。 triage 这是搭配上面的Issue tracker用的，你如果是本地文档，你大概率不会用这个。因为你不可能先写个文档描述issue，然后再丢目录里面去排序吧！真的有人这样做吗？ zoom-out 这玩意就一句话，直接写提示词都行，没有什么工作流程之类的，所以本质上只是方便一点。魔改的话可以让它做些数据流图啊之类的，更清晰一点。 一般咋用 grill-with-docs → prototype(optional) → to-prd → to-issues → tdd improve-codebase-architecture → prototype(optional) → to-prd → to-issues → tdd diagnose → tdd 这个to-prd → to-issues很多时候是形影不离的，一开始我认为这两个就该合并，但后来实际开发中发现，有时候不会去写prd的，一个明确的需求就直接拆分任务了。这两个技能拆分是有道理的。 为啥用这 superpowers、trellis等这些其实都用过，有个共同的特点就是流程控制比较强，或者说比较重，穷鬼最喜欢省token了。 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 我一个人做了一款“喵呜乐消消”的消除游戏，附开源地址和试玩链接 先放链接，不喜欢看长文的朋友直接玩： 试玩地址 ： 点这里直接玩 GitHub ：[ GitHub - worth01/miaolegemi: 喵了个咪，关于猫猫的消除休闲游戏 · GitHub ] 说明 本作品由AI辅助进行界面设计、代码生成与风格优化，并经过人工调整、完善逻辑与细节后完成，相关AI辅助创作过程及游戏实际界面见下方截图。 这个是首页，点击“开始乐消消”进入游戏 这是游戏页面，以及抽卡页面，抽取猫咪并领养，猫咪上场即可发动主动技能 背景 我一直想做一款独立制作的小游戏，但没有游戏制作的专业背景。AI 工具普及之后，我觉得这件事变得真实可行了，于是就开始干。 整个项目从设计文档到代码，借助了Claude辅助完成。大概的分工是这样的： 我负责 ：产品方向、玩法设计、关卡设计、前后端开发、所有决策 AI 负责 ：图片生成、根据我的需求改bug、给出技术方案、讨论设计问题 AI生成猫咪图片截图： AI帮助修复bug： AI讨论设计问题： 这一次开发，更像是「我作为产品经理，AI 作为开发工程师」的协作模式。每一个功能点都是我想清楚了再让 AI 实现，遇到问题再一起调。 整个过程比我预期难，但也比我预期有收获。AI时代，把需求想清楚，是这个过程里最费时间、也最有价值的事。还有，要勇敢的迈出第一步。 目前的状态 游戏主体功能基本完成，包括： 消消乐核心玩法（30关 + 6种棋盘 + 6种干扰牌） 猫咪养成系统（12只猫 + 技能 + 好感度 + 序列号） 三区机制（包裹区 / 家园 / 出战席） 布阵系统（出战席 + 观战区） 羁绊系统 抽卡保底（SR 20抽小保底 / SSR 80抽大保底） 鱼干经济系统 称号和里程碑系统 纪念册（离开的猫永久记录） UI 细节持续优化中。暗黑模式：未来科技感设计风格，整体偏简洁硬核的未来机械风，没有过度花哨的霓虹，主打干净、克制的科技界面。明亮模式：采用牛奶萌宠可爱风。 目前还在改进中，游戏音乐也在同步制作中··· 以上 欢迎来玩，有任何反馈都可以在评论区说，或者去 GitHub 提 Issue。 如果觉得有意思，点个Star是对我最大的鼓励 ** 立即试玩 GitHub ：[ GitHub - worth01/miaolegemi: 喵了个咪，关于猫猫的消除休闲游戏 · GitHub ] 1 个帖子 - 1 位参与者 阅读完整话题
关于为什么要写这篇文章，大概是我昨天刷到短视频上很多内容，普通人应该如何抓住AI风口，做AI短剧？如同鸭老师所说赛道已趋近于饱和。创业开发个人AI团队？可是这玩意说实话一般人没多少资本并且大家真的懂商业模式吗，亦或者是能够具备在酒桌上谈笑风生的商务能力吗。在当下，在AI工具和各家大模型层出不穷又层层迭代的今天，我始终认为普通人想要抓住AI的风口，最保守的打法仍然是学到了AI之后去一家企业上班，工作，开展AI相关的工作，做一个业务型的类似AI售前工程师吧。也有人说为什么不直接去做AI应用开发岗，说实在的，如果纯做AI开发岗，对技术和学历的要求又太高了，不太适用于非科班出身并且中途转行的。综合来说，我更想要表达的是，我更偏向于去做一个业务——IT——AI之间的沟通桥梁，教会大家把你丢到企业以后，你如何快速的去上手完成你的工作，所以这一次我想写一下我个人对AI产品评估比较通用的流程，让大家大概有个印象，有一个大体的框架。 AI产品评估流程——5步流程法 1. 结果导向 ：评判一个AI产品值不值得做，首先避不开的一定是项目价值，那要如何去评判呢。很简单，围绕着钱来展开，要么就是多赚钱，省钱，或者就是少赔钱。先说多赚钱，那首先就得能不能带动销量上的一个增长，第二优先级那就是省钱，也就是能够降本增效呗，比如每年节省多少人力，少发了多少工资。少赔钱就是过去业务可能存在某个风险点，现在这个产品解决了这个风险点，能让你少赔一点钱。以我上次那个客服质检Agent为例来说的话就是，能不能带动销量，很明显，如果能在聊天记录中挖掘到了消费者的需求，开发了新的产品，从而带动了GMV，就是有价值的。第二是省钱，过去可能我需要10个人完成的工作，我是不是可以只需要5个人来完成，其余的人是不是可以干别的，以后是不是可以不用招人了业务扩展以后，少发了工资也就是少发了钱。第三是少赔钱，过去业务流程上有某个风险点，比如说过去某个客服员工发脾气，对顾客一顿情绪发泄，导致客户流失，后续采用AI，规避掉了这种风险，避免了客诉，可以少赔一点钱。 通过标准：能有一项硬性指标，即可通过，例如带动间接增长100万，每日节省时间8小时，也就是1人力，可以有效减少损失50万之类的，项目期初为了立项，大体预估一个是可以的，但是不要太高。 2. 业务场景评估 ：在通过第一步后，就开始下场进行需求调研，分为两个方面。其一是业务流程，开发完这个产品后，只是针对于个人或者部门去使用的单点产品，还是能够有效的改变现有流程，实现跨部门沟通协作，例如客服Agent项目里，过去是客服被动回复消息，现在开始角色变化，客服变为前沿的业务洞察，能够反哺研发部门和营销部门以及运营部门，形成一个跨部门协作沟通的流程。其二是该业务流程当中是否涉及很多认为主观判断因素，如果大部分都绕不开人为判断的话，也不建议上线，因为后续修改变动风险较高。 通过标准：只要是针对单个部门以上且主观判断的仅占全流程的20%，即可通过 3.接下来便是 数据流 了，第二条将的是业务流程，第三条就是数据是如何流转的，通常是分布在各个杂乱的业务系统，或者是Excel，或者是某几位老员工的经验，甚至是从第三方平台下载的，就需要考虑是否能获得稳定的数据来源了。 通过标准：如果是外接数据，API接口必须稳定，如果是企业内部数据，不得超过了3张手工表维护（也就是不能人为去判断填的数据不能超过3张，超过说明现有业务流程就是有问题的，理想情况下是所有数据都有线上化） 4. 产品稳定性 ：其实也就是风险点，在上述工作都准备完成后，接下来就到了风险评估。一是是否能接受AI的稳定性，假如AI犯错了怎么办，要如何最短时间内预警发现，业务部门是否有应对方案，这个时候通常情况下是，建立数据质量监控看板，由业务部门去整理核心指标，如果有异常数据直接发送到飞书或者钉钉群聊。二是后续如果组织架构调整，业务流程变更，AI产品需要迭代的时候，成本高不高，要IT部门评估二开的费用。 通过标准：业务部门能出紧急应对方案，IT部门在产品开发的时候能有一定产品迭代方案。 （如果实在找不出也可以，但是需要IT领导和业务领导签字确认） 5. 组织风险预警 ：也许这个产品真的很好，但是AI的诞生，公司里一定有同事是抗拒的，按照项目管理的说法是，要找出干系人，利益者，谁有可能会在整体项目进展的过程中，去卡你，而你至少需要获得一名大领导的支持站台，否则后续很难推进。（个人经验：项目开展前由各个业务负责人指派一个PO，明确跟考核挂钩，并且中途可以换人） 以上是我个人的一些经验，有的人会说，哎呦也要算一下ROI，投入产出比，其实个人的话不建议，因为你要是明确了你的ROI，就等于后续是给你自己挖坑，不要给业务那么大的预期，做好上面的这5点，差不多了，90%的企业是够用了。上面内容主要还是个人认为比较重要的5点，其他的不是问题，项目开展会遇到各种问题，加油吧各位佬有。 2 个帖子 - 2 位参与者 阅读完整话题
有没有经验丰富的佬友给点建议，工作和生活该如何平衡？30岁已婚，处于要工作就没生活，要生活工作技能就会提升的很慢的境地，很崩溃，要怎么办？ 4 个帖子 - 4 位参与者 阅读完整话题
有推荐的JS逆向技能或者补环境逆向技能吗 求佬友推荐几个好用的 1 个帖子 - 1 位参与者 阅读完整话题
用过的有opencode,trae,pi,generic等agent，opencode和generic我用的是app端的。但是似乎是因为generic是py构架的所以有点吃配置啥的，所以就在尝试将generic的内容迁移到pi agent里面去（虽然pi也有bug，但是贵在它轻量和opencode差不多的感觉，日常用起来都不错）。有没有佬试过的说说案例？pi本身也是有缺陷的：不如generic的浏览器用的好。目前正在尝试ing 1 个帖子 - 1 位参与者 阅读完整话题
OpenAI 现在有官方的 Agent Skills 仓库，里面分 .system 和 .curated 。我翻了一下，感觉比自己从零写 Skill 更适合入门：先看别人怎么拆任务边界，再改成自己的版本。 官方仓库： GitHub - openai/skills: Skills Catalog for Codex · GitHub Codex Skills 文档： Agent Skills – Codex | OpenAI Developers 我觉得优先看这几个 1. playwright 适合做浏览器自动化、截图、页面检查。前端开发时特别有用，因为它不只看代码，还能实际打开页面验证。 2. pdf 适合处理 PDF 读取、渲染、检查版式。比让模型直接“猜 PDF 内容”靠谱。 3. openai-docs 这个很适合学习“如何把官方文档查询流程写进 Skill”。当任务涉及更新很快的 API，Skill 应该强制查官方文档，而不是靠模型记忆。 4. gh-fix-ci / gh-address-comments 这类 GitHub 工作流技能值得看，因为它把“读失败日志、定位原因、修复、验证”的流程写得比较明确。 5. security-best-practices 安全类任务尤其适合做成 Skill，因为检查清单稳定，而且不能靠临场发挥。 安装方式 官方 README 里提到可以用 Codex 里的 $skill-installer 安装 curated skill，例如： $skill-installer playwright $skill-installer openai-docs $skill-installer gh-fix-ci 装完后重启 Codex，让新技能被发现。 我学到的 Skill 设计原则 描述要写清楚“什么时候用”。 大文件放 references，不要全塞进 SKILL.md。 重复操作写 scripts，让模型调用脚本。 输出格式固定，减少每次漂移。 如果你准备自己写 Skill，建议先抄官方 skills 的目录结构，不要一开始就发明新范式。 1 个帖子 - 1 位参与者 阅读完整话题
前端开发只看代码很容易漏问题：按钮溢出、移动端遮挡、canvas 空白、深色模式对比度不够。这个场景很适合做一个 Playwright 视觉检查 Skill。 OpenAI 官方 skills 里也有 playwright / playwright-interactive ，可以参考： github.com GitHub - openai/skills: Skills Catalog for Codex Skills Catalog for Codex Skill 目标 让 agent 在完成 UI 改动后，自动做这些事： 启动 dev server。 打开页面。 截桌面和移动端截图。 检查页面是否空白。 检查明显遮挡、溢出、报错。 把截图路径和问题列出来。 SKILL.md 草稿 --- name: frontend-visual-check description: Verify frontend UI changes with Playwright screenshots across desktop and mobile viewports. Use after implementing or modifying visible UI. --- # Frontend Visual Check When active: 1. Start the project dev server using the repo's documented command. 2. Open the changed route in a real browser. 3. Capture desktop and mobile screenshots. 4. Check for blank page, console errors, overlapping text, and broken layout. 5. Report screenshot paths and concrete issues. Default viewports: - Desktop: 1440x900 - Mobile: 390x844 Do not mark UI work complete if the page is blank or visibly broken. 为什么要做成 Skill 因为视觉检查是稳定流程，不应该每次重新教模型。 尤其是这些场景： dashboard landing page canvas / Three.js mobile layout 表格、弹窗、侧边栏 我会加的一条硬规则 If the screenshot is blank, stop and debug rendering before summarizing. 很多 AI 前端翻车不是代码没写，而是页面根本没渲染出来。 这个 Skill 很适合作为前端项目的项目级技能。 2 个帖子 - 2 位参与者 阅读完整话题
安全检查很适合做成 Skill，因为它有稳定 checklist，而且容易被普通开发任务忽略。 OpenAI 官方 skills 里也有 security 相关技能可以参考： github.com GitHub - openai/skills: Skills Catalog for Codex Skills Catalog for Codex 我会检查这些点 是否误提交密钥、token、cookie。 是否把 .env 、日志、私钥放进仓库。 新增接口有没有鉴权。 用户输入有没有校验。 文件上传有没有类型和大小限制。 SQL/命令/路径拼接有没有注入风险。 依赖有没有明显高危包。 SKILL.md 草稿 --- name: security-check description: Check code changes for secrets, authentication, authorization, input validation, injection risk, and unsafe file handling. Use before merging backend, auth, upload, payment, or infrastructure changes. --- # Security Check Focus on exploitable issues, not generic advice. Check: 1. Secrets and credentials 2. Authentication and authorization 3. Input validation 4. SQL/command/path injection 5. File upload safety 6. Dependency and config risks 7. Logging of sensitive data Output findings with severity, file path, impact, and minimal fix. Do not suggest large rewrites unless required. 适合触发的场景 登录注册 权限控制 文件上传 支付回调 Webhook 数据库查询 脚本执行 CI/CD 配置 不适合触发的场景 普通文案、颜色、布局调整就没必要跑完整安全检查。 所以 description 里最好写清楚：什么时候用，什么时候不用。 我的经验是：安全 Skill 不需要很长，但 checklist 要硬。 2 个帖子 - 1 位参与者 阅读完整话题
发版前写 release notes 很容易临时翻 git log ，然后漏掉 breaking change 或迁移说明。这个场景适合做成 Skill。 目标 让 agent 根据 git diff、commit、PR 标题，整理出稳定格式的发布说明。 SKILL.md 草稿 --- name: release-notes description: Generate release notes from git history, merged PRs, and changed files. Use before tagging a release or publishing a changelog. --- # Release Notes Collect: 1. User-facing changes 2. Bug fixes 3. Breaking changes 4. Migration steps 5. Known risks 6. Verification commands Output: ## Highlights ## Changes ## Fixes ## Breaking Changes ## Migration ## Verification 我会加的规则 Do not include internal refactors unless they affect users or operators. If a migration is required, put it in Breaking Changes or Migration. If tests were not run, say so explicitly. 使用方式 Use release-notes to summarize changes since v1.2.0. Read commits and changed files. 如果项目有 GitHub PR，可以再加： Group changes by PR and preserve links. 为什么值得做成 Skill release notes 的格式应该稳定，否则每次发版都像重新写作文。 固定格式之后，团队成员看起来也舒服：哪些是功能、哪些是修复、有没有 breaking change，一眼能扫到。 1 个帖子 - 1 位参与者 阅读完整话题
最近看 Claude Code Skills 文档，最大的感受是：Skill 不应该写成“万能提示词”，而应该写成一个边界很清楚的小工具包。 官方文档： Extend Claude with skills - Claude Code Docs Agent Skills in the SDK - Claude Code Docs 我理解的 Skill Skill = 一段可自动发现的说明 + 必要的脚本/模板/参考资料。 它适合沉淀那些你经常重复做、而且流程比较稳定的任务，例如： PR review 生成 changelog 检查论文格式 按项目规范写测试 根据设计稿实现页面 不适合把所有偏好一股脑塞进去。那样模型每次都要读一大坨，反而容易失焦。 最小结构 my-skill/ SKILL.md scripts/ templates/ references/ SKILL.md 最关键的是 frontmatter： --- name: pr-review description: Review code changes for bugs, regressions, missing tests, and risky behavior. Use when the user asks for code review or pre-merge checks. --- # PR Review Read the diff first. Prioritize correctness issues over style. Report findings with file path and line reference. description 要写触发条件，不要只写“一个很强的 review 技能”。模型是靠描述判断什么时候加载的。 我建议的写法 一条 Skill 只做一类事： review 就只 review deploy 就只 deploy paper polish 就只处理论文 screenshot 就只做截图和视觉检查 如果一个技能里同时写“审查、重构、部署、写文档”，最后就很容易变成大型玄学 prompt。 判断一个 Skill 好不好 我会看三点： 触发场景是否清楚。 输出格式是否稳定。 有没有可复用脚本或模板，而不是全靠模型临场发挥。 这个思路对 Codex 的 Agent Skills 也适用。后面我准备把常用的 review、Playwright 截图、项目初始化都整理成技能。 1 个帖子 - 1 位参与者 阅读完整话题