Copilot Chat

Copilot Chat 真正好用的时候，不是你把它当搜索框，而是把它当“带着当前代码上下文的技术同事”。问题问得越贴近项目，它给出的回答越有用。

#Copilot Chat 适合解决什么问题

• 看不懂一段老代码，想先抓主线
• 知道要改哪里，但不想手写第一版
• 需要补测试、补注释、补错误处理
• 想先讨论方案，再决定要不要真正改代码

如果只是问通用知识，普通聊天工具也能答。Copilot Chat 的优势，是它更容易贴住你正在看的文件。

#两种入口怎么选

#侧边栏 Chat

适合长对话。比如你想先讨论一个分页方案，再追问接口结构、状态管理、测试策略，侧边栏更顺手。

#Inline Chat

适合就地修改。你已经选中一段代码，只想让它解释、重写或补测试，这种时候 Inline Chat 更省切换成本。

我的经验是：讨论问题去侧边栏，动刀改代码用 Inline。混着用最舒服。

#常见任务

• Explain：先帮你理解这段代码到底在干什么
• Fix：围绕错误信息给修复方向
• Tests：补单测、边界条件和 mock
• Refactor：拆函数、改命名、整理重复逻辑
• Docs：补注释、README 片段、接口说明

#提问别太空

很多人问 Copilot Chat 效果差，不是模型差，是问题太空。比如“帮我优化这段代码”，这种说法范围太大。

更稳的写法是：

text复制
目标：把用户列表页改成分页 + 搜索。
约束：必须沿用现有 API 与 Redux Slice，不引入新依赖。
输出：先列修改点，再给关键代码片段。

只要把 目标、约束、输出形式 说清楚，回答质量通常会明显变好。

#一个很实用的用法

我更常把它当“先出草稿，再人工收口”的工具。比如：

1. 先让它解释旧函数
2. 再让它列出可能的修改点
3. 最后只让它生成一小段确定的代码

这样比直接说“帮我把整个页面重构了”靠谱得多，也更容易审。

#常见误区

#一次把需求说得太大

Copilot Chat 会给你一个听起来很完整的答案，但里面往往夹着很多假设。任务越大，假设越多。

#不告诉它哪些东西不能动

你不说，它就会默认一切都能改。结果可能顺手把你不能动的 API、状态结构、目录规则一起改了。

#把回答当结果，不当草稿

这点最危险。Copilot Chat 给的是建议，不是提交记录。你还是得看逻辑、跑测试、过 diff。

#快捷键和命令

快捷键会因 IDE 和本地配置不同而变化，最好直接看你当前编辑器的 keybindings。命令也会随着版本调整，所以这页不把某个命令清单写死，只保留一个原则：

能选中代码时，优先基于选中内容提问；不能选中时，再去侧边栏描述上下文。

#参考资料

• GitHub Docs: https://docs.github.com/en/copilot↗
• GitHub Copilot Quickstart: https://docs.github.com/en/copilot/get-started/quickstart↗