在生产环境中，团队搭建AI Agent自动化处理GitHub Issue的初期流程时，通常会先实现一个简洁的闭环：新Issue进入后，Triage Agent快速判断质量与范围，若足够清晰就直接打上ready-to-implement标签，触发Implementation Agent生成Draft PR。

这个模式对明确的小Bug和边界清晰的小特性非常高效。但真实项目中，总有一类Issue无法被“一键”覆盖——它们匹配团队长期路线图，却存在显著的产品模糊性（多种实现路径差异极大，需要人类权衡取舍）或技术复杂度（实现规模远超几百行代码）。此时，单纯依赖Triage直接下发实现指令的Agent，经常生成与隐性预期偏差较大的代码，Review环节反复返工，甚至引入难以追溯的技术债。

这正是Zach Lloyd在构建云软件工厂过程中遇到的核心卡点。他在Warp.dev的实践中，选择为工厂增加一个独立的Spec阶段，而不是简单强化Triage的判断能力。

为什么Spec阶段是自动化扩展的关键节点

起初我以为只要让Triage的prompt更聪明、加入更多上下文，就能解决复杂Issue的问题。后来深入整个工厂的执行链路才发现：Spec生成本身是一个高认知负荷的任务，它需要同时处理产品意图拆解和技术架构权衡。把这个任务独立出来，让专用Agent先产出结构化输出，再由人类在低成本点进行对齐，反而是更优的系统设计。

类比一下：给一个普通厨房做一顿家常菜，一张简短菜谱就够；但要做一桌分子料理或为特定客人定制的宴席，就必须先有两份文件——一份写清楚“最终呈现效果和用户体验”（产品规格），另一份写清楚“食材比例、烹饪工艺、设备约束和风险控制”（技术规格）。没有这两份文件，即使顶级大厨也容易跑偏。Spec阶段做的，正是把“模糊的Issue”转化为两份可执行、可验证的规格文件。

Triage决策逻辑的升级

为了让工厂能智能路由，Zach Lloyd在示例图像编辑器项目中新增了roadmap.md和vision.md两个文件，清晰描述团队想把产品做成什么样子、未来规划的方向。

Triage Agent的判断逻辑随之更新为：

• 如果Issue明确、范围小 → 直接打ready-to-implement
• 如果Issue匹配roadmap/vision，且满足以下任一条件 → 打ready-to-spec
  • 模糊性：存在多个差异显著的产品或技术实现路径，人类需要参与选择
  • 复杂度：预计实现代码量远超几百行
• 其他情况 → needs-info（要求补充信息）或wait-to-implement（暂缓）

这个决策不再是简单的“能不能实现”，而是“是否需要先进行Spec对齐”。

Spec Agent的产出与执行链路

当Issue被打上ready-to-spec标签后，GitHub Action触发Spec工作流。Spec Agent复用之前搭建的基础设施（Docker镜像、Oz云自动化平台、Warp技能系统），依次调用：

• write-product-spec → 生成PRODUCT.md（定义产品行为、用户故事、验收标准、边界条件）
• write-tech-spec → 生成TECH.md（定义技术架构、代码形状、关键模块划分、约束与非功能性要求）

两个文件统一放在specs/<issue-slug>/目录下，与Issue强绑定。

生成后，推荐的做法是把Specs先提交成一个独立的PR（或直接并入后续实现PR）。这样既保留了“Agent当时瞄准的what和how”，也方便后续Verification Agent用/validate-changes-match-specs进行自动校验。

人类的最佳介入点在这里：拉取Specs到本地，用类似Matt Pocock的/grill-me技能进行交互式细化，确认产品意图和技术方向一致后，再把Issue标记为ready-to-implement。这时Implementation Agent才启动，并被明确指示“必须严格遵循已存在的PRODUCT.md定义行为、TECH.md定义实现形状”。

流程可视化（Mermaid）

两种流程的系统级权衡

Spec不是额外负担，而是工厂的长期基础设施

Spec阶段的引入，本质上是在AI Agent规模化开发中，把“意图对齐”这个最难的部分，从高成本的编码阶段前移到低成本的规划阶段。Implementation Agent不再需要猜测“产品到底想要什么”，而是拿到一份清晰的北极星文件去执行。

这也解释了为什么把Specs检查入PR如此重要——它把Agent的思考过程变成了可版本控制、可Review、可后续验证的工程资产，而不是一次性的黑盒输出。

在真实落地中，你会发现：简单Issue依然保持极高吞吐，复杂Issue则通过Spec层获得可控的质量与对齐度，整个工厂的处理能力从“能跑通Demo”进化到“能承接真实产品迭代”。

如果你正在构建或优化自己的AI驱动开发流程，建议从以下三件事开始实践：

1. 在仓库根目录添加roadmap.md和vision.md，让Triage有清晰的长期上下文。
2. 升级Triage判断逻辑，明确“模糊性”和“复杂度”的判定标准。
3. 引入Spec工作流，生成PRODUCT.md + TECH.md，并把它们作为Implementation的强制输入。

尝试后，欢迎在评论区分享你的复杂Issue处理现状，或者你在落地过程中遇到的具体权衡点。我们下期继续拆解Review与Verification Agent的构建。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。