Skill、MCP 等等 AI 外围工具，本质是 markdown 小作文吗

[Chuckle]

不清楚现在 AI 编程是怎么运作的，问问大伙。

一堆有结构的 markdown 组合起来，还有些 markdown 用来描述每个 markdown 干什么的，让 AI 挑着读？

看起来还有 json ，用来结构化描述这堆 markdown 作用，或者 AI 平台会用写好的代码读取这个 json ？

至于 markdown 里，就是没有特定结构的自然语言咯？描述规则、规范等等？

AI 客户端会让我们把这堆东西按一定目录结构放到特定文件夹里？比如一个项目里面的.claude 、.cursor 、.agents 、AGENTS.md 等用于提供给不同 AI 客户端用？

要是需要让 AI 调用外部代码能力的情况，就是 http 请求或者 stdio 通信？比如起个本地后端服务用于获取一言，那 markdown 里就写请求地址、入参出参长啥样？ AI 模型判断到自己需要调的时候，就会去发请求？发请求、读写本地文件、执行命令这些基础能力是 AI IDE 等客户端自带的？

所以和各种 AI API 发请求时，除了校验、会话 id 、模型调参之类的，就只是在传这些 markdown 和上下文组成的字符串？不能一股脑都传过去吧，怎么实现按需传的？

[povsister]

恭喜你发现了 AI 的本质：写小作文和当复读机

[Chuckle]

cursor 的回答，看起来大差不差。

1. 一堆 Markdown + 「描述每个干啥」+ AI 挑着读？
对，就是这么设计的。

Cursor：.cursor/rules/ 里每个规则是 markdown （或 .mdc ），用 YAML frontmatter 写：
globs：匹配哪些文件时这条规则生效
description：这条规则在什么情况下有用
alwaysApply：是否每次都带
客户端/Agent 根据「当前对话涉及的文件 + 描述」决定哪些规则被加入本次请求，相当于「按需挑着读」。

Claude Code：.claude/rules/ 里也是多份 markdown ，可以用 frontmatter 的 paths 做路径匹配，只有命中当前工作文件时才加载对应规则，同样是「按需」。

所以：有结构的 markdown 组合 + 用 frontmatter/描述说明「每条干啥、何时用」+ 由客户端/Agent 根据当前上下文决定带哪几条，这个理解是对的。

2. JSON 是干啥的？给 AI 读还是给代码读？
两种都有：

给人/给 AI 的说明：很多项目里会有 README 、CONTRIBUTING.md 、AGENTS.md 等，是自然语言 + 一点约定格式（比如「## 规则」「## 命令」），主要给 AI 当说明读。

给程序读的配置：
Cursor 的规则列表/索引可能用配置（不一定是裸 JSON ，也可能是 YAML ）记录「规则文件路径、glob 、描述」等，客户端代码读这些配置，决定本次请求要附上哪些规则、以什么顺序。
Claude Code 的 .claude/settings.json 是结构化配置，给 Claude Code 客户端读，不是给模型当「正文」读的。

所以：JSON/配置 = 给客户端程序做「规则调度、匹配、优先级」； markdown = 给模型当「可读的规则/说明」。模型主要吃的是 markdown 内容，不是 JSON 结构本身。

3. Markdown 里是「没特定结构的自然语言」吗？
不完全是。通常会有约定俗成的结构，但不是严格 schema：

常见区块：项目概述、常用命令、目录结构、命名/代码风格、禁止事项、示例等。

仍然是自然语言句子 + 列表 + 代码块，没有强制「必须有哪些 key 」的 JSON 式结构。

有的客户端会约定简单 frontmatter （如 globs 、description 、paths ），其余正文自由写。

所以：半结构：有惯用区块 + 自然语言描述规则/规范，不是完全无结构，也不是完全像 API schema 那样死板。

4. 目录结构：.claude 、.cursor 、AGENTS.md 等
是的，各客户端有自己约定的目录/文件：

Cursor：.cursor/rules/（多条规则）、历史上有 .cursorrules 单文件。

Claude Code：.claude/（如 settings.json ）、.claude/rules/、根目录 CLAUDE.md 。

通用/多客户端：很多项目会放 AGENTS.md 或 README 里写「给 AI 的说明」，谁支持谁就读。

所以：是的，大家会把「给 AI 用的东西」按各客户端的约定放到特定文件夹（如 .cursor 、.claude ）或根目录固定文件名（如 AGENTS.md ），不同客户端各读各的。

5. 调外部能力：HTTP 还是 stdio ？谁发请求？能力谁提供？
两种都有，而且「谁发请求」要分清：

MCP （ Model Context Protocol ）里常见两种传输：
stdio：和本地进程用标准输入输出通信（例如本地 MCP server 、本地后端）。
HTTP：和本地或远程 HTTP 服务通信。

谁真正发请求：
模型只做决策：「我要调某个 tool （例如 get_hitokoto ）」。
真正发 HTTP 、读文件、执行命令的，是 AI 客户端（ Cursor/Claude Code 等）或 MCP 客户端。
客户端根据「当前可用的 tool 列表 + 模型选的 tool + 参数」去执行：发请求、调 MCP 、跑 shell 等。

Markdown 里写啥：若你自己写一个 MCP server 或 HTTP API （比如「一言」），一般会在规则/文档里写：请求地址、方法、入参/出参长什么样，这样 AI 在「工具描述」或上下文中看到后，才知道该选哪个 tool 、传什么参数。工具本身的 schema （名字、参数、描述）往往由 MCP server 或客户端配置提供，markdown 更多是补充说明、示例、注意事项。

所以：通信方式 = HTTP 或 stdio 都常见；发请求/读写文件/执行命令 = 客户端或 MCP 客户端自带或通过 MCP 获得； markdown 里写请求地址、入参出参是为了让 AI 正确选择并填写参数。

6. 和 AI API 发请求时传啥？「按需传」怎么实现？
传的是「一串」多段内容，但不会无脑全塞：

发给模型的大致组成：
系统提示（含「你是什么、默认行为」）；
被选中的规则/文档（上面说的「挑出来的」 markdown 等）；
对话历史（可能截断或摘要）；
当前用户消息；
有时还有「当前打开/选中的文件」等。
这些在客户端里会拼成一条或几条消息（例如 system + user/assistant 轮次），本质上就是字符串（ token 序列），再加上校验、会话 id 、模型参数等 API 元数据。

「不能一股脑都传」怎么办：
规则/文档：用 globs / paths / description 做匹配，只把「和当前编辑文件、当前问题相关的」规则附进本次请求；
代码库：用语义检索（ embeddings + 向量相似度）或路径/符号索引，只取「和当前问题最相关的片段」放进上下文；
对话历史：超过一定长度就截断、摘要或滑动窗口，保证不超模型 context 上限。

所以：和 API 交互时，除了鉴权、会话、模型参数，主要就是在传「选好的规则 + 选好的上下文 + 对话」组成的字符串；按需传 = 客户端用匹配规则 + 检索/索引 + 历史裁剪，只把「用得上的」塞进这次请求，而不是把整个仓库和所有规则都塞进去。

[Chuckle]

@povsister 怎么说呢，好像也没有比这更好的设计了 大模型 API 好像有个通用的 oneAPI 来着，看消息格式也是老熟悉的 schema 呀

[Chuckle]

那感觉要是团队协作的话，能搞个类似 git 的工具呀，记录每个人产生的 AI 改动及对应的对话啥的，然后每次对话结束都让 AI 自己总结这个项目注意的点，AI 对话时容易出错的地方等等到一个 markdown 里，不断迭代，这个项目就越来越被 AI 熟悉了？就是感觉久了之后仓库大小会爆炸。。。。

[Ketteiron]

本质是 string | (args) => string | Promise<string>，静态文本或者生成动态文本的副作用函数

[capgrey]

MCP 不是

[Adelell]

宇宙的本质是小作文

[Chuckle]

@capgrey 嗯，抓包看了下，mcp 是 schema fc ，skill 也放在 tools 里，看起来就是预设提示词，很灵活，大模型要了之后才把对应的 skill.md 读给大模型，神 token 啊

[s1n1an]

Agent 两大本质：工具调用（这个是主要的，MCP 也是工具调用）、提示词管理（ Markdown 小作文）

豆包/千问帮用户点外卖是工具调用； Agent 弹出个表单或者选择框让用户选择，也是工具调用； Agent 列出一个 Todo 清单，也是工具调用； Manus 的 Agent 可以读写文件沙箱、可以在沙箱里运行 Shell 命令，也是工具调用； Claude Code 在本地 ls 列出代码、grep 查询代码，也是工具调用。

但是，把上面每一个工具注册给 Agent ，都需要一个配套的 Markdown 小作文。

把 Skills 注册给 Agent 也要小作文；规范工具的调用方式，例如 Todo 清单只允许从上往下 done ，不允许修改已 done 的项，这也需要小作文，不然这个 Todo 会跳着执行或者突然被改掉了；很多 Agent 提供的例如 “深度研究”，其实也是提供一个 Markdown 小作文给 Agent ，让它的输出更高大上。

[yifangtongxing28]

聪明的程序运行像个人

[horizonl]

我觉得本质是工作流指导吧，告诉 ai 怎么操作。跟带新人干活一样

[charlie21]

怎么给人交代任务，就怎么给 LLM 写小作文。你甚至可以用语音输入写小作文再修改精简给 LLM 看

你甚至可以带着人才培养（ LLM 喂养，喂资料）的心情写小作文，喂养出一个又肥又大又聪明的 LLM 就可以宰了用了

一个 skill 里可以调用其它 skills
https://zhuanlan.zhihu.com/p/1999434374538618259

[Archeb]

我的理解：
Skills = 使用说明书(SKILLS.md) + MCP/CLI/TOOL 等调用方式 + 实现(JS,Py,Shell 等代码)
三者打包在一起就叫一个 Skill

[tlerbao]

@Archeb 整洁

[YanSeven]

promt 是 llm 这个黑盒子的唯一入口。那么能干啥。

[pollux]

对比之前的软件概念：
API 接口 = MCP （ api 是给程序调用的，mcp 是给智能体调用，各种 SDK 就意味着各种语言实现的 MCP ）
使用手册 = Skill (产品说明，使用手册，维修指南都是给人看的，Skill.md 是给智能体读取和理解的)
交付软件 = Agent (以前的软件有界面，有鼠标键盘操作，有各种增删改查，但有了 agent 智能体，不需要界面，只要对话就可以出结果甚至出图表，音频，视频画面，不过目前还是初期，但是后面会出现像钢铁侠里的贾维斯，全程只要对话就能得到想要的信息)

愚见：现在所有的概念都是为了智能体而服务。所以会出现几种可能性：
1. 传统软件把原来的 api 重新按 mcp 规范实现了一遍，把使用指南用 Skill.md 实现了一遍，都是为了方便 agent 调用，是与时俱进，补足了短板。如: MCP MySQL Server , nginx mcp server, Ansible MCP Server
2. 转换器： 不破坏原来的软件，通过中间层，利用 ai 来操纵原来的软件接口，如 playwright-mcp
3. 原生 MCP 软件：后面新出现的软件，要想有点竞争力，都会把 mcp 和 skill 当作基本功能，如 chrome-mcp

[jukanntenn]

你的理解是对的，但是可以取一个更好地名字简洁概括且显得更加高级：Context Engineering 。

[cellsyx]

预制提示词

[xiaket]

今天早上刚写了一篇和这个相关的: https://blog.xiaket.org/2026/context.html

[xxbing]

我用一个实际场景解释什么是 MCP 和 Skills 。
假设有一个网站 A ，它的前端和服务器之间做了加密通信。我现在想逆向分析它的加密流程，以及使用的密钥生成方式。
在以前，我们的做法通常是：
- 手动抓包
- 手动下载 JS
- 手动阅读混淆代码
- 把代码片段和抓包数据复制给 AI
- 再人工一步步对照分析
整个过程非常碎片化，人必须不断来回操作。
现在有了 MCP 和 Skills ，流程就完全不同了。
我只需要安装一个 Chrome Dev MCP （例如基于 Chrome DevTools Protocol 的控制服务）。
然后：
- AI 可以自动操控浏览器
- 自动打开网站
- 自动下断点
- 自动抓取加载的 JS / HTML
- 自动抓包分析请求
- 自动查看 runtime 变量
- 自动跟踪加密函数调用栈
也就是说，它不再是“看你给它的代码”，而是直接进入真实运行环境里操作。
那 Skills 是什么？
Skills 就是我预先写好的“专家级操作指南”。
比如我可以在 Skill 里写：
- 遇到无限 debugger 要如何 patch
- 如何 hook XMLHttpRequest / fetch
- 如何定位加密函数
- 如何追踪 key 生成逻辑
- 如何识别常见混淆模式
- 如何 dump 内存中的关键变量
- 如何避免页面检测 DevTools
- 分析完成后输出什么结构化结果
这些都是我多年的逆向经验总结。
MCP 负责“给 AI 手脚”
Skills 负责“给 AI 方法论”
两者结合之后，AI 不再是一个聊天机器人，而是一个可以执行复杂实操流程的自动化分析员。

[MindMindMax]

本质就是： 提示词 + 结构的混合体，客户端桥接执行。LLM 根据这份 “使用说明书”判断调用工具的方式与时机

[iv2ex]

我认同你对本质的理解。
不管用什么 SKILL 、MCP ，在和大模型协作的过程都是小作文。

只是不同的工具，封装了不同的对话职责。这就是程序开发的解耦和封装思维。

[Charles0929]

用户）排查 bug
claude or 其他 cli) 组装请求（当前终端存在的工具集、当前终端存在的 skills 、当前终端存在的 MCP 等）调用 LLM
LLM ）接收请求，发现 bug 是有 A 文件引起，响应：将 A 文件内容通过 工具 A 读取后 发给我
claude or 其他 cli) 工具调用获取内容，组装请求调用 LLM
LLM ）接收请求，响应
claude or 其他 cli) 根据 LLM 响应作相应处理。

Function Calling\MCP\Skills 这些都是丰富用户终端可以提供的能力（打开浏览器、点外卖、操作文件等）使用 Markdown 这一类是因为 LLM 就是一段文本预测另一端文本，类似成语接龙。

[bytesfold]

本质是 context 啊