最近半年，用 AI 写代码的频率越来越高。不论是公司的项目还是说自己想手搓一款产品，我个人已经非常习惯于先把需求交给 AI，让它分析需求、制订计划，然后再一步一步实现。

刚开始时，这种方式确实很爽。因为一个原本不知道从哪里下手的功能，跟AI对话过几轮之后就能够跑起来。

但是项目做得越久，我越明显地发现一个问题：AI 是会写代码，但是不等于说它能把项目做好。

有时需求还没聊清楚，它就已经开始改文件；有时计划看起来很完整，真正实现时却漏了关键边界；还有时它告诉我“测试通过”，我一上真机或者打开浏览器，问题马上就出来了😅。

这也是我最近开始关注 OpenSpec、Superpowers 和 gstack 的原因。

简单来说，它们是在 AI 和代码之间又加了一层工作方法（论）：让 AI 先想清楚要做什么，再按相对稳定的流程去计划、开发、测试和审查。

一、我们真正想解决的，不是“AI 不会写代码”

以前给 Codex 下任务时，提示词会写得很长：先检查 Git 状态，只改哪些文件，不要改哪些内容，完成后运行什么测试，还要报告哪些结果。

这种方式当然有效，但是它有两个问题：

第一个问题是，每次都要重新写。项目稍微复杂一点，提示词很快就会变成一篇小作文，而且很难保证没有遗漏。

第二个问题是，要求虽然写进了对话，却没有真正变成项目的一部分。对话一长、上下文一压缩，或者换一个新的会话，AI 可能又要重新理解一遍。

所以：

  • 能不能让需求和验收标准真正保存下来，而不是只存在聊天记录里？
  • 能不能让 AI 遇到不同任务时，自动遵循合适的工作流程？
  • 能不能在“写完代码”之外，再补上产品、架构、测试和安全这些视角？

OpenSpec、Superpowers 和 gstack，分别更偏向解决这三个问题。

二、OpenSpec：先把“要做什么”说清楚

我个人对于 OpenSpec 最直观的理解是：给 AI 编程加一份可以持续维护的需求档案。

平时直接让 AI 开发，一个需求通常是从聊天框开始的。比如我说：“给录屏应用增加 GIF 导出功能。”这句话对人来说已经大概能懂，但真正开发时还有很多没有说清楚的地方：比如，从哪个页面进入、转换过程能否取消、多个任务是否允许同时进行、应用退到后台以后怎么办、失败后显示什么。

如果这些内容没有提前确认，AI 很可能一边写一边猜。最后功能看似完成了，实际做出来的却不是我们想要的。

OpenSpec 的做法，是把一次改动拆成 proposal、spec、design、tasks 等可以落在仓库里的内容。需求不再只是“给 AI 发过的一段话”，而是变成项目中可以查看、修改和追踪的 Markdown 文件。官方示例还会把需求写成具体场景，例如“当用户点击主题按钮时，页面切换主题并保存选择”。这样后面验收时，检查的就不只是“有没有主题按钮”，而是完整行为是否成立。

它的基本流程也并不复杂：

先探索问题 → 提出变更 → 审核规格和任务 → 实施 → 验证 → 归档

按照官方文档，安装并初始化后，可以先用探索命令梳理模糊需求，也可以直接创建提案，在 Codex 中，具体调用形式会由初始化结果提示。

**OpenSpec 的作用不是让 AI “写得更快”，而是让人有机会在动代码之前发现理解偏差。**因为我们在做项目的时候，很多问题不是语法不会写，而是业务理解不够完整准确。比如像交易指令、运维监控这类系统，一旦状态含义、数据来源或者异常场景没弄清楚，代码写得再快也没有意义。

当然，OpenSpec 也不是说所有任务都必须使用。改一个颜色、调一个边距，如果还要先写 proposal 和 spec的话，反而会把简单的事情搞复杂。因此：需求有歧义、涉及多个文件、验收条件较多，或者后面可能继续迭代时，OpenSpec 才能真正发挥其价值。

三、Superpowers：给 AI 一套比较严格的开发习惯

如果说 OpenSpec 更关心“最终要做成什么”，那么 Superpowers 更关心“开发过程应该怎么走”。

Superpowers 本质上是一套面向编程 Agent 的技能和软件开发方法。它不会只在最后提醒 AI“记得测试”，而是尽量把头脑风暴、方案确认、实施计划、测试驱动开发、调试、代码审查和收尾这些步骤放进实际工作流里。

这跟我现在使用 Codex 的方式其实很接近，只不过我主要依靠自己写提示词来约束它。例如：

先审计现有实现
不要直接修改代码
先给出计划
确认后再实施
完成后运行测试
报告仍需人工验证的内容

Superpowers 想做的，是把这些反复出现的要求整理成可以复用的技能。AI 遇到对应场景时，不需要我每次从头提醒，而是应该自动进入相应流程。

我比较认同它里面的几个思路：

首先，需求没有确认好之前不要急着改代码。AI 最大的问题往往不是不会实现，而是会非常自信地实现一个错误的理解。

其次，修 Bug 时要先找根因，不能看到哪里报错就改哪里。这个习惯看起来普通，但在 AI 编程里非常重要，因为 AI 很擅长快速给出一个“能让报错消失”的补丁，却不一定会主动证明问题为什么发生。

最后，不能把“AI 说已经完成”当成完成。测试命令、浏览器结果、真机表现和 Git diff，至少要有可以核对的证据。

但是 Superpowers 也有明显的风格：它比较强调流程纪律。对于复杂功能，这能减少返工；对于很小的改动，完整流程可能显得偏重。它还可能和团队原有的研发规范、自己已经写好的 AGENTS.md 或其他技能重复。

所以说，不能把它理解成“安装以后代码质量自动提高”，而是应该把它看成一套默认比较严格的工作习惯。真正有用的前提，仍然是我们能看懂它为什么这样做，并且知道什么时候应该简化。

四、gstack：不是一个助手，而是一组有明确分工的角色

gstack 给我的感觉又不太一样。

gstack由 Garry Tan 开源，最初围绕 Claude Code 的个人工作方式发展，现在官方安装脚本也支持 Codex、Cursor、OpenCode 等多种编程 Agent。它把很多工作拆成了有明确角色的技能：有人从产品和 CEO 视角挑战需求，有人从工程负责人视角检查架构，有人做设计审查、代码审查、浏览器 QA、安全审计和发布。

例如，一个功能并不一定从“开始开发”进入。它可以先经历这样的过程：

office-hours：先追问问题到底是什么
plan-ceo-review：从产品价值和范围上挑战方案
plan-eng-review：检查技术方案和架构风险
review：审查当前代码改动
qa：在真实浏览器里验证页面
ship：完成发布前收尾

这套思路最有意思的地方，是它不再把 AI 当成一个什么都做的“全能实习生”，而是主动切换不同角色。

我以前会让 ChatGPT 帮我监督 Codex，其实已经有一点类似：Codex 负责分析和修改代码，ChatGPT 再帮我判断计划制定是否合理、测试是否充分、接下来需不需要手动验证。gstack 相当于把这种角色分工做得更加系统，而且观点很鲜明。

不过，“观点鲜明”既是优点，也是需要注意的地方。

gstack 不是一套完全中立的行业标准，它更像是把一位有经验的创业者和工程管理者的工作偏好写进技能里。对个人开发、从零做产品或者缺少完整团队的人来说，这些角色能补上很多盲区；但如果公司已经有成熟的产品评审、代码审查、CI/CD 和安全流程，直接照搬整套 gstack，可能会与现有规范冲突。

另外，它的功能很多，第一次接触时很容易陷入“我是不是每个命令都要跑一遍”——我个人认为是没有必要，先用需求梳理、工程计划、代码审查和 QA 这几个最容易理解的环节，已经足以判断它适不适合自己。

五、三者到底有什么区别

个人理解：

工具 更关心什么 什么时候想到它
OpenSpec 需求、规格和变更记录 功能还没说清楚，或者需要长期维护需求时
Superpowers 开发过程和工程纪律 希望 AI 按稳定步骤计划、测试、调试和审查时
gstack 专业角色和端到端交付 希望从产品、架构、设计、QA、安全等多个视角检查项目时

更通俗一点：

  • OpenSpec 像是把需求说明书放进代码仓库；
  • Superpowers 像是给 AI 一本开发工作手册；
  • gstack 像是临时组了一支有产品、研发、测试和发布角色的小团队。

它们之间并不是完全没有重叠。OpenSpec 也会生成任务，Superpowers 也会先梳理需求，gstack 也包含计划和审查。如果把三套流程全部机械叠加，很可能得到大量重复文档和重复确认。

因此，问题不是“能不能一起用”，而是“每一层到底解决了什么问题”。

六、如何选择🤔

以我目前的项目和经验，我不建议一上来把三套工具全部装满，然后要求 Codex 每次严格跑完整流程。

我更倾向于从 OpenSpec 开始。

原因很简单：（个人认为）最容易出问题的地方，往往是需求边界和业务理解，而不是少一个自动化命令。先把“做什么、为什么做、怎样算完成”固定下来，比继续加长提示词更有价值。

接下来，可以挑 Superpowers 里与自己最相关的环节，例如系统化调试、测试驱动开发和代码审查，看看它能不能减少反复提醒 Codex 的成本。

至于 gstack，可以把它用在一个功能已经形成方案之后：让不同角色来挑战计划，检查界面，做浏览器 QA，或者在发布前做一次更全面的审查。它最大的价值，不一定是写更多代码，而是提醒我们还有哪些视角没有考虑。

一个比较理想、但不必每次完整执行的流程可能是：

用 OpenSpec 固定需求和验收标准
        ↓
用 Superpowers 约束实现、测试和调试过程
        ↓
用 gstack 的特定角色做产品、架构、QA 或发布审查

小改动直接做；中等功能选择其中一层；真正复杂、风险较高的功能，再把几层组合起来。工具应该跟着任务走，而不是任务跟着工具走。

七、最后：AI 编程正在从“会不会写”变成“如何管理”

以前判断一款 AI 编程工具好不好，主要看它能不能读懂项目、能不能一次写对、生成代码快不快。

现在给我的感受是，模型能力只是其中一部分。需求怎么保存、上下文怎么交接、任务怎么拆分、测试怎么证明、代码由谁审查，这些以前属于软件工程的问题，在 AI 编程里一个都没有消失。

OpenSpec、Superpowers 和 gstack 的共同点，就是它们都不满足于“给 AI 一句话，然后等它交代码”。它们试图把开发团队中已经存在的规格、流程和角色，重新放进人与 AI 的协作中。

这不意味着用了它们就不会翻车，也不意味着流程越完整越专业。相反，如果自己完全不理解需求、不看计划、不验收结果，再好的工作流也只是让 AI 更有条理地犯错。

AI 可以承担越来越多的执行工作，但是不能因此放弃判断。

本文主要参考：