AI 编程最常见的失败，并不是模型不会写代码，而是它太快进入实现：需求还没说清，测试范围没有定义，代码已经改了一大片。Garry Tan 开源的 gstack 试图把这种即兴协作改造成一条有工位、有交接物、有复核步骤的工程流程。
“Judgment-as-Code（判断即代码）”并不是 gstack 官方提出的标准术语，而是本文对其设计的研究性概括：把产品、工程、设计、安全和发布中的判断规则写进可版本化的技能文件，再交给 Agent 执行。它是分析框架，不是已经被证明的新软件范式。
gstack 到底是什么
gstack 是 Garry Tan 公开的 AI 开发技能集合，最初围绕 Claude Code 构建，当前仓库也提供其他宿主的安装路径。项目包含产品澄清、规格、工程评审、设计、代码审查、浏览器 QA、安全、发布和复盘等技能。
几个典型入口能说明它的思路：
/office-hours用一组强制问题挑战产品假设，先产出设计说明。/plan-ceo-review重新审视范围和产品价值，不急着实现。/plan-eng-review固化架构、数据流、边界条件和测试计划。/qa与浏览器工具验证实际页面，而不只阅读代码。/cso组织安全审查，/ship和发布相关技能处理交付。
技能数量和名称会随项目版本变化，因此本文不把某个快照中的“多少个角色”写成永久事实。官方仓库与技能文档才是当前能力清单。
关键不在角色扮演，而在交接契约
把一个模型叫作 CEO、工程经理或安全官，本身不会产生真正的组织多样性。gstack 较有价值的部分，是让上一步形成结构化产物，供下一步继续工作：产品澄清进入规格，工程计划给 QA 定义测试面，审查发现的问题进入修复和发布流程。
这种设计有三个工程收益：
- 延迟编码。 把问题定义和范围审查设为显式关卡，降低快速做错的概率。
- 关注点分离。 实现、审查和验证使用不同指令与产物，减少同一步骤自说自话。
- 流程可读。 技能主要以文本和脚本存在，团队可以审阅、修改、版本控制和复盘。
因此，gstack 不是“下载一支虚拟公司”。更准确地说，它是一套运行在 AI 编码宿主之上的工程流程包。
什么是“判断即代码”
传统自动化最容易编码确定性规则，例如测试必须通过、部署必须有审批。专家判断更模糊：什么需求应该砍掉，哪种实现虽然能跑却会留下架构债，什么视觉结果“正确但不好用”。
技能文件提供了一个中间层：它不能把审美变成数学定理，却能把检查顺序、反例、证据要求和停止条件写清。判断因此获得了几种类似代码的属性：
- 可以进入版本控制，看到规则何时改变；
- 可以复用，在不同项目上执行相同审查；
- 可以被测试，用历史案例检查是否触发了预期问题；
- 可以分叉，团队按自己的风险偏好维护版本。
这是本文对 gstack 最重要的推断。它描述一种实践方向，不表示自然语言规则具有程序代码同等的确定性。
三个不能忽视的边界
同一个模型不是独立团队
不同技能可以改变关注点，却仍可能共享模型的知识缺口与偏见。让同一模型先写再审，比完全不审更有结构，但不能等同于独立安全团队或资深工程师签字。
流程会放大原有判断
技能擅长执行已经写下来的标准。标准本身错误或不适合当前业务时，自动化会更稳定地重复错误。现成技能应被视为 Garry Tan 团队偏好的可读样本，而不是所有公司的最佳实践。
产出规模不代表产品价值
README 中的开发速度和代码量属于作者自报口径，难以与其他团队统一比较。代码行数还会受到语言、生成方式和重构策略影响。本文不把这些数字作为 gstack 有效性的证据。
团队应该怎样采用
先选一个高频且可验收的环节，例如 PR 审查或发布前 QA。把现有技能在历史案例上回放，记录它发现了什么、误报了什么，再调整规则。敏感命令保留人工审批，最终上线仍由测试、代码所有者和安全策略把关。
更长期的价值不是把所有 gstack 技能照搬进来，而是把团队自己的事故复盘、架构约束和产品原则写成技能。每条判断都应附带适用范围、证据、反例和升级条件。这样得到的才是组织自己的“可执行经验”。
参考资料与延伸阅读
资料核验日期：2026-08-23。“Judgment-as-Code”是本文的研究性概括；项目能力以官方仓库当前版本为准。