在生产环境中团队搭建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明确、小范围匹配roadmap 模糊或复杂其他遵循Specs新GitHub IssueTriage Workflow Triage Skillready-to-implementready-to-specneeds-info / wait-to-implementSpec Workflow Spec Skillwrite-product-spec生成 PRODUCT.mdwrite-tech-spec生成 TECH.mdSpecs Pull Requestspecs/issue-slug/人类Review Refine可选交互式grill-meImplementation Workflow Implementation SkillImplementation PR人工Review Merge两种流程的系统级权衡维度简单一键实现流程Spec驱动增强流程关键差异适用场景明确、小范围Bug与特性模糊、复杂、高价值需求边界清晰度端到端自动化程度极高中高Spec阶段保留人类确认点权衡点前移人类介入成本集中在最终Review集中在Spec确认成本更低、影响更大杠杆效应输出对齐风险高依赖Agent隐性理解低Specs作为显式契约可验证性长期可追溯性弱无结构化记录强PRODUCT.md TECH.md可复用、可审计知识资产化对复杂任务扩展性受限易失效显著提升可覆盖真实生产场景工厂成熟度Spec不是额外负担而是工厂的长期基础设施Spec阶段的引入本质上是在AI Agent规模化开发中把“意图对齐”这个最难的部分从高成本的编码阶段前移到低成本的规划阶段。Implementation Agent不再需要猜测“产品到底想要什么”而是拿到一份清晰的北极星文件去执行。这也解释了为什么把Specs检查入PR如此重要——它把Agent的思考过程变成了可版本控制、可Review、可后续验证的工程资产而不是一次性的黑盒输出。在真实落地中你会发现简单Issue依然保持极高吞吐复杂Issue则通过Spec层获得可控的质量与对齐度整个工厂的处理能力从“能跑通Demo”进化到“能承接真实产品迭代”。如果你正在构建或优化自己的AI驱动开发流程建议从以下三件事开始实践在仓库根目录添加roadmap.md和vision.md让Triage有清晰的长期上下文。升级Triage判断逻辑明确“模糊性”和“复杂度”的判定标准。引入Spec工作流生成PRODUCT.md TECH.md并把它们作为Implementation的强制输入。尝试后欢迎在评论区分享你的复杂Issue处理现状或者你在落地过程中遇到的具体权衡点。我们下期继续拆解Review与Verification Agent的构建。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。