提到 superpowers经常玩 AI 编程工具链的朋友应该不陌生。它本质上不是某一个具体的软件而是围绕命令行 AI 编程助手比如 Codex CLI做出来的一套“技能扩展体系”把你日常开发里那些重复、琐碎、容易出错的环节封装成一个个可复用的能力包。装好之后原本只会“一问一答”的助手突然就变成了一个能自己跑测试、查日志、读依赖树、改完代码顺手帮你过一遍编译的“副驾驶”。这篇东西我就从安装到实战、再到排坑把我自己折腾这套体系的过程完整写下来希望能给正在研究 superpowers 怎么用的朋友省点时间。先说清楚它能解决什么问题。默认状态下的 AI 编程助手能力边界往往比较窄它能读你贴给它的代码片段能泛泛地给建议但让它去理解整个项目结构、自己去执行构建命令、自己看测试报告基本做不到。superpowers 这类技能扩展就是把这些“做不到”变成“做得到”。它通过一套插件化的命令和技能包把终端操作、文件读写、构建工具链、甚至 Java 这类重型项目的专项能力逐一挂到对话助手下面。装上之后你不需要频繁地复制粘贴代码、切换窗口、手动跑命令多数常规操作在对话里就能完成。这篇分享适合谁看我觉得只要你的日常工作离不开命令行和代码调试都值得花半小时把整套配置思路过一遍。尤其是做 Java 后端、维护多模块工程的朋友这套东西能省下大量重复劳动。新手也不用怕我不会默认你已经懂那些底层机制每一步都会讲清楚“为什么这么做”。1. 先拆解 superpowers 到底在解决什么1.1 默认工具和“超能力版”的差距我第一次接触这个概念时第一反应是不就是给终端助手加几个插件吗能有多大区别真正用起来才发现区别不在单个功能而在工作流的完整度。默认情况下AI 编程助手和你之间是“碎片化协作”关系你提问它回答你想让它执行某个操作它多数时候只能给你命令然后你自己去终端里跑。遇到复杂任务比如“帮我修一下这个模块的单元测试失败问题”你得手动把报错信息复制给它再把相关代码贴给它它分析完给出修改建议你再改再跑测试再把新报错贴回去。一个来回少说几分钟多的时候十几个来回都不奇怪。而挂上 superpowers 这类技能扩展之后助手的能力模型发生了变化。它不再只是“读代码、写代码”的语言模型还拥有了“执行命令、读文件、分析项目结构、调用外部工具”的能力你可以直接对它说“跑一下 payment 模块的测试把失败的用例按模块分组整理给我”它自己能完成全部操作然后把结果筛好给你。说白了从“咨询顾问”变成了“能干活的实习生”。1.2 为什么这种扩展能流行起来往深了说这其实折射出 AI 工具从“聊天式辅助”走向“自动化协作”的大趋势。大家真正想要的不是一个更聪明的对话窗口而是一个能接进现有工作流、理解工程上下文、能动手处理任务的执行者。用一个不太严谨但很贴切的类比原生 AI 助手像一部刚出厂的手机功能齐全但都是出厂设置superpowers 生态里那些技能包就是手机应用商店里的 App。你可以按需安装每个技能包只解决一类问题互相之间还能配合调用。更重要的是这种扩展方式是开放式的社区里每个人都有能力写自己的技能包发布出来给别人用。这也是它能在极客圈快速传播的核心原因——每个人装完都会产生一套自己的工作流然后分享出来整个生态越滚越大。我还注意到一件事这套体系实际上扮演了“胶水层”的角色。很多团队内部会有自己的构建命令、检查脚本甚至内部工具链这些东西原本很难让 AI 助手理解但通过自定义技能包你可以把这些“团队知识”直接教给助手。新成员入职的第一天跑一遍技能包初始化就能让助手具备团队级的技术认知这是传统文档根本做不到的。从这个角度看superpowers 已经超出了个人效率工具的范畴逐渐成了团队工程效能基础设施的一部分。2. superpowers 安装与环境准备2.1 安装前的运行时检查先说安装因为很多人卡在这一步。superpowers 对底层运行时是有要求的它不是纯脚本需要依赖你机器上已有的某些命令行工具才能工作。我建议按下面这个顺序逐项检查别急着上手装。第一确认你有一个支持插件扩展的 AI 编程命令行助手。目前社区里比较常见的是 Codex CLI 这类工具superpowers 的相关热词里也一直跟着 codex基本可以认为这套技能体系是围绕着 Codex 生态成长起来的。你可以在终端里执行codex --version如果返回了版本号说明基础环境就绪。如果提示找不到命令需要先安装 Codex CLI官方推荐用 npm 全局安装npm install -g openai/codex。第二检查 Node.js 运行时版本。superpowers 的技能调度器本质上是跑在 Node 环境下的脚本集合版本太旧会直接导致部分技能加载失败。node -v我个人建议至少 18 以上20 LTS 更稳妥。低于 16 的话很多语法糖和方法是用不了的装完大概率会报错。第三检查 Git 配置。技能包里很大一部分能力是围绕代码仓库的比如生成提交信息、分析变更集、回滚操作等这些都依赖 Git。确保 Git 已安装且全局身份信息已配置git config --global user.name git config --global user.email两个命令都有输出说明没问题。没有的话先补上不然后面跑技能包会报“无法识别提交者身份”的错。2.2 正式安装与初始化流程环境确认没问题之后安装本身并不复杂。我的建议是拉取主仓库到本地指定目录然后用 CLI 的安装命令直接完成初始化git clone https://github.com/obra/superpowers.git ~/.superpowers cd ~/.superpowers npm install npm run setupnpm run setup这个步骤是关键它会在你的 CLI 配置目录下生成插件入口文件并完成部分技能包的本地索引构建。安装过程中终端会输出一大段日志我第一次看的时候觉得眼花但其实大部分是告诉你哪些技能包被注册了。真正需要留意的只有两类信息一类是ERROR开头的错误信息另一类是WARN开头的警告信息。错误必须处理警告多数可以暂时忽略但建议截个图存一下。装完之后验证是否成功也很简单。在任意 Git 仓库目录下启动 codex输入 “list your skills” 或者直接问“你有哪些超能力”如果返回一长串带描述的能力清单说明安装成功。我第一次看到那个清单时还挺震撼的因为里面除了常见的代码审查、生成提交信息之外还有分析依赖、定位重复代码、解释测试失败原因这类非常具体的能力。2.3 初始化完成后的目录结构认知装完之后别急着用先花两分钟了解一下它的目录结构。因为后续你自己写技能包、改配置都得知道文件放哪里。初始化后的核心目录大致如下~/.superpowers/skills/技能包存放目录每个子目录是一个独立技能。~/.superpowers/config.json全局配置文件控制技能开关、权限策略等。~/.superpowers/scripts/技能包调用的底层脚本一般不需要改。~/.superpowers/templates/模板目录新建技能时的脚手架来源。理解了这个结构后面无论是调试还是扩展你都能很快定位到问题文件。很多人装完发现技能不生效最后查下来都是技能包目录权限不对或者配置文件路径写错这类问题定位起来特别快。3. 核心技能包配置与自定义3.1 技能包体系的基础逻辑superpowers 的技能包体系理解起来其实很简单每一个技能包 一段精心设计的指令提示词 一组可调用的工具函数 一份使用说明。当你在对话中触发某个技能时调度器会把这个技能对应的指令文本注入到对话上下文里让 AI 助手按照预设的流程去执行任务。举个例子一个“代码审查”技能包的底层指令可能会告诉助手“按以下步骤审查代码先读变更文件再关联分析主要函数最后按严重级别输出问题列表”。这套指令写得越具体、越结构化最终的输出就越稳定、越专业。这也是为什么用现成的优秀技能包比自己随口在对话里提需求要可靠得多。从存储角度看技能包就是一个包含特定文件的目录。核心文件是SKILL.md——这是技能的主文件AI 会优先读取它来理解这个技能是干什么的、怎么干。工具脚本则放在同目录或者子目录下。加载机制方面CLI 在启动时会扫描技能目录解析每个SKILL.md的元信息构建成一个可被 AI 检索的技能列表。你在对话里提到某个技能名或者问它有哪些能力时它就是从这份列表里做匹配。3.2 配置一个现成的 Java 专项技能包Java 是 superpowers 生态里比较成熟的方向社区里有人专门做了面向 Maven 项目的工具包覆盖依赖分析、测试执行、编译检查等场景。我自己实际用下来体验最好的是它能把 Maven 的dependency:tree输出解析成结构化的依赖说明AI 可以根据这份说明直接帮你定位冲突。拿配置一个“依赖冲突治理”技能包举例。装好基础版本后它的技能目录大致长这样java-maven-assistant/ ├── SKILL.md └── scripts/ ├── deps_tree.sh ├── run_tests.sh └── compile_check.sh其中deps_tree.sh的核心内容其实就是一行命令的封装#!/bin/bash cd $1 mvn dependency:tree -DoutputFile/tmp/deps_tree.txt -DoutputTypetext /dev/null 21 cat /tmp/deps_tree.txt为什么要封装成脚本而不是让 AI 直接去跑mvn dependency:tree因为在真实项目里构建日志极其冗长直接输出到对话上下文里会占用大量 token还容易让 AI “迷失重点”。封装脚本先把命令跑一遍再只把整理过的结果交给 AI 分析效率和准确率都高得多。在SKILL.md里会写明这个技能的适用场景和调用方式。触发时AI 会读取脚本输出然后结合项目上下文帮你分析是否存在依赖冲突、版本不一致等问题并给出修复建议。实测下来在处理 Spring Boot 多模块项目的依赖冲突时这套技能包能节省大量手动比对 pom.xml 的时间。3.3 手把手写一个你自己的技能包如果说安装现成的技能包是“站在别人肩膀上”那自己写技能包才是真正掌握这套体系的标志。别担心门槛没有想象中高。第一步创建技能目录。命名建议简洁且语义明确比如code-review或commit-message目录名就是技能的标识符。mkdir -p ~/.superpowers/skills/my-project-assistant/scripts第二步创建SKILL.md文件。这个文件是技能的核心里面用结构化描述定义技能的名称、用途和调用方式。一个我最常用的“提交信息生成”技能文件示例--- name: 生成提交信息 description: 根据当前暂存区的代码变更生成符合 Conventional Commits 规范的提交信息 when: 用户要求生成 commit message 时自动触发 --- 请按以下流程执行 1. 执行 git status --short 查看变更文件列表 2. 执行 git diff --staged 查看具体代码变更 3. 根据变更内容总结提交类型feat/fix/docs/style/refactor/test/chore 4. 输出一条主提交信息以命令格式给出方便直接复制这里面最关键的是when字段它定义了技能的自动触发条件。有了它AI 会在用户提出相关问题时自动匹配到这个技能包不需要每次手动指定。第三步添加工具脚本。如果技能包只依赖通用命令可以不用专门写脚本但如果是私有化的项目级操作比如拉取内部接口文档、执行特有的代码规范检查那就需要脚本封装。脚本编写时有一个容易被忽略的细节尽量只输出精简结果避免把中间过程全部灌给 AI。因为脚本输出最终会作为上下文的一部分被 AI 读取输出越冗长AI 的处理精度就越低。第四步验证技能是否被正确加载。重启 CLI然后直接问“你有哪些技能”如果新加的技能出现在清单里说明加载成功。如果没出现检查SKILL.md的格式是否正确、目录权限是否有问题。4. Java 场景实战superpowers 怎么接进日常开发4.1 Java 项目为什么更需要这套能力Java 开发和其他语言相比有几个突出痛点恰好是 superpowers 能针对性解决的。第一是样板代码多。实体类、DTO、Mapper、Service、Controller光是这些常规结构的代码量就非常可观。AI 助手在拥有技能包后能根据项目上下文自动补充这些样板代码而且风格基本一致。第二是构建链路长。一个大型 Maven 多模块项目从编译到测试再到打包动辄几分钟。如果助手只提供了命令而不是执行能力这些时间全都是你的沉没成本。集成执行类技能包后AI 可以直接调动构建工具把时间花在真正的代码分析和修改上。第三是项目认知门槛高。Java 项目的核心逻辑往往分散在多个服务层新人对代码库的理解成本很高。superpowers 可以通过技能包快速提取项目的模块结构、依赖关系、关键配置相当于给 AI 接了一双“透视眼”也间接帮你降低了理解成本。4.2 Java 技能包的典型配置组合下面这套配置组合是我自己在日常 Java 开发中沉淀下来的一套“黄金组合”覆盖从编码到验证的完整链路你可以直接照抄也可以根据项目特点增删。第一Maven 构建控制技能包。脚本封装mvn clean verify常用命令并解析输出的关键信息。AI 可以自动执行编译、测试、打包然后为你总结构建结果。重点是失败时它能直接提供失败模块的路径和失败原因不需要你手动去翻冗长的构建日志。第二依赖关系分析技能包。脚本封装mvn dependency:tree输出结构化的依赖树结果。用途集中在依赖冲突定位、冗余依赖识别。特别适合排查 NoClassDefFoundError 这类问题。第三单元测试生成与修复技能包。脚本封装测试执行、覆盖率汇总命令。AI 根据业务代码自动生成 JUnit 测试并在测试失败时对比分析业务代码和断言逻辑定位失败原因。这个技能包我强烈建议优先配置因为手工写单元测试是极耗时间的环节而 AI 的生成能力在这方面表现非常稳定。第四代码质量检查技能包。脚本封装 Checkstyle 和 SpotBugs 检查命令。AI 根据检查报告定位不符合规范的文件和具体规则并给出修复建议。对于需要做代码评审的技术负责人来说这个技能包能省去大量机械性的检查时间。下面这三行初始化命令是我实际验证过的你可以在自己的项目根目录执行把上面几个技能包一次性接入npx superpowers add java-maven-assistant npx superpowers add junit-analyzer npx superpowers add code-quality-guard执行时留意终端输出看到installed字样就说明该技能包已经装好索引会在下次启动时自动刷新。4.3 与团队协作流程的深度绑定单独个体使用 superpowers 只能提升个人效率真正放大价值的方式是把这套能力绑定进团队协作流程。我见过一种很高效的用法把技能包接入到代码评审前置环节。开发者在提交 Pull Request 之前先让 AI 执行一次代码质量检查技能包自动生成一份“变更前检查报告”把潜在问题、规范冲突的地方提前暴露出来。这份报告会随 MR 描述一并提交评审者打开 MR 时不仅看到了代码差异还看到了机器预先分析的摘要评审效率大幅提升。我还试过把技能包的能力接入到项目文档生成中。Java 项目的接口文档、模块说明文档维护起来很费劲。通过自定义技能包AI 可以在构建成功后自动扫描 Controller 层的注解和实体定义生成结构化的接口文档草稿。虽然最终仍需要人工校对参数描述但初稿质量已经能省掉大半整理时间。在这个阶段一个重要建议是技能包脚本必须遵循“幂等性”原则。同一条命令执行两次结果应当一致不能产生副作用。否则一旦接入自动化流水线重复执行时可能会出现意外行为。团队中如果有人修改了技能包却没有同步文档后续排查问题会成为一个隐蔽的雷区。5. 实操过程与核心环节的完整记录5.1 一场完整的技能包调试过程实际操作中我会建议每个刚接触这套体系的人都完整走一遍“技能包调试”流程。这不只是验证安装更是理解整个体系运作模式的最好方式。我自己调试一个新安装的 Java 技能包时通常会在一个临时测试项目里执行以下完整链路先用命令检查技能包注册状态再实际触发一次技能对话观察 AI 的分析过程最后检查工具脚本的输出文件是否被正确写入。举个真实的例子。装完 junit-analyzer 技能包后我随便找了一个 Spring Boot 测试类在 CLI 中发起指令“run junit-analyzer on PaymentServiceTest”。AI 收到指令后会先读取测试文件再调用技能包脚本执行测试命令测试完成后读取结果文件最后给我输出一份结构化的测试分析报告。整个过程中我注意到 CLI 会在终端里显示每一步的调用细节包括执行了哪条命令、脚本输出了什么内容。这些日志就是判断技能包是否按预期工作的关键依据。调试时有一个常见的误区很多人一上来就在大型生产项目里验证结果因为项目本身复杂度高无法判断是技能包的问题还是项目的问题。我的建议是先用一个最简项目做冒烟测试确认技能包链路通了再放到真实项目里做深化验证。这样可以大大缩短问题定位时间。5.2 关键调试参数与执行日志解读技能包执行过程中CLI 输出的日志信息是排除故障的第一手资料。你需要重点关注三类信息。第一类技能匹配结果。每次对话中CLI 会显示系统匹配了哪个技能包。如果你被匹配到了一个与你意图无关的技能多半是SKILL.md中的描述写得不够准确需要调整description字段。第二类脚本执行结果。包括退出码和输出内容。退出码非 0 说明脚本本身执行失败这时候需要去检查脚本的权限、依赖路径或环境变量。第三类上下文注入情况。这部分决定了 AI 从脚本输出中解析信息的质量。如果某个技能包输出内容过多你会看到日志中提示“上下文截断”这时就得优化脚本输出格式了让它更精简。为了方便对照我把常见的日志关键词和对应的含义整理成了一张速查表。日志关键词含义处理建议skill matched: xxx当前对话命中了 xxx 技能确认技能是否符合预期running tool: xxx正在执行 xxx 工具脚本观察脚本状态和耗时exit code: 0脚本执行成功继续下一步exit code: 1脚本执行失败检查脚本权限和环境context truncated输出过长被截断精简脚本输出或减少内容量skill not found找不到对应技能包检查技能目录加载路径这张表我建议截图存一份。真到报错的时候逐条对照会比在群里求助快得多。5.3 从通用配置到项目级落地的复现路径如果你照着前面的内容一路跟下来现在已经拥有了一个能跑的技能包环境接下来就是把它真正用起来。我给一条比较稳妥的落地路径按照这个顺序逐步推进成功率会高很多。第一步选择一个小型但真实的业务模块作为试验田。别一上来就拿核心支付系统开刀选一个边界清晰、依赖简单的模块比如用户服务或通知服务。第二步梳理你在这个模块上最耗时、最机械的工作内容。比如每次改动都需要补充一堆单元测试那你就把测试生成类技能包作为优先级最高的配置。第三步在 CLI 中实际执行一轮完整的技能驱动工作流。让 AI 完成一次“改代码—跑测试—出报告”的完整闭环把中间遇到的任何异常都记录下来。第四步根据首轮试验结果调整技能包的脚本输出格式或 SKILL.md 的触发逻辑然后重复执行直到整个过程不需要人工干预即可完成。第五步把验证过的技能包配置提交到团队的公共配置仓库让同事通过一条命令完成同步安装。这套流程我前后迭代过三轮第一轮大概用了两周才理顺第二轮缩短到三天第三轮基本可以做到当天配置当天生效。说白了工具本身的复杂性不会因为你多用几次就消失真正高效的是你自己对工具链掌控力的提升。6. 常见问题与排查技巧实录6.1 技能不生效的第一排查顺序这大概是所有人都会遇到的第一道坎装完之后技能清单里看不到新装的技能包或者看到技能包但是触发不了。先检查技能目录是否存在且包含SKILL.md文件。直接列出目录内容ls ~/.superpowers/skills/ | grep 技能包名称如果目录存在但文件缺失可以判断是初始化过程中出了问题最简单的解法是重新运行初始化脚本确保配置目录被完整写入。如果目录和文件都在下一步检查SKILL.md中name字段是否与目录名保持一致。这个看起来很小的细节实际踩坑率极高。CLI 在加载技能时会严格比对目录名和文件内的name字段两者不一致时会发生静默跳过整个技能包在 AI 的感知列表里根本不存在。排除上面两种情况后最后再检查配置文件里的权限开关。有些版本的 CLI 默认不允许技能包自动执行脚本需要在配置里把安全策略设为允许。我建议只在可信仓库中开启自动执行外部项目保持默认限制这是安全与效率的平衡点。6.2 上下文丢失与“AI 变笨”现象很多人在集成 superpowers 后反馈AI 的回答质量好像变差了。这通常不是错觉而是上下文管理出了问题。根本原因是技能包本身会占用上下文窗口。一段精心编写的 SKILL 指令可能有几千字符调度器每次触发技能时都要把它注入对话。当一个会话中同时触发多个技能包时可用上下文空间被大量挤压AI 可参考的项目代码信息变少了回答自然就显得“变笨”了。解决这个问题有两个思路。第一精简技能包描述。检查每个技能包的 SKILL.md凡是能在 500 字符以内表达清楚的就不要写 2000 字的长篇大论。第二勤开新会话。具体到一个任务链路上如果某个技能包已经完成使命就开启新会话再触发下一个技能包不要让没有价值的指令文本持续占用上下文空间。在比较大的项目里我会采用另一种更精细的方式为不同类型的任务配置不同的技能包组合。比如开发调试场景只加载“Maven 构建 测试生成”这两个技能包代码评审场景才加载“质量检查 依赖分析”技能包。按需加载避免所有技能包常驻上下文。6.3 脚本执行失败的系统性排查脚本执行失败是另一个高频问题。表象各不相同有报权限拒绝的有报命令找不到的也有执行成功但输出为空的。权限拒绝先看脚本的执行位是否被设置。Git 克隆下来的仓库有时会丢失执行权限chmod x ~/.superpowers/skills/*/scripts/*.sh命令找不到大概率是 PATH 环境变量问题。CLI 在运行时继承的环境变量可能与你手工执行命令时不同。排查方法是在脚本开头临时加一行which mvn node npm跑完之后看输出哪个命令显示 not found就在脚本中显式写明其绝对路径或者在脚本开头补全 PATH。执行成功但输出为空通常是脚本内部的路径参数有问题。很多技能脚本默认把输出写到/tmp目录但项目本身可能不在预期路径。检查脚本里有没有对工作目录的显式cd操作确保它进入的是目标项目根目录而不是执行 CLI 时的当前目录。脚本问题有一个通用的调试技巧在脚本开头添加set -x让终端输出每一步实际执行的命令和结果。排查完再删掉这一行避免正式使用时的日志噪音。6.4 经典问题速查表把高频问题汇总成一张速查表每次卡住的时候按图索骥基本能解决九成以上的问题问题现象可能原因处理方法技能清单为空配置目录未生成或路径错误执行初始化脚本重建配置技能存在但无法触发SKILL.md 的 name 与目录名不一致改正 name 字段保持同名技能触发后无响应安全策略不允许自动执行在配置中开启自动执行授权脚本执行报 permission denied缺少执行权限chmod x 脚本文件脚本执行报 command not foundPATH 不含命令路径在脚本中设置绝对路径输出内容过多导致回答质量下降上下文空间被占用精简脚本输出采用摘要模式技能与意图不匹配SKILL.md 描述不精确优化 description 字段关键词7. 踩坑记录与效率心得7.1 我自己的三次翻车现场翻车一一次性配了十几个技能包对话界面里满屏都是技能说明AI 回答质量暴跌。后来才意识到技能包的“全”不等于“好”真正值得常驻的只有三五个核心技能包。其余的都应当按需启用随用随调。翻车二把一个内部技能路径硬编码在了脚本里结果团队其他人克隆配置后全都跑不起来。自那之后所有脚本一律采用相对路径或者从环境变量读取路径坚决杜绝绝对路径依赖。翻车三有一次在 Windows 环境下运行时踩到了 CRLF 换行符的坑。脚本文件从仓库克隆下来后CLI 无法正常执行报错信息非常怪异。把脚本转成 LF 换行符后问题立刻消失。跨平台使用这套工具时这是个非常隐蔽的坑。7.2 关于质量与效率的平衡建议说到底superpowers 只是一个放大器你的工作流设计得好它能把效率放大十倍你的工作流本身一团糟它也会把混乱放大十倍。所以在投入精力研究各种技能包之前先把基础工作流理顺。我个人的习惯是每天开工前花五分钟思考当天的主要任务把它们归类到对应的技能包里然后在对话里按顺序触发。整个白天的工作节奏本质上就变成了“触发技能—审核结果—迭代细节”的循环而不是“复制代码—贴到对话—再复制回来”的机械重复。另外不要盲目崇拜任何人的现成配置。我在不同项目、不同场景下反复调整了技能包组合很多次最终沉淀下来的版本已经和最初拉取的模板相差很大了。自己动手删改才能真正形成适合你的工作模式。7.3 最后分享一个关于验证的小技巧每次修改技能包的脚本或者 SKILL.md 之后不要急着说“看起来没问题了”去跑一遍验证链路。我自己会在修改后立刻触发一次该技能检查输出是否正常。如果改了脚本就跑一跑执行结果如果改了说明文件就看一看生成的质量。这个习惯帮我避免了很多次“演示时才发现坏了”的尴尬。现在团队里新成员入职我推荐的第一件事 就是先跑一遍 superpowers 的初始化配置然后在一个小项目里完成一轮“技能包驱动开发”。从目前的效果来看新成员通常在第一天就能用上这套工作流第二周已经能自己往技能库里贡献新的能力包了。工具链的复利效应大概就是从这个时候开始显现的。