我的 skills 仓库：

以及我在 ChineseResearchLaTeX 里维护的 skills（更偏科研写作/LaTeX 工程化）：

还是那句话：开发和调试真不容易，如果这些东西对你有用，欢迎点个 Star 支持一下哈哈 (～￣▽￣)～

概览

• Prompt 工程从 “一句话问答” 演化到 “可复用工作流”：CoT、ReAct、工具调用、结构化输出一路把边界推到今天
• Agent Skill 本质上是把 Prompt + 规则 + 脚本 + 模板 “打包成工程资产”，从玄学走向可维护、可复现
• MCP 更像连接层（把外部工具/资源接进来），Skill 更像流程层（告诉 AI 什么时候、按什么顺序、用什么标准做事）
• 在 vibe coding 里，Skill 是“稳定的手感来源”：把最佳实践固化成可重复跑的动作，减少上下文遗忘与输出漂移
• 我自己的两套实践：通用开发辅助的 skills 仓库，以及面向科研写作工作流的 ChineseResearchLaTeX/skills

前言

如果把大模型当作一个“会写代码、会写文档、还能跟你讨论方案的同事”，那 Prompt 就是你跟它沟通的方式；而 Prompt 工程，就是你为了让沟通更稳定、更可控、更省心而做的“工程化改造”。

但小伙伴很快会发现：Prompt 写得再漂亮，只要换个场景、换个项目、换个模型，输出就会飘；而且你很难把一次成功的对话沉淀成团队可复用的流程。于是，Prompt 工程的下一步就很自然地出现了：把“会话技巧”做成“技能”——这就是 Agent Skill 的意义所在。

这篇文章我会先用一条相对“工程视角”的时间线把 Prompt 的演化说清楚，然后聊清 Agent Skill 和 MCP 的分工，再回到 vibe coding：为什么我认为 Skill 是这个时代最实用的 Prompt 工程形态之一，最后重点介绍我自己维护的两个 skills 项目，看看它们是怎么落地的。对了，我之前在《Claude code和Claude skills的工程设计》那篇里更偏“技能工程化设计”地聊过一次，这篇算是从 Prompt 的角度再补一刀。

Prompt 的发展历史

Prompt 这东西并不是 ChatGPT 才出现的。更准确地说：Prompt 一直是“人机接口”的一部分，只是在大模型时代它从“输入框”变成了“半个编程语言”。

一开始，大家主要靠 zero-shot / few-shot 在提示词里给模型“看几个例子”，GPT-3 把这种 in-context learning 的能力带入大众视野¹。随后，“指令微调 + 对齐”让模型更听话（你开始能用更自然的语言提要求），Prompt 的重心从“凑样例”转向“写清楚任务与约束”。

2022 年开始，Prompt 工程迎来第一个大跃迁：Chain-of-Thought（CoT） 把“让模型把推理过程写出来”这个技巧系统化了²。很多复杂任务（数学、推理、多步骤规划）第一次出现了可解释、可控的提升路径。紧接着 ReAct 把 “思考（Reason）” 和 “行动（Act）” 串起来：模型不仅要想，还要会用工具、会查资料、会迭代修正³——这基本就是后面 Agent 思路的雏形。

再往后，工具调用与函数调用逐渐成为标配：模型开始能稳定地产生结构化输出、调用外部工具、把结果再写回到最终回答里。你会发现 Prompt 不再是“让模型生成一段文字”，而是“让模型按流程做事”。甚至还有 Toolformer 这类工作把“用工具”当作可学习能力嵌进模型行为里⁴。

到这里，一个很现实的问题就摆在面前了：当 Prompt 变成“流程”，它就天然需要版本、需要测试、需要复用、需要部署——你总不能每次都靠手打和复制粘贴吧？于是 Agent Skill 这种“Prompt 工程化资产”的形态，就顺理成章了。

下面我用一个粗粒度时间线，帮你把这条演化脉络钉牢：

Agent Skill 和 MCP：有什么异同？

很多人第一次听到 Skill，会下意识把它当成 “更复杂的 Prompt”。这只对了一半：Skill 的确以自然语言为核心，但它的关键点是 工程化边界。

我更喜欢把它们理解成两个互补层：

• MCP（Model Context Protocol）是连接层：解决的是“模型如何安全、标准化地访问外部工具与资源”。比如连到 GitHub、数据库、文件系统、Notion、搜索引擎……让 AI 真的“能拿到数据、能做动作”。⁷
• Agent Skill 是流程层：解决的是“拿到工具之后，怎么按你的标准把事做对”。它更像一套可维护的操作手册：触发语义、步骤、输出规范、边界条件、必要时的脚本与模板。⁵

如果你看过 Claude 官方那篇对 Skills 与 MCP 的解释，会发现它的比喻非常贴切：MCP 像五金店的货架，Skill 像店员的经验⁶。货架能让你买到工具，但不会保证你把柜子修好；店员能把“怎么修”讲清楚，但也需要工具才能落地。

我这里再补一个更“vibe coding”味道的说法：MCP 解决“能不能做”，Skill 解决“怎么稳定地做对”。

一套 Agent Skill 怎么落地：我常用的最小骨架

如果你把 Skill 当成一个“工程资产”，那它就应该长得像工程资产：有契约、有配置、有确定性工具，有需要时再加载的参考资料。最小可用形态大概是这样：

my-skill/
├── SKILL.md          # 语义接口 + 工作流（给 AI 读的“剧本”）
├── config.yaml       # 参数与硬约束（把不确定性关进笼子）
├── scripts/          # 确定性执行（curl/py/sh/...，能跑就别让模型背）
└── references/       # 需要时再读（规范、模板、示例、FAQ）

这套结构在 vibe coding 里特别“顺手”的原因是：它让你可以把一个任务拆成两类信息——不那么精确但很关键的意图（写在 SKILL.md 里），以及必须精确、必须可复现的约束（写在 config.yaml/脚本里）。你越早把“硬约束”从 Prompt 里挪出来，越不容易被上下文漂移折磨。

为什么 Agent Skill 对 vibe coding 很重要？

vibe coding 的本质不是“让 AI 一次写完”，而是让你在高频迭代里保持心流：你不断提出意图、让 AI 跑一版、你挑关键点修正、再跑下一版。这里最怕两件事：一是模型“忘了规矩”，二是你“记不住上次怎么跑通的”。

Skill 在 vibe coding 里就像一个“外置小脑”：

它把你在项目里踩过的坑、总结过的标准、希望 AI 遵守的工程原则，固化成一个可触发的能力包。下一次你不需要再把规则解释一遍，也不需要担心 AI 临场发挥把风格写歪——你只需要说“用这个 skill 跑一下”，然后把注意力放在真正重要的决策上：架构、边界、验收标准。

更关键的是：Skill 天然鼓励 “模糊端与精确端分离”。SKILL.md 用自然语言讲意图和流程；config.yaml 用硬参数约束行为；scripts/ 负责确定性执行。你会发现这套结构特别适合大模型这种“强推理但不够确定”的协作者：该让它灵活的地方让它灵活，该锁死的地方就锁死。

我的 skills 仓库：把经验做成工具箱

我维护的 skills 仓库（huangwb8/skills）可以理解成一套“通用型 vibe coding 外设”：偏开发工作流、偏工程化、偏可复用。⁸

它的设计目标很直白：把我在项目里反复用到的动作，做成可被 Codex / Claude Code 等工具发现并调用的技能。比如：

init-project 会把一个新项目的工程指令（AGENTS.md/CLAUDE.md/CHANGELOG.md/README 等）一键生成出来，省掉你每次从零搭规则；auto-test-code / auto-test-project 这类技能会逼着你回到“先验证再动手”的节奏（否则 AI 改一堆你根本不知道哪里坏了）；git-commit / git-publish-release 则把“写 commit 信息、发 release notes”这些重复劳动也流程化掉。

如果你打开仓库目录，会看到它刻意做得很“朴素”：每个 skill 一个文件夹（比如 init-project/、auto-test-project/、git-commit/、install-bensz-skills/、write-skill-readme/），以及一个专门用来做“一键安装/复制部署”的 @install/ 目录。对我来说，这种结构最大的好处是：你不用记住一堆零散 prompt 的“暗号”，只需要记住 skill 名字，然后让工具去发现、去加载、去执行。

更实用的一点是：它把“部署”也当成工程问题处理。比如你想把整套 skills 同步到 ~/.codex/skills 或 ~/.claude/skills，就可以直接用仓库里的安装脚本（本质是复制部署，不玩花里胡哨的软链接魔法）：

# 参考仓库说明，按需选择 codex/claude 目标目录
bash -c "$(curl -fsSL https://raw.githubusercontent.com/huangwb8/skills/main/@install/install.sh)" -- -t codex

你会发现：这些技能看起来都不“高大上”，甚至有点像脚手架；但它们对 vibe coding 的价值很实在——减少你在工具和流程上的摩擦，把注意力留给“到底要做什么”。

实战：ChineseResearchLaTeX——从 skills 仓库长出来的科研写作项目

前面聊了那么多”概念”和”骨架”，这一节我想用 ChineseResearchLaTeX 这个项目做一次完整的实战拆解，让你看看一套 skills 在真实科研场景里到底长什么样、怎么协作、为什么这么设计。⁹

它是怎么来的

ChineseResearchLaTeX 最初只是一个 NSFC（国家自然科学基金）LaTeX 模板集——帮你把标书排得好看一点、格式不出错。但写过标书的小伙伴都知道，排版只是最后 10% 的事，前面 90% 的痛苦是：文献怎么找、立项依据怎么写、研究内容怎么编排、旧标书怎么迁移到新模板……每一步都是高频重复劳动，每一步都容易出事故。

于是我就想：既然通用开发工具已经用 skills 仓库管起来了，为什么不把科研写作的”最佳实践”也做成 skills？ 它们本质上面对的是同一个问题——把人脑里的经验固化成 AI 可执行的流程，减少上下文遗忘和输出漂移。

所以 ChineseResearchLaTeX/skills/ 就这么长出来了：遵循和 huangwb8/skills 完全一样的骨架规范（SKILL.md + config.yaml + scripts/ + references/），但每个 skill 都专门面向科研写作的某个环节。目前一共 11 个 skill，覆盖从文献调研到标书终稿的全链路。¹⁰

四步工作流：从主题到终稿

如果说通用开发类 skills 更像”螺丝刀套装”——你随时拿一把出来拧两下就行；那这套科研向 skills 更像一条流程化生产线：它们之间有明确的上下游依赖关系，前一步的输出就是后一步的输入。

整条线大概是这样的：

get-review-theme          # 第一步：从任意来源提取结构化主题
       ↓
systematic-literature-review   # 第二步：多源检索 → AI 评分 → 专家级综述
       ↓
guide-updater              # 第三步：把综述洞见沉淀成项目指南
       ↓
nsfc-*-writer 系列          # 第四步：按指南写标书各章节

第一步，你可能手头有一篇论文、一段自然语言描述、一张思维导图截图，甚至一个网页 URL——get-review-theme 会把它吃进去，吐出”主题 + 关键词 + 核心问题”的结构化输出。这一步解决的是”我到底要综述什么”这个看似简单、实则经常含糊不清的问题。

第二步是重头戏。systematic-literature-review 大概是整套 skills 里最复杂的一个（光 SKILL.md 就 27KB）：AI 自定检索词、多源检索（MCP → OpenAlex → Semantic Scholar → Crossref，自动降级）、逐篇 AI 语义评分、高分优先选文、自动字数预算、资深领域专家自由写作，最后强制导出 PDF 和 Word。它有三个档位——Premium（旗舰级，对标 Nature Reviews，80–150 篇参考文献）、Standard（学位论文 Related Work，50–90 篇）、Basic（快速调研，30–60 篇）。你只需要给它一个主题，它就能从零开始跑出一篇有模有样的综述。

第三步很容易被忽略，但我认为它最关键。guide-updater 做的事情是：把综述里发现的核心不足、研究空白、可能的切入点，沉淀到项目指南文件里。换句话说，它逼你在写标书之前先想清楚”为什么要做这个研究””亮点在哪””现有研究的局限是什么”。这一步的产出不是给 AI 看的——是给你自己看的，是你和 AI 之间的”共识文档”。

第四步就是真正的标书写作了。nsfc-justification-writer（立项依据）、nsfc-research-content-writer（研究内容）、nsfc-research-foundation-writer（研究基础）各司其职，每个都只往自己负责的 .tex 文件里写，绝不越界。它们会读你在第三步沉淀的项目指南，确保立项依据的”科学问题”和研究内容的”子目标”是对得上的——而不是各写各的。

拆一个 skill 给你看

说了这么多，不如拆一个具体的 skill 看看内部长什么样。就拿 nsfc-justification-writer（立项依据写作器）举例吧——它是写标书时第一个要用的写作 skill，也是”模糊端与精确端分离”这个设计理念的典型体现。

它的目录结构是这样的：

nsfc-justification-writer/
├── SKILL.md          # 语义接口：工作流、写作标准、验收规则
├── config.yaml       # 硬约束：字数范围、禁用词、术语一致性矩阵
├── scripts/          # 确定性工具：安全写入脚本、诊断脚本
└── references/       # 参考资料：信息表模板、理论创新指南

SKILL.md 里写的是”怎么把立项依据写好”的专家经验：四段闭环叙事（价值与必要性 → 现状与不足 → 科学问题/假说 → 切入点与贡献）、渐进式写作引导（先骨架→再段落→再修订→再润色→再验收）、跨章节一致性检查（术语/缩写/指标口径要和研究内容对得上）。这些是”模糊端”——你需要 AI 的语义理解能力来完成。

config.yaml 里写的是”绝对不能违反的红线”：字数上下限（比如 3000–5000 字）、禁止出现的高风险表述（”国际领先””填补空白”这类评审一看就皱眉的话）、术语一致性矩阵（同一个概念在全文不能换着说法用）。这些是”精确端”——该锁死的就锁死，不给模型发挥空间。

scripts/ 里有一个安全写入脚本，它会定位 \subsubsection 标记位置，只替换正文段落、自动备份原文件。为什么不直接让 AI 写整个 .tex 文件？因为 LaTeX 模板的结构（宏定义、包引用、格式控制）是绝对不能被 AI “随手改一下”的，这种确定性操作就该交给脚本。

references/ 里放着信息表模板——这是你作为研究者需要提前填的”最小输入”：研究主题、核心假说、已有工作基础、目标期刊/基金类型。没有这个输入，AI 再聪明也只能瞎编。

你看，这就是前面说的”模糊端与精确端分离”在一个真实 skill 里的样子：SKILL.md 管意图和流程，config.yaml 管硬约束，scripts 管确定性操作，references 管输入规范。四件事各归各的文件，互不干扰。

为什么值得做成项目级 skills

你可能会问：这些东西直接写成一个很长的 Prompt 不就行了吗？干嘛非要拆成 skill？

答案很简单：因为科研写作是长流程、多文件、强约束的。一个标书项目，你可能要跑好几周；中间会换设备、换模型、换上下文窗口。如果你的”写作规则”只是一段 Prompt，它会在某一次对话里丢掉；但如果它是一个 skill，它就是项目的一部分——跟代码一样有版本、能 diff、能回溯。

而且科研写作有一个特殊性：你需要 AI 发挥创造力，但又绝对不能让它乱来。立项依据需要”讲故事”的能力（这是 AI 擅长的），但你不能让它编造参考文献（这是 AI 最容易翻车的）。把这种”允许发挥”和”严格禁止”的边界写进 skill，比你每次手动叮嘱靠谱得多。

最后，skill 化还解决了一个很实际的问题：团队协作。你写的 skill 可以直接给合作者用，他们不需要理解你的 Prompt 是怎么写的——只需要填信息表、跑 skill、看输出。这就把”个人经验”变成了”团队工具”。（写过标书的小伙伴应该懂我在说什么，哈哈。）

其它我觉得很重要的点

最后补三点我自己踩坑后越来越在意的“工程细节”，它们往往决定了一个 skill 到底是“玩具”还是“能长期用的生产力”。

第一点是把验收写进流程。很多人写 Prompt 只写“做什么”，不写“怎么判定对不对”。而一旦你把验收标准（输出结构、关键字段、必须存在/禁止出现的内容、回归测试方式）写进 skill，它就开始从“聊天技巧”变成“可交付流程”。

第二点是警惕工具输出里的 Prompt Injection。当你开始用 MCP 连接外部世界（网页、Issue、PR、邮件、文档），你就必须默认：外部文本里可能夹着“诱导模型违规”的指令。Skill 的价值之一就是把“哪些内容是数据、哪些内容是指令”这条边界写得更死：工具输出只当素材，不当指令；必要时做域名白名单、内容过滤、显式引用与复述，而不是原样吞进上下文。

第三点是持续瘦身。Skill 很容易越写越长、越堆越复杂，但真正好用的 skill 往往反而“短而硬”：关键约束写清楚，边界明确，能用脚本做的就脚本做，剩下交给模型的推理去完成。别把 skill 写成百科全书——写成“开箱就能跑”的操作手册更重要。

小结

Prompt 工程的演化，本质上是人机协作的演化：从“让模型说一句话”，到“让模型按步骤推理”，再到“让模型会用工具、会跑流程”。当 Prompt 变成流程，它就必须工程化；而 Agent Skill 之所以实用，是因为它把流程变成了可复用、可维护、可部署的资产——尤其在 vibe coding 这种高频迭代场景里，Skill 相当于把你的最佳实践固化成了稳定手感。我的 skills 仓库更偏通用开发工作流，而 ChineseResearchLaTeX/skills 更偏科研写作与 LaTeX 的长流程交付；两者共同指向一个结论：未来你真正积累的，不只是代码，而是“可复用的协作方式”。

参考

1. Brown et al. – Language Models are Few-Shot Learners. https://arxiv.org/abs/2005.14165
2. Wei et al. – Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. https://arxiv.org/abs/2201.11903
3. Yao et al. – ReAct: Synergizing Reasoning and Acting in Language Models. https://arxiv.org/abs/2210.03629
4. Schick et al. – Toolformer: Language Models Can Teach Themselves to Use Tools. https://arxiv.org/abs/2302.04761
5. Agent Skills – Agent Skills. https://agentskills.io/
6. Anthropic – Extending Claude capabilities with Skills and MCP servers. https://claude.com/blog/extending-claude-capabilities-with-skills-mcp-servers
7. Model Context Protocol – Introduction. https://modelcontextprotocol.io/docs/getting-started/intro
8. huangwb8 – skills. https://github.com/huangwb8/skills
9. huangwb8 – ChineseResearchLaTeX (skills). https://github.com/huangwb8/ChineseResearchLaTeX/tree/main/skills
10. Skills.sh – huangwb8/chineseresearchlatex. https://skills.sh/huangwb8/chineseresearchlatex