在使用AI开发工具的这段时间里，我发现了一个有趣的现象：很多人在创建Skill时，往往把问题理解得太简单了。

他们会问"怎么让AI帮我生成一个Skill"，但真正的难点其实隐藏得更深——它不在生成效率，而在需求理解。

这篇文章想解决的，正是这个被忽略的前置问题：当用户的需求本身还很模糊时，我们应该怎样才能稳定地创建出高质量的Skill？

一、问题的本质：需求理解优先于代码生成

在实际工作中，用户提出的需求往往包含这样的表述：

• "帮我给这个项目做一个Skill"
• "以后这个目录下的需求你都要懂"
• "你做方案时要考虑全局"

表面上看是在创建Skill的需求，但深层隐藏的约束往往没有被明说：

• 项目是多模块协同系统而非单体
• 用户真正担心的是AI只做局部修改
• 想沉淀的是长期复用的项目知识
• 希望AI每次动手前都理解全局关系

这说明问题的起点根本不是"怎么生成文件"，而是怎么把模糊表达翻译成真正可执行的约束。如果这一步做错了，后面的Skill写得再规整，也只是把错误的问题定义包装得更漂亮而已。

二、两个工具的分工差异

在同时使用Claude和Codex两套skill-creator的过程中，我发现了一个关键区别：它们优先解决的问题并不相同。

三、Claude的价值：把隐藏需求显化

当面对"你做方案时要考虑全局"这样的抽象表述时，Claude会先停下来深入理解，并将其翻译为具体可执行的约束：

• 修改一个模块前，要先判断会不会影响其他模块
• 涉及接口、事件、数据模型时，要检查上下游是否同步变化
• 不能只围绕单个目录做局部最优方案
• 这个Skill的目的不是介绍项目，而是防止AI做出孤立修改

这里的关键不是"句子更完整"，而是问题定义被重新改写了。原来以为要创建"项目介绍型Skill"，现在发现真正需要的是"全局影响分析型Skill"。这个转变虽然看似只差几个词，但后面的Skill结构会完全不同。

Claude的本质贡献是：完成了创建Skill前最重要的前置工作——把模糊需求里的隐藏约束显化为可执行需求。

四、Codex的价值：把约束固化为符合机制的结构

当需求相对清晰后，Codex更擅长把这些约束真正落实为符合Skill机制的产物。这包括两个核心特征：

1. 更贴近按需加载机制

Codex的skill-creator有一个重要原则：默认假设模型已经足够聪明，只补充它本来不知道但执行任务时必须知道的信息。这对应于Skill最重要的特性——渐进式披露。体现在具体结构上：

• 触发层：只说什么时候该用
• SKILL.md：保留行动原则和关键约束
• references/：细节知识拆进子目录
• 脚本：把脆弱步骤交给脚本处理

最终的Skill更像一个真正的"按需加载工具"，而不是堆满背景资料的长文档。

2. 更擅长处理自由度的位置

对于不同的问题场景，自由度的处理方式应该差异化：

• 对需求理解这种高不确定问题，要给模型足够空间
• 对格式、结构、校验这种低不确定问题，要尽量收紧自由度

Codex在后者上特别稳定，它把那些不值得让模型反复判断的部分，尽量变成确定的结构、模板和校验。这是一件工程上很重要的事。

五、实践路径：串联而非替代

Claude和Codex的最合适用法不是替代关系，而是串联关系。形成的工作流是：

第一步：用Claude处理模糊需求

先不要急着生成Skill，让Claude做这些事：

• 识别需求里没说透的目标
• 补齐真正的风险点和边界
• 把"感觉上想要的东西"翻译成明确约束
• 最终沉淀成一份结构化需求说明

第二步：用Codex的skill-creator创建或更新Skill

当需求相对清晰后，再进入Skill创建阶段。Codex更适合做这些事：

• 组织Skill的层级结构
• 压缩冗余信息，保留真正必要的上下文
• 把高自由度内容和低自由度步骤分开
• 生成更符合按需加载特征的Skill
• 在更新时保持结构稳定，防止Skill越写越胖

这条路径背后的逻辑很自然：Claude负责把需求挖出来，Codex负责把需求固化下来。

前半段的模糊性被先处理掉，后半段的结构化质量也更容易保证。

总结

在我使用Skills的这段时间里，我的认识在不断深化。

最初我以为Skill-creator的核心价值是"提升生成效率"，但现在我更确信，它真正改变的是我们处理知识的方式。

我们开始可以把原本模糊的经验，一步步转化为可复用的方法论。

而这个转化过程中，需求的理解和显化远比代码生成更关键。

所以我的建议是：下次当你有Skill创建需求时，不要直接问"怎么生成"，而是先问"问题真正是什么"。

用Claude挖清楚，再用Codex做扎实。这样一来，你创建的不仅是一个Skill文件，而是一个真正可复用、可维护的知识资产。