微软Copilot连错3次版本号后，他用1个指令让AI自己修Bu

去年有个数据挺有意思：GitHub Copilot用户平均每周接受AI建议的代码量，相当于一个中级开发者3天的工作量。但没人统计过其中有多少是错的——比如把不存在的库版本当成漏洞报给你。

瑞士工程师Nicolas Fränkel最近就踩了这个坑。他用Copilot CLI分析一个搁置数月的代码库，AI甩给他12条改进建议，还主动要求创建GitHub Issue。结果3条关于"版本过期"的警告全是幻觉——他用的版本比AI的训练数据还新。

这不是Copilot独有的问题。所有大模型都在吃过去的语料，而软件世界的版本号每天都在变。Fränkel的处理方式很产品经理：先批量验证，再决定投入。12条建议里他关了8条，剩下4条确实有价值。这时候他做了个反直觉的决定——不自己修，让AI去修。

子代理（Sub-agent）是2024年下半年开始在AI工程圈冒头的概念。简单说，就是让AI不只做建议者，而是成为执行者。

Fränkel给Copilot的指令很具体：为每个待修复的Issue启动独立子代理，拉取代码、创建隔离分支、实施修复、补测试、跑通全部用例、推送到GitHub、发起PR。一条指令串起7个动作，全程不需要他盯着。

但这里有个新手陷阱。很多人第一次用子代理时，会忍不住在提示词里塞满上下文——生怕AI做错。Fränkel的经验恰恰相反：前置的筛选步骤已经帮你完成了信息收集，子代理阶段应该信任之前的判断，而不是重复论证。

他引用了Anthropic工程师Claude Code的"标注循环（Annotation Cycle）"方法论：人类负责定义问题和验收标准，AI负责在约束内探索解法。两者交替，而不是一方全程兜底。

Git Worktree：让多个AI同时干活的秘密

子代理并行运行的最大技术障碍，是Git的默认行为。常规操作下，所有分支共享同一个工作目录。如果两个代理同时切分支，文件系统会直接冲突。

Fränkel的解法用了Git一个冷门功能：worktree。这个2015年引入的命令允许把不同分支映射到独立文件夹，物理隔离工作空间。

具体命令很简单：git worktree add <路径> <分支名>。执行后，你的仓库会多出一块完全独立的目录，有自己的HEAD、自己的暂存区、自己的未提交修改。主仓库和worktree之间通过裸仓库（bare repository）共享对象数据库，磁盘开销极小。

这意味着什么？Fränkel可以同时启动4个子代理，每个代理操作自己的worktree，彼此零干扰。等它们各自推完分支、发起PR，worktree可以直接删除，干净得像没发生过。

这个方案的成本是认知负担。大多数开发者用了十年Git，可能从来没碰过worktree。Fränkel自己也承认，他是在解决"多个代理抢同一个.git目录"的问题时，才翻文档找到这个解法。

更隐蔽的坑在权限层。Copilot CLI默认连GitHub MCP Server是只读模式，能查Issue不能建。Fränkel的绕法是先用gh命令行工具完成OAuth认证，再在同一终端会话里启动Copilot。这样Copilot会继承gh的凭证，获得完整读写权限。

这个细节说明一件事：当前AI工具链的权限模型还是拼凑状态。没有统一标准，只有各种临时方案。

从"AI帮我写代码"到"AI替我走完流程"

Fränkel的实验发生在2025年4月初，距离OpenAI发布GPT-4的函数调用能力已经过去近两年。但"让AI独立完成端到端工作流"这件事，至今仍是少数派实践。

阻力不在技术，在信任阈值。当AI写错一行代码，你可以Review；当AI建错一个分支、推错一个远程、发起PR时写错标题，清理成本指数级上升。

Fränkel的应对策略是分层验收。子代理的每个阶段都有硬性卡点：测试必须全绿才能继续，PR必须按命名规范创建。这些约束写在系统提示里，成为AI的"操作手册"而非"建议参考"。

他分享的实际提示词结构值得拆解：

第一层是工具绑定——明确指定gh用于GitHub交互、git worktree用于分支隔离。第二层是流程强制——用"必须""才能"等词建立依赖链条，而非并列罗列。第三层是输出规范——PR标题模板、分支命名模式，全部量化。

这种写法接近给人类外包写需求文档：不给模糊空间，不给即兴发挥余地。

结果如何？Fränkel没提具体数字，但从上下文推断，4个Issue中至少有部分完成了全流程自动化。考虑到他手动关闭了8条AI建议，最终自动化率可能在30%左右——不算高，但指向一个明确趋势。

子代理的边界：什么时候该喊停

Fränkel的实验也暴露了当前技术的硬边界。他在文章末尾留了道思考题：如果子代理在实施过程中遇到设计决策，应该自主判断还是暂停请示？

这个问题没有标准答案。他的倾向性很明显——前期筛选越严格，执行阶段越应该放手。但"严格"的定义因人而异。有人觉得需要架构师评审方案，有人觉得只要测试通过就能合并。

更现实的约束在成本端。子代理并行运行意味着多倍的Token消耗。Fränkel的4个Issue如果全部走通，单次实验的API费用可能超过手动修复的人力成本。只有当规模扩大——比如40个Issue、400个Issue——自动化优势才会显现。

这解释了为什么子代理目前集中在两类场景：一是开源项目的批量维护（Issue triage后自动修复标准化问题），二是企业内部的代码治理（统一升级依赖、补全测试覆盖）。两者共同点是问题类型可预期、验收标准明确、失败成本可控。

Fränkel没有提他的实验最终合并了几个PR。但他在文末开放了一个反馈通道，邀请读者改进他的提示词模板。这种姿态本身说明：子代理的最佳实践还在形成期，没有权威答案，只有持续迭代。

如果你现在打开Copilot CLI尝试同样的流程，大概率会遇到Fränkel没写到的坑——可能是某个GitHub Action的权限变更，可能是Copilot对worktree路径的解析差异。这些细节不会出现在任何文档里，直到有人踩过、写过、分享过。

所以最后一个问题留给你：当你的AI助手连续三次报错版本号时，你会选择手动纠正它，还是设计一套机制让它自己发现错误、自己修正流程？