【💰】进来来晒晒徽章

xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。


折腾到凌晨,终于搞定了! 用 AI 写了一个脚本,可以用一行命令让你正在使用的免费 SLL 可以自动化续签! 对小白和初级用户非常友好,无学习成本。 完全免费,只需关注我公众号,哈哈不容易多支持
欢迎交流,大佬可以 pass 了!只适合初级用户!!
适用场景:就是你在宝塔里面已经用了一堆的免费 SSL,想一键自动化。这种情况下,用我这个比较方便。

这篇文章从基本原理出发完整拆解变分自编码器(VAE)的构建过程。重点不在数学推导而在于把概念落到足够具体的层面:完成实现、训练、调试和部署。每个组件做了什么、为什么需要它、代码里怎么写文章都会逐一交代,后半部分会逐行走读一个最小化的 PyTorch 实现,并介绍训练完成后的几种推理模式。 当需要理解数据中潜藏的模式时,变分自编码器(VAE)是一个值得考虑的选项。它不只是做数据压缩而是以连续、可插值的方式去捕捉数据背后的生成结构:覆盖可能性的完整范围。训练结束后模型既能重建已有样本,也能生成新的逼真样本,还能对新数据做异常检测。 标准自编码器的做法是把数据压缩到低维表示再还原。问题出在它学到的潜在空间往往缺乏结构:相邻的点未必对应相似的数据,随机采样产出的结果也大多没有意义。 VAE 对潜在空间施加了正则化约束。输入不再被映射到单一的潜在向量,而是映射到一个分布:通常是高斯分布。训练期间,模型让这些分布贴近一个已知的先验(一般取标准正态分布),最终得到的潜在空间平滑且有组织,可以安全地从中采样和推断。 这正是 VAE 在异常检测和表示学习中发挥作用的原因。重建偏差可以在原始特征空间中得到直观解读;潜在偏差如果实现了解耦也具有可解释性,但缺少专门的训练目标(如 β-VAE、FactorVAE 等)时,解耦并无保证。 VAE 由三个概念层面的部件组成——编码器、潜在空间(通过采样/重参数化技巧实现)、解码器。 编码器接收输入,输出两个向量:均值 μ 和方差 σ²,二者共同定义潜在空间上的概率分布。采样步骤利用一种保持可微性的技巧从该分布中抽取潜在向量,解码器再拿到这个向量去重建原始输入。 训练过程同时平衡两个目标:重建要准确,潜在分布要贴近先验。VAE 的结构特性正来源于这种平衡。 VAE 的损失函数同时追求两件事:把输入数据重建得尽可能准,并约束潜在空间服从标准正态分布。重建损失(比如均方误差)度量输出与输入的偏差;KL 散度度量学习到的潜在分布与标准正态分布之间的距离。 换个角度看——重建损失在奖励保真度,KL 损失则在防止模型死记硬背,迫使潜在空间维持良好的分布形态。 下面逐步走读一个最小化的 PyTorch 实现。示例假定输入为表格或展平后的数据,但同样的思路适用于图像和序列。 编码器将输入向量映射为两个输出:潜在分布的均值和对数方差。 到这一步为止,还没有涉及任何概率运算。代码只是在预测分布的参数。 直接从分布中采样会切断梯度的传播路径。重参数化技巧的做法是把采样拆解为一个确定性函数加上随机噪声。 梯度照常经由 μ 和 σ 回传,随机性又被保留下来。 解码器负责把潜在向量映射回原始输入空间。 解码器不需要知道任何关于概率分布的事情,它只做重建。 前向传播的流程与概念上的流程完全一致。 beta 参数控制重建质量与潜在正则化之间的权衡。当 beta > 1 时即为 β-VAE——以牺牲重建精度为代价换取更解耦的潜在因子。 训练阶段模型只接触数据样本,优化上述组合损失。有一点需要特别留意:用于异常检测时,VAE 通常仅在正常数据上训练,模型由此学会"正常"的分布形态,异常样本则在推理时暴露为高重建误差或偏离常规的潜在分布。 训练结束后,手里拿到的远不止一个重建模型。潜在空间中的距离和偏差都携带语义:可以检视哪些潜在维度在异常出现时发生了漂移,可以对比重建结果,也可以跟踪 KL 散度随时间的变化趋势。 可解释性在异常检测中就是这样进行。如果潜在空间已解耦,某个因子的异常即可定位到具体原因;即使未能解耦,仍然可以在原始特征空间中分析重建偏差,回溯根因。 VAE 的用途不止一种。训练完成后根据目标不同可以被复用在多个场景中,编码器-解码器架构加上结构化的潜在空间给了它足够的适应余地。 训练结束后 VAE 已经建立了对"正常"数据的内部表征。新输入经过编码器→潜在空间→解码器后,将输出与原始输入做比较即可判断异常——重建误差越大,样本越可能偏离正常模式。以信用卡交易为例,消费模式异常的交易在重建时会产生明显偏差,对应较高的异常得分。类似场景还包括设备监控和医疗异常检测。关键推理信号是重建误差,或样本在已学分布下的似然度。 无需任何特定输入,直接在潜在空间中采样再经解码器输出,即可生成新的逼真样本。潜在空间在训练期间已被约束为近似标准正态分布,从中采样的点解码后会产生与训练数据风格相近的新数据。典型场景包括数据增强、系统仿真和压力测试。在医学领域,可以产出罕见病的逼真影像,或合成客户交易历史用于测试。 关键推理信号是从潜在先验分布采样(z ~ N(0,1)),经解码输出新样本。 在标准 VAE 基础上引入额外的条件信息,就得到了条件 VAE(CVAE)。例如基于标签生成图像,或基于客户群体生成合成交易、生成某类肿瘤的影像,或某商户类别的交易记录。应用方向包括定向数据增强、场景模拟、受控合成实验。 对潜在空间做分析和修改,可以观察输出如何随之变化。潜在遍历——固定其余维度、单独改变一个维度——能揭示各因子的语义含义;潜在空间本身也可用于聚类。一个具体的例子:在机械传感器数据中,某个潜在因子可能对应振动频率,调整它就能模拟机器提速后的状态。这类操作在可解释性分析、根因定位和场景规划中都有用处。 训练好的 VAE 可以处理不完整输入——编码后在潜在空间中采样,再解码出完整的重建,从而填补缺失数据。典型场景有数据清洗、预处理和错误修正,比如补全图像中的缺失像素、物联网数据中丢失的传感器读数,或者残缺不全的交易记录。 VAE模型要做的核心决策是:哪些信息值得保留,哪些可以丢弃。理清这一点之后数学只是执行层面的工具,不再是障碍。 一个经过良好训练的 VAE 产出的不只是重建结果,它提供了一个观察数据行为的视角——数据在哪里偏离,复杂系统如何被压缩进一个紧凑且可解读的表示里。本系列的下一篇将聚焦 VAE 在异常检测中的实际应用。 https://avoid.overfit.cn/post/17cbb214d50f4e469a458c061b3c5138 by Ayo AkinkugbeVAE 为什么存在
VAE 在学习重建数据的同时,也在学习一个形态接近简单概率分布的潜在空间。
三个核心组件

损失函数
VAE 的损失函数同时追求两件事:把输入数据重建得尽可能准,并约束潜在空间服从标准正态分布。
从理论到代码
定义编码器
import torch # PyTorch核心库
import torch.nn as nn # 神经网络构建模块
import torch.nn.functional as F # 常用激活函数和工具函数
class Encoder(nn.Module): # 将编码器定义为神经网络模块
def __init__(self, input_dim, latent_dim):
super().__init__() # 初始化父类nn.Module
# 第一个全连接层:
# 接收输入数据并将其映射到隐藏表示
self.fc1 = nn.Linear(input_dim, 128)
# 输出潜在分布均值(mu)的线性层
self.fc_mu = nn.Linear(128, latent_dim)
# 输出潜在分布对数方差(log σ²)的线性层
# 使用对数方差是为了数值稳定性
self.fc_logvar = nn.Linear(128, latent_dim)
def forward(self, x):
# 将输入通过第一层并应用ReLU激活函数
# 从原始输入中提取有用特征
h = F.relu(self.fc1(x))
# 计算潜在分布的均值
mu = self.fc_mu(h)
# 计算潜在分布的对数方差
logvar = self.fc_logvar(h)
# 返回两个参数,以便后续从分布中采样
return mu, logvar编码器将输入数据压缩为紧凑的潜在表示(μ 和 σ),捕捉其关键特征。
重参数化技巧
def reparameterize(mu, logvar):
# 将对数方差转换为标准差
# std = sqrt(variance)
# 使用logvar保持训练的数值稳定性
std = torch.exp(0.5 * logvar)
# 从标准正态分布中采样随机噪声
# 这个噪声是使VAE具有随机性的关键
eps = torch.randn_like(std)
# 创建潜在向量z
# z = 均值 + (随机噪声 * 标准差)
# 这使得梯度在训练过程中能够通过mu和std流动
return mu + eps * std重参数化技巧让 VAE 能在潜在空间中采一个随机点,同时不破坏反向传播。本质上,它把随机性改写成了网络可以求导的形式。
定义解码器
class Decoder(nn.Module):
def __init__(self, latent_dim, output_dim):
# 初始化PyTorch父模块
super().__init__()
# 第一个全连接层
# 接收潜在向量z并将其扩展为隐藏表示
self.fc1 = nn.Linear(latent_dim, 128)
# 输出层
# 将隐藏表示映射回原始输入大小
# 产生重建结果
self.fc_out = nn.Linear(128, output_dim)
def forward(self, z):
# 将潜在向量z通过第一个线性层
# 并应用ReLU引入非线性
h = F.relu(self.fc1(z))
# 将隐藏表示通过输出层
# 产生重建的输入
return self.fc_out(h)解码器从采样得到的潜在向量出发,尝试恢复出与原始输入匹配的数据。
组合在一起:VAE
class VAE(nn.Module):
def __init__(self, input_dim, latent_dim):
super().__init__()
# 编码器将输入数据映射到潜在分布(mu, logvar)
self.encoder = Encoder(input_dim, latent_dim)
# 解码器将潜在向量z映射到重建的输入
self.decoder = Decoder(latent_dim, input_dim)
def forward(self, x):
# 将输入通过编码器获取潜在分布参数
mu, logvar = self.encoder(x)
# 使用重参数化技巧采样潜在向量z
z = reparameterize(mu, logvar)
# 将潜在向量解码回输入空间
recon_x = self.decoder(z)
# 返回重建结果和潜在统计量(用于计算损失)
return recon_x, mu, logvar损失函数的代码实现
def vae_loss(recon_x, x, mu, logvar, beta=1.0):
# 重建损失:
# 衡量输出与原始输入的接近程度
recon_loss = F.mse_loss(recon_x, x, reduction='mean')
# KL散度损失:
# 惩罚潜在分布偏离标准正态分布过远的情况
kl_loss = -0.5 * torch.mean(
1 + logvar - mu.pow(2) - logvar.exp()
)
# 总损失平衡重建质量
# 和潜在空间正则化
return recon_loss + beta * kl_loss训练循环
# 创建优化器来更新VAE的参数
# Adam是训练神经网络的常用且稳定的选择
optimizer = torch.optim.Adam(vae.parameters(), lr=1e-3)
# 多次遍历数据集
for epoch in range(num_epochs):
# 遍历数据的批次
for batch in dataloader:
# 获取当前批次的输入数据
x = batch
# 前向传播:
# 编码 -> 采样潜在z -> 解码
recon_x, mu, logvar = vae(x)
# 计算VAE损失(重建损失 + KL散度)
loss = vae_loss(recon_x, x, mu, logvar)
# 清除上一步的旧梯度
optimizer.zero_grad()
# 反向传播:
# 计算损失相对于模型参数的梯度
loss.backward()
# 使用优化器更新模型参数
optimizer.step()用于异常检测时,VAE 通常仅在正常数据上训练。模型学到"正常"的分布形态后,异常样本会以高重建误差或偏离常规的潜在分布暴露出来。
训练完成后得到了什么
实际应用——训练好的 VAE 的推理模式
异常检测

合成数据生成

条件生成

潜在空间操作与可解释性

数据填补与重建

总结
我们是袋鼠云数栈 UED 团队,致力于打造优秀的一站式数据中台产品。我们始终保持工匠精神,探索前端道路,为社区积累并传播经验价值。 本文作者:霁明 在 AIWorks 的工作流和 Agent 编排系统中,有一个核心需求:支持在节点配置面板的配置项中引用上游节点的输出变量。例如,一个 LLM 节点需要引用“开始节点”的用户输入或自定义变量,或者引用上一个“HTTP 请求节点”的返回结果。 最直接的方案是使用传统的 Input 或 Textarea 组件,配合变量占位符语法如 我们期望的用户体验是: 实现后的效果如下: Lexical 是 Meta(Facebook)于 2022 年开源的一个可扩展的可扩展富文本编辑器框架,它专注于提供高可靠性、出色的可访问性和高性能,让开发者能构建出从简单文本到复杂富文本协作编辑器的应用。它核心是一个轻量、无依赖的编辑器,通过模块化的插件机制支持自定义功能,支持与 React 等前端框架进行绑定,旨在简化富文本编辑器的开发和维护。 在深入实现之前,我们需要理解 Lexical 的几个核心概念。 Lexical 采用不可变状态设计。编辑器的所有内容都存储在 关键点: Lexical 的内容由树状节点结构组成: 核心节点类型: DecoratorNode 是实现自定义可视化元素的关键,后文会详细讲解。 Lexical 使用命令模式处理用户输入和操作: Lexical 内置了许多命令,例如:KEY\_DOWN\_COMMAND、UNDO\_COMMAND、INSERT\_TAB\_COMMAND 等,具体可查看LexicalCommands.ts 命令优先级从高到低: 节点转换是 Lexical 的强大特性,允许监听特定类型节点的变化并自动处理: 这是实现“输入特定文本自动转换为自定义节点”的核心机制。 Lexical 采用组合式插件设计: 插件通过 这是整个方案的核心。我们通过继承 关键设计点: 当用户输入 工作流程: 注意这里我们并不直接插入 变量格式通过正则表达式定义: 会渲染一个可视化变量标签,包含节点图标、节点名称和变量名,效果如下: 在某些场景(如 HTTP 节点的 URL 输入、条件节点的表达式输入),我们需要限制编辑器为单行模式: 这个插件通过两种机制实现单行限制: 编辑器内容需要与后端数据同步,我们采用纯文本格式存储。 编辑器状态初始化: 编辑器状态同步: 由于 本文介绍了基于 Lexical 实现工作流变量输入编辑器的完整方案: 这套方案适用于: 欢迎关注【袋鼠云数栈 UED 团队】\~1. 引言
1.1 背景与动机
{{nodeId.variableName}}。但这种方案存在明显的用户体验问题:/ 字符时,自动弹出变量选择菜单{{#nodeId.variableName#}} 格式,便于后端解析1.2 最终效果

/,即刻弹出变量选择悬浮菜单2. 技术选型:为什么选择 Lexical?
2.1 Lexical 简介
2.2 主流富文本框架对比
维度 Lexical Slate Tiptap ProseMirror Editor.js Quill 维护方 Meta 社区 Tiptap 团队 社区 CodeX 团队 社区 是否开源 是 (MIT) 是 (MIT) 是 (MIT) 是 (MIT) 是 (Apache 2.0) 是 (BSD) React 支持 原生 原生 支持 需适配层 支持 支持 学习曲线 中等 中等偏高 中等偏低 陡峭 低 低 社区生态 增长迅速 稳定 繁荣 稳定 稳定 稳定 TS 支持 完善 完善 完善 支持 支持 支持 核心优势 高可靠性、高性能、Meta 背书,适合现代 web 应用 灵活性极高、符合 React 直觉 兼顾易用与强大、UI 无头 协同编辑天花板、极其严谨 块级结构、天然适合 CMS 简单易用、稳定 主要劣势 文档仍可优化 升级可能断层 协作/高级功能需付费订阅 开发门槛极高 跨行选择等体验有限 定制复杂功能较难 适用场景 现代高性能 React 应用 需要极度定制 UI 的 React 项目 快速交付的产品 复杂协同办公 (Google Docs 类) 新闻发布、类 Notion 编辑器 评论区、简单博客、CMS 2.3 选择 Lexical 的理由
2.4 AIWorks 使用的依赖
{
"lexical": "^0.35.0",
"@lexical/react": "^0.35.0",
"@lexical/text": "^0.35.0",
"@lexical/utils": "^0.35.0"
}lexical:核心库,提供编辑器状态管理、节点系统、命令系统@lexical/react:React 绑定,提供 Composer、插件等组件@lexical/text:文本处理工具,包含文本实体(Text Entity)相关功能@lexical/utils:工具函数,如 mergeRegister 用于批量注册/注销3. Lexical 核心概念速览
3.1 编辑器状态
EditorState 中,任何修改都会产生新的状态对象。// 读取状态(只读操作)
editor.getEditorState().read(() => {
const root = $getRoot();
const text = root.getTextContent();
});
// 更新状态(写操作)
editor.update(() => {
const selection = $getSelection();
if ($isRangeSelection(selection)) {
selection.insertText('Hello');
}
});read() 内只能读取,不能修改update() 内可以读取和修改$ 开头的函数(如 $getRoot、$getSelection)只能在这两个回调中调用3.2 节点体系
RootNode
└── ParagraphNode (ElementNode)
├── TextNode ("普通文本")
├── VariableLabelNode (DecoratorNode)
└── TextNode ("更多文本")类型 说明 示例 RootNode根节点,每个编辑器有且仅有一个 - ElementNode容器节点,可包含子节点 ParagraphNode, ListNode TextNode文本叶子节点 普通文本内容 DecoratorNode装饰器节点,可渲染自定义 React 组件 变量标签、提及、表情 3.3 命令系统
// 创建自定义命令
const HELLO_WORLD_COMMAND: LexicalCommand<string> = createCommand();
// 注册自定义命令行为
editor.registerCommand(
HELLO_WORLD_COMMAND,
(payload: string) => {
console.log(payload);
return false;
},
COMMAND_PRIORITY_LOW,
);
// 触发对应命令
editor.dispatchCommand(HELLO_WORLD_COMMAND, 'Hello World!');COMMAND_PRIORITY_CRITICAL (4)COMMAND_PRIORITY_HIGH (3)COMMAND_PRIORITY_NORMAL (2)COMMAND_PRIORITY_LOW (1)COMMAND_PRIORITY_EDITOR (0)3.4 节点转换
editor.registerNodeTransform(TextNode, (textNode) => {
// 每当 TextNode 发生变化时触发
const text = textNode.getTextContent();
// 检测特定模式并转换
if (isVariablePattern(text)) {
const variableNode = $createVariableLabelNode(...);
textNode.replace(variableNode);
}
});3.5 插件架构
<LexicalComposer initialConfig={config}>
{/* 核心编辑插件 */}
<RichTextPlugin contentEditable={...} placeholder={...} />
{/* 功能插件 */}
<HistoryPlugin /> {/* 撤销/重做 */}
<OnChangePlugin /> {/* 内容变化监听 */}
<VariableLabelPlugin /> {/* 自定义:变量渲染 */}
<VariableLabelPickerPlugin />{/* 自定义:变量选择 */}
</LexicalComposer>useLexicalComposerContext() 获取编辑器实例:const MyPlugin = () => {
const [editor] = useLexicalComposerContext();
useEffect(() => {
// 使用 editor 注册命令、转换等
}, [editor]);
return null; // 无 UI 的纯逻辑插件
};4. 整体架构设计
4.1 架构图

4.2 组件职责划分
组件/模块 职责 PromptEditor业务组件,连接 workflow store,处理多行提示词场景 VariableEditor业务组件,处理单行变量输入场景 Editor核心组件,封装 Lexical 编辑器和所有插件 VariableLabelNode自定义节点,渲染为 React 组件,用于反显变量标签 VariableLabelPlugin自定义插件,监听文本变化,将变量语法转换为变量标签 VariableLabelPickerPlugin自定义插件,处理 / 触发和变量选择SingleLinePlugin自定义插件,限制单行输入 4.3 数据流及渲染过程
5. 核心实现详解
5.1 自定义 VariableLabelNode
DecoratorNode 来创建一个可以渲染 React 组件的自定义节点:export class VariableLabelNode extends DecoratorNode<JSX.Element> {
__variableKey: string; // 变量的完整标识,如 {{#nodeId.name#}}
__variableLabel: string; // 显示用的标签
__isSystemVariable: boolean; // 是否为系统变量
static getType(): string {
return "variableLabel";
}
// 返回 React 组件作为节点的渲染内容
decorate(): JSX.Element {
return (
<VariableLabel
variableLabel={this.__variableLabel}
isSystemVariable={this.__isSystemVariable}
/>
);
}
// ... 其他方法
}VariableLabel 组件,实现可视化展示5.2 触发器:
/ 唤起变量选择菜单/ 时,我们需要弹出一个变量选择菜单。这里使用 Lexical 官方提供的 LexicalTypeaheadMenuPlugin:const VariableLabelPickerPlugin = ({ variableGroups }) => {
const [editor] = useLexicalComposerContext();
// 自定义触发匹配:检测用户输入 /
const checkForTriggerMatch = useBasicTypeaheadTriggerMatch("/", {
minLength: 0,
});
// 用户选择变量后的处理逻辑
const onSelectOption = useCallback((selectedOption, nodeToRemove, closeMenu) => {
editor.update(() => {
// 删除触发字符 /
if (nodeToRemove) nodeToRemove.remove();
// 插入变量文本,格式为 {{#nodeId.variableName#}}
selection.insertNodes([
$createTextNode(`{{#${selectedOption.nodeId}.${selectedOption.name}#}}`),
]);
closeMenu();
});
}, [editor]);
// ...
};/ → checkForTriggerMatch 返回匹配结果VariableMenu 组件,显示可用变量列表onSelectOption 插入格式化的变量文本VariableLabelPlugin 监测到文本变化,自动转换为节点VariableLabelNode,而是插入格式化的文本字符串。这是为了解耦选择逻辑和渲染逻辑——文本到节点的转换由下一个插件统一处理。5.3 文本实体识别与自动转换
VariableLabelPlugin 负责监听文本变化,当发现符合变量格式的文本时,自动将其转换为 VariableLabelNode:const VariableLabelPlugin = () => {
const [editor] = useLexicalComposerContext();
// 创建变量节点的工厂函数
const createVariableLabelPlugin = useCallback((textNode: TextNode) => {
const text = textNode.getTextContent();
const info = parseVariableTokenInfo(text);
return $createVariableLabelNode(
text,
info?.variableName ?? "",
info?.isSystemVariable ?? false,
);
}, []);
useEffect(() => {
// 注册文本实体转换器
registerLexicalTextEntity(
editor,
getVariableMatchInText, // 正则匹配函数
VariableLabelNode,
createVariableLabelPlugin,
);
}, [editor]);
// ...
};// 用户变量格式:{{#uuid.variableName#}}
export const USER_VARIABLE_REGEX = new RegExp(
"(\\{\\{)(#)([a-fA-F0-9-]{36}\\.[a-zA-Z0-9_]+)(#)(\\}\\})",
);
// 系统变量格式:{{#system.xxx#}}
export const SYSTEM_VARIABLE_REGEX = new RegExp(
"(\\{\\{)(#)(system\\.[a-zA-Z0-9_]+)(#)(\\}\\})",
);registerLexicalTextEntity 是核心的转换逻辑,它注册了两个 Transform:export function registerLexicalTextEntity(editor, getMatch, targetNode, createNode) {
// 1. TextNode → VariableLabelNode 的转换
const textNodeTransform = (node: TextNode) => {
const text = node.getTextContent();
const match = getMatch(text);
if (match === null) return;
// 分割文本节点,将匹配部分替换为目标节点
const [nodeToReplace, remainingNode] = node.splitText(match.start, match.end);
const replacementNode = createNode(nodeToReplace);
nodeToReplace.replace(replacementNode);
// 递归处理剩余文本(可能包含多个变量)
if (remainingNode) textNodeTransform(remainingNode);
};
// 2. 反向转换:当节点内容不再匹配时还原为文本
const reverseNodeTransform = (node) => {
const match = getMatch(node.getTextContent());
if (match === null) {
replaceWithSimpleText(node); // 还原为普通文本
}
};
return [
editor.registerNodeTransform(TextNode, textNodeTransform),
editor.registerNodeTransform(targetNode, reverseNodeTransform),
];
}5.4 变量标签的可视化渲染
VariableLabel 组件负责将变量以友好的方式呈现给用户:const VariableLabel = ({ variableLabel, isSystemVariable }) => {
const { Icon, nodeLabel, displayLabel } = useVariableLabelInfo(
variableLabel,
isSystemVariable,
);
return (
<div className="inline-flex items-center rounded-sm bg-bg-primary-4 px-[2px]">
<Icon className="flex-shrink-0" />
<span className="text-text-2-icon">{nodeLabel}</span>
<span className="text-text-4-description">/</span>
<span className="text-primary-default">{displayLabel}</span>
</div>
);
};
5.5 编辑器单行模式
const SingleLinePlugin = ({ onEnter }) => {
const [editor] = useLexicalComposerContext();
useEffect(() => {
mergeRegister(
// 1. 限制 RootNode 只保留一个段落
editor.registerNodeTransform(RootNode, (rootNode) => {
if (rootNode.getChildrenSize() <= 1) return;
const children = rootNode.getChildren();
const firstChild = children[0];
// 将后续段落的内容合并到第一个段落
for (let i = 1; i < children.length; i++) {
const paragraph = children[i];
paragraph.getChildren().forEach(child => firstChild.append(child));
paragraph.remove();
}
}),
// 2. 拦截 Enter 键
editor.registerCommand(KEY_ENTER_COMMAND, (event) => {
event?.preventDefault();
onEnter?.(); // 可以触发外部回调,如提交表单
return true;
}, COMMAND_PRIORITY_HIGH),
);
}, [editor, onEnter]);
return null;
};5.6 编辑器状态初始化与同步
export const textToEditorState = (text = "") => {
const lines = text.split("\n");
const paragraph = lines.map((p) => ({
children: [{ text: p, type: "text", ... }],
type: "paragraph",
//...
}));
return JSON.stringify({
root: { children: paragraph, type: "root", ... },
});
};const handleEditorChange = (editorState: EditorState) => {
const text = editorState.read(() => {
return $getRoot()
.getChildren()
.map((p) => p.getTextContent())
.join("\n");
});
onChange(text);
};VariableLabelNode.getTextContent() 返回原始变量格式({{#nodeId.name#}}),导出的文本可以直接存储,再次加载时会自动转换回节点形式。6. 总结
/ 触发展示变量选择菜单最后
袋鼠云数栈 UED 团队持续为广大开发者分享技术成果,相继参与开源了欢迎 star
Go运行时(runtime)是Go高性能和高并发的核心支撑,其中内存管理与垃圾回收是关键。今天将深入底层机制,理解Go程序如何分配内存、如何决定数据的生命周期、以及Go垃圾回收器是如何工作的。 1、Go内存管理体系概览 Go使用一种分层式、针对并发优化的内存管理架构。可以概括为:线程本地分配(arena+mcache)+全局分配(central)+垃圾回收(GC),也就是减少锁争用+高速内存分配+自动回收。 2、内存分配器 Go的内存分配器模仿TCMalloc(TCMalloc—Design document for the C/C++ memory allocator TCMalloc, which the Go memory allocator is based on.),主要分三层: 2.1 堆(Heap):有runtime管理的大块连续内存区域 Go并不直接向操作系统请求小块内存,而是向操作系统申请一块(64MB大小)内存,这块内存在操作系统的术语叫Arena(竞技场),Go在Arena内做更细粒度的管理 2.2 中心缓存(Central Cache):全局共享的小对象池(加锁) Central按size class将对象划分为8B~32KB的多种规格: 每个size class都有一个central列表 用于分配中等频率的内存 有锁(mutex)保证多线程安全 2.3 mcache:每个P拥有的线程本地缓存(无锁) Go的GMP模型中,每个P(处理器)拥有一个mcache: 本地缓存,分配速度极快 小对象分配的时间复杂度是O(1),直接从mcache中拿 mcache没了才从Central Cache获取 3、小对象和大对象的分配策略 4、栈内存和堆内存 Go使用可憎长栈(由2KB~8GB): 栈内存快、无需GC,函数返回自动销毁 堆内存慢,需要GC管理 因此,尽可能把对象放在栈内存上,更高效,要做到这一点,依赖逃逸分析。 5、逃逸(Escape)分析 什么是逃逸?编译器决定变量放在栈上还是放在堆上,放在堆上的就产生了逃逸。可以用以下命令来查看自己的程序哪些地方产生了逃逸: 5.1 什么情况下变量会逃逸? 5.1.1 返回值逃出当前作用域 5.1.2 变量被存到interface、空interface时 5.1.3 闭包引用的外部变量 5.1.4 大量数据复制到channel时也可能逃逸 5.1.5 编译器无法证明变量的生命周期,例如发送指针到通道 6、Go垃圾回收(GC)整体流程 Go的GC是并发标记、并发清扫: 世界停止很短 GC是三色表记法 并发+增量+自适应(根据GOGC调整) 7、GC完整流程图 8、三色标记法(Tri-Color Marking) 三种颜色的含义: GC从Roots开始扫描(栈、全局变量、寄存器),步骤: 8.1 初始化:所有对象都是白色 8.2 将Root对象标记为灰色,进入灰色队列 8.3 循环处理灰色对象队列 对每个灰色对象:把它的子对象标记为灰色,自己变为黑色 8.4 结束时:黑色存活,白色将在Sweep阶段被回收 9、写屏障(Write Barrier):并发GC保证正确性的关键 并发GC时用户程序还在运行,会出现:新引用出现或者白对象被指向,导致对象遗漏,Go使用混合写屏障来保证三色不变性。 写屏障规则: 在程序写指针(p=q)时:将新引用的对象标记为灰色,将旧引用的对象标记为灰色(必要时) 核心保证:黑对象永远不指向白对象 10、Sweep阶段:并发清除白色对象,这个阶段和程序并发运行,不会产生STW(Stop the word) 11、GOGC:GC调度器 GOGC默认是100,表示:当本来GC后heap增长100%,再次触发GC。 12、从GC视角出发,如何写出更高效的代码? *源码地址* 1、公众号“Codee君”回复“每日一Go”获取源码 2、源码获取链接: https://pan.baidu.com/s/1B6pgLWfSgMngVeFfSTcPdg?pwd=jc1s 提取码: jc1s 如果您喜欢这篇文章,请点赞、推荐+分享给更多朋友,万分感谢!
文末有源码下载链接!
go build -gcflags "-m -m"




┌────────────┐
│ Root Scan │ ← STW(短暂)
└─────┬──────┘
│
▼
┌────────────┐
│ Marking │ ← 并发(goroutine 与 GC 同时运行)
├────────────┤
│ Write Barrier(写屏障) │
└─────┬──────┘
│
▼
┌────────────┐
│ Mark Done │ ← STW(短暂)
└─────┬──────┘
│
▼
┌────────────┐
│ Sweep │ ← 并发
└────────────┘
GOGC=50 // 更频繁 GC
GOGC=200 // 更少 GC
GOGC=off // 关闭自动 GC
前几天,OpenClaw 2026.2.26 有重大更新,把 ACP Agents 作为一等公民了:这样 OpenClaw 可以作为 ACP Clients 连接上任何的 ACP Agents 了。
不过,早在一月份,OpenClaw 自己就可以作为 ACP Agent ,被其他任意 ACP Client 所连接。
我就在想,如果能通过 VS Code 来连上 OpenClaw ,岂不是更方便?
于是,我今天就立马更新了我的 VS Code ACP Client extension,添加了对 OpenClaw 的支持!

不过,值得注意的是,最近版本的 OpenClaw 作为 ACP Agent 似乎有些 bug ,我使用的是 v2026.1.30 版本的 OpenClaw ,可以如丝般顺乎地操作~
npm i -g [email protected]
目前,ACP Client extension 已经默认支持 GitHub Copilot 、Claude Code 、Gemini CLI 、Qwen Code 、OpenCode 、Codex CLI 、Qoder CLI 、Auggie CLI 、OpenClaw 这九个 Agent 。
当然也可以另外配置,连接更多的 ACP Agent 。
项目的代码完全开源:
https://github.com/formulahendry/vscode-acp
欢迎围观或者使用~
简介:memcpy、memmove函数的使用与模拟实现,memset、memcmp函数的使用。 如下图所示,当复制的内容重叠时会有两种情况。用不同的复制顺序分别处理即可。 其实,在 举个例子: 举个例子:1
memcpy使用和模拟实现void * memcpy ( void * destination, const void * source, size_t num );memcpy从source的位置开始向后复制num个字节的数据到destination指向的内存位置。\0,的时候并不会停下来。source和destination有任何的重叠,复制的结果都是未定义的。(需要注意的是部分编译器进一步完善了memcpy函数的功能使其可以正常复制重叠内容,这种完善是非必须的,在其他编译器中可能不支持。若要复制重叠的内容用memmove最佳)memcpy的模拟实现:void* my_memcpy(void* des, const void* src, size_t num)
{
assert(des && src);
void* ret = des;
while (num--)
{
*(char*)des = *(char*)src;
des = (char*)des + 1;
src = (char*)src + 1;
}
return ret;
}2
memmove使用和模拟实现void * memmove ( void * destination, const void * source, size_t num );memcpy的差别就是memmove函数处理的源内存块和目标内存块是可以重叠的。memmove函数处理。memcpy的模拟实现中采用的从前向后的拷贝,已经完成了对des < src这种情况的处理。
memmove的模拟实现:void* my_memmove(void* des, const void* src, size_t num)
{
assert(des && src);
void* ret = des;
if (src > des)
{
//前——>后
while (num--)
{
*(char*)des = *(char*)src;
des = (char*)des + 1;
src = (char*)src + 1;
}
}
else
{
//后——>前
while (num--)
{
*((char*)des + num) = *((char*)src + num);
}
//des = (char*)des + num - 1;
//src = (char*)src + num - 1;
//while (num--)
//{
// *(char*)des = *(char*)src;
// des = (char*)des - 1;
// src = (char*)src - 1;
//}
}
return ret;
}3
memset函数的使用void * memset ( void * ptr, int value, size_t num );memset是用来设置内存的,将内存中的值以字节为单位设置成想要的内容。#include <stdio.h>
#include <string.h>
int main()
{
char str[] = "hello world";
printf("%s\n", str);
memset(str, 'x', 6);
printf("%s\n", str);
return 0;
}4
memcmp函数的使用int memcmp ( const void * ptr1, const void * ptr2, size_t num );ptr1和ptr2指针指向的位置开始,向后的num个字节
#include <stdio.h>
#include <string.h>
int main()
{
int arr1[] = { 1,2,3,4,5,6,7,8,9,10 };
int arr2[10] = { 1,2,3,4};//0 0 0 0 0 0
int r = memcmp(arr1, arr2, 17);
printf("%d\n", r);
return 0;
}
别再为嵌套公式头疼了!这款神器能让 AI 直接读懂你的 Excel 工作簿,实时解释、编辑和调试公式,就像有个高手坐在旁边手把手教你。

热度:🔺379
访问官网 | Product Hunt 详情
广告投放不用再在七个平台间来回切换了!只需一个指令,Pixel 就能帮你在 LinkedIn、Meta、Google 等主流渠道创建、发布并优化广告,让每一分预算都花在刀刃上。

热度:🔺308
访问官网 | Product Hunt 详情
iPhone 用户终于能享受真正的离线语音控制了!这款应用依靠轻量模型,让你用自然指令直接操作手机——创建日历、打开地图或开关手电筒,完全不用联网。

热度:🔺236
访问官网 | Product Hunt 详情
写歌词、编旋律找不到感觉?让 AI 当你的创意伙伴,把天马行空的想象变成动感的音乐曲目,轻松玩转不同风格。

热度:🔺208
访问官网 | Product Hunt 详情
电商卖家福音来了!上传一张产品照片,几秒钟就能生成全套 AI 摄影集——工作室、生活方式和模特照一应俱全,快速在亚马逊、Etsy 等平台抢占先机。

热度:🔺173
访问官网 | Product Hunt 详情
想让你 Mac 的外观和周围环境和谐一致?Solace 在菜单栏默默运行,根据天气和时间自动调整黑暗模式、壁纸和色调,带来沉浸式体验。

热度:🔺170
访问官网 | Product Hunt 详情
前端开发别再“盲写”代码了!这款 AI 工具能截图识别 UI,把界面元素映射到代码上,直接在浏览器里验证修复效果,确保一次搞定。

热度:🔺167
访问官网 | Product Hunt 详情
分享 AI 提示还在复制粘贴?输入任何提示,秒获预填好的可分享链接,支持 ChatGPT、Claude 等主流工具,免注册又私密。

热度:🔺122
访问官网 | Product Hunt 详情
学生和深度工作者的救星!这个极简空间把番茄钟、任务管理、笔记和学习音乐全打包,打开就能专注,规划学习毫不费力。

热度:🔺112
访问官网 | Product Hunt 详情
Solana 开发者看过来!这个工具能替代传统测试验证器,让你用主网账户在本地模拟程序,基础设施即代码部署,开发之旅更顺畅。

热度:🔺104
访问官网 | Product Hunt 详情

开发者朋友们大家好: 这里是 「RTE 开发者日报」 ,每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE(Real-Time Engagement) 领域内「有话题的技术 」、「有亮点的产品 」、「有思考的文章 」、「有态度的观点 」、「有看点的活动」,但内容仅代表编辑的个人观点,欢迎大家留言、跟帖、讨论。 本期编辑:@瓒an、@鲍勃 1、DeepSeek 悄悄上线新论文,北大清华联创 近期,DeepSeek 联合北京大学与清华大学悄悄上线了一篇论文,正式发布名为 DualPath 的新技术方案,重点解决了 AI 大模型在执行复杂多轮任务时遭遇的历史数据读取瓶颈。 据论文介绍,现在 AI 系统在处理超长上下文时,负责「处理输入信息」和「生成文本回答」的两个计算模块,会出现数据通道资源错配的情况。 针对此问题,新的 DualPath 打破了常规的单线传输限制,允许历史数据先通过闲置通道进入「生成回答」模块,随后利用集群内部的高速网络,瞬间转发给「处理输入」模块。 官方评估数据显示,在处理真实复杂的 AI 任务时,该技术将离线处理吞吐量最高提升 1.87 倍,在线服务吞吐量平均提升 1.96 倍。 当前,大模型正快速向具备自主规划能力的「智能体(Agent)」方向演进,AI 需要频繁回顾动辄数万字的上下文,导致系统性能的制约因素已从「算力不足」转变为「数据传输太慢」。 而 DualPath 技术的验证,证明了通过优化底层数据流向,可以在不增加硬件采购成本的情况下大幅盘活闲置资源。 ( @APPSO) 2、首创音视频深度协同与统一拼接框架:SkyReels V4 开启「生成+修复+编辑」一体化视频创作 2 月 27 日,Skywork AI 正式发布多模态视频基础模型 SkyReels V4 。该模型以双流多模态扩散 Transformer(MMDiT)为核心架构,可实现 1080p 分辨率、32 FPS 帧率及 15 秒时长的音视频同步生成 ,是全球首个集多模态输入、联合音视频生成及统一生成/修复/编辑任务于一体的视频基础模型。 在权威评测机构 Artificial Analysis 的基准测试中,SkyReels V4 在「文本生成视频(带音频)」领域排名全球第二,表现显著优于 Google Veo 3.1、OpenAI Sora 2 及 Wan 2.6 等主流模型。 针对传统视频模型普遍存在的模态割裂与功能分散问题,SkyReels V4 通过三大核心技术创新实现了多场景覆盖: 目前,SkyReels V4 的一体化创作能力已在广告营销、影视制作及教育培训等多个场景落地应用。未来,Skywork AI 计划进一步扩展 60 秒以上的长视频生成能力,增强交互编辑功能,并向开发者开放模型 API 接口。 (@昆仑万维集团) 3、Deepgram 成为 IBM 首个语音技术合作伙伴,全面接入 watsonx 打造企业级实时语音智能体 2 月 24 日,IBM 与 Deepgram 宣布达成合作,**IBM 将把 Deepgram 的语音转文本和文本转语音技术整合至其 watsonx Orchestrate 生成式 AI 解决方案中。**通过此次合作,Deepgram 正式成为 IBM 的首个语音技术合作伙伴。 此次技术整合主要为满足企业客户对高性能转录和实时字幕的需求,帮助企业实现运营自动化。面对真实世界中复杂的音频环境,该系统展现出以下核心功能优势: 这些新引入的语音 AI 技术,将为医疗保健和金融等领域的自动化客户服务与支持、通话分析以及语音驱动的数据录入开辟新的应用场景。 Deepgram 首席执行官 Scott Stephenson 表示,语音正迅速成为人类与技术交互的默认接口,企业客户如今可以通过 watsonx Orchestrate Agent Builder,在经过十多年完善的实时架构上构建语音智能体和支持语音的工作流。IBM 相关业务副总裁 Nick Holda 也指出,引入全新的语音识别与转录能力将优化并加速企业组织的 AI 计划,实现运营的现代化。 ( @IBM Newsroom) 1、VUI Labs 完成数千万天使+轮融资,发力情感语音大模型与多模态 Agent VUI Labs(宇生月伴)宣布完成数千万元天使+轮融资,由同创伟业领投,老股东靖亚资本、小苗朗程持续加注。公司半年内累计获得近亿元投资,资金将用于核心模型迭代、产品和商业化落地、全球人才引进及 Voice Agent 平台建设 。VUI Labs 由上海交通大学特聘教授钱彦旻与连续创业者梅杰创办,专注于打造多模态情感对话语音大模型与语音智能体平台。 基于在端到端语音模型领域的深厚积累,VUI Labs 自研了多模态情感交互语音大模型 Luna 系列,其核心技术成果主要包含以下三点: 在产品应用方面,公司于 2026 年 1 月推出首个 C 端语音智能体产品 SaySo。与传统语音转文字工具不同,SaySo 具备多步规划、工具调用等能力,能精准理解上下文语境并优化输出内容。早期测试数据显示,该产品展现出极高的用户粘性:用户 78% 的文字产出已由其完成,横跨近 50 个主流应用;仅用 6 周时间,中位数用户的键盘依赖度即断崖式降至 20%。 投资方认为,下一代人机交互界面的核心技术在于语音,而语音交互的关键在于时延与情感。VUI Labs 在这两方面的基础技术优势,结合成熟的工程化商业落地经验,将有力推动其在多模态 Agent 这一未来核心应用场景中实现快速突破与规模化发展。 ( @Z Potentials) 2、中兴官宣 MWC 2026 推 TopFlow「直播神器」,还有 AI 宠物 iMoochi 中兴官方今日预热,将在 MWC 2026 世界移动通信大会(3 月 2 日开始)推出一款 TopFlow「直播神器」。 从宣传海报可以看到,TopFlow 带有屏幕和疑似录制按钮,屏幕中显示上传和下载速度,有望整合拍摄、网络、直播等功能。 中兴还将同时推出一款 AI 宠物 iMoochi。这款产品采用毛茸茸造型,配有萌趣大眼睛。 根据官方介绍,iMoochi 是一款以「陪伴」为核心的 AI 宠物,用柔软的触感、克制的表达与理解你之后的回应,陪在你身边。 (@IT 之家) 3、OpenAI 宣布获得超千亿美元融资 昨晚,OpenAI 终于宣布完成 1100 亿美元新一轮融资,投前估值高达 7300 亿美元。 具体来看该笔融资:软银投 300 亿美元、英伟达投 300 亿美元、亚马逊投 500 亿美元。 而拥有了该笔融资后的 OpenAI,估值更是直逼特斯拉。 而这笔钱将分别用于「与英伟达合作获取下一代推理芯片」「通过亚马逊 AWS 触达更多企业客户」和「支撑公司从研究型机构向全球产品公司转型」。 除了砸钱,亚马逊还与 OpenAI 签署了 战略合作协议: 与此同时,微软也紧急发声明「维稳」:与 OpenAI 的合作关系一切照旧。 另外,OpenAI 还晒出了一组恐怖数据:ChatGPT 周活跃用户突破 9 亿,付费企业用户超过 900 万,消费者订阅用户达到 5000 万+。 OpenAI 称今年 1 月和 2 月有望成为公司历史上新增订阅用户最多的两个月。 ( @APPSO) 1、Salesforce CEO 反驳「软件末日」:都不是第一次这样讲了 近期,客户关系管理软件服务提供商 Salesforce CEO Marc Benioff 在最新的财报电话会上,正面回应了「AI 智能体将导致 SaaS 模式消亡」的市场担忧。 针对近期资本市场担忧 AI 智能体将颠覆按座席收费模式的「SaaS 末日论(SaaSpocalypse)」,Benioff 在会上指出,行业并非首次面临此类危机,而企业级 SaaS 因集成 AI 智能体而变得更具护城河。 而据 TechCrunch 报道,这一观点的抛出,被业界视为对底层大模型厂商越界行为的直接反击。 本月早些时候,OpenAI 推出企业级智能体 Frontier 时展示了截然相反的路线图:OpenAI 意图掌控技术栈核心,而将提供核心业务数据的 SaaS 供应商降级为底层的系统记录引擎。而该路线分歧正是触发本轮 SaaS 概念股抛售潮的核心诱因。 近期,Anthropic 宣布 Claude Code 能自动梳理 COBOL 依赖、生成文档并识别风险,引发市场对 IBM 主机业务受冲击的担忧,IBM 股价在当地时间本周一录得近 26 年最大单日跌幅,市值蒸发约 310 亿美元。 ( @APPSO) 阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么 写在最后: 我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创,感兴趣的朋友请通过开发者社区或公众号留言联系,记得报暗号「共创」。 对于任何反馈(包括但不限于内容上、形式上)我们不胜感激、并有小惊喜回馈,例如你希望从日报中看到哪些内容;自己推荐的信源、项目、话题、活动等;或者列举几个你喜欢看、平时常看的内容渠道;内容排版或呈现形式上有哪些可以改进的地方等。 作者提示: 个人观点,仅供参考
01 有话题的技术


02 有亮点的产品



03 有态度的观点



在 macOS 上一直觉得 Core Tunnel 挺好用,但在 Windows 下始终没找到特别顺手的 SSH 隧道管理工具。
春节期间,闲着也是无聊,使用 golang + Wails v2 手搓了 SSH Tunnel 的 GUI 管理器: Loris Tunnel
同时加入断线自动重连、延迟测试( Ping )、快速迁移/创建 我感觉比较有用的功能
主界面:

把之前的 SSH command 直接引入批量创建

隧道列表,可以直接显示延迟情况

这也是我第一次写客户端 app 并开源到 Github 上,也不知会不会有权限不对的问题
比如 macos 上我就反复折腾了好几次权限的问题。 下载需要执行
sudo xattr -rd com.apple.quarantine /Applications/loris-tunnel.app
自我觉得一些比较方便的功能点:
初步先放 10 个永久的邀请码
V2EX-D3O1-IJFM-EFL3
V2EX-JECJ-8CIU-IYXW
V2EX-5BWB-4CK2-5IGN
V2EX-TFH3-ET50-L5GS
V2EX-XS0Z-GJC9-PKGK
V2EX-AALN-61L3-X5OT
V2EX-WYYD-BP9N-QKKI
V2EX-84E4-E9GV-PE3N
V2EX-ICD4-GJFE-F6AR
V2EX-XFRG-LM6B-X09M
github 地址: https://github.com/RangerWolf/loris-tunnel-app
方便的话来一个小星星支持一下也可以
下载地址: https://github.com/RangerWolf/loris-tunnel-app/releases
我估计这玩意最后也赚不到大钱,能把写这个 APP 花的 token 的钱赚回来就非常满足了
目前还没有接入任何支付功能,后续一步步来吧
感谢之前的命令行工具版本:https://github.com/alebeck/boring 参考这份代码,学了很多东西
最后,祝愿 2026 年大家一起发财,走向自己想要的人生!
配方改良有 AI 的成分(大家可以理性探讨),有喜欢 diy 的可以尝试一下。昨晚做成了(入模有点太丑了)
新版中药洗发皂(热制皂)制作指南(含迷迭香精油版)
核心目标: 解决干涩 + 真正锁住药效 + 融入迷迭香护发精华
1. 药材部分(与你原来的配方保持一致)
2. 皂基部分(彻底更新,不再买皂基,改用以下原料)
3. 工具准备
第一阶段:熬制浓缩中药汁(关键变化:要冷冻)
第二阶段:制作热制皂(核心操作)
安全防护: 戴好橡胶手套、口罩和护目镜。操作全程保持通风。
混合碱液:
混合油脂:
油碱混合:
热制(关键区别):
🌿 关键步骤:加入迷迭香精油(新增细化步骤)
入模与晾干:

我一开始做 VidBee ,起因很简单,女朋友刚开始做自媒体,每天都要下载素材。yt-dlp 虽然强无敌,但她是电脑小白,连软件都要我帮她装,更别说什么命令行了。
我们也试过一些现成工具,比如 ytDownloader 和 YoutubeDownloader。看起来像给新手准备,真用起来还是绕,失败提示也不清楚,用户体验并没有比命令行高多少。
如果你想先试试看,最快上手就三步。先到 https://vidbee.org/download 下载对应系统版本,安装后把视频链接粘进去,再点下载就行。
如果这个工具对你有帮助,欢迎到 https://github.com/nexmoe/VidBee 点个 Star ⭐ 支持一下。

后来我把她每天会遇到的问题记了下来,核心就三件事
VidBee 现在的设计基本都围绕这三个点。先把流程打通,再慢慢加能力。
第一块是下载流程。输入链接后直接解析,不需要记参数。常用格式和清晰度会放在前面,失败时把原因讲清楚,用户知道下一步该怎么做。


第二块是 RSS 自动下载。你可以把常看的频道、播放列表或者栏目源加进订阅,VidBee 会在后台定时检查更新,有新内容就自动进队列下载。这样不用每天盯着链接刷新,也不会漏掉刚发布的素材。对高频做内容的人来说,这一块省下来的时间非常直接。

第三块是管理体验。VidBee 会按频道、作者或任务规则自动分文件夹,下载完成后素材结构更清楚,回看历史、二次整理、补下素材都会更快,不用再到文件夹里盲找。配合 RSS 自动下载,这套流程更像一条持续运转的素材备份线,账号一更新,本地就会同步留档。后续我们也会在这块继续打磨交互细节,把整理、检索和批量管理做得更顺手。

我不想做一个看起来功能很多但上手很累的下载器。我更在意新手第一次打开就能用,也在意高频用户越用越省时间。
做内容的人都懂,很多时候不是没有想法,而是流程太磨人。VidBee 对我来说,就是把这些摩擦尽量拿掉,把时间还给创作。
大家好,最近因为国产化办公的需求,一直在折腾 UOS 20 (ARM64) 环境下的自动化。发现官方的 KeymouseGo 在麒麟芯片和 X11 环境下直接运行会有一些兼容性问题,于是花时间做了一次深度适配和重新编译。
现在的版本在 HUAWEI Kirin 9000C 上跑得非常稳,解决了 AArch64 架构下的一些依赖报错。
🛠 适配技术细节:
📸 运行情况:
环境截图预览:



💬 写在后面: 考虑到不少同在国产化平台奋斗的开发者可能也有类似需求,我把编译好的分发包和修改后的代码都发到了 GitHub 上。如果你也遇到了 ARM 环境下键鼠录制失效的问题,欢迎下载测试并反馈 Bug 。
希望这个版本能帮到有需要的朋友,大家有什么适配上的问题也可以在帖子里交流!

远看大猫肥 😸😸😸
近看肥猫大 😺😺😺
肥猫确实大 😼😼😼
真是大肥猫 😹😹😹

在数字化时代,企业官网不仅是品牌展示的窗口,更是与用户互动的重要渠道。然而,传统的人工客服往往难以覆盖所有访问者,尤其是在非工作时间。这时,智能客服网页版应运而生,成为企业提升服务效率和用户体验的利器。 智能客服网页版是一种轻量化的智能问答解决方案,专为企业官网设计。它通过一行代码即可嵌入网站,无需技术团队介入,5分钟内就能上线专属的智能客服机器人。访答智能客服网页版基于深度优化的中文RAG(检索增强生成)技术,能够精准理解用户问题并提供基于官网内容的答案。 传统客服系统通常需要复杂的开发和配置,而智能客服网页版只需将生成的代码嵌入官网HTML即可。企业无需投入额外的人力或资源,就能实现“7×24小时不打烊”的客服能力。 访答智能客服网页版通过深度学习官网内容构建专属知识库,能够精准匹配用户问题并提供可靠答案。此外,它还支持多模态内容识别,包括图片和图文混排资源,使回答更加直观和全面。 智能客服在回答问题时,会自动提供官网参考链接,用户可一键跳转至原文页面。这不仅增强了回答的可信度,还引导用户深度浏览官网,提升网站留存率。 当官网内容更新时,企业只需一键更新知识库,无需修改前端代码。这种便捷的维护方式大大降低了运营成本,确保客服机器人始终与官网内容同步。 智能客服网页版可快速嵌入企业官网,根据官网内容智能回答用户问题。无论是产品咨询、服务介绍还是常见问题解答,它都能提供及时且准确的支持,从而节省人力客服成本,提升品牌形象与访问转化率。 对于教育机构和政府网站而言,智能客服网页版可以帮助用户快速找到所需信息,减少重复性问题的处理时间,提高服务效率。 部署访答智能客服网页版非常简单,只需以下几步: 随着人工智能技术的不断发展,智能客服网页版将在准确性和智能化方面进一步提升。未来,它可能融合更多先进技术,如自然语言处理和情感分析,为用户提供更加人性化和个性化的服务。 智能客服网页版是企业官网升级服务能力的重要工具。通过访答智能客服网页版,企业可以以零开发成本快速部署专属客服机器人,实现精准应答和高效服务。无论是提升用户体验,还是降低运营成本,智能客服网页版都能为企业带来显著的价值。智能客服网页版:官网问答新体验
什么是智能客服网页版?
为什么选择智能客服网页版?
1. 零开发成本,快速部署
2. 精准应答,提升用户体验
3. 溯源参考导航,增强可信度
4. 一键更新,维护便捷
智能客服网页版的应用场景
企业官网
教育机构与政府网站
如何部署智能客服网页版?
智能客服网页版的未来展望
结语

元宵佳节将至
🎉 限免时间:2026 年 2 月 28 日 - 3 月 3 日 23:59
0 元领取终身会员,解锁全部高级功能。
本次更新带来了四大核心功能,希望能真正帮到你:
不仅仅是数字,我们让压力“可视化”。首页实时展示压力状态,新增压力源头精准定位,帮你分析是工作、睡眠还是其他因素导致了压力波动。试试搜索“压力自测”,让腕能帮你找到答案。

▲ 首页实时压力状态


身体就像电池,需要充放电管理。新版本引入“身体电量”概念,直观展示能量储备。针对跑步爱好者,我们提供科学的训练指导,拒绝无效堆跑量,让每一次流汗都更有价值。



睡眠是恢复能量的关键。我们强化了睡眠分析算法,特别关注深度睡眠时长与质量,帮你拆解睡眠结构,找到身体修复的秘密。

通过长期的“观照”,你会发现身体运行的规律。我们将每一个瞬间记录下来,生成可视化的健康趋势图,让你对自己的身体了如指掌。



打开 App Store 搜索关键词 “压力自测”
(优先搜索此词,可以帮助我们提升关键词权重,感谢支持!)
或 “腕能”

现在发帖时编辑的内容未发布的话,大概全部输入和选择的内容都会在草稿中保存,并在恢复时提供二次编辑。若草稿中的匿名发布扩展是开启状态的话,草稿恢复后将不会恢复金币池与竞猜的内容,因为匿名发布不能选择竞猜与金币池扩展。
当前版本的一些其他更新:
昨天花了一天时间写了个工具,今天迫不及待分享出来。
起因很简单:我想在手机上用 Claude Code ,但不想每次都开终端。
之前试过 Happy ,体验不错。但问题是——我得专门打开一个 App 。我的日常工作流在微信/飞书/钉钉里,消息在那儿,工作群在那儿,整天泡在那儿。
我就想:能不能直接在微信/飞书/钉钉里跟 Claude Code 聊天?
于是就有了 cc-connect。极速帮你把工作机器的 claude code 接入 im 软件。实现随时随地大小班。
名字灵感来自 cc-switch ,一个很棒的项目,向作者致敬。
github 地址:https://github.com/chenhg5/cc-connect

一句话:把你的本地 AI 编程助手接到通讯平台上。
支持的 AI 工具:
支持的平台:
配好之后,你直接在微信/飞书/钉钉/Slack 里发消息,Claude Code 就会在你电脑上干活,然后把结果发回来。
可能有人会问:为什么不接 OpenClaw ?
我两个都用过,最后选择了 Claude Code ,原因有三:
1. 写代码能力更强
Claude Code 背后是 Anthropic 的最新模型,代码质量和理解能力都是目前顶尖的。同样的任务,Claude Code 经常能一次搞定,其他工具可能要来回几轮。
2. Agent 能力更强
Claude Code 的自主性更好。你给它一个目标,它能自己拆解步骤、自己调用工具、自己处理异常。不需要你手把手教它每一步。
3. 对生态支持更好
Claude Code 的 skill 扩展机制比较成熟,社区资源也多。虽然 OpenClaw 也有 skill 系统,但 Claude Code 的工具链更完善,调度也更强。
当然,cc-connect 的架构是插件化的,后续也会支持 OpenClaw 、Cursor Agent 等。但如果你现在就要用,我建议先从 Claude Code 开始。
中午吃饭刷手机,突然想到项目里有个 bug 可以修。
以前:回公司、开电脑、打开终端、启动 Claude Code...
现在:直接在飞书里给机器人发消息:"帮我修一下 xxx 的 bug"
吃完饭回来,代码已经改好了。
周六在外面,同事在钉钉群里艾特我:"线上出了个问题,能帮忙看下吗?"
以前:"我在外面,晚点处理"
现在:直接在钉钉群里让 Claude Code 查日志、定位问题、修代码。
同事以为我带着电脑加班,其实我就掏了个手机。
我同时维护几个项目。用 cc-connect 可以配多个:
一个进程同时管理,互不干扰。
大多数平台都支持 WebSocket 或长轮询,你不需要有公网 IP ,不需要配置内网穿透。
只有 LINE 和企业微信需要 webhook ,这种情况下用 ngrok 或 cloudflared 暴露端口就行。
| 模式 | 行为 | 适用场景 |
|---|---|---|
default |
每个工具调用都要你批准 | 日常开发,保持控制 |
acceptEdits |
文件编辑自动批准,其他工具还是问你 | 信任编辑,控制其他 |
plan |
只做规划,不执行,等你批准 | 复杂任务,先看方案 |
yolo |
所有操作自动批准 | 可信环境,放手让它干 |
[projects.agent.options]
mode = "default"
# 也可以预先批准特定工具:
# allowed_tools = ["Read", "Grep", "Glob"]
聊天中随时可以切换模式:
/mode # 查看当前模式和所有可用模式
/mode yolo # 切换到 YOLO 模式
/mode default # 切回默认模式
每个人有独立的会话,上下文完整保留。
还可以在聊天里用斜杠命令管理会话:
| 命令 | 说明 |
|---|---|
/new [name] |
创建新会话 |
/list |
列出所有会话 |
/switch <id> |
切换会话 |
/current |
显示当前会话信息 |
/history [n] |
查看历史消息 |
/allow |
预先批准某个工具 |
/mode [name] |
查看或切换权限模式 |
/quiet |
切换思考/工具进度消息显示 |
/stop |
停止当前执行 |
用 Go 接口实现的,想加新平台或新 AI 工具都很简单:
// 加新平台
core.RegisterPlatform("myplatform", New)
// 加新 Agent
core.RegisterAgent("myagent", New)
把下面这段话发给 Claude Code 或其他 AI 编程助手,它会帮你完成整个安装和配置过程:
请参考 https://raw.githubusercontent.com/chenhg5/cc-connect/refs/heads/main/INSTALL.md 帮我安装和配置 cc-connect

http(s)://<你的域名>:<端口>/wecom/callbackim.message.receive_v1/newbotmessage.channels、message.im更多平台的配置说明看 README 。
┌──────────────┐ ┌────────────┐ ┌──────────────┐
│ 飞书/钉钉 │◄───►│ Engine │◄───►│ Claude Code │
│ Slack/... │ │ (Router) │ │ Cursor/... │
└──────────────┘ └────────────┘ └──────────────┘
Platform Core Agent
三层结构,全部解耦,完全插件化。

如果你也在用 Claude Code ,又恰好日常泡在飞书/钉钉/Slack 里,强烈建议试试。
配一次,以后手机随时派活。
老板以为你卷到 24 小时在线,其实你只是在正确的工具上花了点时间。

来分享一个最近在 Claude Code 帮助下写的 codex-collab skill (项目链接),基于 Codex 官方的 Codex App Server 协议让 CC 能够丝滑地实现对 Codex 的驱动和调用,效果如图。

平时写代码一直在主用 CC ,偶尔也会用 Codex 来进行一些辅助的代码审查与反馈(如在 Codex 中使用 /review 命令),往往能发现一些 CC 没有考虑到或者忽略的地方。
为了能让 Claude 更自然地和 Codex 协作,也尝试过官方的 MCP 和一些开源的 skill ,但是效果总是不尽理想:MCP 会阻塞 Claude 的执行流程,而大多数 skill 都是通过命令行的方式来进行调用的,支持的交互方式受限,而且总觉得不够优雅和鲁棒,遂决定自己再手搓又双叒一个与 Codex 协作的 skill 出来。
最开始参考部分开源 skill 采用了 tmux 来实现和 Codex TUI 的交互,但是这种方式还是太不稳定了,需要手动键入指令、轮询检测 tmux 界面中的文本来判断是否执行完成。
后来看到了 Codex App Server 协议,支持使用 JSON-RPC 2.0 消息和 Codex 进行通信,并且提供了非常标准规范的 API ,于是就基于此协议来实现了和 Codex 的交互脚本,并且根据自己的使用经验,逐步微调了 SKILL.md 中的提示词。
安装 skill 之后,在 CC 里提及 Codex ,或者当 Claude 觉得需要参考第三方意见时,就会触发该 skill 调用 Codex 。
欢迎大家使用,因为目前只经过自己这些天的使用和测试,有什么意见或者遇到什么问题也请不吝赐教