GitHub Copilot CLI：先对齐计划，再授权执行与纠偏
GitHub Copilot CLI: Plan before you build, steer as you go
01 · 先读这里
为什么推荐
复杂 Agent 最危险的时刻往往不是报错，而是“理解错了却开始执行”。GitHub 把规划、澄清与授权拆成明确的界面节点：先看计划，再选择范围，拒绝权限时仍能给出修正方向。对发布、批量配置、交易等业务场景很有参考价值。
02
这篇讲什么
GitHub Copilot CLI 把复杂编码任务分成先规划、再执行的协作过程。用户通过快捷键进入 Plan mode，Copilot 在动手修改代码前分析目标、提出澄清问题，并将结构化实施计划放到专门面板供确认；问答可用选项让范围和假设更明确。执行过程中，用户还能继续发送指令，或在拒绝工具权限时附带原因，使 Agent 调整做法而不是直接终止。官方更新提供计划模式、澄清选项和拒绝反馈的终端截图。这个案例可迁移到任何高风险、长步骤、需要人类决策的业务 Agent。
扩展评分
一句话带走
把“先想清楚、再动手、拒绝后仍可纠偏”设计成明确状态。
交互范式
交互到底改变了什么
- 原来的交互
- 用户提出任务后直接生成/执行，误解范围时往往需要事后返工；权限拒绝可能打断任务。
- Agent 带来的变化
- 增加明确的 Plan mode、ask_user 澄清和计划确认；执行中允许追加指令与拒绝原因反馈。
- 用户的新成本
- 用户需要花时间审阅计划、回答关键问题、决定授权边界；多一次确认换取较低的误执行风险。
- 关键交互机制
- Shift+Tab 切换 Plan mode；ask_user 结构化选项；专用计划审阅面板；拒绝工具调用时的行内反馈。
- HCI 依据
- 原文称 Plan mode 是用户请求较多的能力，但未提供用户研究方法或数据。
- 团队设计信号
- 将用户澄清、计划预览和工具权限视为同一任务生命周期的不同决策节点。
设计策略
从具体设计中学习
01
在执行前设置独立计划态，而不是直接开工
- 看图重点
- 看 Plan mode 明确状态提示与尚未开始执行的任务结构。
- 图像作用
- 官方产品截图
- 问题
- 复杂需求可能在目标不清时被 Agent 直接实施。
- 方案
- Shift+Tab 进入 Plan mode，先分析请求、澄清并形成结构化实施计划。
- 为什么这样做
- 把“计划”与“执行”拆开，让用户有机会在代价发生前修正理解。
- 取舍
- 根据方案推断：简单任务也要求完整计划可能增加操作成本。
原文依据与解读
before Copilot starts implementing
- 译文
- 在 Copilot 开始实施之前。
- 解读
- 计划不是冗长思考文本，而是可审阅的行动方案。
可迁移规则高风险动作默认先进入计划/预览态，待确认后才执行。
02
把模糊范围转成可回答的澄清选项
- 看图重点
- 看问题如何被分解成多个明确的可选回答。
- 图像作用
- 官方产品截图
- 问题
- 用户的自然语言请求可能缺少范围、方案或偏好。
- 方案
- ask_user 工具提出澄清问题，提供选项，计划在对齐后进入执行。
- 为什么这样做
- 让用户只补关键决策，减少来回解释和误读。
- 取舍
- 根据方案推断：选项设计可能遗漏用户真实意图，应保留自由输入或其他选项。
原文依据与解读
confirm assumptions about feature scope
- 译文
- 确认对功能范围的假设。
- 解读
- 澄清控件是控制权交接，不只是表单补全。
可迁移规则Agent 遇到影响执行的歧义时，先提出有限的关键选择题。
03
让权限拒绝附带修正理由，保持任务连续
- 看图重点
- 看拒绝操作之后用户仍能补充文字反馈，Agent 可以调整路径。
- 图像作用
- 官方产品截图
- 问题
- 拒绝工具调用后，Agent 可能失去继续执行的方向。
- 方案
- 在拒绝权限请求时允许附带行内反馈，Agent 根据反馈调整方案。
- 为什么这样做
- 把否定操作转化为新的约束，避免重新开始整段任务。
- 取舍
- 根据方案推断：用户可能反复拒绝造成状态复杂，需要显示当前有效权限。
原文依据与解读
inline feedback on rejection
- 译文
- 拒绝时的行内反馈。
- 解读
- 拒绝不是二元开关，而是可带理由的约束更新。
可迁移规则权限弹窗提供拒绝原因/替代方案输入，并回到可恢复的任务状态。
推理链
从问题到设计判断
- 问题
- 复杂任务执行前缺乏方案对齐，权限拒绝后易中断。
- 证据
- GitHub 官方更新展示 Plan mode、ask_user 和拒绝反馈截图；无对照实验。
- 判断
- 关键不确定性和权限边界应由用户显式决定。
- 设计策略
- 计划预览 + 结构化澄清 + 行内拒绝理由。
- 结果
- 官方实现了上述操作路径；误执行率或效率改善数据原文未提供。
迁移原则
带回自己的项目
- 执行会改动业务数据时先展示计划并设置确认点。
- 澄清问题只问影响决策的变量，提供选项和自由补充。
- 权限拒绝允许填写原因并提供恢复路径。
03
它真正解决的问题
复杂 Agent 任务可能在理解不完整时直接执行；权限被拒后缺少继续协作的恢复路径。
04
作者用了什么依据
GitHub 官方 changelog 逐项说明 Plan mode、ask_user、计划面板与拒绝反馈，并附对应终端截图。
05
核心设计洞察
让用户在 Agent 行动前决定方案，在行动中还能解释“为什么不允许”。
06
具体做了什么
用独立 Plan mode 延后执行；用可选答案的澄清交互消除歧义；权限拒绝附带可执行反馈。
07
为什么这样做
Problem：任务理解与权限决策容易造成误执行/中断 → Evidence：官方提供计划、澄清、拒绝反馈三类 UI → Judgment：决策应在关键节点交还用户 → Strategy：Plan mode + ask_user + rejection feedback → Result：支持先对齐后执行和被拒后调整；效果数据原文未提供。
08
有什么关键取舍
增加前置澄清与计划确认会减慢简单任务，但可降低复杂任务的理解偏差（根据方案推断）。
09
最终有没有验证
原文未提供
从这篇学习
值得学什么
Agent 不能把“知道怎么做”与“得到执行许可”混为一谈。
计划态、执行态和被拒绝后的恢复态需要不同的交互控件。
原文未提供
在高代价动作前先消除范围不确定性，再把人类判断嵌入授权节点。
拒绝权限不是失败终点，也可以是带理由的协作反馈。
按 Plan → Clarify → Reject & Steer 的任务时序组织案例。
10 · 迁移
可以带走什么
对发布、配置、交易、批量修改类 Agent 先展示可审阅计划，再允许授权与拒绝原因反馈。
你的反馈
这篇对你有用吗？
反馈只会记录下来，不会自动改变推荐算法。