Copilot多阶段协作如何衔接计划与审查

代码写得更快，需求理解、审查和线上排障却未必跟得上。原文围绕 GitHub Copilot 的多阶段 Agent 工作流，讨论了一个更实际的问题：怎样把 AI 产出的计划、代码和诊断接起来，并让人保留关键决定权。

它最有价值的部分，是把注意力放在阶段交接上：上一阶段留下什么，下一阶段读取什么，出错后从哪里重来。不过，文中的架构推测和示意代码，需要与已经确认的产品能力分开看。

四个阶段，交接的到底是什么

原文把开发工作拆成规划、生成、审查和生产调查四个阶段，各阶段需要的上下文不同，交付物也不同。

规划阶段从 issue 或功能请求出发，生成包含任务拆分、目标文件和修改范围的结构化计划。人先审核计划，再让 Agent 写代码。这样可以尽早发现需求理解偏差，避免代码已经改了一大片，才发现方向错了。

生成阶段读取获批计划和相关代码，输出 diff，而不是整份文件替换。审查阶段再拿 diff 对照计划与代码库规范，标出潜在问题，最后由人决定是否合并。

生产调查处理的是另一类材料：日志、调用链和近期变更。Agent 尝试关联错误与代码修改，提出可能的根因，人负责验证诊断、选择处理方式。

这套工作流的关键产物，是能被下一阶段继续使用的证据。

原文强调每次阶段转换都要经过人工批准，但它给出的代码并没有完整实现所有关口。因此，更适合把它理解为设计主张，不能直接视为一套已经落地的完整审批机制。

为什么不能一直往聊天记录里塞上下文

长对话能保留文字，却不保证下一轮调用准确记住最初的修改范围。原文提出三类需要持久保存的材料：计划、代码变更、调查证据。

计划可以是 JSON 或 Markdown 任务列表，记录文件路径和修改说明，放在工作区中；diff 应关联具体计划项，便于审查时核对；调查证据则包含日志片段、trace ID，以及错误模式与代码变更的对应关系。

大白话解释，就是把任务进度写成可读取的工作记录，让下一阶段有明确的输入来源。

下面这段示意代码展示了最直接的数据交接：规划阶段保存计划，生成阶段重新加载计划，并据此获取相关文件。

    def planning_stage(self, issue_text):
        # Agent generates plan
        plan = self.agent.generate_plan(issue_text)
        self.context.store("plan", plan)

        # Human gate
        if not self.human_approves(plan):
            return self.planning_stage(issue_text)  # retry

        return plan

    def generation_stage(self):
        plan = self.context.load("plan")
        codebase_context = self.context.get_relevant_files(plan)

        # Agent generates code
        diffs = self.agent.generate_code(plan, codebase_context)
        self.context.store("diffs", diffs)

        return diffs

重点看 self.context.load("plan")：生成阶段从共享存储读取计划。这里的 generate_plan、get_relevant_files 和 generate_code 都是作者示意代码中的方法，不能当作 Copilot 已公开的 API。

上下文还需要筛选。规划到生成，需要任务、文件、范围、相关代码片段和受影响文件的依赖关系；进入调查时，则需要部署时间等运行信息。

作者推测 GitHub 可能结合向量搜索与结构化元数据完成路由，但也明确说内部状态存储没有公开。具体怎样检索、裁剪和更新上下文，原文没有给出实现证据。

人工关口能兜住哪些错误

原文列出三类失败：代码偏离获批计划，审查通过后仍在线上出错，以及跨阶段丢失最初意图。

对应的恢复方式也不同。偏离计划，可以对比 diff 涉及的文件与计划目标，拒绝后重新生成；线上出错，可以关联近期合并与新增错误，由人回滚，再让 Agent 根据错误信息修复；需求理解已经跑偏，则应回到规划阶段澄清。

不过，人工关口也会成为新的等待点。原文没有给出阶段转换延迟、上下文体积增长、重试率、审查误报率这些数据。没有这些指标，就无法判断省下的编码时间，是否又消耗在排队审批和反复生成上。

安全风险同样贯穿输入链路：issue 可能夹带提示注入，代码库可能存在恶意示例，日志也可能被伪造错误模式污染。计划审查、代码审查和诊断确认能提供防线，但原文也承认，面对看起来合理、细节却错误的输出，人未必能识别。

人工批准能提供纠错机会，批准本身不能证明结果正确。

我的判断

我认同把计划、diff 和调查证据拆开保存。相比把所有材料塞进一段长对话，这种组织方式更便于追溯：为什么改这个文件，依据哪条需求，诊断引用了哪段日志，都有机会查清楚。

但原文没有展示实测结果，也没有给出与普通 Copilot 使用方式、直接生成后开 PR 等流程的对照数据。它关于效率和可靠性的判断，仍属于架构分析与经验之谈。

文章把这套模式称为 GitHub 的首个官方框架，却没有在所给正文中列出具体配置、可运行 SDK 或完整产品入口；实现示例也只是简化代码。读者可以借鉴其组织方式，不能据此认定 Copilot 已提供文中描述的全部机制。

适用前提也比较明确：团队已有清晰阶段边界，有人承担审查，代码库具备较好的测试覆盖。小团队若每一步都等待同一个人确认，流程可能更慢。安全关键系统和密码学场景，也不能靠一次人工点头接受「似乎正确」的代码。

相比全自主 Agent，这套方案保留了更多人工控制，同时需要持续投入审查时间。值不值得采用，应看任务风险、审查成本和失败后的恢复难度。

能拿来做什么

• 在日常 AI 编程中，先让 Agent 把任务、目标文件和修改范围写进 Markdown 计划，确认后再开始生成，并在需求变化时同步更新计划。
• 审查前端或 Node 项目的 diff 时，把获批计划一起交给 Agent，要求它说明每处变更对应哪项任务，方便人发现超范围修改和遗漏。
• 用 Agent 辅助线上排障时，提供相关日志片段、trace ID、部署时间和近期变更，并要求诊断指出依据，再由人决定是否回滚或修复。
• 如果准备推广到团队，先记录人工等待时间、拒绝重试次数和审查误报情况，用实际数据判断多阶段流程是否节省了总时间。