这几年我在 Clojure 社区里翻过不少配置清单和最佳实践绝大部分都是告诉你把这些插件安上、把那几行配置贴进去然后你得到一个看起来很酷的编辑器但真上手写业务代码时你根本不知道某些功能是怎么冒出来的出了错也不知道该去改哪一层。后来我盯上了这个叫 superpowers 的开源项目它一改这种授人以鱼的套路把所有能力拆成一个个带编号的 skills每个技能都是一份可理解的教程加上一段可落地到编辑器里的配置。这篇文章不打算做成文档翻译我只讲自己实际安装、引入技能、用 REPL 驱动写代码这一路上遇到的问题和心得适合那些已经会用 Clojure/ClojureScript 写点东西但总觉得自己的开发环境差点意思的人。1. 一个技能树式的开发环境而不是一坨快捷配置1.1 为什么我一开始对这种技能设计是怀疑的先说点大实话。我最初看到 superpowers 这个名字第一反应是又一个把 dotfiles 堆到天上的配置包。因为很多类似的仓库做出来的东西看起来很强实际是你删掉某个插件后整个环境就崩了仓库主人是 Twitch/YouTube 的播主他的配置绑定在个人习惯上普通人根本滚动不起来。但 superpowers 的几个设计点确实改变了我这种偏见。它不叫配置而叫技能。每个技能对应一个明确的编辑器能力比如连接到任意 nREPL在 buffer 内执行 Clojure 表达式用 clojure-lsp 做语义诊断。你按顺序引入技能每引入一个你的编辑器就多一块拼图。这些技能之间不是靠一份全局配置文件强行耦合的而是各自有独立的说明文档、配置片段和练习样例。另一个让我改观的地方是它的学习属性。这项目不满足于让你能用它逼你懂。每个技能开头通常会有一段背景说明讲清楚这个能力解决什么问题然后才是配置步骤最后还会留一个半开放的练习你自己把配置改一改让它适配一个额外的场景。我之前跟着别的大神配置走一天就能把环境弄得很繁华但三天后我就忘了那些快捷键为什么是这样绑的。在 superpowers 里我引入一个技能要花二十分钟但这二十分钟里我理解的是一套底层原理而不是几十行魔法配置。1.2 项目的边界它不是一个编译器也不是一门语言还有一个重要边界需要说清楚。superpowers 不是一个独立的编程语言运行时也不是 Clojure 编译器的一部分它是介于Clojure 基础学习和编辑器深度定制之间的一套工作流主要面向 Clojure/ClojureScript 开发。它围绕的核心工具基本是这一套组件作用和技能的关系nREPLClojure 的远程 REPL 协议让编辑器能连上运行中的进程几乎所有高级技能的地基clojure-lsp提供补全、跳转、诊断、重构等语言服务以 LSP 技能的形式引入parinfer / smartparens结构化编辑让括号层级永远可读一套独立输入法层面的技能Calva / Conjure / Cider不同编辑器里的 Clojure 客户端技能的具体载体不同编辑器有不同分支deps.edn / Leiningen构建与依赖管理技能运行时的依赖入口理解了这个边界你就明白超级精力不该乱用。真正需要花大力气的是技能之间的配合逻辑比如什么时候需要在多个 nREPL 连接间切换什么时候要用远程 nREPL 连到测试环境里的进程。这些是通用开发能力不只是某个编辑器的按键映射。2. superpowers 到底包含了哪些 skills先给你看清全貌2.1 从 101 到 30x一份我整理过的技能清单这项目里的 skills 是有编号体系的数字越大依赖关系越深我也建议按顺序引入否则容易遇到功能有了但不知道它底层在干什么的尴尬。我根据自己实操过的内容把技能分了档这里直接给出一张很实用的表技能编号技能名我自己的叫法引入后你得到什么前置技能101第一个在线 REPL在编辑器里直接执行当前 buffer 的表达式看见返回值无102在括号森林里行走结构化选择、提升、滑动括号告别手数括号101103LSP 点亮语义补全、悬停文档、跳转定义、引用查找101201多会话切换同时连接项目主进程和测试进程互不干扰101, 103202远程进程接线连接跑在 Docker 或远端服务器上的 Clojure 进程201203热重载与状态管理改业务代码不丢 REPL 状态对长期运行的服务很有用201301栈回溯与性能抓手异常堆栈可点击跳转性能数据直接在编辑器里呈现201这些名字是为了方便理解不是项目原话。比如 101 在不同编辑器分支里实现方式完全不同VS Code 里可能是借助 Calva 的 Evaluate current top-level formNeovim 里则是 Conjure 的cpp操作但背后的原理都是把 buffer 里的文本发给 nREPL 求值。2.2 每个 skill 内部到底长什么样一个技能不只是一段配置它一般是教程 补丁 练习的三件套。我在本地打开过某个技能的目录结构大致是这样skills/ 101-connect-repl/ README.md config/ settings.json # 编辑器级别的开关 keybindings.json # 快捷键绑定 exercises/ one.clj # 一个练习文件 two.cljs # 浏览器端练习 patches/ user.clj # 用户级 REPL 初始化其中 README.md 是最有价值的因为它把配置背后的意图讲清楚了。config 目录里的文件不是让你直接覆盖到全局的而是给你看懂了再合入。exercises 里的代码通常要自己改一改、在 REPL 里跑一跑才算真正引入这个技能。patches 则是针对运行时的补充比如给 nREPL 加上某些 middleware。这种三件套结构让引入技能变成一件有节奏感的事先读文档再合配置最后用练习验证。这比把整个 dotfiles 拷过来盲装要稳得多。2.3 你以为已经懂了其实还差一个编号我还观察到一个隐藏逻辑编号不完全是按难度排的也按你在真实项目里会用到的频率排。101 到 103 是每天都要用的基本功201 开始是为中型项目和团队协作准备的301 基本是排查线上问题的高级手法。如果你只想给日常写算法题配环境引入 101 到 103 就够了如果你在做一个后端服务或者嵌入式 ClojureScript 应用201 和 203 几乎是必须的。这也是我想提醒大家的不要一股脑把所有 skill 都引入你需要的是一套能支撑当前项目的核心链路而不是把项目变成技能展览馆。3. 把 superpowers 装进编辑器完整操作链路3.1 前置环境先把这些东西准备好我不建议在还没有 Clojure 命令行工具的前提下就去装 superpowers。你需要先有这些否则后面会有大量看似莫名其妙的失败一个支持所选编辑器的 Clojure 客户端VS Code 用 CalvaNeovim 用 ConjureEmacs 用 CiderJava 运行时我实测用 OpenJDK 17 和 21 都正常Clojure CLI 工具负责提供clj和clojure命令一个用 deps.edn 组织的项目最好先建个空的练习项目用来测试技能引入是否成功。你可以用一条命令把最基础的东西确认掉clojure --version java -version我当时就是栽在一个旧 JDK 8 上nREPL 连接一直断换了 JDK 17 才好。这里先给你一个经验nREPL 和 clojure-lsp 对 Java 版本很敏感装之前看一眼官方文档要求的 JDK 下限别让环境问题污染到你判断技能的引入是否成功。3.2 从仓库到本地的三种引入方式我实际操作下来发现这个项目支持三种引入策略适用不同场景第一种是全量克隆人工合入。把项目 clone 到本地然后按 README 逐个把配置文件复制到你的编辑器配置目录里。适合第一次接触因为你必须逐行看不能偷懒。第二种是符号链接总体接管。把 superpowers 的 skill 目录直接软链到你的.config或settings.json的加载路径里适合决定长期使用它作为主工作流的人。缺点是如果上游更新了你的本地符号链接会直接跟着变有时候配置文件的结构变化会破坏当前环境。第三种是按技能打补丁只下载某一个具体 skill 目录手动合并它涉及的配置片段适合已经有自己成熟配置、只想补充特定能力的人。我自己用的是一开始全量 clone走到 203 技能后就回退到按技能打补丁的方式。原因很简单全量符号链接虽然省事但一旦你偏离了作者的习惯配置每次上游更新都会冲突管理成本很高。3.3 每个技能的实际落地以 VS Code 为例如果你用 VS Code流程相对最直观。装好 Calva 扩展后引入 101 技能的步骤差不多是这样创建一个练习项目保证存在deps.edn和至少一个源目录比如src/打开项目根目录启动 REPL 会话Calva 会读取 deps.edn 并启动 nREPL把 skill 中 config 里的settings.json合并到工作区设置里再照着keybindings.json把快捷键绑定进去我一般只绑最常用的两个避免覆盖自己肌肉记忆里的键位。关键的一步是patches/user.clj。这个文件通常是放在~/.clojure/下的用户级初始化脚本里面可以加载一些 nREPL 增强 middleware。如果没有它技能里某些高级功能比如上下文感知的补全可能不生效。我当时第一次合入时就把user.clj的位置放错了找了好久才发现 Calva 启动 nREPL 使用的是clj的默认用户路径不是项目路径。这一点值得单独记住。3.4 用 Neovim 引入时的差异点Neovim 分支下的 superpowers 把配置藏在 lua 模块里引入一个技能通常意味着把一个 lua 文件放进lua/superpowers/目录然后在init.lua里启用require(superpowers.skills).load({ 101 true, 103 true })这里有个坑Conjure 的 REPL 映射通常定义在after/ftplugin/clojure.lua里而技能里给的是全局键位直接往全局键位表塞会污染所有文件类型。我的做法是给技能加载设置一个独立的 keymap 前缀比如leadersp然后每个技能再往下挂子映射leaderspv 将当前顶层表达式送进 REPL leaderspc 关闭最近的 REPL 会话 leaderspf 跳转到当前符号的定义这样你既保留了 Conjure 的默认键位又把 superpowers 的技能键位隔离开来。技能加载的成功标准是在任意clj/cljs文件里按下那个键状态栏能看到已连接 nREPL之类的反馈而不是直接报 silent error。4. 引入技能之后REPL 驱动工作流是怎么跑起来的4.1 一个真实场景从零连上进程到改完代码热重载装完 superpowers 后我的第一个完整工作流是给一个 ClojureScript 项目加一个功能。以前我会写代码、刷新浏览器、看 Console 报错来回折腾。现在整套流程完全变了。第一步用 101 技能确认当前 buffer 可以被求值。我打开src/app/core.cljs光标放在一个 form 上执行将表达式发送到 REPL立刻在编辑器的内嵌终端里看到了返回值。这一步很基础但它验证了从文件到 nREPL 再到浏览器环境这条链路是通的。第二步用 102 技能做结构化编辑。Clojure 代码最炸心态的就是一堆括号我过去写复杂条件时经常漏括号或者多括号。引入了 parinfer 相关技能后我只需要按缩进来写括号层级会自动跟着缩进走。这玩意儿不是帮你写代码是让你把注意力解放到真正的逻辑上。第三步用 201 技能把测试进程单独拉一条线。我在项目里同时起了两个 REPL 会话一个连主程序体一个连测试运行器。测试跑挂了我能直接跳到测试文件里改再重新加载那个测试 namespace根本不用重启开发进程。这在纯手动管理 nREPL 的时期是不可想象的。4.2 为什么 nREPL 连接不稳定的问题大量消失了很多人在不用 superpowers 之前对编辑器连 Clojure 进程的认知是玄学有时候连得上有时候连不上过一会儿又断。我在慢慢引入这些技能后才理解了里面的关键参数。nREPL 不像 HTTP 那样简单它默认只支持单一客户端连接。如果你同时开了 Calva、Cider 和 Neovim三个客户端去连同一个端口后到的会让前面的无效。superpowers 在处理多会话时靠的是 nREPL 的ack端口和中间层代理它会给每个客户端分配一个独立的 session id而不是真的给每个客户端开独立端口。在配置里你要注意两件事一是启动 nREPL 时使用类似于{:aliases {:repl {:extra-deps {nrepl/nrepl {:mvn/version 1.1.1}} :main-opts [-m nrepl.cmdline --port 7888]}}}二是如果你的编辑器客户端有允许任何 middlewares的开关要打开否则加载user.clj时会被安全校验拦下来。我把这两件事做好之后连接稳定性明显提升不再出现今天能用明天连不上的怪症。4.3 技能之间如何协作以热重载为例热重载是 203 技能里最有价值的一块。很多人觉得热重载就是改完代码自动刷新其实在 Clojure 里它的核心是如何在不重启进程的情况下替换已经加载的变量定义并且不丢失运行时状态。superpowers 教的方法不是用某个黑科技插件而是回到 Clojure 自身的clojure.tools.namespace/refresh机制。它在user.clj里封装了一组函数让你在编辑器里一键执行清除所有 namespace、按依赖顺序重新加载、最后重新调用启动入口。实际操作里我遇到过一个典型场景我在跑一个 WebSocket 服务手上有几百个已经连上来的客户端连接。如果按旧习惯改完handler.clj就重启进程所有连接都断用户全被踢下线。有了这套技能后我改完代码执行refresh服务进程还是同一个监听端口的 socket 也没关只是业务逻辑换了新的。这种能力在学习阶段看着不惊艳但真正维护一个线上服务时它是救命级别的好处。当然热重载也有它的边界这也是我在使用中总结出来的不是每个 namespace 都能安全刷新如果某些变量有外部副作用比如注册了定时任务或者持有了原生对象refresh之后这些旧引用会变成孤儿必须手动清理。所以 superpowers 在 203 技能里专门提供了一个钩子让你在刷新前跑一个before-refresh函数去释放这些资源。5. 用几天后最容易踩的坑和我的排查路径5.1 配置加载了但功能没出现先从三个层面筛查我最开始引入 103 技能clojure-lsp时明明把配置都放到位了但代码补全就是不出。我花了两小时才发现问题不是 lsp 服务器没启动而是 nREPL 补全能力和 LSP 补全能力在我的工作区里冲突了。排查顺序很重要。我后来固定了一套思路遇到配置了但没效果的情况先看三个层面第一层客户端是否真的加载了新配置。VS Code 里改完settings.json后窗口需要 reloadNeovim 里改完 lua 模块后要重启或执行:luafile加载。这个看起来小儿科但它最容易漏。第二层对应的进程是否真的以新配置启动。比如 clojure-lsp 是从旧端口拉起的那不管你怎么改.lsp配置都不会生效。你可以直接在命令行手动跑一次clojure-lsp --project-root .看它输出的启动日志确认它确实读到了你的超能力配置目录。第三层依赖是否真的在 classpath 上。很多技能会引入额外的库比如org.clojure/tools.namespace。如果你的deps.edn没把技能要求的依赖加进去编辑器层面的客户端会静默失败。用clojure -Stree或在 REPL 里执行(require clojure.tools.namespace.repl)都能快速验证。5.2 nREPL 端口被占用与幽灵连接另一个高频问题出在多项目并行时。你的电脑上一堆项目各起一个 nREPL端口如果写死成同一个后启动的项目就会把前面的连接冲掉。我遇到的现象是项目 A 执行 REPL 求值没反应项目 B 的返回值却莫名其妙出现在项目 A 的终端里。说白了就是编辑器的文件-连接映射错乱了。superpowers 的多会话技能里其实有对应的管理工具它的思路是让你不依赖固定端口而是让 nREPL 自己选一个可用端口然后把端口写到.nrepl-port文件里编辑器每次从文件读端口再连接。我参考这个思路后把每个项目的:repl别名改成clojure -M:repl .nrepl-port 然后用一个简单的 shell 片段把该端口的内容展示出来cat .nrepl-port这样每个项目都是动态端口旧项目的端口文件被新项目覆盖也不会互相打架。真实项目里这种做法比写死 7888要稳太多。5.3 上游更新把配置结构改了怎么办superpowers 的一个隐藏风险是它还在快速演进技能的目录结构可能会变。某次我git pull之后发现原来在config/settings.json的配置被拆到了config/editor/下面符号链接直接失效。这时候最忌讳的事情是强行保留自己的符号链接靠记忆补配置。我后来养成的习惯是先从上游公告里看一眼变更说明再决定是否跟进。如果只是小改我会用三个文件来管理自己的差异层文件作用superpowers.base.vendor.json上游未改动的基线配置不手改superpowers.diff.json记录我相对于基线的修改superpowers.personal.json只放我的个人键位和习惯这样每次上游更新我只需要重新生成基线文件然后让diff和personal重新叠加就能快速知道哪些自定义技能丢了。这也是我和这个项目和解的方式上游是课程你是讲师你把课程拿到手里之后当然要自己调整讲课顺序。6. 把别人的技能改成自己的定制一个新 skill6.1 从消费技能到生产技能什么时候该自己写当你用了几周后某些项目专属的工作流就会浮现出来。比如我给一个嵌入式 Clojure 项目调试时需要一个把当前文件推送到远程设备并执行的命令superpowers 官方技能里没有直接提供这个能力。这时候你面临两条路一是把所有东西都塞进项目自己的脚本里结果换项目之后又要重写一遍二是把这种行为抽象成一个新的 skill把它和项目逻辑解耦下次换个项目也能复用。我建议至少用几周再开始自定义技能因为你得先积累出什么值得抽象的判断。我自己写技能时有个朴素标准如果一个操作我要连续执行三次以上且每次都需要先做三步以上准备动作它就值得封装成一个 skill。6.2 写一个自定义 skill 的完整步骤我先描述一个很简单的例子做一个在编辑器里查看某个 Clojure 函数调用统计数据的技能技能名叫402-call-stats。第一步建目录skills/ 402-call-stats/ README.md config/ settings.json patches/ stats.clj第二步在stats.clj里写核心逻辑。比如统计当前 buffer 里所有定义的函数被多少处引用(ns superpowers.stats (:require [clojure.string :as str])) (defn count-uses [sym] (count (re-seq (re-pattern (str \\b sym \\b)) (slurp (or (first *command-line-args*) )))))这个是简化版真实的技能里你肯定要接入 clojure-lsp 的索引结果而不是用正则但它足以说明一个技能的核心部分其实就是一段可被编辑器调用的函数。第三步把配置文件和新技能挂到加载器。如果你在 Neovim 里就把它写成一个after/ftplugin/clojure/lsp的 lua 模块local M {} function M.call_stats() local sym vim.fn.expand(cword) local cmd clojure -M:stats .. sym local result vim.fn.system(cmd) print(result) end return M第四步写 README。这一条很多人嫌麻烦就跳过了但我强烈建议写。因为技能的价值不在代码而在如何用没有文档的技能过两个月你自己都会忘记它该怎么启动。6.3 自定义技能的卸载与边界管理自己造技能最爽的一点是你可以随意加功能但最危险的一点也是这个。我见过一些人把 superpowers 改成了个人口味很重的集成环境之后整个技能体系变成一个不可迁移的工程。要避免这种情况我给自己的规则是每个自定义技能只做一件事如果一件事里有两个以上的动作拆成两个技能自定义技能的文件尽量只依赖官方技能提供的公共入口比如superpowers.lsp这样的基础模块而不是直接篡改基础模块写文档时明确标注这个技能和项目无关可以和项目解耦。在我自己的体验里自定义技能带来的长期收益比直接改配置要好得多。一个配置是一次性的别人拿不走一个技能是产品化的小工具它在团队里可以被复制、讨论、改进。7. 最后的几点实操体会这个项目给我最大的收获不是某个快捷键或者某个配置文件而是一种对开发环境进行版本管理的心态。我现在看待编辑器配置的方式已经从我的配置文件里有什么变成了我掌握了哪些技能哪些技能之间还缺一块拼图。如果你正准备开始引入 superpowers我的建议是先别去动你已经稳定使用的日常项目单独建一个玩具项目只用 101 和 102 两个技能跑三天等你对这套读文档-合配置-做练习的节律熟悉了再把 103、201 这些技能逐步放进来。这样即使某个技能引入失败你的核心工作流还是完整的不会突然进入什么都不能用的状态。最后再分享一个小技巧本地练习时把每个 skill 的 README 打开放在屏幕右侧左侧放着对应练习代码遇到不理解的配置项别急着往下走先动手删掉它看看功能缺了什么再把它加回去。这套方法看起来蠢但它是理解技能内在依赖关系最快的路比我给你列一百条注意事项都管用。技能这东西装进去很简单真正变成自己的还是要靠这种反复拆卸和组装的过程。