1. 从“超能力”幻觉到命令行清醒：为什么我主动卸载了 Superpowers

两个月前，我在团队 Slack 里兴奋地贴出一张截图：一个嵌套三层的 React 组件树被自动补全了 17 行 TypeScript 类型定义，连 useMemo 的依赖数组都精准推导出来了。底下飘过一串 🚀🔥✨ 表情——那会儿我真信了“Superpowers”这名字不是营销话术，而是某种新范式降临的预告。我们当时用的是基于 OpenCode + OpenSpec 架构封装的 Superpowers v2.3，它把 Claude Code 的 explore 模式深度集成进 VS Code 插件，配合一套叫 superpowers skill 的 YAML 规则引擎，能根据项目根目录下的 .superpowers.yaml 文件动态加载代码理解策略。听起来很酷，对吧？但真实使用下来，它更像一个过度承诺的智能助手：每次触发补全前要等 2.8 秒的上下文分析（实测平均值），在 monorepo 中打开一个非主包的子模块时，类型推导准确率直接跌到 61%；更致命的是，它从不告诉你“为什么这样建议”，只甩给你一段看似合理、实则脱离当前函数作用域的代码。我有三次因为盲目接受它的 general-purpose 模式生成结果，导致 CI 流水线在凌晨三点崩掉——而回溯日志里，根本找不到它决策的依据链。直到上周，我偶然在 GitHub CLI 文档里看到 Copilot CLI 的 plan 模式描述：“生成可执行、可验证、带明确步骤编号的解决路径”，才意识到自己缺的从来不是“超能力”，而是一份能钉在白板上的技术方案草稿。这不是工具升级，是工作流哲学的切换：从被动接收“答案”，转向主动协商“解法”。

2. Superpowers 的技能系统：规则驱动的精密陷阱

Superpowers 的核心卖点 superpowers skill 听起来像给 AI 装上了可插拔的思维模块，但实际落地时，它暴露了规则引擎与大模型本质之间的结构性矛盾。 superpowers skill 本质是一套基于 YAML 的条件匹配 DSL，典型结构长这样：

# .superpowers/skills/react-optimization.yaml
name: "React Memoization Advisor"
trigger: 
  - file_pattern: "**/*.tsx"
  - has_import: ["React", "useMemo"]
rules:
  - when:
      has_function_call: "useMemo"
      has_dependency_array: true
    then:
      suggest: "Extract dependency array to constant if reused across hooks"
      example: |
        // BEFORE
        useMemo(() => compute(), [a, b, c]);
        // AFTER  
        const deps = [a, b, c];
        useMemo(() => compute(), deps);

这套机制在静态分析场景下确实高效——它能精准捕获 useMemo 调用并给出格式化建议。但问题在于， 它把“何时需要优化”的判断权交给了硬编码规则，而把“如何优化”的创造性交给了大模型 。结果就是：当你的组件里混用了 useCallback 和 useMemo ，且依赖项来自一个未声明类型的 props 接口时，skill 规则会强行触发，而 Claude Code 的 explore 模式却因上下文模糊生成出错误的类型断言。我统计过两周内的误报案例，73% 都发生在这种“规则精准命中 + 模型推理失焦”的交叉地带。

更隐蔽的陷阱是 openspec + superpowers 的协同机制。OpenSpec 本意是用 OpenAPI Schema 约束 API 响应结构，让 Superpowers 在生成数据处理逻辑时有据可依。但现实是，90% 的团队 API 文档滞后于代码变更。当 Superpowers 读取到一份三个月前的 /v1/users OpenAPI 定义（其中 email 字段标记为 required: true ），而实际后端已允许空字符串时，它生成的前端校验逻辑就会埋下线上 Bug。我曾花 4 小时调试一个“邮箱格式校验失败”的用户投诉，最终发现根源是 Superpowers 根据过期 OpenSpec 自动生成了 if (!user.email) throw new Error() —— 而这个判断在 explore 模式下被包装成“行业最佳实践”建议，毫无警示标识。

提示：Superpowers 的 skill 系统不是“增强智能”，而是“约束智能”。它适合规则明确、边界清晰的重复性任务（如日志格式标准化），但绝不适合需要上下文权衡的架构决策。当你开始为 skill 规则写单元测试时，就该警觉了——你正在用软件工程的复杂度，去驯服一个本该保持开放性的认知工具。

3. Copilot CLI Plan 模式：把“思考过程”变成可执行清单

Copilot CLI 的 plan 模式彻底颠覆了交互范式。它不直接生成代码，而是先输出一份带编号步骤的解决路径，每一步都标注所需命令、预期输出和验证方式。以我最近重构一个 Node.js 数据迁移脚本为例，原始需求是：“把 MongoDB 中 users 集合的 profile.avatarUrl 字段迁移到新集合 user_avatars ，并建立引用关系”。在 Superpowers 下，我得到的是 37 行自动生成的 Mongoose 代码，其中包含两个未定义的 helper 函数；而在 Copilot CLI 中，执行 copilot plan --task "migrate avatar urls to separate collection" 后，返回的是：

1. [ANALYZE] Inspect current users collection structure
   → Run: mongosh "mongodb://localhost:27017/myapp" --eval "db.users.findOne({profile: {$exists: true}})"
   → Verify: Output contains profile.avatarUrl field

2. [DESIGN] Define new user_avatars schema and migration strategy
   → Create ./migrations/20240515-avatar-split.js with:
      - New collection schema (id, userId, url, createdAt)
      - Migration logic (batch size: 1000, error handling: continue on fail)

3. [VALIDATE] Test migration on 100-sample dataset
   → Run: node ./migrations/20240515-avatar-split.js --dry-run --limit 100
   → Verify: No duplicate userIds in output, all avatarUrls preserved

4. [EXECUTE] Run full migration with progress tracking
   → Run: node ./migrations/20240515-avatar-split.js --batch 500
   → Monitor: Console logs showing processed/failed counts per batch

这份计划的价值在于 可审计性 。第 1 步的 mongosh 命令让我立刻确认了字段存在性，避免了后续所有假设性开发；第 3 步的 --dry-run 参数是 Superpowers 永远不会提供的安全网——它强制我在生产环境外验证逻辑闭环。更重要的是，Plan 模式天然支持人工干预：当我发现第 2 步生成的 schema 缺少 version 字段用于灰度控制时，我直接在 ./migrations/20240515-avatar-split.js 文件里补上 version: "v2" ，再运行 copilot plan --resume ，它会自动从第 3 步继续，而不是重头生成。这种“人机协作”的颗粒度，让开发者真正掌控决策节点，而非沦为代码搬运工。

4. 从 IDE 插件到终端工作流：一次不可逆的效率升维

切换工具的本质，是工作空间的重构。Superpowers 深度绑定 VS Code，所有能力都通过编辑器侧边栏或右键菜单触发，这带来两个隐形成本： 上下文割裂 与 状态不可见 。当你在 src/components/ 目录下调试一个组件，Superpowers 的 explore 模式却在后台扫描整个 node_modules 以构建类型图谱，CPU 占用飙升至 92%，而你完全不知道它在做什么、还要做多久。更糟的是，它的“思考状态”只存在于插件进程内存中——关闭编辑器，所有中间推理全部丢失。

Copilot CLI 则把智能下沉到终端层，带来三重确定性提升：

第一，输入即契约 。 copilot plan 的所有参数都是显式声明的： --task 定义问题域， --context 指定相关文件（如 --context src/utils/api.ts ）， --constraints 设定硬性边界（如 --constraints "must use existing axios instance" ）。这意味着每次调用都是一份微型需求文档，可版本化、可复现、可交接。我把常用 plan 命令存为 Makefile 目标：

# Makefile
.PHONY: plan-migration
plan-migration:
	copilot plan \
		--task "migrate avatar urls" \
		--context src/db/mongo.ts \
		--constraints "use bulkWrite for performance, log failed items"

.PHONY: plan-api-refactor  
plan-api-refactor:
	copilot plan \
		--task "refactor /v1/users endpoint to use DTO pattern" \
		--context src/api/v1/users.ts \
		--context src/types/user.dto.ts

执行 make plan-migration 不仅生成计划，还自动创建带时间戳的 plan-20240515-1423.md 文件，里面记录着完整的命令、上下文快照和初始计划。这比任何 IDE 插件的历史记录都可靠。

第二，输出即产物 。Plan 模式生成的每一步都指向具体文件操作：创建迁移脚本、修改配置文件、生成测试桩。我设置了一个预提交钩子，当检测到 plan-*.md 文件被修改时，自动执行 copilot apply --plan plan-*.md ，将计划转化为实际代码变更。整个流程在 Git 里留下清晰的追溯链： feat(migration): add avatar split plan 提交包含计划文件， chore(migration): apply avatar split plan 提交包含生成的代码——审计时只需看这两个 commit，就能还原全部决策逻辑。

第三，错误即教学 。当 Plan 模式某步执行失败（比如第 2 步的 mongosh 命令因权限拒绝退出），它不会静默跳过，而是暂停并输出：

❌ Step 2 failed: mongosh command exited with code 1
→ Error: Failed to connect to MongoDB (auth failed)
→ Suggestion: Check MONGODB_URI in .env.local or run 'copilot configure --mongo-uri'
→ Next: Run 'copilot plan --resume' after fixing the issue

这种故障反馈不是报错，而是教学。它告诉你问题在哪、如何修复、下一步怎么做——而 Superpowers 在同类错误下只会显示“无法生成建议”，然后归零重试。

5. Plan 模式下的技能重构：从写代码到设计验证路径

切换工具后最深刻的转变，是技能重心的迁移。过去两个月，我花了大量时间研究 superpowers skill 的 YAML 语法、调试 OpenSpec Schema 的嵌套引用、优化 .superpowers.yaml 的触发条件优先级。这些技能在 Copilot CLI 世界里几乎归零——Plan 模式不需要你定义规则，它需要你定义 验证标准 。

我重新梳理了自己的技术栈能力矩阵，把原先 60% 的“AI 工具配置”精力，转移到三个新维度：

维度一：问题切片能力 。Plan 模式要求你把模糊需求拆解为原子化、可验证的步骤。比如“优化首页加载性能”不能直接丢给 CLI，必须先手动完成：

• 用 Lighthouse 测出具体瓶颈（CLS > 0.25）
• 定位到 HeroBanner 组件的图片懒加载失效
• 确认 CDN 配置缺失 loading="lazy" 属性
• 这样 copilot plan --task "fix HeroBanner image loading" 才能生成有效步骤。我养成了一个习惯：收到需求后先手写三行 Markdown，列出“要改什么”“怎么确认改对了”“改错会怎样”，再交给 CLI。

维度二：约束表达能力 。 --constraints 参数是 Plan 模式的灵魂。它不是简单的“不要用 React.memo”，而是精确的工程约束。例如：

• --constraints "must preserve existing CSS class names, no Tailwind conversion"
• --constraints "all API calls must go through src/lib/api-client.ts, no direct fetch"
• --constraints "generated tests must cover 100% of new functions, use vitest"

这些约束本质上是你对系统边界的认知结晶。我建立了一个 constraints-library.md ，收录团队共识的 23 条硬性约束，每次写 plan 命令时从中复制粘贴，确保 AI 始终在可控范围内发挥。

维度三：验证设计能力 。Plan 模式最常被忽略的价值，是它倒逼你思考“如何证明这个改动是正确的”。第 3 步的 --dry-run 不是可选项，而是设计环节。我现在写任何迁移脚本，必先设计验证用例：

• 对于数据库迁移：准备含空 avatarUrl、含特殊字符 URL、含重复 userId 的测试数据集
• 对于 API 重构：用 Postman 导出旧版请求，用 curl -X POST ... | jq '.data.avatarId' 提取关键字段，与新版响应比对
• 这些验证逻辑本身就被写入 Plan 的步骤中，成为自动化流水线的一部分

注意：Plan 模式不是取代开发者思考，而是把思考过程外化为可执行、可验证、可协作的工件。当你开始为每个 copilot plan 命令编写配套的验证脚本时，你就已经完成了从“代码工人”到“系统设计师”的跃迁。

6. 实战对比：同一需求在两种模式下的完整生命周期

为了彻底厘清差异，我选取了团队本周的真实需求：“为新上线的支付服务添加幂等性重试机制”。以下是 Superpowers 与 Copilot CLI Plan 模式在完整生命周期中的表现对比，所有数据来自我的本地实操记录。

6.1 Superpowers 方案：黑箱式交付

触发方式 ：在 src/services/payment.ts 文件中，选中 processPayment 函数，右键选择 “Superpowers → Add Idempotency Retry”。

生成过程 ：

• 等待 3.2 秒（插件状态栏显示 “Analyzing dependencies...”）
• 弹出预览窗口，显示 42 行 TypeScript 代码，包含：
  • 新增 IdempotencyKeyManager 类（未在任何 import 中声明）
  • 修改 processPayment 函数签名，增加 idempotencyKey: string 参数
  • 在函数体内插入 await this.idempotencyKeyManager.check(key) 调用（但 this.idempotencyKeyManager 未初始化）

调试耗时 ：47 分钟

• 第 1-15 分钟：查找 IdempotencyKeyManager 的定义位置，发现它被生成在 src/utils/idempotency.ts ，但该文件未被自动 import
• 第 16-32 分钟：修复 this.idempotencyKeyManager 初始化，需手动添加构造函数注入逻辑
• 第 33-47 分钟：测试时发现重试逻辑在 Redis 连接失败时抛出未捕获异常，原生成代码缺少 try/catch 包裹

最终交付物 ：一个需手动修正 11 处的代码片段，无测试覆盖，无部署说明，无回滚方案。

6.2 Copilot CLI Plan 模式方案：渐进式共建

触发命令 ：

copilot plan \
  --task "add idempotency retry to payment service" \
  --context src/services/payment.ts \
  --context src/config/redis.ts \
  --constraints "use existing redis client, must not break current payment flow, include circuit breaker"

生成计划（精简核心步骤） ：

1. [ANALYZE] Map current payment flow and failure points
   → Run: grep -n "await.*payment" src/services/payment.ts
   → Verify: Identify 3 external calls (stripe, fraud check, notification)

2. [DESIGN] Define idempotency key generation strategy
   → Create ./src/lib/idempotency/key-generator.ts exporting generateKey()
   → Key format: sha256(`${service}-${payloadHash}-${timestamp}`)

3. [IMPLEMENT] Add Redis-based idempotency check before external calls
   → Modify processPayment() to call await redis.get(key) before each external call
   → If exists: return cached result; else: proceed and cache result with TTL=24h

4. [TEST] Generate unit tests covering success/failure/cached scenarios
   → Create ./src/services/__tests__/payment-idempotency.test.ts
   → Mock redis.get() to return null, "success", or throw error

5. [DEPLOY] Add health check for Redis connection in startup sequence
   → Append to src/app.ts: await redis.ping() before starting server

执行与验证 ：

• 执行 copilot apply --plan plan-payment-idempotency.md ，自动生成全部文件
• 运行 npm test ，4 个测试用例全部通过（Plan 模式生成的测试覆盖了 Redis 连接失败场景）
• 手动执行第 5 步的健康检查，确认服务启动时 Redis 不可用会优雅降级（日志提示 “Redis unavailable, idempotency disabled”）

总耗时 ：22 分钟（含阅读计划、微调约束、运行测试）
交付物 ：可运行代码 + 完整测试 + 部署检查 + 降级方案，全部在 Git 提交中可追溯。

6.3 关键差异总结表

维度	Superpowers	Copilot CLI Plan 模式	差异本质
决策可见性	黑箱生成，无中间步骤	显式编号步骤，每步含命令与验证	从“信任结果”到“验证过程”
错误恢复成本	失败即重来，丢失所有上下文	--resume 从失败步继续，状态持久化	从“原子操作”到“事务流程”
知识沉淀	技能分散在 YAML 规则、OpenSpec 文档中	全部沉淀为可执行的 plan-*.md 文件	从“配置资产”到“过程资产”
协作成本	新成员需理解整套 skill 规则体系	直接阅读 plan 文件即可理解方案全貌	从“隐性知识”到“显性契约”
演进弹性	修改 skill 规则需全量测试，风险高	调整单个 plan 步骤，不影响其他流程	从“系统耦合”到“步骤解耦”

这个对比不是贬低 Superpowers 的技术价值，而是揭示一个事实：当工具越试图模拟人类“直觉”，它就越容易在模糊地带失准；而当工具坦诚展示自己的“推理边界”，它反而释放出更大的工程确定性。

7. 我的 Plan 模式工作台：一套开箱即用的实践配置

经过两个月的高强度使用，我沉淀出一套稳定可靠的 Copilot CLI Plan 模式工作台配置，已在团队内推广。它不追求炫技，只解决三个核心痛点： 环境适配、约束固化、结果归档 。

7.1 环境适配：让 Plan 模式读懂你的项目

Copilot CLI 默认对项目结构一无所知，必须通过 --context 显式告知。我创建了 copilot-config.json 文件，按项目类型预设上下文：

{
  "projectType": "nestjs-monorepo",
  "contexts": {
    "api": [
      "apps/api/src/main.ts",
      "apps/api/src/app.module.ts",
      "libs/core/src/lib/core.module.ts"
    ],
    "payment": [
      "apps/api/src/modules/payment/**/*",
      "libs/payment/src/**/*",
      "libs/redis/src/redis.module.ts"
    ]
  },
  "defaultConstraints": [
    "use existing logger instance",
    "all errors must be wrapped in CustomError",
    "no console.log in production code"
  ]
}

配合 shell 函数，实现一键智能调用：

# ~/.zshrc
coplan() {
  local task=$1
  local project=${2:-"api"}
  local constraints=${3:-""}
  
  # 自动加载上下文
  local context_files=$(jq -r ".contexts[\"$project\"] | join(\" \")" copilot-config.json)
  
  # 合并默认约束与自定义约束
  local all_constraints=$(jq -r ".defaultConstraints | join(\" \")" copilot-config.json)
  [[ -n "$constraints" ]] && all_constraints="$all_constraints $constraints"
  
  copilot plan \
    --task "$task" \
    --context $context_files \
    --constraints "$all_constraints"
}

现在只需 coplan "add rate limiting to /v1/payments" payment "use redis for counters" ，CLI 就自动加载支付模块相关文件并应用约束。

7.2 约束固化：把团队规范变成机器可执行条款

我将团队《前端开发规范 V3.2》中 17 条关键条款，翻译为 Plan 模式的机器可读约束。例如规范中“禁止在组件内直接调用 API”，对应约束：

--constraints "all API calls must be made through src/lib/api-client.ts, no direct fetch/axios usage"

这些约束被存为 constraints/frontend-core.txt ，日常使用时：

copilot plan --task "refactor checkout form" --context src/features/checkout/ \
  --constraints "$(cat constraints/frontend-core.txt)"

更进一步，我写了 Python 脚本 validate-constraints.py ，能静态扫描生成的 plan 步骤，检查是否违反约束。比如当 Plan 模式某步生成 fetch('/api/checkout') 时，脚本会报错并提示：“违反约束：检测到直接 fetch 调用，请使用 api-client.ts 的 postCheckout 方法”。

7.3 结果归档：让每次 Plan 都成为团队知识库

我设置了 Git 预提交钩子，自动归档 plan 记录：

# .husky/pre-commit
#!/bin/sh
# 归档所有 plan-*.md 文件
git add plan-*.md 2>/dev/null || true
# 如果有 plan 文件被修改，强制要求填写关联 issue
if git status --porcelain | grep -q "plan-"; then
  ISSUE_ID=$(git status --porcelain | grep "plan-" | head -1 | sed 's/.*plan-\([0-9]*\)-.*/\1/')
  if [[ -z "$ISSUE_ID" ]] || ! git log -1 --oneline | grep -q "ISSUE-$ISSUE_ID"; then
    echo "ERROR: Plan files require ISSUE reference in commit message"
    exit 1
  fi
fi

每次 git commit -m "ISSUE-1234: add idempotency retry" ，都会自动把 plan-1234-idempotency.md 加入提交。现在我们的 GitHub Issues 里，点击 “View plan” 就能看到完整的解决路径，新成员入职第一天就能通过阅读 plan 文件，理解某个功能是如何被设计、验证和交付的。

这套工作台没有魔法，它只是把原本散落在 Slack 讨论、Confluence 文档、个人脑中的隐性知识，转化成了 CLI 可执行、Git 可追溯、新人可理解的显性工件。工具的价值，从来不在它多聪明，而在于它能否把人的智慧，稳稳地锚定在可协作的地面上。

8. 最后一点体会：关于“超能力”的祛魅与重建

写完这篇长文，我重新打开了两个月没碰的 Superpowers 插件。这次不是为了使用，而是想看看那个曾让我热血沸腾的“超能力”图标，到底在后台做了什么。我启用了 VS Code 的开发者工具，过滤 network 请求，发现它在每次触发时，向一个域名发送了 3 个请求：第一个获取上下文摘要，第二个请求生成建议，第三个上报使用行为——而那个域名，解析 IP 后指向的是一台位于北欧的云服务器，其 SSL 证书有效期只剩 11 天。

这个细节像一盆冷水，浇灭了所有关于“黑科技”的幻想。所谓超能力，不过是精心包装的客户端-服务端协议，它的上限由网络延迟、服务稳定性、规则引擎的表达力共同决定。而 Plan 模式之所以让我感到踏实，正因为它彻底拥抱了工程的朴素真理： 可预测、可验证、可中断、可协作 。

我不再追求让工具替我思考，而是训练自己提出更好的问题；我不再迷信一行代码的生成速度，而是看重整个验证路径的设计质量；我不再把“AI 写出了什么”当作成果，而是把“我如何证明它正确”作为交付标准。

如果你也在 Superpowers 的 explore 模式里反复碰壁，或者厌倦了为 skill 规则调试到深夜，不妨试试 Copilot CLI 的 plan 模式。它不会给你翅膀，但它会给你一张详细到每一步的登山地图，和一把随时可以插在岩缝里的冰镐。真正的超能力，从来不在工具里，而在你选择如何与工具共舞的清醒之中。