过去一年我几乎每天在和AI结对写代码。快是真的快代码生成速度翻了几倍但如果你像我一样拿它去改真正的生产项目大概率会经历同样的落差它给了你答案你却不敢直接上线。这也是为什么我最近把大量时间花在Superpowers这套方法上它不解决“能不能写”而是解决“写出来能不能信”。简单说Superpowers是一套提示词组织规则也是一种让AI编程从“快”走向“可靠”的工作协议。下面我会用完整的实操记录把这个方法拆开讲清楚。1. 为什么AI编程会卡在“快而不稳”1.1 快是红利可靠才是瓶颈我用AI写代码的时间不算短最初的感觉就是惊艳给它一个稍微具体点的需求几十秒后就是一整段能跑的代码。可是项目越做越复杂问题也跟着暴露。Demo阶段无所谓坏了重来就行但一旦牵扯到已有系统、数据库、历史逻辑“生成得飞快”和“生成得可信”就是两回事。我踩过最疼的一次坑是这样让AI给一个内部工具加个导出功能它马上给了一版完整实现编译通过、测试通过结果一上线发现老数据的编码格式完全不兼容线上瞬间出现一批乱码文件。原因很简单我把需求说清楚了但没告诉它“要兼容老数据”它也没打算问。那一刻我才意识到AI编程最大的风险不是写不出代码而是它对任务的假设和你的真实假设不一致。所以后来我开始研究一个方向能不能通过一套固定的提示词结构逼着AI在动手之前先讲清楚它的假设、计划、验证方式。这套东西在社区里已经有不少实践被称作Superpowers。直觉上它只是一些文字规则但实际用下来它把AI从“快速猜测器”变成了“有纪律的执行器”。1.2 Superpowers是什么它不是工具而是一套“工作协议”刚听到Superpowers这个名字我以为是某个新的IDE插件或者第三方运行环境。研究之后发现它更接近一套“工作协议”通过规范化的提示词结构把AI编程时的角色、目标、方法、输出格式、自检方式全部固定下来。我理解它的核心思想是这样通用的AI编程工具本身就像一个天赋很高但纪律一般的员工你问得越开放它发挥越飘你给它的任务边界和验收标准越清晰它越容易交付可靠的结果。Superpowers本质上就是那本“员工操作手册”。它不给AI增加任何模型能力但能让现有模型把能力稳定发挥出来。这套协议我通常会分成四个部分角色与目标告诉AI它现在是谁、要完成什么。背景与约束把项目里“不能破坏的东西”和“必须遵守的规则”写清楚。任务拆解与执行顺序要求AI先给计划再逐步实现。输出与自检规定最终交付物长什么样以及必须包含哪些验证信息。这四个部分听起来简单但在实际操作里缺一不可。只给目标AI容易自嗨只给背景AI容易保守只给约束AI容易卡死在细节里只提自检AI会自己骗自己。Superpowers把这几块拧成一个固定流程可靠性就是这么一点一点堆上去的。2. 安装与上手从零到能跑2.1 安装准备其实不需要安装很多朋友问我的第一句话永远是“Superpowers去哪里下载”。我第一次接触也这么找过后来才明白它不需要传统意义上的安装它需要的是“挂载”。目前主流AI编程工具比如Codex、Claude Code、Cursor这类基本都支持项目级指令文件或者在会话里自定义系统提示词。Superpowers的用法就是把规则放进这些通道里。我推荐两种挂载方式。第一种是会话级挂载每次开启新对话时把完整规则粘贴到第一条消息。好处是灵活我可以根据任务临时调整缺点是稍显麻烦适合刚开始试用的人。第二种是项目级挂载在项目根目录创建类似AGENTS.md或CLAUDE.md这样的指令文件把通用规则放进去。好处是对话开始时AI会自动读取不需要重复粘贴。适合已经把协议跑通、打算长期固定使用的团队。我的建议永远是先做小范围验证别一上来就把规则写进全公司的指令文件。我最初是在一个临时分支上用了三天确认稳定之后才把规则固化到项目里。2.2 第一份Superpowers提示词怎么写这里给你一个我一直在用的最小可用模板你可以直接复制去试。不要觉得它啰嗦每一段都有它存在的理由。你是资深软件工程师。请完成以下任务但必须遵守我的工作协议。 目标 在这里写清楚你要做的功能或修复的问题 项目背景 用几句话描述项目是什么、技术栈、运行环境 关键约束 1. 不要修改与本次任务无关的代码。 2. 保持现有代码风格。 3. 所有新功能必须附测试用例或验证步骤。 执行方式 先复述你对任务的理解再给出执行计划。 在你确认计划之前不要写任何实现代码。 输出格式 1. 任务理解 2. 执行计划 3. 实现代码 4. 验证方式 5. 潜在风险这个模板看起来不复杂但它做了几件普通提示词没做的事强制AI先复述任务、先给计划、最后自评风险。一旦这几步被固定AI就会从“急着给答案”切换到“先想清楚再动手”的状态。2.3 我习惯的启动顺序用这个模板我个人的启动顺序通常是这样第一轮只发“目标、项目背景、关键约束、执行方式”这几部分让它先输出任务理解和执行计划。这时我不会急着说“开始写代码”而是先看它的理解对不对。如果它理解偏了早就纠正便宜得多代码都写了再返工就亏大了。第二轮确认计划没问题之后再说“按计划实现注意遵守关键约束”。这样AI就有了明确的执行起点不会被上一轮的讨论带偏。第三轮拿到代码之后我会先把“验证方式”和“潜在风险”这两段单独抓出来看。如果它连潜在风险都写不出来说明它对代码不够了解我会继续追问“给我三个最可能出问题的边界条件”。这个顺序看着多了一步但实际能帮你省掉三四轮返工。AI生成代码的成本很低麻烦的是推进到下一轮时的上下文混乱Superpowers的价值就在于把混乱提前过滤掉。3. 核心优势拆解可靠性的四个来源3.1 上下文管理让AI“记得住、想得全”AI编程不可靠的第一个来源是上下文不够。不是模型记不住而是你没告诉它足够的“使用说明书”。我曾经让AI给一个Python脚本加进度条它很自然地用了tqdm但项目运行环境是离线内网根本装不了新依赖。模型并不知道这个限制因为我在提示词里没写。Superpowers的做法是在关键约束里强制写入“运行环境”和“已有依赖”。这不是一句空话它会直接影响AI做技术选型。你写清楚“环境无外网禁用新依赖”它就会优先考虑用标准库实现而不是推荐一个漂亮的第三方库。上下文管理不是把整个项目源码丢给AI而是把那些关键前提变成显式规则。另一个实操技巧是让AI在每次交付时附上“我做了哪些假设”。比如它实现某个功能时可能默认输入都是合法数据这时候它会把没做校验写在潜在风险里你就能在合并代码前快速判断要不要补上。上下文的本质不是信息量而是对齐。3.2 任务拆解把大任务变成小步快跑我见过很多AI编程翻车都是因为需求太大。一个需求讲出去AI为了“完成”它直接生成了几百行代码中间的逻辑根本没有机会被单独验证。Superpowers强制拆解任务本质上是把工程里的“分而治之”用在AI协作上。举个例子你让AI给你“做一个登录系统”开放式提问的结果通常是一堆堆在一起的代码但如果你按Superpowers的方式要求它先给出五个子任务设计用户表、写注册接口、写登录验证、设计会话处理、写测试用例它每一步都能单独输出、单独检查出错后也不需要整个推倒重来。这里面的心理机制也很重要AI在一个大任务里容易“创造性发挥”但在一个明确的小任务里它会倾向于保守完成。任务越细幻觉越少。我自己的经验是一个提示词里只放一个可验证的小目标可靠性提升最明显。3.3 验证闭环让AI给自己“找茬”让人工智能给自己找麻烦听起来像是天方夜谭但实际试下来效果相当好。Superpowers里有一个固定环节所有实现代码都必须附“验证方式”和“边界条件”。这个设计的目的就是逼AI从“生成者”切换到“测试者”视角。我常用的写法是这样实现完成后请列出至少三个测试场景 1. 正常情况 2. 异常输入 3. 边界条件空值、极值、并发等一旦这个要求被写进协议AI往往会主动补上很多我没想到的细节。比如自动处理空列表、检查文件不存在的情况、对超时时间做判断。这些东西如果我不要求它很可能默认“用户会正确使用”。验证闭环就是把“很可能没做”变成“必须在交付物里体现”。最让我印象深刻的是一次修并发问题。AI写完加锁代码之后按协议列出了“同一时间并发100个请求”和“锁超时”两个风险点并要求我额外确认超时时间配置。那一刻我感觉到它不再是单纯生成代码而是在和我做工程评审。3.4 错误修正不推翻重来而是“增量修复”用AI编程最浪费时间的场景是什么我投给“代码出错后让AI重写整个文件”一票。有些错误可能只差一行逻辑但模型为了照顾全貌把整个函数都改了结果新错误像葫芦娃一样往外冒。Superpowers在错误修正环节有一条重要原则固定出错的函数或文件只允许增量修改。我在提示词里会加这样一句如果实现出现错误请先分析错误原因定位到最小修改范围。 只修复导致问题的代码不要重构无关部分。这一句话能挡住很多“好心办坏事”。AI的本性是生成完整的答案但要让它可靠就必须引导它克制。每当我发现一个问题我会直接把编译错误、运行日志、甚至测试断言全部贴给它然后限定“只给我改动的diff别给我全文”。这么做之后返工次数显著下降。4. 实操过程与细节一次完整的功能改造4.1 场景设定给日志脚本加“分级过滤”纸上谈兵没意思我给你看一次我完整跑过的例子。我有一个内部Python脚本负责扫描日志文件并把异常行输出到终端。脚本很简陋没有级别过滤也没有颜色区分一直想改但手头没有大块时间。这次我打算让AI帮我来改并且用Superpowers的方式来做。原始需求就一句话“给这个日志扫描脚本增加按级别过滤和终端彩色输出。”如果用普通方式发给AI它大概率会直接给我一段带colorama的代码确实能跑但我的运行环境并没有这个依赖。所以我要在提示词里把约束说清楚。我写下的提示词是这样你是资深Python工程师。请帮我改造一个日志扫描脚本。 目标 给现有脚本增加两个能力按日志级别过滤、终端输出时对级别着色。 项目背景 这是一个命令行工具Python 3.8标准库开发不使用第三方依赖。 脚本入口是 scan.py主要逻辑是读取日志文件逐行检查 ERROR 关键字并输出。 关键约束 1. 不要引入第三方库颜色输出用 ANSI 转义序列实现。 2. 保持原有命令行参数风格新增参数用 argparse。 3. 过滤规则是可选参数默认仍然全部输出。 执行方式 先复述你的理解然后给出改造计划确认后再写实现。这里每一个约束都是我实际踩过坑才补上的。点名“不要第三方库”是因为AI特别喜欢用colorama点名“保持原有参数风格”是为了防止它顺手把入口参数改成别的结构点名“默认全部输出”是为了避免它把默认行为改成只有告警才显示真到用的时候吓人一跳。4.2 实操现场提示词怎么发、AI怎么回我把这段提示词发给AI之后它第一轮回复的是任务理解和执行计划而不是直接写代码。计划里有四步解析新参数、增加级别过滤、写ANSI着色函数、更新使用说明。看起来思路清晰但我当时还是挑了一个问题它没有提到“配置文件里的老格式日志”。因为老日志的级别字段不一定固定在第几个位置我追加了一条修正注意有些历史日志里没有级别字段默认按 INFO 处理。 请把这部分纳入你的异常处理方案。补上这一条之后它的实现代码才真正覆盖了真实场景。很多AI生成的代码看似完整其实是默认了“日志格式完美”这在真实项目里是个危险假设。之后它给出的实现包含了几个值得关注的细节首先过滤逻辑不是简单的if level in line而是用正则去匹配日志级别字段避免把“ERROR_COUNT”这种词误判成级别其次颜色输出用了\033[开头的ANSI序列并加了自动检测终端是否支持颜色的判断最后它还补了一句“如果输出不是TTY则禁用颜色”防止重定向到文件时出现一堆乱码字符。这三处细节没有一句是我明确要求的但它们都来自Superpowers里的“潜在风险”环节。它被要求思考边界条件所以主动考虑了无终端、老格式、误匹配这些问题。这就是协议起作用的地方。4.3 关键细节什么叫“可靠”的输出这次实操里AI的最终输出模块是这样的实现代码 - scan.py 新增 --level 参数 - 新增 colorize 函数支持 ERROR/WARN/INFO 三级 - 新增过滤函数基于正则提取级别 验证方式 1. 测试不带参数./scan.py demo.log 应输出全部行 2. 测试 --level ERROR只输出包含ERROR的行 3. 测试无终端重定向输出内容不包含ANSI转义码 潜在风险 - 老日志无级别字段时默认INFO - 颜色判断依赖TTY检测部分Windows终端可能显示异常这才是可验收的输出。每一段都是可操作、可验证的不是“代码在这你自己看”。当AI编程的输出从“一段代码”变成“一段带验收说明的交付物”时你才真正敢把它合并进项目里。这也是Superpowers最核心的竞争力它把模糊的代码生成变成了清晰的工程交付。5. 常见问题与排查技巧实录5.1 答非所问怎么办答非所问是AI编程里最常遇到的问题尤其是上下文很长之后。你可能上一句还在聊从配置文件读取参数下一句它就开始重构整个启动流程完全跑偏。我自己的排查逻辑是这样先检查提示词里有没有明确的目标句。没有目标句AI会默认把最近的讨论当作重点。我通常会在中间插入一句“当前任务仍然是最初定义的功能请不要扩大范围”。听起来很蠢但效果立竿见影。如果还是答非所问下一个排查点就是假设冲突。它可能觉得“用户其实想要更完整的架构”于是开始画大饼。这时候我会直接要求“先复述我的目标再告诉我你打算怎么实现”。很多时候它一复述自己就发现跑偏了。5.2 生成的代码反复报错怎么办代码反复报错最忌讳的就是把报错信息丢过去之后补一句“重写整个文件”。我试过很多次它确实能修好当前错误但常常破坏了别的正常功能然后进入“修A坏B、修B坏A”的循环。改法很简单要求它先定位再修改。我会在提示词里写请先根据报错信息分析原因指出具体文件和函数。 确认定位无误后只给出需要修改的代码片段不要输出整个文件。这样即时代码还是报错每一步的变更范围都很小我一眼就看到它动了哪里。另外给报错信息时最好带上完整堆栈和运行环境描述不然AI只能瞎猜。5.3 上下文被冲掉怎么办AI编程聊到后面经常会出现一种“失忆”感前面刚定的技术方案后面它就忘了。这不是模型真的失忆而是上下文窗口被大量无关内容挤占。对话越长早期信息被稀释得越厉害。Superpowers的应对方式是做“进度快照”。我会在任务比较长的时候要求AI在每一步完成之后输出一行摘要存成一个说明文件比如当前进度 - 已完成参数解析 - 已完成过滤函数 - 待处理输出着色、测试用例当下一次对话从摘要恢复时相当于把散落的上下文重新压缩成一份结构化笔记。这个方法比试图让AI记住所有细节靠谱得多。我甚至会在切换子任务时把当前进度快照复制到新对话的第一条消息里效果很好。5.4 避坑清单速查表坑典型现象对策需求写得太宽泛AI超范围重构用“目标约束”固定边界没写关键技术栈限制引入不必要依赖明确“仅标准库”或“已有依赖”没有验证要求只给代码不给测试要求附验证方式和边界条件报错后直接重写全文件修一个坏一个限定最小修改范围讨论过多导致上下文丢失AI忘记早期决策定时输出进度快照无条件信任AI输出合并后线上翻车每次合并前必须看diff这张表基本覆盖了我从开始用AI编程到现在踩过的七八成问题。每次模型能力升级问题表现形式会变但这些底层逻辑一直很稳约束不够AI就自由发挥验证不够AI就盲目自信上下文不清AI就左右摇摆。6. 让“可靠”成为习惯我用Superpowers这套方法前后也有几个月了最大的体会是它并没有让我少写代码但确实让我省下了大量“以为写完其实没写完”的时间。以前我总觉得AI编程是个效率工具现在更愿意把它看作一个需要管理协作的搭档。给它清晰的边界、验证步骤和上下文它就能稳定输出不给这些它就给你表演“自信的猜测”。如果你想试试我不建议一上来就背一整本规则。先从最简模板开始跑一个小任务把“目标、约束、执行方式、输出格式”这四个要素写清楚然后用三次任务做对比看交付质量的变化。等你习惯了这种对话结构再逐渐加入风险自检、进度快照、增量修复这些进阶手段。最后分享一个我自己的习惯我的一份完整Superpowers规则最终会被保存成项目根目录的AGENTS.md但最开始它只是我备忘录里的一段文字。每当我遇到新的失败模式就往那段文字里加一条规则。慢慢地它从两行变成了两页我的AI编程交付质量也随着这一页页规则变得靠谱起来。别指望AI一次就给你完美答案但一套好协议能让它每次都给出可检验的答案。