[科研实践] VS Code (Copilot) + Overleaf (使用 Overleaf Workshop 插件)

[科研实践] VS Code (Copilot) + Overleaf (使用 Overleaf Workshop 插件)

科研圈写文档常用 Latex 环境,尤其是 Overleaf 它自带的 AI 润色工具 Writefull 太难用了。如果能用本地的 CoPilot / Cursor 结合 Overleaf,那肯定超高效!


于是我们找到了 VS Code 里的 Overleaf Workshop 插件。这里已经安装好了,没装过的同学可以直接点击 “安装”

安装后左边会出现 Overleaf Workshop 的图标:

点击右边的“+”:

Overleaf 官网需要登录,这里我们通过 cookie 调用已登录账号的 API:

回到主界面,右键点击 “检查”:


打开检查工具后,找到 “网络”(Network)窗口,搜索 “/project”

/project

如果首次加载没内容,刷新页面就能看到 project 条目了:


点击 project 条目,往下找到 “请求标头”,需要复制一段包含 cookie 的字符串(“神秘代码”)。这段代码全选后按 Ctrl+C 复制:

回到 VS Code,选择 “通过 cookie 登录”,粘贴(Ctrl+V)刚才的 cookie 字符串,回车确认:

这时会列出所有 Overleaf 项目。单击新窗口打开,打开后界面和 Overleaf 一致,左边是 LaTeX 代码,右边是 PDF 预览(“Ctrl+cmd+v” 预览快捷键)。现在试试本地 AI 功能:安装 VS Code 后,可连接 GitHub 或其他 AI 工具(如 CoPilot)

这相当于是用本地AI工具远程操作网页端的Overleaf

接下来就可以畅快写作啦~

快捷键:Ctrl + S 就能直接开始远程编译啦

参考视频:科研论文党王炸组合overleaf+Copilot_哔哩哔哩

Read more

PyWebview浅谈

PyWebview浅谈

pywebview是一个轻量级、跨平台的 Python 库,核心功能是在桌面应用中嵌入系统原生的 WebView 组件,让你可以用 HTML/CSS/JavaScript 构建 UI,同时用 Python 处理逻辑——完美匹配“Web 技术做 UI + Python 做后端”的需求。 1. 核心定位 pywebview 不是“打包 Chromium 的 Electron 替代品”,而是复用系统自带的 WebView(如 Windows 的 Edge/IE、macOS 的 WebKit、Linux 的 GTK+Webkit/Qt WebEngine),因此: * 体积极小(

前端Vibe Coding

前端Vibe Coding

一、打破认知:Vibe Coding不是“摸鱼”,是前端开发的效率革命 1.1 核心定义与起源 Vibe Coding(氛围编程)是由Andrej Karpathy于2025年2月提出的AI驱动开发范式,核心是“自然语言描述需求,AI生成实现,人类聚焦创意与决策” 的协作模式。它并非简单的代码生成工具,而是对前端开发流程的重构——将开发者从CSS调试、重复组件编写等机械劳动中解放,专注于UI交互设计、用户体验优化等创造性工作。 与传统开发的本质区别在于: • 传统前端开发:手动编写90%代码 + 10%创意决策 • Vibe Coding:AI实现70%基础代码 + 30%核心创意+审查优化 1.2 为什么前端最适合Vibe Coding? 前端开发的特性与Vibe Coding的优势高度契合: • 组件化天然适配:UI组件(按钮、卡片、表单)具有强复用性,

《OpenClaw架构与源码解读》· 第 12 章 Cron、Webhooks 与事件驱动自动化

第 12 章 Cron、Webhooks 与事件驱动自动化 前面第 8–10 章介绍的消息处理链路,都是被动响应式的:用户先说话,OpenClaw 才行动。但 OpenClaw 更有价值的地方之一,恰恰是它可以主动出击——在你没有发消息的时候,悄悄把事情做了,再来汇报。 本章介绍三种让 OpenClaw「自己动起来」的机制:Cron 定时任务、Webhooks 外部触发、以及类 Gmail Pub/Sub 的长链路事件源。 12.1 Cron Jobs:让 OpenClaw「记住」该做什么 12.1.1 什么是 Cron Jobs Cron Jobs

JWT 技术(JSON Web Token) 全解:原理、应用与生产级避坑指南

笔者阅读很多 JWT 技术的博文,发现大多只是讲 “JWT 是什么”,而这篇文章重点介绍它为什么出现、结构细节、以及生产环境中最棘手的“注销与续签”问题。 在前后端分离、微服务架构大行其道的今天,JWT(JSON Web Token)几乎成为了身份认证的代名词。 很多开发者只知道它是一个“长长的字符串”,用来做登录校验,但并不清楚它内部的运作机制,以及它在安全性上的潜在风险。本文将从原理、结构、流程、以及最核心的生产陷阱四个维度进行详细拆解。 一、为什么需要 JWT?(Session vs Token) 在 JWT 出现之前,我们主要使用 Session + Cookie 的方式。 1.传统Session的认证痛点 * 服务端有状态:服务端需要保存 Session 数据(内存或Redis)。 * 扩展性差:集群环境下,必须做