QtCreator配置AI辅助编程插件github copilot保姆级教程

QtCreator配置AI辅助编程插件github copilot保姆级教程

文章目录

概要

在这里插入图片描述
Free版‌免费使用,每月限额 2000 次代码补全 + 50 次聊天交互‌集成于 VS Code,支持跨文件编辑、终端协助及自定义指令‌ ‌

Pro版‌‌个人用户‌:10 美元/月 或 100 美元/年‌ ‌特殊群体‌:学生/教师/热门开源维护者可免费使用 Pro 版‌


Business版‌19 美元/月/用户,按月计费‌面向组织或企业中的团队订阅‌ ‌

Enterprise版‌39 美元/月/用户,按月计费‌企业可按需为不同组织分配 Business 或 Enterprise 订阅‌

官方地址
GitHub Copilot主页
GitHub Copilot官方文档
环境要求
系统:Window11(我是Window11装的,其他系统不清楚)
Qt Creator:使用11+以上的版本,我使用的是Qt Creator 15.0.1
Qt和QtCreator是两个东西,Qt是库,QtCreator是编辑器,可以分开安装,我就是装的qt5.14.0配的4.11.0的Creator,然后重新单独安装了Qt Creator 15.0.1

在这里插入图片描述
资源地址
Qt Creator 15.0.1安装包
网盘地址
因为ZEEKLOG不设置积分,就得要求下载吗,更麻烦,所以设置了2积分,如果没积分,评论留言,我给单独发过去

配置流程

  • 安装Qt Creator 15.0.1
  • 下载安装node.js
  • 下载copilot.vim
  • 重启之后,打开【编辑】-【Preferences】,选择【Copilot】,在右侧勾选Enable Copilot、Auto request(勾选之后在编写代码的时候就可以自动进行提示了),然后分别配置Node.js和copilot.vim的language-server.js的路径;

打开Qt Creator,选择【帮助】【关于插件】,找见copilot,然后勾选上插件,点击确定,重启Qt Creator;

在这里插入图片描述
![(https://i-blog.ZEEKLOGimg.cn/direct/b5596e835aa146b18bbf1c309ff50581.png)

进入授权界面后点击【Authorize Github Copilot plugin】按键授权Qtcreator插件即可;

在这里插入图片描述

登录会让输入验证码,返回Qt Creator,找到下图所示的验证码输入即可;

在这里插入图片描述

配置完路径后【Sign in】就会按键就会亮起,我的已经登录完成了,登录完成就会显示登录的用户名,下边是没登录的样子,上边是完成之后的样子;

在这里插入图片描述
在这里插入图片描述

点击Free下边的Get started即可解决,此时返回qt应该就可以使用了。

在这里插入图片描述

返回qt可能会弹如下窗口,这个是需要我们去领取一下这个插件权限,跳转网页到GitHub Copilot主页
-

在这里插入图片描述

Read more

微信 H5 缓存控制:后端重定向 & 前端强制刷新

在 Web 开发中,缓存是一把双刃剑。对于静态资源,它能极大提升加载速度;但对于业务逻辑频繁变动的 H5 页面(如支付、订单页),缓存往往会导致用户看到过期的数据或界面。最近在维护一个 uni-app 项目时,遇到了一段关于 H5 缓存控制的逻辑,引发了我对于“后端重定向加时间戳”和“前端 JS 加时间戳”这两种方案的思考。虽然两者的最终目的一致,但在 Hash 模式下,它们的实现原理和效果有着本质的区别。 一、 问题背景 在应用启动的生命周期中,通常会有这样一段逻辑:当用户访问特定的关键页面(如支付、订单页)时,如果当前 URL 中缺少时间戳参数,前端会自动解析 URL,追加当前时间戳,并强制页面刷新。 这就引出了一个问题:为什么不直接在后端重定向时加时间戳?这两种方式有什么区别? 二、 核心区别:

通义千问3-14B镜像使用指南:Ollama WebUI集成实操手册

通义千问3-14B镜像使用指南:Ollama WebUI集成实操手册 1. 为什么选Qwen3-14B?单卡跑出30B级效果的务实之选 你是不是也遇到过这些情况:想用大模型做长文档分析,但Qwen2-72B显存爆了;想部署推理服务,却发现Llama3-70B连双卡都吃不消;想商用又卡在许可证上,MIT和Apache协议反复对比到头秃……别折腾了,Qwen3-14B就是为你准备的“守门员”——不是参数堆出来的纸面王者,而是真正在RTX 4090单卡上稳稳跑满、128k上下文一次加载、双模式自由切换的实干派。 它不靠MoE稀疏激活来凑参数量,148亿全激活Dense结构,意味着每层每个参数都在认真干活。FP8量化后仅14GB显存占用,A100上120 token/s,4090上也能稳住80 token/s——这不是实验室数据,是实测可复现的消费级硬件表现。更关键的是,它把“思考过程”做成可开关的选项:需要深度推理时打开Thinking模式,数学题、代码生成、逻辑链拆解直接对标QwQ-32B;日常对话、文案润色、多语种翻译就切到Non-thinking模式,延迟砍半,响应快得像本地打

前端AI工具实践

前端AI工具实践

Claude Code前端使用 步骤一:安装 Claude Code npm install -g @anthropic-ai/claude-code 运行如下命令,查看安装结果,若显示版本号则表示安装成功 claude --version 步骤二:配置Claude Code+GLM智谱大模型(免费) Coding Tool Helper 是一个编码工具助手,安装并运行它,按照界面提示操作即可自动完成工具安装,套餐配置,MCP服务器管理等。 # 进入命令行界面,执行如下运行 Coding Tool Helper npx @z_ai/coding-helper 步骤三:开始使用 Claude Code VSCODE安装Claude Code 插件 Claude Code CLI(到指定项目目录打开CLI) Claude

从零构建高可靠语音通话功能:WebRTC 实战与避坑指南

快速体验 在开始今天关于 从零构建高可靠语音通话功能:WebRTC 实战与避坑指南 的探讨之前,我想先分享一个最近让我觉得很有意思的全栈技术挑战。 我们常说 AI 是未来,但作为开发者,如何将大模型(LLM)真正落地为一个低延迟、可交互的实时系统,而不仅仅是调个 API? 这里有一个非常硬核的动手实验:基于火山引擎豆包大模型,从零搭建一个实时语音通话应用。它不是简单的问答,而是需要你亲手打通 ASR(语音识别)→ LLM(大脑思考)→ TTS(语音合成)的完整 WebSocket 链路。对于想要掌握 AI 原生应用架构的同学来说,这是个绝佳的练手项目。 从0到1构建生产级别应用,脱离Demo,点击打开 从0打造个人豆包实时通话AI动手实验 从零构建高可靠语音通话功能:WebRTC 实战与避坑指南 最近在开发一款社交APP时,团队遇到了语音通话功能的"三座大山":用户反馈通话像在太空对话(延迟超过500ms)、会议室场景回声严重、