Agent Skills on 拾光集

AI Skills 入门教程：用一个 SKILLs.md，让 AI 记住你的工作方法

Tue, 28 Jul 2026 15:54:00 +0800

每次让 AI 写周报、整理会议纪要或分析数据，都要重新解释格式、语气和步骤？

这类问题可以通过 AI Skills 解决。

Skills 可以理解为写给 AI 的一份“标准操作手册”：它把任务说明、执行规则、参考案例和所需资源整理在一个文件夹中。当用户提出相关需求时，支持 Agent Skills 的 AI 工具可以读取并执行这些规则。

简单来说：普通提示词只服务于当前对话，Skills 更适合保存可重复使用的工作流程。

Skills 是什么？

一个 Skills 通常对应一项明确任务，例如：

根据工作记录生成周报
按固定标准审核文章
整理会议纪要并提取待办事项
检查代码中的安全问题
按品牌规范生成营销文案

官方 Agent Skills 规范将 Skills 定义为一种轻量级开放格式。最基础的 Skills 是一个文件夹，其中必须包含 Skills.md；复杂 Skills 还可以附带脚本、模板、示例和参考资料。

Skills 能解决什么问题？

1. 减少重复沟通

不需要每次都重新说明：

输出包含哪些栏目
使用什么语气
哪些内容不能出现
数据应该如何展示
最终结果采用什么格式

2. 统一输出标准

多人或多次使用同一个 Skills 时，可以尽量保持相同的结构、流程和判断标准。

3. 沉淀个人工作方法

当你发现一套提示词效果很好，可以把它整理成 Skills，而不是让它一直留在聊天记录中。

需要注意的是，Skills 并不是让 AI 获得真正的“永久记忆”。它更像一份保存在本地或项目目录中的规则文件：只有工具能够发现并加载它时，规则才会生效。

Skills 的基本目录结构

一个标准 Skills 不只是单独散落的文本文件，而是一个独立文件夹：

weekly-report/
├── Skills.md
├── references/
│   └── report-example.md
└── templates/
    └── weekly-report-template.md

其中：

Skills.md：必需，写明名称、用途和执行规则
references/：可选，存放参考资料或优秀案例
templates/：可选，存放固定模板
scripts/：可选，存放需要执行的辅助脚本

Anthropic 和 OpenAI 的官方文档都将 Skills 描述为包含指令、资源以及可选脚本的任务能力包，而不只是一个简单提示词。

三步写出第一个 Skills

下面以“周报助手”为例。

第一步：写清楚名称和触发条件

在 Skills.md 顶部加入 YAML 元数据：

---
name: weekly-report
description: 根据用户提供的本周工作记录生成中文周报。当用户要求写周报、整理本周工作，或提交一组工作记录时使用。
---

至少应写清楚：

name：Skills 的名称
description：它能做什么，以及什么时候应该使用

description 不要只写“处理文档”或“提高效率”，否则 AI 很难判断什么时候需要调用它。

第二步：把要求改成可执行规则

不要只写：

1
2

写得专业一点。
内容简洁一些。

这种描述过于主观，不同模型可能有不同理解。

可以改成：

# 周报生成规则

收到用户的工作记录后，按以下顺序处理：

1. 将内容分为：
   - 本周完成
   - 进行中
   - 下周计划

2. 每条内容优先保留：
   - 项目名称
   - 完成数量
   - 当前进度
   - 产生的结果
   - 后续动作

3. 不得虚构用户未提供的数据。

4. 没有具体数字时，保留原始事实，并注明“未提供量化数据”。

5. 删除“积极推进”“持续赋能”“圆满完成”等空泛表达。

6. 每条控制在两句话以内。

7. 最后增加一段不超过80字的本周总结。

这些规则能够直接执行，也更容易检查结果是否合格。

第三步：提供输入与输出示例

示例能帮助 AI 理解你真正想要的效果。

# 示例

## 输入

- 完成用户调研
- 修复了几个登录页面的问题
- 数据看板还在调整
- 下周准备上线新活动

## 输出

### 本周完成

1. 完成用户调研，共收集326份有效问卷，并整理出15条核心反馈。
2. 修复登录页面3个影响用户使用的问题，登录功能已通过测试。

### 进行中

1. 数据看板重构已完成约60%，预计下周完成剩余图表和筛选功能。

### 下周计划

1. 完成数据看板重构并提交测试。
2. 上线新用户活动，持续跟踪访问量和注册转化率。

### 本周总结

本周重点完成用户调研和登录功能修复，数据看板重构按计划推进，下周将进入功能上线和数据验证阶段。

示例越接近真实工作场景，输出通常越稳定。

可直接复制的完整 Skills.md

---
name: weekly-report
description: 根据用户提供的工作记录生成结构清晰的中文周报。当用户要求写周报、总结本周工作或发送零散工作记录时使用。
---

# 周报助手

## 目标

将用户提供的零散工作记录整理为可以直接发送的中文周报。

## 执行步骤

1. 阅读全部工作记录。
2. 合并重复事项。
3. 按“本周完成、进行中、下周计划”分类。
4. 保留项目名称、数量、进度、结果和下一步动作。
5. 生成结构清晰的 Markdown 周报。

## 输出结构

### 本周完成

列出已经完成并产生结果的事项。

### 进行中

列出尚未完成的任务，并说明当前进度和下一步动作。

### 下周计划

列出下周需要执行的具体任务。

### 本周总结

使用不超过80字总结本周重点、进展和风险。

## 写作规则

- 使用平实、清晰的中文。
- 每条内容不超过两句话。
- 优先使用具体数字、进度和结果。
- 不使用“积极推进”“持续赋能”“圆满完成”等空泛表达。
- 不得编造用户没有提供的信息。
- 信息不足时，保留原意并注明缺少的数据。
- 默认使用 Markdown 格式。

## 示例

输入：

- 完成客户调研
- 修复登录页面问题
- 看板还在调整
- 下周上线活动

输出：

### 本周完成

1. 完成客户调研，并整理主要需求和反馈。
2. 完成登录页面问题修复，相关功能已恢复正常。

### 进行中

1. 数据看板仍在调整，下一步将完善图表和筛选功能。

### 下周计划

1. 完成数据看板调整并提交测试。
2. 上线新活动并跟踪用户参与数据。

### 本周总结

本周完成客户调研和登录问题修复，数据看板正在推进，下周重点为活动上线和数据验证。

新手常见的三个错误

触发条件太模糊

错误写法：

用于处理工作。

推荐写法：

`1`	`当用户要求生成周报，或提交本周工作记录时使用。`

规则只有形容词

错误写法：

`1`	`写得专业、简洁、有深度。`

推荐写法：

`1`	`正文不超过500字，每条不超过两句话，每项至少保留一个结果或进度信息。`

一个 Skills 承担太多任务

不建议把“写周报、做PPT、分析数据、发送邮件”全部放进同一个 Skills。

更合理的方式是拆成多个独立 Skills：

weekly-report/
meeting-notes/
data-analysis/
email-reply/

一个 Skills 只解决一类明确问题，通常更容易触发，也更方便维护。

使用第三方 Skills 前要注意什么？

不要看到 GitHub 上的 Skills 就直接安装。

第三方 Skills 可能附带脚本、命令或外部资源。使用前至少检查：

Skills.md 要求 AI 执行哪些操作
是否包含 scripts/ 等可执行文件
是否会读取环境变量、密钥或私人文件
是否要求上传数据到外部服务
GitHub 仓库是否持续维护

研究已经指出，Agent Skills 生态存在指令注入、恶意脚本和供应链风险，因此第三方 Skills 应当像第三方代码一样审查，而不是只把它当作文档。

去哪里找现成的 Skills？

可以从以下官方项目开始：

建议先阅读官方示例，再根据自己的工作流程修改。不要直接复制一个功能复杂的 Skills，然后期待它完全符合自己的需求。

总结

写 Skills 的关键，不是堆积大量提示词，而是把一项任务说明清楚：

什么时候使用
按什么步骤执行
必须遵守哪些规则
最终输出什么格式
什么样的结果才算合格

第一次可以从最常用、最重复的一项任务开始，例如周报、会议纪要或文章审核。先完成一个简单可用的版本，再根据实际输出逐步补充规则和示例。

5个自定义 Skills，让 Codex 从代码生成器升级为全能 AI 开发助手

Tue, 28 Jul 2026 11:34:00 +0800

很多人使用 Codex 时，只让它完成“写代码”这一件事。

遇到需求就生成代码，出现报错再继续修改。这样的使用方式虽然方便，但 Codex 很难理解项目背景，也容易出现需求理解偏差、界面模板化、修改范围过大等问题。

更有效的方法，是通过 Agent Skills 为 Codex 增加固定的知识、规则和工作流程。

Skill 本质上是一组可重复使用的说明、脚本和资源。它可以让 Codex 在执行特定任务时，按照预先设定的流程工作，而不是每次都依赖临时提示词。OpenAI 的 Skills 项目也将其定义为帮助 Codex 扩展专业能力的模块化目录。¹

下面这 5 个 Skill，分别解决知识管理、方案审查、UI 设计、中文写作和代码质量问题。

一、obsidian-skills：把 Obsidian 变成 Codex 的知识库

在长期项目中，真正影响 AI 工作质量的往往不是模型能力，而是它不知道你之前做过什么。

例如：

项目已经确定了哪些技术方案
哪些错误曾经出现过
用户有哪些固定偏好
某项设计为什么被放弃
当前项目有哪些待办事项

obsidian-skills 可以让 Codex 读取和管理 Obsidian 知识库中的 Markdown 笔记、任务、属性、Bases 和 JSON Canvas。

该项目遵循 Agent Skills 规范，并明确支持 Codex CLI 等兼容 Skills 的 AI 编程工具。²

它能解决什么问题

使用这个 Skill 后，可以让 Codex：

搜索 Obsidian 中的历史笔记
创建和更新项目文档
整理零散的开发记录
查找与当前任务相关的内容
将解决方案沉淀为长期知识
根据历史记录继续未完成的工作

适合的使用场景

例如你可以告诉 Codex：

1
2
3

搜索 Obsidian 中与当前网站部署有关的笔记，
整理已经尝试过的方法、失败原因和最终解决方案，
然后根据这些信息继续排查问题。

这样可以减少重复解释项目背景，也能避免 AI 再次尝试已经失败的方法。

需要注意：它主要负责帮助 AI 操作和整理 Obsidian 知识库，并不等于自动拥有完整的长期记忆。最终效果仍取决于你的笔记结构和记录质量。

二、UI Skill：减少 AI 生成网页的模板感

AI 可以快速生成网页，但生成结果经常存在明显的“AI 模板感”。

常见问题包括：

不分场景地使用紫蓝渐变
所有内容都居中排列
页面由大量相似卡片组成
默认使用常见字体和圆角
只考虑桌面端，没有检查移动端
视觉效果不错，但真实上线后不好使用

UI Skill 的作用不是提供一个固定模板，而是给 Codex 增加一套设计判断标准。

目前 GitHub 上已经有多种面向 Codex 的 UI Skills。例如 ui-ux-pro-max-skill 提供了 UI 风格、配色、字体组合、产品类型、UX 规则和图表类型等设计知识，可用于网页和移动端界面的规划、生成、审查与优化。³

1. 建立设计黑名单

可以在 Skill 中明确禁止一些容易产生模板感的设计：

除非项目明确要求，否则不要默认使用：

- 紫色到蓝色的渐变背景
- 所有标题和内容居中对齐
- 大量相同尺寸的信息卡片
- 缺乏层级的圆角矩形
- 没有业务含义的装饰性光效
- 默认套用科技 SaaS 网站风格

设计黑名单并不是完全禁止这些元素，而是要求 Codex 在使用前说明理由。

2. 根据业务选择设计语言

品牌官网、个人博客和后台管理系统，不应该使用完全相同的设计方式。

Skill 可以要求 Codex先判断页面类型：

页面类型	设计重点
品牌落地页	品牌识别、视觉节奏、转化路径
个人博客	阅读体验、内容层级、页面速度
后台系统	信息密度、操作效率、状态反馈
电商页面	商品信息、信任感、购买路径
工具网站	功能入口、操作引导、结果展示

3. 增加上线前质检

页面完成后，要求 Codex 检查：

手机端图片是否变形
长英文和链接是否可以换行
按钮是否有明确反馈
文字对比度是否足够
页面加载是否依赖过大的图片
表单是否提供错误提示
页面是否存在横向溢出
键盘操作是否正常

这样可以让 Codex 从“生成一个好看的页面”，升级为“交付一个可以实际使用的页面”。

三、Humanizer-zh：减少中文内容的 AI 味

Codex 不只能写代码，也经常被用于生成：

产品介绍
README 文档
博客文章
更新日志
网站文案
操作说明
社交媒体内容

但 AI 生成的中文常常存在表达生硬、结构重复和营销感过强的问题。

Humanizer-zh 是一个中文内容优化 Skill，主要用于识别并减少 AI 写作痕迹，让文字更自然、更接近真实中文表达。其项目说明中明确提到，它可以用于编辑或审阅 AI 生成的文本。⁴

常见的 AI 写作问题

它可以重点检查以下内容：

频繁使用“值得注意的是”
每段都使用相同句式
过度使用“赋能”“重塑”“开启新篇章”
没有事实支撑的夸张表达
大量使用“首先、其次、最后”
句子看似完整，但缺少具体信息
中文中出现明显的英文翻译腔

使用示例

完成网站文章后，可以让 Codex 执行：

使用 Humanizer-zh 检查这篇文章。

要求：
1. 删除空泛和夸张的营销表达；
2. 保留技术事实、命令和项目名称；
3. 调整重复句式；
4. 使用自然、简洁的中文；
5. 不要为了口语化而降低专业性。

它适合作为内容发布前的最后一道编辑流程，而不是简单地把所有内容改成口语。

四、grill-me：在开发之前先把方案问清楚

AI 编程最常见的问题之一，是需求还没有明确，AI 就已经开始写代码。

结果通常是：

技术路线选择错误
功能边界不断扩大
忽略重要异常情况
修改大量无关文件
做完以后才发现需求理解错了

grill-me 的作用，就是在动手开发前扮演一个严格的方案审查者。

该 Skill 会围绕计划、设计或技术方案持续追问，直到关键决策、假设和分支得到明确。⁵

它会重点追问什么

例如开发一个用户登录功能时，grill-me 不会立刻生成代码，而是先检查：

使用邮箱、手机号还是第三方账号登录
是否需要注册、找回密码和邮箱验证
登录状态保存多久
是否允许多设备同时登录
失败次数是否需要限制
用户数据存储在哪里
哪些页面需要登录后访问
是否存在管理员和普通用户权限

使用示例

使用 grill-me 审查下面的开发方案。

在需求和边界没有明确之前，不要编写代码。
请重点检查：

- 隐含假设
- 异常流程
- 数据安全
- 权限设计
- 技术复杂度
- 后期维护成本

这个 Skill 看起来会让前期讨论变慢，但通常能减少后期返工。

五、编码原则 Skill：限制 Codex 的修改范围

前面四个 Skill 解决了知识、方案、设计和内容问题，最后还需要一套编码原则来限制 Codex 的执行行为。

这部分不一定需要安装现成项目，也可以根据自己的开发习惯创建一个自定义 SKILL.md。

五个 Skill 如何组成完整工作流

这五个 Skill 并不是相互独立的工具，可以按照开发流程组合使用。

第一步：读取历史知识

使用 obsidian-skills 搜索项目笔记、历史方案和踩坑记录。

第二步：审查需求

使用 grill-me 挑战需求和技术方案，找出缺失信息与边界情况。

第三步：设计并实现界面

使用 UI Skill 确定设计语言、页面结构、响应式规则和质检标准。

第四步：优化文字内容

使用 Humanizer-zh 调整页面文案、README 和博客内容，减少机械化表达。

第五步：完成最小修改并验证

使用编码原则 Skill 限制修改范围，并执行测试、构建和代码检查。

完整流程可以概括为：

历史知识检索
    ↓
需求追问与方案审查
    ↓
UI 设计与代码实现
    ↓
中文内容优化
    ↓
测试、验证与交付

实际使用时，不需要每次启用全部 Skill

五个 Skill 不一定每次都要同时使用。

可以根据任务类型进行组合：

任务	推荐 Skill
整理项目经验	obsidian-skills
开发复杂新功能	obsidian-skills + grill-me + 编码原则
制作网站页面	UI Skill + Humanizer-zh + 编码原则
编写技术文章	obsidian-skills + Humanizer-zh
重构旧项目	grill-me + 编码原则
制作产品落地页	UI Skill + Humanizer-zh
排查历史问题	obsidian-skills + 编码原则

Skill 数量并不是越多越好。真正重要的是每个 Skill 都有明确职责，并且不会互相冲突。

总结

Codex 的价值不只是生成代码。

通过 Skills，可以将知识、规范和工作流程固定下来，让 Codex逐渐具备以下能力：

读取并整理项目知识
在开发前审查需求
根据业务选择设计语言
优化中文内容表达
控制代码修改范围
在交付前完成自我验证

最终目标不是让 Codex 一次生成更多代码，而是减少沟通成本、降低返工概率，让每次修改都更加稳定和可控。

GitHub 项目地址

“编码原则”部分属于可自行创建的自定义 Skill，并非本文确认的单一 GitHub 项目。

OpenAI Skills 项目将 Agent Skills 描述为由指令、脚本和资源组成的模块化目录，可帮助 Codex 重复执行特定任务。 ↩︎
obsidian-skills 项目说明其遵循 Agent Skills 规范，并支持 Codex CLI。 ↩︎
UI UX Pro Max Skill 提供多种设计风格、配色、字体组合、UX 规则与技术栈支持。 ↩︎
Humanizer-zh 用于识别和减少中文文本中的 AI 生成痕迹。 ↩︎
grill-me 用于通过持续追问，对计划、需求或设计方案进行压力测试。 ↩︎

Skills 创建全流程：从需求规划到测试落地，零基础也能完成

Tue, 28 Jul 2026 11:08:00 +0800

很多人第一次接触 Skills 时，会认为它只是一个写了提示词的 Markdown 文件。

实际上，一个真正稳定、可复用的 Skill，更像是一份专门交给 AI 执行的标准作业流程。它不仅要告诉 AI“做什么”，还要说明什么时候启用、按照什么步骤执行、需要读取哪些资料，以及最终应该输出什么结果。

本文将完整梳理 Skills 创建流程，从前期规划、目录初始化、SKILL.md 编写，到验证与实际测试。即使没有开发经验，也可以按照步骤逐步完成。

一、什么是 Skill？

Skill 是一个独立的文件夹，其中包含 AI 完成特定任务所需要的说明、脚本、参考资料和模板资源。

它可以把通用 AI 转变成更适合某项工作的专业助手，例如：

按固定格式撰写产品介绍
根据公司规范回复客户邮件
自动分析 Excel 或 CSV 数据
按统一标准生成网站文章
批量处理图片或 PDF 文件
调用特定 API 完成固定工作流
根据团队规范检查代码

一个 Skill 通常围绕一个明确任务设计，而不是试图解决所有问题。

第一阶段：前期规划

在创建文件之前，先把 Skill 的目标和使用方式规划清楚。

这一步看似没有写代码，却会直接决定 Skill 是否容易触发、执行是否稳定，以及后续是否方便维护。

1. 明确 Skill 的目标

建议从以下四个方面定义目标。

1.1 功能描述

首先说明这个 Skill 具体解决什么问题。

不要只写：

帮助用户处理内容。

这种描述过于宽泛，AI 很难判断应该在什么情况下调用它。

更清晰的写法是：

根据用户提供的原始资料，生成适合个人博客发布的中文 Markdown 文章，并补充标题、文章结构、SEO 关键词、标签和项目地址。

功能描述越具体，后续越容易设计执行流程。

1.2 适用场景

明确用户在什么情况下需要使用这个 Skill。

例如：

用户要求润色个人博客文章
用户提供视频文案，希望整理成教程
用户希望生成可直接复制的 Markdown 内容
用户希望补充 GitHub 项目地址
用户要求文章适合 Google SEO 和 AI 搜索引用

适用场景也是 Skill 判断是否应该触发的重要依据。

1.3 预期输出

提前规定 Skill 完成任务后应该交付什么。

例如：

1. 原文问题分析
2. 建议补充的信息
3. 优化后的文章标题
4. 可直接复制的 Markdown 正文
5. SEO 描述
6. Tags 标签
7. 项目地址

输出格式越明确，多次执行时的结果越稳定。

1.4 限制条件

同时还要说明 Skill 不应该做什么。

例如：

不虚构测试数据
不编造 GitHub Stars 数量
无法确认的信息需要明确标注
不堆砌 SEO 关键词
不在文章中保留明显错别字
不泄露 API Key、密码或个人隐私
未经确认不得执行删除、付款或生产环境修改

限制条件可以减少 AI 自由发挥过度造成的问题。

2. 分析实际需求

目标明确后，需要从用户、技术、性能和兼容性四个维度继续分析。

2.1 用户需求

先判断谁会使用这个 Skill，以及他们会如何提出请求。

建议至少准备 3～5 个真实示例。

例如，创建一个博客文章优化 Skill 时，用户可能会这样说：

`1`	`帮我把这段视频文案整理成博客文章。`

`1`	`重新润色这篇文章，并补充 GitHub 项目地址。`

`1`	`生成可以直接复制到 Hugo 网站中的 Markdown 内容。`

`1`	`让文章更适合 Google SEO 和 AI 搜索引用。`

这些真实表达可以帮助你完善 Skill 的触发描述。

2.2 技术需求

检查 Skill 是否需要额外工具或文件。

常见资源包括：

Python 或 Bash 脚本
API 接口
MCP 服务
浏览器搜索能力
GitHub 项目资料
公司内部文档
Markdown 模板
图片、Logo 或字体
Excel、PDF、Word 处理工具

并不是每个 Skill 都需要脚本。

能够通过清晰文字说明完成的任务，优先写在 SKILL.md 中；只有重复、容易出错或需要固定结果的操作，才更适合使用脚本。

2.3 性能需求

提前考虑执行成本和效率，例如：

是否需要联网搜索
是否会读取大型文件
是否需要处理大量图片
是否会调用付费 API
是否需要批量执行
是否存在较长的运行时间
是否需要限制 Token 消耗

Skill 内容也不宜无限扩张。应只保留 AI 真正需要的规则，把较长的资料放入 references/，需要时再读取。

2.4 兼容性需求

确认 Skill 将在哪些平台或环境中运行，例如：

Codex
Claude Code
GitHub Copilot
Cursor
Gemini CLI
Windows
macOS
Linux
Docker
团队内部 Agent 平台

不同平台对 Skill 的安装路径、元数据和调用方式可能不同，因此不要默认一个 Skill 在所有环境中都能完全通用。

第二阶段：正式创建 Skill

规划完成后，就可以开始建立目录和编写内容。

3. Skill 命名规范

建议使用：

小写英文字母
数字
连字符 -

不要使用：

空格
中文文件夹名
下划线
大写字母
含义不清的缩写

正确示例：

`1`	`blog-content-optimizer`

`1`	`fabric-email-writer`

`1`	`github-project-researcher`

不推荐：

`1`	`My Skill`

`1`	`blog_skill`

新建技能

文件夹名称应该与 SKILL.md 中的 name 保持一致。

4. 使用 Skill Creator 初始化

如果当前环境中已经安装官方 skill-creator，建议优先使用初始化脚本，而不是手动建立所有文件。

标准命令格式：

`1`	`scripts/init_skill.py <skill-name> --path <output-directory>`

例如，将 Skill 创建到 Codex 默认 Skills 目录：

1
2

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills"

同时创建 scripts/ 和 references/：

1
2
3

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills" \
  --resources scripts,references

同时创建脚本、参考资料和静态资源目录：

1
2
3

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills" \
  --resources scripts,references,assets

初始化脚本可以自动生成基础模板，减少目录名称、YAML 格式和必要文件写错的概率。

不同版本的 Skill Creator 所在路径可能不同。实际使用时，应以本机安装目录中的 skill-creator 文件为准。

5. 手动创建 Skill 目录

没有初始化脚本时，也可以手动创建。

Windows PowerShell

mkdir my-skill
cd my-skill

New-Item SKILL.md -ItemType File
mkdir scripts
mkdir references
mkdir assets

tree /F

macOS 或 Linux

mkdir my-skill
cd my-skill

touch SKILL.md
mkdir scripts references assets

tree -a

如果系统没有安装 tree，可以使用：

`1`	`find . -maxdepth 3 -print`

或者：

ls -la

需要注意，scripts/、references/ 和 assets/ 都是可选目录。没有实际用途时，不需要为了结构完整而创建空文件夹。

6. 标准目录结构

一个较完整的 Codex Skill 可以采用以下结构：

my-skill/
├── SKILL.md
├── agents/
│   └── openai.yaml
├── scripts/
├── references/
└── assets/

各目录作用如下。

`SKILL.md`

这是整个 Skill 的核心文件，必须存在。

它负责说明：

Skill 名称
Skill 的用途
什么时候应该触发
应该按照什么流程执行
应该读取哪些资源
最终输出什么结果
有哪些限制条件

文件名必须写成：

`1`	`SKILL.md`

不建议写成：

`1`	`skill.md`

部分系统区分大小写，错误命名可能导致 Skill 无法被识别。

`agents/openai.yaml`

这是 Codex Skill 推荐使用的界面元数据文件，可用于展示：

Skill 显示名称
简短说明
默认提示语
图标或界面相关信息

它主要服务于 Skill 列表和交互界面，不应代替 SKILL.md 中的核心执行规则。

`scripts/`

用于保存可以重复执行的代码，例如：

scripts/
├── clean_markdown.py
├── validate_output.py
└── export_result.py

适合放入脚本的任务通常具备以下特点：

操作步骤固定
需要重复执行
手动生成容易出错
结果必须保持一致
需要调用本地程序或处理文件

新增脚本后，应实际运行测试，不能只确认代码看起来正确。

`references/`

用于保存参考资料，例如：

references/
├── writing-rules.md
├── seo-checklist.md
├── api-documentation.md
└── company-style-guide.md

较长的背景资料不建议全部塞进 SKILL.md。

可以在 SKILL.md 中说明什么时候读取某份参考资料，让 AI 按需加载，从而减少上下文占用。

`assets/`

用于保存最终任务可能使用的静态资源，例如：

assets/
├── logo.png
├── article-template.md
├── report-template.docx
└── website-template/

它适合存放：

图片
图标
Logo
文档模板
网页模板
示例文件
需要复制到输出结果中的资源

`LICENSE` 或 `LICENSE.txt`

如果 Skill 准备公开发布或共享给团队，应明确授权方式。

常见许可证包括：

MIT License
Apache License 2.0
GNU GPL
项目自定义许可证

对于仅在个人电脑内部使用的 Skill，许可证通常不是运行所必需的；但公开到 GitHub 前，建议补充清晰的授权文件。

第三阶段：编写 SKILL.md

7. YAML Frontmatter

SKILL.md 顶部需要包含 YAML 元数据。

基础格式：

---
name: my-skill
description: Explain what this skill does and exactly when it should be used.
---

其中最重要的是 description。

它不仅是介绍文字，也是 AI 判断是否调用这个 Skill 的主要依据。

不推荐：

`1`	`description: 一个非常好用的内容处理工具。`

8. 编写执行流程

SKILL.md 正文应该以明确、可执行的规则为主。

下面是一个简单示例：

---
name: blog-content-optimizer
description: Optimize Chinese blog content into clear, credible and copy-ready Markdown. Use when the user provides rough notes, transcripts or existing articles and asks for rewriting, SEO improvement, GitHub project verification, tags or website publishing content.
---

# Blog Content Optimizer

## Workflow

1. Read the complete source material.
2. Correct spelling, command and terminology errors silently.
3. Identify vague, repetitive or overly promotional statements.
4. Determine what factual information is missing.
5. Verify time-sensitive claims and GitHub project information.
6. Rewrite the article in clear Chinese Markdown.
7. Preserve relevant SEO keywords naturally.
8. Add the verified project address at the end.
9. Generate comma-separated tags.

## Output

Return the following sections:

1. 原文存在的问题
2. 建议补充的信息
3. 中文优化版
4. Tags
5. 项目地址

## Rules

- Do not fabricate facts, statistics, Stars or test results.
- Do not stuff keywords.
- Do not mention spelling corrections in the final article.
- Mark information that cannot be verified.
- Keep headings descriptive and easy to quote.
- Prefer concrete steps and examples over marketing language.

这类写法比长篇介绍更有效，因为每一条都可以直接指导 AI 执行。

第四阶段：验证与测试

9. 运行基础校验

完成 Skill 后，可以使用 Skill Creator 提供的验证脚本检查格式。

`1`	`scripts/quick_validate.py <path/to/skill-folder>`

例如：

`1`	`scripts/quick_validate.py ~/.codex/skills/my-skill`

验证工具通常可以发现：

SKILL.md 缺失
YAML 格式错误
缺少 name
缺少 description
文件夹命名不符合规范
Skill 名称与目录不一致

出现错误后，根据提示修改，再重新运行验证命令。

10. 使用真实任务测试

通过格式验证，并不代表 Skill 已经真正可用。

至少准备 3～5 个测试请求，例如：

`1`	`把下面的视频文案整理成可以发布的 Markdown 教程。`

`1`	`检查这篇文章中的 GitHub 项目是否真实，并补充项目地址。`

`1`	`让文章更适合 Google SEO，但不要堆砌关键词。`

`1`	`只修改错别字，不改变原文语气。`

测试时重点观察：

Skill 是否在正确场景触发
不相关请求是否错误触发
输出结构是否稳定
是否遗漏关键步骤
是否读取了正确的参考资料
是否出现虚构内容
脚本是否能够正常运行
多次执行的结果是否基本一致

11. 根据测试结果持续优化

Skill 通常不会一次完成。

更合理的优化循环是：

实际使用
↓
发现遗漏或错误
↓
定位问题来源
↓
修改 SKILL.md、脚本或参考资料
↓
重新验证
↓
再次使用真实任务测试

例如：

经常没有补充项目地址 → 在工作流程和输出格式中同时增加 GitHub 检查要求。
经常错误触发 → 缩小 description 中的使用范围。
经常无法识别用户表达 → 在 description 中增加常见触发场景。
输出格式不稳定 → 提供固定模板或示例。
重复任务消耗较多 Token → 把固定操作改成脚本。

Skill 的价值并不在于文件数量，而在于它能否让同类任务以更稳定、更可预测的方式重复完成。

哪些情况适合使用 Skill Creator？

1. 创建新的 Skill

当你只有一个需求想法，还没有确定目录、执行步骤和输出结构时，可以让 Skill Creator 帮助完成：

需求梳理
使用场景分析
目录初始化
SKILL.md 草稿
资源规划
验证与测试

2. 优化已有 Skill

如果已有 Skill 经常漏步骤、错误触发或输出不稳定，可以使用 Skill Creator：

优化 description
精简冗余内容
补充测试案例
重新规划脚本和参考资料
比较修改前后的执行结果

3. 团队协作

多人共同维护 Skills 时，Skill Creator 可以帮助团队统一：

目录结构
文件命名
输出格式
开发流程
测试标准
版本维护方式

4. 固定且重复的工作流

例如只需要几个固定命令或固定步骤的任务，也适合封装成 Skill：

项目初始化
文件格式转换
批量重命名
发布前检查
固定格式报告生成

不过，任务越简单，Skill 内容越应该保持精简，不需要为了显得完整而增加大量无用说明。

5. 高度定制的业务任务

当任务依赖公司内部规范、专业资料、固定模板或特殊流程时，Skill 可以将这些知识组织成可复用资源。

例如：

面料报价邮件规范
公司品牌文案规则
内部数据库查询方式
特定 API 调用流程
固定交付文件格式

创建 Skill 时的常见错误

错误一：目标范围过大

例如：

`1`	`帮助用户完成所有办公任务。`

这种 Skill 几乎无法稳定触发，也很难测试。

应该拆分成：

1
2
3

customer-email-writer
invoice-data-checker
weekly-report-generator

错误二：只写功能，不写触发场景

如果 description 没有说明什么时候使用，AI 可能无法正确调用。

错误三：把所有资料都写进 SKILL.md

过长的文件会占用更多上下文。

应该将详细资料拆分到 references/，需要时再读取。

错误四：创建大量无用目录

没有脚本就不需要建立空的 scripts/；没有静态资源也不需要建立 assets/。

错误五：脚本没有实际运行

AI 生成的脚本即使语法看起来正确，也可能存在依赖、路径或参数问题，必须实际执行测试。

错误六：只验证格式，不测试效果

格式正确只能证明 Skill 可以被读取，不能证明它能完成真实任务。

错误七：在文件中写入敏感信息

不要把以下内容直接写入 Skill：

API Key
登录密码
Cookie
私钥
客户隐私数据
生产环境凭据

敏感信息应通过安全的环境变量或密钥管理工具提供。

总结

一个标准的 Skills 创建流程，可以归纳为六个步骤：

明确目标
↓
收集真实使用案例
↓
规划 scripts、references 和 assets
↓
初始化并编写 SKILL.md
↓
运行格式验证和真实任务测试
↓
根据实际结果持续迭代

对于零基础用户来说，最重要的不是一次写出复杂的 Skill，而是先选择一个明确、重复出现的小任务。

只要目标清晰、触发场景明确、输出格式固定，并通过真实任务不断测试优化，就可以逐步建立一套属于自己的 AI 工作流程。

Book to Skill：把一本书变成 AI 可以反复调用的知识工具

Mon, 27 Jul 2026 19:55:00 +0800

很多人用 AI 阅读一本书时，通常只会做两件事：

总结全书内容
提炼重点和金句

这种方式可以帮助我们快速了解一本书，却很难真正把书里的方法应用到工作中。

Book to Skill 提供了另一种思路：把 PDF、EPUB、DOCX、Markdown 等文档转换成结构化的 Agent Skill，让 AI 不只是“读过这本书”，而是能够在后续任务中调用书里的框架、原则和方法，帮助你分析问题、检查方案或生成内容。

简单来说，它不是把一本书压缩成一篇摘要，而是把一本书整理成一套可以反复使用的 AI 知识工具。

Book to Skill 是什么？

Book to Skill 是一个开源 Agent Skill，主要用于把书籍、技术文档或一组资料转换成结构化 Skill。

它会从原始文档中提取：

核心框架和思维模型
可以直接执行的方法
决策规则
常见错误和反模式
重要概念与术语
各章节的关键知识
快速查询用的速查表

生成完成后，AI 可以根据当前任务按需读取对应章节，而不是每次都把整本书重新放进上下文。

这意味着，你以后不必反复翻阅几十页甚至几百页的 PDF，也不需要每次重新向 AI 解释这本书讲了什么。

它和普通的 AI 读书总结有什么区别？

普通的 AI 总结通常只能回答：

这本书主要讲了什么？

Book to Skill 更关注的是：

这本书里的方法，应该在什么情况下使用？

例如，一本内容创作类书籍被转换成 Skill 后，你可以让 AI：

根据书中的方法策划短视频选题
设计视频标题和封面文案
检查口播脚本的开头是否足够吸引人
分析内容节奏和信息密度
判断脚本是否存在留存问题
按照书中的标准重写脚本
查询某个概念出自哪个章节

它输出的不是一份看完就放在一边的读书笔记，而是一套能够参与实际工作的知识系统。

Book to Skill 会生成哪些文件？

将一本书转换完成后，通常会得到类似下面的文件结构：

your-book-skill/
├── SKILL.md
├── glossary.md
├── patterns.md
├── cheatsheet.md
└── chapters/
    ├── ch01-introduction.md
    ├── ch02-framework.md
    ├── ch03-methods.md
    └── ...

这些文件分别承担不同作用：

文件	主要用途
`SKILL.md`	保存核心思维模型、使用说明和章节索引
`chapters/`	按章节保存详细知识，需要时再读取
`glossary.md`	整理书中的重要术语和定义
`patterns.md`	汇总技巧、方法、流程和常见模式
`cheatsheet.md`	保存决策规则和快速参考信息

这种结构比单独生成一篇长摘要更实用。

AI 在处理具体问题时，只需要加载相关章节，不必一次把整本书全部塞进上下文，也能减少无关内容对回答的干扰。

支持哪些文档格式？

Book to Skill 当前支持多种常见文档格式，包括：

PDF
EPUB
DOCX
TXT
Markdown
HTML
RTF
reStructuredText
AsciiDoc
MOBI
AZW / AZW3

除了单本书，它还可以处理整个文件夹、多个文档或符合特定规则的一组文件。

因此，它不仅适合处理电子书，也可以用来整理：

企业内部操作手册
品牌规范
产品文档
技术资料
API 说明
行业研究报告
论文与个人笔记
培训教材
项目知识库

只要这些资料是你经常需要查询和使用的，就可以考虑将它们整理成 Skill。

如何安装 Book to Skill？

安装到 Claude Code

在终端中执行：

`1`	`git clone https://github.com/virgiliojr94/book-to-skill.git ~/.claude/skills/book-to-skill`

安装完成后，重新启动 Claude Code，或让它重新加载 Skills。

安装到 GitHub Copilot CLI

`1`	`git clone https://github.com/virgiliojr94/book-to-skill.git ~/.copilot/skills/book-to-skill`

然后在 Copilot CLI 会话中执行：

1
2

/skills reload
/skills info book-to-skill

安装到通用 Agent Skills 目录

`1`	`git clone https://github.com/virgiliojr94/book-to-skill.git ~/.agents/skills/book-to-skill`

这个目录可用于部分兼容开放 Agent Skills 规范的工具。

需要注意的是，不同 AI 编程工具对 Skills 的目录、调用命令和兼容程度可能不同。官方仓库当前明确说明支持 Claude Code、GitHub Copilot CLI 和 Amp。其他工具能否直接使用，应以对应工具的 Skills 文档为准。

如何把一本书转换成 Skill？

假设电脑中有一本书：

`1`	`~/books/content-guide.pdf`

可以执行：

`1`	`/book-to-skill ~/books/content-guide.pdf`

也可以在命令后指定生成的 Skill 名称：

`1`	`/book-to-skill ~/books/content-guide.pdf content-creator-guide`

如果需要把多份资料合并成一个 Skill，可以执行：

`1`	`/book-to-skill ~/books/book.pdf ~/notes/my-notes.md content-knowledge`

处理整个文件夹：

`1`	`/book-to-skill ~/documents/project-docs/ project-knowledge`

处理某个目录中的全部 EPUB 文件：

`1`	`/book-to-skill "~/books/*.epub" my-book-library`

Book to Skill 在正式生成前，还可以先分析文档结构、估算 Token 消耗，并展示预计生成的文件。

对于篇幅较长的书，建议先选择分析模式，确认提取出来的框架和章节是否准确，再继续生成完整 Skill。

一个实际应用案例

假设你有一本关于短视频内容创作的电子书。

转换成 Skill 后，可以让 AI 完成以下任务。

1. 快速了解全书

`1`	`请基于这个 Skill，整理全书的核心框架、关键原则和主要方法。`

2. 生成短视频方案

1
2

请使用书中的内容创作框架，策划一条介绍 Book to Skill 的 60 秒短视频。
需要包含标题、开头钩子、脚本结构、核心画面和结尾行动指令。

3. 检查现有脚本

请按照书中的评估标准，检查这份短视频脚本。

重点分析：
1. 标题点击潜力
2. 前 3 秒吸引力
3. 内容节奏
4. 信息密度
5. 留存风险
6. 惊喜点
7. 可以删除的内容
8. 具体修改方案

4. 查询书中概念

`1`	`请解释书中关于内容留存的核心方法，并说明它适合在哪些场景使用。`

5. 重写脚本

1
2
3

请根据书中的原则重写这份脚本。

保留原来的主题，但增强开头吸引力、内容节奏和结尾转化。

这时，AI 的判断依据不再只是通用知识，而是你提供的那本书中提取出来的框架。

Book to Skill 真正适合哪些人？

这个工具比较适合以下用户：

经常阅读技术书或商业书的人
想把读书笔记真正用于工作的人
内容创作者和短视频运营人员
产品经理与项目负责人
开发者和技术团队
需要频繁查询公司内部文档的团队
想建立个人 AI 知识库的人

如果你只是想快速知道一本书讲了什么，普通的 AI 总结已经足够。

如果你希望 AI 在未来的任务中持续使用书里的方法，Book to Skill 会更有价值。

使用时需要注意什么？

1. 不要把它当成万能知识转换器

生成效果取决于原始文档质量。

扫描模糊、排版混乱、缺少文字层或章节结构不清晰的 PDF，可能会影响内容提取结果。

2. 重要结论仍需回到原文核对

Skill 可以帮助查找、整理和应用知识，但不代表生成结果一定完全准确。

涉及专业决策、法律、医疗、财务或重要商业问题时，应重新核对原始章节。

3. 注意版权与使用权限

建议只处理以下资料：

自己购买并合法取得的电子书
自己创作的内容
公司授权使用的内部文档
开放许可资料
已进入公共领域的作品

不要随意转换、传播或公开分享无权处理的受版权保护内容。

4. 敏感文件应谨慎处理

项目官方说明，Book to Skill 主要在本地读取文档并写入 Skill 目录，不会主动上传文件或运行网络服务。

不过，最终生成和调用 Skill 时是否会把内容发送给云端模型，还取决于你使用的 AI 工具和模型服务。

处理公司机密、客户资料或个人隐私文件前，应先确认对应 AI 服务的数据政策。

5. 不要直接相信网络视频中的 Star 数量

GitHub Star 会随时间变化。

与其在文章中写死“6.9K Star”或其他数字，不如直接查看项目仓库中的实时数据，避免文章发布后很快过时。

我的理解

Book to Skill 最有价值的地方，不是帮助我们更快地“读完一本书”，而是改变书籍知识的使用方式。

过去，一本书读完之后，真正能记住和使用的内容可能很少。

现在可以把书里的框架、规则和方法整理成一个 Agent Skill，让 AI 在写作、分析、策划和决策时按需调用。

它相当于把一本静态的电子书，变成一个可以查询、分析并参与工作的知识模块。

不过，它并不能代替阅读本身。

真正合理的用法，是让 AI 帮助我们定位知识、理解框架和应用方法，再回到原文核对上下文。这样既能提高学习效率，也能减少断章取义和错误理解。

项目地址

GitHub：

https://github.com/virgiliojr94/book-to-skill

项目名称：

`1`	`virgiliojr94/book-to-skill`

项目功能、安装方式和兼容范围可能继续更新，请以 GitHub 仓库中的最新 README 为准。

Codex 效率倍增：5 个值得关注的开源工具

Mon, 27 Jul 2026 19:40:00 +0800

同样使用 Codex，为什么有些人写代码更快、更稳，还能让 AI 自动查文档、理解大型项目，甚至操作浏览器和电脑？

原因并不只是模型更强，而是他们给 Codex 配置了更完整的工具链。

Codex 本身已经可以阅读代码、修改文件、运行命令和修复 Bug，但在实际使用中，仍然容易遇到以下问题：

没有理解完整需求，就直接开始写代码；
使用过时的技术文档，生成已经失效的 API；
一个简单功能引入大量依赖，代码越来越复杂；
项目文件太多，AI 反复搜索代码，消耗大量 Token；
AI 能分析问题，却无法操作浏览器或桌面软件。

下面介绍 5 个值得关注的开源项目。它们分别从开发流程、网页数据、代码精简、项目理解和电脑自动化五个方向，补足 Codex 的能力。

本文中的 GitHub Star 数量会随时间变化，因此不再使用固定数字作为主要判断标准。是否值得安装，还应结合项目更新频率、Issue、许可证和实际需求综合判断。

5 个工具分别解决什么问题？

工具名称	核心功能	主要解决的问题
Superpowers	为 AI 加入需求分析、开发计划、测试和代码审查流程	AI 没想清楚就直接写代码
Firecrawl	抓取网页并转换为 Markdown 或结构化数据	AI 使用过时文档或无法读取网页
Ponytail	强调标准库优先、最小实现和减少依赖	代码过度设计、项目越来越臃肿
Graphify	将代码库转换为本地知识图谱	大型项目难理解、反复搜索文件
Agent TARS	识别屏幕并操作鼠标、键盘和浏览器	AI 只能思考，不能完成界面操作

1. Superpowers：让 Codex 先分析，再写代码

很多 AI 编程任务失败，并不是因为模型不会写代码，而是因为它在需求还没有明确时，就直接开始修改项目。

例如，你只说一句：

给网站增加一个用户登录功能。

AI 可能马上创建数据库、安装认证框架、增加多个中间件，最后才发现你只需要一个简单的后台密码验证。

Superpowers 的作用，就是给 Codex、Claude Code 等 AI 编程工具增加一套更严格的软件开发流程。

它通常会引导 AI 按照以下步骤工作：

先分析用户需求；
主动询问缺失的细节；
输出开发方案；
将任务拆分成多个步骤；
编写测试；
实现功能；
运行测试；
检查代码质量；
完成代码审查。

它更像是一套 AI 开发规范，而不是简单的提示词模板。

Superpowers 适合解决什么问题？

如果你经常遇到下面这些情况，可以考虑使用 Superpowers：

AI 没理解需求就开始修改代码；
功能做出来了，但方向完全错误；
修改一个问题，却破坏了其他功能；
AI 写完代码后不测试；
大型任务执行到一半开始偏离目标；
希望 Codex 按测试驱动开发流程工作。

使用时需要注意

Superpowers 会让开发流程更加完整，但也会增加执行步骤。

如果只是修改一个按钮颜色、调整一段文字或修复简单配置，并不一定需要启动完整的需求分析和测试流程。

它更适合中等以上复杂度的开发任务。

2. Firecrawl：让 Codex 获取最新网页和技术文档

AI 编程工具经常会遇到一个问题：模型掌握的知识不是实时更新的。

当框架、云服务或第三方 API 更新后，Codex 可能仍然使用旧版本参数，甚至生成已经被删除的方法。

例如：

Next.js 更新了路由方式；
OpenAI API 修改了请求格式；
Cloudflare 增加了新的配置参数；
某个 JavaScript 库废弃了旧方法；
官方文档已经更新，但 AI 仍然按照旧教程回答。

Firecrawl 是一个面向 AI Agent 的网页抓取和数据提取工具。

它可以将网页内容整理成适合 AI 阅读的格式，包括：

Markdown；
HTML；
JSON；
结构化数据；
网页截图；
页面链接；
整站爬取结果。

普通网页中通常包含导航栏、广告、按钮、脚本和大量无关代码。

Firecrawl 会尽量提取正文内容，再转换成干净的 Markdown，让 Codex 更容易理解。

Firecrawl 可以怎么配合 Codex？

例如，你准备让 Codex 接入一个刚刚更新的 API。

可以先让 Firecrawl 抓取官方文档，再把整理后的内容交给 Codex。

这样，Codex 不需要完全依赖模型记忆，而是根据最新文档生成代码。

一个常见工作流程是：

抓取官方文档
↓
转换为 Markdown
↓
交给 Codex 阅读
↓
根据最新文档生成代码
↓
运行测试验证

Firecrawl 适合哪些场景？

获取最新 API 文档；
抓取产品页面；
整理公开数据；
分析竞争对手网站；
提取新闻和文章正文；
给 AI Agent 提供实时互联网内容；
将复杂网页转换成 Markdown。

使用时需要注意

Firecrawl 的核心项目是开源的，但官方提供的云端 API 服务可能存在免费额度和付费套餐。

因此，“项目开源”不代表所有在线调用都永久免费。

如果需要大量抓取，也可以研究自托管方案。

同时，抓取网站时应遵守目标网站的 robots.txt、服务条款和相关法律要求。

3. Ponytail：阻止 AI 把简单问题写复杂

Codex 在生成代码时，有时会出现明显的过度设计。

一个原本只需要十几行代码的小功能，AI 可能会：

新建多个文件；
引入新的第三方库；
创建多层抽象；
增加复杂配置；
设计未来可能永远不会使用的扩展接口；
把简单逻辑封装成多个类。

最终结果是代码看起来很专业，但维护成本越来越高。

Ponytail 的核心思想是：

没有明确需要的功能，就不要提前实现。

这也是软件开发中常见的 YAGNI 原则，即：

You Aren’t Gonna Need It。

Ponytail 会引导 AI 优先考虑以下问题：

这个功能真的需要新增代码吗？
项目中是否已经存在类似能力？
能否直接使用语言标准库？
能否使用平台原生功能？
是否真的需要安装第三方依赖？
是否可以使用更简单的实现？
是否正在为不存在的未来需求过度设计？

举一个简单例子

假设需求是读取一个 JSON 文件。

AI 可能建议安装额外的 JSON 处理库。

但对于 Python、JavaScript、Go 等语言来说，标准库本身已经具备 JSON 解析能力。

Ponytail 会优先让 AI 使用现有能力，而不是为了一个简单任务增加新的依赖。

Ponytail 适合哪些用户？

个人开发者；
小型项目；
快速验证产品；
希望减少依赖的团队；
经常使用 Codex 生成代码的用户；
发现项目越改越复杂的开发者。

使用时需要注意

代码少并不代表代码一定更好。

涉及以下内容时，不能为了减少代码而省略必要设计：

安全验证；
错误处理；
日志记录；
数据校验；
权限控制；
自动化测试；
长期维护需要的模块拆分。

Ponytail 的重点不是“强行减少代码行数”，而是减少没有实际价值的复杂度。

4. Graphify：让 Codex 快速理解大型项目

当项目只有十几个文件时，Codex 通常可以快速理解代码结构。

但如果项目包含几百个甚至几千个文件，AI 就需要不断执行：

搜索文件；
查找函数；
阅读调用关系；
打开配置文件；
查找数据库结构；
分析模块依赖；
重复读取相同代码。

这个过程不仅慢，还会消耗大量上下文和 Token。

Graphify 可以提前分析整个项目，并将项目内容转换为本地知识图谱。

它可以处理的内容包括：

源代码；
项目文档；
配置文件；
数据库 Schema；
Markdown；
PDF；
图片；
视频；
其他项目资料。

对于代码内容，Graphify 可以使用 Tree-sitter 进行结构化解析，从而识别：

文件之间的关系；
函数调用关系；
类和模块依赖；
代码入口；
数据流；
配置关联；
项目目录结构。

Graphify 能帮助 Codex 回答什么问题？

建立知识图谱后，可以让 AI 更快回答：

用户登录功能涉及哪些文件？
这个函数被哪些模块调用？
修改数据库字段会影响哪些页面？
项目入口文件在哪里？
支付流程经过哪些服务？
某个配置项会影响哪些组件？
这段代码是否存在循环依赖？
一个 Bug 可能来自哪些模块？

相比让 Codex 每次从头搜索整个项目，知识图谱能够提供更完整的项目上下文。

Graphify 适合哪些场景？

接手陌生项目；
分析大型代码仓库；
维护遗留系统；
阅读缺少文档的项目；
多个 AI Agent 协作开发；
进行代码影响范围分析；
降低重复读取项目文件的次数。

使用时需要注意

知识图谱只能帮助 AI 理解代码关系，不能替代真实测试。

即使 Graphify 判断某个函数只被三个模块调用，也仍然需要通过运行测试和实际环境验证修改结果。

另外，项目代码发生较大变化后，需要重新更新或增量更新知识图谱。

5. Agent TARS：让 AI 从思考走向操作

Codex 更擅长处理代码、命令行和文件。

但很多实际工作并不完全发生在终端中，例如：

打开网页后台；
点击菜单；
填写表单；
上传文件；
操作设计软件；
整理网页内容；
使用桌面应用；
在浏览器中完成多步骤任务。

Agent TARS 是字节跳动开源的多模态 AI Agent 项目。

它可以结合视觉模型、GUI Agent 和 MCP 工具，让 AI 尝试理解屏幕内容，并进行鼠标、键盘和浏览器操作。

它的能力方向包括：

识别页面按钮；
理解输入框和菜单；
点击网页元素；
输入文字；
操作浏览器；
调用 MCP 工具；
完成多步骤界面任务；
结合搜索、文件和网页工具工作。

Agent TARS 能做什么？

理论上，你可以给它一个任务，例如：

打开网站后台，找到最近发布的文章，并检查标题是否存在错别字。

AI 会尝试：

打开浏览器；
进入对应页面；
识别后台菜单；
找到文章列表；
打开文章；
分析页面内容；
返回检查结果。

这类工具让 AI 不再只是告诉你“应该点击哪里”，而是尝试直接执行界面操作。

Agent TARS 适合哪些场景？

浏览器自动化；
GUI Agent 研究；
网页后台操作；
重复性桌面任务；
多步骤资料整理；
Computer Use 测试；
MCP 工具调用。

使用时需要注意

不要把 Agent TARS 理解成可以完全放心接管电脑的工具。

GUI Agent 仍然可能出现：

点击错误位置；
误解页面内容；
输入错误信息；
删除不该删除的文件；
在错误账号中执行操作；
页面加载后判断失败；
执行高风险操作。

建议优先在以下环境中测试：

虚拟机；
测试账号；
低权限用户；
不包含重要文件的电脑；
隔离的浏览器环境。

涉及以下操作时，应保留人工确认：

发布内容；
删除文件；
修改账号；
发送邮件；
提交订单；
付款；
上传隐私文件；
修改服务器配置。

这 5 个工具应该怎么选择？

不需要一次性把所有工具全部安装。

更合理的方式是先找到自己当前最明显的问题，再选择对应工具。

AI 写代码经常跑偏

选择：

`1`	`Superpowers`

它适合帮助 Codex 先明确需求，再按照计划、测试和代码审查流程执行。

经常遇到过时 API 和技术文档

选择：

`1`	`Firecrawl`

它可以抓取最新官方文档，并转换成适合 AI 阅读的 Markdown。

AI 生成的代码越来越复杂

选择：

`1`	`Ponytail`

它会提醒 AI 优先使用现有代码、标准库和原生能力，减少不必要的依赖。

项目太大，Codex 总是找不到代码关系

选择：

`1`	`Graphify`

它可以将项目转换为知识图谱，让 AI 更快理解项目结构和调用关系。

希望 AI 操作浏览器和桌面软件

选择：

`1`	`Agent TARS`

它适合研究 GUI Agent、浏览器自动化和 Computer Use。

是否都支持 Codex、Cursor 和 Claude Code？

不能简单地理解成“安装一次，所有 AI 编程工具全部通用”。

不同项目的接入方式可能包括：

Agent Skills；
MCP Server；
CLI 命令；
API；
本地服务；
Docker；
插件配置；
自定义提示词；
项目规则文件。

例如，某个项目可能更适合 Claude Code，另一个项目可能主要通过 MCP 接入 Cursor，也可能需要手动配置 Codex。

因此，具体安装和兼容方式应以项目最新 README 为准。

使用开源 AI 工具前，建议检查这些内容

不要只看 GitHub Star 数量。

安装前建议重点检查：

1. 最近是否仍在更新

查看最近一次提交时间和版本发布时间。

如果项目长期没有维护，可能无法兼容最新 Codex、Cursor 或 MCP 协议。

2. Issue 中是否存在严重问题

重点关注：

安装失败；
数据泄露；
高 CPU 占用；
无法卸载；
Windows 兼容问题；
macOS 权限问题；
API Key 泄露；
项目无法启动。

3. 是否需要额外付费服务

有些项目本身开源，但可能依赖：

OpenAI API；
Claude API；
Gemini API；
Firecrawl 云服务；
向量数据库；
云服务器；
搜索 API。

因此，开源不一定等于零成本。

4. 是否会读取敏感代码

如果项目需要扫描整个代码仓库，要先确认数据是否只在本地处理。

涉及公司代码、客户项目或商业机密时，不要直接上传到不确定的第三方服务。

5. 是否拥有高权限

GUI Agent 和电脑自动化工具可能需要：

屏幕录制权限；
鼠标控制权限；
键盘控制权限；
浏览器访问权限；
文件系统权限。

安装前应明确它可以访问哪些数据。

总结

提升 Codex 的效率，并不只是更换一个更强的模型。

真正影响 AI 编程体验的，通常还有三件事：

是否有明确的开发流程；
是否能获得最新、准确的资料；
是否能快速理解当前项目。

Superpowers 负责规范开发流程，Firecrawl 负责获取实时网页和技术文档，Ponytail 负责控制代码复杂度，Graphify 负责理解大型项目，Agent TARS 则将 AI 能力扩展到浏览器和桌面操作。

但工具并不是越多越好。

更实际的做法是：

找到工作流中最浪费时间、最容易出错的一步，再安装对应工具。

如果 Codex 经常写错方向，就先解决需求分析问题。

如果 AI 经常引用过时 API，就先解决实时文档问题。

如果项目越来越复杂，就先限制过度设计。

如果大型项目理解困难，就建立本地知识图谱。

只有真正需要操作网页和电脑时，再考虑 GUI Agent。

GitHub 项目地址

Superpowers https://github.com/obra/superpowers
Firecrawl https://github.com/firecrawl/firecrawl
Firecrawl MCP Server https://github.com/firecrawl/firecrawl-mcp-server
Ponytail https://github.com/DietrichGebert/ponytail
Graphify https://github.com/Graphify-Labs/graphify
Agent TARS / UI-TARS Desktop https://github.com/bytedance/UI-TARS-desktop

Find Skills 使用教程：帮你搜索、筛选和安装合适的 AI Agent Skills

Mon, 27 Jul 2026 19:10:00 +0800

Skills 太多不知道装哪个？先用 Find Skills 帮你筛选

接触 Claude Code、Codex、Cursor 或其他 AI Agent 一段时间后，很多人都会遇到同一个问题：

可安装的 Skills 越来越多，但真正适合自己的却很难找。

看到别人推荐测试 Skills、SEO Skills、前端设计 Skills、亚马逊选品 Skills，很多新手的第一反应是全部收藏，或者看到一个就安装一个。

最后工具箱越来越大，真正使用的可能只有两三个。

与其花时间在 GitHub 和 Skills.sh 里逐个翻找，不如先安装一个专门帮助你寻找 Skills 的 Skills：Find Skills。

Find Skills 是什么？

Find Skills 的代码名称是 find-Skills，由 Vercel Labs 的 Skills 项目提供。

它不是用来替你写代码、做选品或制作视频的业务型 Skills，而更像一个 AI Skills 导航员。

它主要做三件事：

根据你的实际任务寻找相关 Skills；
对搜索结果进行初步筛选；
提供 Skills 的用途、来源和安装命令。

你只需要把需求说清楚，它就会帮助你缩小范围，而不是让你面对一长串不知道该怎么选择的 Skills。

为什么建议先安装 Find Skills？

真正的问题通常不是没有 Skills，而是 Skills 太多。

Skills.sh 是一个开放的 Agent Skills 目录，里面收录了大量可复用能力。Skills 可以理解为一组面向特定任务的操作说明、脚本和相关资源，用来教 AI Agent 按照相对固定的流程完成工作。

但 Skills 数量增加后，也会带来三个问题：

名称相似，不知道哪个更适合；
来源不同，质量差距较大；
安装太多后，管理和维护成本上升。

因此，Find Skills 的价值不只是“帮你搜索”，而是先理解任务，再帮助你判断哪些结果更值得进一步查看。

Find Skills 是怎么寻找 Skills 的？

根据其官方说明，Find Skills 通常会按照以下流程工作。

第一步：拆解你的真实需求

它会先判断：

你属于哪个领域；
你具体想完成什么任务；
这个任务是否可能已经有成熟的 Skills。

例如，“我想做亚马逊”范围太大。

更有效的表达是：

帮我寻找一个适合亚马逊产品研究的 Skills，重点关注关键词、竞品分析、市场需求和广告数据。

需求越具体，搜索结果通常越准确。

第二步：先查看热门 Skills

Find Skills 会先检查 Skills.sh 排行榜，看看相关领域是否已经存在安装量较高、使用较广的 Skills。

热门不代表一定适合你，但通常意味着有更多用户使用和验证，可以作为第一轮筛选依据。

第三步：使用关键词继续搜索

如果排行榜中没有合适的结果，它会使用 Skills CLI 继续搜索，例如：

`1`	`npx Skills find amazon product research`

Skills CLI 也支持直接按关键词搜索：

`1`	`npx Skills find typescript`

还可以限定 GitHub 用户或组织：

`1`	`npx Skills find react --owner vercel`

第四步：核对 Skills 的质量

Find Skills 不应该只根据搜索结果名称进行推荐，还会重点查看：

安装量；
作者或组织来源；
GitHub 仓库星标；
项目是否持续维护；
Skills 的实际用途；
是否与当前任务匹配。

官方指南建议优先考虑安装量较高、来源可信的 Skills；安装量很少、来源陌生或仓库维护不足的项目，则需要更加谨慎。

Find Skills 安装命令

可以使用下面的命令安装 Vercel Labs 提供的 find-Skills：

`1`	`npx Skills add vercel-labs/Skills --Skills find-Skills`

在支持指定 Agent 的环境中，也可以明确选择安装目标。例如安装到 Claude Code：

`1`	`npx -y Skills add vercel-labs/Skills --Skills find-Skills --agent claude-code`

执行方法很简单：

打开终端；
粘贴安装命令；
按下回车；
根据终端提示完成安装。

需要注意的是，不同 Agent 和 Skills CLI 版本的安装路径或参数可能有所区别。安装前可以先查看项目最新说明。

安装后怎么使用？

安装完成后，不需要记住复杂命令，可以直接使用自然语言描述需求。

例如：

帮我寻找一个用于前端自动化测试的 Skills，优先推荐来源可信、安装量较高并且仍在维护的项目。

或者：

帮我找一个适合独立站 SEO 内容分析的 Skills，需要支持关键词研究、竞品分析和内容缺口检查。

还可以进一步增加筛选条件：

请先说明每个 Skills 的用途、作者来源、安装量、GitHub 仓库情况和安装命令，不要直接安装，等我确认后再操作。

这样做可以避免 AI 搜到结果后立即安装，也方便你先比较不同选项。

哪些人适合使用 Find Skills？

Find Skills 并不只适合程序员。

程序员

可以寻找：

自动化测试 Skills
代码审查 Skills
Git 提交规范 Skills
React 或 Next.js 优化 Skills
部署和排错 Skills

跨境电商卖家

可以寻找：

亚马逊选品 Skills
关键词研究 Skills
竞品分析 Skills
Listing 优化 Skills
广告数据分析 Skills

内容创作者

可以寻找：

视频脚本 Skills
标题生成 Skills
SEO 内容优化 Skills
社交媒体分发 Skills
字幕和内容整理 Skills

个人网站站长

可以寻找：

技术 SEO 检查 Skills
网站性能优化 Skills
结构化数据 Skills
内容审查 Skills
Google Search Console 分析 Skills

核心原则只有一个：

不要按照 Skills 的名字搜索，而要按照自己准备完成的任务搜索。

安装第三方 Skills 前要注意什么？

Find Skills 可以帮你缩小范围，但不能代替最终的安全判断。

安装之前，建议至少检查以下内容：

查看作者来源

优先考虑官方组织、知名开发者或长期维护的开源仓库。

阅读 Skills.md

确认它会执行哪些步骤、调用哪些命令，以及是否会修改本地文件。

检查脚本和依赖

如果 Skills 带有 Shell、Python、JavaScript 脚本，应先查看脚本内容，不要直接运行来源不明的代码。

检查更新时间和 Issue

长时间没有更新、存在大量未处理问题的项目，需要谨慎安装。

不要一次安装几十个

先根据当前任务安装两三个真正需要的 Skills，使用一段时间后再决定是否保留。

Find Skills 和 `npx Skills find` 有什么区别？

两者都可以帮助你搜索 Skills，但使用方式不同。

npx Skills find 是直接在终端中搜索：

`1`	`npx Skills find seo`

Find Skills 则会先理解你的自然语言需求，再决定搜索哪些关键词，并帮助你整理和比较结果。

简单理解：

npx Skills find 是搜索工具；
Find Skills 是帮助你使用搜索工具的导航规则。

对于已经知道准确关键词的人，直接使用命令会更快。

对于不知道该搜什么、也不知道如何判断质量的新手，Find Skills 更容易上手。

我的使用建议

不要一开始就安装几十个 Skills。

更合理的顺序是：

先安装 Find Skills；
明确当前准备完成的任务；
让它推荐两到三个候选 Skills；
检查来源、安装量、仓库和脚本；
只安装真正适合当前工作的项目；
定期删除长期不用的 Skills。

Find Skills 节省的不只是搜索时间。

更重要的是，它可以减少无效安装，让你的 AI Agent 工具箱保持轻量，并把注意力重新放回真正需要完成的任务上。

项目地址

Find Skills GitHub 项目：https://github.com/vercel-labs/Skills/tree/main/Skills/find-Skills
Skills.sh：https://Skills.sh
Skills CLI 项目：https://github.com/vercel-labs/Skills

Agent Skills on 拾光集

AI Skills 入门教程：用一个 SKILLs.md，让 AI 记住你的工作方法

Skills 是什么？

Skills 能解决什么问题？

1. 减少重复沟通

2. 统一输出标准

3. 沉淀个人工作方法

Skills 的基本目录结构

三步写出第一个 Skills

第一步：写清楚名称和触发条件

第二步：把要求改成可执行规则

第三步：提供输入与输出示例

可直接复制的完整 Skills.md

新手常见的三个错误

触发条件太模糊

规则只有形容词

一个 Skills 承担太多任务

使用第三方 Skills 前要注意什么？

去哪里找现成的 Skills？

总结

5个自定义 Skills，让 Codex 从代码生成器升级为全能 AI 开发助手

一、obsidian-skills：把 Obsidian 变成 Codex 的知识库

它能解决什么问题

适合的使用场景

二、UI Skill：减少 AI 生成网页的模板感

1. 建立设计黑名单

2. 根据业务选择设计语言

3. 增加上线前质检

三、Humanizer-zh：减少中文内容的 AI 味

常见的 AI 写作问题

使用示例

四、grill-me：在开发之前先把方案问清楚

它会重点追问什么

推荐使用阶段

使用示例

五、编码原则 Skill：限制 Codex 的修改范围

推荐的核心原则

五个 Skill 如何组成完整工作流

第一步：读取历史知识

第二步：审查需求

第三步：设计并实现界面

第四步：优化文字内容

第五步：完成最小修改并验证

实际使用时，不需要每次启用全部 Skill

总结

GitHub 项目地址

Skills 创建全流程：从需求规划到测试落地，零基础也能完成

一、什么是 Skill？

第一阶段：前期规划

1. 明确 Skill 的目标

1.1 功能描述

1.2 适用场景

1.3 预期输出

1.4 限制条件

2. 分析实际需求

2.1 用户需求

2.2 技术需求

2.3 性能需求

2.4 兼容性需求

第二阶段：正式创建 Skill

3. Skill 命名规范

4. 使用 Skill Creator 初始化

5. 手动创建 Skill 目录

Windows PowerShell

macOS 或 Linux

6. 标准目录结构

SKILL.md

agents/openai.yaml

scripts/

references/

assets/

LICENSE 或 LICENSE.txt

第三阶段：编写 SKILL.md

7. YAML Frontmatter

8. 编写执行流程

第四阶段：验证与测试

9. 运行基础校验

10. 使用真实任务测试

11. 根据测试结果持续优化

哪些情况适合使用 Skill Creator？

`SKILL.md`

`agents/openai.yaml`

`scripts/`

`references/`

`assets/`

`LICENSE` 或 `LICENSE.txt`