本文最后更新于 50 天前，如有失效请评论区留言。
skills的Github仓库：
开发和调试不易，希望小伙伴们帮忙给项目点Star、关注我的帐号呀！感谢感谢！
因为在PackyCode的小群里有小伙伴比较好奇Skills这种产品形态，刚好最近几天我也了解并深入地实践了一下，颇有经验。这篇文章，我想聊聊：Skills 到底是什么？我平时怎么设计一个 Skill？如何基于一个 Skill 再往上搭一条”可重复跑”的 Pipeline（工作区级流程）？这篇文章会以我自己做的”系统文献综述”相关实践为例，分享我踩坑后总结出来的一套大致步骤和经验。另外，这个流程同样适用于 OpenAI Codex：现在 Codex 和 Claude Code 都已能按 Agent Skills 的方式发现和调用技能，”写一次，到处用”是可以做到的。(～￣▽￣)～
在深入 Skills 工程化之前，我想先聊聊在 AI 开发实践中沉淀下来的一些”哲学思考”——这些经验教训直接塑造了我后面要讲的设计原则。
小伙伴可能会问：AI 这么强，还需要流程吗？我觉得不但需要，而且更重要。关键是要搞清楚：AI 开发的成功关键不在于”一次性做出完美结果”，而在于”可复现性、可维护性”。
首先是人类角色的重新定位。不要想着让 AI 自动优化流程——我试过，基本上没有好结果。模型总会以一种你意想不到的方向和复杂度工作。人类对项目的全局把握还代替不了，所以我建议：用 AI 辅助提出开发计划，然后人类深度优化这个计划，确定好全局框架后，先让 AI 直接跑一次获得 demo，再针对某些部分细细优化。AI 时代需要的人类智能并没有减少，只是从”关注细节”转向了”关注架构、全局”。
其次是混合式开发的必然性。AI 本质上是概率性的，而不是真正具备智能（否则不可能犯那些低级错误）。所以我们必须做”精确端和模糊端分离”：比如在 Skills 开发中，SKILL.md（模糊端，让 AI 理解意图）与 config.yaml（精确端，约束参数）要明确分开。只要缺乏必要的人工审查，技术债是必然的、并且会迅速膨胀——这也是为什么“轻逻辑重测试”比”重逻辑轻测试”更重要：模块化测试可以缓解对上下文窗口的焦虑，也能减少模型幻觉的影响。
最后是流程的本质回归。软件工程在 AI 时代不仅没有失效，反而更重要了。编程不是一种垂直能力，而是通用能力。即使 AI 将来真的拥有了”智能”，它也必须有效使用软件工程才能开发出优雅的程序。AI 应用的成功、长青，关键在于找到非一次性交互型任务，以及必须依赖混合架构的任务——比如我在前面提到的”系统文献综述”，它正是一个典型的”需要 AI 推理能力 + 需要人类设计流程”的混合任务。
经常”瘦身”、不要过度设计、Long-context 如何保证指令遵循和减少幻觉……这些都是我们在实践中不断遇到的问题。但核心始终是：流程不是为了限制 AI，而是为了让 AI 的能力能够稳定、可复现地释放出来。
如果你把 AI 当成一个”协作者”，那 Skill 可以理解成一个 可复用的任务能力包：
SKILL.md 里的 name/description 决定什么时候该用它。references/（便于”补知识/补规则”）scripts/ 更像”工具箱”：倾向于直接运行，而不是把源码塞进上下文让模型背诵我觉得，Skill 是”可维护的操作手册”——你写的不只是”告诉 AI 怎么做”，而是在写”让未来的你、以及任何协作者，都能稳定复现结果”的说明书。
更重要的一点是：Codex 和 Claude Code 已统一遵循 Agent Skills 开放标准。这意味着我们可以采用单一技能库架构——你写的一套技能，可以同时兼容 Codex、Claude Code 及其他支持 Agent Skills 的平台。”写一次，到处用”不再是空话。(～￣▽￣)～
小伙伴可能会问：这听起来跟传统软件里的 Package（npm 包、Python 包）好像？哈哈，确实有相似之处，但本质差别挺大的。我特意做了一个对比表，方便你快速理解两者的定位差异：
| 维度 | Skills | Packages |
|---|---|---|
| 核心载体 | 自然语言 + 脚本（以文本指令为主） | 二进制/源码（以编译代码为主） |
| 执行者 | AI 模型（理解并执行指令） | 操作系统/运行时（直接执行机器码） |
| 🔥 依赖关系 | 语义触发（通过 description 自动匹配） | 显式声明（package.json / requirements.txt） |
| 版本管理 | Git + 文件哈希（渐进式加载） | 语义化版本（SemVer：1.2.3） |
| 🔥 测试方式 | 对话会话测试（非确定性，需要 AI 推理） | 单元/集成测试（确定性，断言验证） |
| 安装方式 | 复制到系统目录（~/.claude/skills/） | 包管理器安装（npm/pip/cargo） |
| 🔥 可移植性 | 跨平台通用（AI 理解语言即可） | 平台/语言相关（需要编译/运行时） |
| 适用场景 | 复杂推理任务（文献综述、代码审查、写作） | 确定性计算（算法、数据处理、UI 渲染） |
是不是感觉清楚了？(～￣▽￣)～ 简单来说：
两者不是替代关系，而是互补关系——你完全可以在一个 Skill 里调用 Package 提供的脚本工具，这也是我为什么强调 scripts/ 要像”工具箱”一样设计的原因。
小伙伴可能会问：MCP（Model Context Protocol） 呢？它跟 Skills 是什么关系？
这是个很好的问题！根据 Claude 官方博客 的定义，两者是互补但不同层的概念：MCP 提供连接能力（安全、标准化的外部系统访问），Skills 提供专业知识（领域知识 + 工作流逻辑）。官方用了一个很生动的比喻：如果你走进一家五金店要修柜子——MCP 就像货架上的商品（木工胶、钳子、合页……），Skills 就像店员的专业经验（告诉你”用什么、怎么用、先做哪步”）。
| 维度 | MCP | Skills |
|---|---|---|
| 🔥 核心作用 | 连接层（Connectivity） | 流程层（Expertise） |
| 主要职责 | 安全、标准化的外部系统访问 | 工作流逻辑、领域知识、输出标准 |
| 典型场景 | 连接 Notion、GitHub、Salesforce 等 | 会议准备、代码审查、文献综述等 |
| 组合方式 | 单个 Skill 可编排多个 MCP，单个 MCP 可支持多个 Skill | |
关键点是：MCP 让 Claude”能连接”，Skills 让 Claude”知道怎么用”。没有 Skills，Claude 只能猜测你的意图；有了 Skills，Claude 能按你的”剧本”执行。
这也是为什么我在 systematic-literature-review 里强调”多源检索 + 固定骨架 + 硬校验”——MCP 可以帮你连上 PubMed/arXiv，但 Skill 才知道”先搜什么、怎么评分、按什么结构写”。
很多人一开始会想：我直接把技能丢到 ~/.claude/skills 或 ~/.codex/skills 不就好了？
理论上可以，工程上我强烈不建议。原因很简单：系统目录应该是“部署态（runtime）”，而不是“开发态（workspace）”。
一个专门的 Skills 工作区至少解决三类关键问题：
下面这个目录是我的skill开发区的部分预览。我会把整个技能库当成一个工程项目来维护：
pipelines/skills/
├── Prompts.md # 工作流/标准（更像“项目总纲”）
├── AGENTS.md # 这个工作区的工程指令
├── init-project/ # 基础 skill：一键生成项目指令
├── install-bensz-skills/ # 基础 skill：系统级安装器（复制部署）
├── auto-test-skill/ # 基础 skill：测试驱动迭代
└── systematic-literature-review/
├── SKILL.md # 核心：语义接口 + 工作流
├── README.md # 面向使用者：怎么触发/怎么写需求
├── config.yaml # 可配置参数（避免硬编码）
├── references/ # 需要时再读的规则/模板说明/领域知识
├── scripts/ # 可执行脚本（确定性、可重复）
├── test/ # 测试会话（回归用）
└── CHANGELOG.md # 有机整体更新的变更记录
这里我用 systematic-literature-review 这类”长流程、强交付”的 Skill 举例，因为它最能体现 Skill 的工程价值。
systematic-literature-review 是我设计的一个自动化做系统综述/文献综述的 AI 技能。你可能会问：”这不就是个文献搜索吗？”差别可大了去了！它做的事情远不止”搜搜论文”：
– 自动定检索词 → AI 自行决定用哪些关键词去哪里搜（PubMed/arXiv/Google Scholar/多源检索）
– 智能筛选 → 逐篇读摘要、智能打分（1-10 分语义相关性）、做子主题归类、按高分优先比例选文
– 自动规划字数预算 → “综/述”字数分配（70% 引用段 + 30% 无引用段），三次采样取均值
– 全自动写作 → 固定骨架（摘要/引言/子主题/讨论/展望/结论），保留正文字数与参考文献数的硬校验
– 强制导出 → PDF + Word 双格式，支持多语言翻译（中英日德法西等）
最关键的是：它是完全可重现的——从检索词到参考文献列表，从字数统计到引用一致性，每一步都有日志可追溯。是不是有点像”把整个综述流程当 CI/CD 管道跑”？(〜￣▽￣)〜
我会把 SKILL.md 的 YAML 头部当成“技能的 API 文档”，至少想清楚两件事：
description，让工具能“自然匹配”到它。你可能会问：为啥这么在意 description？
因为在实际使用时，很多时候你不会精确地说“请调用 XX skill”，你会说“帮我做个文献综述”。这时候描述就是路标。
我做系统综述时最怕两件事：中途崩和产出不可验。所以我会把流程拆成一组“阶段”，每个阶段都尽量做到：
以系统综述为例，我通常会把它拆成类似这种节奏（只讲结构，不讲具体实现）：
核心思想是：把“我觉得写完了”变成“机器能验收”。
长流程技能一定会遇到各种意外（路径不对、模板缺失、恢复状态异常、LaTeX 编译失败、引用 key 对不上……）。
我自己的经验是：不要指望模型每次都聪明，应该在 Skill 里提前写好“护栏策略”：
\cite{} 与 .bib 对齐等是不是感觉有点像“把 AI 当 CI 用”？对，就是这个味儿。哈哈。
我会强制自己做两份文档：
README.md：面向使用者——怎么触发、怎么提需求、怎么选档位/范围。SKILL.md：面向执行者（AI）——工作流、输入确认、输出规范、校验规则。这样做的好处是：你未来要改内部流程时，不一定要让用户跟着改提示词，而用户提需求也不会被一堆工程细节劝退。
我做了一段时间后发现，真正能让 Skill 体系跑起来的，不是某个“很强的业务 Skill”，而是这三个“基础 Skill”。它们分别解决：初始化、部署、迭代。
init-project：一键生成项目指令（AGENTS.md / CLAUDE.md）只要你会经常开新工作区（新仓库、新 pipeline、新专题），你就会懂：让 AI 一上来就“懂规矩”太重要了。
init-project 的意义在于：
AGENTS.md / CLAUDE.md对我来说，它等价于：把“我想要的协作方式”变成可复制的模板。
install-bensz-skills：系统级复制安装（让 Skill 真正“可用”）我不喜欢软链接式的“临时可用”，我更想要一种“装上就能用、换目录也能用”的体验。
install-bensz-skills 做的事情很朴素但很关键：
pipelines/skills/ 下的技能复制安装到系统目录~/.codex/skills/~/.claude/skills/SKILL.md 的哈希）来决定是否需要更新，只安装变化的部分它的意义在于：你可以把技能库当成“源码仓库”，把系统目录当成“运行环境”，这就是标准的开发/部署分离。
auto-test-skill：测试驱动迭代（把”修修补补”变成可追溯的优化循环）Skill 的迭代很容易变成：用户提一句，你改两行，过两天又坏了……
我后面就专门做了一个 auto-test-skill，用来强制自己按”测试会话”管理迭代：
它的价值不是”帮我写测试代码”，而是帮我建立一种习惯：每次改动都能解释、能复现、能验收。
Skill 解决的是”如何完成某个小任务”。而我抽象出的 Pipeline，它的作用是处理”任务如何被组织、如何被重复执行、如何不互相污染”这一问题。
我还是以写文献综述（下称 reviews）为例。我把 reviews 设计成一个”综述项目工厂”，它只做三件事：
{主题}），互不干扰systematic-literature-review，并且必须传 --work-dir，否则直接失败可以这么理解：Skill 是“工位上那台机器”；Pipeline 是“工厂的车间管理制度”。
如果你想从 0 做 Skill + Pipeline，强烈建议基于我的 huangwb8/skills 项目开发（已搭建好完整的工程结构和基础技能，可直接 fork 或参考）。大致步骤如下：
假设 Skill 的工作区是
skills
AGENTS.md 和 CLAUDE.md 文件已经规范了 AI 的行为，它会自动生成规范的目录结构。auto-test-skill 管理迭代：问题→计划→修复→复测→写验证报告）。如果你胆子大，要用 auto-test-skill 自动优化项目，我建议还是用 GPT-4.1 和 4.5-Opus 这种比较智能、长上下文的模型来跑。我是喜欢自己看，因为这会让我对项目的发展有足够的把握度和安全感。auto-test-skill 又来了是不是感觉一下子”工程味”就上来了？这就对了：Skill 体系的关键不是聪明，而是稳定。我觉得，Vibe coding 时代如果你能习惯做一个”经常有全局思维且仅偶尔关注细节”的人，那么 Claude Code/Codex 用起来一定是很爽的。
你现在最想把哪类工作做成 Skill？我也想看看大家都在”自动化”什么。如果你也在做类似的工程化探索，欢迎评论区或 GitHub Issues 里留下你的想法吧！
---------------
完结，撒花！如果您点一下广告，可以养活苯苯😍😍😍
本文最后更新于 50 天前，如有失效请评论区留言。
skills的Github仓库：
开发和调试不易，希望小伙伴们帮忙给项目点Star、关注我的帐号呀！感谢感谢！
因为在PackyCode的小群里有小伙伴比较好奇Skills这种产品形态，刚好最近几天我也了解并深入地实践了一下，颇有经验。这篇文章，我想聊聊：Skills 到底是什么？我平时怎么设计一个 Skill？如何基于一个 Skill 再往上搭一条”可重复跑”的 Pipeline（工作区级流程）？这篇文章会以我自己做的”系统文献综述”相关实践为例，分享我踩坑后总结出来的一套大致步骤和经验。另外，这个流程同样适用于 OpenAI Codex：现在 Codex 和 Claude Code 都已能按 Agent Skills 的方式发现和调用技能，”写一次，到处用”是可以做到的。(～￣▽￣)～
在深入 Skills 工程化之前，我想先聊聊在 AI 开发实践中沉淀下来的一些”哲学思考”——这些经验教训直接塑造了我后面要讲的设计原则。
小伙伴可能会问：AI 这么强，还需要流程吗？我觉得不但需要，而且更重要。关键是要搞清楚：AI 开发的成功关键不在于”一次性做出完美结果”，而在于”可复现性、可维护性”。
首先是人类角色的重新定位。不要想着让 AI 自动优化流程——我试过，基本上没有好结果。模型总会以一种你意想不到的方向和复杂度工作。人类对项目的全局把握还代替不了，所以我建议：用 AI 辅助提出开发计划，然后人类深度优化这个计划，确定好全局框架后，先让 AI 直接跑一次获得 demo，再针对某些部分细细优化。AI 时代需要的人类智能并没有减少，只是从”关注细节”转向了”关注架构、全局”。
其次是混合式开发的必然性。AI 本质上是概率性的，而不是真正具备智能（否则不可能犯那些低级错误）。所以我们必须做”精确端和模糊端分离”：比如在 Skills 开发中，SKILL.md（模糊端，让 AI 理解意图）与 config.yaml（精确端，约束参数）要明确分开。只要缺乏必要的人工审查，技术债是必然的、并且会迅速膨胀——这也是为什么“轻逻辑重测试”比”重逻辑轻测试”更重要：模块化测试可以缓解对上下文窗口的焦虑，也能减少模型幻觉的影响。
最后是流程的本质回归。软件工程在 AI 时代不仅没有失效，反而更重要了。编程不是一种垂直能力，而是通用能力。即使 AI 将来真的拥有了”智能”，它也必须有效使用软件工程才能开发出优雅的程序。AI 应用的成功、长青，关键在于找到非一次性交互型任务，以及必须依赖混合架构的任务——比如我在前面提到的”系统文献综述”，它正是一个典型的”需要 AI 推理能力 + 需要人类设计流程”的混合任务。
经常”瘦身”、不要过度设计、Long-context 如何保证指令遵循和减少幻觉……这些都是我们在实践中不断遇到的问题。但核心始终是：流程不是为了限制 AI，而是为了让 AI 的能力能够稳定、可复现地释放出来。
如果你把 AI 当成一个”协作者”，那 Skill 可以理解成一个 可复用的任务能力包：
SKILL.md 里的 name/description 决定什么时候该用它。references/（便于”补知识/补规则”）scripts/ 更像”工具箱”：倾向于直接运行，而不是把源码塞进上下文让模型背诵我觉得，Skill 是”可维护的操作手册”——你写的不只是”告诉 AI 怎么做”，而是在写”让未来的你、以及任何协作者，都能稳定复现结果”的说明书。
更重要的一点是：Codex 和 Claude Code 已统一遵循 Agent Skills 开放标准。这意味着我们可以采用单一技能库架构——你写的一套技能，可以同时兼容 Codex、Claude Code 及其他支持 Agent Skills 的平台。”写一次，到处用”不再是空话。(～￣▽￣)～
小伙伴可能会问：这听起来跟传统软件里的 Package（npm 包、Python 包）好像？哈哈，确实有相似之处，但本质差别挺大的。我特意做了一个对比表，方便你快速理解两者的定位差异：
| 维度 | Skills | Packages |
|---|---|---|
| 核心载体 | 自然语言 + 脚本（以文本指令为主） | 二进制/源码（以编译代码为主） |
| 执行者 | AI 模型（理解并执行指令） | 操作系统/运行时（直接执行机器码） |
| 🔥 依赖关系 | 语义触发（通过 description 自动匹配） | 显式声明（package.json / requirements.txt） |
| 版本管理 | Git + 文件哈希（渐进式加载） | 语义化版本（SemVer：1.2.3） |
| 🔥 测试方式 | 对话会话测试（非确定性，需要 AI 推理） | 单元/集成测试（确定性，断言验证） |
| 安装方式 | 复制到系统目录（~/.claude/skills/） | 包管理器安装（npm/pip/cargo） |
| 🔥 可移植性 | 跨平台通用（AI 理解语言即可） | 平台/语言相关（需要编译/运行时） |
| 适用场景 | 复杂推理任务（文献综述、代码审查、写作） | 确定性计算（算法、数据处理、UI 渲染） |
是不是感觉清楚了？(～￣▽￣)～ 简单来说：
两者不是替代关系，而是互补关系——你完全可以在一个 Skill 里调用 Package 提供的脚本工具，这也是我为什么强调 scripts/ 要像”工具箱”一样设计的原因。
小伙伴可能会问：MCP（Model Context Protocol） 呢？它跟 Skills 是什么关系？
这是个很好的问题！根据 Claude 官方博客 的定义，两者是互补但不同层的概念：MCP 提供连接能力（安全、标准化的外部系统访问），Skills 提供专业知识（领域知识 + 工作流逻辑）。官方用了一个很生动的比喻：如果你走进一家五金店要修柜子——MCP 就像货架上的商品（木工胶、钳子、合页……），Skills 就像店员的专业经验（告诉你”用什么、怎么用、先做哪步”）。
| 维度 | MCP | Skills |
|---|---|---|
| 🔥 核心作用 | 连接层（Connectivity） | 流程层（Expertise） |
| 主要职责 | 安全、标准化的外部系统访问 | 工作流逻辑、领域知识、输出标准 |
| 典型场景 | 连接 Notion、GitHub、Salesforce 等 | 会议准备、代码审查、文献综述等 |
| 组合方式 | 单个 Skill 可编排多个 MCP，单个 MCP 可支持多个 Skill | |
关键点是：MCP 让 Claude”能连接”，Skills 让 Claude”知道怎么用”。没有 Skills，Claude 只能猜测你的意图；有了 Skills，Claude 能按你的”剧本”执行。
这也是为什么我在 systematic-literature-review 里强调”多源检索 + 固定骨架 + 硬校验”——MCP 可以帮你连上 PubMed/arXiv，但 Skill 才知道”先搜什么、怎么评分、按什么结构写”。
很多人一开始会想：我直接把技能丢到 ~/.claude/skills 或 ~/.codex/skills 不就好了？
理论上可以，工程上我强烈不建议。原因很简单：系统目录应该是“部署态（runtime）”，而不是“开发态（workspace）”。
一个专门的 Skills 工作区至少解决三类关键问题：
下面这个目录是我的skill开发区的部分预览。我会把整个技能库当成一个工程项目来维护：
pipelines/skills/
├── Prompts.md # 工作流/标准（更像“项目总纲”）
├── AGENTS.md # 这个工作区的工程指令
├── init-project/ # 基础 skill：一键生成项目指令
├── install-bensz-skills/ # 基础 skill：系统级安装器（复制部署）
├── auto-test-skill/ # 基础 skill：测试驱动迭代
└── systematic-literature-review/
├── SKILL.md # 核心：语义接口 + 工作流
├── README.md # 面向使用者：怎么触发/怎么写需求
├── config.yaml # 可配置参数（避免硬编码）
├── references/ # 需要时再读的规则/模板说明/领域知识
├── scripts/ # 可执行脚本（确定性、可重复）
├── test/ # 测试会话（回归用）
└── CHANGELOG.md # 有机整体更新的变更记录
这里我用 systematic-literature-review 这类”长流程、强交付”的 Skill 举例，因为它最能体现 Skill 的工程价值。
systematic-literature-review 是我设计的一个自动化做系统综述/文献综述的 AI 技能。你可能会问：”这不就是个文献搜索吗？”差别可大了去了！它做的事情远不止”搜搜论文”：
– 自动定检索词 → AI 自行决定用哪些关键词去哪里搜（PubMed/arXiv/Google Scholar/多源检索）
– 智能筛选 → 逐篇读摘要、智能打分（1-10 分语义相关性）、做子主题归类、按高分优先比例选文
– 自动规划字数预算 → “综/述”字数分配（70% 引用段 + 30% 无引用段），三次采样取均值
– 全自动写作 → 固定骨架（摘要/引言/子主题/讨论/展望/结论），保留正文字数与参考文献数的硬校验
– 强制导出 → PDF + Word 双格式，支持多语言翻译（中英日德法西等）
最关键的是：它是完全可重现的——从检索词到参考文献列表，从字数统计到引用一致性，每一步都有日志可追溯。是不是有点像”把整个综述流程当 CI/CD 管道跑”？(〜￣▽￣)〜
我会把 SKILL.md 的 YAML 头部当成“技能的 API 文档”，至少想清楚两件事：
description，让工具能“自然匹配”到它。你可能会问：为啥这么在意 description？
因为在实际使用时，很多时候你不会精确地说“请调用 XX skill”，你会说“帮我做个文献综述”。这时候描述就是路标。
我做系统综述时最怕两件事：中途崩和产出不可验。所以我会把流程拆成一组“阶段”，每个阶段都尽量做到：
以系统综述为例，我通常会把它拆成类似这种节奏（只讲结构，不讲具体实现）：
核心思想是：把“我觉得写完了”变成“机器能验收”。
长流程技能一定会遇到各种意外（路径不对、模板缺失、恢复状态异常、LaTeX 编译失败、引用 key 对不上……）。
我自己的经验是：不要指望模型每次都聪明，应该在 Skill 里提前写好“护栏策略”：
\cite{} 与 .bib 对齐等是不是感觉有点像“把 AI 当 CI 用”？对，就是这个味儿。哈哈。
我会强制自己做两份文档：
README.md：面向使用者——怎么触发、怎么提需求、怎么选档位/范围。SKILL.md：面向执行者（AI）——工作流、输入确认、输出规范、校验规则。这样做的好处是：你未来要改内部流程时，不一定要让用户跟着改提示词，而用户提需求也不会被一堆工程细节劝退。
我做了一段时间后发现，真正能让 Skill 体系跑起来的，不是某个“很强的业务 Skill”，而是这三个“基础 Skill”。它们分别解决：初始化、部署、迭代。
init-project：一键生成项目指令（AGENTS.md / CLAUDE.md）只要你会经常开新工作区（新仓库、新 pipeline、新专题），你就会懂：让 AI 一上来就“懂规矩”太重要了。
init-project 的意义在于：
AGENTS.md / CLAUDE.md对我来说，它等价于：把“我想要的协作方式”变成可复制的模板。
install-bensz-skills：系统级复制安装（让 Skill 真正“可用”）我不喜欢软链接式的“临时可用”，我更想要一种“装上就能用、换目录也能用”的体验。
install-bensz-skills 做的事情很朴素但很关键：
pipelines/skills/ 下的技能复制安装到系统目录~/.codex/skills/~/.claude/skills/SKILL.md 的哈希）来决定是否需要更新，只安装变化的部分它的意义在于：你可以把技能库当成“源码仓库”，把系统目录当成“运行环境”，这就是标准的开发/部署分离。
auto-test-skill：测试驱动迭代（把”修修补补”变成可追溯的优化循环）Skill 的迭代很容易变成：用户提一句，你改两行，过两天又坏了……
我后面就专门做了一个 auto-test-skill，用来强制自己按”测试会话”管理迭代：
它的价值不是”帮我写测试代码”，而是帮我建立一种习惯：每次改动都能解释、能复现、能验收。
Skill 解决的是”如何完成某个小任务”。而我抽象出的 Pipeline，它的作用是处理”任务如何被组织、如何被重复执行、如何不互相污染”这一问题。
我还是以写文献综述（下称 reviews）为例。我把 reviews 设计成一个”综述项目工厂”，它只做三件事：
{主题}），互不干扰systematic-literature-review，并且必须传 --work-dir，否则直接失败可以这么理解：Skill 是“工位上那台机器”；Pipeline 是“工厂的车间管理制度”。
如果你想从 0 做 Skill + Pipeline，强烈建议基于我的 huangwb8/skills 项目开发（已搭建好完整的工程结构和基础技能，可直接 fork 或参考）。大致步骤如下：
假设 Skill 的工作区是
skills
AGENTS.md 和 CLAUDE.md 文件已经规范了 AI 的行为，它会自动生成规范的目录结构。auto-test-skill 管理迭代：问题→计划→修复→复测→写验证报告）。如果你胆子大，要用 auto-test-skill 自动优化项目，我建议还是用 GPT-4.1 和 4.5-Opus 这种比较智能、长上下文的模型来跑。我是喜欢自己看，因为这会让我对项目的发展有足够的把握度和安全感。auto-test-skill 又来了是不是感觉一下子”工程味”就上来了？这就对了：Skill 体系的关键不是聪明，而是稳定。我觉得，Vibe coding 时代如果你能习惯做一个”经常有全局思维且仅偶尔关注细节”的人，那么 Claude Code/Codex 用起来一定是很爽的。
你现在最想把哪类工作做成 Skill？我也想看看大家都在”自动化”什么。如果你也在做类似的工程化探索，欢迎评论区或 GitHub Issues 里留下你的想法吧！
---------------
完结，撒花！如果您点一下广告，可以养活苯苯😍😍😍