skills，真的重要嘛？大家来讨论下吧。

[mfsw]

对于 codex 5.5 来说，个人开发网站应用，下面的这些 skill ，哪些是比较推荐的？谢谢大佬指教。 superpowers

Brainstorming

grill me

Frontend Design

claude-design

UI UX Pro Max

claude-mem

Gstack

harness

Matt 的前端 Skill

ponytail

[junwind]

skill ，mcp 等等东西，对于大模型，我个人觉得都是阶段性的产物，就像电车现在续航不够的，就出现了混合，增程。我相信未来就是朝着言出法随演进。

[ndxxx]

skill 就是「言出法随」里的「言」，大部分人的语言表达能力和对特定知识领域的总结，都不如具体的 skill 。

但凡看一眼 SKILL.md 也不会问这种问题😅

[yidinghe]

什么是 skill：
skill 用于具体的、有结果有输出的操作，而不是一堆模糊的原则性的指导。例如从指定的位置收集指定的信息然后生成指定格式的报告。

什么时候创建 skill：
你有重复性的工作要做，又不想为此劳心劳神开发一个应用，那就用 skill 描述一个，很快捷。

skill 做不到的：
首先 skill 是上下文的一部分，所以它不能帮你管理上下文。其次 skill 是按需加载的，所以 grill-me 和 karpathy 指南这类，更适合直接写入 SOUL 而非写入 skill 。

[YanSeven]

你就算是上帝来了，复杂一点的需求，定制化的流程，你也不可能一句话表述清楚吧。
轻量的简单的 skill 作为一种可复用的流程化的东西，本身就是很普通的一枚螺丝钉，没有什么重不重要的。

那种重型的想搞成框架性的 skill 到是迟早会被扫进垃圾堆。

[evan9527]

我的理解：
一个项目你输入 A 想要得到 B 的结果，中间可能需要大量沟通和试错成本，
skill 就是一套可以复现、可调试，稳定的输出流程,可以节省中间环节的成本。

[laminux29]

楼上没有一人讲到本质。

skill 、mcp 的本质是通过接口调用的方式，帮你减少提示词，原因是目前大模型的输入窗口太小。

[unusualcat]

看对于什么人群来说的。如果都是程序员，用同样的 ai ，那基本上不重要。因为同样的任务，让同行来做，都能得到达标的结果。区别可能在于花费的 token 以及完成任务的整体时间上。
如果是程序员和岳云鹏开发同一个项目做对比的话，那 skills 就显得比较重要了。

[HeStudy]

我理解的 skill 其实就是面对大模型的 sop ，现实的业务流程是复杂的，严格来说不存在所谓的完全通用的 skill ，但是你可以把很多个小型 skill 进行组合、魔改，最终变成适合你的 skill ，拿 superpowers 来说，其实我只需要它的头脑风暴和 tdd ，而它的并行子代理开发我并不需要，因为我觉得这玩意很慢而且很耗 token ，那就结合自身的需要去按需使用或者 fork 仓库，造一个你自己觉得好用的。

总之就是，目前这些所谓的工程 skill ，你最好亲自去挨个尝试一下，看看哪些你觉得顺手或者可以自己改造为适配你自己的，我目前的流程基本就是头脑风暴用来疯狂追问，澄清需求，然后制定 plan ，再丢给 tdd 开发，最后使用 agent-browser 或者 computer use 进行验证调试。

[jaskell]

有用，包括 MCP ，大模型不可能解决一切问题，分场景有不同的落地方案，skills 和 MCP 都是，我实际使用下来的感受是这样的。skills 解决引导大模型如何做事的问题，避免同样问题反复和大模型沟通交互，MCP 解决有些场景比如操控各种硬件设备的能力问题，发现都是工程问题的解决方案，和大模型无关

[GeruzoniAnsasu]

skills 就是个渐进式披露的文档树，并且独立于你的项目之外。理解这点之后你就不会问这种问题，就好比


> homebrew 大伙用得多吗，都装了哪些工具，来讨论下吧

[Krman]

用哪些，用多少 skill/mcp ，取决于你的工作内容。每次 session 启动时一次性加载过多且不相关的 skill/mcp 对 context 是有不同程度的污染。建议对于工作内容差异过大的项目，在不同项目目录分别设置不同 skill ，不要所有 skill 把塞进根目录。

[wxyz]

我是后端开发，我现在只用 openspec+superpower 这两套 skill ，梳理核对需求、拆分开发任务都很好用啊。
MCP 主要是联网搜索+数据库相关 MCP ，自动做集成测试用的。
现阶段 AI 还是需要一套规范流程的，人的需求没办法完美的同步给大模型，需要反复核对需求和设计方案的。

[flionay]

@laminux29 笑，意思接口调用的方式就不占用模型窗口大小了吗

[refear99]

通用开发完全不需要，特别是在用 codex 的情况下，codex 的 agent 自带的提示词和工作流优于任何目前的通用 skill

但是公司内部流程是需要的，比如下面是一个平安保险 pdf 的查询 skill

```
---
name: pingan-health-pdf
description: Look up Ping An Health Insurance public disclosure PDF material URLs by product name and return JSON data. Use when a user asks for 平安健康险 / 平安健康保险 product PDFs such as 产品条款, 费率表, 产品说明书, 特定清单, 现金价值表, 合同条款, or public disclosure materials by product name.
---

# Ping An Health PDF Lookup

## Goal

Given a Ping An Health Insurance product name, find public disclosure material URLs from each matched product's `contentReference` JSON. Search both product pools by default:

- 在售保险产品: `12105675798371923550`
- 停售保险产品: `14411518807585587486`

Known material keys:

- `productTerm`: 产品条款
- `rate`: 产品费率表
- `instructions`: 产品说明书
- `specialList`: 产品特定清单
- `cashValue`: 产品现金价值表

Return JSON only. Do not summarize as prose unless the user explicitly asks for explanation.

## Workflow

1. Query both tags using the product name.
2. For each matched product, read `contentView.contentReference`.
3. Fetch the `contentReference` URL; it returns JSON containing PDF/material entries.
4. Normalize every non-empty material entry into `materials[]`.
5. Return exactly one JSON object with a top-level `data` field.
6. If no exact result is found, retry with a shorter title fragment. If still none, return `{"data":[]}`.

## Product Query

Endpoint:

```text
POST https://mcore.health.pingan.com/bff/content/info/queryHistoryVersionList
```

Headers:

```text
content-type: application/json
origin: https://health.pingan.com
referer: https://health.pingan.com/
```

Body template:

```json
{
"pageSize": 10,
"pageNo": 1,
"tagId": "<TAG_ID>",
"type": 7,
"leaf": true,
"title": "<PRODUCT_NAME>"
}
```

Important response fields:

- `data.data[].productCode`
- `data.data[].onSaleAt`
- `data.data[].offSaleAt`
- `data.data[].productLevelCode`
- `data.data[].contentView.title`
- `data.data[].contentView.publishedAt`
- `data.data[].contentView.contentReference`
- `data.data[].contentView.contentContentTags[].tag.name`

## Output Format

Return exactly one valid JSON object:

```json
{
"data": [
{
"title": "产品名称",
"product_code": "产品代码",
"product_level_code": "产品分级",
"on_sale_at": "开售时间",
"off_sale_at": "停售时间",
"published_at": "发布时间",
"status": ["在售保险产品"],
"content_reference": "contentReference URL",
"materials": [
{
"key": "productTerm",
"label": "产品条款",
"filename": "文件名",
"url": "PDF URL",
"raw": {}
}
]
}
]
}
```

Output rules:

- Output JSON only.
- Do not wrap the JSON in Markdown fences.
- Do not add explanatory prose before or after the JSON.
- `data` is always an array.
- `materials` is always an array.
- Include every non-empty material key and every file entry.
- Use the Chinese label for known material keys; preserve unknown keys with `label` equal to the key.
- For object entries, set `filename` from `filename`, `name`, or the label. Set `url` from `url` or `link`, or empty string.
- For non-object entries, set `filename` to the label, `url` to the string value, and `raw` to the original value.

## Python Option

Use this when Python 3 is available. It only uses the Python standard library and prints the required JSON shape.

```bash
PRODUCT_NAME='平安互联网全家福住院医疗保险' python3 - <<'PY'
import json
import os
import urllib.request

```

[zuopenn]

skill 本质不就是上下文提示词吧，只不过称之为 skill

[luckyc]

skill 让 llm 快速了解内部的一些平台, 操作内部平台啊, 我感觉是必备技能.

[S0lution]

你是总监，模型是你的员工，SKILL 是你们部门的产出规范，没有规范除非你对你员工的要求细致到原子需求层面，否则你十个员工会出来十个不同版本
随着你员工技术越来越厉害 工作越来越规范，逐渐你不需要给他们下规范他们的产出也会趋于同化，也会更符合你的要求

[starlion]

skills 就是让 ai coding agent （ LLM ）怎么更好工作的一系列指令
别人探索出的一系列流程指令指挥 LLM 更好干活，然后总结出来，就是它使用 AI 最佳实践总结
我们可以借鉴、学习、使用

[starlion]

别人总结的领域专业知识，然后串成工作流程，喂给（指挥） AI 干活

[dobelee]

Skills ，你可以粗暴地理解为索引。
那你觉得 MySQL 索引重要吗？

[friz]

非常重要，技能既能量化自己的，也能学习其他人的

[YYDC]

原先提需求需要巴拉巴拉一大堆，现在只用 grill me

[mooyo]

superpowers github core-review simplify-code

我只用这几个

[encro]

@laminux29

你这本质不对。。。

skill 的本质是流程沉淀和经验复用。

mcp 的本质是向大模型提供标准化的接口。

一般理解这两个本质，就不会问这些问题了。




当前大模型已经可以逐步 skill 内置了。所以 skill 也越来不重要了。

以前我用 superpowers 惊呆了，

现在觉得繁琐了。

因为大模型会根据你的问题，分析你的意图，然后给出最佳思考和解决路线了，以前 Brainstorming 是经验总结，让火车跑在轨道上，现在这类是限制，大模型已经是自动驾驶汽车了，很多时候不需要给他轨道了。

[Seulgi]

现在的 skill 其实很过度，有的模型甚至用着 skill ，用着用着就自己疯狂改 skill 了，改的面目全非

[maymay5]

先把这项功能放在一边，其实程序员圈子里一直以来就有两类人：
第一类：工具、方法论、管理，等等面面俱到，整个项目都要井井有条，甚至严格遵守 PDCA 戴明环

第二类：不喜欢遵守这些，一个记事本记录所有，编译器启动即开写，简单测试就提交，主打一个松弛

所以再回归 skills ，需不需要取决于你属于上面的哪一类，你要是主打松弛，临时改一下 Agents.md ，临时加个 Hooks 也是可以的，你要喜欢井井有条，那就用 skills 目录管理一下，没有正解，只有适宜

[xxyzf]

skill 相当于函数封装； MCP 相当于 Agent 的开发文档。

[zhiyu1998]

以我玩 Hermes 的经验来说非常重要，至少重复流程一下就搞完了，不用再学习一次

如果玩 codex 还是 AGENTS.md 重要

[aarontian]

@laminux29 有利于缩减上下文没错，但 skill 可不是通过接口调用的方式

[zhoudian]

有必要的，抽象 skill 解决相同的问题

[lambdaX999]

我感觉万物皆可 skill ，简单来说就是一段脚本（或者一个完整的 python 项目）加 skill 的提示词，什么情况下用什么脚本。我现在用的比较多的就是 cli （连接外部系统，比如飞书 cli ，百炼 cli ，还有一些内部的）+skill ，我自己都写了很多 skill ，类似 workflow+脚本。有些特殊的系统就用 MCP 连接

[cherrychen]

都是提示词+脚本，可能有一些知识规则。这种重复性的工作可以形成 skills

[NewMoorj]

skill 就是一段高度定制化的提示词

[laminux29]

@flionay

如果你的语文差，看不懂我写的东西，可以把我写的东西，复制给 AI ，让它帮你中译中。

[laminux29]

@encro skill 目前没有官方定义，所以无论你怎么说都行，但你也不能说我的本质不对。

[laminux29]

@aarontian 不用接口怎么缩减上下文嘛。接口就是帮你屏蔽内部细节，只暴露接口与说明，从而达到缩减上下文的目的。

[SHIINASAMA]

重要，这就是新时代的短咏唱型魔法。skill 可以帮你快速完成很多可提炼的重复性工作

[cellsyx]

在 skill 这个概念提出之前，AI 辅助开发过程中输入的那些重复的，有固定格式的 prompt 段落（比如手动压缩上下文然后 handoff 到新会话继续当前任务，或者是基于当前修改内容生成符合格式要求的 commit message 等重复性流程化工作）实际上就是 skills ，它本就是 AI 辅助开发过程中自然产生的一个环节，当然重要了。

25 年底提出 Agent skills 和后续一系列的改进只是为这个必要的开发流程环节起了个名字，以及在各种 TUI 、GUI 的 IDE 中优化使用体验（例如 / $ 补全 skill 名称，还有在 IDE 层面支持 skill 的固化和快速调用）

[viskem]

施魔法的时候当然用快捷咒语，不会从头到尾说施放逻辑。Skill 就是如此。除非真没什么自己研究出来的魔法招式，那也确实就字面意思：“我没有技能”。

[way2explore2]

@junwind 我觉着 SKILL 是阶段性产物，MCP 不是，它是进化的 Standard ，就像 HTML 4 5 6 7 8 9

[JoJoWuBeHumble]

这就像你和我说 spring 对于 java 真的重要吗？
skill 能保证重复工作的稳定产出

[mfsw]

感谢诸位大佬热心讨论与指教。

其实我想问的是，你们常用的 skills 有哪些？

[paragon]

skill 本质其实就是懒加载的 prompt

[houOne]

我的选择是，让 GPT 带着我 创建一个 skill 然后理解一下到底什么是 skill

[lulinchuanllc]

skills 应该是某种思考的模式或做事情的方式，只不过之前只是某个人是这么想这么做的，他高效，总是直接要害，我们把他做的过程提炼出来，变成了 skills

[jyIssac]

其实我用来做模板资源设计，例如我在做一个农场游戏，在 skill 里面定义了通用属性和设计，最后我 @skills ，说 西瓜， 他就会给我按照我设计好的尺寸/风格/周期，相关去给我生成每个阶段的矢量图/webp ，做这种很短上下文的模板生成非常好用，最后还能调我的接口裁切上传对象存储

[iuh]

skills 能相对简单的去固化流程 还是挺有用的 但是在开发场景里 我感觉会被越来越弱化 因为模型足够强能很快理解到你要做什么。但是在 AI 去做业务流程中，他不可或缺

[a0210077]

类似于脚本/工具的性质，给大模型执行特定流程用。针对重复性工作可以省 token+稳定输出，尤其是大半是统一流程，小部分需要手动输入的工作有奇效
我认为有用，现阶段没有其他替代，通常脚本做不到大模型的变通，纯提示词做不到稳定输出

[HeyWeGo]

skill 就是格式化语言

[yanq123]

@laminux29 #6 本质是沉淀工作流方法论，不是减少提示词。减少提示词是工程产物

[fbu11]

skills 的确是现阶段的过渡产物， 但目前阶段还是挺重要的，至少不需要跟前两年一样，prompt 写一大堆，很多 skills 定义好了模板，省去了很多时间，也进一步帮不懂技术或者 AI 的人以及不会写 prompt 的人使用 AI ，没有 skills 之前不会写 prompt 真的难倒一大批人，现在就还好。
要想走到真正的 AGI 还早着呢。

[fkdtz]

@laminux29 #6 我要是能像你这么自信就好了

[sprinng]

这个轻量,大家可以试试 https://github.com/doccker/cc-use-exp

[Allendeng]

没用

[rphoho]

现阶段重要，团队里对比下 skill 用得好的人和不用的人，产出的质量和速度简直天差地别。

[paradoxie]

举一个我的场景收益最大的例子，我会把已经完成产品化的项目的部署流程非常细致地全部 skill 化，这样每次就能顺利自动完成稳定的部署和接口验证测试了，不至于每次打字，ai 每次还需要去找相关配置进行部署，这种不确定太高了

[loryyang]

我其实用得不多，很多东西写成文档就好了，需要的时候让模型读一下就可以了
我觉得要做成 skill 的情况是：多项目之间复用，或者有脚本、资源等复杂的能力融合。大部分就一段提示词的功能，也没必要做成 skill

[loryyang]

@loryyang #57 另外一种 skill 的模式是市场模式：某些人开发，其他人下载使用
这种场景我觉得，实际效果不如它看起来那么好。因为每个人的场景总是有那么些不一样的，而开发者因为看不到实际场景，会尽量写得面面俱到。拿过来直接用，大部分情况下，也就是个 60 分的效果，想要好，还是得自己慢慢迭代。
这种公开的 skill ，我一般就是拿来参考下，挑一些有价值的东西写到自己的项目里面去

[diudiuu]

我觉得有用的就是 mcp ，比如抓取一些网站，正规得可能人家不允许抓，ai 也会抓取失败
我自己写了一个学习得程序什么都可以抓，集成为 mcp ，让工具接入到 mcp ，后面就直接用我自己写的了。

[bgm004]

superpowers 已经删除了，一堆繁琐的 plan 和 task 后写出来的还是不如人意。

[asAnotherJack]

相当于提示词的封装吧，如果不用 skill ，你想用某个流程的时候，直接把一大篇说明通过提示词告诉 AI ，也是一样的，写个 skill 相当于能复用这一大篇说明。重要不重要的，看你这个流程会不会重复用吧，如果经常重复用写个 skill 总比每次复制方便一些

[hongxiansen]

第 1 周, 0 skill.
第 2 周, 发现总要说 "帮我部署到 xxx 服务器, 端口转发是 44000 ~ 44100, 这部分我配置过端口转发", 于是让 AI 帮我建一个 skill, 下次我只需要说部署到 xxx.
第 3 周, 有个总控项目, 是个监控看板. 收集我的其他项目. 我希望新建一个项目时, 自动加到这个里边, 于是让 AI 加了一个 skill.

...

skill 对我来说, 是我发现自己在 repeat, 那就通过 skill 来 dry.

我或许可以说 "你查看一下我的所有 session 聊天记录, 看看有没什么值得提取出 skill 的, 注意一定要有必要的才这么做, 高准确度, 而不是高召回率."


我也看到很多人分享 skill, 也焦虑要不要用. 我觉得正确答案是, 当我纠结时, 直接同时都跑一下, 对比一下用的效果和不用的效果. 慢慢收集这个感觉, 直觉. 可能这样 skill 才能变成工具, 而不是另一个黑盒子.

(AI 这个黑盒子我感觉已经很难受了. 但太好用了, 上瘾了戒不掉)

[zhengqiang64]

skills 是说明书，当你不擅长某个东西时，提供说明书自然事半功倍。但相对灵活性的任务，一般是不需要这个说明书的。否则等于给 agent 套在一个知识框架里，他思考问题都会先看看能不能套用这个说明书。
比如把一些 api 封装成 skills ，把一种调度方式封装成 skills ，这都有助于某些目的明确的开发。但如果换一个不相干的任务，他也会先看下这个 skills ，哪怕没触发 skills 后续的作用，但也影响到了他的思考。也就是注意力被分散了。因此我认为除了必要的时候，安装必要的 skills 外，其他那种所谓优化的流程的 skills 是能不装就不装。