夜雨聆风一句话总结：AI 编程助手的效率，不取决于它能不能马上写代码，而取决于团队能不能把“先想清楚、再动手、有人复核”变成默认流程。
很多人第一次使用 AI 编程助手，都会从同一个动作开始：打开聊天框，输入一句“帮我把这个功能写出来”。
这很快，但也很容易把工程工作压缩成一次不可见的交接。模型为什么这样拆任务、它漏掉了哪些风险、哪些文件被改了，往往要等到代码已经生成后才开始追问。
GitHub Copilot 应用最近介绍了一组斜杠命令。表面上看，这是给聊天框增加快捷入口；更值得注意的是，它把 AI 编程从“问一句、答一段”，推进成了几种明确的工作模式。
“/”不是快捷键，而是工作流的入口
在 Copilot 应用里输入 /，会出现与当前上下文相关的命令。它们不只是让用户少打几个字，而是在提醒使用者：同一个模型，可以被放进不同的责任位置。
你可以让它先规划，也可以让它反驳你的方案；可以让它自动执行，也可以让另一个模型从旁边重新审查。
这和普通聊天最大的区别，是把“我要什么”与“现在允许模型做什么”分开了。
工程上最怕的不是模型不会写，而是模型在错误的阶段做了正确的事：需求还没澄清，就开始改代码；架构还没讨论，就开始批量重构；风险还没暴露，就进入自动执行。
先用 /plan，再让模型动手
/plan 的价值不在于它能生成一份漂亮的计划，而在于它强迫任务先经过一次结构化拆解。
一个真实的功能需求，至少应该先回答几件事：
哪些文件和模块会受到影响？ 依赖关系和数据流怎么变化？ 哪些地方可能造成兼容性或迁移风险？ 应该分成几步实施，哪一步可以先验证？
对于两因素认证、支付流程、通知系统这类任务，直接写代码往往会把复杂度藏起来。先让模型列出影响面，团队才有机会在成本最低的时候纠正方向。
计划不是文档工作，而是给自动执行设置一个起点。
用 /spar 让模型站到你的对面
很多 AI 交互的问题在于，模型太容易顺着用户的方案继续往下写。你提出用 Redis，它就开始写缓存代码；你决定用 GraphQL，它就帮你补 schema。
/spar 的角色不同：它要求模型质疑假设，主动指出替代方案、边界条件和潜在副作用。
这一步尤其适合三种场景：
架构已经有倾向，但团队还没有把反对理由说透； 迁移或发布计划看起来可行，却可能有回滚盲区； 性能优化有明确收益，但也可能伤害一致性或用户体验。
它不是让模型替你做决定，而是把“反对意见”提前放进决策过程。真正重要的不是它最后说选 A 还是 B，而是它有没有逼你补上原先没写出来的条件。
/autopilot 应该是流程的第三步
自动执行很诱人，但不应该成为默认的第一步。
当任务已经完成拆解，主要风险也被讨论过之后，/autopilot 才适合接管多步骤实施：修改文件、更新依赖、补测试、整理文档，再根据反馈继续迭代。
这里有一个常被忽略的区别：自动执行不是“模型更聪明了”，而是模型获得了更长的行动链。行动链一旦变长，团队就不能只看最终 diff，还要关心中间经过了哪些决策点。
因此，自动模式至少要配套三件事：
明确任务边界，不要把“顺便优化一下”混进目标； 为关键写操作保留可回滚的提交点； 要求测试和验证结果随任务一起返回，而不是只看“完成了”。
/rubber-duck 说明：第二个模型不是装饰
复杂重构之后，最难发现的通常不是语法错误，而是自己已经习惯了的假设。
/rubber-duck 让另一个模型独立审查方案，检查盲点、边界条件和不必要的复杂度。它的意义不是增加一个“AI 评委”，而是把复核从同一条思考路径里拎出来。
这也提示团队：未来的 AI 编程流程，不一定只有一个模型从头做到尾。一个模型负责推进，另一个模型负责挑战；前者追求连续性，后者负责打断惯性。
真正可复用的是这条顺序
如果把这些命令组合成一条日常工作流，可以从一个简单版本开始：
/plan：写出影响面、步骤和风险；/spar：让模型攻击方案，而不是继续迎合；/autopilot：只在边界清楚后执行多步工作；/rubber-duck：在合并或发布前做独立复核；人来决定：哪些风险可以接受，哪些动作必须停下。
/create-canvas 和 /orchestrate 则适合把任务进一步扩展到可交互界面、多个仓库或并行工作流。它们的共同方向是：AI 编程正在从一个聊天窗口，变成一组可以切换、组合和审计的工程状态。
别把命令数量当成生产力
斜杠命令当然可能变成另一份需要背诵的菜单，但这不是重点。
重点是团队终于可以把一些隐含的工程纪律，直接写进人和模型的协作路径里：先计划，允许反对，再执行，最后复核。
没有这条顺序，再多命令也只是更快地产生代码；有了这条顺序，命令才开始承担流程控制的作用。
AI 编程的下一步，不是让模型更像一个不知疲倦的程序员，而是让整个工程流程更清楚地知道：什么时候该放手，什么时候必须停下来想一想。
参考资料：Jacklyn Carroll，《A guide to slash commands in the GitHub Copilot app》，GitHub Blog。