Copilot的提问、编辑和代理模式：功能解析与适用场景

dotNET跨平台

于 2025-05-10 08:04:16 发布

阅读量73

点赞数

文章标签： copilot 代理模式

原文链接：https://mp.weixin.qq.com/s?__biz=MzAwNTMxMzg1MA==&mid=2654101518&idx=5&sn=6dd64bd5f233bd8985131207aa4c37fe&chksm=8149e9665c6ebb78f8a60ad05fd6127968eea8757732f6446821e313ec48238654d470e95d91&scene=126&sessionid=0

版权

点击“数字共生”

立即关注我们

本文使用 ClinePRO 自动翻译。

原文作者：Ashley Willis

原文链接：

https://github.blog/ai-and-ml/github-copilot/copilot-ask-edit-and-agent-modes-what-they-do-and-when-to-use-them/

本文将介绍GitHub Copilot的三种独特模式，并提供实用指南帮助开发者高效整合到工作流程中。

如果你最近在VS Code中使用Copilot Chat时没注意到底部隐藏的小下拉菜单，别担心-很多人都会忽略它，尤其是在埋头赶工时。这个不起眼的菜单正是切换提问（ask）、编辑（edit）和代理（agent）模式的关键入口，这三种模式能以截然不同的方式助力你的开发工作。

但请注意：每种模式的功能差异显著。根据你的开发者类型、对项目的熟悉程度，或是愿意让Copilot掌控多少主动权，每种模式带来的体验可能天差地别。我在构建应用、测试想法甚至尝试生疏框架时，都曾以不同方式运用这三种模式。同时，我也与其他开发者交流过他们的使用心得。以下是我的经验总结。本文并非操作手册（如需详细说明请查阅VS Code文档），而更像是一份思维指南，帮助你思考如何将这些工具融入自己的工作流程。

提问模式：快速直接验证

提问模式是最简单的模式-如果你长期使用GitHub Copilot，这可能是你唯一调用过聊天窗口的场景。

运作方式：选中代码，在Copilot Chat中输入问题，它便会生成答案。无论是解释代码功能、建议测试方法、提供实现代码片段，还是提醒特定边界情况的处理方式，它都能应对。

提问模式快速、高效，且完全专注于回答编程问题而不会改动代码。你可以直接在编辑器中提问，Copilot会结合当前编辑器环境的所有上下文给出解答。就像有个声音在耳边低语："我觉得这段代码的意思是..."

它的能力不仅限于你的代码。任何编程相关问题都可以提问-比如如何使用某个库、如何构建SQL查询，甚至针对特定数据集哪种搜索算法更高效。

需要Tailwind样式帮助？想复习JavaScript闭包概念？好奇如何在React中实现输入防抖？Copilot都能帮忙。无需项目承诺，无需架构决策，更不会修改代码。它只在你需要时提供答案，是遇到阻碍时阻力最小的求助方式。

编辑模式：保持掌控，加速前进

VS Code中的编辑模式开始展现更强大的能力。你可以选择项目中任意数量的文件，用自然语言描述修改需求，Copilot会立即生成跨文件的代码编辑建议，并以可审查的差异对比形式呈现。

当你明确目标却不想亲自逐行编写时，编辑模式堪称完美。选中代码块后输入指令（比如"添加错误处理"或"用async/await重构"），Copilot便会重写代码-但关键的是，它会先展示改动差异而非直接保存。

这正是编辑模式的可靠性所在：Copilot完成工作，但最终决定权在你手中。你不是交出控制权，而是在保持全程监督的同时加速进程。

若想进一步提升体验，可以为编辑模式添加自定义指令。这相当于提前教会Copilot你和团队的编码偏好：代码风格、详略程度、团队标准、解释语气，甚至注释的书写语言。设置这些偏好就像提前给Copilot一本手册-当你说"清理这段代码"时，它已明白"清理"对你而言的具体含义。

我常在两种场景使用编辑模式：深陷遗留系统却不想牵动其他部分时，或是需要精准完成一系列琐碎但烦人的小改进时。它不会重设计你的架构，也不会擅自重命名未指定的内容，只是专注让当前工作更快更好地完成，同时减少心智负担。

说实话，习惯之后真的回不去了。

代理模式：强大之力，待君驾驭

现在让我们聊聊代理模式。在此模式下，你只需提供高层级提示，Copilot便会自主规划步骤、选择正确文件、运行工具或终端命令，并持续迭代代码编辑直至任务完成。

这是Copilot Chat中最强大的模式-同时也是最新推出的，因此对许多人来说仍是最陌生的。代理模式能推理整个项目，执行多步操作，并在会话期间保持大量上下文记忆。无论是构建功能、修复缺陷、创建文件、清理路由逻辑，还是仅凭一条提示搭建整个应用模块，它都能胜任。

乍看之下，代理模式像是编辑模式的扩展版-某种程度上确实如此。但关键区别在于：它不仅重写你指定的代码行，还会分析关联代码，识别需要同步修改的部分，跨项目保持一致性。

另一核心差异？代理模式会自动应用编辑，而非等待显式批准（但仍会在运行高风险命令前要求审查）。其工作流更接近持续编辑的"驾驶员"模式：开发者定义目标，Copilot执行更新时无需步步请示。

对部分开发者而言，这种模式自然且高效；但对另一些人，可能会觉得让渡了过多控制权。在实际项目中，结合前文提到的自定义指令能大幅提升代理模式表现。例如我们在某个演示项目中使用的指令范例：

This is a Next.js-based travel application with TypeScript that helps users search for trips, manage bookings, view travel guides, and track points. The application uses React components, server components, and client components as part of the Next.js App Router architecture. Please follow these guidelines when contributing:## Code Standards### Required Before Each Commit- Run `npm run lint` to ensure code follows project standards- Make sure all components follow Next.js App Router patterns- Client components should be marked with 'use client' when they use browser APIs or React hooks- When adding new functionality, make sure you update the README- Make sure that the repository structure documentation is correct and accurate in the Copilot Instructions file- Ensure all tests pass by running `npm run test` in the terminal### TypeScript and React Patterns- Use TypeScript interfaces/types for all props and data structures- Follow React best practices (hooks, functional components)- Use proper state management techniques- Components should be modular and follow single-responsibility principle### Styling- You must prioritize using Tailwind CSS classes as much as possible. If needed, you may define custom Tailwind Classes / Styles. Creating custom CSS should be the last approach.## Development Flow- Install dependencies: `npm install`- Development server: `npm run dev`- Build: `npm run build`- Test: `npm run test`- Lint: `npm run lint`## Repository Structure- `app/`: Next.js App Router pages and layouts organized by route- `components/`: Reusable React components  - `components/ui/`: UI components (buttons, inputs, etc.)  - `components/__tests__/`: Component tests- `lib/`: Core logic and services  - `lib/data/`: Data models and mock data  - `lib/types/`: TypeScript type definitions- `public/`: Static assets- `tests/`: Test files and test utilities- `README.md`: Project documentation## Key Guidelines1. Make sure to evaluate the components you're creating, and whether they need 'use client'2. Images should contain meaningful alt text unless they are purely for decoration. If they are for decoration only, a null (empty) alt text should be provided (alt="") so that the images are ignored by the screen reader.3. Follow Next.js best practices for data fetching, routing, and rendering4. Use proper error handling and loading states5. Optimize components and pages for performance

如果你曾发现代理模式在构建前端时忘记后端结构，这并非错觉-尽管上下文窗口正在不断扩容，但目前仍有极限。与其在提示词中塞满提醒，不如用自定义指令预先设定规则：API调用方式、命名规范、甚至代码库的风格偏好。这为代理模式提供了更稳固的工作基础，让你在减少微观管理的同时获得更高一致性。

虽然本文不深入探讨自定义指令（VS Code文档已有优秀说明），但如果你需要跨会话工作或构建比一次性脚本更复杂的项目，它们绝对值得尝试。对我个人而言效果显著，尤其是在需要快速推进又需保持结构的副项目中。

通过这种方式使用代理模式，我已取得不少亮眼成果。有时我会在新仓库中放入README文件明确愿景，然后让Copilot完成首轮构建：组件、布局、路由甚至内容填充都能一气呵成。虽然初始成果并非完美（也不该如此），但相比从零开始已大幅缩短了可用原型的距离。初始提示越细致，代理模式表现越出色。

当然，保持参与仍很重要。偶尔代理模式可能运行意外命令，或修改你认为应保留的文件，在大型项目上也可能需要更长的推理时间。

在时间紧迫的现场演示中，这种不确定性确实会增添"刺激感"。但在日常开发尤其是实验性或启动新项目时，代理模式能自然融入我的创作流程。

与代理模式协作就像与思维超前的天才伙伴结对：若目标一致，奇迹可期；若出现偏差，只需轻推其回到正轨。关键在于良好的提示沟通、深思熟虑的初始指令，以及过程中的明确引导-这样才能让协作既高效又有趣。

资深开发者该如何看待？

这个问题在我的团队讨论中频繁出现。虽然代理模式充满未来感，但强大并不意味着它总是最佳选择。有时你需要更精准地处理代码库的某些部分-如果是调整敏感系统中的少量文件，提问或编辑模式可能更合适。

经验丰富的开发者往往最清楚哪些部分需要谨慎处理（甚至不应触碰）以避免后续问题。这不是无谓的谨慎，而是对底层复杂性的深刻理解。

值得注意的是：代理模式并非新手专属。某种程度上，当使用者能给出清晰明确的指令（并理解代码与算法结构的细微差别）时，它反而表现最佳。如果你了解系统结构、脆弱边界所在，以及何时需要审查改动而非信任流程，你就能从代理模式中获得真实价值-这正是资深开发者的领域。

当然，强烈的个人偏好也伴随而来。除非你明确指定规则，否则代理模式不会自动遵循你的惯例。这时自定义指令就派上用场了。当资深工程师将那些通常心照不宣的内容-命名模式、设计原则、需谨慎处-转化为文字并与项目一同存入版本控制时，整个团队都会获得更好体验。这不仅加速代理模式，更能提升建议质量。

很多时候编辑模式仍是更优选择。当你只需要第二双眼睛而非交出键盘时，编辑模式能让你稳步前进而不失控。这完全合理。