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

超全实测!llama.cpp性能基准库:从参数调优到多场景测试全攻略

超全实测!llama.cpp性能基准库:从参数调优到多场景测试全攻略 【免费下载链接】llama.cppPort of Facebook's LLaMA model in C/C++ 项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp 你是否还在为本地部署大语言模型(LLM)时的性能瓶颈发愁?同样的硬件配置,为何有人能跑100 tokens/秒,而你却卡在20 tokens/秒?本文将带你深度掌握llama.cpp官方性能测试工具——llama-bench,通过标准化测试流程和参数调优技巧,让你的模型性能提升300%! 读完本文你将获得: * 3分钟上手的性能测试命令模板 * 4组关键参数(线程数/GPU层/批处理大小)调优指南 * 5种输出格式(CSV/JSON/

语音识别本地化:探索OpenAI Whisper的离线部署与创新应用

语音识别本地化:探索OpenAI Whisper的离线部署与创新应用 【免费下载链接】whisper-base.en 项目地址: https://ai.gitcode.com/hf_mirrors/openai/whisper-base.en 在数据隐私日益受到重视的今天,如何在不依赖云端服务的情况下实现高效语音转文字?OpenAI Whisper作为一款开源语音识别模型,正以其98%以上的识别准确率和完全本地化的处理能力,重新定义个人与企业的音频处理方式。本文将带你深入探索Whisper的技术原理、部署流程及创新应用场景,让你在隐私安全与识别效率之间找到完美平衡。 探索本地化语音识别的技术价值 你可能会好奇,为什么越来越多的开发者选择本地部署语音识别系统?与传统云端方案相比,Whisper带来了三重核心优势:首先是数据主权的完全掌控——所有音频处理均在本地设备完成,避免敏感信息上传云端的隐私风险;其次是99种语言的全面支持,从日常对话到专业术语都能精准识别;最后是离线环境下的稳定运行,即使在网络不稳定的场景中也能保持高效工作。 📌 技术突破点:Whisper采用基于Tr

FPGA板上基于Simulink与ModelSim联合仿真验证的Buck闭环设计及调试

FPGA板上基于Simulink与ModelSim联合仿真验证的Buck闭环设计及调试

simulink与modelsim联合仿真buck闭环设计 主电路用simulink搭建,控制电路完全有verilog语言实现(包括DPWM,PI补偿器) 适用于验证基于fpga的电力电子变换器控制,由于控制回路完全由verilog语言编写,因此仿真验证通过,可直接下载进fpga板子,极大缩短了开发数字电源的研发周期。 buck变换器指标如下: (*额定输入电压*) Vin->20, (*最大输入电压*) Vin_max->25, (*最小输入电压*) Vin_min->15, (*输出电压*)Vo>10, (*开关频率*)fs->50*10^3, (*输出功率*)Po->100, (*最小占空比*)Dmin->0.1, (*额定占空比*)D ->0.5,

彻底解决 Codex / Copilot 修改中文乱码【含自动化解决方案】

彻底解决 Codex / Copilot 修改中文乱码【含自动化解决方案】

引言 在使用 GitHub Copilot 或 OpenAI Codex 自动重构代码时,你是否遇到过这样的尴尬:AI 生成的代码逻辑完美,但原本注释里的中文却变成了 我爱中文 这样的乱码?有时候这种字符甚至会污染正确的代码,带来巨大的稳定性隐患。 一、 问题核心:被忽视的“终端中转” 乱码的根源不在于 AI 的大脑,也不在于编辑器的显示,而在于执行链路的编码不一致。 Copilot/Codex 在执行某些修改任务(如:重构整个文件或批量替换)时,往往会通过终端调用系统指令。由于 Windows 终端(PowerShell/CMD)默认使用 GBK 编码,它在处理 AI 传来的 UTF-8 字节时会发生“误读”,导致写入文件的内容从源头上就损坏了。