你同时开了三四个编码代理窗口Claude Code在改认证逻辑Codex在修APICursor在处理UI。几个小时后你切换回来发现一个代理只改了部分文件就停了另一个提了PR但没合并第三个把ticket描述改得面目全非还漏了验证步骤。你成了全职的“代理保姆”不断切换上下文、催进度、修烂摊子。输出量上去了但你的注意力被彻底撕碎。这不是模型不够聪明而是缺少一套能让代理真正“干完活”的结构。我起初以为只要把ticket丢给代理它们自然会处理好。后来发现代理特别擅长把事情做到“看起来差不多”却极少自己把所有环节走完提交代码、开PR、合并、部署、打勾所有检查项。缺少明确合同和强制完成机制它们就会在最舒服的地方停下来。Fred Jonssonenginoid分享的这套实践正是针对这个痛点用Linear作为中央协调层把多个不同 harnessClaude Code、Codex、Cursor等的代理组织成可并行、可测量、可持续改进的“软件工厂”原型。为什么让代理自己管理ticket会散架代理没有人类对“完成”的直觉。它们会用自己发明的术语重命名ticket“Fix gated-access exception in owned-compute handler”把工作拆得过于细碎或散落在backlog各处只做到“代码能跑”就认为任务结束忽略合并、部署和验证结果是你花大量时间做本来该由系统保证的收尾工作。解决之道是把ticket变成对人类和代理都清晰的合同同时用批量并行 强制完成机制把你从“实时保姆”变成“工厂设计师和最终验收者”。把ticket变成清晰合同的五个核心部分每个ticket都遵循固定模板重点放在目标状态而非具体实现路径Goal目标一句话说清楚要达成什么。Why为什么业务或技术动机让代理理解真实需求。Outcomes预期结果用树状结构组织Epic → 子任务方便代理看到“完成整个树”的全局感也让你一目了然进度。Implementation approach实现指导可选只有当你有明确偏好时才写。默认留给执行代理自主决策。Verifications验证清单由专门的ticket authoring agent生成强制包含Automated、Manual、Visual三类检查。任何未打勾的检查项都会阻止ticket关闭。这种格式既保留了人类可读性又给了代理足够的上下文同时通过检查项形成硬性质量闸门。**Goal**: 用户能在移动端完成支付流程且通过PCI合规检查 **Why**: 当前桌面流程在移动端转化率低30%且存在安全隐患 **Outcomes**: - Epic: 移动端支付重构 - 子任务1: 适配移动端UI组件 - 子任务2: 集成Stripe移动端SDK - 子任务3: 添加合规审计日志 **Implementation approach**: 优先复用现有Stripe集成尽量减少新依赖 **Verifications**: - [ ] Automated: 单元测试 集成测试全部通过 - [ ] Manual: 在真实设备上完成支付流程 - [ ] Visual: 截图对比新旧UI差异代理完成工作后必须把所有checkbox打勾否则无法关闭ticket。这比单纯的“写完代码”要求高得多也有效防止了“看起来完成了”的幻觉。批量并行买回你的深度工作时间系统把工作组织成3-5个并行workstream的批次。每个批次内的任务由不同代理执行且尽量不重叠代码区域通过LLM辅助判断。批次执行是无监督的Claude的AskUser钩子被屏蔽代理被告知“ unsupervised但受质量和安全监控”。这避免了代理每15分钟就来问你问题把你拖回上下文切换的地狱。你只需要在批次开始前用一个“workstream update”技能生成下一批提示词然后把它们分别粘贴给对应代理。批次通常30分钟到4小时不等一天能跑2-4批。这带来的最大收益是你的注意力从“实时指挥多个代理”变成了“设计工厂流程 集中review 做真正需要人类创造力的工作”。强制完成机制与人工升级路径早期版本里代理经常在关键节点停下写了代码但不提交、不开PR、不合并、不部署、不打勾检查项。现在的做法是通过提示词 harness钩子强制代理完成完整闭环注册agent session并绑定ticket标记in progress提交PR并确保合并部署打勾所有验证项上传session transcript用于事后分析标记ticket closed或blocked标记session完成如果实在无法完成必须按标准格式发起人工升级Human escalation而不是随意扔给你一句“需要你加GitHub App”。升级提示词被严格约束假设人类非常忙、不知道上下文、需要最小思考成本。代理必须提供精确指令、脚本甚至把其他未阻塞的工作继续推进减少升级后的等待浪费。Linear与代理的微调配合Linear本身通过MCP很好用但为了让代理真正高效还做了三处针对性调整禁止代理直接覆盖ticket描述容易破坏验证清单改为只允许发diff补丁。给代理独立的身份app-based认证而不是用你的个人OAuth避免通知混乱和“你是我”的身份混淆。增强get_issue返回完整上下文评论、子任务减少代理需要额外询问的情况。这些小改动让代理能更好地“像团队成员一样”使用Linear而不是像临时工具。从 ad-hoc 多代理 到 结构化软件工厂维度Ad-hoc 多代理模式Linear结构化工厂模式关键权衡任务组织散乱、术语混乱Outcome树状层级 清晰合同前者灵活后者可审计可追踪完成度经常半途而废强制闭环PR合并部署打勾需要初始提示工程投入人类注意力全天碎片化切换与催促批次无监督 集中review大幅提升深度工作时间知识积累依赖你手动记录Ticket模板 transcript 持续改进系统性复利可测量性几乎为零可统计完成率、缺陷率、批次时长为后续优化提供数据基础这套系统目前还是“低技术原型”用桌面harness 手动粘贴提示但已经让代理在一个月内处理了约400个issue且显著改善了作者的生活质量。软件工厂的未来与我们的角色软件工厂不是科幻而是正在发生的工业革命。当前瓶颈依次是审查/验证 → 长时程规划 → token成本 → 规格定义 → 用户验证。基础能力已经具备剩下的主要是组合与经济学问题。人类在工厂里的角色将逐步转向更高杠杆的位置理解真正需要构建什么在工厂层面而非具体任务层面给出指令在研究、权衡、优化等需要创造力和直觉的地方提供人类洞见评估交付物是否符合专业与人性标准构建、维护并持续改进工厂本身正如Fred所说我们应该主动参与塑造这个未来而不是被动接受“一直review PR”的命运。方法论会从Scrum、XP演化成更像工业流程的标准化、测量与持续改进体系Toyota Production System的思想在这里非常适用。我起初对“软件工厂”这个词有些抗拒后来看到这套能真正把注意力还给人类的实践后才真正相信这是软件工程的必然方向而且现在正是我们这些一线工程师参与定义它的时候。现在轮到你你在使用AI编码代理时最大的痛点是什么是代理经常半途而废还是你被碎片化任务淹没或者你已经在尝试类似Linear 批量workstream的结构欢迎在评论分享你的具体卡点、已经有效的做法或者对“软件工厂”这个方向的看法。我们一起把这些实践打磨得更清晰、更可复制。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。
