最近我把 Codex 的技能货架从第一排翻到最后一排说实话这个过程比逛超市挑调料还费劲。货架上摆着几百个 skill 包从“去 AI 味”到“SOLIDWORKS 接入”再到“狗头军师”名字一个比一个会起但你真的装上跑几天就会发现大部分属于“占着内存不干活”的类型。翻完之后我真正留下来的其实一只手数得过来。这篇就聊聊我留下了哪几个以及为什么是它们。如果你正在用 Codex 写代码、做内容或跑自动化你应该已经感觉到了Codex 本身是一套不错的 CLI 和 Agent 底座但真正的战斗力很大程度来自你往它身上挂了多少合适的 skill。所谓 skill你可以理解成一份份按需调用、塞给模型的工作手册——平时不占上下文遇到对应任务才被取出来照着执行。这篇文章不是 skill 零基础科普也不是把官方文档翻译一遍而是我以一个“翻货架翻到头晕”的用户身份把这批技能按真实使用价值重新排了个序同时把选型标准、部署经验和踩坑记录一并放在里面。1. 翻完货架之后我留下来的标准只有这三条1.1 先把“skill 是什么”这件事说清楚在聊具体留下哪些技能之前得先把“skill 到底是什么”对齐一下。Codex 生态里的 skill本质上是一组文件——通常是一个目录目录里放着一个SKILL.md主文件再加上若干辅助资源。SKILL.md开头是元信息技能名称、用途描述、适用场景后面是正文详细指令、执行步骤、输出格式、示例。它和普通提示词最大的区别在于“按需加载”。模型在对话过程中会先看到每个技能的简短描述只有当手头任务和某个技能描述匹配时才会真正展开这个技能的内容。换句话说技能不是一股脑塞进上下文的而是像你工位边上的工作手册——平时躺在那里接到对应活儿才翻开。这个机制现在已经被很多平台抄过去了。除了 Codex 自己的技能生态openclaw 这类开源 Agent 方案在兼容 skill 目录规范豆包这类产品也在做自己的技能市场workbuddy、superpower 这类第三方合集站点我翻过质量参差不齐但它们的出现至少说明一件事把程序员的“函数封装”思路搬到提示词工程里已经是行业共识了。1.2 三条筛选铁律真痛点、有边界、能维护货架上的东西很多但我的筛选标准并不复杂只有三条——不符合的再好听也不要。第一条它必须解决真实痛点而不是把一段提示词换个名字。市面上大量“技能”其实就是把 Prompt 包装成一个文件夹效果跟你直接复制粘贴同样的话没有区别。我留下来的技能必须能改变工作流程本身原来要手动一步步做的现在一步到位原来要翻半天文档的技能里自带规范原来结果不可控的技能输出有固定模式可验证。第二条它必须有清晰的触发边界。判断依据是技能文件里的 description 写得是否克制。好的描述会写明当且仅当用户提到 X 时才可使用如果任务涉及 Y请回退到默认行为。很多技能被砍掉就是因为描述写得太宽泛什么任务都想接结果在正常对话里频繁被误触发反而干扰主线工作。第三条它必须可维护、可迭代。你要能看懂它、能修改它、能在改动后验证它。一个技能再强大如果三天后没人维护就跟没有一样。我后面会专门说维护习惯但选型的时候这条就要先想清楚——别收一个自己根本不敢动的黑盒。1.3 关于“skill 编码 193、247”这类编号的小提醒翻货架的时候你会看到网上有人提“skill 编码 193”“skill 编码 247”之类的说法。我的理解是这些编号大多来自社区技能索引仓库的顺序编号不同编号对应不同模板版本或适用模型。同一个系列技能不同编号之间的差异可能非常大——有的基于旧版 Agent 协议写的在新版 Codex 上根本不触发有的则是为某个特定模型调的换模型后就废。所以我的建议很直接下载任何技能之前先扫一眼它的 README 和说明文件重点看两件事——适配的 Codex 版本、适配的模型。如果这两个信息缺失再火也别装。技能不是越多越好装错了反而会给后面的排查添乱。2. 我先留了一批“知识类”技能书、论文、课程都能变成可检索资产2.1 book-to-skill不是把书塞进去而是给模型做“目录和索引”这批里我最先留下的是“book-to-skill”这类技能它解决的是把一本书变成可检索资产的问题。热门搜索词里能看到这个需求很大我自己的使用场景是把几本工具书和一个项目的内部规范文档做成技能让 Codex 在干活时能按需引用里面的方法。这类技能的核心思路就八个字内容压缩指针索引。很多人的误区是“把整本书塞进技能”结局基本都会被上下文窗口教做人。正确做法是把一本书结构化——目录、每章两三条核心结论、关键术语表、图表说明再加上指向原文具体位置的检索索引。模型被触发之后先按框架理解任务属于哪一章的范畴再通过索引去取所需的细节。这样既不会占着上下文又能保证关键知识不缺失。我自己实测下来一本两百页的工具书最终落成技能后可能只有不到一万字的骨架文件但效果远比硬塞全文要好。因为模型真正需要的往往不是原文而是“结构化的方法论准确的术语定义可追溯的来源”。2.2 论文与备课类技能文献综述和课程设计的长尾需求同属知识类的还有论文分析技能和备课技能这两个词条在搜索热度里也很靠前。论文技能解决的是让模型按固定 schema 提取一篇论文的研究动机、方法、数据集、消融实验、结论并自动生成横向对比表。做文献综述时以前要逐篇阅读然后手工整理现在直接把 PDF 丢给加载了论文技能的 Codex让它按统一格式输出你再做人工校对。备课技能则完全是另一类需求把课程目标、学员水平、课时长度拆解成指令让模型生成大纲、例题、变式练习。语言学习技能也差不多核心是“分难度曲线”——同一个知识点给初学者和进阶者产出的解释完全不同。这类技能共同的价值是把“反复出现的任务模板化”。论文分析、教学设计都是流程固定但有认知门槛的活儿技能包里沉淀了流程模型负责执行你负责把关这条分工线很舒服。2.3 实操一份 SKILL.md 骨架给你看一下我自己用的 book-to-skill 骨架规模控制好改动成本也低--- name: book_reader description: 当用户要求基于指定书籍做内容整理、问答、综述或方法提取时使用。 仅在任务明确关联该书内容时触发若用户只是泛泛提问请走默认对话。 --- # 任务目标 基于《书名》的内容完成用户要求的问题解答或内容整理。 # 执行步骤 1. 先从技能目录下 index.md 中定位问题对应章节。 2. 依据章节摘要判断是否够用不够时检索 rag_index/ 下的切片文件。 3. 输出答案时必须标注引用章节禁止编造原文不存在的观点。 # 输出格式 - 答案正文 - 引用章节编号 - 不确定点清单如原文存在歧义或缺失这里最需要注意的是 description 字段。它写得好不好直接决定模型会不会正确触发。写得太宽日常问题也被拉进来写得太窄需要的时候反而不触发。我建议你每次改 description 时都拿几个真实问题进行回归测试。3. 接着留的是垂直领域技能GIS 空间分析和 SOLIDWORKS 这种“冷门刚需”3.1 GIS 空间分析 skill把常用空间计算封成操作链路第二批让我真正觉得值得留下的是 GIS 空间分析 skill。搜索热词里这个需求很猛原因很实在——空间分析的坑太多了坐标系、投影、单位、拓扑关系每一步错一点结果就全偏。通用对话模型并不是不会写空间分析代码而是它经常“不知道你踩过哪些坑”。一个好的 GIS 技能会把常见空间计算的操作链路完整封装起来。比如缓冲区分析技能里会固定成先检查输入数据的坐标系CRS如果还是经纬度先转成投影坐标系再按目标单位算缓冲区最后把结果按原始坐标系输出。这个过程听起来简单但你不把它固化成技能模型每次生成的代码都可能漏掉其中一步。import geopandas as gpd gdf gpd.read_file(input.shp) if gdf.crs is None: gdf gdf.set_crs(EPSG:4326) gdf_metric gdf.to_crs(EPSG:3857) gdf_buffered gdf_metric.geometry.buffer(500) # 500米 gdf_result gpd.GeoDataFrame(geometrygdf_buffered, crsgdf_metric.crs) gdf_result.to_file(output.shp)这代码本身不复杂但“先检查 CRS再转投影米制坐标系才算 buffer”这个顺序是无数个错误结果换来的经验。没有技能的模型经常直接拿经纬度去算距离然后给你一个在每个纬度下都不同的诡异结果。技能的价值就是把这种“操作链完整性”固定下来。3.2 SOLIDWORKS 参数化 skillAPI 驱动的重复劳动终结者另一个让我留下的是 SOLIDWORKS 接入 skill。很多人会觉得奇怪一个写代码的 Agent 怎么会跟 CAD 软件扯上关系但搜索词里“solidworks接入skill”热度不低说明工业设计领域真有人拿 Codex 在干重复劳动。这类技能做的事情是通过 SOLIDWORKS 的 API 做参数化建模、批量属性修改、工程图导出。比如一个零件族几十个型号只是尺寸不同手工改要一个个打开模型调整参数用技能封装后则可以通过脚本批量生成。技能里会把“切除拉伸”“配合”“公差带”这类领域术语翻译成对应的 API 调用序列模型不需要“理解”机械设计它只需要正确执行映射关系。这类技能我留下来的理由很清晰通用模型擅长文本理解和代码生成但不擅长“领域专有名词→具体工具 API”的映射。垂直技能本质上是在做这层翻译省掉的不只是时间还有大量试错成本。3.3 这类技能的价值在“领域语言压缩”和“操作链完整”把 GIS 和 SOLIDWORKS 放在一起说是因为它们有一个共同点通用对话覆盖不了但需求又足够刚性。它们做的事情可以总结成两个词——领域语言压缩操作链完整。模型的知识面再广也不可能把所有垂直领域的 API 细节都记住。技能包把最常用的操作、最常见的坑、最标准的输出格式压缩进一份可控的文件里模型用到时再展开。这不只是效率问题更是结果可靠性的问题。对我来说这类技能是“冷门刚需”你在普通社区看不到太多讨论但真正用上的人会一直用下去。4. 最后留下的这批是风格控制类去 AI 味、打斗动作、狗头军师4.1 去 AI 味技能的结构前置规则 输出后置检查风格控制类技能里最值得留下的就是“去 AI 味”技能。你可能觉得写提示词时加一句“写自然一点”不就行了实测下来这远远不够。自然是个模糊概念模型不知道你定义的“自然”到底长什么样。真正好用的去 AI 味技能结构是两层第一层是前置规则。把所有 AI 腔的高频词和句式拉进黑名单——“首先/其次/最后”“值得注意的是”“综上所述”“通过本文”这些直接禁止使用形容词数量限制、每段首句禁止做总结、禁止段落排比堆砌。第二层是后置检查。技能会要求模型在生成草稿后逐项统计这些黑名单词的出现频率检测总结段的密度超标就自动改写再返回结果。我给模型喂的规则列表非常刚性因为生成任务最怕模糊指令。“写得更自然一些”这种话模型没法执行但“删掉最后一段总结把每段首句改成具体动作描写”这种指令它执行得很好。4.2 打斗动作提示词技能给创作场景用的“分镜手册”搜索热词里的“打斗动作提示词 skill”看着小众实际上是创作类用户真金白银在搜的东西。写小说、写剧本、做视频脚本的人会发现让模型描写动作场面它最容易写出那种“两人身影交错拳风呼啸”的空洞句子。这个技能的核心是把“两个角色打架”这种一句话需求细化成可执行的镜头指令动作逻辑进攻、格挡、受身、空间位置两人距离、所处地形、节奏变化快攻、停顿、喘息、物理合理性重心、惯性、受伤后的动作变形、感官细节脚步声、呼吸、衣物摩擦声。模型加载技能后等于拿到了一套分镜手册它输出的动作描写就有了结构支撑而不是华丽的空转。这个技能的启示是创作类任务模型缺的往往不是词汇而是约束。你给它的框架越明确它产出的内容越有画面感。4.3 狗头军师这类脑洞技能的真正用法限制域越大输出越无聊“狗头军师 skill”我一开始是当段子收藏的用起来发现它其实有一套反常识的逻辑。它强制模型从一个特定角度回答——专门生产那些“不正经但可能有用”的歪招。这看起来是给模型放权实际上恰恰相反它给模型加了一个非常强的人设和回答域。这件事引出一个很重要的经验创意类任务不是给模型越大自由度就越好而是给它一个人设和一个限制域输出反而更有信息量。让模型“说点有创意的”它会给你平庸的正确废话让它“从狗头军师的角度先考虑成本和可行性再给三个反套路方案”它反而能给出你没想到的角度。所谓“条件越具体脑洞越有方向”就是这回事。打斗动作技能是空间限制狗头军师技能是人设限制去 AI 味技能是语言规则限制——风格控制类的本质都是用约束换质量。5. 真正折腾我的不是选技能而是部署和配置这些坑5.1 安装、登录、组织设置这一串破事说完了留下来哪些也得说说那些差点让我放弃的时刻。技能装上之后最耗时间的其实不是选型而是部署和配置。先说安装登录。Codex 的安装包和 CLI 装起来本身不算难但很多人卡在登录和组织设置上。“组织设置加载不了”这个报错我遇到过搜索热词里也是高频问题。常见原因有两种一是登录态过期或者当前账号不在目标组织的成员列表里这时候需要重新登录并检查账号权限二是本地配置残留旧版本的配置文件格式跟新版本冲突最干净的办法是先把旧配置备份后清掉再重新登录。Windows 桌面版安装中途未完成的情况我也遇到过多数是系统权限和 PATH 问题重装前清掉 AppData 下的配置缓存比反复点击安装程序有用得多。5.2 接第三方模型时的模型名不匹配gpt-5.6-sol 报错“codex 接入 deepseek”是现在很热的玩法原理是 Codex 本身只是个客户端让你自定义模型服务端点。但很多人配置完以后会遇到类似“the gpt-5.6-sol model is not supported when using codex with a ...”的报错。这个报错的原因非常简单你配置里的模型名在你指向的服务端点上并不存在。比如你想接 DeepSeek但配置里还留着 Codex 官方默认的模型名第三方端点根本不认识它。排查手法先确认你配置的模型名对应该服务商提供的名称再确认端点路径是否正确。一个典型的兼容接入配置长这样model deepseek-chat base_url https://api.yourprovider.com/v1 api_key sk-xxxx不同的兼容层字段名可能有差异但核心就三项模型名、端点地址、鉴权方式。这三项对齐了90% 的报错都能解决。这条经验同样适用于其他任何第三方端点——报错信息里出现模型名不支持先别怀疑网络先看名字对不对。5.3 本地请求转发失败的排查思路另一个让人头疼的报错是切换配置工具时出现的“cc switch local proxy failed while handling codex endpoint /responses”这类信息。我第一次看到这行字时也懵了第一反应是去翻网络配置其实走了弯路。这类报错的本意是你用了某个配置切换工具它把请求转发到 Codex 的/responses端点时本地请求转发层没能成功处理这次调用。排查思路按顺序来效率最高第一步确认切换后的端点 URL 是否真的被改到了新地址。很多切换工具会在切换后保留旧配置。第二步确认鉴权 token 是否同步更换新旧配置混用是常见事故。第三步确认有没有残留进程占用端口。旧进程不退出新请求会被转发到一个已经死掉的服务上。第四步直接绕过工具手动调一次接口验证curl http://127.0.0.1:8000/v1/responses \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ -d {model:deepseek-chat,input:ping}如果 curl 直接能通说明问题出在切换工具的配置同步上如果 curl 也不通问题才真正出在本地请求转发层本身。5.4 内网部署deepseek harness 附带的 skill 怎么搬最后一个部署场景是有人问到的“deepseek harness 附带的 skill 怎么部署到内网服务器”。我自己帮团队搬过一套流程不复杂但有一个关键点很容易忽略。整体思路是模型服务本身要在内网能访问到技能目录、索引文件、向量库这些资源要随模型一起拷贝到内网Codex 的配置要指向内网端点而不是默认的公网地址。具体步骤大致是——先把模型服务在内网机器上跑起来通过兼容端点暴露再把 skill 目录放到约定路径确认SKILL.md里的资源引用路径全部改成内网可访问的相对路径或内网地址最后写一份内网专用的 Codex 配置文件指定base_url指向内网服务器。这里最容易被忽略的就是搬迁 skill 时不只是拷贝目录那么简单。技能里可能写了外网 URL、外部 API 接口、需要联网拉取的数据集这些依赖不断掉技能到内网就是坏的。我那次踩的坑就是索引文件里残留了一条外部路径导致内网环境里模型始终无法加载索引。排查了大半天才发现是路径指向问题。6. 我的货架维护习惯定期清理、给技能写 changelog、用测试集验货6.1 给每个 skill 建立最小测试集技能选完了坑也踩完了最后发现真正区别“随手能用”和“越用越乱”的是维护习惯。我给每个留下的技能都配了一个最小测试集——每个技能至少三个固定测试问题。比如知识类技能测试就是“概括第三章内容”“对比 2.1 和 2.2 的限制条件”“提取全文中所有指标定义”GIS 技能测试就是“对这个数据集做 500 米缓冲区”“算两个图层相交面积”“把结果转成经纬度输出”。改技能之前先跑一遍测试集改完再跑一遍输出差异一目了然。这个方法不高级但它能把“调技能靠玄学”变成可控的对比过程。很多技能是被改坏的不是用坏的——今天加一条规则明天改一句描述没有测试集兜底你根本不知道哪次改动作出了偏差。6.2 版本管理三件套命名、changelog、示例文件维护技能的第二个习惯是版本管理我用的三件套是命名规范、changelog、示例文件。命名规范建议带领域和动作前缀比如gis-buffer-analysis而不是gis1因为技能多了以后名字就是检索入口。changelog 记录每次改动尤其是 description 字段和触发条件的变化——这两个地方最容易被改坏但恰恰又最容易被顺手调一下就不管了。示例文件的质量比数量重要。我在每个技能目录里都放了三五个“标准输入-标准输出”示例这些示例的作用是给模型做锚定——它能从示例里学到你想要的具体风格效果比指令里写一堆“请注意质量”好得多。6.3 最后分享一个我自己的小习惯技能包也要“去库存”回到开头说的“翻货架”。翻完货架的人最容易犯的毛病是收藏了一堆“也许以后用得上”的技能。我的习惯是每两周清一次库存按触发次数把技能排个序超过一个月没触发、又看不出未来潜力的直接归档。理由很简单——技能货架不是收藏夹是生产工具。货架上的东西越多模型每次做技能匹配时的干扰就越大维护成本也越高。我留下的这几个每一个都在过去一个月里被真实触发过至少三次这比任何评测数据都实在。翻货架很容易真正难的是知道什么该留、什么该清以及留下来了之后好好养护。