1. 从“技能货架”说起Codex 的 skill 到底是个什么东西第一次接触 Codex 的 skill 体系很多人会有点懵。官方文档里把它描述得很抽象社区里又冒出 SKILL.md、agent skill、skill 插件、workbuddy skill 一堆名词看下来还是不知道它到底解决什么问题。我自己的理解是skill 就是给 Codex 这个通用助手装上的“专业外挂”让它从“什么都能聊两句”变成“某个具体活儿干得特别利索”。打个生活化的比方。Codex 本身像一个刚毕业的高材生脑子好使、知识面广但你让他直接上手做一份规范的测试用例、写一套 Playwright 自动化脚本、或者按公司模板生成一份周报他大概率会给你一个“能跑但不够专业”的结果。skill 的作用就是把你平时积累的那套“怎么做才对”的经验固化成一个可复用的模块Codex 每次遇到同类任务就自动调用输出质量立刻上一个台阶。这也是为什么“翻完 Codex 的技能货架我留下了这几个”这个标题特别戳我。技能货架上的东西太多了官方自带的、社区贡献的、各种 skill 编码 247、skill 编码 193 之类的编号版本满天飞全装上去只会让 Codex 变得又慢又乱。真正有价值的做法是先搞清楚 skill 的运作机制再根据自己的高频场景做减法只留那几个真正提升效率的。这篇文章就是把我自己筛选、试用、踩坑的全过程摊开讲。适合两类人看一类是刚装好 Codex、面对一堆 skill 不知道从哪下手的另一类是已经装了一堆、但感觉没发挥出效果、想重新梳理的。我会把每个留下来的 skill 为什么留、怎么配、实际用起来什么感觉都讲清楚也会把那些被我删掉的坑一并交代省得你再走一遍。2. 先搞懂机制SKILL.md 是怎么被 Codex 读进去的2.1 skill 的目录结构与加载逻辑在动手装任何 skill 之前我强烈建议先把一个 skill 的目录结构看明白。绝大多数 Codex skill 的形态都长这样my-skill/ ├── SKILL.md # 核心描述文件必须有 ├── scripts/ # 可选放可执行脚本 ├── references/ # 可选放参考资料 └── assets/ # 可选放模板、图片等其中SKILL.md 是整个 skill 的灵魂。Codex 在启动或者被触发时会扫描 skill 目录读取每个 SKILL.md 里的元信息通常是 YAML front matter 格式包括这个 skill 叫什么、什么时候该用、需要哪些参数。你可以把它理解成一张“名片 说明书”Codex 靠这张名片判断当前任务要不要调用这个 skill。一个典型的 SKILL.md 头部大概是这样--- name: playwright-test-generator description: 根据页面结构或需求描述生成 Playwright 测试用例 trigger: 当用户提到测试用例、自动化测试、Playwright 时激活 ---下面才是正文用自然语言写清楚这个 skill 具体怎么执行、有哪些步骤、输出格式是什么。这里有个关键点很多人忽略description 和 trigger 写得越精准Codex 调用得越准。我见过有人把 trigger 写成“处理各种任务”结果这个 skill 几乎从不被触发因为 Codex 判断不出什么时候该用它。2.2 为什么“货架”上大部分 skill 你其实用不上技能货架上的 skill 大致分几类官方维护的基础能力类、社区贡献的垂直场景类、以及各种个人定制的实验性 skill。我翻下来最大的感受是——80% 的 skill 是为别人的工作流量身定做的。比如有些 skill 是专门做某类特定文档格式转换的有些是针对某个小众框架的代码生成还有些是“前任 skill”“狗头军师 skill”这种偏娱乐向的。它们本身可能做得很好但和你的日常高频场景不匹配装上去只会占用上下文、增加 Codex 的判断负担。我自己的筛选标准就三条高频一周至少会用两三次的场景才值得装高价值这个活儿手工做很费时间或者很容易做错可验证skill 的输出我能快速判断对错不会引入隐性风险按这三条筛下来货架上真正值得长期留的其实没几个。下面就是我最终留下的那几个以及它们各自的实战表现。3. 我留下的第一个create-plan把“想清楚”这件事自动化3.1 create-plan 解决的到底是什么痛点create-plan 这个 skill 是我用得最频繁的一个没有之一。它解决的问题特别朴素在动手写代码或做任何复杂任务之前先逼自己把计划列清楚。你可能觉得这不就是让 Codex 帮忙列个 to-do 吗没那么简单。普通的“帮我列个计划”得到的往往是一堆正确的废话比如“第一步分析需求、第二步设计方案、第三步实现”。而 create-plan 这个 skill 内置了一套结构化的追问逻辑它会先反问你几个关键问题把你的模糊需求逼成清晰目标然后再输出一份带依赖关系、带验收标准的执行计划。我实测下来用它规划一个中等复杂度的功能开发能省掉至少半小时的来回澄清。因为它在生成计划的过程中会主动识别出“这里有个前置依赖你还没确认”“这个步骤的验收标准不明确”这类问题。3.2 create-plan 的实操配置与调用方式安装 create-plan 之后SKILL.md 里最关键的是它的触发条件。我把它配置成当任务描述超过两句话、且涉及多个步骤时自动激活。这样既不会在小任务上浪费调用又能在真正需要规划的时候及时介入。实际使用时我的习惯是先把需求用大白话丢给 Codex然后明确说一句“用 create-plan 帮我拆一下”。它会输出类似这样的结构阶段任务前置依赖验收标准1确认数据模型字段无字段清单评审通过2实现接口层阶段1单测覆盖核心分支3接入前端阶段2联调通过这个表格看起来简单但前置依赖那一列是精华。很多项目延期不是因为某一步难而是因为步骤之间的依赖没理清做到一半发现前面缺东西。create-plan 会强制你把依赖显式写出来这一点比人肉规划靠谱得多。提示create-plan 生成的计划不要直接照单全收尤其是验收标准那一列一定要自己过一遍。我遇到过它把“代码能跑”当成验收标准的情况这种标准太松等于没标准。3.3 一个真实的使用场景复盘上个月我要给一个内部工具加导出功能。需求原话是“支持把列表导出成 Excel”。如果直接开干我大概率会先写导出逻辑写到一半发现还要处理权限、还要考虑大数据量分页、还要统一文件命名规范。用 create-plan 走了一遍之后它帮我拆出了这么几个隐藏点导出权限要和列表查看权限对齐、超过一万行要异步生成、文件名要带时间戳避免覆盖。这几个点如果靠我自己想可能要到测试阶段才暴露。这就是 create-plan 的价值——它不帮你写代码它帮你把“没想到”变成“想到了”。4. 我留下的第二个Playwright 测试用例生成 skill4.1 为什么测试用例生成值得单独做一个 skillPlaywright 现在几乎是前端自动化测试的标配但写测试用例这件事本身很枯燥。一个页面十几个交互点每个都要写定位、写断言、写等待纯手工写一天下来眼睛都花。更麻烦的是Playwright 的定位器写法有很多坑比如动态 iframe 里的元素、懒加载的列表、需要等待网络请求完成的场景新手很容易写出“本地能跑、CI 上必挂”的用例。所以当我看到货架上有专门做 Playwright 测试用例生成的 skill 时第一反应就是必须试。它的核心逻辑是你给它页面结构或者一段需求描述它输出符合 Playwright 最佳实践的测试代码包括合理的等待策略、稳定的定位器、清晰的断言。4.2 生成用例的质量到底行不行我拿一个真实的登录页做了对比测试。手工写的用例大概是这样await page.click(#login-btn); await page.waitForTimeout(2000); expect(await page.title()).toBe(首页);这个写法有两个问题waitForTimeout是硬等待慢且不稳定用 id 定位在重构后容易失效。而 skill 生成的版本是await page.getByRole(button, { name: 登录 }).click(); await expect(page).toHaveURL(/dashboard/);它用的是role-based 定位这是 Playwright 官方推荐的方式可读性和稳定性都更好。断言也直接用了toHaveURL这种自动重试的断言不需要手动等待。这一对比就能看出 skill 里沉淀的是真正的最佳实践而不是随便生成的代码。不过它也不是万能的。涉及复杂业务逻辑的用例比如“下单后库存扣减且订单状态流转正确”skill 生成的骨架还需要你补充具体的业务断言。我的经验是把它当成一个高质量的起手模板而不是全自动的测试工厂。4.3 处理动态 iframe 和复杂等待的实战技巧热词里有个“scrapy playwright 动态 iframe”说明动态 iframe 是很多人的痛点。我在用这个 skill 的时候专门测了这类场景。它的处理思路是先定位 iframe再在 iframe 的上下文里操作元素const frame page.frameLocator(iframe[namecontent]); await frame.getByText(提交).click();这个frameLocator的写法比老式的page.frame()要稳因为它支持自动等待 iframe 加载完成。踩过的坑是如果 iframe 是动态插入的光靠 frameLocator 还不够需要在操作前加一个await page.waitForSelector(iframe[namecontent])确保 iframe 本身已经出现在 DOM 里。还有一个高频问题是npx playwright install失败。这个和 skill 本身无关但会直接影响你能不能跑起来。常见原因是网络下载浏览器二进制超时解决办法是配置国内镜像源或者手动下载对应版本的浏览器放到缓存目录。这个坑我在“常见问题”那节会详细展开。5. 我留下的第三个去 AI 味的写作 skill5.1 “去 AI 味”这个需求是怎么来的热词里“去 ai 味的 skill”出现频率很高说明这是个普遍痛点。现在用 AI 生成的内容太多了一眼就能看出那种“通过……可以……”“随着……的发展”的套路。如果你要把 AI 辅助生成的内容直接发出去不改一遍基本没法看。这个 skill 的思路不是简单地替换几个词而是从句子结构层面做改造。它会识别出典型的 AI 句式比如过度使用被动语态、滥用连接词、每段都以总结句开头然后给出改写建议。5.2 它的改写逻辑和实际效果我拿一段典型的 AI 生成文字测试了一下。原文是“通过本文的介绍读者可以了解到 Codex skill 的基本概念随着技术的不断发展skill 的应用场景将越来越广泛。”skill 改写后变成“Codex skill 说白了就是给助手装外挂。装什么、怎么装直接决定它干活利不利索。”这个改写抓住了两个关键把抽象名词换成具体动作把展望式空话换成直接判断。我实测下来它对“通过”“随着”“为……提供支持”“综上所述”这几个高频 AI 词的识别很准改写后的文字读起来确实更像人写的。不过要注意这个 skill 是辅助不是替代。它改完的稿子你还是得自己读一遍因为有些改写会改变原意或者把专业表述改得太口语化不适合正式文档。我的用法是先让它过一遍把明显的 AI 味去掉然后自己再润色一遍语气和准确性。5.3 怎么判断一段文字有没有 AI 味用久了这个 skill我自己也总结出一套判断标准分享出来看开头如果第一句是“随着……的发展”或者“在当今……的背景下”基本可以判定看连接词密度一段话里出现三个以上“因此”“然而”“此外”要警惕看结尾如果结尾是“综上所述”“总之”“为……提供了有力支持”几乎可以确定看句式通篇都是“通过 A 可以实现 B”这种结构缺少主语的主动表达AI 味很重这套标准配合 skill 使用效率会高很多。你先自己扫一眼标记出可疑段落再让 skill 针对性改写比全文丢给它效果更好。6. 那些被我删掉的 skill以及删掉的理由6.1 功能重叠的 skill 只留一个货架上有很多功能重叠的 skill。比如光是“代码审查”类的就有三四个不同版本有的偏重风格检查有的偏重安全漏洞。我一开始全装了结果 Codex 每次遇到代码审查任务都要在几个 skill 之间犹豫输出反而不稳定。后来我的做法是同类功能只留一个选那个 trigger 写得最精准、输出格式最符合我习惯的。剩下的全部删掉。删完之后 Codex 的响应速度明显变快输出也更聚焦。6.2 低频场景的 skill 果断舍弃有些 skill 做得确实精致比如“book to skill”能把一本书的内容拆成结构化笔记“ai 备课 skill”能帮老师生成教案。但我一年也用不上一次留着就是占地方。skill 不是收藏品是工具用不上的工具再漂亮也该收起来。我给自己定了个规矩装一个新 skill 之前先问自己过去一个月有没有遇到过需要它的场景。如果没有就先不装等真的遇到了再说。这个规矩帮我砍掉了至少一半的冲动安装。6.3 输出不可控的 skill 风险太大还有一类 skill 我删得很坚决就是输出结果我无法快速验证的。比如某些自动生成数据库迁移脚本的 skill它生成的 SQL 看起来没问题但实际执行可能锁表、可能丢数据。这种 skill 一旦出错代价太大不如自己老老实实写。判断标准很简单这个 skill 的输出我能不能在三十秒内判断对错。能就留着不能就删掉或者只在沙箱环境用。7. 常见问题与排查技巧实录7.1 skill 装了但 Codex 不调用怎么办这是最高频的问题。排查顺序我一般是这样的排查项检查方法常见原因SKILL.md 格式检查 front matter 是否合法YAML 缩进错误trigger 描述看是否过于宽泛或过于狭窄描述模糊导致匹配失败目录位置确认放在 Codex 扫描的路径下放错目录命名冲突是否有同名 skill后装的覆盖了先装的我遇到最多的是 trigger 写得太泛。比如写成“处理文档相关任务”Codex 根本判断不出什么时候该用。改成“当用户要求生成 Markdown 格式的技术文档时激活”命中率立刻上来了。7.2 Playwright 相关 skill 跑不起来的排查Playwright 的坑主要集中在环境上。npx playwright install失败是最常见的通常是下载浏览器二进制时网络问题。解决办法有两个一是配置镜像源二是手动下载对应版本的 Chromium 放到~/.cache/ms-playwright目录下。还有一个坑是版本不匹配。skill 里用的 Playwright API 可能是较新版本的写法而你本地装的是老版本跑起来就报错。我的习惯是装完 skill 先看一眼它依赖的 Playwright 版本然后本地对齐。注意如果你在 CI 环境跑 Playwright记得把浏览器缓存目录也缓存起来否则每次构建都要重新下载慢得让人崩溃。7.3 skill 之间互相干扰怎么处理装多了 skill 之后偶尔会出现“A skill 该触发的时候触发了 B”的情况。这通常是因为两个 skill 的 trigger 描述有重叠。解决办法是给每个 skill 的 trigger 加上排他性条件比如“当用户明确提到 X 关键词时激活不适用于 Y 场景”。如果调整 trigger 还是不行那就只能做减法了。这也是我前面反复强调“只留高频高价值”的原因——skill 数量本身就是一种成本。8. 我个人的 skill 管理习惯8.1 定期清理比不断安装更重要我现在每个月会花十分钟过一遍已装的 skill问自己三个问题这个月用过吗用的时候效果好吗有没有更好的替代三个问题里有两个答不上来就删。这个习惯坚持了几个月我的 skill 列表从最初的二十多个精简到了现在的五个。数量少了但每个都是精兵强将整体效率反而更高。8.2 给 skill 写使用笔记每个留下来的 skill我都会在本地记一笔什么时候装的、解决什么问题、有什么坑、典型调用示例。这个笔记不放在 skill 目录里单独放一个文档。好处是过一段时间忘了某个 skill 怎么用翻笔记比翻 SKILL.md 快得多。8.3 新 skill 先在沙箱试看到感兴趣的新 skill我不会直接装到主力环境而是先在一个隔离的测试环境里跑几个真实任务。确认输出质量稳定、没有副作用再迁移到主力环境。这个习惯帮我避免了好几次“装了新 skill 结果把原有工作流搞乱”的事故。说到底Codex 的 skill 体系是个好东西但它考验的不是你装了多少而是你能不能克制住“全都想要”的冲动只留下真正服务于自己工作流的那几个。翻完整个货架我最后留下的这几个每一个都经过至少一个月的实战检验每一个都能说清楚它帮我省了多少时间、避了多少坑。这个筛选过程本身可能比 skill 本身更有价值。