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

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

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

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

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

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

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

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

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

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

楼上没有一人讲到本质。

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

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

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

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

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

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


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

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

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

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

通用开发完全不需要，特别是在用 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

```

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

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

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

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

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

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

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

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

superpowers github core-review simplify-code

我只用这几个

@laminux29

你这本质不对。。。

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

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

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




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

以前我用 superpowers 惊呆了，

现在觉得繁琐了。

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

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

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

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

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

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

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

如果玩 codex 还是 AGENTS.md 重要

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

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

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

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

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

@flionay

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

skill 就是格式化语言

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

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

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

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

没用

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

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

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