工作流
gstack 为什么退到专项工具箱
5 min read
我接触 gstack 时，正处在一个很容易被重流程吸引的阶段。
当时我已经不满足于只让一个模型写代码。项目变大以后，我需要计划、审查、浏览器验证、前端复查和发布前检查。gstack 的角色化工具箱正好给了我一种“虚拟工程团队”的感觉。
这套东西在复杂任务里确实有价值。浏览器 QA、视觉复查、性能检查、发布前检查，这些能力能把模型从纯文本推理拉回真实页面和真实结果。
问题出在默认入口
问题不是 gstack 没用，而是它不适合成为所有任务的默认入口。
日常开发里有大量小任务。一个局部文案、一个样式问题、一个已定位的 bug，如果每次都拉起完整角色链路，流程成本会超过改动本身。对我来说，这种成本不只是时间，也包括注意力被打散。
后来我开始把重流程从主线里拿掉。小任务回到 Codex 直接处理，复杂任务再加计划和验证。gstack 不再默认出现，而是保留在更适合它的场景里。
保留下来的能力
我保留的是专项能力，而不是完整重流程。
前端页面需要真实浏览器检查时，浏览器 QA 仍然有价值。页面气质不稳时，设计复查仍然有价值。部署前需要快速看健康状态时，检查类工具仍然有价值。
只是这些能力现在不再抢主线。主线由 Codex 负责理解项目、执行改动和验证结果。Trellis 负责长期上下文，Aegis 负责高风险边界。gstack 退到外置位置，只在对应场景里出现。
这次降级对我很重要。它让我明白，工具链不是越厚越专业。真正成熟的用法，是知道什么时候用它，也知道什么时候不用它。
参考来源：