周一早上我打开 Codex，看着 Skills 那一栏是空的，不知道该装什么。

网上随便搜一下，出来一堆必装 10 个的清单，里面什么 GitHub、Figma、Presentations 都有，每个博主列的不一样，看着都挺合理。但真按着一个个装下来，会发现两件事：第一，有些 Skill 装了一两个月也没用过；第二，真到用的时候，才发现某个经常重复做的事，没有对应的 Skill。

问题不是清单不对，是清单没解决我下个月要做什么。

我后来给自己定了一条规矩：装 Skill 之前，先回答两个问题。第一个，这个月我最常做的 3 件事是什么。第二个，这 3 件事里，有哪一件是因为重复才慢的。

回答完，再去装。装得少，但每个都用得上。

按这个思路，我把自己装的第一批 Skill 压到了 8 个，分三层。

第一层，基础包，先装这 3 个，能覆盖 80% 的日常。

filesystem，读写本地文件是所有任务的地基。Codex 要改一段代码、存一份文档、从 log 里抽关键行，全靠它。没装这个，Codex 只是个会说话不会动手的助手；装上，Codex 才能真的执行。

git，开发类任务离不开版本管理。提交、回滚、查 diff、看分支历史，没有 git 帮忙每次都得自己敲一长串命令。装上之后，跟它说一句帮我看看这次改了啥，或者把上一次提交回滚掉，它就能直接跑。

web fetching，查资料、抓数据、看 API 文档，全靠它。学一个新东西时让 Codex 自己去官网把文档抓回来，比手动复制粘贴快得多。装这一个，能省掉一半手动喂资料的活。

这三个装齐，Codex 就能从只动嘴不动手，变成真能干活。

第二层，提效包，一个月后再装，让一次任务变成可复用的流程。

plan mode，复杂任务先规划再动手。比如让 Codex 做一个自动抓豆瓣电影 Top 250 并入库的小脚本，没规划的话它可能边写边想，跑偏了还得拉回来。开了 plan mode，Codex 会先把步骤列出来跟我确认，再动手。多花两分钟，换来的是少返工三小时。

subagent 或者 task，把一个复杂任务拆成几个子任务并行。比如前端改 UI 加后端改接口加写测试文档同时进行，三个 subagent 同时跑，总时间不是相加而是取最长那个。前提是子任务之间没有强依赖。

worktree，把当前代码克隆一份到隔离分支再动手。改坏了不影响主分支，改完了再合并回去。装这个之后让 Codex 大胆试才真的安全。

这一层不是必须，但装上之后你会明显感觉到，同一类任务，第二次做比第一次快。

第三层，业务包，按你的工种挑，一个就够。

做后端就装 database 或 HTTP requests，做运维就装 shell 加 docker，做内容就装 markdown 转 PDF 或图像生成。

这一层没有标准答案。看你是写代码、做运营、还是搞内容，挑对应那个用得上的装。装多了反而互相干扰，每次 Codex 启动都得猜你这次要用哪个。

8 个装完之后，我不会继续加。

新加一条 Skill 的门槛是上个月我手动做了至少 3 次这件事。达不到，说明这事还不够日常，装上来 Codex 也不会优先用它，反而把启动列表拖慢。

所以你看，不是装得多就用得好。是装得准，每次用得上，Codex 才会越用越顺。