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

【每天一个知识点】Midjourney

【每天一个知识点】Midjourney

🧠 一、Midjourney 的工作方式(原理机制) Midjourney 是基于 扩散模型(Diffusion Model) 与 大规模视觉语言模型(CLIP) 的 AI 图像生成系统。 它的核心原理可以概括为三个阶段: 1️⃣ 文本理解阶段(Prompt Encoding) * 用户输入提示词(Prompt),例如: “A futuristic cityscape at sunset, ultra realistic, cinematic lighting, 8K” * Midjourney 使用一个经过大规模训练的 文本–图像对齐模型(类似 OpenAI 的 CLIP) 来理解提示词的语义。 * 模型将文字转化为一组高维语义向量(text embedding)。 2️⃣ 扩散生成阶段(Diffusion Process) * 系统从一张“

AIGC产品经理面试题汇总|从 0 到 1 做 AIGC 产品,核心能力与面试考点全拆解

2026年,生成式AI已经彻底走完了从技术爆发到产业落地的关键周期。当通用大模型的格局逐步固化,垂直行业的AIGC应用遍地开花,AI产品经理早已从互联网行业的“加分岗”,变成了科技企业、传统产业数字化转型的核心刚需岗。 但市场始终存在严重的人才供需错配:传统产品经理懂用户、懂流程,却摸不透AIGC的技术边界与产品逻辑;技术背景的从业者懂模型、懂算法,却无法把技术能力转化为可落地的用户价值与商业闭环。这也导致了AIGC产品岗的面试呈现出极强的两极分化——背概念的候选人一抓一大把,能真正讲清“从0到1做一款AIGC产品”的人寥寥无几。 这篇文章,我们不止于罗列面试题,更要拆解AIGC产品经理的核心能力模型,还原从0到1操盘AIGC产品的全链路流程,深挖大厂高频面试题背后的考察逻辑,同时结合产业趋势给出前瞻性判断。无论是想入行AIGC领域的产品新人,还是想突破职业瓶颈的资深产品人,都能从中找到可复用的方法论与可落地的行动指南。 第一章 认知破界:AIGC产品经理的核心定位与底层认知 这是所有面试的开篇考点,也是做AIGC产品的底层逻辑。面试官问基础认知题,从来不是想听你背大模型的定

llama.cpp加载多模态gguf模型

llama.cpp预编译包还不支持cuda12.6 llama.cpp的编译,也有各种坑 llama.cpp.python的也需要编译 llama.cpp命令行加载多模态模型 llama-mtmd-cli -m Qwen2.5-VL-3B-Instruct-q8_0.gguf --mmproj Qwen2.5-VL-3B-Instruct-mmproj-f16.gguf -p "Describe this image." --image ./car-1.jpg **模型主gguf文件要和mmporj文件从一个库里下载,否则会有兼容问题,建议从ggml的官方库里下载 Multimodal GGUFs官方库 llama.cpp.python加载多模态模型 看官方文档 要使用LlamaChatHandler类,官方已经写好了不少多模态模型的加载类,比如qwen2.5vl的写法: from llama_cpp import Llama

开源ASR新选择:Fun-ASR与Whisper对比评测

开源ASR新选择:Fun-ASR与Whisper对比评测 在语音技术日益渗透日常生活的今天,自动语音识别(ASR)早已不再是实验室里的高冷概念。从会议纪要自动生成到客服录音智能质检,再到教育领域的课堂内容归档,语音转文字能力正成为众多产品的“标配”。然而,当开发者真正着手落地时,往往面临一个现实困境:用闭源服务担心数据外泄,自己训练模型又成本高昂、门槛不低。 OpenAI的Whisper无疑是当前最知名的通用语音识别方案之一。它开源了模型权重,支持多语言识别,在英文场景下表现优异,也因此被广泛集成进各类工具链中。但当我们把视角拉回中文环境——尤其是面对带口音的普通话、行业术语密集或需要私有化部署的业务场景时,Whisper的表现就开始显得有些“水土不服”。 正是在这种背景下,由钉钉联合通义实验室推出的 Fun-ASR 显得尤为亮眼。它不仅完全开源、可本地部署,还在中文识别精度和系统实用性上做了大量针对性优化。更关键的是,它配套提供了一个开箱即用的WebUI界面,让非专业用户也能轻松完成批量转写任务。 这不仅仅是一次简单的“国产替代”,而是一种面向实际应用需求重构ASR使用体验的