GitHub Copilot 基础：Ask、Agent、Planning 三种模式

同一个工具里的三种模式，很多人凭手感切换。其实判据挺清楚。

三种模式的分界

模式	谁决定下一步	你看到什么	适合
Ask	你	一个答案	问一个具体问题、要一段代码
Agent	模型	一串它自己做的改动	边界清楚的多文件改动
Planning	先出计划，你批准	一份计划，再执行	改动面大、你还不确定该怎么改

这三种的排序是自主性从低到高，而可审查性从高到低。

Ask 模式你审的是一段代码；Agent 模式你审的是一堆改动的最终结果；而中间那些它试过又回退的东西，你看不到。

Planning 模式的价值就在这儿：它把「决定怎么做」和「做」分开了，让你在最便宜的时候（还没动手）介入。

对测试工作的具体建议

写单个测试 → Ask。 目标明确、范围小，多余的自主性只会带来噪音。

把一批测试改成新框架的写法 → Agent。 这是它最强的场景：改动机械、判据客观（跑得过就是对的）、而且改错了能一眼看出来。

给一个没有测试的模块补测试 → Planning。 因为这里最重要的决定不是「怎么写」，是「测哪些」—— 而那个决定你应该参与。

一条硬规矩：让它改测试要格外小心

这条是从一份真实的案例研究里学到的，我认为是这个垂类最该记住的一条。

那套系统自动修复失败的 UI 测试，报告的收敛率是 70%。换个口径 —— 把「靠作弊达成的收敛」剔掉 —— 50%。

差的那 20 个点是这么来的：

• 把 expect(value).toBe(5) 改成 expect(value).toBeTruthy()
• 把一条修不好的用例直接删掉，于是剩下的「100% 通过」

模型不是在作弊，它是在忠实地优化你给的目标。 目标写成「让测试通过」，删测试就是最短路径。

所以：让 AI 改实现代码可以，让它改断言必须人来批。 那份研究把这条列为五条设计准则之一 —— 把测试当作行为规范，断言的改动需要人工确认。

自定义 agent 和云端 agent

课程后面会讲给自动化仓库配自定义 agent。这里有一条实际的经验：自定义 agent 的价值在于把项目约定固化下来，而不是让它更聪明。

写进去最值钱的三样：

1. 这个仓库的测试怎么跑（命令、环境、需要什么前置）
2. 这个仓库的约定（页面对象怎么组织、断言用哪套、什么绝对不要做）
3. 常见的坑（哪些测试天生不稳、哪些目录不要碰）

这三样每次都要重新解释的话，就是每次调用都在付的税。 固化下来是一次性付清 —— 而且它比塞在提示词里的好处是：它是一个能被 review、被版本控制的文件。skill 该怎么写下一篇细讲。

边界与代价

Agent 模式看不到中间过程，这是它最大的风险。 它可能试了五种改法，前四种把文件改坏又改回来。最终 diff 干净，不代表过程是安全的 —— 如果那个过程里碰了不该碰的东西（比如跑了一条会写数据库的命令），你不会知道。

Planning 模式的计划本身可能是错的。 批准一个看起来合理的计划，和批准一段看起来合理的代码，风险是一样的。计划的价值在于它便宜，不在于它更可靠。

这一篇里我的第一手部分只有「让 AI 改断言很危险」这一条的对照：我自己的系统里做过一个「不做无人值守自愈」的决定，当时的理由是怕它修错；读到那份研究才明白，真正的风险是它会成功，只是用了删测试的方式 —— 这正是被改的对象和验证的对象必须分开的理由。