不知道你有没有这种感觉：让 AI 写功能，10 分钟出了 500 行代码。一跑，全是报错。再让它修，修着修着，最初要做什么都忘了。
我以前也这样。后来换了个思路------不是让 AI 直接当码农，而是先让它当产品、架构、设计、测试、发布的搭子，评审完了再动手。
这个搭子就是 gstack (同时支持claudecode/codex)
gstack 是什么
把 AI 编程比作盖房子的话：
- 普通用法：直接往上垒砖
- gstack 用法：先出施工图，审过了再开工
说白了就是：把"写代码"前置成"做决策"，把返工扼杀在动手之前。
我在用的 AI 开发流水线
这套我跑了有一阵子了，对"有想法、想快、又怕翻车"的场景特别管用。
1）需求澄清------/office-hours
bash
/office-hours它会逼你回答几个问题：
- 你到底在解决谁的问题？
- 第一版最小闭环是什么？
- 你要快上线，还是要做理想架构？
看起来只是多问了两句，但真的能帮你省掉后面一堆返工。
实际效果截图：
阶段性提问结束，会让你选择方案：
2）用 CEO 视角挑战方案------/plan-ceo-review
bash
/plan-ceo-review这步特别适合避免"做了很多，但没什么价值"的情况。
它会帮你做三件事：
- 逼你想清楚这到底是不是在解真问题
- 给你 2~3 套路线（最小可行 / 理想架构 / 创意路线）
- 把 scope 拆成：现在做、延后做、别做
你会第一次感受到：AI 不只是"会写"，还会"删"。
实际效果截图：
3）工程门禁------/plan-eng-review
bash
/plan-eng-review这是"技术债隔离带"。它会盯几件事：
- 接口契约稳不稳（schema、错误码）
- 异常能不能降级，不是只会 console.error
- 测试有没有覆盖分支，不是只测 happy path
- 发布能不能回滚，不是靠祈祷
不是能跑就行，是要可维护、可观测、可回滚。
实际效果截图：
4）设计门禁------/plan-design-review
bash
/plan-design-review这步特别容易被跳过去，但体验差距往往就出在这里：
- 信息层级对不对（先看啥、后看啥）
- 状态文案全不全（loading、error、fallback）
- 移动端交互合不合理
- 可访问性达没达到基线（键盘、读屏、对比度）
UI 不是"好看"问题，是"用户敢不敢继续用"问题。
实际效果截图：
5）实现阶段
这时候你手里已经有了：
- 明确范围（哪些做、哪些不做）
- 工程规范（契约、错误、测试、发布）
- 设计规范（层级、状态、交互）
让 AI 写代码，基本就是"按图施工"。
如果你中途想退出的话，可以先让它更新下文档状态，然后后续再继续。gstack生成的记忆文档在~/.gstack/projects/[your-project-name]目录下:
6）上线前质量收口------/qa + /review
bash
/qa
该指令会：测试你的应用，找出漏洞，用原子提交修复它们，然后重新验证。每次修复都会自动生成回归测试。
/review
该指令会：找出那些通过持续集成测试但在生产环境中崩溃的缺陷。自动修复显而易见的缺陷。标记出完整性方面的不足。
当然，你可以只执行：/qa-only/qa：系统化找 bug/review：PR 风险审查
7）发布------/ship + /land-and-deploy + /canary
这个没实际使用过，感兴趣的话，可以自己试试。
命令速查表
| 阶段 | 命令 | 作用 |
|---|---|---|
| 需求澄清 | /office-hours |
把想法变成可执行设计 |
| 战略校准 | /plan-ceo-review |
挑战问题与范围，做取舍 |
| 工程门禁 | /plan-eng-review |
架构/错误/测试/发布过审 |
| 设计门禁 | /plan-design-review |
交互与状态体验过审 |
| QA | /qa / /qa-only |
系统化测试并修复 |
| 代码审查 | /review |
预合并风险检查 |
| 发版 | /ship |
打包发布流程 |
| 落地+监控 | /land-and-deploy + /canary |
合并部署+线上观测 |
几个建议
建议 1：AI 写得快，不代表你该跳过评审。 越快，越要有门禁。
建议 2：先定"错误如何失败"，再写功能。 很多线上事故不是功能错，是失败方式错。静默失败、状态假成功、不可回滚------这些才是问题。
建议 3：把"延期项"写进文档，不要写进脑子。 用 TODOS.md 或 docs/designs/xxx.md。脑子会忘，文档不会。
我的工作习惯
每个新功能我都会先问自己三个问题：
- 这个功能的设计文档在哪？
- CEO/Eng/Design 三轮评审结论有没有写进仓库？
- 没写清楚之前，是不是又在让 AI 硬写代码？
三句有一句答不上来，我就不开工。
写在最后
以前觉得 AI 编程的上限是"写得快"。现在觉得不是------它真正的上限是：让你做对决策，再把正确的事做快。
如果你也在被"写得飞快、改得崩溃"折磨，可以试试 gstack 这套流程。AI 不再像临时工，而像有组织的团队。