别再让 AI 盲写代码了：我用 gstack 把"灵感"变"可上线"

不知道你有没有这种感觉：让 AI 写功能，10 分钟出了 500 行代码。一跑，全是报错。再让它修，修着修着，最初要做什么都忘了。

我以前也这样。后来换了个思路——不是让 AI 直接当码农，而是先让它当产品、架构、设计、测试、发布的搭子，评审完了再动手。

这个搭子就是 gstack (同时支持claudecode/codex)

gstack 是什么

把 AI 编程比作盖房子的话：

• 普通用法：直接往上垒砖
• gstack 用法：先出施工图，审过了再开工

说白了就是：把"写代码"前置成"做决策"，把返工扼杀在动手之前。

我在用的 AI 开发流水线

这套我跑了有一阵子了，对"有想法、想快、又怕翻车"的场景特别管用。

1）需求澄清——/office-hours

/office-hours

它会逼你回答几个问题：

• 你到底在解决谁的问题？
• 第一版最小闭环是什么？
• 你要快上线，还是要做理想架构？

看起来只是多问了两句，但真的能帮你省掉后面一堆返工。

实际效果截图：

阶段性提问结束，会让你选择方案：

2）用 CEO 视角挑战方案——/plan-ceo-review

/plan-ceo-review

这步特别适合避免"做了很多，但没什么价值"的情况。

它会帮你做三件事：

• 逼你想清楚这到底是不是在解真问题
• 给你 2~3 套路线（最小可行 / 理想架构 / 创意路线）
• 把 scope 拆成：现在做、延后做、别做

你会第一次感受到：AI 不只是"会写"，还会"删"。

实际效果截图：

3）工程门禁——/plan-eng-review

/plan-eng-review

这是"技术债隔离带"。它会盯几件事：

• 接口契约稳不稳（schema、错误码）
• 异常能不能降级，不是只会 console.error
• 测试有没有覆盖分支，不是只测 happy path
• 发布能不能回滚，不是靠祈祷

不是能跑就行，是要可维护、可观测、可回滚。

实际效果截图：

4）设计门禁——/plan-design-review

/plan-design-review

这步特别容易被跳过去，但体验差距往往就出在这里：

• 信息层级对不对（先看啥、后看啥）
• 状态文案全不全（loading、error、fallback）
• 移动端交互合不合理
• 可访问性达没达到基线（键盘、读屏、对比度）

UI 不是"好看"问题，是"用户敢不敢继续用"问题。

实际效果截图：

5）实现阶段

这时候你手里已经有了：

• 明确范围（哪些做、哪些不做）
• 工程规范（契约、错误、测试、发布）
• 设计规范（层级、状态、交互）

让 AI 写代码，基本就是"按图施工"。

如果你中途想退出的话，可以先让它更新下文档状态，然后后续再继续。gstack生成的记忆文档在~/.gstack/projects/[your-project-name]目录下:

6）上线前质量收口——/qa + /review

/qa

该指令会：测试你的应用，找出漏洞，用原子提交修复它们，然后重新验证。每次修复都会自动生成回归测试。

/review

该指令会：找出那些通过持续集成测试但在生产环境中崩溃的缺陷。自动修复显而易见的缺陷。标记出完整性方面的不足。


当然，你可以只执行：/qa-only

• /qa：系统化找 bug
• /review：PR 风险审查

7）发布——/ship + /land-and-deploy + /canary

这个没实际使用过，感兴趣的话，可以自己试试。

命令速查表

几个建议

建议 1：AI 写得快，不代表你该跳过评审。 越快，越要有门禁。

建议 2：先定"错误如何失败"，再写功能。 很多线上事故不是功能错，是失败方式错。静默失败、状态假成功、不可回滚——这些才是问题。

建议 3：把"延期项"写进文档，不要写进脑子。 用 TODOS.md 或 docs/designs/xxx.md。脑子会忘，文档不会。

我的工作习惯

每个新功能我都会先问自己三个问题：

1. 这个功能的设计文档在哪？
2. CEO/Eng/Design 三轮评审结论有没有写进仓库？
3. 没写清楚之前，是不是又在让 AI 硬写代码？

三句有一句答不上来，我就不开工。

写在最后

以前觉得 AI 编程的上限是"写得快"。现在觉得不是——它真正的上限是：让你做对决策，再把正确的事做快。

如果你也在被"写得飞快、改得崩溃"折磨，可以试试 gstack 这套流程。AI 不再像临时工，而像有组织的团队。