1. 项目概述与适用场景Superpowers 这个名字听起来很中二但实际接触下来会发现它其实是一套非常务实的 AI 编程工作流增强方案。简单来说它是一个围绕 AI 编码助手比如 Codex、Worbuddy 这类命令行工具构建的技能包管理与调用框架,用模块化的方式把提示词、工具函数、项目级约束组织成一个个可复用的技能,让你在写代码、改代码、做重构时能够得到更稳定、更可预期的 AI 辅助。我第一次注意到这个项目是在折腾 Codex CLI 的时候。当时我发现自己反复手写一些非常长的提示词模板比如按这个项目的测试风格补测试涉及数据库迁移时先检查兼容性每次都要重新组织语言而且 AI 的输出风格时好时坏。于是我开始寻找一种能够把这类经验沉淀成固定技能包的方式Superpowers 就是在那时候进入我视野的。它解决的核心问题就是如何让 AI 编码助手在不同的项目和场景下都能保持一致的协作行为。这套方案适合几类人一是重度使用 AI 编程助手的开发者二是想给团队建立统一 AI 协作规范的 Tech Lead三是对自动化工作流感兴趣的效率控。它本身不依赖特定的编程语言但如果你在做 Java、Python 或前端项目里面的很多技能包可以直接套用。2. 核心设计思路为什么需要技能包而不是提示词模板2.1 提示词模板的痛点大多数用过 AI 编程助手的人都会经历这样一个阶段一开始觉得非常惊艳什么问题都能答但随着使用深入你会发现输出质量越来越不稳定。同样的任务换个说法描述AI 的理解就完全不一样。更让人头疼的是AI 往往会忘记上下文尤其是当一个任务涉及多个步骤、多个文件的时候它经常写了一会儿就跑偏。我在实践中总结了三个最核心的痛点提示词太长每次都要重新复制粘贴而且容易改出错。不同项目的代码风格、工程约定差异很大AI 无法自动感知。缺少一个机制来锁定 AI 的工作流程比如遇到编译错误应该先看日志还是先查依赖。Superpowers 的基本思路就是把提示词升级成技能包。一个技能包就像一份岗位说明书里面描述了某个特定场景下 AI 应该完成的目标、遵守的约束、可调用的工具以及工作步骤。你不需要每次重新起草只需要按需加载对应的技能包AI 就知道该以什么方式来配合你。2.2 技能包的构成拆解一个标准的 Superpowers 技能包通常会包含下面几个组成部分技能元信息名称、版本、适用范围、依赖关系。这部分用于管理和识别类似软件包的 manifest。系统级指令定义 AI 的角色和协作风格比如你是本项目的资深工程师输出建议时优先考虑可维护性。工作流定义把一个大任务拆解成若干阶段每个阶段有明确的输入、输出和验收标准。工具调用规范规定什么情况下可以读取文件、运行测试、搜索代码库什么情况下需要停下来向用户确认。项目约束参考记录当前项目特有的约定例如代码格式、命名规则、禁止使用的依赖库等。这种结构带来的最大好处是确定性。你不再依赖 AI 的临场发挥而是在一定程度上规范了它的工作路径。我用一个生活化的类比以前用 AI 编程就像请了一个经验丰富但完全不了解你喜好的新厨师每次做菜口味都随机波动Superpowers 就像是给这位厨师一份详细的菜单和厨房操作规范他依然自由发挥但大方向不会跑偏。2.3 为什么选择命令行优先Superpowers 选择以命令行界面为主要的交互入口这一点我一开始不太理解觉得图形化配置不是更友好吗但实际用下来发现命令行优先的设计考虑得很透彻。AI 编程助手本身就跑在终端里命令行方式可以让技能包的加载、切换、管理完全融入工作流不需要频繁切换窗口。另外命令行天然适合组合和脚本化你可以把多个技能包串联起来形成一条自动化的处理链。比如我可以把代码审查技能包和测试生成技能包串起来让 AI 先审查代码再基于审查报告生成测试用例整个过程只需要一条命令。我在实际使用中还发现命令行界面让技能包的版本管理变得非常轻松每个技能包就是一个目录直接用 Git 管理想回滚就回滚想分享就推送远程仓库。这在团队协作里价值很大。3. 环境准备与安装流程实录3.1 前置依赖确认在正式安装 Superpowers 之前有几个基础依赖需要先确认。我踩过一些坑这里直接列一个清单操作系统macOS、Linux 或 Windows需开启 WSL我在 macOS 和 Ubuntu 上都验证过。运行时环境Node.js 18 或更高版本项目本身是基于 Node 实现的。AI 编码助手需要有一个可用的 AI 代码生成工具作为底层引擎比如 Codex CLI。如果你在用 Worbuddy也可以接入后面会讲到具体配置方法。Git用于技能包的拉取和版本管理这个基本都有确认一下版本别太旧就行。之所以强调 Node.js 版本是因为项目里用到了较新的异步处理和文件监控能力旧版本跑起来会有兼容问题。我最初在一台 Node 16 的老机器上装启动时报了一个原生模块编译错误折腾了半天才发现是 Node 版本太低。3.2 通过包管理器安装环境准备好之后安装过程就很快了。下面的命令适用于通过 npm 安装npm install -g superpowers装完之后建议先跑一下版本检查确认安装成功superpowers --version如果没有报错说明主程序已经就位。这里需要注意Superpowers 本身只是一个框架真正发挥作用的是技能包所以下一步是拉取核心技能包仓库。3.3 初始化技能包仓库Superpowers 的技能包存放在独立的 Git 仓库中首次使用需要执行初始化命令把默认的技能包集合clone到本地superpowers init这条命令会做三件事创建一个技能包存放目录、从远端仓库拉取默认技能包、生成一份配置文件。默认配置文件的路径一般在~/.superpowers/config.json里面记录了技能包的搜索路径、当前启用的技能列表、以及针对不同编码助手的适配参数。初始化完成后可以列一下已安装的技能包superpowers list我记得到这一步默认会有十几个技能包覆盖常见场景例如新项目初始化、单元测试生成、代码重构、依赖升级、README 撰写等。3.4 环境变量与编码助手适配Superpowers 需要知道它要控制哪个 AI 编码助手。以 Codex 为例常见的做法是在 shell 配置文件中设置环境变量。在.bashrc或.zshrc中加入export SUPERPOWERS_ENGINEcodex export SUPERPOWERS_CONFIG_DIR$HOME/.superpowers设置完后记得执行source ~/.zshrc或重新打开终端。如果你用的是 Worbuddy那么引擎名称改成worbuddy即可适配方式基本上是一致的。一个容易忽略的地方是Superpowers 并不是直接替代原有的编码助手而是作为它们的前置调度层。也就是说,你在终端发起的命令实际上先经过 Superpowers 解析,它再调用底层的编码助手执行具体任务。这种设计的好处在于,不同的编码助手可以共享同一套技能包,换工具的时候不用重写提示词。3.5 指定项目目录加载全局安装好之后还需要在某一个具体项目里激活 Superpowers否则技能包不会生效。进入项目目录执行superpowers enable这个命令会在项目根目录生成一个.superpowers文件夹里面存放该项目专属的技能配置、自定义约束和工作流规则。每个项目的配置可以独立存在非常适合处理不同团队、不同技术栈的差异化需求。我在一个 Java 多模块项目里执行完superpowers enable后会习惯性检查一下生成的配置文件确认它自动识别到的构建工具是 Maven 还是 Gradle。较新版本的 Superpowers 会根据项目文件结构做自动识别但自动识别偶尔会出错手动修正一下更稳妥。4. 核心功能拆解与实操细节4.1 技能包的查找与加载机制Superpowers 的日常使用中最核心的操作就是加载技能包。加载方式很简单superpowers use java-testing名称用短横线风格类似 npm 包名。执行成功后Superpowers 会把这个技能包的所有指令注入到当前会话的下游编码助手中。实践下来我建议一条命令只加载一个技能包不要图省事叠加好几个否则互相之间的约束可能冲突。查找可用技能包时除了list命令我还经常用搜索功能superpowers search migration搜索结果会展示技能包名称、简介、依赖关系和最近更新时间。这个搜索是基于本地技能包索引做的速度很快不需要联网。4.2 Java 项目的技能包实践热搜词里有 superpowers java这也确实是我最常用的场景之一。Java 项目因为工程复杂度高、编译链长特别适合用技能包来固化 AI 操作流程。以java-project-cleanup技能包为例它的工作流一般是扫描项目结构识别构建工具和源码目录组织方式。解析pom.xml或build.gradle列出所有直接依赖和传递依赖。对照已配置的依赖规则表找出过期的、重复的或存在已知安全风险的依赖。生成一份依赖清理建议报告按优先级排序。只有在用户确认后才自动修改构建文件。这套流程最大的价值在于最后一步的安全阀。早期的 AI 操作往往直接改配置文件,经常改完就编译不过。Superpowers 会把风险操作拆出来,先给建议、等确认,这种刻意设计的缓冲极大地减少了破坏性操作。实操时,我通常会在加载技能包后追加一个目标范围,例如告诉它只检查 web 模块的依赖,跳过 common 模块。Superpowers 的解析器会把这个指令作为技能包执行时的额外约束,最终生成报告的范围就准确很多。这一点非常实用,因为全量扫描在多模块项目里非常耗时,而且信息量太大反而难以聚焦。4.3 自定义技能包的写法系统自带技能包虽然覆盖面广,但每个团队总有一些特殊约定,这时候就需要写自定义技能包。自定义技能包本质上就是一个带配置的目录,结构大致如下my-team-rules/ ├── skill.json ├── instructions.md └── tools/ └── verify-logic.jsskill.json是技能包的元信息文件,字段包括name、version、description、engine和dependencies。下面是一个最小可用的示例{ name: my-team-rules, version: 1.0.0, description: 团队编码规范强约束技能包, engine: codex, dependencies: [java-testing] }instructions.md是技能包的核心,里面写的是给 AI 的具体指令。我用一个简单的模板来说明# 团队编码规范 - 所有新增的公共方法必须包含 Javadoc 注释。 - 禁止在循环中调用远程服务接口。 - 日志必须使用 slf4j,且包含上下文参数。 - 数据库操作必须通过 Mapper 层,禁止在 Service 里直接写 SQL。写完技能包后,把它放到配置目录的skills文件夹下cp -r my-team-rules ~/.superpowers/skills/然后重新扫描一下superpowers scan现在superpowers use my-team-rules就能正常加载了。我建议每个自定义技能包都用一个独立的 Git 仓库管理,团队其他人拉下来放到指定目录就能用,这种做法其实把整个团队的 AI 协作规范做到了代码化。4.4 技能包编排与流程串联Superpowers 比较进阶的玩法是将多个技能包串联成一个复合工作流。举例来说,我在处理一个遗留 Java 模块时,会先加载project-analysis做结构分析,再加载dependency-audit做依赖审查,然后加载refactor-tips生成重构建议。这种方式手动执行的话需要敲三条命令,但 Superpowers 允许在配置里定义工作流别名。在项目的.superpowers/config.json中,配置如下{ workflows: { legacy-refactor: [ project-analysis, dependency-audit, refactor-tips ] } }保存后执行superpowers run legacy-refactor,三个技能包就会按顺序执行,前一个的输出自动作为后一个的上下文输入。这个功能在实践中非常省心,尤其是面对大型项目时,它可以避免你反复手动切换技能包、丢失中间数据。5. 常见问题与排查技巧实录5.1 技能包加载后无效果我刚上手时遇到最多的问题就是:明明执行了superpowers use,但 AI 助手的行为没有任何变化。排查下来发现,绝大多数情况是因为下游编码助手的系统提示词被其他配置覆盖了。很多编码助手支持三级配置:用户级、项目级、会话级,会话级优先级最高。如果你在会话里手动输入过自定义指令,Superpowers 注入的技能指令可能排在其后,效果就不明显。解决办法是:在加载技能包之后,先发送一条简单的测试消息让 AI 复述当前遵循的规则。如果 AI 的回答里包含了你想要的约束,说明注入成功了;如果没有,检查一下会话级配置是不是写了什么残留指令。5.2 命令找不到或版本不匹配有时候升级系统后,superpowers命令会突然找不到。这种情况多半是全局 npm 包的软链接失效了。重新执行一次安装命令就能恢复。真正难排查的是版本不匹配问题:底层的编码助手升级后,接口变化导致 Superpowers 调用报错。这种错误信息一般比较抽象,比如Received unexpected response from engine。我自己的排查流程是:先查看 Superpowers 的日志,默认日志在~/.superpowers/logs目录下,直接看最后一个日志文件的尾部输出,通常就能定位到是哪一步的通信出了问题。确认是编码助手升级导致的兼容性问题后,我一般会先锁定编码助手的版本,等待 Superpowers 发布适配更新。5.3 技能包内部依赖冲突当项目里加载多个技能包时,偶尔会遇到技能包之间互相冲突的情况。典型表现是,两个技能包对同一个操作给出了不同的规则,AI 不知道执行哪一个,输出结果变得混乱。Superpowers 在设计上有依赖优先级机制,但默认策略不一定符合你的预期。一个可靠的做法是,在.superpowers/config.json里显式指定优先级:{ skillPriority: { java-testing: 100, my-team-rules: 80 } }数字越大优先级越高。这样配置之后,冲突的时候 AI 会优先遵循java-testing的约束。不过我还是建议:尽量不要在同一个会话里加载两个强约束类型的技能包,最好拆分任务、逐个加载。5.4 自定义技能包不被识别写好的自定义技能包放到目录里,scan也扫了,但list就是不显示。我遇到过几次,基本都是skill.json格式问题,比如 JSON 里多了个逗号,或者version字段不符合语义化版本规范。这个其实很好自查,用任意 JSON 校验工具验一下格式,再对照官方文档检查必填字段,通常就能解决。另外一个容易忽略的点:技能包目录名必须和skill.json里的name字段完全一致,包括大小写。目录叫my-team-rules,但name写了my_team_rules,就会出现注册失败但不报错的诡异情况。5.5 使用过程中的性能问题在处理特别大的项目时,我发现 Superpowers 的扫描和索引阶段会占用较多 CPU 和内存。特别是scan命令,它要遍历所有技能包,并检查每个技能包的依赖图,项目大时会有明显延迟。Git 仓库体积特别庞大时,首次索引甚至会卡上几十秒。针对这种情况,我通常会在配置里排除不需要扫描的目录:{ ignoreDirs: [node_modules, target, dist, .git] }配合这个配置后,扫描速度显著提升。实测一个包含约 2000 个文件的 Java 项目,配置前扫一次大概 20 秒,配置后降到 3 秒左右。6. 实战案例:Java 遗留项目重构分析为了让你更直观地了解 Superpowers 的工作方式,我用一个实际经历过的案例来说明。当时接到一个内部工具项目,基于 Spring Boot 2.3,Java 8,代码量大概五万行,有一些明显的结构性问题,但没有一个系统性的改进思路。我的第一个动作是进入项目目录,执行superpowers enable初始化项目级配置。然后依次执行复合工作流:superpowers run legacy-refactor这个工作流里包含了结构分析、依赖审查和重构建议三个阶段。第一阶段扫描完,生成了一个模块依赖图,我一眼就看出common模块被几乎所有业务模块依赖,但它自身又依赖了三个业务模块——典型的循环依赖,导致编译时频繁出现奇怪的问题。第二阶段依赖审查给出的报告,把 30 多个直接依赖和百余个传递依赖按风险等级做了一个矩阵。其中有两个传递依赖存在已知的 CVE 漏洞,但直接依赖版本没有冲突,这意味着只需要升级传递依赖对应的直接组件就能解决,不需要大动干戈。第三阶段重构建议是最有意思的,它给出了一个按推荐顺序排序的操作清单,每个操作都附带影响范围分析和回滚预案。我在确认了前三条建议后,手工执行了部分重构,再用 AI 处理剩余重复性工作。整个过程下来,项目构建时间缩短了将近 40%,循环依赖问题也彻底解掉了。这个案例让我真正意识到,Superpowers 的价值不在于让 AI 神奇地看懂你的代码,而是通过规范化的工作流,把 AI 的产出稳定在一个高水位上,而不是时而惊艳、时而离谱。7. 不同编码助手的接入方式和适配经验7.1 Codex CLI 接入配置Codex 是目前社区里比较流行的 AI 编码助手之一,它的命令行模式非常干净,适合和 Superpowers 配合使用。接入方式主要是在环境变量和配置层面做绑定。除了前面说过的SUPERPOWERS_ENGINEcodex,还建议设置SUPERPOWERS_CODEX_MODEL指定模型,例如:export SUPERPOWERS_CODEX_MODELgpt-4.1这样可以在不修改 Superpowers 全局配置的情况下,按项目切换模型。我一般会把这种环境变量写在项目的.env文件里,配合 direnv 之类的工具自动加载,在没用的项目里就不会占内存。和 Codex 搭配时的资源占用也值得留意,Superpowers 会为每次会话维护一个上下文缓存,在长会话中缓存文件可能增长到几十 MB。如果你的机器内存比较紧张,定期执行superpowers cache clean清一下缓存是很有必要的。7.2 Worbuddy 接入配置Worbuddy 是另一个可以接入 Superpowers 的编码助手。它的配置方式和 Codex 大同小异,但有一个需要特别注意的地方:Worbuddy 的会话模型是以对话分组为基础的,Superpowers 注入的技能指令需要添加到一个新的分组才会完全生效。如果你在已有分组里加载技能包,很可能出现指令部分生效、部分丢失的情况。我在使用 Worbuddy 时,一般会给每个任务建一个新的分组,然后在分组内执行:superpowers use project-analysis这样技能指令就会完整注入到该组上下文中,后续对话都遵循这套规则。实测下来,这种做法的稳定性要比直接混用旧分组高很多。7.3 多引擎切换的管理办法如果你像我一样,同时装了 Codex 和 Worbuddy,日常还有一个诉求是在两个引擎之间平滑切换。Superpowers 支持通过启动参数临时指定引擎:superpowers --engine worbuddy use java-testing这个参数只对当前命令生效,不会改动全局配置。结合 shell alias,可以做到一套命令走天下。我在配置里加了两个别名:alias codex-supersuperpowers --engine codex alias worbuddy-supersuperpowers --engine worbuddy这样在终端里分别输入codex-super use java-testing和worbuddy-super use java-testing,背后加载的是同一套技能包,但下游执行引擎完全独立。8. 团队协作与版本管理经验8.1 技能包仓库的 Git 化管理当 Superpowers 在团队里推广开来之后,技能包就不再是个人配置了,它实际上变成了团队 AI 协作知识库。我强烈建议为技能包单独建一个 Git 仓库,并采用如下分支策略:主分支保留稳定可用的技能包,开发分支存放实验中的新技能包,每个技能包的变更独立提交, Commit Message 写明改动意图。这样做最大一个好处是可审计性。当 AI 在某次操作中出现了异常行为,你可以回溯到当时加载的技能包版本,看看是不是某条规则变更导致的。我在团队里推行这套方式后,解决了不少昨天还好用、今天突然不行的玄学问题。8.2 技能包版本锁定和依赖管理一样,技能包版本锁定也是团队协作里的一个重要环节。你肯定不希望昨天大家用的还是同一个技能包版本,今天就有人升级到了新版本,结果输出风格大变。Superpowers 的配置文件里可以锁定技能包版本:{ lockedSkills: { java-testing: 1.2.0, project-analysis: 2.0.1 } }配置之后,后续在项目内加载技能包都会使用锁定版本,除非你显式更新。这个机制对保证团队产出一致性非常有帮助。8.3 与 CI/CD 流程的集成Superpowers 的技能包不仅在本地开发时用,也可以封装成 CI 流程里的一环。比如在 Pull Request 触发时,跑一个代码规范审查技能包,把 AI 的审查结果作为自动评论发到 MR 里。这种做法其实是用人力维护一套规则,再通过 AI 去执行,相当于给静态检查工具加了一层语义理解能力。我在实际项目里,把团队自定义的review-standards技能包接入了 GitLab CI,用一行命令触发:superpowers run review-standards --input $CI_PROJECT_DIR跑完后输出的报告会被 CI 捕获,和eslint、checkstyle的结果一起汇总展示。这套体系运行小半年,最直观的感受是:常规问题在 MR 阶段就被拦截掉了不少,评审人能更集中精力看逻辑设计,而不是反复提格式问题。9. 疑难杂症专项排查与修复手记9.1 引擎通信超时Superpowers 和底层编码助手之间的通信,依赖长连接和回调机制。某些网络环境或者代理配置会干扰这种通信,表现为命令发出后长时间无响应,最后报 timeout。排查时我优先检查底层的编码助手是否在独立终端里能正常工作,如果能,那么问题基本出在 Superpowers 与它的通信层。一个可行的解决思路是调大超时时间。在配置文件里加一项:{ timeoutSeconds: 120 }如果网络状况比较复杂,还可以尝试把通信协议切到轮询模式,代价是会稍微增加延迟,但稳定性会好很多。这也是我在远程开发机上常做的调整。9.2 技能包输出被截断当技能包给 AI 注入的指令太长时,部分编码助手会因为上下文窗口限制而截断内容,导致规则条数不完整。我之前在一个自定义技能包里写了 30 多条规范,结果 AI 实际遵循的是前 15 条,后面那半完全没用上。这种问题有两个方向的解法:一是精简技能包内容,把强约束的规则压到 10 条以内,弱约束放到参考文档里;二是启用 Superpowers 的分块注入机制,让它把一个技能包拆成多个小块按需加载,时刻只能加载当前阶段需要的规则块。9.3 多项目切换时配置残留在不同项目之间来回切换时,容易遇到上一个项目的约束串到下一个项目的情况。这其实是因为技能包信息缓存在全局层面,没有根据项目目录自动清理。最稳妥的办法是在切换项目后显式执行一次重置:superpowers reset然后在新的项目里重新enable并按需加载技能包。虽然多敲两条命令,但换来的是各项目配置互不干扰的确定性。我在同时维护四个项目的期间,一直是靠这个流程避免串味的。9.4 日志排查的关键位置遇到任何诡异的问题,第一反应不要乱猜,先看日志。Superpowers 的日志目录在~/.superpowers/logs,按日期分文件。查看最近日志:tail -n 100 ~/.superpowers/logs/superpowers-$(date %Y-%m-%d).log日志会记录每个技能包的加载时间、注入的指令长度、引擎往返耗时还有错误堆栈。我排查问题时,基本遵循这样的顺序:先确认技能包加载和注入链路是否完整,再检查引擎返回状态,最后看具体的错误堆栈。掌握了这三个环节的日志位置,绝大多数问题都在十分钟内能定位。10. 关于性能调优与资源占用10.1 技能包索引优化Superpowers 在启动和扫描时会构建技能包索引。索引本身是一个倒排结构,技能包数量变多、描述文本变长时,构建时间会线性上升。我目前本地维护了四十多个技能包,不优化的话每次扫描接近一分钟。通过调整ignoreDirs、精简技能描述,已经压到了十秒以内。如果你的技能包数量更多,还可以考虑拆分成多个技能包仓库,按领域分开管理,例如Java 领域技能仓库和前端领域技能仓库,按需切换到对应仓库源。这比维护一个超大仓库要好维护得多。10.2 内存占用控制我记得在一台只有 8GB 内存的旧 Mac 上做测试时,Superpowers 和编码助手两个进程叠加,内存占用一度接近 4GB,机器明显发烫。后来我调整了两处:一是清掉不再使用的技能包缓存,二是通过环境变量限制了编码助手的上下文窗口大小。整体内存占用降到了 2GB 左右,使用体验才恢复正常。日常使用中我也养成了一个习惯:每次跑完一个大型分析任务后,顺手清一下缓存。这个操作成本很低,但能避免长时间开发过程中内存持续累积导致卡顿。10.3 网络请求的合并策略部分技能包会调用在线服务,比如依赖安全评审、文档检索等。如果每个技能包都独立发起网络请求,在复合工作流模式下会明显拖慢速度。Superpowers 支持请求合并,把同一时间段内的多个网络请求打包发送,减少往返次数。这个配置项在config.json中:{ bundleNetworkRequests: true }实测在legacy-refactor工作流里,开启后整体执行时间缩短了大概 25%。当然,这个选项并非所有场景都适合,如果你有断点调试单个技能包的需求,关掉合并反而更容易定位问题。11. 一些长期实践后的心得体会前前后后用 Superpowers 已经有段时间了,从最初只把它当作高级提示词管理工具,到后来真的把团队规范、项目分析、CI 集成都建立在它之上,我的感受是:这类工具真正的价值,是把 AI 的使用方式从自由对话推进到了工程化管理。如果你现在刚接触它,我的建议是不要一上来就追求复杂的自定义技能包和复合工作流,先老老实实用默认技能包跑通一个小项目,感受一下它如何约束 AI 的行为。等你熟悉了它的工作逻辑,再逐步补充团队特有的规则和流程,这样的话,排查问题会轻松得多。最后再分享一个非常实用的小技巧:写自定义技能包里的instructions.md时,第一条指令一定要写如果用户需求与本规则冲突,以用户需求为准。这条兜底规则看似简单,却能在技能包设计不完善的时候,避免 AI 拿着指令胡乱操作。我靠这个止损过好几次,现在每个技能包必带这一句。
