Codex教程 on 拾光集

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 工作流程。

Codex教程 on 拾光集

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？

1. 创建新的 Skill

2. 优化已有 Skill

3. 团队协作

4. 固定且重复的工作流

5. 高度定制的业务任务

创建 Skill 时的常见错误

错误一：目标范围过大

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

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

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

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

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

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

总结

相关项目

`SKILL.md`

`agents/openai.yaml`

`scripts/`

`references/`

`assets/`

`LICENSE` 或 `LICENSE.txt`