Codex Skills on 拾光集

AI 漫剧制作 Skill 工作流：用剧本、资产和分镜提高创作效率

Wed, 29 Jul 2026 11:47:00 +0800

制作 AI 漫剧，真正困难的通常不是生成一张图片，而是如何让剧情节奏、人物形象和镜头衔接保持一致。

目前 GitHub 上已经出现多套面向 Claude Code、Codex 等 AI Agent 的开源 Skills。虽然不同项目的命名并不完全相同，但核心流程基本可以归纳为三类：

剧本创作 Skill
图像资产 Skill
分镜制作 Skill

这三类 Skill 可以把小说或创意逐步转换为剧本、角色资产、分镜表和图像或视频提示词。

一、剧本创作 Skill

剧本 Skill 负责把小说、故事大纲或简单创意，整理成适合短剧和漫剧制作的结构化剧本。

常见输出包括：

故事背景与核心冲突
角色身份、动机和人物关系
分集大纲
场景编号与场景说明
人物动作和对白
每集开头的吸引点
结尾悬念或下一集钩子

它的价值不是单纯“把文字写长”，而是提前解决剧情节奏问题。

很多 AI 漫剧画面并不差，但播放数据不理想，常见原因是开头进入剧情太慢、冲突不明确，或者每集结尾缺少继续观看的理由。

因此，剧本生成后仍然需要人工检查：

前几秒是否出现核心事件
主角目标是否明确
冲突是否能够通过画面表现
对白是否过多
每个场景是否有存在的必要

二、图像资产 Skill

图像资产 Skill 会从剧本中提取需要反复使用的视觉元素，例如：

主要角色
次要角色
服装造型
场景
道具
交通工具
特殊物品
关键视觉符号

随后，它会为每项资产生成结构化说明和图像提示词。

一份实用的角色资产档案，至少应包含：

年龄范围
脸型与五官特征
发型和发色
身材与体态
服装款式、颜色和材质
常用表情
正面、侧面和背面参考
中文与英文提示词
不允许变化的角色特征

这一步的重点是解决**角色一致性**。

同一个人物在不同镜头中出现时，应尽量复用相同的角色描述和参考图，而不是每次重新生成一套提示词。否则容易出现脸型、发型、服装颜色和年龄不断变化的问题。

三、专业分镜 Skill

分镜 Skill 负责把剧本转换成可以直接执行的镜头清单。

它通常会为每个镜头标注：

镜头编号
场景与时间
出场人物
景别
摄影机角度
人物位置
人物动作
表情变化
灯光与色调
镜头运动
台词或旁白
建议时长
首帧或关键帧提示词

例如，剧本中只有一句：

主角发现桌上的合同被人替换。

分镜需要进一步明确：

先用近景展示主角翻开合同
再切换到合同签名位置的特写
主角手指停顿，表情从疑惑变为警觉
镜头缓慢推进
背景声音逐渐减弱
最后切到门外模糊的人影

只有完成这样的镜头拆解，图像模型和视频模型才能获得更明确的执行信息。

三类 Skill 如何组成完整工作流

一套基础的 AI 漫剧生产流程可以按照下面的顺序执行：

第一步：导入故事

输入小说章节、故事大纲或原创创意，明确：

视频类型
目标平台
单集时长
画面比例
目标观众
视觉风格

第二步：生成分集剧本

使用剧本 Skill 输出分集大纲和单集剧本，并人工确认剧情逻辑、冲突和结尾钩子。

第三步：建立资产库

使用资产 Skill 提取角色、场景和道具，先生成角色参考图或三视图。

资产确认后再进入批量分镜阶段，避免后期不断返工。

第四步：生成分镜

使用分镜 Skill 将剧本拆解为逐镜头表格，并生成每个镜头的关键帧提示词。

第五步：生成图片和视频

把已经确认的角色参考图、场景资产和分镜提示词交给图像或视频模型。

生成过程中应优先检查：

人物是否一致
服装是否变化
场景空间是否连续
人物动作能否衔接
镜头景别是否过于重复

使用 Skill 不代表可以完全自动化

Skill 的作用是把经验和制作规则整理成可重复执行的流程，但它不能自动保证作品质量。

实际制作中仍然需要人工完成：

判断故事是否值得制作
修改生硬对白
选择最终角色形象
检查人物和场景一致性
筛选生成结果
控制节奏、配音和音乐
处理版权及人物肖像风险

更准确地说，Skill 能够减少重复整理和提示词编写工作，让创作者把更多时间放在剧情判断和成片质量上。

总结

AI 漫剧制作的关键，不是一次生成多少张图片，而是能否建立稳定的生产流程。

剧本 Skill 负责解决故事和节奏问题，资产 Skill 负责保持人物与场景一致，分镜 Skill 负责把文字转换为可执行的镜头。

将这三类 Skill 串联起来，可以明显减少重复工作，但最终作品是否好看，仍然取决于创作者对剧情、画面和节奏的判断。

Cheat on Content：用 AI 预测视频表现，让内容创作从直觉走向数据

Tue, 28 Jul 2026 16:14:00 +0800

做短视频时，最难判断的往往不是“能不能写出来”，而是：

这个选题值得拍吗？
标题有没有吸引力？
发布后可能获得多少播放？
为什么有些视频表现很好，有些却没有流量？

Cheat on Content 是一个开源的 AI 内容分析工具。它不会承诺准确预测某条视频一定能获得多少播放量，而是帮助创作者建立一套可以持续校准的内容评估系统。

它的核心思路是：

创作稿件
→ 发布前打分
→ 记录预测结果
→ 发布内容
→ 回收真实数据
→ 分析预测偏差
→ 更新评分规则

随着历史样本不断增加，这套系统会越来越了解你的账号，而不是只依赖通用的爆款公式。

Cheat on Content 能做什么？

1. 发布前评估内容潜力

将视频脚本或文章草稿交给 AI 后，它会根据当前评分规则，对内容进行分析，例如：

选题是否符合目标受众
开头是否能够留住用户
标题是否具有点击吸引力
内容结构是否清晰
评论区是否有讨论空间
可能出现哪些传播风险

这些分数不是平台官方预测数据，而是基于历史样本和自定义规则得出的参考结果。

2. 记录发布前预测

工具会在内容发布前保存预测结果，包括：

预估播放量区间
预期互动表现
内容优势
潜在问题
预测依据

发布后再将真实数据导入，避免出现“看到结果后再解释原因”的事后分析。

3. 根据真实数据复盘

视频发布一段时间后，可以录入实际播放量、点赞、评论、收藏等数据。

系统会对比：

1
2
3

发布前预测结果
VS
发布后的真实表现

然后找出预测偏高或偏低的原因，帮助创作者判断：

是选题判断错误
是标题不够准确
是开头留存不足
还是账号受众与预期不同

4. 持续更新评分规则

当系统连续多次出现同一方向的预测偏差时，会提示调整评分规则。

新规则不会直接覆盖旧规则，而是需要重新测试历史样本。只有新规则对过去内容的判断更加准确，才适合继续使用。

这让内容评估从一次性的 AI 建议，变成一套能够持续迭代的创作系统。

如何使用 Cheat on Content？

第一步：初始化内容项目

安装完成后，在 Claude Code 或 Codex 中输入：

`1`	`初始化 cheat-on-content`

工具会询问内容类型、更新频率、账号方向等基础信息，并在项目目录中创建所需文件。

第二步：导入历史内容

建议准备至少 5～10 条历史内容作为初始样本，包括：

表现较好的视频
表现一般的视频
表现较差的视频
对应的标题或文字稿
播放量、点赞、评论等数据

不要只导入爆款内容。

只有同时提供成功和失败样本，AI 才能识别两者之间真正有价值的差异。

第三步：分析新稿件

将准备发布的视频脚本保存到项目中，然后让工具进行打分和预测。

例如：

`1`	`打分这篇 scripts/video-001.md`

或：

`1`	`启动预测 scripts/video-001.md`

AI 会分析稿件并给出修改建议，同时保存发布前预测。

第四步：发布并记录结果

内容发布后，将真实数据录入系统。

工具会把实际结果与原始预测进行对比，并生成复盘记录。

第五步：升级内容评分规则

当历史样本逐渐增加后，系统会根据预测偏差建议更新评分标准。

长期使用后，你会得到一套更符合自己账号、赛道和受众的内容判断方法。

这个工具适合哪些人？

Cheat on Content 比较适合：

短视频创作者
自媒体运营人员
知识类博主
YouTube、抖音、小红书内容团队
需要批量测试选题的企业账号
使用 Claude Code 或 Codex 创作内容的人

它尤其适合已经发布过一批内容，但仍然无法总结流量规律的创作者。

使用时需要注意什么？

预测结果不是流量保证

视频播放量还会受到发布时间、平台推荐、账号权重、热点变化、封面、剪辑质量等因素影响。

因此，预测分数更适合用于比较多个选题，而不是把某个数字当成最终结果。

初期预测误差可能较大

项目说明中提到，如果没有导入历史对标样本，前几篇内容的预测误差可能较明显。

使用时间越长、样本越完整，评分规则才越有参考价值。

数据整理需要一定时间

目前使用过程中，仍需要手动整理脚本和发布数据。

对于完全不熟悉终端、Markdown 或 Claude Code 的用户，初次配置会有一定学习成本。

总结

Cheat on Content 的价值，并不是神奇地算出一条视频能获得多少播放量。

它真正解决的问题是：

将“我感觉这个选题可能会火”，变成一套有记录、有预测、有结果、有复盘的内容实验流程。

对于长期做短视频或自媒体的人来说，单次 AI 改稿并不难，真正困难的是建立稳定的判断标准。

Cheat on Content 提供了一种可执行的方法，让每次发布都能为下一次创作积累数据。

GitHub 项目地址

Cheat on Content - GitHub

Claude Code 安装

1
2
3

git clone https://github.com/XBuilderLAB/cheat-on-content.git
cd cheat-on-content
bash install.sh

Codex 安装

1
2
3

git clone https://github.com/XBuilderLAB/cheat-on-content.git
cd cheat-on-content
bash install.sh --codex

安装完成后，建议重新打开 Claude Code 或 Codex 会话，再执行初始化命令。

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 Skills on 拾光集

AI 漫剧制作 Skill 工作流：用剧本、资产和分镜提高创作效率

一、剧本创作 Skill

二、图像资产 Skill

三、专业分镜 Skill

三类 Skill 如何组成完整工作流

第一步：导入故事

第二步：生成分集剧本

第三步：建立资产库

第四步：生成分镜

第五步：生成图片和视频

使用 Skill 不代表可以完全自动化

相关开源项目

1. Drama Skills

2. 山音超级编剧大师

3. 山音导演大师

总结

Cheat on Content：用 AI 预测视频表现，让内容创作从直觉走向数据

Cheat on Content 能做什么？

1. 发布前评估内容潜力

2. 记录发布前预测

3. 根据真实数据复盘

4. 持续更新评分规则

如何使用 Cheat on Content？

第一步：初始化内容项目

第二步：导入历史内容

第三步：分析新稿件

第四步：发布并记录结果

第五步：升级内容评分规则

这个工具适合哪些人？

使用时需要注意什么？

预测结果不是流量保证

初期预测误差可能较大

数据整理需要一定时间

总结

GitHub 项目地址

Claude Code 安装

Codex 安装

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.md`

`agents/openai.yaml`

`scripts/`

`references/`

`assets/`

`LICENSE` 或 `LICENSE.txt`