1. 从“superpowers”这个标题说起它到底是什么第一次看到“superpowers”这个词很多人脑子里蹦出来的可能是超级英雄电影里的超能力或者某个游戏里的技能系统。但如果你是在技术社区、开源项目或者开发者群里看到这个词那它大概率指向的是一个完全不同的东西——一个围绕 AI 编程助手能力扩展的工具集或框架。我最早接触这个概念是在一个开发者聚会上有人提到“给编辑器装上 superpowers”当时我还以为是某种插件合集后来深入了解才发现它更像是一套让 AI 辅助编程从“能写代码”进化到“能像资深工程师一样思考和工作”的方法论加工具链。简单来说superpowers 解决的核心问题是AI 编程助手虽然能生成代码片段但往往缺乏项目全局观、上下文记忆和工程化思维。你让它写个函数它写得挺好但你让它重构一个模块、排查一个跨文件的 bug、或者按照团队规范提交代码它就开始胡言乱语了。superpowers 的思路就是通过一系列配置、提示词工程、工具集成和工作流设计把 AI 助手的能力边界从“代码补全器”扩展到“虚拟团队成员”。它适合谁呢如果你是一个经常用 AI 辅助写代码的开发者不管你是刚入门的新手还是带团队的老手只要你觉得现在的 AI 助手“不够聪明”或者“不好用”那这套东西就值得你花时间研究。我写这篇东西的出发点很简单网上关于 superpowers 的中文资料太碎了要么是零散的安装命令要么是某个特定场景的配置片段缺少一个从思路到实操再到避坑的完整梳理。我自己在项目里折腾了好几轮踩了不少坑也总结了一些让 AI 助手真正“听话”的技巧。下面我就按照我自己的理解把 superpowers 这套东西拆开揉碎讲清楚。2. 核心设计思路为什么需要给 AI 助手“开挂”2.1 AI 编程助手的天然短板在哪里要理解 superpowers 的价值得先搞清楚现在的 AI 编程助手到底缺什么。我用过不少工具从早期的代码补全到现在的对话式编程发现它们普遍存在几个硬伤。第一个是上下文窗口的限制一个中型项目动辄几万行代码AI 不可能全部读进去它只能看到你当前打开的文件或者你手动粘贴的片段这就导致它给出的建议经常“只见树木不见森林”。第二个是缺乏项目级的记忆你昨天告诉它这个项目用的是某种特定的架构模式今天再问它它已经忘得一干二净。第三个是工程规范意识薄弱它生成的代码可能逻辑正确但命名风格、注释习惯、错误处理方式跟你的团队规范完全不搭。这些短板不是模型能力不够而是使用方式的问题。就像你招了一个技术很强但完全不熟悉你项目的新人你不给他文档、不告诉他规范、不让他看代码库他当然干不好活。superpowers 的核心思路就是给 AI 助手补上这些“入职培训”和“工作环境”。2.2 superpowers 的解决路径配置层、提示层、工作流层我梳理下来superpowers 的实践可以分成三个层次。最底层是配置层解决的是“让 AI 知道项目长什么样”的问题。这包括项目结构说明、技术栈清单、代码规范文档、常用命令列表等等。这些东西不是写给人类看的而是专门为 AI 优化的格式比如用结构化的 Markdown 或者 JSON 来描述方便 AI 快速解析。中间层是提示层解决的是“让 AI 知道怎么干活”的问题。这包括系统提示词的定制、任务模板的设计、对话历史的压缩策略等等。最上层是工作流层解决的是“让 AI 融入日常开发流程”的问题比如代码审查、提交信息生成、自动化测试触发等等。这三个层次不是孤立的而是相互配合的。配置层提供事实基础提示层提供行为准则工作流层提供执行框架。我见过很多人只做了配置层就以为万事大吉结果发现 AI 还是经常跑偏就是因为缺少提示层的约束和工作流层的引导。2.3 为什么这套思路值得投入时间有人可能会问花这么多时间折腾配置和提示词值得吗我的答案是如果你每天用 AI 助手超过一小时那绝对值得。我自己的体验是在没做任何定制之前AI 生成的代码大概有 30% 需要我手动修改或者重写而且经常需要我反复解释项目背景。做了 superpowers 这套配置之后一次通过率能提到 70% 以上而且它给出的建议明显更贴合项目实际。更重要的是它减少了我“跟 AI 解释需求”的心智负担让我能把精力集中在真正需要人类判断的架构设计和业务逻辑上。还有一个隐性收益是团队协作。当你把 superpowers 的配置作为项目的一部分提交到代码仓库里团队里每个人用的 AI 助手都会遵循同样的规范生成的代码风格自然就统一了。这比写一堆文档然后指望大家自觉遵守要有效得多。3. 核心细节解析superpowers 的关键组件与实操要点3.1 项目上下文文件给 AI 的“入职手册”项目上下文文件是整个 superpowers 体系的地基。我一般会在项目根目录放一个专门给 AI 看的说明文件命名上可以用.ai-context.md或者AI_GUIDE.md关键是让 AI 工具能自动识别或者方便你手动引用。这个文件的内容需要精心设计不能随便复制 README 就完事。我通常会把内容分成几个固定板块。第一个板块是项目概览用三五句话说明这个项目是干什么的、核心功能有哪些、面向什么用户。第二个板块是技术栈清单精确到版本号比如“Java 17 Spring Boot 3.2 MySQL 8.0 Redis 7.0”这样 AI 就不会给你生成基于旧版本的代码。第三个板块是目录结构说明重点标注哪些目录放什么类型的代码比如service层只放业务逻辑、controller层只做参数校验和路由。第四个板块是代码规范包括命名约定、注释要求、异常处理方式、日志格式等等。第五个板块是常用命令比如怎么启动本地环境、怎么跑测试、怎么打包。注意这个文件不要写得太长控制在 500 到 1000 字之间。太长了 AI 反而抓不住重点而且每次对话都要消耗上下文窗口。我的经验是把最关键的信息放在前面细节可以放在后面AI 会优先关注开头部分。3.2 提示词模板让 AI 按套路出牌提示词模板解决的是“每次都要重新解释需求”的问题。我一般会准备几套常用模板比如“新增功能模板”、“Bug 修复模板”、“代码审查模板”、“重构模板”。每个模板都包含固定的结构任务描述、输入信息、输出要求、约束条件。以“新增功能模板”为例我会这样写首先说明“你是一个资深 Java 后端工程师正在参与一个 Spring Boot 项目”然后给出具体的功能需求接着明确输出格式要求比如“先给出设计思路再给出代码实现最后列出需要注意的边界情况”最后加上约束条件比如“不要引入新的第三方依赖”、“所有公开方法必须有 Javadoc 注释”。这样一套模板用下来AI 的输出质量会稳定很多不会今天给你写个接口明天给你写个抽象类。模板不是一成不变的我会根据实际使用效果不断调整。比如我发现 AI 经常忘记处理空值就在约束条件里加一条“所有入参必须做空值校验”。又比如我发现它生成的单元测试覆盖率不够就在输出要求里明确“每个 public 方法至少对应一个正常用例和一个异常用例”。3.3 对话历史管理别让上下文爆炸用 AI 助手时间长了对话历史会越来越长最后要么超出上下文窗口要么让 AI 变得“注意力涣散”。superpowers 的一个关键实践就是主动管理对话历史。我的做法是每个独立任务开一个新对话任务完成后把关键结论摘录到项目笔记里而不是让对话无限延续。如果某个任务确实需要多轮对话我会在每轮结束时让 AI 自己总结一下当前进展和待办事项然后下一轮开始时把总结粘贴进去而不是依赖工具自动携带全部历史。这样做的好处是上下文始终精简AI 的响应速度和质量都有保障。另外我会定期清理不再需要的对话避免工具里堆积太多历史记录影响检索效率。3.4 工具集成让 AI 能“动手”而不只是“动嘴”superpowers 的另一个重要维度是让 AI 助手能够调用外部工具。比如让它能执行终端命令、读写文件、查询数据库、调用 API。这需要你的 AI 工具支持工具调用或者插件机制。我目前用的方案是给 AI 配置一个受限的命令执行环境它可以通过特定格式的指令来运行测试、查看日志、检查代码风格。这里的关键是权限控制。你不能让 AI 随意执行任何命令否则它可能不小心删库跑路。我的做法是只开放白名单命令比如mvn test、git diff、cat这些只读或者安全的操作。写操作比如git commit、mvn deploy必须由我手动确认。这样既享受了自动化的便利又不会失去控制。4. 实操过程从零搭建一套可用的 superpowers 配置4.1 环境准备与工具选型在开始之前你需要确定自己用的 AI 编程助手是什么。目前主流的选择有几类一类是编辑器内置的 AI 插件一类是独立的对话式编程工具还有一类是命令行下的 AI 助手。不同工具对 superpowers 的支持程度不一样有的支持自定义系统提示词有的支持项目级配置文件有的两者都支持。我自己的主力环境是 VS Code 加上一个支持自定义指令的 AI 插件同时配合命令行工具做批量处理。选型的时候我主要看三个指标是否支持项目级配置、是否支持工具调用、是否支持对话历史导出。这三个指标直接决定了你能不能完整实施 superpowers 的各个层次。提示不要一开始就追求“全家桶”先把你最常用的那个工具配置好跑通一个完整流程再考虑扩展到其他工具。我见过有人同时折腾五六个工具最后哪个都没配好。4.2 第一步编写项目上下文文件打开你的项目根目录新建一个文件我习惯叫它AI_CONTEXT.md。然后按照前面说的五个板块来填充内容。这里我给出一个我实际项目里的简化示例你可以参考这个结构# 项目上下文 ## 项目概览 这是一个面向中小企业的库存管理系统后端核心功能包括商品管理、入库出库、库存预警、报表导出。 ## 技术栈 - Java 17 - Spring Boot 3.2.0 - MySQL 8.0使用 MyBatis-Plus 作为 ORM - Redis 7.0用于缓存和分布式锁 - Maven 3.9构建工具 ## 目录结构 - src/main/java/com/example/inventory/controllerHTTP 接口层只做参数校验和路由 - src/main/java/com/example/inventory/service业务逻辑层所有核心逻辑写在这里 - src/main/java/com/example/inventory/mapper数据访问层只写 SQL 映射 - src/main/java/com/example/inventory/model实体类和 DTO - src/test/java单元测试和集成测试 ## 代码规范 - 类名用大驼峰方法名和变量名用小驼峰 - 所有 public 方法必须有 Javadoc说明参数含义和返回值 - 异常统一使用自定义的 BusinessException不要直接抛 RuntimeException - 日志使用 SLF4J禁止使用 System.out.println - 数据库查询必须考虑分页禁止全表扫描 ## 常用命令 - 启动本地环境mvn spring-boot:run -Dspring-boot.run.profileslocal - 运行测试mvn test - 打包mvn clean package -DskipTests - 代码格式化mvn spotless:apply这个文件写完之后每次跟 AI 对话时要么让工具自动加载它要么在对话开头手动粘贴进去。我实测下来光是这一步就能让 AI 的代码采纳率提升至少 20%。4.3 第二步定制系统提示词系统提示词决定了 AI 的“人设”和“行为准则”。不同的 AI 工具设置位置不一样有的在设置面板里有的在项目配置文件里。我一般会写一段 200 到 300 字的系统提示词核心内容包括角色定义、工作原则、输出格式要求。我的系统提示词大概长这样“你是一个有十年经验的 Java 后端工程师熟悉 Spring 生态和分布式系统设计。你的任务是辅助我完成日常开发工作。请遵循以下原则第一所有代码必须符合项目上下文文件中的规范第二在给出代码之前先简要说明设计思路第三主动指出潜在的性能问题和边界情况第四如果不确定某些信息直接问我而不是猜测。输出代码时使用 Markdown 代码块并标注语言类型。”这段提示词看起来简单但效果非常明显。AI 不再上来就甩一堆代码而是先跟你确认需求给出的代码也更有工程味。4.4 第三步建立任务模板库在项目里建一个ai-templates目录把常用的提示词模板存成 Markdown 文件。我目前维护了六个模板新增接口、修改接口、修复 Bug、代码审查、单元测试生成、数据库迁移。每个模板都包含“适用场景”、“模板内容”、“使用示例”三个部分。以“修复 Bug 模板”为例模板内容是这样的“我遇到了一个 Bug表现是 [描述现象]。复现步骤是 [步骤]。我期望的行为是 [期望]。相关代码在 [文件路径]。请帮我分析可能的原因并给出修复方案。修复方案需要包含根因分析、修改点列表、修改后的代码、验证方法。”用模板的好处是你不用每次都想“我该怎么问”直接填空就行。而且模板本身可以迭代你发现某个模板效果不好就调整它下次用的时候自动就改进了。4.5 第四步配置工具调用与自动化如果你的 AI 工具支持工具调用可以进一步配置自动化流程。我配置了几个常用场景代码提交前自动让 AI 审查 diff、生成提交信息、检查是否有遗漏的测试。具体做法是写一个脚本在 git pre-commit 钩子里调用 AI 工具的 API把 diff 内容传进去让 AI 返回审查意见。这里要注意的是自动化流程不能完全替代人工判断。我的做法是 AI 审查结果只作为参考最终提交还是由我确认。另外API 调用要考虑频率限制和成本不要每个文件保存都触发一次审查那样既慢又贵。5. 常见问题与排查技巧实录5.1 AI 不遵守项目规范怎么办这是最常见的问题。你明明在上下文文件里写了“所有 public 方法必须有 Javadoc”但 AI 生成的代码就是没有注释。我排查下来主要有几个原因一是上下文文件没有被正确加载AI 根本没看到二是上下文文件太长关键信息被淹没了三是提示词里没有强调规范的重要性。解决办法分三步首先确认工具是否真的读取了上下文文件可以在对话里直接问 AI“你看到项目规范了吗”让它复述一遍其次把最重要的规范放在上下文文件的开头并且用加粗或者列表形式突出最后在系统提示词里加一句“如果生成的代码不符合项目规范我会要求你重写”。5.2 AI 生成的代码能跑但性能很差这个问题通常是因为 AI 缺乏对数据规模的认知。比如你让它写一个查询接口它给你写了个全表扫描然后内存分页在小数据量下没问题数据一多就崩了。我的应对策略是在上下文文件里明确写出关键表的预估数据量级比如“订单表预计千万级商品表预计十万级”。这样 AI 在写查询时会主动考虑索引和分页。另外我会在代码审查模板里加一条“请评估这段代码在数据量增长十倍后的表现”。让 AI 自己做性能推演往往能发现它之前忽略的问题。5.3 对话轮次多了之后 AI 开始“胡言乱语”这是上下文窗口溢出的典型症状。AI 在长对话中会逐渐丢失早期信息开始重复或者自相矛盾。我的做法是设置一个硬性规则任何任务如果超过十轮对话还没完成就强制开新对话把当前进展总结成一段文字带过去。总结的内容包括已完成的部分、待完成的部分、关键决策和约束条件。还有一个技巧是定期让 AI 自己压缩对话历史。你可以说“请把到目前为止的对话总结成 200 字以内的要点包括已确认的需求、已完成的修改、待解决的问题”。然后你把这段总结作为新对话的开头这样既保留了关键信息又释放了上下文空间。5.4 团队协作时配置不一致如果团队里每个人用的 AI 工具和配置都不一样那 superpowers 的效果会大打折扣。我的建议是把 AI 相关的配置文件纳入版本控制包括上下文文件、提示词模板、系统提示词。然后在项目 README 里加一节“AI 助手配置指南”说明怎么把这些配置应用到各自的工具里。对于工具差异可以做一个兼容层。比如上下文文件用纯 Markdown 写这样所有工具都能读提示词模板用占位符标记变量不同工具用脚本做替换。关键是让核心配置统一工具层面的差异通过适配来解决。5.5 常见问题速查表问题现象可能原因排查步骤解决方案AI 不遵守规范上下文未加载或太长问 AI 复述规范精简上下文突出关键规范代码性能差缺乏数据量认知检查是否全表扫描在上下文中标注数据量级长对话后胡言乱语上下文窗口溢出检查对话轮次开新对话带总结过去团队配置不一致各自为政检查版本控制统一配置文件写配置指南AI 拒绝执行任务权限或安全限制检查工具权限设置调整白名单或换工具6. 我踩过的坑和最后分享的几个技巧第一个坑是过度依赖 AI 的“自信”。AI 有时候会用非常肯定的语气给出错误答案尤其是在涉及具体版本号、API 签名、配置参数的时候。我的经验是凡是涉及外部依赖的具体细节一定要自己验证一遍不要直接复制粘贴。我一般会让 AI 给出答案后再问一句“这个信息的来源是什么你确定吗”有时候它就会改口说“我不确定建议你查官方文档”。第二个坑是上下文文件写得太“人类友好”。一开始我直接把 README 复制过去结果 AI 抓不住重点。后来我改成结构化、列表化的写法效果立竿见影。AI 对格式的敏感度比人类高你用表格和列表给它信息它解析得又快又准。第三个技巧是给 AI 设定“角色切换”。同一个对话里你可以让 AI 先以“架构师”身份做设计再以“开发工程师”身份写代码最后以“测试工程师”身份写用例。这样比一次性让它干所有事效果更好因为每个角色的关注点不同分开执行能减少遗漏。还有一个我最近在用的技巧让 AI 在给出方案后自己扮演“挑刺者”再审查一遍。你可以说“现在请你以最挑剔的代码审查者身份找出刚才方案里的三个潜在问题”。这个方法能挖出不少 AI 自己之前忽略的边界情况。最后说一个关于成本控制的体会。AI 工具按 token 计费的话长上下文和频繁调用会很快烧钱。我的做法是把不紧急的任务攒起来批量处理而不是想到什么问什么。另外简单任务用便宜的小模型复杂任务才用大模型这样整体成本能降不少。