大多数人第一次看到 GitHub Copilot CLI 里的 /research，都会下意识把它理解成“更会搜索的问答命令”。这个理解不算错，但也只对了一半。
/research 真正有意思的地方，不是它会不会替你搜，而是它把任务从“回答一个问题”切成了“先探索，再综合，再给建议”。这听起来像文字游戏，实际用起来差很多。你问普通模式“React 和 Vue 哪个更适合内部后台”，它可能直接给一张优缺点表。你切到 /research，它更像是在说：别急着站队，我先把背景、约束、方案差异和可能踩坑的地方理一遍。
这正是它值得单独写一篇的原因。
/research 到底是什么
可以把 /research 理解成 GitHub Copilot CLI 里的一个研究工作流入口。它不是让模型立刻给你一个像样答案，而是鼓励它先做这些事：
- 拆解问题，识别你真正想知道的东西
- 主动查找补充信息，而不是只吃你当前 prompt
- 对多个来源或多个候选方案做归纳
- 在结论之外，把依据和边界一起写出来
也就是说，它更适合那种问题还没完全收敛的场景。
比如下面这两类任务，气质完全不同：
“帮我写一个 Bash 脚本，批量重命名图片”这是执行题，直接写就行。
“帮我研究一下 monorepo 下前端包管理策略，比较 pnpm workspace、Turborepo 和 Nx，给出适合 20 人团队的建议”这就是典型 research 题。它不只是产出代码或命令，更重要的是把问题空间摸清楚。
它和普通问答模式差在哪
普通问答模式擅长的是快答。你知道自己要什么，只需要一个实现、一段代码、一个解释，直接问最快。
/research 擅长的是慢一点，但更像真的调研。它会更自然地去做这些动作：
- 主动补充背景
- 比较替代方案
- 暴露不确定性
- 给出“在什么前提下适合/不适合”
如果把两者类比成人：
- 普通模式像一个反应很快的同事，你问什么他立刻答
/research更像那个会先打开十几个标签页，再回来跟你说“别急，我觉得你真正该看的是这三件事”的同事
AI 时代很多工具都在拼“秒回”。但对于技术判断，秒回往往不是最值钱的部分。真正值钱的是：有没有帮你把模糊问题收敛成可决策的问题。 /research 的意义就在这儿。
哪些场景最适合用 /research
1. 技术选型
这是 /research 最像样的舞台。
比如你在考虑：
- 新项目该不该上 Bun
- 向量数据库该选 pgvector、Qdrant 还是 Weaviate
- 团队该继续用 REST，还是把一部分读接口改成 GraphQL
- Copilot、Claude Code、Codex 这些工具在你团队里怎么分工
这类问题的共同点是：没有标准答案，只有上下文相关的更优解。你需要的不是一段定义，而是一份把约束条件摊开的比较。
这时 /research 很合适，因为它会把“优点”之外那些更关键的东西带出来，比如学习成本、迁移成本、团队习惯、生态成熟度、长期维护压力。
2. 摸陌生仓库或陌生框架
你接手一个没见过的 repo，或者第一次碰 Astro、LangGraph、Supabase、Temporal 这类东西时，最怕的不是不会写，而是不知道先看哪儿。
/research 适合这种“先建立地图”的阶段。你可以让它做这些事：
/research 这个仓库的核心模块有哪些？配置入口在哪里？构建、部署和本地开发流程分别是什么？有哪些我应该先理解的关键文件？或者：
/research Temporal API 解决了 JavaScript Date 的哪些历史问题？如果我要在现有 Node 项目里逐步引入，最先该替换哪些用法？这类任务的重点不是立刻改代码，而是减少你第一次进入陌生系统时的迷路成本。
3. 方案对比和迁移前评估
很多工程决策不是“做不做”，而是“现在值不值得做”。
比如：
- 要不要把旧脚本迁到 GitHub Actions
- 要不要从 npm 切到 pnpm
- 要不要给现有项目接入 MCP
- 要不要把 PRD 工作流改成原型先行
如果你直接问 AI “该不该迁移”，它很容易一本正经地支持迁移，因为新东西总显得更先进。/research 更适合拿来压住这种“新技术自动加分”的冲动，让它把迁移收益、风险、兼容性和回滚成本说清楚。
4. 写调研稿、内部分享、决策备忘录
/research 还有一个很实用的用途：给你打研究底稿。
你不一定要把它的输出原样拿去发，但它很适合做这些前置工作：
- 收集论点
- 梳理背景
- 列出比较维度
- 找到还缺的证据
- 整理一版决策 memo 的骨架
这在 AI 时代是一个被低估的用法。模型最容易帮到人的，不一定是替你写最终版本，而是把“空白页的恐惧”打碎。对于需要做判断的人来说，这一步很值钱。
哪些场景不该用 /research
1. 你只是想快点写出来
比如：
- 写一个 SQL 查询
- 修一个 ESLint 报错
- 生成一个 shell 脚本
- 给函数补测试
这时候开 /research 往往是在给自己加戏。问题已经很清楚了，直接让 Copilot 干活更快。
2. 你已经知道答案，只缺执行
如果你已经决定“就用 pnpm”“就把这个接口改成 cursor pagination”“就上 Astro”，那就别再让 /research 帮你重新发散一轮。它会增加上下文、补充分支、扩展问题空间，而这恰好不是你现在需要的。
3. 你把它当成“自动尽调”
这是最危险的一种误用。
/research 可以帮你更系统地探索，但它不等于替你完成最终判断。尤其是涉及这些内容时：
- 价格和计费策略
- 安全承诺
- 法务合规
- 版本兼容矩阵
- 生产事故风险
这些地方，AI 可以帮你做第一轮整理，但最后还是得回到官方文档、真实环境和团队经验上做确认。
/research适合帮你缩小问题空间，不适合替你签字画押。
几个特别实用的提示词写法
如果你想让 /research 真干活，prompt 最好别只写一个名词。把任务边界交代清楚，它会聪明很多。
场景一：技术选型
/research 比较 GitHub Copilot CLI、Claude Code 和 Codex 在日常开发中的适用场景。
重点看：代码修改能力、终端工作流、上下文控制、适合个人还是团队、容易踩的坑。
最后给出适合 3 人小团队的建议。场景二：评估是否迁移
/research 我们现在在 npm workspace 上维护一个中型 monorepo，CI 时间偏长。
帮我研究切到 pnpm workspace 的收益、风险、迁移步骤和回滚点。
默认前提：Node 20、GitHub Actions、团队 12 人。场景三：摸清陌生项目
/research 帮我快速理解这个仓库。
请说明：入口文件、模块划分、本地运行方式、测试方式、部署方式，以及我第一次改需求前必须知道的 5 件事。场景四：为文章或分享做材料
/research 我要写一篇介绍 GitHub Copilot CLI /research 功能的文章。
请整理这个功能解决的核心问题、适用场景、不适用场景、与普通问答模式的差异，以及 5 个贴近日常开发的示例。你会发现，好的 /research prompt 通常都包含四个东西：
- 研究对象
- 评估维度
- 使用前提
- 输出形式
这和普通 prompt engineering 很像，但又更强调“决策上下文”。AI 改变的是信息收集速度，没有改变“问题定义质量决定输出质量”这条老规律。
/research 在团队里最适合扮演什么角色
我会把它定义成一个研究型副驾，不是拍板的人。
它特别适合放在这些环节前面：
- 选型会议前，先出一版材料
- 开始重构前，先摸清现状
- 接手新仓库前，先建立地图
- 写内部分享前，先拉起框架
- 做技术债治理前，先把替代方案列全
这类工作以前通常很碎：开一堆标签页、翻文档、读 issue、抄对比、写纪要。/research 的价值，不是 magically 让这些劳动消失，而是让它更集中、更连续、更不容易漏掉关键分支。
从这个角度看，它代表的不是“AI 更会聊天了”，而是CLI 工具正在从命令执行器，变成问题探索器。这才是更值得注意的变化。
用它时最该保留的人类判断
最后得泼一点冷水。/research 再好用，也别把它想成“外包大脑”。
真正该由人守住的部分，至少有这三块：
- 问题是不是问对了：如果问题定义就歪了，研究越深入，跑偏越远
- 证据够不够硬：AI 可能会整理得很像样，但引用层级和权威性仍然需要你审
- 结论适不适合你团队：再漂亮的方案，只要和现有组织、预算、能力结构不匹配，就只是漂亮
AI 已经很擅长帮我们扩张“搜索和整理”的手，但真正稀缺的仍然是判断。/research 最好的使用方式，不是替你做决定，而是让你在做决定前少走一点弯路。
如果普通 Copilot 模式像是在回答问题，/research 更像是在陪你把问题问明白。这两者的差别，不花哨，但很要命。
参考
- GitHub Copilot CLI for Beginners — GitHub
- GitHub Copilot in the CLI — GitHub