AI终于会做项目-夜雨聆风

AI终于会做项目

昨天看到一个 85K stars 的 skill：

https://github.com/garrytan/gstack

很多人第一眼看 gstack，会以为这又是一个 agent 大礼包。

一堆角色，一堆命令，一堆流程。

操千曲而后晓声，观千剑而后识器

gstack 把 AI 开发这件事，从想到什么说什么变成了按流程打仗。

这点对 Hermes 这种 skill 体系特别有启发。

gstack 到底是什么？

它是增强你怎么和 AI 一起做项目。

很多 AI 工具，解决的是写得更快。

gstack 解决的，是更上游也更关键的问题：

想法怎么澄清
需求怎么定边界
工程方案怎么收敛
代码怎么 review
页面怎么真实 QA
上线怎么标准化
事后怎么复盘

它的一整条链路：

Think → Plan → Build → Review → Test → Ship → Reflect

这和普通 prompt 工具不是一回事。

普通工具是：你想到什么，就问什么。

gstack 是：你在不同阶段，调用不同角色，完成不同任务。

这就已经不是 AI 帮你写代码了，这是在把 AI 变成一支团队。

正所谓欲穷千里目，更上一层楼

很多项目越做越乱不是模型不够强，是顺序错了。

方向没定，就开始写。
方案没稳，就开始改。
代码写完，就以为结束。
最后返工一轮接一轮。

gstack 最有价值的地方，就是它强行把顺序拉正。

第一步：先定义问题

比如你说：“我要做个 daily briefing app。”

普通 AI 往往直接开始列功能、写页面、出接口。

但 gstack 会先反问你：

你真要的是简报吗
还是你想解决信息负担
这是个功能，还是一个产品机会
你现在说的需求，会不会只是伪需求

因为很多项目是死在一开始就把问题定义错了。

第二步：先做产品 review，再做工程规划

gstack 不会一上来就聊技术选型。

它先看：

这个需求是不是做小了
是不是做偏了
有没有更值钱的切口
现在该扩，还是该砍

这个层面过了，才进入工程层：

架构怎么拆
数据流怎么走
边界条件有哪些
哪些地方最容易炸
测试怎么补

先定方向，再施工。不是先写，再给自己找理由。

第三步：实现之后，是进入审查
gstack 很强调一个现实：

能跑，不等于能上线；过测，不等于没坑。

所以它在实现之后，马上接 review。

查

逻辑 bug
隐藏风险
不完整实现
CI 过了但线上会炸的问题

这一步本质上是在防一件事：

大多数 AI 编程流程最容易失控的地方。

第四步：真实 QA
这一点是 gstack 很加分的地方。

它不是只做代码层检查，还会做真实页面测试：

打开页面
点击流程
找交互 bug
发现问题后修
修完再验证

这一步把 AI 从代码生成器，往交付系统推了一步。

第五步：发布和复盘

很多人用 AI，流程停在写完。

但最容易出问题的是：

发布前没做齐检查
发布后没盯异常
做完后没有复盘沉淀

gstack 把这几步也纳进来：

同步主分支
跑测试
检查覆盖率
推代码
开 PR
看控制台报错
看性能回退
看上线后异常
最后做复盘

这就让它从写功能工具，变成了项目推进框架。

纸上得来终觉浅，绝知此事要躬行。

这句放在 gstack 身上特别合适。

因为它是让不同角色在不同阶段干不同的活，这才是真正像团队。

很多人第一次接触这类东西，都会有错觉：

是不是装上以后，AI 自动就升级了？

gstack 是一套使用纪律。

重点是它场景不同，叫不同角色。

阶段不同，干不同事情的逻辑

它和 Hermes 真正的结合点在哪里

我觉得 gstack 适配 Hermes，最值得迁移的是把它的方法论 skill 化。

因为 Hermes 的 skill 体系，本质上就是：

Markdown / SKILL.md
明确角色
明确步骤
明确触发条件
明确工具调用方式

把它那套流程思维，编译成 Hermes 能读、能调、能执行的 SKILL.md 体系。

如果真要结合，我觉得这三点比较推荐

1）host config 抽象

每个 agent 单独定义：

路径
工具名
文档规则
输出格式

同一套方法论，不必绑死在一个宿主上。

Claude Code 能跑；Hermes 能跑；别的 host 也能跑。

2）模板生成

一套模板，多宿主编译。

这样以后更新一版方法论，Hermes 版可以跟着生成。

这样有三个好处：

成本低
可维护
可迭代

3）工具语义翻译

这点最容易被忽略。

很多人迁 skill，总想做到一模一样，其实没必要。

真正重要的是同一方法论，在不同 agent 上可执行。

博观而约取，厚积而薄发

为什么说它适合做自我进化 skill？

因为 gstack 本身就是分阶段的。

它是分层的：

office-hours 负责澄清问题
CEO review 负责判断方向
Eng review 负责压实方案
review 负责找隐藏 bug
qa 负责真实验证
ship 负责标准化上线

这种结构最大的好处是：

可评测的
可优化的
可复盘的
可持续迭代的

这就很接近真正的自我进化，工程上的闭环进化。

它最适合：

独立开发者
创业者
技术负责人
一个人扛多个角色的人
想把 AI 开发流程标准化的人

因为这类人最缺的是流程纪律。

不太适合

只改一两行小 bug
写一次性脚本
做极短任务
只想随手让 AI 帮忙补一段代码的人

gstack 的问题也很明显：

小修小补时，你会嫌流程多。
学习成本不低。角色多，命令也多。
更适合认真做项目，不太适合顺手改一行字。

所以它最适合的场景是功能复杂、需要 review、需要 QA、要长期维护
想减少返工的。

如果迁移到 Hermes 先迁最核心的 3 个 skill

第一层：先迁最核心的 3 个 skill

/office-hours
/review
/qa

这三个几乎覆盖了：

需求澄清
质量把关
真实验证

先把这三层跑顺，你就已经不是在裸用 AI 了。

你是在建立自己的 AI 项目纪律。

后面再慢慢补：

产品 review
工程 review
发布前流程
发布后观察
周期性复盘

第二层：再补产品 review 和工程 review
当任务复杂起来，再把这两层加上：

产品层 review
工程层 review

这样 Hermes 就开始具备项目判断器的感觉了。

第三层：最后补发布与复盘。等前面几层跑稳了
再补：

发布前检查
发布后观察
周期性复盘

到这一步，Hermes 才真正升级成会做项目。

如果你问我：

gstack 值不值得 Hermes 结合

我觉得很值得。

但真正该结合的是：

宿主抽象
模板生成
工具语义翻译
以及流程观

gstack 最强的地方，不是让 AI 更会写代码。而是让一个人，也能像带着一支团队那样做项目。

大鹏一日同风起，扶摇直上九万里

gstack 的本质，不是一个命令包。它是一套 AI 做项目的方法论。

如果 Hermes 真把这套东西吃透了，增强的就从写代码能力变成

从想法到交付的整条链路。