ARTICLE · 1234478
AI 编程助手总在重复提问?Superpowers v7.0.1 换了套问法
上下文 · 追问 · 压缩截断 · 技能分层 · obra/superpowers v7.0.1 —— 这一版没有加新功能， 修的是流程里的两处漏水点：提问前先读项目，长技能在上下文压缩后不再丢尾巴。
给编码代理装一套流程
Superpowers 不是库，也不是模型。它是一套装在编码代理身上的开发流程： 15 个可组合的 skill，加上一段在会话开始时把 skill 拉进上下文的引导指令。
装好之后，代理不会直接写代码。它先做 brainstorming，把需求问清楚； 再写实现计划；然后按任务派发子代理执行、逐个评审；最后走收尾分支的流程。
这套东西的价值不在某个 skill 写得多聪明，而在于它把「先想清楚再做」 变成了代理的默认动作。规则不是提示词里的一句嘱咐，而是可以被调用、 被检查、被测试的文档与脚本。
skill 靠 description 决定什么时候被触发，description 写的是触发条件， 不是流程摘要。这也是为什么改一句描述能影响整个流程的入口。
仓库以 Shell 和 Markdown 为主，通过插件市场分发。Claude Code、Codex、Cursor、 Gemini CLI、Copilot CLI 等 16 种运行环境各有安装路径，安装命令的差异写在 README 里。 项目拿到 30.3 万 star、2.7 万 fork，说明「给代理立规矩」这件事有大量真实需求。
这份兼容性来自很薄的一层适配：每个环境一份插件清单，skill 本身是通用的 Markdown， 真正的差异只在引导指令怎么被加载。也正因为它寄生在别人的运行时里， 宿主的行为变化会直接改变它的效果，上下文压缩就是其中之一。
v7.0.0 在 2026 年 10 月 10 日重写了 brainstorming，v7.0.1 在 10 月 21 日回头修补它。 两版之间隔了十一天，修的都是重写后暴露出来的行为问题。
两个被放大的小毛病
第一个毛病是提问像模板。
v7.0.0 的 brainstorming 每次开场都一样：先给一个「要不要跳过提问」的选项， 再问一句「你什么时候最希望这个东西存在」。用户已经在需求里写清楚要做什么， 它还是照念。发布说明没有回避这一点：很多人反馈新的默认问题很快就让人烦， 而且感觉很公式化。
模板化提问的成本不只是多打几个字。用户为了绕开它，会学着在开场就写一大段背景， 代理仍然照念，双方各多做一轮无用功。更麻烦的是，用户很难判断这是版本问题， 还是自己没表达清楚。
第二个毛病是设计文档被跳过。
流程要求先摆出两三种实现路径，让用户选，再写设计文档，批准之后才能动工。 但在一个测试场景里，改动前的 24 次运行有 24 次没写文档就直接开工； 改动后降到 3 次。也就是说，规则写在文档里，执行时仍会被绕过。
第三个问题不在提问，在长度。
Claude Code 做上下文压缩后重新挂载 skill 时，每个 skill 只保留前 20,000 个字符， 后面的内容在整个会话里等于不存在。subagent-driven-development 的五轮修复上限 写在文档靠后的位置，一次真实会话在压缩后丢掉了它，于是一个任务跑了 18 轮修复。
规则还躺在仓库里，只是已经不在模型的上下文里。这类失效最难查：文件没删、 版本没退，行为却悄悄变了。它不会报错，也不会留下日志， 只表现为代理忽然不听流程的话。
提问和加载都换了做法
brainstorming 的变化可以按四步看。
• 先读再问：项目里已有代码，或用户指明了规格、计划、文件，它先读这些内容， 第一条消息不再问项目本身已经回答的问题。
• 先复述再追问：用户已经说清想要的，它用大约 200 字把请求复述一遍， 附上在项目里读到的事实，然后只问一个真正还没定的问题。后续问题建立在 之前的回答和读到的代码上，并说明答案会改变什么。
• 跳过选项收窄：只有它自己判断该做 brainstorming 时才提供「跳过提问」。
用户点名要 brainstorming，或用 /brainstorming 调用，它不再问要不要跳过。
• 先方案后文档：摆出两三种做法、各自权衡，推荐一种，等用户选定； 然后写设计文档，小改动写短的，大项目写完整的；文档批准前不写产品代码。
技能体量方面的改动更偏工程。
• subagent-driven-development 把修复循环、最终评审、报告处理、恢复、预检、
批处理、无法验证的指导拆进 references/ 下的七个文件，正文只留主流程
和「什么时候去读哪个文件」。拆出去的不是边角料：修复循环里写着五轮上限，
前三轮恢复原实现者，后两轮换更强的模型和新上下文；最终评审负责整条分支的收口。
• writing-skills 把 SKILL.md 模板、发现优化、防弹化、流程图约定移进 references/，
正文新增二十几行、删除三百行。
• executing-plans 删掉了一段示例流程，因为它重复了上文已经说过的规则。
• 新增 tests/skill-size/test-skill-size.sh：任何一个 SKILL.md 达到 20,000 字节，
测试直接失败。
贡献流程也一起收了紧。issue 和 PR 模板现在要求填写「谁在提交」和一段 200 字以内、由人写的摘要；bug 报告还要说明如何确认问题在没有安装 Superpowers 时不会出现。修复别人 issue 的代理生成 PR，除非维护者明确要求，否则不收。 diagnosing-superpowers 生成的 issue 草稿也加了同样两节，摘要是占位符时它拒绝提交。
让规则活在调用点上
这些改动背后是同一个思路：不要把所有规则一次性塞进上下文， 而是把规则放在真正需要它的那一步。
skill 正文只保留「每次都用得上」的判断逻辑，细节放进 references/，
由代理在执行到对应步骤时从磁盘读取。压缩只会截断已挂载的正文，
读文件这个动作发生在截断之后，拿到的永远是新内容。
旧做法是把所有边界条件写进一份长文档，靠一次加载全部记住。文档越长， 越依赖模型的注意力；注意力在压缩后会打折。新做法把记忆外包给磁盘， 模型只需要记住一件事：什么时候该去读哪个文件。
这样还有两个副作用。正文短了，代理在长会话里更不容易忘记主流程； 细节文件按需读取，也不会在无关任务里占上下文。技能的边界因此从 「文件有多长」变成了「这一步需不需要它」。
提问的改法遵循同样的逻辑。先读项目，是因为答案已经在代码和文档里， 再问一遍只是把检索成本转嫁给用户。复述请求，是给用户一次低成本纠错的机会， 避免在错误理解上继续追问。一条消息只问一个问题，是因为选项会引导答案， 而用户自己组织的语言能带出选项覆盖不到的意图。
最关键的是顺序：先摆方案，再写文档，最后等批准。
方案阶段解决「怎么做」，文档阶段固化「做什么」，批准是一道硬门槛。 三道分开，代理就没法用「我以为你同意了」绕过设计评审。 发布说明里的 24 次对 3 次，就是这个门槛从装饰变成约束的证据。
v7.0.1 是一次典型的维护版本：没有新入口，没有新概念， 只是把上一版暴露的行为偏差收回来，再把长文档改造成能扛住压缩的形态。 对每天让代理跑长任务的用户来说，这种改动比多一个功能更实际。
