Copilot把3个issue判了死刑

4月9日，瑞士开发者Nicolas Fränkel在博客记录了一次真实的AI协作实验：让Copilot分析代码库，生成12条改进建议，结果3条直接被证伪——版本号根本不存在。剩下的9条里，又有一半经人工复核后关闭。最终4条存活，他用sub-agents（子代理）在4小时内全部落地成PR。

这不是演示视频，是带血的生产日志。

Fränkel的实验戳中了一个正在蔓延的痛点：当AI coding assistant从"聊天框里的顾问"变成"能动手改代码的执行者"，中间那道质量闸门该怎么设？他的答案是——别指望AI自我纠错，把 triage（分类筛选）和 execution（执行）拆成两个独立阶段，中间必须有人工介入。

这篇文章的价值不在于"sub-agents很酷"，而在于记录了一套可复现的协作流程：如何让AI在自主执行前，先经过足够严格的事实核查。Fränkel本人是资深Java开发者、Apache Maven提交者，现任Datadog开发者倡导者。他的实验环境是Copilot CLI + GitHub MCP Server + git worktree，目标代码库是一个他离开数月后重新接手的项目。

第一阶段：让Copilot"自由发挥"，收获12条建议

Fränkel的初始prompt极其简单："analyze the following codebase and report to me improvements and possible bugs." 这种模糊性是故意的——既给AI留出发现意外问题的空间，也接受它会产出垃圾。

Copilot返回了12条。Fränkel没有直接执行，而是要求它为每条创建GitHub issue，附带标签和优先级。这一步本身就在测试AI的上下文理解：能否把模糊描述转化为可追踪的工作项？

结果很快暴露问题。3条issue被标记为"版本不存在"，但Fränkel实际使用的版本比Copilot的训练数据更新。他直接关闭，标注"won't fix"。这不是AI的"幻觉"，是知识截止日期的硬边界——一个所有LLM产品都无法回避的约束。

剩下的9条进入人工复核。Fränkel逐条独立判断，同时用Copilot辅助交叉验证。最终5条被关闭，4条通过。存活率33%，但Fränkel认为这个比例"相当健康"——AI的价值不是替代判断，而是把人的注意力压缩到值得深入的区域。

这里的关键动作是"triage"（分类筛选）。Fränkel在另一篇文章《How I Use Claude Code》中详细阐述过他的"Annotation Cycle"：每次与AI协作时，必须留下足够的审查痕迹，确保后续执行者（无论是人还是另一个AI）能复现决策依据。这次实验中，triage阶段产出的上下文——为什么接受、为什么关闭、每条issue的验证过程——直接成为sub-agents的输入燃料。

第二阶段：sub-agents的启动条件与致命陷阱

4条存活issue进入执行阶段。Fränkel选择用sub-agents并行处理，但他的prompt设计暴露了一个反直觉的约束：sub-agents的自主性越高，前置的triage就必须越重。

新手常犯的错是"信息过载式prompt"——因为担心AI做错，就把所有可能的背景、约束、例外情况塞进初始指令。Fränkel尝试过这种路径，发现效率极低。sub-agents的价值在于减少人工干预，如果每步都要人确认，还不如自己写代码。

他的解决方案是把"信息收集"前置到triage阶段。当人工复核决定接受某条issue时，其实已经完成了深度调查：代码位置、相关依赖、潜在副作用、测试覆盖情况。这些上下文被结构化地附加到issue描述中，成为sub-agent的启动包。

Fränkel公开的prompt模板包含6个连续动作：

1. 用gh工具获取issue详情
2. 用git worktree创建独立工作目录
3. 实现功能或修复
4. 必要时补充测试
5. 全量测试通过
6. 推送分支并按命名规范创建PR

每个动作都是原子化的，但依赖关系清晰。Fränkel特别强调git worktree的作用：常规git branch会让多个sub-agents在同一个目录冲突，worktree把每个分支映射到独立文件夹，实现真正的并行。

技术细节需要展开。Copilot CLI默认连接GitHub MCP Server，但只读。要创建或更新issue，必须在终端用gh完成认证，然后在同一终端运行Copilot CLI，才能继承完整权限。这是一个容易被忽略的集成点——很多开发者卡在"AI说没权限"的环节，其实是认证流程没打通。

第三阶段：4小时产出的真实成本

Fränkel没有公开4条PR的具体内容，但提供了足够判断效率的线索：从triage完成到全部PR创建，耗时约4小时。这个时间包含sub-agents的执行、测试运行、以及必要的人工复核。

对比传统工作流：人工分析代码库→识别问题→创建issue→分配优先级→开发修复→测试→PR。Fränkel的实验把前两步交给AI，中间插入严格的人工筛选，最后把执行再次外包给AI。总人时投入集中在triage阶段，但避免了执行阶段的上下文切换损耗。

一个值得注意的细节是测试策略。Fränkel要求"all tests must pass before you continue"，但没有说"必须创建新测试"。他的判断标准是：如果issue本身涉及测试覆盖不足，才强制补充；如果是纯逻辑修复，现有测试通过即可。这种弹性避免了过度测试的官僚成本，也保留了关键路径的质量底线。

PR命名规范是另一个被明确写入prompt的约束。Fränkel没有透露具体模式，但强调"using the following naming pattern"——说明他在组织层面有统一的branch/PR管理规则，sub-agents只是执行者。这暗示了一个更深层的设计原则：AI协作的有效性，取决于组织流程的标准化程度。如果每个开发者有自己的命名习惯，sub-agents就无法规模化复用。

Fränkel没说的：什么情况下这套流程会崩

博客文章是成功案例，但Fränkel的叙述中埋了几个警示信号。

首先是知识截止日期问题。3条"版本不存在"的误报，说明Copilot的训练数据滞后于实际依赖版本。这不是个例，是系统性风险。如果代码库大量使用前沿库或内部私有依赖，AI的分析基座就不稳。Fränkel的应对是人工复核，但这在规模扩大时会成为瓶颈。

其次是triage的质量依赖。Fränkel能高效筛选，因为他熟悉代码库历史。如果是全新接手的项目，或者issue涉及跨模块的复杂交互，人工复核的时间成本会急剧上升。33%的存活率在他手里是"健康"，在缺乏经验的开发者手里可能是"漏判"或"误判"的温床。

第三是sub-agents的故障恢复。Fränkel提到"you can still technically interact with the sub-agents when they work, but it drops their value significantly"——技术上有干预能力，但会大幅贬值。这意味着一旦sub-agent走入歧途（比如错误理解issue描述、选了错误的实现路径），纠正成本可能高于重启。他没有记录4条PR中是否出现这种干预，但"significantly"这个词暗示了负面经验。

最后是权限与安全的张力。gh认证在同一终端继承，是便利也是风险。如果sub-agent被prompt注入攻击，或者执行了意外的 destructive 操作，权限边界就是最后一道防线。Fränkel的实验是单人项目，但推广到团队场景时，这个问题会放大。

这些不是否定sub-agents的价值，而是划定适用边界。Fränkel的实验发生在"离开数月后重新接手"的上下文——代码库有历史积累，但相对稳定；issue规模可控（4条并行）；开发者本人是资深工程师，能快速判断AI产出的质量。这三个条件缺一不可。

行业参照：sub-agents正在从demo走向工具链

Fränkel的实验不是孤例。2024年以来，主流AI coding工具都在向"agentic"方向演进：Claude Code的"computer use"、OpenAI的Operator、Devin的端到端开发承诺。但生产环境的落地节奏明显滞后于演示视频——问题恰恰卡在Fränkel记录的这些环节：triage质量、权限管理、故障恢复、组织流程适配。

一个可对比的案例是Anthropic在2024年10月发布的Claude 3.5 Sonnet with computer use。官方演示中，Claude能自主浏览网页、填写表单、执行多步骤任务。但早期用户反馈显示，在真实业务系统中，Claude的"自主"往往卡在权限边界或异常处理——它能处理happy path，但对edge case的恢复能力有限。