【AI提效】产品经理10 分钟装上 Superpowers:做这三件事,用七步工作流让 编码更靠谱

SKILL.md，让模型先对号入座技能、再动手。下文对 README 里的默认工作流、技能库与协作哲学做了压缩整理，方便你快速上手。

“

读完你能：装好插件 → 跑通验证提示词 → 用两则案例话术在真实任务里试一轮。

背景 / 问题是什么

• 场景：日常在 Cursor 里让 Agent 改需求、动老代码、跟生产问题；团队里有人习惯先想清楚再写，有人习惯「先改再说」。
• 痛点：大模型不是不会写，而是过程不可控——需求还在聊天里飘，模型已经开始打补丁；修 Bug 靠猜，改一处坏一处；计划书写得像样，执行时却跳过验证就宣称「完成了」。
• 目标：把成熟工程实践拆成可版本、可更新、可共享的技能包，让助手在会话里默认走对流程；你仍然掌握业务判断与安全边界。

核心结论

1. 核心区别：Superpowers 不是又一个「提示词合集」——工程习惯写在 SKILL.md 里；using-superpowers 要求先判断有没有命中技能，再回复与改代码。
2. 它最适合治的病：过程不可控（返工、无验收的「完成」、排障无章）；治不了：业务对错、模型能力上限、公司制度之外的事。
3. 在 Cursor 里：以插件市场安装为主，与 Agent 对话配合最好。
4. 和你仓库里的 AGENTS.md 不冲突：用户与项目规则优先；Superpowers 补通用工程纪律，二者应叠加。
5. 入门路径：安装 → 30 秒验证提示词 → 案例 A / 案例 B 各练一遍。

方案概览 - 七步工作流

官方默认工作流

1. brainstorming：动代码前先澄清需求，分段呈现设计稿，保存设计文档。
2. using-git-worktrees：设计通过后，在新分支上隔离工作区，跑通项目初始化与干净测试基线。
3. writing-plans：把已批准设计拆成 2～5 分钟粒度任务，每步含路径、改法、如何验收。
4. subagent-driven-development 或 executing-plans：按计划执行——要么每任务派生子代理并做规格符合 + 代码质量两阶段评审，要么分批执行并保留人类检查点。
5. test-driven-development：红 → 绿 → 重构；先写失败测试，再写最小实现；删除测试之前写的实现代码。
6. requesting-code-review：任务之间对照计划做评审，Critical 级问题阻断后续进度。
7. finishing-a-development-branch：收尾时跑测试、给出合并 / PR / 保留 / 丢弃等选项，并清理 worktree。

“

一句话：Agent 在动手前就会检查是否命中技能；命中则按技能执行——这是流程被钉死的关键。

Superpowers 协作哲学

• 头脑风暴：先确定清楚需求，落地到spec文档，再进行编码。

• TDD测试驱动：能自动验证的才算「真完成」。

• 系统化优先：用流程降低「边聊边改」的随机性。

• 证据优先：先验证、再下结论；与排障、收尾类技能同一逻辑。

按类型速记（辅助记忆）

与「一次性提示词」的本质区别

关键概念（给非全栈读者）

实践步骤 - 安装 Superpowers

1. 环境与前置条件

• 系统：macOS / Windows / Linux 均可，使用 Cursor 当前最新稳定版。
• 账号：能登录 Cursor；公司设备需确认允许安装市场插件。
• 能力：能打开 Agent 对话（入口与快捷键以你客户端说明为准）。

2. 最小可运行示例

安装（在 Agent 中输入，择一；以你版本自动补全为准）

/add-plugin superpowers

或：

/plugin-add superpowers

若斜杠命令不一致：打开 Cursor → 插件市场，搜索 superpowers，按界面引导安装。各平台差异见 GitHub README。

装完后的「30 秒验证提示词」（建议原样复制）

请说明：在 Superpowers 已正确加载时，你在「开始改代码之前」会检查哪些技能可能被触发？请至少举出 2 个具体技能名，并说明什么任务应先走 brainstorming。

期望现象：回答里出现 brainstorming、writing-plans、test-driven-development、systematic-debugging 等具体标识，而不是泛泛的「我会先分析需求」。

案例 A：接口「偶尔 500」——用排障流程代替「猜改」

场景：/api/orders 在生产大约 1% 请求返回 500，本地难复现。

不推荐这样对 Agent 说（容易进入乱改模式）：

“

「帮我把这个接口修一下，可能是数据库超时。」

推荐说法（显式点名技能，约束在取证与假设阶段）：

“

「按 systematic-debugging 的流程来：先列出可观测证据（日志字段、trace id、状态码分布），再区分确定性错误还是竞态/超时；在我同意前不要改业务逻辑，只给出最小复现实验与下一步要采集的数据。」

你在本机可做的最小实操：打开 Agent，用上面约束跑一轮；贴一条请求 ID 与脱敏后的相关日志片段；要求输出假设列表 → 如何证伪 → 最小验证命令，而不是直接给大段 patch。

案例 B：加一个「小功能」——从头脑风暴到可验证计划

场景：用户设置页增加「导出个人数据为 JSON」（含权限与审计）。

第一轮（对齐范围，避免做错需求）：

“

「在写任何代码之前，按 brainstorming 向我提问：数据范围、合规边界、文件大小上限、异步导出还是同步、错误提示与重试策略。」

第二轮（产出可执行计划，而不是散文）：

“

「基于上面共识，用 writing-plans 输出实施计划：按 Task 拆分，每个 Task 带验收标准与预计涉及的模块/目录。」

第三轮（再进入实现；若团队推行 TDD，可追加）：

“

「实现时遵循 test-driven-development：先写会失败的测试（RED），再写最小实现（GREEN），最后小步重构（REFACTOR）。」

亲测：实际没这么复杂——第一步用 brainstorming 之后，跟着 Superpowers 的指引，即可完成从头脑风暴、specs 编写、计划编写、代码开发、TDD 测试的工作流全过程。

踩坑与注意事项

“

注意：最容易翻车的点单独强调。

• 把 Superpowers 当成「自动写对」：它管流程，不管你的业务判断与安全审批。
• 命令抄错版本：斜杠前缀会随 Cursor 迭代变化，以界面自动补全为准。
• 团队只装不用：需要有人在真实 PR 里带头跑通「案例 B」式拆任务，否则停留在「装了」状态。
• 诚实边界：流程对了，仍可能受模型能力、上下文长度、工具权限限制；不是银弹。

总结

• 回顾：Superpowers 用 Agent 可加载的 Skill 把 README 里的工作流钉进对话，核心是先匹配技能、再执行任务。
• 亮点：brainstorming 先把需求聊清楚、test-driven-development 保障开发质量。
• 行动建议：今天只做三件事——装好插件 → 跑通验证提示词 → 用案例 A 或 B 各练一轮。
• 延伸阅读
• Superpowers GitHub 仓库：https://github.com/obra/superpowers
• Cursor 插件市场（Superpowers）：https://cursor.com/marketplace/superpowers
• Cursor 安装说明（Mintlify）：https://www.mintlify.com/obra/superpowers/installation/cursor
• Cursor 官方文档：https://cursor.com/docs
• Superpowers 讨论区：https://github.com/obra/superpowers/issues