企业官网建设流程全解析

最近逛技术社区，几乎每天都在看大家讨论 Codex 的 Skill。有人把它捧成“给 Codex 装上外挂”，有人拿它和 Claude Code 的 Agent Skill 反复对比。我也从刚开始一脸懵，到现在前后试过不下二十种 Skill 脚本，最后筛出五个被点名最多、实测也确实能提升效率的 Skill。这篇文章不整虚的，只聊我自己的使用体验、配置过程，还有几个真正踩过的坑。如果你正在研究 Codex，或者刚听说 Skill 这个概念但不知道从哪下手，这篇应该能帮你少走不少弯路。

先说结论：Codex Skill 不是某个官方突然塞给我们的新功能，而是一种把“经验”打包成文件、再让 Codex 按套路执行的方式。它解决的最大问题，不是 Codex 不够聪明，而是 Codex 每次对话都像失忆一样，需要你把同样的背景、流程、规范反复说一遍。Skill 把这些重复劳动固化下来，让模型一进入任务就知道“先做什么、再做什么、按什么标准交付”。接下来我会把 Skill 的基本原理讲透，然后逐个拆解公认好用的五个 Skill，最后给出一份可以直接照抄的配置流程和避坑清单。

1. Codex Skill 到底是什么？为什么值得折腾

1.1 Skill 和 Agent 的区别

很多人一开始会混淆 Skill、Agent 和普通 Prompt，我在刚开始用的时候也一样。Agent 是可以自主决定“做什么”的智能体，比如让它去分析项目、写代码、跑命令、再根据结果调整策略；而 Skill 更像是一本“岗位手册”，规定的是“当接到某类任务时，应该按什么流程做、输出什么格式、注意哪些边界”。两者不是替代关系，而是配合关系。

你可以这样理解：Agent 是那个干活的人，Skill 是它的 SOP。没有 Skill，你每次都得口头交代“按团队规范写、先设计再编码、最后自查”；有了 Skill，Codex 读到相关任务时自己就知道该按手册执行。普通 Prompt 则更零散，用完就忘，Skill 是沉淀下来的可复用资产。所以 Skill 不是神秘黑科技，它真正改变的是：把“一次性指令”升级成“长期记忆+标准作业流程”。

1.2 Codex 加载 Skill 的基本流程

Codex 之所以能“学会”一个 Skill，核心靠的是一个叫SKILL.md的文件，外加可选的支持文件。通常一个 Skill 的目录结构是这样的：skills/你的技能名/SKILL.md，旁边可能还有references/（参考资料）、scripts/（可执行脚本）、assets/（模板或图片）等文件夹。

当你在对话中引用某个 Skill，或者 Codex 根据任务描述自动匹配到它时，Codex 会把SKILL.md的内容注入当前上下文。这个文件里面写清楚了触发条件、执行步骤、输出格式和注意事项。Codex 读完这个文件，就像拿到一份操作手册，接下来它会按照手册里的动作来工作。如果手册里提到某个脚本，它还可以通过命令行直接运行。

需要注意的是，Skill 并不是越多越好，而是越“精准”越好。一个 200 行、写满各种示例的 Skill，确实能提供很多参考，但也会占用大量上下文窗口，让模型在处理具体问题时变得迟钝。所以社区里真正好用的 Skill，往往都是短小精悍、一句话能说清用途的那种。

2. 五大公认 Skill 清单：我筛选的标准

在展开之前，先说下我怎么选出这五个。首先是社区讨论热度，哪些 Skill 被频繁提起、出现在各种“推荐清单”里；其次是我个人实战后的效果，能不能明显提升产出质量或节省时间；最后是适用范围，不能只对某一个人有用，最好是能被多数人复用的能力。

综合这三点，我最终保留的是：Taste Skill、Humanizer Skill、Archify Skill、WorkBuddy Skill、科研 Skill。这五个分别对应审美判断、文本人性化、代码架构梳理、任务编排和科研辅助，覆盖了我在编程工作之外最常见的几类需求。

2.1 Taste Skill：像请了个有审美的伙伴

Taste Skill 是我个人最惊喜的一个。它的核心能力是：让 Codex 对“做得好不好看、好不好用、有没有品位”这件事给出判断。大多数情况下，Codex 能判断“对不对”，但很难判断“美不美”。比如你给它两版前端页面，让它挑一个更好的，默认回答通常都是很委婉的“各有特点”，这等于没说。Taste Skill 会强制它按维度拆解：视觉层次、留白、色彩对比、字体节奏、交互路径、代码可维护性等等，最后给一个带理由的结论。

我用它审过产品页、调研过 Landing Page 的文案调性，也让它评价过两个方案里哪一个的代码结构更有扩展性。效果比默认 Prompt 好非常多。它的原理其实不复杂：在SKILL.md里明确定义“品味判断”的评价维度，要求 Codex 先逐项打分，再给综合结论，而不是含糊表态。

实操时有一点要提醒：Taste Skill 非常依赖上下文材料。如果你只是丢给它一句话说“帮我判断下哪个更好”，它依旧会给出泛泛而谈的答案。正确做法是把两版方案的关键内容贴进去，最好附上设计目标和使用场景，它才能给出有依据的判断。这也是所有 Skill 的一个共同点——Skill 负责流程，上下文负责素材。

2.2 Humanizer Skill：把“AI 味”洗掉

Humanizer Skill 的名字很直白：让 Codex 生成的文字更接近人类写的。现在很多人都在用 AI 写邮件、写文案、写周报，但一眼就能被看出是 AI 生成的内容，主要是因为句式太工整、用词太“正确”、完全没有个人语气。Humanizer Skill 做的事，就是把这些痕迹一点一点洗掉。

我自己最常用的场景是写英文邮件和中文工作日志。在 Skill 里，我会定义几个改写步骤：先识别文本中的典型 AI 痕迹，比如过度使用“首先/其次/最后”、排比句泛滥、缺少具体细节；然后重写成更自然的句式，适当加入口语化表达，甚至故意保留一点“不完美”的语法；最后对比原文和改后版本，看是否保留了核心信息。

还有一个容易被忽略的用途：把 AI 生成的代码注释“人味化”。默认生成的注释通常是“这是一个函数，用于计算总和”之类的废话，Humanizer Skill 可以让它变成“这里要处理边界情况，之前被坑过两次”这种更有现场感的描述。但注意别滥用，技术文档和接口注释还是准确第一，过度口语化反而显得不专业。

2.3 Archify Skill：代码架构的手术刀

Archify Skill 是我在接手老项目时救命一样的存在。它的功能总结起来就是：帮 Codex 快速梳理项目结构，识别模块边界，分析依赖关系，最后输出一份清晰的架构说明。缺陷在于，默认情况下 Codex 看代码是“看一步走一步”，看到某个文件就全神贯注在那个文件里，Archify Skill 会强迫它先“鸟瞰全景”。

具体使用时，Archify Skill 通常会让 Codex 先扫描目录结构，理清入口文件、核心模块、工具函数和配置文件，再逐层深入到关键业务模块，记录模块之间的依赖和耦合。最终输出一般包括：项目整体架构概览、核心数据流、容易出问题的耦合点、重构建议。

我最推荐在两种场景下使用：一是你刚接手一个没有文档的旧项目，需要快速摸清底细；二是准备做重构，想让 Codex 先盘一盘哪些模块是高风险的。不过要注意，Archify Skill 如果一次性扫描太多文件，非常容易超出上下文限制，输出也会变得冗长。我的做法是在 Skill 指令里明确限制扫描深度和文件数量，比如只分析src下的前 50 个核心文件，其他先跳过。

2.4 WorkBuddy Skill：让 Codex 帮你管任务

WorkBuddy Skill 是把 Codex 变成一个“轻量任务管理器”。它跟 Jira、Notion 这些工具不同，不追求完整的项目管理能力，而是聚焦在“把大目标拆成小步骤，并排出合理顺序”。每次我拿到一个需求，不想自己动脑拆解时，就会让我调用 WorkBuddy。

举个例子，我想做一个“个人博客站”，直接让 Codex 做，它可能一口气给你生成一堆文件。但用 WorkBuddy Skill，它会先问清楚目标、技术栈、时间范围，然后输出一个有条理的任务清单：第一步搭框架，第二步设计数据库，第三步实现文章发布功能，第四步做部署，每一步还附带验收标准。这种“由远及近”的规划方式，比默认的“直接开写”要高效得多。

我实际用下来的心得是：WorkBuddy Skill 适合做计划和任务拆解，但别让它承担太重的事务跟踪功能。Codex 本身没有持久化任务状态的能力，你关掉对话后它就不记得了。所以我通常只在一次会话内让它输出计划，然后自己把清单保存到项目文档里，或者粘贴回对话中继续追踪。

2.5 科研 Skill：从查文献到憋论文的辅助

最后一个科研 Skill，是我最近被问得最多的。它本质上是一个“科研工作流增强包”，专门给做学术研究、写论文、做实验设计的人用。很多人以为 Codex 只适合写代码，其实在科研领域，它同样能做很多辅助工作：总结文献、搭建论文框架、设计对比实验、检查统计方法选择合不合理，甚至帮你润色学术英语。

我试用了一个社区版本的科研 Skill，效果相当不错。比如说，你给它一个研究问题，它会按“背景-方法-结果-讨论”的标准论文结构来引导你整理材料；把几篇论文的摘要贴进去，它可以生成文献综述的初始框架，并标出哪个方向还缺证据；你在实验设计上犹豫时，它还会提醒你注意对照组设置和样本量。

当然也要泼一盆冷水：科研最核心的创造性和严谨性没法靠 Skill 外包。它能帮你把流程规范好，但实验数据是否真实、结论是否站得住脚，仍然需要你自己判断。我通常是把它当作“第二大脑”，用来整理思路和快速生成初稿，再用自己的专业知识反复核验。

3. 从零配置一个属于你的 Skill

3.1 创建一个最小可用的 SKILL.md

与其直接下载别人的 Skill，我更建议你至少自己创建一个，只有亲手搭过一次，才能真正理解它的工作方式。创建一个 Skill 非常简单，首先建一个目录，名字就是你的 Skill 名，比如my-skill。然后在里面新建一个SKILL.md文件，文件内容一般分两部分：YAML frontmatter 和正文指令。

以下是最小可用的示例：

--- name: my-skill description: 当用户需要整理一篇技术笔记时使用，要求结构清晰、提炼重点。 --- # My Skill ## 目标 将用户输入的内容整理为结构化技术笔记，包含背景、核心思路、关键代码和注意事项。 ## 步骤 1. 读取用户输入，识别主题。 2. 提取核心思路，用 2-3 句话概括。 3. 整理关键代码或配置，省略无关细节。 4. 列出至少 3 条注意事项。 5. 输出 Markdown 格式。 ## 输出格式 - 背景 - 核心思路 - 关键代码 - 注意事项

这个 Skill 虽然简单，但已经具备完整结构：有触发条件描述、有执行步骤、有输出格式。你把它放到 Codex 能读取的位置后，当用户输入相关需求时，Codex 就会自动按这套流程来。

3.2 写好 Frontmatter 和 Instructions

很多人容易忽略description字段，实际上它是决定 Codex 会不会主动匹配到你的 Skill 的关键。这里的描述要写清楚“什么场景下使用”，而不是写“这个 Skill 很好很强大”。比如“当用户需要整理技术笔记时使用”就比“处理文本”要精准得多。你可以理解为 Skill 的索引词，Codex 读到任务时会根据这个描述来判断要不要调用。

Instructions 正文部分是核心，原则上要具体、可执行。除了列步骤，还可以包含“禁止做什么”。比如在 Humanizer Skill 里，我会明确写“不要使用‘首先、其次、最后’这类套路化连接词”；在 Archify Skill 里，我会写“不要试图一次性分析所有文件”。这些边界条件能极大程度避免模型自由发挥。

同时，建议在 Instructions 里加入“输入要求”和“输出示例”。有了一次完整示例，模型的稳定性会明显提升。示例可以放在references/example.md里，然后在正文中说明“如果需要查看示例，请读取 references/example.md”。

3.3 放到 Codex 能读到的目录

Skill 文件写完之后，最关键的一步是放到正确位置。以常见用法为例，Codex CLI 会扫描当前工作目录下的.codex/skills文件夹，也会扫描用户全局配置目录下的skills文件夹，比如~/.codex/skills。我一般把个人通用技能放在全局目录，把项目相关的技能放在仓库里的.codex/skills下，这样既能复用又方便团队其他人 clone。

如果你用的是桌面版，可能还需要在设置里确认技能目录路径。这里有个小技巧：改完 Skill 后，最好新开一个会话再测试，因为已经开始的对话不一定能及时刷新技能列表。我一开始就老是在同一个会话里反复试，结果一直没生效，开了新会话才正常加载。

另一个很多人忽略的点是：项目内.codex文件夹一旦被.gitignore忽略，团队成员就拉不到你的 Skill。如果你希望 Skill 跟仓库一起分发，记得在.gitignore里放行。反之，如果你只在本地用，就无所谓。

3.4 测试与迭代技巧

Skill 不是写完就能一次跑对，它需要像一个程序一样反复测试。我的建议是先用一个非常小的测试用例，看看 Codex 会不会触发你的 Skill，以及输出格式是否符合预期。如果触发不了，优先检查description是否足够明确；如果触发但输出的东西不对，就看看是步骤不够具体，还是缺示例。

迭代过程中我有两个习惯。第一，把测试过程中出现的好结果保存到references/里，作为 few-shot 示例。第二，在 Skill 中加入“反例”，也就是“不要这样做”的说明，比如在 Humanizer Skill 里，我会写“不要保留任何‘作为一个人工智能模型’之类的表达”。好的 Skill 是在一次次反馈中打磨出来的，不要指望一次成型。

最后提醒一点：Skill 的上下文体量要克制。一个 Skill 包含太多内容，模型容易抓不住重点。能精简到 50 行以内就尽量精简；更详细的资料放references/，让模型按需读取，而不是一股脑全部注入。

4. 常见问题与避坑记录

4.1 明明放好了 Skill，Codex 就是不理我

这是出现频率最高的问题。常见原因有三个：目录名称不对、frontmatter 格式不合法、描述与任务匹配不上。目录名称最好全小写，用连字符连接；SKILL.md文件名不能写错；frontmatter 里至少要包含name和description两个字段，且注意 YAML 缩进，我见过因为多了一个空格导致解析失败的案例。

排查时可以先用命令或桌面端查看当前已加载的 Skill 列表，确认文件到底有没有被识别。如果列表里没有，就检查目录路径；如果列表里有但对话不自动触发，就先尝试显式引用，比如在对话里输入@my-skill 帮我整理笔记，这样能强制 Codex 加载。显式引用成功后，再进一步优化description，让它在相关场景下自动匹配。

4.2 多个 Skill 打架怎么办

当同一段任务可能匹配到多个 Skill 时，Codex 可能会把多个指令揉在一起，输出非常拧巴。比如同时触发 Taste Skill 和 Humanizer Skill，模型既想判断审美，又想改成人味，结果两头不讨好。解决方法是给每个 Skill 划定足够清晰的边界，避免描述重叠；同时在一个任务中尽量只关注一种能力。

如果确实需要多个 Skill 协作，我的做法是分阶段调用：先让 Codex 用 Taste Skill 做判断，拿到结论后，再单独要求它用 Humanizer Skill 润色结果。不要在同一个指令里同时提两个 Skill，除非它们在流程上明确是前后关系。另外，检查一下项目配置里是否启用了不必要的全局 Skill，临时禁用可以避免干扰。

4.3 上下文太长被截断

Skill 的目的是指导模型，但技能文件本身也会占用宝贵的上下文窗口。如果SKILL.md写得像一本小册子，再加上用户自己的材料，很容易让模型在处理核心问题时“忘了前面的内容”。我见过一份社区 Skill 整整写了 600 行，结果实际推理时模型依赖大减。

解决技巧是：精简SKILL.md本体，把详细示例、模板、背景资料放到references/子目录中。在正文里写清楚“如果需要查看 examples，请读取 references/example.md”。这样模型默认先读取精简指令，必要时再展开细节，能极大缓解上下文压力。还有一个小技巧是，让 Skill 指令本身也遵守“先结论、后细节”的结构，关键步骤放在最前面。

4.4 切换服务商或接口地址后请求失败

我自己在折腾 Codex 时也遇到过一类比较头疼的报错：明明配置都改好了，但一请求就提示 endpoint 地址不符、请求失败之类。很多人在切换服务商或本地接口配置时会遇到。大部分问题的根源是客户端和服务端之间的接口版本不匹配，或者是切换过程中残留了旧配置。

我这里的建议很简单：遇到这种问题，先检查环境变量里有没有设置旧的 endpoint 地址，把它清掉后重试；其次确认版本更新到最新；最后如果仍不行，就删掉本地的临时配置文件，重新登录。不要一上来就怀疑某个 Skill 的问题，这通常是环境层面的问题，和 Skill 关系不大。折腾的时候留一点耐心，大部分这类问题最终都能通过清理配置解决。

5. 我的真实使用感受与建议

5.1 哪些人适合用 Skill，哪些人不适合

说实话，Skill 并不是每个人的刚需。如果你只是偶尔用 Codex 写一段一次性脚本，不追求稳定规范和可复用的流程，那完全没有必要折腾 Skill，多写几个 Prompt 就够了。但如果你是重度用户，每天都在用 Codex 做代码开发、文档撰写、内容创作，而且特别希望输出风格稳定，那么 Skill 的收益会非常明显。

另外，团队协作场景特别适合用 Skill。你可以把团队的编码规范、提交信息格式、代码审查重点都写进团队共享的 Skill 里，这样每个用 Codex 的同事都能获得同样的“肌肉记忆”。与之相对，如果你只是想玩一玩、不想维护一堆文件，那可以先从别人整理好的 Skill 合集开始，用顺了再创建自己的。

5.2 我知道的几个 Skill 资源获取渠道

找 Skill 最直接的地方是 GitHub，搜索awesome-codex-skills、codex skills等关键词，有很多社区维护的合集。现在不少开发者把自己的 Skill 仓库公开出来，你可以在里面挑几个热门的试。还有一个渠道是各类 Codex 用户群和社区，大家在群里分享自己的 Skill，遇到问题也能直接问。

这里要特别提醒安全问题：Skill 本质上是一堆指令，而且可以引用可执行脚本。下载别人写的 Skill 之前，一定要先打开文件看一遍，确认里面没有奇怪的命令或要求。我见过一些 Skill 会引导 Codex 读取敏感文件甚至运行不明脚本。安全第一，千万不要觉得“别人分享的肯定没问题”。

5.3 最后的小技巧

最后分享一个小技巧，也是我用了这么久最深的体会：写 Skill 时，不要追求“大而全”，而是从一个小痛点开始。比如先写一个“让 Codex 帮你写 git commit message”的 Skill，指令就三五行，跑通之后再逐步加上更多细节。你在一次次微调中，才会慢慢明白 Codex 的脾气，才能真正写出让自己用着顺手的 Skill。

我个人在实际操作中的体会是，Skill 的最大价值不是让 Codex 变得更“听话”，而是让我的经验和判断力变得可以复制。以前我接手一个新项目，需要花很久给 Codex 解释各种背景；现在只要给它一个合适的 Skill，它自己就知道按什么节奏来。这个转变看起来很轻，实际用起来却是天壤之别。如果你还没试过自己配一个 Skill，我建议你今天就去写一个最简单的，跑通一遍全流程，你会回来感谢自己。