Superpowers技能体系全解析：从概念到实操搭建个人能力增强系统

1. 从“superpowers”这个热词说起：它到底指什么

最近一段时间，“superpowers”这个词在技术社区和效率工具圈子里被反复提起。很多人第一次看到它，会以为是某个新出的超级英雄电影，或者某个游戏里的技能系统。但如果你在开发者社区、AI工具讨论群或者效率方法分享帖里看到这个词，它大概率指向的是一个完全不同的东西——一套围绕“技能（skills）”组织起来的个人能力增强体系。

我最早接触这个概念，是在一个做自动化工作流的朋友那里。他给我演示了一套他自己整理的“技能包”，里面包含了文本处理、数据清洗、格式转换、批量重命名等一堆小工具，每个工具都被封装成一个独立的“skill”，需要的时候直接调用，不需要的时候完全不占地方。他管这套东西叫“superpowers”。当时我的第一反应是：这不就是脚本集合吗？但用了几次之后我发现，它和传统的脚本集合有本质区别——每个skill都有明确的触发条件、输入输出规范和使用场景说明，整体上更像是一个“能力操作系统”，而不是一堆散落的脚本。

所以，当我们讨论“superpowers”的时候，我们实际上在讨论的是一套以技能为最小单元、可插拔、可组合的个人能力扩展机制。它的核心价值不在于某个单一功能有多强大，而在于它提供了一种标准化的方式来组织、调用和复用各种能力。你可以把它想象成手机上的应用商店：每个app就是一个skill，你需要什么就装什么，不需要的可以卸载，装多了也不会互相干扰。

这个概念的流行，和当前AI辅助工具的普及有直接关系。当越来越多的人开始用AI来处理日常任务时，一个现实问题就出现了：AI本身的能力是通用的，但每个人的具体需求是高度个性化的。有人需要批量处理图片，有人需要自动整理会议纪要，有人需要快速生成周报。这些需求如果每次都从头写提示词，效率极低。而“superpowers”这套思路，就是把这些高频需求固化成一个个可复用的skill，用的时候直接调，不用每次都重新描述。

适合阅读这篇内容的人，大致有三类：第一类是对“superpowers”这个词感到好奇、想搞清楚它到底是什么的初学者；第二类是已经听说过这个概念、想动手搭建自己技能体系但不知道从哪下手的实践者；第三类是用过一些零散工具、但觉得管理起来很乱、想找一套系统化方法的老手。不管你是哪一类，接下来的内容都会从概念拆解、技能分类、引入方法、实操步骤到避坑经验，一层一层讲清楚。

2. 拆解superpowers的技能体系：到底有哪些skills

2.1 从功能维度看技能分类

要理解superpowers里“有哪些skills”，首先得明确一个前提：skills的分类方式不是固定的，它取决于你把它用在什么场景。但根据我在实际使用和观察中总结的经验，大多数人的技能包都可以归入以下几个大类。

文本处理类技能是最常见的一类。这类skill的核心任务是接收一段文本，按照预设规则进行处理，然后输出结果。典型的包括：格式转换（比如Markdown转HTML）、内容提取（比如从长文中抽取关键句）、批量替换（比如统一修改文档中的术语）、摘要生成（比如把长报告压缩成要点）。这类技能的特点是输入输出都是文本，逻辑相对简单，但使用频率极高。

数据处理类技能稍微复杂一些。它们通常涉及结构化数据的读取、清洗、转换和输出。比如CSV文件的列合并、JSON数据的字段提取、Excel表格的批量公式计算、日志文件的解析统计。这类skill往往需要处理边界情况，比如空值、格式错误、编码问题，所以在设计时要格外注意容错机制。

文件与目录操作类技能是另一大类。包括批量重命名、按规则分类归档、自动备份、格式转换（比如图片批量转格式）、压缩解压等。这类skill的特点是直接和文件系统打交道，操作不可逆的风险较高，所以通常需要加入确认步骤或 dry-run 模式。

信息获取与整理类技能在AI工具普及后变得特别流行。比如定时抓取某个来源的更新、自动整理成固定格式、推送到指定位置。这类skill的难点不在于技术实现，而在于来源的稳定性和格式的规范性。

辅助决策类技能是相对高级的一类。它们不直接执行操作，而是提供分析结果或建议。比如根据历史数据给出排期建议、根据文本内容判断情感倾向、根据关键词推荐标签。这类skill的价值在于减少重复判断的成本。

下面这张表可以帮你快速对照自己的需求，看看应该优先建设哪类技能：

2.2 从触发方式看技能类型

除了按功能分类，另一种更实用的分类方式是看skill是怎么被触发的。这直接决定了你在使用时的体验。

手动触发型是最简单的。你需要用的时候，主动调用某个命令或点击某个按钮。这类skill适合低频但重要的任务，比如季度报告生成、年度数据归档。手动触发的好处是可控性强，不会在你不知情的情况下执行操作。

条件触发型稍微智能一些。当满足某个条件时，skill自动执行。比如“当下载文件夹超过50个文件时自动按类型归档”“当检测到某个文档被修改时自动备份”。这类skill适合有明确触发规则的重复任务，能省去大量手动检查的时间。

定时触发型是按固定时间间隔执行。比如每天早上九点自动整理前一天的笔记、每周五下午自动生成本周工作汇总。这类skill适合周期性的整理和汇报任务。

链式触发型是最高级的一种。一个skill执行完后，自动触发下一个skill。比如“抓取数据→清洗数据→生成报告→发送通知”这样一条完整的流水线。这类skill的搭建难度最高，但一旦跑通，效率提升也最明显。

我在实际使用中的体会是：不要一上来就追求链式触发。先把单个skill跑稳，确认输入输出都符合预期，再考虑把它们串起来。很多人的技能体系之所以最后荒废了，就是因为一开始设计得太复杂，某个环节出问题后整条链都断了，排查起来非常痛苦。

2.3 哪些skills是“必备款”

如果你刚开始接触superpowers，面对琳琅满目的技能类型不知道从哪下手，我建议先从下面这几个“必备款”开始。它们覆盖了最高频的需求，实现难度也不高，能让你快速感受到这套体系的价值。

第一个是文本格式转换skill。不管你做什么工作，总会遇到需要把内容从一种格式转到另一种格式的情况。Markdown转纯文本、HTML转Markdown、CSV转表格、JSON转YAML，这些转换如果每次都手动做，累积起来的时间非常可观。做一个通用的转换skill，支持几种常见格式互转，基本能覆盖80%的日常需求。

第二个是批量重命名skill。这个听起来很简单，但实际使用频率高得惊人。下载了一堆文件需要按规则改名、整理照片需要加上日期前缀、处理数据文件需要统一命名规范，这些场景几乎每周都会遇到。一个支持正则表达式、支持预览、支持撤销的批量重命名skill，能帮你省下大量重复劳动。

第三个是内容摘要skill。在信息过载的环境下，快速提取核心内容的能力越来越重要。不管是长文章、会议记录还是邮件线程，能一键生成摘要的skill，能让你在短时间内判断哪些内容值得细看、哪些可以跳过。

第四个是定时备份skill。数据丢失的风险永远存在，但手动备份又容易忘记。一个简单的定时备份skill，把重要目录定期复制到指定位置，加上版本标记，就能在很大程度上降低意外损失的风险。

第五个是关键词提取skill。从一段文本中自动提取关键词和标签，对于内容整理、搜索优化、分类归档都非常有用。这个skill的实现方式可以很简单，也可以很复杂，建议先从基于词频和位置的基础版本开始，后续再考虑加入语义分析。

3. 怎么引入这些技能：从零搭建你的技能体系

3.1 引入前的准备工作

在动手引入任何skill之前，有几个准备工作必须先做好，否则后面会反复返工。

明确你的运行环境。你是在本地电脑上跑，还是在服务器上跑，还是在一个受限的沙箱环境里跑？这直接决定了你能用哪些工具、能访问哪些资源。本地环境最灵活，但需要自己管理依赖；服务器环境适合定时任务，但调试起来麻烦一些；沙箱环境限制最多，但安全性最好。我个人的建议是：日常高频使用的skill放在本地，定时和后台任务放在服务器，来源不明的skill先在沙箱里试。

确定你的技能存放位置。这个位置应该是固定的、有版本管理的、方便备份的。我见过太多人把skill散落在各个目录里，过两个月自己都找不到哪个是哪个。推荐的做法是建一个专门的目录，比如~/skills或者~/superpowers，下面按类别分子目录，每个skill一个独立文件夹，里面至少包含一个说明文件和一个执行文件。

选择你的调用方式。你希望怎么触发这些skill？是命令行输入一个短命令，还是点击一个图形界面按钮，还是通过快捷键？不同的调用方式对应不同的封装方法。命令行最灵活，适合技术人员；图形界面最直观，适合非技术用户；快捷键最快，适合高频操作。你可以同时支持多种方式，但初期建议先专注一种。

准备好版本管理工具。skill是会不断迭代的，今天能用的版本明天可能因为依赖更新就出问题了。用Git或者类似的版本管理工具来管理你的skill目录，每次修改都提交一次，出问题可以随时回滚。这个习惯看起来麻烦，但关键时刻能救命。

3.2 单个skill的引入流程

引入一个skill，不是把文件复制过来就完事了。完整的流程应该包括下面几个步骤。

第一步：理解这个skill的输入输出。在引入之前，先搞清楚它需要什么输入、产生什么输出、有没有副作用。比如一个“批量重命名”skill，输入是一个目录路径和重命名规则，输出是重命名后的文件列表，副作用是文件被改名了。理解这些之后，你才能判断它是否适合你的场景。

第二步：检查依赖和环境要求。很多skill不是孤立的，它可能依赖某个库、某个命令行工具、某个运行时环境。在引入之前，先确认这些依赖是否已经安装、版本是否兼容。我踩过的一个坑是：引入了一个Python写的skill，本地Python版本是3.9，但skill用了3.10才支持的语法，结果一跑就报错。后来养成了习惯，每个skill引入前先看它的依赖说明。

第三步：在隔离环境中试跑。不要一上来就在生产环境或者重要目录上跑。先建一个测试目录，放几个测试文件，在隔离环境里跑一遍，确认输入输出符合预期。这一步能发现大部分配置问题和逻辑问题。

第四步：配置到你的调用体系中。试跑通过后，把这个skill注册到你的调用体系里。如果是命令行方式，就加一个alias或者软链接；如果是图形界面，就加一个入口；如果是定时任务，就配置好触发条件。

第五步：记录使用说明和注意事项。这一步最容易被忽略，但长期来看价值最大。每个skill都应该有一个简短的说明，写清楚它做什么、怎么用、有什么限制、出问题怎么排查。过几个月你自己都会忘记细节，更别说如果要把skill分享给别人了。

3.3 批量引入多个skill时的组织策略

当你从零开始搭建技能体系时，往往会一次性引入多个skill。这时候如果没有组织策略，很快就会乱成一团。

我的做法是按“使用频率+依赖关系”两个维度来组织。使用频率高的skill放在最上层，方便快速调用；使用频率低的放在子目录里，需要时再找。有依赖关系的skill放在同一个父目录下，比如“数据清洗”依赖“文件读取”，那它们就应该在一起，避免调用时找不到依赖。

另一个策略是建立统一的入口脚本。不要让你自己记住每个skill的具体路径和调用方式，而是做一个总入口，列出所有可用skill和它们的简短说明，通过参数来选择执行哪个。这样你只需要记住一个命令，剩下的交给入口脚本来处理。

还有一个经验是给每个skill打标签。标签可以按功能打（文本、数据、文件），也可以按场景打（日常、周报、归档），还可以按状态打（稳定、测试、废弃）。标签的好处是，当你的skill数量超过二十个之后，你可以通过标签快速筛选出需要的那些，而不是在一堆名字里翻找。

3.4 引入过程中最容易忽略的细节

有几个细节，我在引入skill的过程中反复踩坑，这里单独拎出来说。

路径问题。skill里如果写了绝对路径，换一台机器或者换个目录就失效了。尽量用相对路径或者环境变量。如果必须用绝对路径，把它做成配置项，不要硬编码在脚本里。

编码问题。处理文本的skill，如果输入文件的编码和预期不一致，输出就会乱码。建议在skill开头统一做编码检测和转换，不要假设输入一定是UTF-8。

权限问题。涉及文件操作的skill，如果目标目录没有写权限，会直接失败。在skill里加入权限检查，提前给出明确的错误提示，比跑到一半报错要好得多。

并发问题。如果多个skill同时操作同一批文件，可能会互相干扰。比如一个skill在重命名，另一个skill在读取，结果读到的就是改了一半的状态。对于可能冲突的skill，加入锁机制或者排队机制。

日志问题。skill执行过程中发生了什么，如果没有日志，出问题后完全没法排查。每个skill都应该把关键步骤和结果写到日志里，至少包括开始时间、结束时间、处理了多少条数据、有没有报错。

4. 安装superpowers的实操步骤与避坑指南

4.1 安装前的环境检查清单

在正式安装之前，先对照下面这个清单检查一遍。这个清单是我在多次安装和帮别人排查问题后总结出来的，能帮你避开大部分低级错误。

这个清单看起来基础，但实际安装中至少有一半的问题都出在这些基础项上。我印象最深的一次是帮一个朋友排查安装失败的问题，折腾了两个小时，最后发现是磁盘满了。从那以后，我每次安装前都会先跑一遍这个清单。

4.2 分步安装流程

假设你已经完成了环境检查，接下来是具体的安装步骤。不同的superpowers实现方式可能细节不同，但整体流程是相似的。

第一步：获取安装包或安装脚本。根据你选择的来源，下载对应的安装包或者获取安装脚本。如果是脚本方式，建议先打开脚本看一眼它做了什么，不要直接盲目执行。重点看它会把文件放到哪里、会修改哪些配置、会安装哪些依赖。

第二步：创建独立的安装目录。不要安装在系统目录或者已有项目的目录里，建一个独立的目录，比如~/superpowers或者~/.local/share/superpowers。独立目录的好处是卸载时直接删目录就行，不会残留文件。

第三步：执行安装命令。如果是包管理器方式，通常是一条命令的事；如果是脚本方式，按照脚本提示一步步来。安装过程中注意看输出信息，有没有警告或者错误。有些警告可以忽略，但错误必须处理。

第四步：验证安装结果。安装完成后，不要假设一切正常。跑一个最简单的skill，确认能正常执行。比如如果有一个“打招呼”或者“显示版本”的skill，先跑这个，确认基础环境没问题。

第五步：配置环境变量和路径。把superpowers的可执行文件目录加到PATH里，这样在任何位置都能调用。如果是图形界面方式，创建桌面快捷方式或者菜单项。

第六步：初始化配置文件。大多数superpowers实现都会有一个配置文件，用来设置默认参数、技能目录、日志位置等。根据你的实际情况修改这些配置，不要直接用默认值。

4.3 安装过程中最常见的五个坑

坑一：依赖版本冲突。这是最最常见的问题。你的系统里可能已经装了某个库的A版本，但superpowers需要B版本，两者不兼容。解决办法是使用虚拟环境或者容器来隔离。Python用venv，Node用nvm，通用方案用Docker。隔离之后，superpowers的依赖和系统的依赖互不影响。

坑二：权限不足导致安装失败。在Linux和macOS上，如果安装目录需要root权限，而你没有用sudo，就会失败。但反过来，如果什么都用sudo，又会导致文件所有者变成root，后续普通用户无法修改。正确的做法是：把安装目录设在你自己的用户目录下，完全不需要sudo。

坑三：网络问题导致依赖下载不全。有些依赖包比较大，或者源的速度比较慢，下载到一半断了，但安装脚本没有正确处理这个错误，结果装出来的东西是残缺的。解决办法是配置一个稳定的源，或者提前把依赖包下载到本地再安装。

坑四：旧版本残留导致冲突。如果你之前装过旧版本，没有完全卸载，新版本安装后可能会调用到旧版本的文件。解决办法是安装前先彻底清理旧版本，包括可执行文件、配置文件和缓存目录。

坑五：配置文件格式错误。很多superpowers实现用YAML或者JSON作为配置文件格式，这两种格式对缩进和标点非常敏感。一个多余的空格或者一个中文标点，就会导致解析失败。建议用专门的编辑器来编辑配置文件，开启语法检查。

4.4 安装后的首次运行验证

安装完成后的首次运行，不要直接上真实任务。按照下面这个顺序逐步验证，能帮你快速定位问题。

先跑一个无副作用的skill，比如显示版本号、列出可用技能、打印帮助信息。这一步验证的是基础环境是否正常。

再跑一个只读的skill，比如读取一个测试文件并显示内容、统计一个目录下的文件数量。这一步验证的是文件访问权限和路径配置是否正确。

然后跑一个有输出但不修改原始数据的skill，比如格式转换、内容摘要。这一步验证的是核心逻辑是否正常。

最后才跑有副作用的skill，比如重命名、删除、移动。而且第一次跑的时候，一定要在测试数据上跑，确认结果符合预期后，再用到真实数据上。

这个渐进式的验证流程，能让你在每一步都明确知道问题出在哪一层，而不是一上来就面对一个复杂的错误信息无从下手。

5. 让技能体系真正跑起来：日常使用与维护经验

5.1 怎么把skill融入日常工作流

装好了skill，不代表就能用起来。很多人装完新鲜两天，然后就忘了。要让skill真正产生价值，必须把它嵌入到日常的工作流里。

我的做法是从最高频的场景开始。先找出你每天或每周都要重复做的操作，看看哪个可以用skill替代。比如我每天都要整理下载文件夹，把不同类型的文件归到不同目录，这个操作我把它做成了一个skill，每天下班前跑一次，几秒钟搞定，以前手动做要花五六分钟。

另一个做法是把skill和现有工具结合。比如你的编辑器支持自定义命令，就把常用的skill绑定到快捷键上；你的终端支持alias，就把skill调用做成短命令；你的任务管理工具支持自动化，就把skill挂到特定事件上。让skill出现在你本来就要操作的地方，而不是让你专门去某个地方调用它。

还有一个经验是定期回顾和清理。每个月花十分钟看看你的skill列表，哪些这个月一次都没用过，哪些用了但效果不好，哪些已经被更好的方案替代了。把没用的清理掉，保持技能体系的精简。技能不是越多越好，而是越精越好。

5.2 技能冲突和优先级处理

当你的skill数量多起来之后，冲突是不可避免的。常见的冲突有两种：功能重叠和资源竞争。

功能重叠是指两个skill做类似的事情，但实现方式或输出格式不同。比如你有一个“文本摘要”skill和一个“内容提炼”skill，功能差不多，但一个输出段落，一个输出列表。这时候你需要决定保留哪个、废弃哪个，或者明确它们各自的使用场景。

资源竞争是指两个skill同时操作同一资源。比如一个skill在写日志文件，另一个skill在清理日志文件，就可能出现写了一半被删掉的情况。解决办法是给资源加锁，或者把可能冲突的skill安排在不同的时间段执行。

处理冲突的原则是：明确优先级，避免模糊地带。每个skill都应该有清晰的职责边界，什么情况下用A、什么情况下用B，要能一句话说清楚。如果说不清楚，说明这两个skill需要合并或者重新设计。

5.3 技能体系的版本管理与备份

skill是会不断修改的，今天调好的参数明天可能就不适用了。没有版本管理，改出问题后想回退都回不去。

我用的是最朴素的方案：整个skill目录用Git管理，每次修改后提交一次，提交信息写清楚改了什么、为什么改。这样任何时候都可以回退到之前的版本，也可以看到某个skill的演变历史。

备份方面，除了Git仓库本身，我还会定期把整个skill目录打包压缩，存到另一个位置。Git仓库如果所在磁盘坏了，一样会丢。异地备份是最后一道防线。

另外，配置文件里的敏感信息（比如API密钥、访问令牌）不要直接提交到Git仓库里。用环境变量或者单独的配置文件来管理，Git仓库里只放模板。

5.4 从使用中迭代：我的skill进化实例

最后分享一个我自己的skill进化过程，让你感受一下这套体系是怎么随着使用不断完善的。

我最早做的是一个“文件归档”skill，功能很简单：把指定目录下的文件按扩展名分类，移动到对应的子目录里。第一版跑了一个月，发现几个问题：图片文件太多，按扩展名分完之后jpg和png还是混在一起；有些文件没有扩展名，不知道归到哪；移动之后原始目录空了，但空目录没有清理。

第二版加了按文件类型和日期双重分类，没有扩展名的文件归到“其他”目录，移动完成后自动清理空目录。又跑了一个月，发现新问题：有些文件正在被其他程序使用，移动会失败；有些文件很大，移动很慢，没有进度提示。

第三版加了文件占用检测、移动进度显示、失败重试机制。到现在这个skill已经稳定跑了半年多，基本上不需要我再操心了。

这个过程让我明白一个道理：好的skill不是设计出来的，是用出来的。第一版不需要完美，能解决80%的问题就行，剩下的20%在使用中慢慢发现、慢慢改进。重要的是先跑起来，然后在实践中迭代。

6. 关于superpowers的几个常见疑问

6.1 它和普通脚本集合有什么区别

这是被问得最多的问题。表面上看，superpowers确实就是一堆脚本的集合，但区别在于组织方式和调用体验。

普通脚本集合是散的，每个脚本独立存在，你需要记住每个脚本的位置、参数、用法。superpowers强调的是统一入口、统一规范、统一管理。每个skill都有标准的输入输出定义，有统一的调用方式，有集中的配置和日志。你不需要记住每个skill的细节，只需要知道它能做什么，然后通过统一的方式调用它。

另一个区别是可组合性。普通脚本之间很难组合，因为输入输出格式不统一。superpowers的skill因为遵循相同的规范，可以像积木一样拼起来，一个的输出直接作为另一个的输入，形成流水线。

6.2 需要编程基础吗

取决于你想用到什么程度。如果只是使用别人做好的skill，基本不需要编程基础，会复制粘贴、会改配置文件就行。但如果想自己写skill，或者修改现有skill来满足特定需求，那至少需要能看懂一种脚本语言，比如Python或JavaScript。

我的建议是：先从使用开始，用着用着自然会产生“要是能改一下就好了”的想法，那时候再去学编程，动力会强很多，目标也明确很多。不要一上来就想着从零写一个复杂的skill，那样很容易受挫。

6.3 技能越多越好吗

不是。技能数量和效率提升不是线性关系。前十个skill可能帮你省下30%的重复劳动时间，但到第三十个的时候，管理成本可能已经超过了它带来的收益。

我个人的经验是：保持核心技能在15到20个之间。这些是高频使用的、稳定的、经过验证的。其他的要么合并，要么废弃，要么放到“备用”目录里，需要时再启用。技能体系的价值在于精，不在于多。

6.4 出问题了怎么排查

排查skill问题的基本思路是从外到内、从简到繁。

先确认是不是环境问题：运行时在不在、依赖全不全、权限够不够。这些是最基础也最容易出问题的。

再确认是不是配置问题：路径对不对、参数有没有写错、配置文件格式有没有问题。

然后确认是不是输入问题：输入文件存不存在、格式对不对、编码有没有问题。

最后才怀疑skill本身的逻辑问题。到这一步，看日志、加打印、逐步缩小范围，定位到具体是哪一行出的问题。

大部分问题其实都出在前三层，真正需要改代码的情况并不多。所以排查时不要一上来就盯着代码看，先把外围因素排除掉。

7. 我在这套体系上踩过的真实坑

7.1 一次误删除带来的教训

早期我做了一个“清理临时文件”的skill，逻辑是删除指定目录下超过7天的文件。测试的时候用的是测试目录，没问题。但正式用的时候，我把目录参数写错了，指向了一个存放重要中间结果的目录。结果skill跑完，一批还需要用的文件被删了。

好在有备份，花了一个小时恢复。但这件事让我养成了两个习惯：第一，所有涉及删除、覆盖、移动的skill，必须支持 dry-run 模式，先预览会做什么，确认无误后再真正执行；第二，重要目录的操作必须二次确认，不能一键执行。

7.2 依赖更新导致的连锁故障

有一次我更新了系统里的一个基础库，结果依赖这个库的三个skill同时挂了。排查了半天才发现是库的接口变了，旧调用方式不再支持。

从那以后，我给每个skill都加了依赖版本检查，在skill启动时先确认依赖版本在预期范围内，不在就给出明确提示，而不是跑到一半报一个看不懂的错误。另外，更新系统级依赖之前，先检查有哪些skill依赖它，评估影响范围。

7.3 日志缺失导致的排查困难

还有一个坑是早期skill没有日志，出问题后完全不知道执行到哪一步了、处理了多少数据、在哪条记录上失败的。只能靠猜和反复重跑。

后来我给每个skill都加了标准日志，至少记录：开始时间、结束时间、处理总数、成功数、失败数、失败详情。日志按日期分文件存放，方便回溯。这个改动看起来增加了工作量，但每次排查问题时省下的时间远远超过写日志的成本。

7.4 配置硬编码带来的迁移麻烦

最开始写skill的时候，路径、参数、选项都直接写在代码里。后来换了一台电脑，所有skill都要改一遍，非常痛苦。

现在的做法是：所有可能变化的东西都抽到配置文件里，代码里只保留逻辑。配置文件用统一的格式，每个skill一个配置段。迁移的时候只需要把配置目录复制过去，改一下路径相关的几项就行。

8. 给刚接触superpowers的朋友的几点建议

如果你刚刚开始了解superpowers，或者正准备搭建自己的技能体系，下面这几条建议可能对你有帮助。

从解决一个具体问题开始。不要为了搭建体系而搭建体系。先找到一个你确实经常遇到的、确实让你烦的问题，针对这个问题做一个skill。跑通之后，你自然就知道下一步该做什么了。

不要追求一步到位。第一版能跑就行，不要求全求美。在使用中发现问题、迭代改进，比一开始就设计一个完美方案要实际得多。

重视文档和日志。这两个东西在写的时候觉得多余，在出问题的时候觉得救命。每个skill至少写清楚它做什么、怎么用、有什么限制。每个skill至少记录关键步骤的执行情况。

定期清理。每个月花一点时间回顾你的skill列表，把没用的清理掉。技能体系的价值在于精，不在于多。一个精简的、每个都常用的技能体系，比一个庞大的、一半都没用过的技能体系有价值得多。

保持学习。superpowers这个概念本身还在不断演变，新的工具、新的方法、新的实践不断出现。保持关注，但不要盲目追新。看到新东西先想清楚它解决什么问题、适不适合你的场景，再决定要不要引入。

这套体系说到底，核心不是技术，而是对自己工作方式的持续观察和优化。你越了解自己每天在做什么、哪些环节效率低、哪些操作重复多，你就越能设计出真正有用的skill。技术只是实现手段，对自身工作流的理解才是根本。