有一段时间，我其实没有太把 Codex 里的 skills 当回事。
那时候我觉得，模型本身已经是最核心的东西了，skills 大概只是一些锦上添花的小组件，有当然更好，没有似乎也无伤大雅。
但这段时间认真把 Codex 用起来之后，我的想法确实变了。
“一个很聪明的 coding model”和“一个真正好用的工作伙伴”之间，差的往往不只是模型本身，更多时候差的是整套工作流。这一点和 OpenAI 最近在 Codex 页面 以及 Codex app 介绍文章 里表达的意思其实很接近：skills 的价值，不只是让 Codex 写代码，而是让它更稳定地参与文档、原型、代码理解、工具调用这些更真实的工作。
OpenAI 还提到，他们内部已经做了数百个 skills。说实话，现在我一点也不觉得夸张了。因为当你开始让 Codex 真正参与写作、调试、浏览网页、做验证、处理仓库协作时，一个好 skill 很快就不再像“附加功能”，而更像是工作环境本身的一部分。
所以这篇文章我不想写成一份大而全的技能目录，我只想写一份我当前这套 Codex 环境里，自己真心觉得值得留下来的 skills 推荐清单。
第一组：让 Codex 更“接地气”的 skills
如果要我用一句话概括 skills 的价值，我会说：它们很大程度上减少了歧义。
所以我会把 web-access 放在很前面。
只要任务涉及实时信息、动态网页，或者任何本来就该去网上确认而不是靠猜的内容，这个 skill 就很重要。它会逼着 Codex 把“上网查证”当成真正的工作步骤，而不是顺手一提。对技术写作、工具调研、事实核对这类任务来说，这个差别其实非常明显。
和它很适合搭配的是 multi-search-engine。
我很喜欢这个 skill 的一点在于，真实搜索本来就是混乱的。有些内容在英文搜索引擎里更容易找到，有些在中文搜索里更直接，还有一些问题必须换搜索引擎、换操作符，才能找到真正有用的信息。这个 skill 未必会让 Codex 在“理论上更聪明”，但它会让实际调研过程更顺手。
再往下就是 mem-search。
这个 skill 很容易在刚开始时被低估，但只要你持续用 Codex 一段时间，它的价值就会越来越明显。过去的 session 一多，memory search 带来的就不只是“找回记录”，而是避免重复劳动、把旧经验真正接起来。如果我问“这件事我们之前怎么解决的”，我想要的是检索，而不是临场发挥。
第二组：能把产出写得更舒服的 skills
我现在用 Codex，早就不只是写代码了。
我还会拿它来写文档、整理思路、润色文字，甚至把一些比较粗糙的想法打磨成可以发出来的东西。
在这种任务里，technical-writer 是我觉得非常值得保留的 skill。
它特别适合文档密集型的工作，比如 README、使用说明、上手指南、结构化解释之类的内容。它最有价值的地方，不是把文字写得更长，反而常常是相反的。它会让内容更清楚、更面向任务本身，也没有那么乱。
然后是 humanizer。
这个我是真的挺喜欢。AI 写作最常见的问题，其实很固定：句子太圆滑，节奏太整齐，读起来像“一个系统正在努力显得专业”。humanizer 的好处就在这里，它会把文字往更正常的人类表达方式上拉一点。这对博客文章尤其重要。我并不希望我的文章读起来像产品宣传稿，或者像一份过于标准化的生成总结。
另外一个我会常备的是 frontend-design。
哪怕我没有要做很夸张的视觉改造，这个 skill 也很有用，因为它会把 Codex 从那种“安全但平庸”的界面输出里往外拉一点。如果我让它做页面优化，或者写一个新模块，我希望最后的结果像是被认真设计过，而不是简单拼起来的。
第三组：能直接帮我省工程时间的 skills
这一组，是我在真正做项目时感受最明显的。
如果是仓库和 review 相关工作，那么 GitHub 这组 skills 非常实用：github:github、github:gh-address-comments、github:gh-fix-ci。
这些 skill 不一定花哨，但非常高杠杆。它们能让 Codex 从“我改了几份文件”进化到“我能理解仓库状态、读 pull request 的上下文、处理 review comment、排查失败的检查项，而且过程中不浪费动作”。
这个变化其实很重要。
同样值得推荐的还有 vercel:agent-browser 和 vercel:agent-browser-verify。只要你在做网站、页面、或者任何偏 UI 的项目，这两个就很实用。因为一个页面“构建成功”和“真的工作正常”，很多时候根本不是一回事。能启动本地服务之后再去浏览器里实际检查一遍，是避免虚假进度最直接的办法之一。
这一点我在这个博客上感受得很直接。嘴上说一句“build 过了”是一回事，真正把页面打开、看看内容、看看交互、看看排版和文案是不是顺，完全是另一回事。
第四组：平时看着普通，但真需要时会特别有用的 skills
有些 skills 第一眼看上去并不惊艳，所以特别容易被忽略。
我说的就是 pdf、docx、pptx、xlsx 这一类。
这些 skills 平时不一定是你最先想到的，但它们恰恰决定了 Codex 能不能从“纯代码工具”走向更完整的工作助手。因为一旦你真的要改 Word、读 PDF、清理表格、或者处理一份 slides，它们就不再是什么附加项，而会变成最快能把事情做完的那条路。
我也会把 skill-creator 放进这一组，不过原因稍微不一样。
OpenAI 最近在文章里提到，skills 的本质是把 instructions、resources 和 scripts 打包起来，让 Codex 更稳定地执行某类工作流。我觉得这里面最重要的点就在于“可复用”。一件事只要重复到一定程度，就值得被封装。自定义 skill 并不只是方便一点，它其实是在把经验沉淀成基础设施。
这也和另一篇 OpenAI 文章 Harness engineering 里提到的观点很契合：一个好的 AGENTS.md 更应该像地图，而不是一本大百科。我挺认同这个判断。稳定规则放在仓库里，保持简短；具体工作流拆到更模块化的位置。skills 恰好很适合承担这部分事情。
如果只能留下五个
如果一定要从我当前这套环境里只留下少数几个，我大概会选下面这五个：
web-accesstechnical-writerhumanizervercel:agent-browsergithub:github
原因倒不是说它们在某种抽象意义上最“高级”，而是因为这几个组合起来，刚好覆盖了我现在最常做的事情：调研、写作、验证，还有仓库工作流。
最后一点想法
我现在的感觉很简单：最好的 Codex 配置，可能并不是 skills 最多的那一套，而是那一小组真正贴合你日常习惯、而且一直可靠的 skills。
对我来说，我想保留的 skills，大概就是能帮 Codex 把下面四件事做好：
- 找到可信的信息
- 把内容写清楚
- 不靠“想当然”，而是去验证真实结果
- 真正融入开发工作流
如果一个 skill 能稳定帮我做到其中一件事，我就愿意留下它。做不到的话，我宁愿列表短一点，环境干净一点。
我之后大概也会继续按这个思路去扩展这套配置：不是不停收集，而是把那些我真的会反复用到的东西留下来。