Github Copilot Agent模式使用经验分享

Github Copilot Agent模式使用经验分享

本文总结了如何使用 GitHub Copilot Agent 模式,并分享实际操作经验。

前置设置

  1. 使用 VSCode Insider;
  2. 安装 GitHub Copilot(预览版)插件;
  3. 选择 Claude 3.7 Sonnet(预览版)模型,该模型在代码编写方面表现出色,同时其它模型在速度、多模态(如图像识别)及推理能力上具备优势;
  4. 工作模式选择 Agent。

操作步骤

  1. 打开 “Copilot Edits” 选项卡;
  2. 添加附件,如 “Codebase”、“Get Errors”、“Terminal Last Commands” 等;
  3. 添加 “Working Set” 文件,默认包含当前打开的文件,也可手动选择其他文件(如 “Open Editors”);
  4. 添加 “Instructions”,输入需要 Copilot Agent 特别注意的提示词;
  5. 点击 “Send” 按钮,开始对话,观察 Agent 的表现。

其它说明

  • VSCode 通过语言插件提供的 lint 功能可以产生 Error 或 Warning 提示,Agent 能自动根据这些提示修正代码。
  • 随着对话的深入,Agent 生成的代码修改可能会偏离预期。建议每次会话都聚焦一个明确的主题,避免对话过长;达到短期目标后结束当前会话,再启动新任务。
  • “Working Set” 下的 “Add Files” 提供 “Related Files” 选项,可推荐相关文件。
  • 注意控制单个代码文件的行数,以免 token 消耗过快。
  • 建议先生成基础代码,再编写测试用例,便于 Agent 根据测试结果调试和自我校验。
  • 为限制修改范围,可在 settings.json 中添加如下配置,只修改指定目录下的文件, 仅供参考:
"github.copilot.chat.codeGeneration.instructions":[{"text":"只需修改 ./script/ 目录下的文件,不修改其他目录下的文件."},{"text":"若目标代码文件行数超过 1000 行,建议将新增函数置于新文件中,通过引用调用;如产生的修改导致文件超长,可暂不严格遵守此规则."}],"github.copilot.chat.testGeneration.instructions":[{"text":"在现有单元测试文件中生成测试用例."},{"text":"代码修改后务必运行测试用例验证."}],

常见问题

输入需求得不到想要的业务代码

需要将大任务拆分成较小的任务, 每次会话只处理一个小任务. 这是由于大模型的上下文太多会导致注意力分散.

喂给单次对话的上下文, 需要自己揣摩, 太多和太少都会导致不理解需求.

DeepSeek 模型解决了注意力分散问题, 但需要在 cursor 中使用 Deepseek API. 不清楚其效果如何.

响应缓慢问题

需要理解 token 消耗机制, token 输入是便宜且耗时较短的, token 输出贵很多, 且明显更缓慢.

假如一个代码文件非常大, 实际需要修改的代码行只有三行, 但由于上下文多, 输出也多, 会导致 token 消耗很快, 且响应缓慢.

因此, 必须要考虑控制文件的大小, 不要写很大的文件和很大的函数. 及时拆分大文件, 大函数, 通过引用调用.

业务理解问题

理解问题或许有些依赖代码中的注释, 以及测试文件, 代码中补充足够的注释, 以及测试用例, 有助于 Copilot Agent 更好的理解业务.

Agent 自己生成的业务代码就有足够多的注释, 检视这些注释, 就可以快速判断 Agent 是否正确理解了需求.

生成大量代码需要 debug 较久

可以考虑在生成某个特性的基础代码后, 先生成测试用例, 再调整业务逻辑,这样 Agent 可以自行进行调试,自我验证.

Agent 会询问是否允许运行测试命令, 运行完成后会自行读终端输出, 以此来判断代码是否正确. 如果不正确, 会根据报错信息进行修改. 循环往复, 直到测试通过.

也就是需要自己更多理解业务, 需要手动写的时候并不太多, 如果测试用例代码和业务代码都不正确, Agent 既不能根据业务写出正确用例, 也不能根据用例写出正确业务代码, 这种情况才会出现 debug 较久的情况.

总结

理解大模型的 token 消耗机制, 输入的上下文很便宜,输出的代码较贵,文件中未修改的代码部分可能也算作输出, 证据是很多无需修改的代码也会缓慢输出.

因此应尽量控制单文件的大小, 可以在使用中感受 Agent 在处理大文件和小文件时, 响应速度上的差异, 这个差异是非常明显的.

Read more

2025终极指南:whisper.cpp跨平台语音识别部署全流程

2025终极指南:whisper.cpp跨平台语音识别部署全流程 【免费下载链接】whisper.cppOpenAI 的 Whisper 模型在 C/C++ 中的移植版本。 项目地址: https://gitcode.com/GitHub_Trending/wh/whisper.cpp 还在为语音转文字服务的网络延迟和高成本烦恼?whisper.cpp作为开源语音识别解决方案,提供了本地化部署的完美选择。本文将带你深入了解如何在不同平台上快速部署和使用这个强大的离线语音识别工具。 通过本文,你将掌握: * 多平台环境配置的一键安装方法 * 模型下载与优化的性能调优技巧 * 常见部署问题的快速解决方案 * 监控与维护的最佳实践 平台选择:找到最适合你的方案 平台类型安装难度推理速度内存占用适用场景Windows桌面⭐⭐1.2x1.1GB个人使用Linux服务器⭐⭐⭐1.5x0.9GB企业部署macOS开发⭐2.0x0.7GB移动应用Android设备⭐⭐⭐⭐0.8x0.5GB边缘计算 环境搭建:快速启动的完整步骤 基础环境准备

本地大模型:如何在内网部署 Llama/Qwen 等安全增强模型

本地大模型:如何在内网部署 Llama/Qwen 等安全增强模型 你好,我是陈涉川,欢迎你来到我的专栏。在上一篇《架构设计:安全 AI 产品的全生命周期(MLSecOps)》中,我们走出了“霍格沃茨的实验室”,直面血肉横飞的真实工程战场,拆解了从需求定义到模型退役的全生命周期(MLSecOps)七阶蓝图。我们明白了,安全 AI 的落地绝不是丢一个 Python 脚本进 Docker 那么简单,而是一场融合了算法、运维与合规的系统级工程。 既然掌握了宏观架构,本篇我们将直接拔剑出鞘,扎进生成式 AI 落地最硬核、最逼仄的深水区——物理隔离的内网环境。如何在严守数据安全与合规红线的前提下,在算力捉襟见肘的企业内网中,将百亿参数的 Llama 或 Qwen 部署上线,并将其微调成一个拥有坚定防守立场、断网也能满血运行的“企业专属安全大脑”! 引言:跨越红线,

最完整WhisperLiveKit指南:从安装到生产部署的AI语音识别全流程

最完整WhisperLiveKit指南:从安装到生产部署的AI语音识别全流程 【免费下载链接】WhisperLiveKitReal-time, Fully Local Speech-to-Text and Speaker Diarization. FastAPI Server & Web Interface 项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit 你是否还在为实时语音转文字的延迟问题困扰?是否需要一个完全本地化部署的解决方案来保护数据隐私?WhisperLiveKit作为GitHub热门的开源项目,将彻底改变你处理实时语音识别的方式。本文将带你从安装到生产部署,掌握这一强大工具的全流程应用。 读完本文,你将能够: * 快速搭建本地语音识别服务 * 根据硬件条件选择最优模型配置 * 实现多语言实时转录与说话人分离 * 部署生产级别的Web应用与Chrome扩展 * 通过Docker容器化实现跨平台部署 为什么选择WhisperLiveKit? 传统的Whisper模型设计用于处理完整语

Windows环境本地大模型工具链安装教程:Ollama + llama.cpp + LLaMA Factory

Windows 11 本地大模型工具链终极教程:Ollama + llama.cpp + LLaMA Factory 本教程将指导你在 Windows 11 系统上,将 Ollama、llama.cpp 和 LLaMA Factory 三个工具统一安装到 E 盘,并实现 GPU 加速、数据集配置和一键启动。所有步骤均已实际验证,适用于 RTX 5080 等现代显卡。 📁 1. 统一文件夹结构(推荐) 在 E 盘 创建父文件夹 LLM,用于集中管理所有相关文件。子文件夹规划如下: text E:\LLM\ ├── Ollama\ # Ollama 程序安装目录 ├── OllamaModels\ # Ollama 下载的模型存放目录