1. 三个满分Skill到底强在哪先看清它们的定位Codex的Skill机制上线也有一段时间了社区里各种Skill仓库满天飞但真正能称得上“满分”的其实就那么几个。我前前后后装了删、删了装折腾了差不多两个月最后稳定留在配置里的只有三个Skill Creator、Any Search、Superpowers。这三个不是那种装完就吃灰的花架子而是各自解决了一类非常具体的痛点。先说结论性的定位。Skill Creator解决的是“我想让Codex干一件它现在不会干的事”这个问题它是一个元Skill用来造Skill的Skill。Any Search解决的是“Codex不知道最新信息”这个问题它把实时检索能力接进了工作流。Superpowers解决的是“Codex干活不够狠、不够系统”这个问题它给Codex注入了一套结构化的执行框架。三个Skill分别对应能力扩展、信息获取、执行深度三个维度组合起来基本覆盖了日常开发中80%以上的场景。很多人第一次接触Skill会把它和Agent搞混。简单说Agent是一个能自主决策的实体Skill更像是给这个实体装备的工具包。你可以把Codex想象成一个手艺很好的工匠Skill就是他工具箱里的各种工具。没有工具他也能干活但有了趁手的工具效率和成品质量完全是两个档次。这三个Skill之所以被称为“满分”核心原因就是它们的通用性极强——不管你用Codex写代码、写文档、做数据分析还是搞自动化它们都能直接派上用场不需要你为了某个特定场景去重新配置。我见过太多人装了一堆Skill结果每个都只用了一次。问题出在选型上——他们选的是“看起来厉害”的Skill而不是“每天都会用到”的Skill。这三个不一样Skill Creator你每次想扩展新能力时都会用Any Search你每次需要查资料时都会用Superpowers你每次让它执行复杂任务时都会用。高频、通用、可组合这才是满分Skill的标准。接下来的内容我会把这三个Skill逐个拆开从安装配置到实际使用从核心原理到踩坑经验全部讲透。不管你是刚接触Codex的新手还是已经用了一段时间想优化工作流的老手应该都能从里面找到能直接抄作业的东西。2. Skill Creator用一个Skill造出无数个Skill2.1 它到底解决了什么问题Skill Creator的核心价值用一句话说就是把“写Skill”这件事本身变成了一个Skill。在没有它之前你想给Codex加一个新能力得自己去翻文档、理解Skill的文件结构、手写配置文件、调试参数整个过程少说半小时多则一两个小时。有了Skill Creator之后你只需要用自然语言描述你想要什么能力它就能帮你生成一个结构完整、可以直接用的Skill。我举个实际例子。之前我需要一个能自动把Markdown表格转成CSV的Skill按照传统方式我得去查Skill的manifest格式、定义输入输出schema、写prompt模板。用了Skill Creator之后我就说了一句“帮我创建一个Skill功能是读取Markdown文件中的表格并输出CSV格式”它直接给我生成了完整的Skill目录结构包括manifest文件、prompt定义、示例输入输出我检查了一遍基本没改就直接用了。整个过程不到三分钟。这个Skill特别适合两类人一类是经常需要定制化能力的开发者另一类是想入门Skill开发但不知道从哪下手的新手。对于前者它能把重复劳动压缩到极致对于后者它生成的Skill就是最好的学习模板你可以直接看到一个标准Skill应该长什么样。2.2 安装与配置要点Skill Creator的安装方式取决于你用的是哪种Codex客户端。目前主流的有三种途径官方CLI、桌面版、以及通过第三方客户端接入。不同途径的安装方式略有差异但核心逻辑是一样的——把Skill Creator的仓库克隆到你的Skill目录下然后在配置文件中注册。以CLI版本为例典型的操作流程是这样的# 进入你的Codex Skill目录 cd ~/.codex/skills # 克隆Skill Creator仓库 git clone https://github.com/xxx/skill-creator.git # 进入目录安装依赖 cd skill-creator npm install # 回到Codex配置目录注册这个Skill cd ~/.codex # 编辑config文件在skills字段中添加skill-creator的路径桌面版的安装更简单通常在设置界面里有一个“导入Skill”的按钮选择你下载好的Skill Creator文件夹就行。但这里有个坑要注意桌面版对Skill的目录结构要求更严格如果你的文件夹里有多余的文件比如.git目录、node_modules等可能会导致导入失败。建议导入前先清理一下。配置方面Skill Creator本身不需要太多参数但有一个设置我强烈建议你打开——自动验证生成的Skill。这个选项会让Skill Creator在生成Skill之后自动跑一遍基础校验检查manifest格式是否正确、必填字段是否齐全、prompt模板是否有语法错误。虽然会多花几秒钟但能帮你省掉大量调试时间。注意Skill Creator生成的Skill默认放在临时目录你需要手动把它移动到正式的Skill目录并注册。别问我怎么知道的我第一次用的时候找了半天生成的Skill去哪了。2.3 实际使用从描述到可用的完整流程用Skill Creator创建一个新Skill完整流程分为四步描述需求、生成骨架、审查调整、注册启用。第一步描述需求是最关键的。很多人在这里就写一句“帮我做一个处理Excel的Skill”然后抱怨生成的结果不好用。问题在于你的描述太模糊了。好的描述应该包含这几个要素输入是什么格式、输出是什么格式、核心逻辑是什么、有没有特殊要求。比如你可以这样写“创建一个Skill输入是一个包含多sheet的Excel文件路径输出是每个sheet的列名和行数统计要求支持.xlsx和.xls两种格式统计结果以Markdown表格形式返回。”第二步生成骨架通常只需要几秒钟。Skill Creator会输出一个完整的目录结构一般长这样my-skill/ ├── manifest.json # Skill的元信息定义 ├── prompt.md # 核心prompt模板 ├── examples/ # 示例输入输出 │ ├── input1.md │ └── output1.md └── README.md # 使用说明第三步审查调整是很多人会跳过的一步但我建议你至少检查三个地方manifest里的触发条件是否准确这决定了Codex什么时候会调用这个Skill、prompt模板里的变量占位符是否正确、examples里的示例是否覆盖了边界情况。我遇到过生成的Skill触发条件写得太宽泛导致Codex在任何任务中都试图调用它反而拖慢了响应速度。第四步注册启用就很简单了把Skill目录移到正式位置在配置里加一行路径重启Codex就生效了。2.4 踩坑经验与优化技巧用Skill Creator这段时间我踩过的坑主要集中在三个方面。第一个坑是生成的prompt过于冗长。Skill Creator为了保证通用性默认生成的prompt模板会包含大量说明性文字有时候一个简单的功能能写出上千字的prompt。这会导致两个问题一是消耗更多token二是可能让Codex“过度思考”。我的做法是生成之后手动精简一遍把那些“你是一个专业的XX助手”之类的套话删掉只保留核心逻辑和输入输出定义。第二个坑是示例不够典型。默认生成的examples往往是最理想情况下的输入输出但实际使用中你会遇到各种奇怪的数据。建议你在examples里至少加一个“脏数据”的示例比如空文件、格式错误的输入、超大数据量等这样Codex在实际调用时容错率会高很多。第三个坑是版本管理混乱。当你用Skill Creator生成了十几个Skill之后你会发现很难追踪每个Skill的版本和修改记录。我的建议是养成习惯每次修改Skill之后在manifest里更新version字段并且在README里简单记一笔改了什么。这个习惯在Skill数量超过五个之后会救你的命。另外分享一个提效技巧把你常用的Skill描述保存成模板。比如你经常需要创建“格式转换类”的Skill那就把这类需求的描述结构固定下来下次直接套模板改几个关键词就行比每次从头想要快得多。3. Any Search让Codex拥有实时信息获取能力3.1 核心原理与能力边界Any Search这个Skill解决的是一个非常根本的问题Codex的知识是有截止日期的。不管你用的是哪个版本它的训练数据都停留在某个时间点之后发生的事情它一概不知。在没有搜索能力的情况下你问它一个最新发布的库怎么用它要么编一个看起来很像但实际不存在的API要么直接告诉你“我不知道”。Any Search的工作方式是在Codex和外部信息源之间搭了一座桥。当你提出一个需要实时信息的问题时它会自动触发搜索流程把检索到的内容整理后注入到Codex的上下文中然后Codex基于这些新鲜信息来回答你。整个过程对你来说是透明的你只需要正常提问就行。但这里要明确它的能力边界。Any Search不是万能的它擅长的是查找最新的文档和API用法、获取某个事件的当前状态、检索特定技术问题的社区讨论。它不擅长的是需要深度推理的复杂问题、需要访问付费墙后面内容的任务、以及需要登录才能查看的页面。理解这个边界很重要能帮你判断什么时候该用它、什么时候该换别的方法。我实测下来Any Search在技术文档检索方面的准确率相当高尤其是查找开源库的最新用法、排查报错信息、了解某个工具的配置方式这些场景基本上一查一个准。但在需要综合多个来源做判断的场景下它给出的结果就需要你自己再过滤一遍。3.2 配置细节与参数调优Any Search的配置比Skill Creator要复杂一些因为它涉及到外部服务的接入。核心配置项包括搜索源、结果数量、超时时间、缓存策略四个部分。搜索源方面Any Search默认支持多种检索后端你可以根据自己的网络环境和使用习惯来选择。配置文件中一般是这样写的{ search_provider: default, max_results: 5, timeout_ms: 8000, cache_enabled: true, cache_ttl_minutes: 30 }max_results这个参数值得说一下。默认值通常是5但我建议根据你的使用场景调整。如果你只是快速查一个API用法3条结果就够了多了反而干扰。如果你在做技术选型调研可以调到8到10条获取更全面的信息。但别调太高超过10条之后边际收益急剧下降而且会显著增加响应时间。timeout_ms的设置也有讲究。默认8000毫秒8秒在大多数情况下够用但如果你经常查询响应较慢的源可以适当调高到12000毫秒。不过要注意超时时间设得太长会导致Codex在搜索失败时卡很久才返回结果体验很差。我的建议是保持在8000到10000之间。cache_enabled强烈建议打开。Any Search的缓存机制是按查询内容做哈希的相同的查询在缓存有效期内会直接返回缓存结果速度极快。cache_ttl_minutes设为30分钟是个比较平衡的值——既能享受缓存带来的速度提升又不会因为缓存太旧导致信息过时。如果你查的是变化很快的内容比如某个服务的实时状态可以把TTL调短到5到10分钟。提示修改配置文件后一定要重启Codex才能生效。我见过有人改完配置直接测试然后说“怎么没变化”折腾半天才发现是没重启。3.3 实战场景什么时候该用它Any Search最典型的使用场景有这么几个我逐个说一下实际体验。场景一查最新库的用法。比如你想用一个上个月刚发布的前端框架Codex的训练数据里根本没有。这时候你直接问“XXX框架怎么创建一个组件”Any Search会自动去检索官方文档然后把最新的用法返回给你。我实测过几个新出的工具库准确率在90%以上偶尔会有版本混淆的情况但大方向没问题。场景二排查报错信息。你遇到一个奇怪的报错把错误信息贴给CodexAny Search会去搜索这个报错的相关讨论通常能找到Stack Overflow或者GitHub Issues里的解决方案。这个场景下它的表现非常稳定因为报错信息通常是唯一的检索精度很高。场景三了解某个工具的当前状态。比如你想知道某个开源项目现在是不是还在维护、最新版本是多少、有没有已知的重大bug。Any Search能帮你快速获取这些信息省得你自己去翻仓库。场景四技术选型调研。当你需要在几个方案之间做选择时Any Search可以帮你快速收集每个方案的优缺点、社区评价、使用案例。但要注意这个场景下它给出的信息需要你自己做交叉验证不能全信。有一个场景我不建议用Any Search需要深度推理的问题。比如“这两个架构方案哪个更适合我的业务场景”这种问题需要结合你的具体上下文做判断搜索只能提供素材不能替你做决策。这种时候应该把搜索到的信息作为输入让Codex基于你的实际情况来分析。3.4 常见问题与排查Any Search用久了难免遇到问题我整理了几个最常见的。问题一搜索返回空结果。这种情况通常是搜索源的问题。排查步骤是先确认你的网络能正常访问搜索源然后检查配置里的search_provider是否写对了最后看看是不是查询词太生僻导致没有匹配结果。如果都正常可以试着把查询词改得更通用一些。问题二结果相关性差。有时候搜出来的东西跟你的问题关系不大。这通常是因为Codex自动生成的搜索词不够精准。你可以在提问时明确给出关键词比如“搜索‘Python asyncio timeout handling’相关的内容”而不是笼统地问“Python异步怎么处理超时”。问题三响应速度慢。如果每次搜索都要等很久先检查cache_enabled是不是关了。如果缓存开着还是慢可能是搜索源本身响应慢可以尝试切换provider或者降低max_results。问题四搜索结果与问题不匹配。这种情况偶尔会发生原因是Codex在整合搜索结果时理解偏了。解决办法是在提问时把上下文说清楚别让Codex去猜你的意图。问题类型可能原因排查步骤解决方式返回空结果搜索源不可用/查询词太偏检查网络、provider配置、换查询词切换搜索源或调整查询词相关性差搜索词不精准检查Codex生成的搜索词手动指定关键词响应慢缓存关闭/结果数过多检查cache配置和max_results开启缓存、降低结果数结果不匹配上下文不清晰回顾提问方式补充上下文信息4. Superpowers给Codex装上系统化执行框架4.1 设计理念为什么需要“超能力”Superpowers这个名字听起来有点中二但它的设计理念其实非常务实。核心思路是Codex默认的执行方式太“随性”了。你给它一个复杂任务它可能会直接开始写代码写到一半发现方向不对再回头改来回折腾好几轮。Superpowers做的事情是在Codex执行任务之前先强制它走一遍结构化的思考流程——拆解任务、识别依赖、制定计划、逐步执行、自我检查。你可以把这理解为给Codex加了一套“工作方法论”。没有Superpowers的时候Codex像一个经验丰富但比较随意的老手拿到活就干干到哪算哪。有了Superpowers之后它更像一个训练有素的项目经理先想清楚再动手每一步都有明确的输入输出和验收标准。这个Skill特别适合复杂任务场景——比如重构一个模块、实现一个完整功能、搭建一个项目骨架。对于简单的单步任务Superpowers反而会增加不必要的开销。所以我的使用策略是简单任务不开复杂任务必开。4.2 安装部署与基础配置Superpowers的安装方式和其他Skill类似但它的配置项更多因为涉及到执行框架的各种参数。基础安装流程# 克隆仓库到Skill目录 cd ~/.codex/skills git clone https://github.com/xxx/superpowers.git # 安装依赖 cd superpowers npm install # 注册到Codex配置 # 在config文件中添加superpowers的路径配置方面Superpowers有几个关键参数需要根据你的使用习惯调整{ planning_depth: standard, max_iterations: 5, self_check_enabled: true, checkpoint_interval: 3, verbose_logging: false }planning_depth控制任务拆解的粒度有三个档位minimal、standard、deep。minimal适合中等复杂度的任务拆解比较粗略standard是默认值适合大多数场景deep会做非常细致的拆解适合大型任务但会消耗更多token和时间。我平时用standard居多只有在做大型重构时才会切到deep。max_iterations限制的是自我修正的最大轮数。Superpowers在执行过程中会自我检查如果发现结果不符合预期会尝试修正。默认5轮一般够用。如果你发现Codex经常在某个任务上反复修正超过5轮说明任务描述可能不够清晰应该回头检查你的输入。self_check_enabled建议保持开启。这是Superpowers的核心价值之一——每完成一个子任务就自动检查一遍确保没有跑偏。关掉它的话Superpowers就退化成了一个普通的任务拆解工具价值大打折扣。checkpoint_interval控制的是每隔几个子任务保存一次进度快照。默认3个意味着每完成3个子任务就会记录当前状态。如果后续步骤出了问题可以回滚到最近的检查点不用从头再来。这个功能在长任务中非常有用。4.3 执行流程拆解从任务到交付Superpowers的执行流程可以拆成五个阶段我结合一个实际案例来说明。假设你让它“给一个现有的Python项目添加完整的单元测试覆盖”。第一阶段是任务理解。Superpowers会先分析你的需求识别出关键信息项目语言是Python、目标是添加单元测试、要求是“完整覆盖”。然后它会提出一些澄清性问题比如“你用的是pytest还是unittest”、“有没有已有的测试文件”、“覆盖率目标是多少”。这个阶段很重要能避免后续返工。第二阶段是计划制定。基于理解的结果Superpowers会生成一个执行计划通常长这样扫描项目结构识别所有需要测试的模块分析每个模块的公开接口和核心逻辑为每个模块生成测试用例运行测试并检查覆盖率补充遗漏的边界情况测试输出最终测试报告每个步骤都有明确的输入和预期输出你可以在这个阶段审查计划觉得哪里不对可以调整。第三阶段是逐步执行。Superpowers按照计划一步步来每完成一步会输出结果并做自我检查。比如第一步扫描完项目结构后它会列出识别到的模块清单确认没有遗漏。第四阶段是自我修正。如果某一步的结果不符合预期比如生成的测试用例运行失败Superpowers会自动分析失败原因并尝试修正。修正过程也会记录在日志里方便你回溯。第五阶段是交付与总结。所有步骤完成后Superpowers会输出一份总结报告包括完成了什么、遇到了什么问题、最终结果如何。这份报告在复杂任务中特别有价值相当于一份完整的操作记录。4.4 进阶用法组合与自定义Superpowers真正强大的地方在于它可以和其他Skill组合使用。我常用的组合方式有两种。组合一Superpowers Any Search。当你需要Codex完成一个需要最新信息的复杂任务时这个组合特别好用。Superpowers负责拆解和执行Any Search负责在需要的时候获取实时信息。比如“用最新的XXX库实现一个YYY功能”Superpowers会先拆解任务然后在需要查库用法的时候自动触发Any Search。组合二Superpowers Skill Creator。当你需要创建一个复杂的Skill时可以让Superpowers来规划整个Skill的结构然后让Skill Creator来生成具体的文件。这个组合适合创建那种包含多个子功能、逻辑比较复杂的Skill。自定义方面Superpowers允许你定义自己的执行模板。比如你经常做某类任务比如数据清洗可以把这类任务的标准流程定义成一个模板下次直接调用模板省去每次重新规划的时间。模板的定义格式在官方文档里有详细说明核心就是定义好步骤序列和每步的输入输出规范。注意Superpowers的模板功能需要一定的学习成本建议先把基础用法用熟了再折腾模板。我一开始就是急着搞模板结果基础流程还没跑通浪费了不少时间。5. 三个Skill的协同与选型建议5.1 组合使用的实际效果单独用这三个Skill各有各的价值但真正让我觉得“回不去了”的是它们组合使用时的效果。我描述一个典型的工作流你就明白了。假设我接到一个需求“帮我用某个新出的前端框架搭一个带搜索功能的页面”。没有这三个Skill的时候我的操作是先手动去查框架文档然后自己规划页面结构再一步步让Codex写代码遇到问题再查再改。整个过程碎片化效率很低。有了这三个Skill之后流程变成了我直接把需求丢给CodexSuperpowers自动拆解任务并制定计划执行到需要查框架用法时Any Search自动检索最新文档如果发现某个功能需要自定义Skill比如特定的代码生成模板Skill Creator可以现场生成。我只需要在关键节点做审查和确认剩下的交给它们协同完成。实测下来这种组合方式在处理中等复杂度任务时效率提升大概在3到5倍。复杂任务的提升更明显因为Superpowers的结构化流程能避免大量返工。5.2 不同场景下的选型策略虽然这三个Skill都很强但并不是每个场景都需要全部开启。我根据自己的使用经验整理了一个选型参考场景类型推荐开启的Skill理由简单代码修改仅Any Search任务简单不需要结构化规划但可能需要查API新功能开发Superpowers Any Search需要规划执行步骤同时可能需要查最新文档创建自定义SkillSkill Creator SuperpowersSuperpowers规划结构Skill Creator生成文件技术调研仅Any Search主要是信息收集不需要执行框架大型重构三个全开需要规划、需要查资料、可能需要生成辅助Skill日常问答不需要简单问题直接问就行开Skill反而增加开销这个表不是死的你可以根据自己的实际情况调整。核心原则是Skill是为任务服务的不要为了用Skill而用Skill。我见过有人不管干什么都三个全开结果简单问题也要等半天完全没必要。5.3 性能与资源消耗的平衡三个Skill全开的情况下资源消耗是显而易见的。主要消耗在三个方面token消耗、响应时间、以及本地计算资源。Token消耗方面Superpowers的规划阶段会额外消耗不少tokenAny Search的检索结果注入也会增加上下文长度。我的经验是三个全开时token消耗大约是裸用的2到3倍。如果你用的是按量计费的方式这个成本需要考虑进去。响应时间方面Superpowers的规划阶段会增加几秒的延迟Any Search的检索通常需要2到5秒。如果你对响应速度要求很高建议只在真正需要的时候开启对应的Skill。本地计算资源方面这三个Skill本身不怎么吃CPU和内存但如果你同时跑多个Codex实例每个实例都加载了这三个Skill内存占用会明显上升。建议根据你的机器配置合理控制并发数。5.4 我个人的使用心得用了这么久我最大的体会是这三个Skill的价值不在于它们各自有多强而在于它们填补了Codex能力版图中最关键的几个缺口。Skill Creator填补了能力扩展的缺口Any Search填补了信息时效性的缺口Superpowers填补了执行深度的缺口。三个缺口补上之后Codex从一个“聪明的助手”变成了一个“能独立完成复杂任务的执行者”。另外一个心得是不要一次性全部配置好就不管了。这三个Skill都在持续更新新版本会修复bug、增加功能、优化性能。建议每隔一两周检查一下有没有更新及时升级。我有一次隔了一个月没更新升级之后发现Superpowers的执行效率提升了将近一倍后悔没早点升。最后分享一个小技巧给每个Skill建一个使用笔记。记录你在使用过程中遇到的问题、解决方案、以及一些好用的配置组合。这个习惯在Skill数量多了之后特别有用能帮你快速回忆起某个Skill的最佳实践不用每次都重新摸索。