第一步：需求验证#

我最开始的想法是「做一个涉及多智能体的 AI 产品」，需求很模糊，要做什么也不清楚。我直接把skill的调用流程告诉AI，让它按顺序调用。

调用 office-hours 后，AI 用 YC 的六步框架问我：

• ① 需求现实：你解决的问题是不是真的存在？有什么证据？
• ② 现状分析：现有方案是什么？它们为什么不够好？
• ③ 具体性：你能不能用一个具体的场景描述这个问题？
• ④ 最小切入点：你能做的最小有用产品是什么？
• ⑤ 观察：你有没有和潜在用户聊过？
• ⑥ 未来适配：如果这个方向成功了，下一步是什么？

一轮聊下来，我把方向定在了「Agent 竞技场」——一个让多个 AI Agent 进行博弈对战、观察策略演化的平台。

第二步：方案设计#

方向确定后，我用 brainstorming 进行方案设计。AI 不是直接给方案，而是逐步提问：

• 「你希望 Agent 支持哪些博弈场景？囚徒困境？猎鹿博弈？还是自定义博弈？」
• 「用户是被动观察还是可以干预 Agent 的策略？」
• 「策略演化需要可视化呈现吗？用什么形式？」

讨论下来，方案基本确定：支持经典博弈场景（囚徒困境、猎鹿博弈等），用户可以创建自定义博弈规则，Agent 自主博弈并展示策略演化过程，提供回放和分析功能。

第三步：PRD 撰写#

方案确定后，用 write-a-prd 产出 PRD 文档。它会追问每个设计细节：

• 「用户创建自定义博弈时，收益矩阵如何输入？」
• 「Agent 的策略选择算法是用什么？固定策略还是学习型策略？」
• 「回放功能需要支持哪些操作？快进、暂停、分步查看？」

最终产出的 PRD 包含：用户视角的问题描述、解决方案、用户故事列表、模块划分、接口设计、测试策略等。

第四步：评审#

PRD 写完之后，进入评审环节。

plan-ceo-review 从战略角度挑战方案：

• 「博弈论教育市场有多大？这个产品是解决教学痛点还是技术自嗨？」
• 「和现有的 Gambit、Game Theory Explorer 相比，差异化在哪里？」
• 「商业模式是什么？」 ' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

plan-eng-review 从工程架构角度审视。它关注的是系统设计层面的问题，比如它会问：Agent 博弈引擎怎么设计、需要支持并行执行吗、策略演化数据怎么存储…这个 Skill 会评估依赖关系、数据流瓶颈、单点故障风险、安全边界，还会检查测试覆盖和性能问题。

plan-design-review 从产品设计角度评分。它用 0-10 分评估七个维度：信息架构是否清晰、交互状态是否完整、用户旅程的设计、AI slop 风险…

评审完成后，Agent就综合以上评审结果及沉淀文档更新了 PRD，补充了遗漏的边界情况和设计细节。

这是我一轮skill组合使用下来沉淀出的文档：

第五步：分阶段开发#

PRD 终稿确定后，进入开发阶段。

首先是 writing-plans ，它把整个项目拆分成几个 Phase，分别对标不同开发阶段。每个 Phase 又拆成十几个 bite-sized 任务，每个任务 2-5 分钟，包含：具体的文件路径、完整的代码示例、验收标准等等。

然后会自动加载 subagent-driven-development 这个skill。每个任务用一个独立的 subagent 执行，不共享 context，避免上下文污染。完成后进行两阶段评审：第一轮检查是否符合规格，第二轮检查代码质量。

整个过程中， test-driven-development 强制执行。每个任务开始前，先写测试。测试写完后才能写实现代码。这保证了代码质量，也减少了后期返工。

第六步：发布#

开发完成后，用 gstack 的 review 进行代码评审，找出潜在的 bug。然后用 qa 用真实浏览器测试，发现问题后自动修复并提交。最后用 ship 完成发布：同步主分支、运行测试、推送代码、创建 PR。

核心思想#

Vibe Coding（跟着感觉走的AI编程）在正式产品中会暴露需求模糊、架构混乱、代码质量不稳定等问题。作者通过 规范驱动开发（Spec-Driven Development, SDD），将 gstack 和 superpowers 两套 Skill 集合组合使用，从需求验证、方案设计、架构评审到分阶段开发，每一步都有文档沉淀和质量把关，从而 大幅减少返工、提升效率、保证质量可控。

我的理解#

这篇文章的核心价值不在于推荐了哪些工具，而在于提出了一个 从”氛围编程”到”工程化开发”的范式转变。Vibe Coding 的问题本质上是 决策前置不足——在没想清楚做什么、怎么做、为什么做之前就开始写代码。SDD 的核心是用结构化的流程把决策提前，用文档沉淀把决策固化，用独立 subagent 把执行隔离。这其实是把传统软件工程的”先设计后编码”思想重新引入 AI 编程，但用 Skill 自动化了评审环节。

主要内容#

我的理解#

这篇文章最被低估的一点是：它揭示了 AI 编程的两个截然不同的阶段。

• 探索阶段（Vibe Coding 适用）：你不知道要什么，AI 也不知道。这时候”跟着感觉走”是对的，因为快速迭代比架构完美更重要。
• 产品阶段（SDD 适用）：你知道要什么，需要高质量、可维护、可复用的代码。这时候需要流程。

很多人用 Vibe Coding 做产品之所以痛苦，是因为用错了工具。就像用 sketch 画建筑图纸——能画出来，但施工时一定会出问题。

另一个关键洞察是：文档不是给人类看的，是给 AI 看的上下文。在 AI 编程中，文档的作用是替代人类记忆中丢失的上下文。每次 Claude Code 启动新会话，它需要重新理解项目。如果所有决策都沉淀在文档里，AI 就不需要”猜”。

总结#

作者通过 gstack + superpowers 的实践，证明了一个观点：AI 编程不是让 AI 随便写代码，而是按一套结构化的开发流程来。核心公式是：

需求验证 → 方案设计 → 三轮评审 → PRD → 任务拆分 → Subagent 执行 → 评审发布

每一步都有文档沉淀，每一步都有质量把关。

我的扩展总结#

1
PRD + 架构文档 + 设计规范 + 测试策略 = AI 的"项目记忆库"