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 Factory成本效益分析:企业级微调投入产出比

Llama Factory成本效益分析:企业级微调投入产出比 想用大模型解决自家业务问题,但一听到“微调”两个字,很多技术负责人就头疼。自己搭环境、写代码、调参数,不仅周期长,对团队技术要求高,最后算下来,人力、算力、时间成本可能远超预期,投入产出比(ROI)成了一笔糊涂账。 有没有一种方法,能让企业像搭积木一样,低成本、高效率地定制自己的专属大模型?Llama Factory的出现,正在让这个想法变成现实。它把复杂的模型微调过程,变成了一个可视化的“工厂流水线”。今天,我们就来算一笔账:使用Llama Factory进行企业级模型微调,到底能省多少钱、提多少效?它的真实投入产出比如何? 1. 传统企业微调:一笔昂贵的“技术债” 在深入分析Llama Factory之前,我们得先看看,如果不使用它,企业通常会面临哪些成本和挑战。 1.1 显性成本:看得见的资金消耗

AI绘画R18提示词实战指南:从基础原理到安全实践

快速体验 在开始今天关于 AI绘画R18提示词实战指南:从基础原理到安全实践 的探讨之前,我想先分享一个最近让我觉得很有意思的全栈技术挑战。 我们常说 AI 是未来,但作为开发者,如何将大模型(LLM)真正落地为一个低延迟、可交互的实时系统,而不仅仅是调个 API? 这里有一个非常硬核的动手实验:基于火山引擎豆包大模型,从零搭建一个实时语音通话应用。它不是简单的问答,而是需要你亲手打通 ASR(语音识别)→ LLM(大脑思考)→ TTS(语音合成)的完整 WebSocket 链路。对于想要掌握 AI 原生应用架构的同学来说,这是个绝佳的练手项目。 从0到1构建生产级别应用,脱离Demo,点击打开 从0打造个人豆包实时通话AI动手实验 AI绘画R18提示词实战指南:从基础原理到安全实践 背景痛点分析 1. 伦理风险与合规挑战 在AI绘画领域,R18内容创作面临着多重挑战。平台审核机制日益严格,违规内容可能导致账号封禁甚至法律风险。同时,不同地区对数字内容的法律界定存在差异,开发者需要特别注意合规边界。

Python 实现 AI 图像生成:调用 Stable Diffusion API 完整教程

Python 实现 AI 图像生成:调用 Stable Diffusion API 完整教程

从零开始学习使用 Python 调用 Stable Diffusion API 生成图像,涵盖本地部署、API 调用、ControlNet、图生图等进阶技巧。 1. 技术架构 Python 客户端 Stable Diffusion API 本地部署 SD WebUI / ComfyUI 云端 API Replicate / Stability AI Stable Diffusion 模型 文生图 txt2img 图生图 img2img 局部重绘 inpainting 超分辨率 upscale 输出图像 后处理管道 存储 本地/OSS 2. 图像生成方式对比 50%25%15%10%

系统开发成本为何居高不下:低代码的工程化降本路径

在企业信息系统建设中,开发成本长期处于高位,往往并非源于单一技术选择,而是由需求不确定性、交付周期拉长、重复性开发以及后期维护复杂化等多重因素共同叠加所致。传统定制开发模式在复杂业务场景下,容易陷入人力密集、协同成本高企和工程可控性不足的问题。 低代码并非通过简化操作来“替代”工程能力,而是尝试以模型驱动、自动化生成与结构化配置为核心,重构系统开发与交付的工程路径。在这一框架下,成本的降低更多体现在重复劳动的压缩、交付链条的收敛以及系统演进过程的可控化,而非单纯的开发速度提升。 理解低代码在工程体系中的作用边界与技术前提,是判断其是否具备真实降本能力的关键。 可视化工作流 流程功能 流程功能清单 流程使用示例 系统界面 流程参数设置 流程示例 流程设计(请假申请) 流程设计(主管审批) 流程设计(完整请假流程) 可视化开发:应用构建技术分析 1.组件化设计:模块化与复用 组件化设计是可视化开发的核心基础,通过将界面元素与业务逻辑拆解为独立可组合单元,实现开发效率、可维护性和系统复用性的提升。在实际应用中,组件化不仅涉及前