第 14 章：进阶常见问题解答（Q11-Q20）

⏱ 预计阅读 9 分钟 更新于 2026/5/19
💡 进群学习加 wx: agentupdate
(申请发送: agentupdate)

Q11：gstack 和 superpowers 的 skill 可以混用吗？

可以。 skill 就是 markdown 文件，放在 ~/.claude/skills/ 目录下就能用。

但你需要注意：

  • 同一个 skill 名字不要重复 — 如果 gstack 和 superpowers 都有 /review，后安装的会覆盖先安装的
  • 命令冲突检查 — 安装后运行 /skills 查看所有可用命令
  • 按需调用 — 在 CLAUDE.md 中明确标注哪个阶段用哪个包的命令

实际操作中冲突很少，因为两套工具的命令名基本不重叠。gstack 偏 /design-*、/plan-*，superpowers 偏 /writing-*、/test-*、/*-driven-*。

Q12：/subagent-driven-development 和 /executing-plans 怎么选？

决策依据：

flowchart TB
    Q1{"任务之间有依赖吗？"}
    Q1 -- "有（后面要用前面的输出）" --> A["/subagent-driven-development"]
    Q1 -- "没有（互相独立）" --> Q2{"你是第一次做这种项目吗？"}

    Q2 -- "是" --> A
    Q2 -- "否" --> Q3{"追求质量还是速度？"}

    Q3 -- "质量优先" --> A
    Q3 -- "速度优先" --> B["/executing-plans"]

    style A fill:#dbeafe,stroke:#2563eb
    style B fill:#fef3c7,stroke:#d97706

简单规则： 不确定就用 /subagent-driven-development。它更安全，每步都有 review。等你熟悉了再考虑 /executing-plans 提速。

Q13：subagent 写的代码质量不好怎么办？

三个层面的解决方法：

1. 计划层面（最有效）

  • 计划写得更详细：包含完整的代码示例
  • 在计划中标注代码风格要求
  • 指定"参考哪个现有文件的写法"

2. 模型层面

  • 复杂任务用 opus 模型（更强但更贵）
  • 简单任务用 sonnet 模型（够用且快）

3. 审查层面

  • spec reviewer 和 code quality reviewer 会过滤低质量代码
  • 如果 reviewer 发现问题，implementer 会修复
  • review 循环直到质量达标

关键认知： subagent 的输出质量取决于你的输入质量。计划越详细，代码质量越高。

Q14：这套流程能用于 Python/Go/其他语言吗？

可以。 gstack 和 superpowers 的 skill 是语言无关的——它们是提示模板，不是代码框架。

但有些命令的语言适配程度不同：

命令 语言适配 说明
/writing-plans 全语言 纯文本计划
/subagent-driven-development 全语言 subagent 按你指定的语言写代码
/test-driven-development 需配置 测试框架不同（pytest/go test/etc）
/design-shotgun 前端为主 生成 HTML/CSS，对纯后端项目意义不大
/design-review 前端为主 审查视觉设计，后端项目用不到

建议： 后端项目主要用 superpowers（计划+编码+测试），gstack 的设计类命令可以跳过。

Q15：/insights 显示的数据准确吗？隐私安全吗？

数据来源： /insights 分析的是你本地的 Claude Code 会话数据（存在你机器上）。

隐私：

  • 数据只存在你的机器上
  • 不发送到 Anthropic 或 gstack 的服务器
  • 分析完全在本地进行

准确性：

  • 命令使用次数：准确
  • 时间统计：大致准确（可能有几分钟偏差）
  • 成本估算：基于 token 计数，仅供参考

Q16：如何创建一个跨项目的通用 skill？

步骤：

  1. 创建 skill 目录
mkdir -p ~/.claude/skills/my-workflow
  1. 写 SKILL.md
# My Workflow

## 触发条件
当用户要求开发新功能时。

## 步骤
1. /plan-eng-review — 技术可行性审查
2. /writing-plans — 生成实施计划
3. /subagent-driven-development — 自动执行
4. /requesting-code-review — 代码审查

## 注意事项
- 所有改动必须有测试
- 不跳过任何步骤
  1. 使用

在任意项目中输入 /my-workflow 即可触发。

跨项目 skill vs 项目 skill：

类型 存放位置 作用范围
全局 skill ~/.claude/skills/ 所有项目
项目 skill 项目/.claude/skills/ 仅当前项目

Q17：/freeze 和 /unfreeze 实际做了什么？

/freeze 是一个流程控制信号，告诉 Claude：

  • 当前处于发布准备期
  • 不接受新的功能开发请求
  • 只允许 bug 修复和文档更新

它不是 git 操作（不会锁分支），而是通过 CLAUDE.md 的规则和提示来约束 Claude 的行为。

实际使用中，/freeze 的效果取决于：

  • CLAUDE.md 中是否有对应的冻结规则
  • Claude 是否遵守这些规则

对于团队项目： 建议用 git branch protection（保护分支）实现真正的冻结，/freeze 作为辅助提醒。

Q18：gstack 的 /retro 和普通项目复盘有什么区别？

维度 普通复盘 gstack /retro
数据来源 人的记忆 git log + 会话数据
视角 参与者主观 AI 客观分析
产出 文档 结构化报告 + 改进建议
频率 项目结束或迭代结束 随时可做

/retro 的额外价值： 它能访问 git 历史和代码变更记录，给出基于数据的分析（"搜索功能的 review 循环比其他功能多 2 倍，说明初始实现质量不高"）。

Q19：如果 AI 给出的代码审查意见我不认同怎么办？

完全可以不认同。 审查意见是建议，不是命令。

处理方式：

  1. 看严重等级 — Critical 认真考虑，Suggestion 可以忽略
  2. 理解原因 — 审查者（AI）给出意见时有理由，先看理由合不合理
  3. 判断上下文 — AI 可能不了解你的全部约束条件
  4. 选择性采纳 — 接受合理的，拒绝不合理的，说明理由

不建议的做法： 全部接受或全部忽略。AI 审查有盲区（不了解业务上下文），但也有优势（发现人容易忽略的问题）。

Q20：学完这个教程，下一步该做什么？

三个方向：

方向一：深入工具

  • 给你的真实项目创建 CLAUDE.md
  • 为常用工作流写自定义 skill
  • 尝试 /executing-plans 对比效率差异
  • 探索 gstack 和 superpowers 的其他命令（本教程没覆盖的）

方向二：改进流程

  • 引入 CI/CD 自动化测试
  • 在团队中推广 AI 辅助开发
  • 建立团队的 skill 库和工作流标准
  • 定期 /retro 持续优化流程

方向三：扩展应用

  • 给 NoteFlow 加后端（Node.js/Python）
  • 尝试移动端开发（React Native）
  • 探索 Agent Teams 的多 agent 协作
  • 研究 MCP（Model Context Protocol）扩展 Claude Code 能力

我的建议： 先把教程的流程在你的真实项目中试一次。用过了才知道哪里好、哪里需要调整。纸上得来终觉浅。