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

鸿蒙金融理财全栈项目——生态合作与用户运营优化

鸿蒙金融理财全栈项目——生态合作与用户运营优化

《鸿蒙APP开发从入门到精通》第27篇:鸿蒙金融理财全栈项目——生态合作与用户运营优化 🚀🤝📊 内容承接与核心价值 这是《鸿蒙APP开发从入门到精通》的第27篇——生态合作与用户运营优化篇,100%承接第26篇的安全合规与用户体验优化架构,并基于金融场景的生态合作与用户运营优化要求,设计并实现鸿蒙金融理财全栈项目的生态合作与用户运营优化功能。 学习目标: * 掌握鸿蒙金融理财项目的生态合作优化设计与实现; * 实现生态合作数据接入、生态合作接口对接、生态合作数据共享; * 理解用户运营优化在金融场景的核心设计与实现; * 实现用户分群优化、用户画像优化、用户留存优化; * 掌握生态合作与用户运营的协同优化策略; * 优化金融理财项目的用户体验与生态合作效果。 学习重点: * 鸿蒙金融理财项目的生态合作优化设计原则; * 用户运营优化在金融场景的应用; * 生态合作与用户运营的协同优化策略。 一、 生态合作优化基础 🎯 1.1 生态合作优化定义 生态合作优化是指对金融理财项目的生态合作进行优化,提升应用的生态合作效果,主要包括以下方面:

By Ne0inhk
Flutter 组件 okay 的适配 鸿蒙Harmony 深度进阶 - 驾驭异步结果链式融合、实现鸿蒙端分布式业务逻辑解耦与精密审计方案

Flutter 组件 okay 的适配 鸿蒙Harmony 深度进阶 - 驾驭异步结果链式融合、实现鸿蒙端分布式业务逻辑解耦与精密审计方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 okay 的适配 鸿蒙Harmony 深度进阶 - 驾驭异步结果链式融合、实现鸿蒙端分布式业务逻辑解耦与精密审计方案 前言 在前文中,我们探讨了 okay 在鸿蒙(OpenHarmony)端实现基础 Result 模式包装的实战。但在真正的“分布式微服务聚合”、“高并发资产对账”以及“具备自愈能力的 IoT 指令链”场景中。简单的 ok() 与 err() 判定往往不足以支撑起复杂的业务全景。面对需要同时并行发起 3 个 API 请求,并要求在“所有请求均成功时执行合并、任一请求失败时执行局部逻辑路由”的高阶需求。如果缺乏一套完善的异步结果映射与多级逻辑聚合机制。不仅会导致异步回调地狱(Callback Hell)在

By Ne0inhk
Windows 下启用 WSL(Linux之Ubuntu)

Windows 下启用 WSL(Linux之Ubuntu)

Windows 下启用 WSL(Linux之Ubuntu) * 启用虚拟环境 * WSL 环境准备 * 安装 Ubuntu * 重启 * 删除 * 迁移 启用虚拟环境 在 Windows 功能弹框中,打开以下 3 个功能: a. Hyper-V b. 适用于 Linux 的 Windows 子系统 c. 虚拟机平台 确定之后等待完成,之后等待电脑配置完成,最后重启电脑。 在“程序”弹框中:点击“启用或关闭 Windows 功能”,进一步打开 Windows 功能弹框。 Window+R:输入 control 在这里插入图片描述 `,调出控制中心,如下: 点击“

By Ne0inhk
【Linux/C++多线程篇(二) 】给线程装上“红绿灯”:通俗易懂的同步互斥机制讲解 & C++ 11下的多线程

【Linux/C++多线程篇(二) 】给线程装上“红绿灯”:通俗易懂的同步互斥机制讲解 & C++ 11下的多线程

⭐️在这个怀疑的年代,我们依然需要信仰。 个人主页:YYYing. ⭐️Linux/C++进阶系列专栏:【从零开始的linux/c++进阶编程】 系列上期内容:【Linux/C++多线程篇(一) 】多线程编程入门 系列下期内容:【Linux/C++网络篇(一) 】网络编程入门 目录 前言:当多线程遇上“交通混乱” 线程的同步互斥机制 一、为什么需要同步互斥? 二、线程互斥之互斥锁 2.1、互斥锁的相关API函数接口  📖 创建一个互斥锁  📖 初始化互斥锁 📖 获取锁资源 📖 释放锁资源 📖 销毁互斥锁 2.2、互斥锁的小练习 三、线程同步之无名信号量 3.1、无名信号量的相关API函数接口  📖 创建无名信号量  📖 初始化无名信号量  📖 申请无名信号量的资源(

By Ne0inhk