本文已自动翻译。查看原文，请点击这里。
我认为，Copilot adoption 中最有用的变化之一，就是摆脱对功能的执着。
这正是这份新的 面向 .NET 开发者的 GitHub Copilot 指南 表现得这么好的原因。
核心想法很简单：不要再问哪个 Copilot mode 最酷，而要开始问 哪个 surface 最适合当前任务。
这才是正确的 mental model
对于大多数真实的 .NET 工作，问题不是：
- chat 还是 agent？
- Visual Studio 还是 CLI？
- inline 还是 cloud？
更好的问题是：
- 我是在理解代码吗？
- 我是在计划 refactor 吗？
- 我是在更新 tests 吗？
- 我是在修复损坏的 build 吗？
- 我是在协调一个涉及多个文件的变更吗？
这是一种与 Copilot 协作更高效的方式。
原文中最有用的一句话
我会从原文里挑出的那句话是：
“问题不是谁最 advanced。更好的问题是：谁适合我现在正在做的工作？”
这也正是我会给出的建议。
因为很多 AI tooling 的混乱，来自把 surface 当成身份，而不是工具。
Visual Studio、VS Code、CLI 和 background agents 各自适合不同的时刻。
一旦你接受这一点，整个体验就会变得更加实用。
为什么这对 .NET 团队尤其重要
.NET 工作往往会在一天内涵盖多种任务：
- 理解 legacy service
- 规划 refactor
- 生成 tests
- 修复损坏的 build
- 同时处理 code、config、docs 和 infrastructure
这意味着没有任何单一 Copilot surface 会对所有事情都最好。
所以这份指南的建议是好的，因为它反映了工作真实发生的方式。
我的看法
这份指南很有用，因为它把 Copilot 看作真实 .NET development loop 的一部分，而不是叠加在上面的新鲜层。
这让它变得 relevant。
坦率地说，更多 AI 指南如果也能朝这种 task-first 思维转变，都会变得更好。
