四个月前，我写过一份自己推荐的 Codex Skills 清单。那时我还在按技能名字做选择，记得当时刚开始时关注点还是在收藏量，web-access、mem-search、humanizer 这些词看起来像一组可以长期保存的工具，但实际上距离真正提升效率以及与 Agent 本身的搭配还差得远。
现在回头看，文章过时得比我预想得快。技能会改名，会更新，会被插件重新打包，也会从一个人的本地缓存进入更正式的 marketplace。更容易被忽略的一点是，能在目录里看到一个技能，和它已经安装、启用、具备依赖，完全是几件事。
所以这次我不再给出一张静态的收藏清单，我更愿意记录自己在这几个月的实际体验中真正会反复调用的工作流，以及每个工作流里值得留下的技能。
先把技能分成三层
现在的 Codex 环境里，我通常会把能力分成三层来看。
第一层是 Codex 本身和项目里的 AGENTS.md。它们负责模型、仓库边界、默认约定和安全规则。一个项目的长期规则放在这里最合适。
第二层是 Skills。一个 skill 通常由 SKILL.md 作为入口，也可以带上脚本、参考资料、模板和示例。它适合描述一套会反复执行的具体流程。
第三层是 Plugins 和外部服务。它们可能带来新的 skills、应用连接器、命令或账号依赖。安装完成只代表文件和入口出现了，是否能在当前环境里调用，还要看注册状态、权限和依赖。
这三层分清以后，很多问题就简单了。仓库规则不要全塞进 skill，偶尔用一次的命令不要急着封装，外部服务也不要因为目录里出现了名字就默认它已经可用。
第一组，负责把事实查清楚
我现在会优先保留 research 和 openai-docs。
research 适合需要查资料、比较方案、核对产品状态的任务。它的价值在于把检索过程变成一份有来源的研究笔记，方便后面写文章、做决策，或者回头复查。它也会提醒我把官方说明、源码和个人判断分开。
涉及 Codex、OpenAI API、模型、计费或产品行为时，我会直接调用 openai-docs。这类信息更新很快，靠旧记忆写一段看似完整的说明，风险比少写两句更大。官方文档解决的是产品当前怎样工作，作者自己的测试再解决普通用户实际会碰到什么。
这组技能的共同点是，它们让“我记得好像是这样”变成“我刚刚核过，出处在这里”。对博客尤其重要，因为一条旧信息会让整篇文章的判断失去时间坐标。
第二组，负责确认页面真的能用
原文里我推荐过 vercel:agent-browser 和 vercel:agent-browser-verify。它们依然有价值，但我现在会把推荐写得更具体一些。
需要控制已经打开、已经登录的网页时，我会用 browser:control-in-app-browser。需要在终端启动本地服务、填写表单、截屏或跑一套可重复的浏览器检查时，我会用 playwright。两者解决的问题不完全一样，前者更像对当前浏览器状态做操作，后者更适合把验证变成工程步骤。
这也是我现在最看重的一组能力。构建成功只说明代码通过了某个阶段，页面是否真的显示正确、移动端有没有挤压、按钮是否能完成动作，还得打开浏览器看一遍。这个博客的文章页、评论区和新页面，我都更愿意把浏览器里的结果当成最后判断。
如果项目是网站或 UI，我还会在需要改视觉时调用 frontend-design。它会把布局、层级、可读性和响应式状态放进同一个任务里，品牌风格仍然由我来决定。没有这个需求时，我不会为了“看起来专业”额外启用它。
第三组，负责把工程反馈闭环
我会把 diagnosing-bugs、tdd 和 code-review 放在一起使用。
遇到报错、行为不对或性能变慢时，diagnosing-bugs 会把任务拉回复现、定位、验证和回归这条线上。它比直接猜一个修复方案更适合处理那些“看起来像缓存，实际是配置或状态”的问题。
要改共享逻辑时，我会让 tdd 先把失败案例写出来，再决定实现范围。小改动可以保持轻量，涉及跨模块契约、用户流程或容易回归的代码时，先有一个能失败的测试，后面的判断会清楚很多。
code-review 适合在改动完成以后重新看一遍风险。它关注的重点是行为回归、边界条件、测试缺口和项目规范。这个步骤经常能发现“代码没问题，但没有满足原始要求”的情况。
GitHub 相关工作则交给 github:github、github:gh-address-comments 和 github:gh-fix-ci。它们分别覆盖仓库和 PR 上下文、审查意见以及失败的 GitHub Actions。这里我会保持一个习惯，先读清楚现状，再动手改；评论已经解决、检查已经通过和文件已经出现在本地，不能混为一谈。
第四组，负责处理代码以外的产物
我仍然会常备 human-writing 和 technical-writer，但会把它们分开用。
human-writing 更适合博客、评论、中文长文和需要保留个人判断的内容。它会帮助我控制语气、材料边界和段落节奏，避免把一段真实经验写成标准答案。
technical-writer 更适合 README、教程、迁移说明、接口文档和面向协作者的知识库。目标是让别人按着文字完成任务，重点在结构、前置条件和验证结果。
处理具体文件时，pdf、docx、pptx 和 xlsx 仍然很值得保留。它们让 Codex 能读懂并修改真实工作里已经存在的文件，也就更容易参与代码之外的任务。尤其是表格和演示文稿，内容正确只是起点，布局和最终渲染也需要检查。
需要生成或修改位图时，我会用 imagegen。这类任务交给图像生成工具更省事，也更容易保持输出格式和素材边界。它和 frontend-design 解决的是两件事，一个处理图像资产，一个处理页面呈现。
第五组，负责把重复经验沉淀下来
skill-creator 是我最近更愿意推荐的技能。
我现在判断一件事是否值得封装，会先看它有没有稳定的输入、步骤和可见结果。比如每次写双语文章都要检查 front matter、翻译链接、事实来源和禁用表达，这种流程重复几次以后，就值得写成 skill。相反，只做过一次的临时命令，留在项目脚本里通常更清楚。
如果要创建完整的 Codex 插件，我会再看 plugin-creator、skill-installer 和 plugin-management。它们解决的是目录结构、安装更新、插件发现、权限和连接管理。对个人环境来说，这些能力最重要的地方是边界清楚，知道什么已经缓存，什么已经安装，什么真正启用了。
这也让我重新理解 AGENTS.md。它应该说明项目怎样工作、哪些边界不能碰，具体流程再交给 skill。规则写短一点，流程写实一点，后面维护起来会轻松很多。
最后一点想法
现在我不太关心一个环境里到底有多少个 skills。我更关心它们能不能在正确的时机出现，能不能说明自己的前置条件，出了问题以后能不能留下可检查的结果。
对我来说，一套舒服的 Codex 环境至少要做到四件事，查资料有出处，改代码有反馈，写内容有自己的声音，重复工作能慢慢变成可复用的流程。
技能目录会继续变化，名字也会继续变化。真正值得留下的，还是那些和日常工作贴得很近、隔一段时间还会再次调用的东西。