1. 什么是 superpowers以及它到底解决什么问题第一次看到“superpowers”这个词是在一个技术社群的分享帖里。有人问“有没有类似《超能力》一样的东西可以让我的工作流瞬间起飞”底下有人回复了一个链接就是这个叫 superpowers 的项目。当时我以为是某种超级英雄皮肤或者游戏外挂点进去才发现它其实是一套能力扩展框架核心思想非常直接给开发者常用的工具、编辑器、命令行走一些类似“技能书”的扩展模块装上之后原本需要好几步甚至手动重复的操作可以被压缩成一条命令或者几个快捷键。用大白话说superpowers 就是一个“技能装载器”。它本身不生产具体功能而是提供一套标准化的接口让各种“技能”或者说 skills 可以被动态加载。你可以把它类比成游戏里的被动技能槽本身是空的但你往槽里装什么技能人物就会多什么本事。不同的技能之间还可以互相组合比如先装一个代码生成技能再装一个命令行增强技能两个技能叠加之后你在终端里写一句自然语言描述它就能自动帮你生成对应的代码片段并直接插入到编辑器中。这个项目解决的核心问题其实大家都遇到过工具链太碎片化。今天要记这个插件的快捷键明天要背那个 CLI 工具的参数一会儿在编辑器里操作一会儿又切到终端。等真正开始干活时间全耗在切换和记忆上了。superpowers 的思路不是再造一把瑞士军刀而是把已有的瑞士军刀重新打磨、归类、放到你顺手的地方并且让你能按需取用。所以它的适用人群非常清晰前端、后端、DevOps、数据工程这些每天和编辑器、终端高度绑定的开发者以及对“全栈效率”有执念的进阶玩家。新手也能装但前提是你至少已经能用命令行走完一个基础开发流程否则你很难感受到它的甜头。2. 技能体系的设计思路为什么不是“一个插件干到底”2.1 从“单体集成”到“细粒度技能库”的转变在 superpowers 出现之前市面上最常见的做法是做一个“全家桶”插件把一百种功能塞进一个包里。你装上之后设置文件长到离谱启动速度被拖慢而且绝大多数功能你根本用不到。我印象最深的一次是装了一个号称“开发者必备”的合集插件结果光补依赖就花了十分钟装完之后编辑器直接卡死最后只能全部卸掉。superpowers 的设计恰恰相反。它把能力拆成独立的小模块每个模块只负责一件具体的事。比如有的 skills 专门处理“在项目里快速生成符合规范的文件结构”有的专门处理“把 JSON 转成 TypeScript 接口定义”有的专门处理“从 Git 历史里筛选出某次发布涉及的文件改动”。这种细粒度拆分带来的直接好处是你不需要为某个小功能背上整个框架的重量装什么用什么不用的东西不会拖慢你的环境。另一个关键差异是接口标准化。所有技能都遵循同一套加载协议也就是说无论你从社区拉一个别人的技能还是自己写一个私有技能它们都能被同一种方式挂载、调用、组合。这一点特别重要因为只有接口统一技能之间才能互操作。否则每个技能都要自己的热键、自己的命令格式、自己的配置文件最终又是一堆碎片。2.2 “技能”这个隐喻背后的交互逻辑为什么偏偏叫“技能”我自己的理解是它的创造者希望大家把注意力从“工具功能”转移到“完成动作”上。传统插件强调的是“功能列表”比如“本插件提供格式化、重命名、符号跳转、缩略图预览”。而技能强调的是“动作结果”比如“将选中代码转为箭头函数”“把当前目录下所有测试文件的 console.log 批量去掉”。这两种思维的差别非常实际。功能列表是你必须先看一遍文档记住每一个入口然后按图索骥动作结果则是你只需要说出你想干嘛superpowers 会帮你匹配到对应的技能。为了让这个匹配足够自然superpowers 在技能声明文件里规定了统一的触发词、参数定义和示例写法。当你在命令行里输入sp 一键调整当前文件中的类名并同步更新引用时它会把这句话解析成意图再用语义匹配的方式找到最合适的技能组合来执行。这种交互逻辑极其适合重复性场景。它不需要你手写一长串正则也不需要你记得某个重构插件的快捷键是 CtrlShiftR 还是 CmdAltK。你只需要用自然语言描述目标剩下的交给技能调度器。当然它不是万能的复杂操作仍然需要手写配置。但它把“高效”的定义从“我记住了所有快捷键”变成了“我能用最简单的方式表达意图”。2.3 模块之间的组合关系与隔离性superpowers 还有一个我喜欢的地方技能与技能之间默认是隔离的。也就是说技能 A 的运行出了问题不会带崩技能 B 的运行环境。每个技能执行时都会有独立的临时上下文执行完后清理干净不给后续操作留垃圾。这个设计和微服务很像虽然是装在同一个“宿主”里但职责、状态、资源都做了边界划分。边界划分还有一个实际好处方便你把自己的自定义技能分享出去。你在项目里总结出一套团队脚手架生成规范如果只存在你自己的配置文件里别人复用不了但如果封装成一个独立技能包打包发布到内部仓库别人一条命令就能装好而且不会和你自己维护的其他技能冲突。我后来给团队内部搭了一套“前端项目初始化 路由生成 API 接口模板”的组合技能包他们装完之后直呼离谱因为他们完全不需要看我那份三十多行的superpowers.config.json。3. 安装与基础配置先把环境跑起来3.1 安装前置条件哪些东西必须提前准备好安装 superpowers 本身并不复杂但有几个前置条件如果没有满足很容易在安装过程中翻车。这里我按照“最容易出问题的顺序”整理了一遍基础运行时环境必须干净。superpowers 在底层依赖一个现代版的运行时环境我这里以 Node.js 环境为例版本太老会导致现代语法解析失败。我建议把运行时环境升级到官方维护的最新 LTS 版本以上不要用那种自带的老版本系统包否则后面装任何技能都可能报出“无法识别 xxx 语法”这类莫名其妙的问题。包管理器要可用。无论你用哪个包管理器都需要保证它能正常访问公共包仓库。很多人在这一步栽跟头不是因为命令错了而是因为环境里配了旧的源地址安装时一直超时。我的习惯是先用一条简单的包拉取命令做连通性测试通了再继续。系统要有基本的命令行体验增强工具比如 Git 和常用的 shell 环境。因为 superpowers 的不少技能会依赖 Git 做版本对比和文件筛选如果你的系统里连 Git 都没配好那么“根据版本历史生成改动清单”这类技能就算装上了也跑不动。确认完之后打开终端敲一句安装命令。安装完成后务必执行一次自检命令它会帮你检查宿主环境是否满足所有技能的基线要求并把检测结果列成表格。这个步骤看着不起眼但能免掉后面百分之六十的排障时间。3.2 初始化配置文件的几个关键项装好之后第一步是初始化配置文件。这个过程会生成一个默认的配置文件但默认配置非常基础大概只声明了技能仓库地址和全局开关。我们需要手动修改几个核心项第一条是技能仓库源。源决定了你能从哪些渠道发现和安装技能。公共仓库里已经有相当多社区维护的技能但如果你的项目涉及敏感数据或内部的专属格式建议额外配置一个私有技能源。配置方式就是往“sources”数组里加一条带权限信息的地址后续安装技能时会按优先级去不同源里找。第二条是自动加载白名单。这个很重要因为它直接决定你的环境启动速度。默认情况下superpowers 不会把仓库里所有技能全部热加载那样太吃内存。它只会加载你显式标记为“允许自动加载”的技能。其他技能保留在仓库里需要用时再临时启用。这种懒加载策略一开始可能让人不适应但用久了你会发现它才是大型技能库能保持流畅的关键。第三条是触发关键字别名。比如你觉得某条固定动作描述太长了可以给它设置一个简短的别名以后输入这个缩写等价于输入那一整句话。这个功能贴近日常习惯我把常用操作全部改成两个字母的别名之后操作速度有了质的飞跃。初始化完成后强烈建议执行一次整体检查命令。它会遍历本地已安装的所有技能检查每个技能的依赖是否完整、触发词是否冲突、配置文件是否合法然后输出一份健康报告。类似于起了个项目后跑一遍全量测试用来做兜底。3.3 给新手的第一份快速验证清单在开始把大量技能装进环境之前先做一个最小验证确认“安装、配置、调用”这条链路是通的。完整的验证过程是这样的用包管理命令安装一个最简单的技能包。选择“最简单”是故意的不建议一上来就装那种上百 KB 的大杂烩技能一旦出问题你根本分不清是安装环节的问题还是技能自身的问题。编辑配置文件把它加入自动加载白名单。然后新建一个临时目录触发这个技能执行一次最简单的动作。如果它能正确输出结果说明整个链路没有问题。最后执行一次配置检查命令如果这一条也通过了那么你的 superpowers 环境已经可以正常接客了。整套流程大约五分钟比直接莽撞地把技能铺开来要稳妥得多。4. 核心技能盘点哪些 skills 值得马上装进自己的环境4.1 代码生成类技能最实用的生产力来源代码生成类技能是 superpowers 体系里最多人使用的类型。你别把它和简单的代码补全混淆代码补全只是根据当前上下文推测下一个字符而这里的代码生成技能是可以根据一句话的任务描述生成一整个完整的、可运行的文件或模块。举个例子你在一个项目里需要“创建一个符合项目规范的服务端接口模块包含参数校验、权限中间件和统一返回格式”。如果你手动写要复制模板、关注版本号、改一堆命名怎么也得三到五分钟。但通过 superpowers 的代码生成技能你只需要把这句话原样敲进去它会自动读取你项目的既定规范比如目录结构、代码风格、依赖版本然后生成一份初始代码直接写入指定位置。这类技能适合谁特别适合团队里需要维护大量相似模块的开发者。我还见过有人把公司内部的需求文档格式训练成技能输入一小段 PRD它就生成对应的前后端接口定义和 type 声明。注意一点生成代码可以提升效率不代表你可以完全不审阅。我在实操中一定会把生成的代码做一次检查尤其是涉及权限和越权校验的逻辑生成器的判断不一定准确必须切换到人工审查模式。4.2 重构与维护技能处理存量代码的利器对于已经运行了很久的老项目来说新增代码的速度远没有“改动存量代码”的频率高。重构类技能的核心能力是保持行为的语义不变只做结构变化。比如批量提取公共逻辑、把函数式组件迁移到类组件、给所有入口统一加错误边界这些操作手工做起来又慢又容易漏尤其在大型仓库里很容易出现“改了一个地方带崩另一个不相关模块”的情况。superpowers 里的重构技能会先做一个影响面分析对你选中的范围做整体扫描标记出所有关联引用再执行实际改动。它还有一个回滚预设如果执行后你发现某个文件不对一条命令就能恢复到改动前的状态。我认为这是加分项因为很多工具改代码是没有后悔药的只能靠 Git 管理而如果改的是依赖复杂的大型配置文件git diff 能帮你看到部分问题但没法帮你做智能回退。有一点值得提醒重构技能在处理 DSL 类文件比如自定义配置文件、模板引擎时效果不如处理普通代码好因为 DSL 没有统一语法树技能无法做精确解析。遇到这种情况我的策略是把自动重构范围控制到最小剩余部分手工调整再把手工调整的逻辑反哺回技能配置下一次它就能处理得更好。4.3 终端与自动化类技能让重复劳动变成一句话终端类技能的目标很纯粹把日常重复执行的命令序列封装成可复用的能力。比如发布前要走一遍编译、跑测试、打镜像、推送仓库如果每一步都用鼠标点效率极低通过终端技能把整个流程封装成一条流水线执行时只需要填一个版本号或环境名就够了。我的一个典型用法是把“项目初始化流程”做成了技能包新同事入职之后不需要读那一份冗长的手册只需要执行技能里的“初始化开发环境”命令它会自动检查依赖版本、安装 hooks、生成本地配置文件、启动基础服务。整个过程不用人工干预出了问题它会把具体的报错原因和解决建议打印出来。自动化技能和脚本的主要区别在于它的假设与校验机制。普通脚本默认外部环境是已知的而 superpowers 的自动化技能在执行前会先校验前置条件不满足就停在那里并告诉你缺什么不会傻乎乎地把环境搞得更乱。这对维护一个稳定开发环境来说太重要了因为脚本跑一半失败比手动操作失败更难定位问题。4.4 数据接口类技能打通格式转换的最后一公里数据接口类技能最适合做数据格式转换和导入导出。前端拿到的数据常常来自各种不同的后端接口有的返回下划线字段有的用驼峰命名有的嵌套一百层有的就摊平一层。手工写转换逻辑费时费力而数据类技能可以通过模板表达式快速重组数据形状。比如把 OpenAPI 文档直接转换成 TypeScript 的请求函数库在过去我们可能需要引入额外的代码生成工具还要配一堆模板参数。现在只要一个技能输入 OpenAPI 文件地址输出就是一份按 module 拆分好的接口文件同时附带完整的类型定义。更有意思的是它还能反转方向把你的类型定义反推成一份 mock 数据模板测试联调的时候经常能帮上大忙。不过要留意的是数据接口类技能对输入数据的格式要求比较高。如果输入数据本身不规范、字段名随意技能就推导不出你想要的结构最终生成的代码反而比手写更混乱。我的习惯是在使用这类技能前先对源数据做一次 schema 校验符合预期的情况下再交给技能去做转换。5. 手把手搭建一个“自动生成组件 自动更新引用”的组合技能方案5.1 先从明确目标和边界开始这部分我会带你完整实操一套组合技能方案。目标设定为在项目里通过一条命令实现组件的创建、到自动注册路由、再到统一导出。这个流程在很多后台管理系统里非常常见手动操作需要涉及至少四个文件组件目录下的新文件、路由配置文件的注册项、全局组件的导出声明、以及菜单配置的扩展项。其中最容易出错的是“引用路径”问题。手动容易漏因为新组件的位置不同相对路径就完全不同稍不留神就写错。这也是我选择这个场景作为教学案例的原因它能充分发挥 superpowers 的长处——跨文件更新保持上下文一致性。开始之前先确认权限。技能需要的操作范围是在你的项目目录内新建文件、修改路由配置文件和导出配置文件。如果你在团队项目里操作最好先确认分支可写。这个限制很实际我见过有人直接把生产分支当成实验环境一条技能命令下去改了好几个配置文件最后都不知道改了什么。5.2 撰写技能定义文件每个技能都遵循同一个标准结构包括基本信息区、触发规则区、执行逻辑区和依赖声明区。基本信息区声明技能的名字、版本号和描述这个描述不能随便写因为以后通过自然语言匹配技能时这里的内容就是“索引依据”。触发规则区定义这个技能的调用方式。我通常会同时配置“指定触发命令”和“语义识别触发词”两种形式前者适合熟练后直接输入快捷指令后者适合不熟悉但想通过自然语言触达的场景。执行逻辑区是这个技能的核心它定义了这个技能完整执行链路读取目标名、确定组件类型、生成组件内容、追加导出语句、更新路由注册表、刷新菜单配置。每一步还带有前置校验不满足条件就终止并给提示。依赖声明区里最需要注意的是执行环境和权限要求。如果某个操作依赖特定命令工具必须在配置里显式声明。否则技能运行时发现依赖缺失它就只能报错而这类报错信息往往不够直接排查起来并不轻松。写完定义文件后把它放到本地的技能目录中再执行一次技能扫描命令。如果扫描通过终端会显示“技能注册成功”这就意味着 superpowers 已识别了该技能的元数据和触发词接下来就可以进入调用阶段了。5.3 实际调用一次并追踪执行日志我在一个典型的管理后台项目中实际跑通了这套过程。首先准备一个临时需求新增一个“支付订单详情页”这是一个普通页面组件需要挂到订单管理菜单下。然后在终端里敲下命令带参数“page 支付订单详情页 /order/detail”。执行过程非常快它先创建了正确的目录结构然后生成了初始模板文件模板里已经包含顶部返回按钮、基础搜索表单和空状态占位模块接着它修改了路由配置文件在订单管理的 children 里追加了对应字段随后它更新了全局导出把新页面的 lazy 加载声明写了进去最后在菜单配置里增加了对应的菜单项及图标占位。完整日志从开始到结束大概三秒。我在执行后分别打开了路由配置、菜单配置和新建的组件文件逐项核对。需要承认的是自动生成的模板文件只能保证结构和规范正确具体业务逻辑和数据结构关系仍然需要在文件里二次开发。但这已经帮我解决掉了“文件位置挂错”“引用路径少写一个层级”“路由地址和菜单不联动”这些高频低级错误。5.4 复盘执行链路中容易踩的坑第一次跑这套技能时我在路由注册这一步翻车了。原因很典型技能默认通过配置文件中已有的某个 anchor 标记来定位插槽位置但那个项目里配置文件的格式和技能预设的格式不一致导致插入位置偏离预期。后来我在配置里允许自定义 anchor 以及在找不到 anchor 时的“追加模式”如果项目里没有标准的锚点就自动把新路由追加到文件末尾而不是强行插到中间。第二个坑是组件命名规范不一致。有的项目组件是 PascalCase还有的项目是 kebab-case技能默认按 PascalCase 生成在另一个项目里跑出来的文件名和项目内规范不匹配。解决办法是在技能定义里增加“命名策略”参数通过读取项目里的现有文件名反推当前项目的命名习惯让新生成的文件自动贴合项目现状。最后一个坑是菜单排序。技能生成的新菜单项默认排到了菜单最前面而产品要求新菜单默认排在菜单末尾。我在技能定义中加了“order 参数”没有传入时默认使用上一次新菜单项的序号加一保证插入顺序合理。这种小细节只有在真实项目里反复使用你才会摸透。6. 从技能装配到自研扩展把 superpowers 变成自己的东西6.1 调试自定义技能的手段自定义技能写出来后大概率不会一次跑通。如果你只靠“执行 - 看结果 - 不行再改”的反馈循环效率不高尤其是当技能链路长、涉及多个文件改动的时候一个问题点可能要全链路跑一遍才能暴露。好在 superpowers 提供了单独执行某一步调试的能力。你可以在配置里把执行逻辑拆成多段分段执行每一段都能单独调试。比如组件生成单独跑一遍它输出的模板如果没问题再让路由更新那段跑一遍避免一坨代码整体执行最后分不清是哪一段出的问题。这有点像单元测试中的 prevent 原则每次都保证一个最小但完整的链路被验证过。我在调试中还养成了一个习惯频繁使用状态快照。每次执行前通过快照把当前项目关键文件的位置记录下来执行后如果发现组件挂载对了但路由没更新可以通过快照把路由配置文件恢复到执行前保留组件生成的结果再单独修路由更新的逻辑。这个流程配合“只保留有效改动”的步骤会让自定义技能的开发周期大幅缩短。6.2 技能参数化把一次性操作变成可复用资产写技能最大的乐趣在于参数化。最初的技能可能是针对某一个具体页面写死的但如果你舍得花时间把关键内容提取为参数它就能覆盖一类需求。以“生成订单详情页”为例把“订单”和“详情页”提炼成参数之后一次技能就能同时生成“用户列表页”“退款审核页”“商品编辑页”只要给不同参数就行。更进一步把“组件模板”本身也参数化不同项目可以指定不同的模板来源有的项目用简单空白页有的项目用包含搜索区、表格区、分页区的标准中后台模板。这样同一个技能加载进来面对不同项目就会自动呈现不同产出极大提升了技能的复用价值。参数化的另一个好处是可以做数据校验。技能在执行前会对必填参数做一次合法性检查如果必填参数为空或者类型不匹配会直接拒绝执行并说明原因。这样你可以放心地把技能交给同事使用而不担心他们在不合适的参数下把它跑出尴尬结果。6.3 把内部最佳实践沉淀成团队级技能superpowers 的最终形态我认为不只是个人提效工具而是团队经验的可复用容器。团队中总有某些操作流程是需要有一定经验的老人才能顺利完成。新人来了最好的路径应该是直接安装一个封装好的技能包在技能的引导下完成整个流程。这样既不会漏步骤产出的结果也更规范统一。我建议团队内部使用独立的技能仓库。每个人的本地环境不用装一大堆东西只需要安装好宿主然后订阅一个“团队推荐技能集”系统会自动安装所需的必备技能。新版本技能发布之后团队成员的本地环境可以自动增量更新不需要反复人肉同步配置。沉淀团队技能需要注意的是“不能过度抽象”。每个团队希望能被沉淀下来的操作一定是有稳定预期和明确结果的。那些还在探索期、每天做法都在变的流程不太适合立刻封装成技能强行封装只会让技能维护成本爆炸反而束缚了探索空间。我的经验是先在个人维度反复用同一套流程等到超过半个月没有人提出流程调整需求时再考虑把它升级为团队级技能。这个尺度需要自己把握但它能省掉很多无谓的维护负担。7. 常见问题与排查实录让踩坑经验直接成为你的避雷指南7.1 安装顺利但调用时提示“技能未注册”这是新手期最高频的问题。出现这个提示首先不要怀疑安装过程大概率是配置的问题。刷新本地技能索引然后确认技能包目录路径是否正确。注意有些技能包解压后是两层目录结构如果你把外层目录直接当作技能根目录加载器会找不到里面的技能定义文件。如果目录没问题检查技能的定义格式。比如缺少必需的元数据字段或者是版本号格式不正确这类问题在加载时不会报错但系统会静默跳过加载。我用一个简单的办法排查查看本地技能清单如果清单里没有出现这个技能就说明它在解析阶段被过滤了再单独校验技能定义文件的合法性如果清单里有但没有可调用的触发词就说明问题出在触发规则的配置上。7.2 自然语言触发时常匹配到不想要的技能语义识别的机制本身带有概率性不可能百分百选准。如果它总是匹配到不合适的技能你可以增加“触发词权重”调整。在一句话描述里某些词对意图的指向性非常强比如“路由”“暴露接口”“导出定时任务”我给这些高权重的名词加上标记系统在匹配时会优先参考这些词。另外我还建议在技能描述里写清楚“不擅长什么”。就像一个人做自我介绍时除了说我会什么也要说明我不会什么。系统在语义匹配时如果命中排除规则词典就会降低该技能的得分。这能很有效地减少那种看似语义沾边但实际完全不是你想法的错误匹配。7.3 动作执行到一半报错且错误堆栈指向宿主环境这种情况大概率是宿主和技能之间的版本兼容性问题。旧版本宿主对一些新技能使用的协议支持不完整导致技能在执行中调用了不存在的接口。解决办法是优先升级宿主到最新版本。如果升级后仍然复现那就需要检查技能是否有“最小宿主版本号”要求。有的技能会声明自己需要某个版本以上才能运行如果你的版本低于要求装的时候系统也会提示但前提是你没有跳过警告。我踩过一次坑一个第三方技能装的时候提示“建议版本较新”我没当回事结果跑的时候一直报内部错误折腾了半小时升级宿主版本后一次通过。所以看到这类警告不要为了省一点升级时间而忽略它。7.4 技能执行结果不符合预期如何定位是状态问题还是逻辑问题这个问题的排查思路很重要。我会先判断是“状态问题”还是“逻辑问题”。状态问题是执行动作时依赖的上下文状态不对比如它以为 A 文件里有一段特定代码标记实际却不存在。这类问题用快照回溯非常有效恢复到执行前修改状态再跑一次。逻辑问题则是技能算法本身的缺陷比如对于边界输入没有考虑周全或者不同项目的差异性没有通过参数规避。这时需要进入技能的调试模式逐段执行并查看每段的结果定位到具体逻辑分支再修。大多数时候我在排查中发现的都不是一个纯粹的 bug而是我在定义技能时“过度假设了项目的统一性”。不同项目的实际情况千差万别最好的办法是多预留可配置的参数让技能在执行前“确认约束条件”而不是盲目执行默认方案。7.5 常见问题与解决方案速查问题现象常见原因解决动作安装失败/超时包管理器源地址不可达更换可用的公共包源重新拉取启动加载慢自动加载白名单里堆了太多技能只保留高频技能在白名单其他技能临时启用技能匹配不准技能描述与触发意图重叠度低调整触发词权重增加排除规则词典执行路径错误项目根目录识别失败在项目配置文件里显式声明项目根目录标志依赖安装失败项目依赖与最新版本不兼容锁版本声明或换用另一版本分支执行结果与文档不符文档版本更新滞后以技能发布页说明为准不要只看旧文档8. 几个关于“度”的个人体会superpowers 这类工具用久了最大的风险反而不是工具本身难用而是你会过度依赖它把一切流程都想包装成技能。我见过有同事试图把“修复 bug”这么一个开放性问题也封装成技能结果发现它根本预测不了业务逻辑的变更最后只能草草收场。技能的天花板在于“规则明确、产出稳定”的场景而不是万能的流程自动化。我在实际使用中的体会是把技能的边界划清楚反而能提升它的价值。高频重复的操作让它做低概率出现的边缘状况留给自己处理。我用 superpowers 管理了日常开发环境中至少六成以上的固定流程省出来的时间并没有用来多写代码而是用在代码评审、方案设计、以及验证生成代码的正确性上。这样心态反而更放松了因为我知道重复的动作不会因为手抖而出错而真正需要判断力的地方我也更有精力处理。如果你正打算在自己的工作流里引入 superpowers最后再分享一个小技巧别一上来就去收藏一堆技能先把一个真正困扰你的流程封装成技能把它跑通、跑顺。当你把一个真实场景完整地变成一项技能之后你自然就明白哪些环节适合抽象哪些环节不适合这个感知比看任何文档都来得可靠。