【VSCODE 插件 调试】 Visual Studio Code + Continue + Ollama实现本地版 Cursor / Copilot

【VSCODE 插件 调试】 Visual Studio Code + Continue + Ollama实现本地版 Cursor / Copilot

Visual Studio Code + Continue

  • 组合Visual Studio Code + Continue + Ollama 基本就是 本地版 Cursor / Copilot。,可以做到:
    • AI 自动写代码
    • 自动改代码
    • 解释代码
    • 自动生成文件
    • agent 自动执行命令

安装 Ollama

在这里插入图片描述
1. 安装 Ollama # macOS: brew install ollama # Linux: curl -fsSL https://ollama.com/install.sh | sh # windows: irm https://ollama.com/install.ps1 | iex 或者直接去官网下载安装 https://ollama.com/download/windows # 2. 拉取模型 ollama pull llama3.3 ollama pull qwen2.5:32b # 3. 启动 Ollama 服务 ollama serve # windows方法 ollama run llama2 ollama run gemma:2b 
  • 在 Ollama 里安装可用的模型,Ollama 官方提供多个参数规模:
模型大小下载体积
0.5B超轻量~398MB
1.5B轻量~1GB
3B中等~2GB
7B推荐~4.7GB
14B~9GB
32B最强~20GB
C:\Users\audit>ollama run qwen2.5-coder:3b pulling manifest pulling 4a188102020e: 100% ▕██████████████████████████████████████████████████████████▏ 1.9 GB pulling 66b9ea09bd5b: 100% ▕██████████████████████████████████████████████████████████▏ 68 B pulling 1e65450c3067: 100% ▕██████████████████████████████████████████████████████████▏ 1.6 KB pulling 45fc3ea7579a: 100% ▕██████████████████████████████████████████████████████████▏ 7.4 KB pulling bb967eff3bda: 100% ▕██████████████████████████████████████████████████████████▏ 487 B verifying sha256 digest writing manifest success >>> 介绍一下 我是一个大型语言模型,由阿里云开发和提供。我的名字是Qwen。我是阿里云自主研发的超大规模语言模型,基于大规模预训练数据 和先进的算法,能够理解和生成自然语言文本。我可以回答问题、创作文章、撰写代码、提供编程帮助等。我的目标是提供高效、准 确和流畅的语言交流服务。 >>> Send a message (/? for help) 

安装Continue

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


在这里插入图片描述
  • 开启索引:
在这里插入图片描述
  • 创建文件:
在这里插入图片描述


在这里插入图片描述

其他操作

还可安装运行在命令行的版本:

在这里插入图片描述
>npm i -g @continuedev/cli && cn "Explore this repo and provide a concise summary of it's contents" changed 93 packages in 30s 12 packages are looking for funding run `npm fund` for details How do you want to get started? 1. ⏩ Log in with Continue 2. 🔑 Enter your Anthropic API key Enter choice (1): 
在这里插入图片描述

简单方式CalliopeAI

  • 发现一个更简单的应用,直接安装即可,可以少去上边的配置:
在这里插入图片描述


在这里插入图片描述


在这里插入图片描述

不知道是否我的配置原因,这个并不好用:

在这里插入图片描述

试用CODEX

在这里插入图片描述


在这里插入图片描述
  • 登录之后可修改C:\Users***.codex\config.toml:
model = "gpt-5.3-codex" model_reasoning_effort = "medium" [windows] sandbox = "elevated" 
  • https://docs.onlinetool.cc/codex/docs/config.html
model = "qwen2.5:3b" model_provider = "ollama" model_reasoning_effort = "medium" [windows] sandbox = "elevated" [model_providers.ollama] name = "Ollama" base_url = "http://localhost:11434" 
在这里插入图片描述

CODEX也有命令行版本

>ollama launch codex --model qwen3 #https://ollama.com/library/qwen3 pulling manifest pulling a3de86cd1c13: 100% ▕██████████████████████████████████████████████████████████▏ 5.2 GB pulling ae370d884f10: 100% ▕██████████████████████████████████████████████████████████▏ 1.7 KB pulling d18a5cc71b84: 100% ▕██████████████████████████████████████████████████████████▏ 11 KB pulling cff3f395ef37: 100% ▕██████████████████████████████████████████████████████████▏ 120 B pulling 05a61d37b084: 100% ▕██████████████████████████████████████████████████████████▏ 487 B verifying sha256 digest writing manifest success Launching Codex with qwen3... Error: codex is not installed, install with: npm install -g @openai/codex > 

CG

Read more

GHCTF2025-WEB题解:如何用SSTI绕过WAF黑名单(附实战payload)

从GHCTF2025实战出发:深度拆解SSTI黑名单绕过策略与高阶Payload构造 最近在GHCTF2025的WEB赛道上,一道看似简单的文件上传题目,却让不少选手陷入了“知道有洞,但payload总被拦截”的困境。这道题表面上是文件上传,实际上却是一场针对SSTI(服务器端模板注入)绕过能力的深度考验。我在实际测试中发现,很多选手能够快速识别出SSTI漏洞的存在,但在面对严格的黑名单过滤时,却往往束手无策,反复尝试的payload都被WAF无情拦截。 这种情况在真实的渗透测试和CTF比赛中并不少见。WAF(Web应用防火墙)的过滤规则越来越智能,传统的{ {7*7}}测试虽然能确认漏洞,但真正要执行命令、读取文件时,那些包含os、flag、__builtins__等关键词的payload几乎都会被第一时间拦截。这道题的精妙之处在于,它模拟了一个相对真实的防御环境——不仅过滤常见敏感词,还对下划线这种在Python反射中至关重要的字符进行了拦截。 本文将从实战角度出发,不局限于GHCTF2025这一道题目,而是系统性地探讨SSTI黑名单绕过的核心思路、技术原理和进阶技巧。我会结

前端通用 Token 全流程操作指南(常见常用版)

前端通用 Token 全流程操作指南(常见常用版) 本文梳理 所有前端框架通用 的 Token 操作逻辑,剥离具体项目/技术栈细节,聚焦「获取→存储→使用→过期→清除」的核心生命周期,每个步骤均标注「通用场景+通用方案+注意事项」,适合所有前端开发场景,可直接作为开发速查表。 前置说明:Token 的核心定位 Token 是后端签发的临时访问凭证,核心作用是: 1. 证明“当前用户是谁”(身份认证); 2. 证明“当前用户有权限访问”(权限校验)。 一、第一步:登录成功获取 Token 通用场景 用户通过账号密码/验证码/第三方登录等方式,向后端发起登录请求,后端验证通过后,在响应体中返回 Token。

前端图片加载失败、 img 出现裂图的原因全解析

在前端开发过程中,我们几乎都遇到过这种情况: 页面中某张图片加载不出来,显示成一个小小的“裂图”图标。 这看似简单的问题,实际上可能由多种原因造成,尤其是在 HTTPS 环境下,混合内容机制(Mixed Content) 是最常见、也最容易被误解的根源之一。 本文将带你系统梳理裂图的各种原因、排查思路,并重点讲清楚混合内容的原理与浏览器行为。 一、什么是“裂图”? “裂图”(broken image)是指浏览器尝试加载 <img> 标签的图片资源失败时的表现形式。 常见表现: * 图片区域显示为灰底、叉号、占位符; * 控制台出现 Failed to load resource 或 Mixed Content 警告; * Network 面板中图片请求状态码为 404 / 403 / blocked。 二、常见的裂图原因汇总

WebRTC / HLS / HTTP-FLV 的本质区别与选型指南

WebRTC / HLS / HTTP-FLV 的本质区别与选型指南

在做系统级直播(而不是自己本地播放)时,很多人都会遇到一个经典问题: WebRTC、HLS、HTTP-FLV 到底有什么区别? 项目中到底该选哪个? 传输协议不同 → 延迟不同 → 兼容性 / 稳定性 / 成本不同 在系统里选哪个,核心看两点: 你要多低的延迟?你要多强的兼容和稳定? 一、简介 * WebRTC:超低延迟(0.2 ~ 1s),适合实时监控、无人机、实时指挥 * HLS(hls.js):最稳、最通用(5 ~ 15s),适合活动直播、课程、公开大并发 * HTTP-FLV(flv.js):中低延迟(1 ~ 3s),适合想比 HLS 低延迟,但不想用 WebRTC 的场景(