正在加载，请稍候
2026年8月GitHub Copilot应用版上线/plan、/spar、/autopilot、/rubber-duck四条斜杠命令。本文拆解每条命令的实战场景与串联方法，附企业落地建议。
这不是该工具第一次引入斜杠命令——CLI 版早已有 /clear、/model 等终端操作。但应用版的设计思路截然不同：不再关心目录切换、终端权限这类环境操作，转而聚焦"怎么把一件事做对"的工作流本身。如果你在评估不同 AI 编码工具对企业开发流程的实际影响，2026 AI 开发工具链企业选型指南 提供了更完整的对比框架。
两套命令解决的是不同层面的问题：
| 维度 | CLI 版命令 | 应用版命令 |
|---|---|---|
| 关注点 | 终端环境（目录、权限、会话） | 开发工作流（规划、验证、执行、审查） |
| 典型命令 | /clear, /model, /add-dir, /cwd | /plan, /spar, /autopilot, /rubber-duck |
| 适用场景 | 终端内的快速操作 | 桌面端多会话、多阶段协作 |
| 上下文管理 | 手动指定目录 | 自动感知项目结构 |
对一个技术负责人来说，这意味着不能只看 AI 工具的代码采纳率，更要看它如何影响团队决策质量——而这四条新命令恰好围绕"决策"展开。
/plan 做的事情很朴素：动手之前，先让工具拆解任务、识别涉及的文件和依赖、给出推进路径。它和"直接让它写代码"的关键区别在于——后者默认你清楚自己要什么，前者先帮你确认你到底要什么。
三种典型用法覆盖了开发中最常见的决策场景：
/plan 我需要为我们的应用程序添加双因素认证。帮我拆解所涉及的工作，确定哪些文件需要修改，并概述一种实现方法。这条命令对团队的价值在于：它把老工程师"在脑子里过一遍"的隐性思维外化了。新成员可以通过其输出在 5-10 分钟内理解系统结构，而不是在代码库里盲目摸索 2-3 小时。
/spar（sparring partner 的缩写）的设计初衷是：在方案确定前，让工具扮演技术对手——质疑假设、指出潜在风险、提出替代方案。和那句"好主意，我来实现"完全相反。
使用场景集中在决策密度最高的环节：
/spar 我计划使用 Redis 作为我们产品 API 的缓存层。挑战我的方法，并指出我可能忽略的任何可扩展性或一致性问题。在企业级开发中，/spar 约等于一次轻量级架构评审——区别在于它 7×24 可用，不会因为人情回避尖锐问题。GitHub 连续两年（2025、2026）被评为 Gartner AI Code Assistants 魔力象限 Leader，这套对抗验证的设计思路很可能是其企业级竞争力的一个注脚。
四条命令中最激进的一条：给一个目标，工具自己完成所有中间步骤——找文件、改代码、跑测试。它和 /plan 天然衔接：先用 /plan 确认路径，再用 /autopilot 执行。
/autopilot 添加将用户报告导出为 CSV 文件的支持。找出需要改动的文件，实现该功能，并更新所有相关测试。/autopilot 把这个项目升级到最新版本的 React。找出破坏性变更，在需要的地方更新代码，并确保测试套件全部通过。但有一个重要前提：/autopilot 的输出质量高度依赖 /plan 阶段的输入质量。没先通过 /plan 或 /spar 理清需求边界，它会在错误方向上高效执行。用 GPT-5.6 Sol 最新数据显示，事实错误率相比 GPT-5.5 Instant 下降了 68%——模型越来越准确，但准确性仍然建立在清晰指令之上。把决策交给 /plan + /spar，执行交给 /autopilot，这是目前最优的分工模式。
/rubber-duck 的名字致敬了程序员经典调试技巧——对着橡皮鸭解释代码。但实现比橡皮鸭强得多：它使用一个不同的模型独立审查代码或计划，捕捉主模型可能遗漏的盲点。
这解决了 AI 辅助开发中的核心问题：模型自审查的局限性。不同模型的训练数据、推理偏好和盲区各不相同。/rubber-duck 的独立模型相当于给代码提交加了一道交叉验证——类似于两人 code review 中的第二个人，但审查范围可以覆盖整个代码库而不仅是 diff。
三条最实用的触发时机：
/rubber-duck 审查我们为添加双因素认证所制定的实施计划。指出我们可能忽略的任何安全漏洞或实现陷阱。一个真实串联流程，以"给用户系统加 OAuth 2.0 登录"为例：
这个闭环把 AI 编码从"人写 prompt → AI 出代码 → 人 review"的单向流程——平均每个 PR 需要 3-5 轮 review——升级为"人定方向 → AI 拆解 → AI 挑战 → AI 执行 → AI 交叉审查 → 人决策"的多阶段协作。每一步人的角色从操作者变成决策者，review 轮次有望压缩到 1-2 轮。
对于正在引入 AI 编码工具的技术团队，四条实用建议：
CLI 版面向终端操作，App 版面向工作流。/add-dir、/cwd 管理的是文件系统；/plan、/spar 管理的是开发决策。两者共有的只有 /clear 和 /model。
不适合。探索性任务（需求不明确）、高风险模块（支付、安全、数据迁移）、需要跨团队协调的任务，都不该直接交给它。最适合的是"目标清晰、边界明确、有测试可验证"的独立任务。
/spar 是方案阶段的对抗——动手之前挑战假设，用的是主模型。/rubber-duck 是代码实现后的审查——用独立模型检查成品。一个前置、一个后置；一个聚焦决策质量、一个聚焦实现质量。
最大的隐性要求：团队需要"愿意被挑战"的文化。如果工程师把 /spar 的质疑当作冒犯，流程就跑不起来。另外，/plan 的输出需要有人能判断质量——工具降低了门槛，没有消除门槛。