大家好，我是 Sunday。
之前写《如何写出一个好的 Skill》时，我花了很多篇幅讲 SKILL.md 该怎么写。最近整理电脑里的 Skill，才发现还有个问题一直没认真处理。
Skill 写得再好，Codex 得先知道什么时候用它。
我把本机两个 Skill 目录扫了一遍，找到了 81 份 SKILL.md。注意，这只是文件数，不等于 81 份都能用。
继续往下看，我找到两份自己用来做公众号选题的 Skill。一份叫 programmer-topic-finder，另一份叫 topic-selection。名字不一样，里面的说明也不完全一样，但开头那段 description 居然一字不差。
两份都说自己负责给 Sunday 策划程序员公众号选题，都覆盖 Agent、RAG、MCP、Skill、AI 编程，还都能处理旧文拆题、热点检索和数据复盘。
我平时让 Codex “帮我想一下明天写什么”，它会看到两个几乎相同的入口。至于最终会不会选错，光看文件还不能下结论，我决定专门试一次。
Codex 选 Skill 时，先看到的是什么
咱们打开 Skill 文件，最容易把时间花在正文上。工作步骤、参考资料、检查标准写得越细，心里越踏实。
可按照 Codex 官方文档，Codex 一开始拿到的是每份 Skill 的名称、描述和路径。等它决定使用某一份 Skill，才会继续读取完整的 SKILL.md。
也就是说，description 负责让它决定要不要进门。正文写得再好，如果入口没选中，后面的内容就没有机会发挥作用。
当 Skill 很多时，初始列表还有长度限制。Codex 会先缩短描述，实在放不下时，可能把一部分 Skill 从初始列表里省掉，并给出提醒。我的 81 份有没有多到这一步，这次没测，先不下结论。但至少能看出来，描述写成一大段“凡是相关都用我”，对选择没有帮助。
OpenAI 最近也专门写文章提醒，很多 Skill 的描述写得太宽，彼此还会抢同一类任务。这个问题和我看到的两份选题 Skill 正好对上了。
我先把那两份真实的选题 Skill 原样放进临时项目，分别问了两次“明天的程序员公众号选题”。GPT-6 Luna 两次都读取了 programmer-topic-finder，没有读取 topic-selection。
所以，描述重复不等于 Codex 当场就会选错。它这两次确实选了一份，也给出了选题。问题在于，只看这两个结果，我仍然不知道它遇到别的说法会怎么选，也没法判断两份 Skill 并存到底有没有必要。
我做了一个很小的对照实验
要继续判断描述相似会带来什么影响，只拿这两份真实选题 Skill 测也有困难。两份都能做选题，任务本身又比较开放。即使记录显示它读了其中一份，我也缺少明确的标准，说这一回用谁才算选对。
于是我在临时目录建了两份测试 Skill。一份处理公众号开头，另一份处理产品发布说明。每份文件里都放了一句容易核对的要求，用到以后，在回复末尾加一句对应的标记。我只用这个标记辅助判断，最后仍然要看工具记录。
这两份是为了实验临时写的，不需要大家安装。标记也只是帮我确认测试结果，正常写公众号文章当然不用在末尾加一句“已按公众号稿处理”。
第一轮，我故意把两份 description 写成同一句话。
description: 处理中文内容的编辑、改写、整理和发布文案，适用于公众号、博客和产品更新说明。这句话有没有毛病？单独看，好像两份 Skill 都能用。但它也没告诉 Codex，写公众号开头时该找谁，整理更新记录时又该找谁。
我给 GPT-6 Luna 发了两类请求，分别让它写一段公众号开头，以及把两条软件更新改成发布说明。每类请求各跑两次。
结果四次都直接给了文字。在这四次 CLI 记录里，我没有看到它读取两份测试 SKILL.md 的工具调用，回复里也没有出现约定的标记。
然后我只改 description，Skill 正文和测试问题保持不变。
# 公众号 Skill
description: 当用户要求撰写或改写微信公众号文章正文、开头时使用。不处理产品更新说明。
# 发布说明 Skill
description: 当用户要求把软件更新记录改写为发布说明时使用。不处理公众号文章。再跑一轮，结果变了。
| 给 Luna 的任务 | 两份描述相同时 | 分清适用范围后 |
|---|---|---|
| 写公众号开头，各跑两次 | 两次都未见读取测试 Skill | 两次仍未见读取 |
| 写产品发布说明，各跑两次 | 两次都未见读取测试 Skill | 两次都读取了发布说明 Skill，并按要求留下标记 |
发布说明那边变好了，公众号开头却没有跟着变。只改清楚 description，并不能保证每条相关请求都会触发 Skill。
这也提醒了我，没读 Skill，不能直接判它“选错了”。 让模型写一小段开头，它可能觉得自己直接就能完成。到底是它没认出 Skill，还是觉得这次用不上，仅凭这条记录分不清。要验证一份 Skill 有没有价值，还得拿它真正负责的复杂任务测，看看规则有没有改善结果。
我又用 GPT-6 Sol 在“分清适用范围”的版本上各跑了一次。这回两类任务都读到了对应的 SKILL.md。不过公众号那次虽然读了文件，最终回复却没有加上约定的标记。
读到 Skill，只能说明它拿到了说明；最后有没有照做，还得看交付结果。 反过来，只看最后一段文字，也未必能准确倒推出它有没有读过 Skill。
我还试了一次在请求里明确写 $wechat-editor。那次回复带上了公众号 Skill 的标记。如果今天这件事必须按某一份 Skill 处理，直接点名确实比让 Codex 自己猜省心。官方文档也把这种方式称为显式调用。
$wechat-editor 是我的临时测试名字。你自己用的时候，换成实际安装的 Skill 名称即可。
当然，每种情况我只跑了两次，Sol 更只跑了一次。这些结果只能帮我发现问题，算不出“Skill 自动选择准确率”，也排不出两个模型谁更会选。
Skill 多了以后，怎么整理
我会先把现有 Skill 的名字和 description 放在一起看。
我那两份选题 Skill，如果分开读，每份都说得过去。并排放在一张表里，职责重叠才显出来。可以先让 Codex 帮你做个只读盘点。
检查我当前项目和用户目录里的 Skill。
列出每份 Skill 的 name、description 和文件路径，找出描述相同或职责明显重叠的条目。
只报告问题和判断依据，先不要修改、删除任何文件。发现重复后，不用急着删。先想清楚它们是不是在做同一件事。如果确实重复，可以考虑合并；如果各有分工，就把区别写到 description 的前面，让人和 Codex 都能一眼看出来。
光看清单还不够，得拿真实请求测。只问 Codex“你能看到哪些 Skill”，我还是不知道它面对具体任务会怎么选。
我会准备三种话。一种明显应该触发，比如“把这段话改成公众号文章开头”；一种明显不该触发，比如“把更新记录写成软件发布说明”；还有一种故意放在中间，比如“把产品更新写成一段适合公众号发的介绍”。第三种最能看出两个 Skill 的边界到底讲没讲清楚。
测的时候看两处。一处是过程里有没有读取目标 SKILL.md，另一处是结果有没有遵守它的要求。我这次通过 CLI 的工具调用记录，看到了读取文件的具体路径；在 Codex APP 里，也可以展开任务里的工具调用，看它有没有打开相应文件。任务越重要，越不能只凭一句“我已经使用了某某 Skill”就算验证通过。
最后还要检查它到底能不能加载。
我这次扫描到 81 份文件，但临时测试用的 Codex CLI 启动时，还提示有 3 份 Skill 因为文件开头的元信息格式有问题而跳过。电脑里有 SKILL.md，和 Codex 真能使用它，中间还差一步。新装完一份 Skill，至少看一眼有没有加载警告，再做一次具体任务测试。
我以前更关心“怎样把一份 Skill 写完整”。装得多了才发现，管理技能库还得处理另一个问题。下次再想加一份新的，我会先看看已有的 Skill 谁在负责同类任务，再决定是修改旧的，还是确实需要新建一份。
那两份描述完全一样的选题 Skill，我也得回去处理一下了。
