上个月我干了一件在不少人看来有点自找麻烦的事把自己攒了快一年的 Codex 配置翻出来然后逐个记录每个 Skill 到底有没有在真实开发里被调用过。一个月之后结论相当尴尬——31 个 Skill 里16 个一次都没被真正调用8 个只点开过一两次稳定在用的只有 7 个。这篇东西就是我一个月 Codex 开发记录的完整复盘聊聊怎么判断一个 Skill 值不值得留、清理之后 Codex 的上下文利用率发生了什么变化以及那些“装上就等于会了”的错觉是怎么毁掉开发效率的。无论你是在折腾 Codex CLI还是刚刚开始接触 Skill 机制这篇文章都能帮你少囤一堆没用的模板。1. 从收藏到清理我为什么会囤下 31 个 Skill1.1 Codex 和 Skill 到底是什么关系先把基础对齐一下。Codex 是一个跑在终端里的编程智能体你给我一个任务它自己分析代码、调用工具、改文件、跑命令最后把结果交回来。它和普通聊天工具最大的区别是能直接动你的工程目录所以很多人把它当成真正的“结对程序员”。Skill 在这个体系里是什么我的理解是它是给 Codex 预写好的一套“工作模板”。每个 Skill 通常由名字、触发描述、指令正文和示例组成。 Codex 收到任务后会先扫一遍配置里挂载的 Skill看到描述匹配的就把对应的指令注入到上下文里让模型按特定的规则干活。你可以把 Skill 理解成手机里的快捷短语或者老法师文件夹里的方案模板——它不是模型的一部分而是帮你把最常见的任务套路固化成可复用的上下文。最初接触 Skill 这个概念时我特别兴奋。因为我在日常开发里有很多重复劳动写单元测试、调 SQL、整理 CSV、做代码 review。如果每个场景都有现成的 Skill那 Codex 就能少走很多弯路。1.2 囤 Skill 的典型路径从“以后可能用得上”开始但事实是我的 Skill 列表并不是按“开发高频需求”去积累的而是按“收藏夹心理”去膨胀的。我复盘了一下囤 Skill 的路径基本有三条第一条刷社区分享帖。看到一个帖子说“数学建模 Skill 特别好用Codex 直接给你出完整模型”我就立刻装上了。虽然我半年没做过一次数学建模但脑子里自动补了一句“以后肯定用得上”。第二条被酷炫描述吸引。像仓颉 Skill、nature Skill、ponytail Skill、workbuddy Skill 这类特别有辨识度的名字基本是看到就存。第三条遇到某个小任务时顺手装。比如有次我需要把一段拼音转成汉字觉得以后还会用就装了一个仓颉 Skill。结果那次任务是手动用在线工具解决的装完之后再也没碰过。一个月前清点的时候配置目录里已经有 31 个 Skill。更夸张的是有些 Skill 我连它们具体管什么都不太记得了只记得“当时好像很有用”。1.3 囤 Skill 的隐性成本不是磁盘是上下文囤 Skill 最坑的地方不是占硬盘而是每次都会偷偷占用 Codex 的注意力。我后来仔细看运行日志才发现Codex 在启动会话时会对所有挂载的 Skill 做一次扫描把描述和部分指令读进上下文。当配置目录里堆了三十几个 Skill且它们的描述写得又长又含糊时会发生三件让人头疼的事第一真正有用的 Skill 会被淹没。模型面对一大堆可选模板经常分不清该触发哪个甚至干脆一个都不触发直接自由发挥。第二无关指令会干扰判断。比如有一个“全球化写作”Skill 描述里写了一大堆“适用于任何写作任务”结果我让它改两行注释时它都自动带入那套冗长的写作风格。第三上下文窗口被无意义的模板占满。Codex 的上下文就这么大模板占掉一段真正分析代码的空间就少一段。尤其在做大工程重构时本来模型就经常抱怨上下文不够结果空白浪费在了一堆从没被用过的 Skill 上。所以囤 Skill 的真问题不是“多占了几 MB 磁盘”而是“每次会话都在为一个不存在的需求付上下文租金”。2. 一个月的真实使用记录什么 Skill 被反复调用2.1 这一个月的 Codex 开发任务长什么样为了搞清楚哪些 Skill 值得留我给自己定了一条规矩这一个月里把所有通过 Codex 完成的任务都记在日志里包括任务类型、用的 Skill、触发结果、修改了哪些文件、最终是否验收通过。不自我感动不凭印象只看记录。我一个月内的主要任务大概有这些写 Python 爬虫抓取公开网页数据清洗一份约 3 万行的 CSV修正格式和字段映射给现有 Flask 项目补单元测试对几个核心函数做重构写 SQL 查询和报表解析非标准格式的日志文件把 Markdown 文档批量转成结构化 JSON顺手做几轮代码审查。这些任务有一个共同点重复度高、动作标准、输出格式固定。按道理说非常应该触发 Skill。可实际统计结果让我相当意外。2.2 31 个 Skill 的使用统计表我把配置里的 31 个 Skill 逐个拉出来统计一个月内的调用次数结果大概是这样的Skill 名称使用次数结论单元测试生成23保留SQL 生成与优化18保留代码审查15保留CSV 数据清洗11保留日志分析9保留依赖升级检查5保留技术文档转 JSON3保留数学建模0删除仓颉文字转换0删除nature 论文风格0删除ponytail 风格0删除workbuddy 任务管理0删除grill 烧烤指南0删除通用代码转换1合并通用文档写作2合并极简代码审查2合并完整 31 个就不一一贴了但趋势已经很清楚真正高频率触发的 Skill 只有五六个剩下的大多数要么零调用要么只在某个特定时刻被我手动“点名”过。这里要解释一下表格里的“使用次数”我并不是靠肉眼数的而是在会话日志里搜每个 Skill 文件的标记名统计它被注入上下文的次数。Codex 运行时会记录当前会话挂载了哪些 Skill这些信息都会留在日志目录里写个小脚本扫一遍就能统计出来。2.3 为什么它们没被用从触发率倒推原因把 31 个 Skill 按“触发率”排个队再逐个阅读它们的描述我发现一个很有意思的规律真正被反复调用的 Skill描述里都有“任务边界清晰、输出格式固定、校验标准明确”这三个特征。比如单元测试生成 Skill描述里明确写了“当用户要求为某个函数或模块创建单元测试时必须使用本 Skill”执行规则里还规定了使用 pytest、mock 外部依赖、输出带断言。模型每次看到相关任务都能毫不费力地判断“该触发它”。反过来一次没被触发的 Skill问题大多出在三个地方第一描述过于宏大。比如某个“专业写作Skill”描述是“帮助用户写出高质量、有深度、具有国际视野的文本”这几乎适用于所有写作任务于是模型反而不知道该不该用它。第二场景从来没有出现。像“数学建模”“仓颉转换”“grill 烧烤指南”听起来很酷但我的真实开发流程里根本没这种需求。第三和普通提示词没有本质区别。去掉 Skill 外壳后里面的指令跟我在对话里直接打一大段提示词差不多模型用不用它都一样等于没起到“模板复用”的作用。说白了我不需要的不是这 31 个 Skill而是“装在列表里假装自己很有生产力”的那 24 个。3. 清理 31 个 Skill 的实操3 步确定去留3.1 先建立一个评估打分表清理不是拍脑袋删文件而是先定一套可量化的标准。我花了一个下午把 31 个 Skill 全部过了一遍评估维度定了五个使用频率过去一个月的调用次数0 次记 0 分1-5 次记 3 分6 次以上记 8 分。不可替代性这套规则是否能用一段普通提示词替代完全能手写替代的记低分。上下文成本描述和指令总共占多少字符越长越低分因为每次会话都可能被白读。维护状态是否跟上 Skill 作者的新版本半年以上没更新的记低分。合并潜力能否和其他 Skill 合成一个更大的“工作台”明显重叠的记低分。每个维度权重不一样我按自己的开发习惯给使用频率和不可替代性各加了权重。总分低于 30 的直接进“删除候选区”30 到 60 的进“合并评估区”高于 60 的才进“保留区”。整套评估真的不需要多聪明关键是逼自己面对两个尴尬事实第一使用频率低于 3 次的 Skill未来两个月大概率还是不会用第二好几个 Skill 之间功能重叠度超过 50%分开放在配置文件里纯粹是在给模型出选择题。3.2 按评分处理保留 7 个、合并 8 个、删除 16 个按评分结果做了三轮动作最终处理结果如下保留的是 7 个。单元测试生成、SQL 生成优化、代码审查、CSV 数据清洗、日志分析、依赖升级检查、技术文档转 JSON。它们都满足同一个条件只要我提到对应任务Codex 会在三次响应内自动触发并且输出格式基本不用改就能用。合并的是 8 个。我把几个写作类 Skill——比如“nature 论文风格”“通用技术文档”“极简代码审查笔记”——合并成了一个“技术文档撰写与格式化”Skill。又把几个数据处理类 Skill 统一合并进“数据清洗与字段映射”里。现在的 SKILL.md 只保留每个子场景的触发关键词和输出规范目的是减轻上下文负担同时保证模型仍然知道“写文档时该用什么语气、切什么结构”。删除的是 16 个。数学建模、仓颉文字转换、grill 烧烤指南、ponytail 风格、workbuddy 任务管理这些都属于“未来可能用得上”型。删除之前我特意确认了一下它们的描述和指令内容没有一个是缺失关键逻辑、无法被普通提示词补上来的。所以删掉它们丢掉的是想象空间不是能力。清理动作本身很直接把对应 Skill 目录从配置文件夹里移除再更新配置文件里的挂载列表。对于保留的 Skill我顺手改了几处描述把“可选的”“你可以”这类模糊措辞全部改成“必须”“禁止”“输出应包含”这些确定性表达。之后重建索引、重启 Codex整个过程不到十分钟。3.3 清理之后 Codex 的表现变化配置瘦身和上下文解放清理完成后的第二天我重新启动了 Codex明显感觉到状态不一样。最直接的变化是配置目录从原来的 600 多 KB 缩到了 90 KB 左右但这个不是重点。重点是 Codex 在启动时读取的 Skill 描述总量少了很多上下文里留给真实任务的空间变大了。我用同样的任务做了一组对比测试给重构前和重构后的配置分别扔同一个重构任务观察模型在第一次回复里是否直接命中关键改动点。清理前它要先从一堆模板描述里“猜”我到底想用哪个 Skill经常先输出一段泛泛而谈的思路再切入代码清理后它基本一次就定位到我想要的改动明显少走弯路。还有一个我自己没预料到的改善模型误触发别的 Skill 的频率大幅下降。之前有个“通用写作”Skill 因为描述足够泛几乎什么任务都会挨上边导致我在写代码时它也自动套用那套冗长的风格。现在这类干扰项都被删了Codex 的输出干净了不少。我给这次清理做的小脚本其实也就二十几行用来统计 Skill 目录下的文件使用频率。思路很简单从 Codex 的会话日志里搜每个 Skill 的标记名把命中次数汇总成表再和配置文件里的 Skill 列表做一次差集就能快速定位“零触发”的候选者。你完全可以复现这个套路不用写太复杂的代码。4. 实操中的常见报错与避坑笔记4.1 Skill 不生效的三类原因清理完不等于万事大吉。这一个月里我反复排查问题发现 Skill 不生效的原因基本可以归成三类。第一类是描述太泛模型根本不触发。我之前有好几个 Skill 就死在这一条上。描述的写法直接决定模型是否会用单纯写“这个 Skill 可以帮你写高质量 SQL”等于没说正确写法是“当用户请求生成 SQL、优化 SQL 或解释 SQL 执行计划时必须使用本 Skill”。你必须把触发条件限定到具体动词和场景模型才敢在那种场景下明确调用。第二类是指令顺序错误规则被后续对话覆盖。Skill 的指令部分有时会很长如果没有把“强制规则”放在最后或者没有用“必须”“禁止”这种强约束词模型在后面的自由发挥里很容易把规则理解成“仅供参考”。我后来把所有硬性校验规则全部挪到指令尾部效果立竿见影。第三类是依赖缺失。有些 Skill 引用了我本机根本没装的脚本工具或包比如某个文档转换 Skill 依赖 pandoc但我的机器上压根没有。Codex 执行的时候规则还是照着 Skill 走结果自然出错。排查这类问题直接看报错日志里有没有“command not found”就能定位。4.2 Codex 使用中常见的三个报错除了 Skill 本身Codex 运行时还有几个高频问题值得说一下。第一个是模型兼容性报错。有一次我启动了 Codex 之后终端直接提示类似“the x model is not supported when using Codex with a custom endpoint”的信息。这个大多数时候是配置文件里定义的模型和 Codex 内置支持的列表对不上。解决办法就是把配置里的模型名改成 Codex 支持的那几个稳定版再重试。不用慌这不是防火墙问题也不是环境坏了就是名字对不上。第二个是上下文溢出。Codex 干到一半突然报“Codex ran out of room in the model’s context”。发生一次你就能明白为什么刚才说 Skill 不要囤太多。上下文窗口是有限的挂载一堆模板、塞进大段历史信息后真代码反而放不进去了。处理办法是重新开一个干净会话把问题描述拆得更精确并且临时把不太相关的 Skill 从挂载列表里摘掉。有时候把注释、日志、报告这些非必要内容从历史里清掉也能救回来。第三个是“正在重新连接”之类的问题。长任务跑到一半Codex 偶尔会因为网络中断或服务端响应超时而卡住。我的经验是不要太依赖单次超长会话尽量把大任务拆成小步提交每一步都确保产出物落盘。真断了就从最近一次成功状态接着跑损失最小。4.3 维护 Skill 库的月度节奏经过这次清理我给自己定了一个简单的维护节奏防止未来再出现第二个“31 个 Skill 的坟场”。新增一个 Skill 之前必须先写一版“试用描述”放进一个独立的 trial 目录不在主配置里大面积挂载。Codex 发起会话时trial 目录里的 Skill 默认不参与扫描只有我需要用的时候手动指定。两周内被调用超过 3 次才有资格晋升为主配置。每周扫一眼会话日志看看主配置里哪个 Skill 一次都没触发过连续两周零触发就直接移到旧配置存档。毕竟平时开发里两周已经足够覆盖大多数任务类型了。每个月底做一次配置提交。我把整个 Skill 配置库放进 git 里管理新增、合并、删除都留下记录。这样即使删错了也能随时回滚。养成了这个习惯以后我再也不怕清理因为所有的变更都可以追溯。5. 最后再分享一个判断 Skill 价值的小技巧清理完这 31 个 Skill我最大的体会不是“少即是多”这种正确废话而是判断一个 Skill 值不值得留根本不看它作者的介绍有多诱人只看它在真实任务里的触发率和复用率。我现在给自己定了一条死规矩任何新 Skill 都必须先进试用区两周内被调用超过 3 次才允许进主配置。没有达到就删理由可以很简单——“我的工作流里不需要这个场景”。这听起来很冷酷但就是这样一条规则让我每天的开发效率反而变高了。因为 Codex 不会在一个任务里同时看见 10 个无关模板也不会在真正该干活的时候被一堆花哨描述分散注意力。Codex 需要的东西从来不是更多的 Skill而是那七八个真正与你日常工作咬合紧密的模板。清理掉 31 个无用 Skill 之后我的 Codex 反而更像一个可靠的结对程序员了。