标签 VSCode 下的文章

想一边上班赚钱,一边炒股散财,就是有时候工作多了,就没时间手机看盘了,今天又错过了抄底的好时机
各位有没有什么盯盘的摸鱼软件推荐

已有 vscode 安装了韭菜盒子,不过不写代码的时候,开着 vscode,只是为了看盘,还是有点吃资源

Vibe Coding 的进化速度,可能还是超乎了我们的想象。

今天,我们在测试 Kimi K2.5 的网页生成功能时,旁边的前端开发同事还以为是真实的网页场景,低声问我:“你这是在写代码吗,还是在摸鱼打游戏?”

直到我说出这是 AI 生成的,而且是只用了几句话就做出来的效果,这让她大为惊讶。

该网页长这样,现在如果不明说的话,确实已经难辨“真假”。

Kimi K2.5 在今天刚刚上新,它没有把重点放在“单项能力突破”上,而是试图把视觉理解、代码生成、交互设计,以及多 Agent 协作,都压进了同一个模型里,一口气提供了四种使用模式。

在笔者看来,其中最有意思的,当属 Agent 集群模式——这也是在国内 AI 上第一次出现的功能,它可以让原本耗时数天的工作,现在仅需十几分钟就能做完,简直是指数级的提效。

比如,要做 100 家公司的市场调研,它能指挥一群不同行业背景的“分析师”分头行动,十几分钟出结果,而不是几个星期;面对 300 页的复杂翻译项目,它能动员一个“语言学专家”团队,快速、准确地完成交付。

四种模式具体如下。不同需求的用户,从随手一问,到需要并行推进的复杂任务,都能找到明确的入口:

  • 快速模式,提供最快的响应体验。

  • 思考模式,可以用来解答复杂问题。

  • Agent 模式,擅长深度研究、PPT、Excel、Word、PDF 和网页生成等任务——目前 K2.5 已经开始掌握 Office 套件的核心技能,其协助办公的能力不容小觑。

  • 重磅全新模式:Agent 集群模式,适合需要并行处理的复杂任务

另外,新编程产品 Kimi Code不仅能直接在终端里运行,还能无缝集成到 VSCode、Cursor、Zed 这些 IDE 里,支持直接输入图片和视频。

月之暗面 CEO 杨植麟,这次亲自为新模型发布录制了视频。

Kimi K2.5 实测

看起来很强是一回事,那用起来是不是另一回事?以下是各种实操案例,InfoQ 也上手测了几组。

几分钟搓出前端网页,能修改细节、还能有声音

为了测试 Kimi K2.5 的视觉理解能力和 Vibe Coding 水平,我们首先直接甩出一张产品页面截图,再配上几句文字描述,看看它能不能自己看懂、自己理解,顺手还能复刻出一个像模像样的产品页面。

比如让 K2.5 做个一个最近很火的心灵疗愈类项目,给的 Prompt 如下:

模仿情绪疗愈类产品,生成一个情绪记录类 APP,适合年轻人释放情绪,让人一眼觉这里允许脆弱的地方。

可以说,这个 Prompt 提示不多,要求不少,对模型视觉理解能力、逻辑思维、产品思维以及设计审美能力都是考验。

从结果看,K2.5 对“情绪”这个概念本身是有一定理解和思考的。它生成的是一个以沉浸体验为核心的情绪页面,而不是常规的情绪记录工具。

视觉上,明显没走浅色卡片流那条老路,而是用了低对比背景、连续画面和节奏型动效(类似呼吸或旋涡),交互重点放在“停留”和“进入状态”上。

在功能组织上,输入、反馈和过渡是连在一起的:用户不是“点一个按钮开始记录”,而是被自然引导进入输入状态——这种设计说明它在生成时已经考虑了状态流转,而不是只输出一个静态页面。

接下来,我们不再给任何视觉参考,只输入文字提示,让 K2.5 独立完成整个网页设计

我们给的 Prompt 很简单:

做一个类似 4399 的小游戏平台,要有完整的游戏分类频道; 但视觉审美要大厂级、高端网游风,整体要酷炫、有冲击力,并且可交互。

结果 Kimi K2.5 没让人失望。

它给出的页面并不是“看起来像网页”的静态效果,而是已经具备明确产品结构的原型。相比以往很多生成结果只停留在大色块 + 随机模块的拼接,它能正确理解“小游戏平台”这一产品类型,在首页层面同时给出清晰的分类入口、内容推荐区和主视觉焦点。

视觉风格上,它没有沿用早期生成工具常见的“低饱和扁平模板”,而是接近成熟网游官网或内容平台的布局逻辑,这一点与一些真实产品如大型游戏平台的信息层级更为接近。

更关键的是,这种效果并非通过多轮细化 Prompt 得到,而是在一次相对抽象的指令下完成,说明模型已经开始具备从“需求描述”直接映射到“产品级页面结构”的能力,而不只是做样式渲染。

类似的例子还有不少。下面这些网页,都是 K2.5 在图像生成工具的辅助下,仅凭一条 Prompt直接生成的完整原型。

除了做整个页面,我们还单独测评了一下 K2.5 对动效的理解能力。

左侧是我们输入的一段小视频,右侧是它生成的效果。结果 K2.5 几乎是完整复刻,拖动鼠标,图片会随之产生位移变化,逻辑和节奏都对得上,动效也足够丝滑。

飞书文档 - 图片

也就是说,K2.5 并不是在“画动效”,而是真的理解了交互在时间维度上的设计意图。

对开发和设计而言,这意味着动效不再从一堆参数和曲线开始,而是可以先把想法直接跑成一个可交互的原型,用几分钟看清值不值得投入工程成本。

以前要干好几天的活,十几分钟就能搞定

至于 K2.5 的 Agent 集群模式,最直观的能力就是:把时间尺度直接拉短了。过去需要“按天算”的复杂任务,现在往往 十几分钟就能跑完一整轮。

来看一个实测例子。

一次性向 Kimi 的 Agent 集群投喂了 40 篇论文,主题横跨心理学与 AI。任务是,在此基础上产出一份系统性的研究综述。

Kimi 的处理流程大致分成了三步:第一步,完整通读。主 agent 多次调用工具,按顺序把 40 篇论文逐篇过了一遍,确保所有关键信息都被纳入同一上下文,而不是零散记忆。

第二步,并行写作。在理解整体结构后,Kimi 自动派生出多个子 agent——可以理解为它的“分身”,分别负责不同章节的撰写,各自并行推进。

第三步,统一收敛。主 agent 最后回到台前,负责校对、取舍和整合,把各个子 agent 的成果汇总成一份长达几十页的专业 PDF 级综述。

整个过程里中,几乎看不到人工干预。

##当 Transformer 开始吃力,K3 可能用上原创架构 KDA

我们先后测评了一整天,总体感受很明确:

Kimi K2.5 在自己擅长的多个方向上,已经跑得相当顺了。比如网页设计生成、动效理解、多 Agent 协作等场景,完成度和稳定性都比较成熟;不过也有短板,比如在 3D 建模这类强几何约束的任务上,表现还欠佳。

当这些能力被一项项跑出来之后,更现实的问题也浮现出来:如果这些复杂推理真的要被当成日常能力反复调用,底层的计算方式还能不能长期扛得住?

月之暗面给出的一个解法,是 Kimi Linear,而 Kimi Linear 中的一个核心创新点,是一个新的实验性架构:KDA(Kimi Delta Attention),一种线性注意力模块的相关思路。

杨植麟此前在 Reddit 上的 AMA(Ask Me Anything)等公开交流中已经透露,下一代 K3 模型,可能会使用月之暗面的这个新架构 KDA。

要讲清楚 KDA 的优势,我们还得先从 Transformer 架构说起。

本质上,Transformer 的注意力机制是全连接的:每个 token 都要和上下文里的其他 token 打一次交道。结果,输入一长,计算量就按平方增长(O(N²));生成新 token 时,还要不断回查之前的 KV Cache。

当上下文一拉长,显存压力迅速飙升,尤其是在 128K 以上的场景里,几乎是“显卡先崩,钱包随后”。

——而且模型越强,这个问题就越明显。

也正因为如此,过去几年里,线性注意力一直是业内反复被拿出来讨论的一条路:把注意力计算从 O(N²) 压到 O(N),让模型跑得更快、也更省。

但现实是,早期不少线性注意力方案确实快了,却很难兼顾记忆能力:信息留不住,推理质量也跟着打折。

而 KDA 核心思想可以概括为一句话:不再每次都“全量算一遍注意力”,而是每次只计算“状态 + 增量(Delta)更新”。

这里的 Delta(增量) 是关键。它在数学上保证了稳定性,即使是在百万级 token 序列中,梯度也不会爆炸或消失。这也让 Kimi Linear 能在超长上下文中跑得稳。

在保持模型能力的同时,还可以显著降低长上下文和连续推理的计算成本——思路有点像 MoE 架构。

##One more thing

在测试 Kimi K2.5 的视觉理解能力时,我们索性出了一道“狠题”。

——甩过去一段动画,让它先吃透画风和叙事方式,再换个主题,重写一支动画脚本。说实话,这活儿对专业动画师都不轻松,我们还特意把 “Agent 集群”模式打开了。

结果最有意思的不是生成内容本身,而是页面最底下那行小字:

“这个任务 Kimi 自己就能完成,不需要 Agent 集群。部分额度已退回。”

体验传送门:https://www.kimi.com/

如题,现在美国梯子开了,vscode 以代理方式打开的,然后 claude 插件在验证后还是一直提示需要验证,请大佬指导下

VSCode 中预览 Markdown(.md) 文件的完整指南

VSCode 内置了 Markdown 预览功能,可以实时查看 Markdown 文件的渲染效果。当你编写文档、README 文件或技术笔记时,预览功能能帮你确认格式是否正确。

使用内置预览功能

VSCode 自带 Markdown 预览,无需安装额外插件。

打开预览窗口

在编辑 Markdown 文件时,按 Ctrl+Shift+V(Windows/Linux)或 Cmd+Shift+V(Mac)即可打开预览窗口。预览窗口会在新标签页中显示渲染后的内容。
alt text

并排预览

如果希望边编辑边预览,按 Ctrl+K V(Windows/Linux)或 Cmd+K V(Mac),先按 Cmd+K,松开后再按 V。这会在编辑器右侧打开预览面板,左侧编辑文件,右侧实时显示预览效果。
alt text
alt text

通过命令面板操作

Ctrl+Shift+P(Windows/Linux)或 Cmd+Shift+P(Mac)打开命令面板,输入 "Markdown",可以看到相关命令:

  • Markdown: Open Preview - 打开预览
  • Markdown: Open Preview to the Side - 并排预览
  • Markdown: Open Source - 从预览返回源文件

通过右键菜单

在 Markdown 文件的编辑器标签上右键,选择 Open PreviewOpen Preview to the Side

alt text

使用插件增强预览功能

虽然内置预览功能已经很实用,但插件可以提供更多特性和更好的体验。

安装 Markdown Preview Enhanced 插件

这是最受欢迎的 Markdown 预览插件之一。

安装方法

  1. Ctrl+Shift+X(Windows/Linux)或 Cmd+Shift+X(Mac)打开扩展面板
  2. 在搜索框中输入 "Markdown Preview Enhanced"
  3. 找到由 Yiyi Wang 开发的插件,点击 "Install"

alt text

使用插件预览

安装后,在 Markdown 文件中右键,选择 Markdown Preview Enhanced: Open Preview to the Side,或按 Ctrl+K V
alt text

插件特色功能

  • 支持数学公式(LaTeX)
  • 支持流程图和时序图(mermaid、PlantUML)
  • 支持目录生成
  • 支持导出为 PDF、HTML、PNG 等格式
  • 支持幻灯片模式
  • 更丰富的主题样式
    alt text
    alt text

其他推荐插件

Markdown All in One:

提供快捷键、自动补全、格式化等功能,包含预览功能和目录生成。

安装方法

  1. 打开扩展面板
  2. 搜索 "Markdown All in One"
  3. 安装 Yu Zhang 开发的插件
markdownlint:
  • 检查 Markdown 语法错误
  • 提供格式规范建议
  • 帮助保持文档质量

基于我的上一个帖子 ipv6+ddns+Termux+openssh+mosh—— 分享个人手机上 vibe coding 的尝试,含详细操作步骤 - 开发调优 - LINUX DO

不需要任何多余的步骤,实现了手机连接 ccb 进行多模型协作 vibe coding
在 vscode 的终端中

tmux new -s ccb
ccb up codex gemini

随后手机上打开 termux,连接到 wsl 中后执行

mosh wsl
tmux a -t ccb

即可达到图中效果

为了方便使用,tmux 配置鼠标滚轮滚动
只是屏幕比较小,如果换成平板岂不是在外随时随地当牛做马?(不是


兼容 cli 和 ide 的新玩法 [ccb] 全新大升级!!!1.18 更新 - 开发调优 - LINUX DO


📌 转载信息
原作者:
Mr_Seven
转载时间:
2026/1/19 18:33:45

有这个想法原因是在 vibe coding 时,总感觉打字没有口说的快,最近手机上豆包输入法语音输入效果不错,想着电脑上也搞个语音输入法,边上又没有麦克风,不如直接用手机输入,通过 websockt 直接传给电脑,说干就干,启动 vscode,让 codex 自己用 python 做一个,1 分钟就不到就出来了,感觉效果还行,不得不感叹,AI 真的发展太快了,程序员的也得转型了。。。

附上地址:手机语音输入同步到电脑


📌 转载信息
转载时间:
2026/1/10 19:11:59

我自己简单组了一套:
IDE:vscode
插件:roocode
大模型:Gemini/DeepSeek
MCP:Serena,以及站里大佬开发的 ace-tool(配的也是站里佬的中转 API)
系统提示词:基本都是去 gemini 网页版现写,然后加到 roocode 的模式里。

这种自组的,和 cursor、antigravity 相比,能追上 90% 的使用体验吗?
另外感谢 L 站的巨佬们,开源、免费用了很多好东西,磕头


📌 转载信息
原作者:
Grant9062
转载时间:
2026/1/10 19:11:56

基于人工智能的流行集成开发环境解决方案(如 Cursor、Windsurf、Google Antigravity 和 Trae)会推荐 OpenVSX 注册表中不存在的扩展,这使得威胁行为者能够占用其命名空间并上传恶意扩展。

这些 AI 辅助 IDE 是从 Microsoft VSCode 分支而来,但由于许可限制,无法使用官方商店中的扩展。相反,它们由 OpenVSX 提供支持,这是一个适用于 VSCode 兼容扩展的开源市场替代方案。

分支的结果是,这些 IDE 继承了官方推荐扩展列表,这些列表硬编码在配置文件中,并指向 Microsoft 的 Visual Studio Marketplace。

这些推荐以两种形式出现:一种是基于文件的,在打开如 azure-pipelines.yaml 这类文件时触发,并推荐 Azure Pipelines 扩展;另一种是基于软件的,在检测到开发者系统上安装了 PostgreSQL 时发生,并建议 PostgreSQL 扩展。

然而,并非所有推荐的扩展都存在于 OpenVSX 上,因此相应的发布者命名空间未被占用。

供应链安全公司 Koi 的研究人员表示,威胁行为者可能利用用户对应用推荐的信任,注册未被占用的命名空间来推送恶意软件。

研究人员于 2025 年 11 月下旬向 Google、Windsurf 和 Cursor 报告了此问题。Cursor 于 12 月 1 日做出反应,修复了该漏洞。Google 最初于 12 月 26 日从其 IDE 中移除了 13 个扩展推荐,并于 1 月 1 日将该问题标记为已修复。Windsurf 尚未回应研究人员。

与此同时,Koi 研究人员占用了以下扩展的命名空间,以防止恶意利用:

ms-ossdata.vscode-postgresql
ms-azure-devops.azure-pipelines
msazurermtools.azurerm-vscode-tools
usqlextpublisher.usql-vscode-ext
cake-build.cake-vscode
pkosta2005.heroku-command

研究人员上传了非功能性的占位扩展,这些扩展不提供实际功能,但仍能阻止供应链攻击。

此外,他们已与 OpenVSX 的运营方 Eclipse Foundation 协调,以验证剩余的引用命名空间,移除非官方贡献者,并应用更广泛的注册表级别保护措施。

目前,没有迹象表明恶意行为者在 Koi 研究人员发现并采取行动之前利用了此安全漏洞。

建议分支 IDE 的用户始终通过手动访问 OpenVSX 注册表并检查扩展是否来自信誉良好的发布者来验证扩展推荐。

更新 [东部时间 1月5日 14:09]:
文章已编辑,以反映 Cursor 告知 Koi 研究人员其已于 2025 年 12 月 1 日修复了该问题。

行内补全:实现思路与关键细节(FIM + Diff + 多层过滤)

想把 “行内补全” 做得好用,核心不是 “能生成”,而是生成后如何稳定落到光标处:不重复、不乱插、不无限循环、单行 / 多行行为符合预期。


先看结论

  • 使用标准 FIM(Fill-In-the-Middle) 流程:prefix + suffix -> middle
  • 内置模型:Pro/Qwen/Qwen2.5-Coder-7B-Instruct(通过统一的 "FIM" 模型名对外提供)
  • 非流式请求拿到完整输出,但内部用 “类流式管道” 逐层过滤(字符级→行级→后处理)
  • 单行补全额外做 Diff:自动判断 “插入” 还是 “替换到行尾”,避免括号 / 后缀重复
  • 多行补全不做 Diff:直接替换到行尾(更符合用户预期,也省成本)


1) 整体架构(从 VSCode 到最终插入)

流程上分 6 段:预过滤 → 分类 → 模板 → 调用与过滤 → 后处理 → Diff(单行)

InlineCompletionProvider
  -> 预过滤(跳过不该补全的场景)
  -> 构建 prefix/suffix(HelperVars)
  -> 单/多行分类
  -> FIM 模板渲染
  -> 调用 FIM API(非流式拿完整结果)
  -> 过滤器管道处理(字符级/行级/后处理)
  -> 单行:Diff 决定 range;多行:替换到行尾
  -> 返回 InlineCompletionItem


2) FIM 请求格式与参数

FIM 模板(Qwen 标准)

<|fim_prefix|>{prefix}<|fim_suffix|>{suffix}<|fim_middle|>

关键约定

  • API 模型名统一用:"FIM"
  • 请求方式:非流式(一次性拿完整结果)
  • max_tokens:单行 64、多行 128(策略性限制 “胡乱续写” 概率)


3) 预过滤:哪些场景直接不补全

目的:便宜地跳过 “补全只会添乱” 的场景,减少无意义请求。

常见跳过项:

  • 配置文件 / 特殊文件模式
  • 未命名空文件
  • 多光标(multi-cursor)
  • 其它明确不应触发 inline completion 的场景


4) 单行 vs 多行:分类策略(决定用户体验)

分类逻辑按优先级(越靠前越强):

  1. Intellisense 选中项:强制单行(避免和补全列表打架)
  2. 单行注释检测:强制单行(注释里多行补全通常噪音大)
  3. 语言特定规则:按语言做微调
  4. 默认:允许多行


5) 过滤器系统:三层拦截,解决 “能生成但不好用”

即使是非流式输出,也可以把 “完整文本” 当成流来处理:逐步截断、跳过、清洗。

LLM 完整输出
 -> 字符级过滤(stop token / suffix 重复 / 首字符换行)
 -> 行级过滤(行数限制 / 重复行 / 相似行 / 空注释 / 双换行)
 -> 后处理(空白、重复上一行、极端重复、去 markdown backticks)
 -> 最终补全

5.1 字符级过滤(更早、更快止损)

典型能力:

  • Stop Token 检测:遇到终止标记立即截断
  • 后缀重复检测:避免生成 “补全 + suffix + 继续乱写”
  • 首字符换行过滤:不让补全以空行开头(体感很关键)

5.2 行级过滤(防循环、防抄下一行)

典型能力:

  • 行数上限:例如超过 50 行直接停止
  • 重复行检测:同一行反复出现(模型陷入循环)就停
  • 相似行检测:生成内容与 “光标下一行” 相似度过高就停(防重复已有代码)
  • 空注释过滤:只输出 //# 这种空注释行直接丢弃
  • 双换行过滤:控制空行数量,避免 “稀碎的大段空白”

5.3 后处理(最终把关)

典型规则:

  • 空白补全直接拒绝
  • 重复上一行(基于 Levenshtein 相似度)直接拒绝
  • 极端重复模式(例如 6 行以上重复)拒绝
  • 去掉模型偶发输出的 Markdown 代码块标记(```)


6) 单行 Diff:解决 “补全重复后缀 / 括号” 的关键

问题本质

FIM 模型对单行位置常见三种输出:

  1. 纯插入:只生成新内容
  2. 重复后缀:把光标后的文本也生成了一遍
  3. 部分重叠:生成内容与后缀部分重叠

如果不处理,最常见的坏体验就是:多一个括号、多一段重复 token

解决方式(单行专用)

diffWords() 比较:

  • currentText:光标后到行尾的已有内容
  • completion:模型给的最后一行补全

然后根据 diff 模式判断:

  • 该不该只 “插入”
  • 还是要 “替换光标到行尾”(即设置 range

Range 语义(VSCode 行为)

  • range = undefined:在光标处插入
  • range = { start: cursor, end: lineEnd }:先删除光标到行尾,再插入(用于清理重复后缀)


7) 多行为什么不做 Diff,而是直接替换到行尾?

多行补全的期望更像 “接管后续内容”,而不是 “精确对齐每个 token”。

选择 “替换到行尾” 的原因:

  • 多行 Diff 成本高,收益不稳定
  • 多行重复后缀概率相对低(且过滤器已拦截一部分)
  • 用户更希望多行补全能 “把后面那段写完”,而不是半插半改


附:代码组织(给想看源码的人)

关键文件(按职责):

  • VvCompletionProvider.ts:主入口,串起 6 阶段流程
  • vvCompletionStreamer.ts:API 调用管理(非流式)
  • vvAutocompleteTemplate.ts:FIM 模板
  • prefiltering.ts:预过滤
  • multiline.ts:单 / 多行分类
  • filters.ts:后处理
  • processSingleLineCompletion.ts:单行 Diff
  • streamFilters/:字符级与行级过滤管道

📌 转载信息
原作者:
allen_zhang
转载时间:
2026/1/1 15:46:53