- Jhj2026-08-19
题主在整理留用答辩资料时，偶然悟到当下skills设计的误区。严格上来说，也不是误区，只是不适合题主这种菜鸟。
很多文档产出类skill都会在最终给用户产出的文档末尾加上“本次不做的范围”等诸如此类的内容，然后列出一些不做的点。是什么原因导致了这样的现象？以下谈谈我的看法。
- 这些skill解决问题的思路是做减法
针对某类问题，将skill的通用性拉满，即，这个skill是奔着可以解决所有场景下的此类问题去设计的。然后再搭配使用时由用户显式声明不做的点或者说不考虑的范围来解决问题。这也正是很多人没法用好很多技术大佬口中那个“好用到极致”的skill的原因，因为他们的经验更丰富、做减法的能力比一般人更强。而普通人在使用时就会出现类似“过度设计”的问题，原先并不复杂的问题，ai给出的方案却很复杂，这正是因为我们没有做好减法。
- 而更适合大众的skill，应该围绕做加法去设计
只保留解决某类问题面临的共性的点，剩下的应该用户结合自己面临的场景去思考还需要考虑哪些点。这也正是最近很火的PiAgent的设计思想，仅提供必要的能力，剩下的由用户结合自身具体情况给agent添加能力，这就是在做加法。
主楼 - nanbloom0012026-08-19
好的 skill 应该就是能在合适的时候自动触发吧，只不过像 superpowers 这种写死了每次都需要触发，所以可能导致效率比较低
- Crazy-092026-08-19
我现在做skill，都是围绕特定情况写的，定制化比大众skill更准确，不过情况很多，一直在优化，针对某些功能专门设计
- nifengfei2026-08-19
- aqqwiyth2026-08-19
又是面向对象的老本行了 封装继承多态。 把一堆基础的tools通过skills封装，然后在封装出一个service 再封装成独立的场景。。。。```
┌───────────────┐
│ Case │
│ 工单上下文 │
└───────┬───────┘```中间塞一个tool skill的使用实践skill ， 再加一个历史优质工单排查case的指引，剩下的交给模型去编排。
同时一个skill指向文档索引，数据库表字段摘要、迭代记录…大杂烩```
│
▼
┌───────────────────────┐
│ Support Orchestrator │
│ │
│ 理解问题 │
│ 规划排查步骤 │
│ 选择 Skill │
│ 保存 Evidence │
│ 判断下一步 │
└──────────┬────────────┘
│
┌─────────────────┼──────────────────┐
▼ ▼ ▼
Knowledge skill Read Tools Write Tools
DWS SQL nacos skill
飞书 ES Case更新
nacos - nanbloom0012026-08-19
佬友你的意思是用 skill 来编排 skill 吗？就是区分原子能力 skill 和调度 skill？
我之前也尝试基于 skill 做一个 workflow，就是把调用具体工具的能力封装进单个 skill，然后到具体任务的时候，使用编排类型的 skill 来调用这些 skill
- aqqwiyth2026-08-19
这个问题的本质还是使用人对AI还存在幻觉 （现阶段 解决一个问题5~10块钱token ，就帮你解决了鼠标点点戳戳的问题）。
市面上做的大部分的skills都是底层或者一些HTTP的API的封装 （至少数据分析的效果牛逼了）
其实解决不了太多实际生产的场景（不用杠我，能解决部分 但是真有问题的时候 你自己可能都不用 假设有一次出幻觉你会帮使用人背锅吗）
解决一个很垂直的问题，干嘛不直接写死成一个固定的脚本。
所以我也是写着玩的 逃:）
有些问题一旦上升到ROI 发现还是人便宜
- Sane2026-08-19
这个样子会导致效率问题吧，每多一层都要多加载一次skill