坦白说,很多人用 Codex 的方式,其实没太发挥出它的潜力。不是因为模型不够强,而是因为没把该配的 Skills 补上。模型只是下限,真正决定你能用到什么程度的,是你有没有把工作流这一层搭起来。
Codex 自己是这么描述 Skills 的——"让 Codex 按你的方式工作"。这句话听着简单,但背后的意思是:同样用 Codex,有人只是补几个函数、修几个 bug,有人已经在拿它读仓库、跑网页、做验证、回 PR 评论、整理发布说明。差别不在"它会不会",而在"你有没有把这件事真正交给它"。
下面这10类 Skills,是值得你优先配置的方向。
01 浏览器执行 / 交互验证类
很多活,不是在编辑器里干完的。
代码写完,你还是得打开网页、登录后台、点按钮、填表单、走一遍流程,看结果到底对不对。这些动作如果还要自己手动补,Codex 就只帮了你一半。
登录后台、点按钮跑流程、填表单、看页面变化、验证功能是不是按预期生效——这些场景,浏览器执行类 Skill 基本闲不住。
代表 Skill:playwright-interactive
02 截图 / 视觉验收类
很多 bug,不是逻辑错了,是页面错乱了。
按钮能点,不代表位置没乱。接口通了,不代表 UI 没崩。你本地觉得差不多,不代表用户看到的也对。
做前端、后台系统、活动页、管理台的时候,这类 Skill 能帮你少踩很多"代码没错但页面不对"的坑——UI 检查、视觉验收、问题定位、改完再确认有没有回归。
代表 Skill:screenshot
03 仓库阅读 / 文档抽取类
很多人一上来就让 Codex 开改,结果改得快、崩得也快。
局部看着没问题,放回整个项目里就不太对劲。最常见的原因不是模型不够强,是它还没把你的项目读明白。README、架构文档、接口说明、目录结构、关键代码——这些东西如果没先过一遍,后面很多修改其实都像在猜。
思路很直接:先读,再改。先让 Codex 搞清楚这是个什么项目,再让它动手。
搜索关键词: repo docs / readme reader / docs extract / architecture docs / codebase summary
没有现成合适的,用 skill-creator 自己做一个。
04 Research / Web Search 类
很多开发任务,光看本地仓库是不够的。
你还是得查官方文档、查版本变化、查社区讨论、查 issue、查别人是怎么落地的。全靠模型硬答,很容易变成"听着有道理,做起来又不是那回事"。
这类 Skill 的意义很明确:先去查,再给建议。给你的不是拍脑袋的回答,而是查过之后的说法。
搜索关键词: research / web search / docs search / developer docs / deep research
05 任务拆解 / 计划类
很多任务不是不会做,而是一上来就做,最后越做越乱。
多文件修改、接口变更、状态流调整、测试补齐、回归验证——没有先想清楚,后面很容易反复返工。
计划类 Skill 最值钱的地方,不只是帮你多做一步,而是在事前先帮你把事情想顺。先排步骤、看依赖,先想哪步容易出问题,再动手。
搜索关键词: create plan / task planning / feature planning / execution plan / break down task
06 代码审查 / 重构 / 最佳实践类
有很多代码不是不能跑,而是以后不好改。
功能能上,不代表结构合理。bug 修掉,不代表下次改的时候不头疼。现在省的那一点时间,后面可能成倍还回去。
这类 Skill 盯的不是"这次能不能交差",而是"这堆代码以后还顺不顺手"——命名别不别扭、结构是不是太绕、重复逻辑能不能改、改完之后是不是更容易维护。
搜索关键词: code review / refactor / best practices / engineering quality / cleanup code
07 测试 / E2E / 回归类
AI 写代码最容易制造的一种错觉,就是:看起来像写完了。
代码有了,结构也有了,函数、页面、接口好像都补上了。但真正的问题是:跑过没有?测过没有?改这一处,会不会把别的地方带崩?
这类 Skill 不是帮你多生成一点代码,而是帮你确认这次改动到底是不是真的能用。小项目里可以跟 playwright-interactive 配合着用,测试链路比较特殊的项目,再自己补一个回归验证 Skill。
搜索关键词: testing / regression / e2e / playwright test / test validation
08 长会话 / 终端持续执行类
有些任务,真不是跑一条命令就完了。
装依赖、构建项目、跑服务、看日志、盯调试输出,这些活最怕的不是慢,是中途断掉。跑到一半,会话没了、上下文断了、日志接不上了,前面那段时间基本就白费。
这类 Skill 适合处理那些要持续盯、持续跑、持续接着做的任务。看着不花哨,但真干活的时候很有用。
搜索关键词: tmux / long session / persistent terminal / watch logs / background workflow
09 Git / CI / PR / Release 类
真实开发不只发生在本地。
写完代码之后还有一串必须处理的事:CI 挂了、PR 评论来了、review 要改、changelog 要补、release notes 要写。这些事没人爱做,但又都躲不掉。
这类 Skill 的意义不是让 Codex 帮你多写几段代码,而是让它顺手把交付这段也接过去。
代表 Skill:gh-fix-ci + gh-address-comments
10 Skill 工厂 / 扩展类
把 Codex 用久了,一定会走到这一步:不再只是装别人做好的 Skill,开始把自己的工作方式也做成 Skill。
别人的 Skill 不一定 100% 适合自己,这很正常。你安装的那些 Skill,其实一开始都是先满足了作者自己,之后才分享出来的。能自己写 Skill,才算真正把这套工具用透了。
代表 Skill:skill-creator + find-skills
装之前,先想清楚自己需要什么
最后一点建议:别一上来就追求装很多。
无脑安装多了,一是会触发混乱——多个 Skill 都觉得自己适合当前任务;二是会污染上下文——Skill 会把一部分规则塞进 Agent 的工作上下文里,Skill 太多,Codex 就会看到更多"可能相关"的说明,反而容易出问题。
如果你刚开始配,建议按这个顺序来:
第一梯队:浏览器执行 / 交互验证、仓库阅读 / 文档抽取、Research / Web Search
第二梯队:任务拆解 / 计划、测试 / E2E / 回归、代码审查 / 重构 / 最佳实践
第三梯队:截图 / 视觉验收、长会话 / 终端持续执行、Git / CI / PR / Release、Skill 工厂 / 扩展
先装那些装上之后平时真的会用到的,跑顺了再往下扩。Codex 能帮你干多少活,很大程度上取决于你有没有把该搭的工作流搭起来。