ai-production-development-workflow-openspec-superpowers-gstack¶

Ch05.019 ai-production-development-workflow-openspec-superpowers-gstack¶

📊 Level ⭐⭐ | 19.0KB | entities/ai-production-development-workflow-openspec-superpowers-gstack.md

三大痛点¶

三件套架构¶

OpenSpec — 规范驱动开发（需求层）¶

核心：双文件夹模型

openspec/    # 当前系统的事实来源（规范文件）
specs/       # 每次变更的完整提案
changes/     # 变更提案目录

每份变更包含三个文件：

这三份文档是 AI 和人之间的契约，AI 在动手写代码之前先在文档里对齐需求。

实测效果：

• Token 消耗降低 30%~50%
• 返工率下降 60% 以上

Superpowers — 强制流程约束 AI 执行（执行层）¶

7 步不可跳过工作流：

关键原则：每一步都不可跳过。

gstack — 执行工具封装（验证层）¶

不做决策，只帮你干活：

数据流与分工边界¶

需求输入
    ↓
OpenSpec → proposal.md / design.md / tasks.md
    ↓
Superpowers → brainstorming → worktree → 小任务 → subagent → TDD → review → 分支收尾
    ↓
gstack → /browse 截图验证 → /qa 端到端测试 → /ship → /land-and-deploy → /canary
    ↓
生产上线

分工边界（三不原则）：

• OpenSpec 只产出规范文档，不写代码
• Superpowers 只按规范执行编码流程，不直接操作浏览器或部署
• gstack 只做验证和交付动作，不参与需求分析或架构决策

三者之间通过文件和命令传递信息，不是通过共享内存或隐式状态。

关键要点¶

1. 三件套缺一不可：需求没对齐 → 返工，执行没规范 → 质量差，验证没工具 → 上线踩坑
2. OpenSpec Token 降低 30~50%，返工降低 60%（实测数据）
3. Superpowers 每步不可跳过——这是生产环境的底线，不是官僚主义
4. gstack 填补了"AI 写完代码但无法验证页面渲染"的空白
5. 与 Coding Harness Engineering 一脉相承：通过 Skill 组合 + 开发规范 + 流程约束推动 AI 产出收敛

→ 原文存档

相关页面¶

• 三合一工具深度对比
• Superpowers 实战

深度分析¶

三件套方法论的核心价值在于将 AI 协作的不确定性从"人-AI 二元博弈"转化为"人-AI-系统三元约束"。传统 AI 编程依赖模型的理解能力和上下文窗口，但随着任务复杂度上升，单次对话的 token 消耗急剧增加，且 AI 的注意力会逐渐漂移（drift）。OpenSpec 的本质是通过外部化需求文档，在 AI 和人类之间建立一个低熵的、持久的事实来源——这不仅仅是文档，更是一种强制思维清晰化的机制。当 AI 被要求在 proposal.md 中阐述"为什么要做"时，实际上是在进行元认知（metacognition）校准，任何无法清晰表述的动机或目标都暴露了需求本身的模糊性。笨小葱实测 Token 降低 30%~50% 的背后，正是这种强制清晰化减少了 AI 的无效探索和反复确认。

Superpowers 的 7 步工作流最深刻的洞察在于不可跳过原则背后的熵减哲学。在 AI 编程场景中，"跳过 brainstorming 直接写代码"或"跳过 review 直接合并"是最高频的效率诱惑——短期内似乎加速了进度，但累积的债务最终以"上线后才发现需求理解偏差"或"主分支被污染"的形式爆发。git worktree 的引入是一个容易被忽视但至关重要的设计：它将 AI 的每一次执行都隔离在独立分支中，从物理层面消除了"AI 误操作覆盖人类代码"的风险。这比任何 lint 规则或权限控制都更根本——错误操作的影响范围天然被分支边界约束。TDD 循环的嵌入则将测试从"质量保障手段"提升为"任务完成的定义标准"：代码只有在通过测试时才被视为完成，这消除了 AI"写完了但没测"的自欺问题。

gstack 作为验证层填补了当前 AI 编程工具链中最薄弱的一环。主流 AI 编程助手（Claude Code、Copilot 等）的验证能力止步于"代码逻辑自洽"——它们能写出语法正确的代码、能通过单元测试，但无法验证"页面在浏览器中渲染是否正确"、"部署后接口是否真的可达"、"上线后性能是否回退"。gstack 通过封装 /browse（真实验证页面渲染）、/qa（端到端测试）和 /canary（生产监控）命令，将验证闭环从"代码正确"延伸到"产品正确"。特别是 /careful 对危险命令的主动拦截，实际上是在 AI 和生产环境之间建立了一道防误操作闸门——在传统人工操作中这是常识，但在 AI 编程中由于执行主体的非人格性，这一安全意识更容易被忽视。

三件套的分层边界设计（三不原则）是防止职责污染（responsibility pollution）的关键制度安排。OpenSpec 不写代码保证了需求文档的客观性和可审查性——如果规范文档的撰写者同时负责实现，那么文档自然会成为代码的"事后辩护"而非"事前约束"。Superpowers 不直接操作浏览器或部署确保了执行层专注于流程纪律，而非被验证细节分心。gstack 不参与需求分析或架构决策则防止了验证工具越界成为决策者——这在实践中是一个微妙但严重的越权风险：当验证工具（如 /browse）提供了截图反馈后，AI 容易基于视觉反馈直接修改需求而非重新对齐规范。文件和命令作为信息媒介的设计还有一个关键优势：可审计性。每次变更的 proposal/design/tasks 三件套形成了完整的决策轨迹，任何时候都可以回溯"当时为什么这样设计"，这在 AI 协助开发中尤为重要，因为 AI 的上下文窗口是有限的，过去的决策如果不显式记录，很快就会消失在上下文中。

从 AI 协作工程化的视角看，三件套方法论的意义在于它提供了一套人机协作的宪法框架——不是约束 AI 能做什么，而是规定人和 AI 各自的不可逾越边界。Harness Engineering 的核心命题是"如何让 AI 的输出持续收敛到人类需求"，而收敛的关键不是提升模型能力（这是供应商的责任），而是在人与 AI 之间建立可靠的、结构化的信息传递机制。OpenSpec 是需求传递机制，Superpowers 是执行纪律机制，gstack 是验证反馈机制——三者共同构成一个完整的人机协作闭环，其设计哲学与 DevOps 的"发现问题尽早反馈"一脉相承，只是将反馈环从人与人扩展到了人与 AI。

实践启示¶

当你开始一个新任务时，首先完成 OpenSpec 三件套而非直接让 AI 写代码。 proposal.md 强迫你回答"为什么做"和"如何衡量成功"，design.md 迫使你提前思考架构和数据流，tasks.md 将宏观目标拆解为可执行单元。这不仅是给 AI 的指引，更是给自己思维盲区的强制曝光。实测数据表明这一前置投资能将整体开发时间缩短（通过减少返工），原因是磨刀不误砍柴工。

在 Superpowers 工作流中，最容易被跳过的是 brainstorming 和代码审查。 brainstorming 是唯一能主动暴露需求隐藏假设的环节——当 AI 连续追问三个"为什么"时，你应该感到欣慰而非烦躁，因为每一个问题都是在帮你避免未来的返工。两阶段代码审查（规范合规 + 质量）应该在你的团队中被制度化，前者检查代码是否做了规定的事，后者检查代码是否做好规定的事。

gstack 的价值在你第一次因为"代码看起来没问题但上线后页面挂了"而加班时会深刻体会。 建议将 /browse 截图验证纳入每次前端变更的标准交付流程，即使 AI 说"代码没问题"。/canary 命令应该始终在生产部署后执行，它是你对抗"AI 自信"和"CI 通过不等于产品正确"这两类认知偏见的最后防线。

在团队中推广三件套时，最大的阻力不是技术而是流程惯性。 开发者会抱怨"brainstorming 太啰嗦"、"TDD 降低了我的效率"，这类似于早期程序员对代码审查的抵触。解决方法是先用小项目验证（1-2 周的 trial period），收集具体的效率数据和返工率对比，用数据而非行政命令来推动采纳。三件套不是银弹，对于简单的一次性脚本或 PoC 项目，过度的流程约束可能得不偿失。

如果你在使用 Claude Code 或类似工具，尝试将 Superpowers 的工作流设计为自定义 Skill 组合。 笨小葱的实践已经验证了这一组合的有效性，具体可参考 中的详细配置。通过 Skill 封装工作流步骤，可以将三件套的执行纪律从"个人自觉"转化为"工具默认"，从根本上减少偷懒跳过步骤的可能性。

第 2 来源：代码随想录/程序员Carl 2026-06-12 面试视角¶

补充自 原文存档，提供同一三件套的面试导向解读——把第 1 来源的工程视角转为求职问答结构，补充 5 个高频面试题标准答法 + "什么时候该用/别用"的决策框架。

补充 1：核心 thesis 的不同措辞¶

Carl 的措辞更接近工程治理语言（"层"是架构概念），笨小葱更接近流水线语言（"层"是工序概念）。两个措辞兼容，但 Carl 的措辞更便于在大厂面试中讨论"AI 治理"和"流程化"。

补充 2：Vibe Coding 的具体反例¶

Carl 用一个会员续费的具体反例说明 Vibe Coding 失控：

• 续费失败怎么处理，没想清楚
• 优惠券和续费能不能叠加，没写
• 幂等性没保证
• 回调失败没有补偿
• 测试只覆盖了成功路径
• 上线前没人认真 Review

这些是工程上的真实痛点，比笨小葱的"三大痛点"更具体。核心论点：AI 增强开发的核心不是让 AI 更快开写，而是让 AI 在正确的规格、正确的流程、正确的交付闭环里写。

补充 3：5 个高频面试题标准答法¶

Carl 整理了 5 道大厂面试高频题的标准答法：

这 5 道题的结构值得在求职准备时单独提取——大厂 AI/Agent 相关岗位的面试问题模板基本能套这 5 题。

补充 4："什么时候该用"决策规则¶

Carl 给出明确的使用边界判断标准：

错误影响半径决定流程强度——如果错误只影响局部样式可以轻流程；如果错误会影响钱、权限、数据一致性、用户主流程就上规格和交付闭环。

补充 5：gstack 的 7 步流程细节¶

Carl 列出了 gstack 的 7 步命令流程（这在第 1 来源中没具体展开**）：

• Think → /office-hours 重新想清楚需求
• Plan → /plan-ceo-review + /plan-eng-review + /plan-design-review 压测产品/架构/UX/测试
• Build → 按 brief 开发
• Review → /review 查回归、缺测试、隐藏风险
• Test → /qa 跑真实浏览器 QA
• Ship → /ship 最后发布检查
• Reflect → /retro 复盘本轮模式和问题

Browser QA 是 Carl 特别强调的环节——"AI 写的是代码，但用户用的是产品"。单元测试发现不了按钮挡住、表单状态没清、移动端布局炸、登录态下流程不对这些 UI/UX 问题。

与第 1 来源的互补关系¶

两源结合：第 1 来源讲工程方法论与实测数据，第 2 来源讲工程措辞升级与求职应用——形成"既懂工程又会表达"的完整认知。

第 2 来源带来的新 tags 视角¶

Carl 文章的 tag 贡献：

• interview — 大厂面试导向
• vibe-coding — 反例分析框架
• ai-engineering — 跨过 vibe coding 走向 engineering 的方法论
• specification-driven — OpenSpec 范式
• browser-qa — gstack 的核心差异化
• deliverable-closure — 交付闭环的工程化定义

这些 tag 与第 1 来源的 harness / production / workflow 互补，扩展了本实体的搜索半径。

相关实体¶

• MOC