大家好，我是不如摸鱼去，好久不见。

进入 2026 以来，大家可以感受到 wot-ui 的迭代速度明显放缓了，我们最近也接到了无数催更的消息。很多人以为我们是在偷懒或者放弃更新了，其实不是，我们是在偷偷写代码然后准备惊艳所有人！（其实是苦苦码了好几个月，来点点赞吧）

接下来看看我们带来了哪些东西吧！

V2

如今已经是 AI 编程时代了，Wot UI 的 slogan 也调整成了「轻量、美观、AI 友好」。我们的目标很直接，就是为大家带来更高效、更易用，也更适合和 AI 协作的 uni-app 开发实践。

主要变化

对比 v1，v2 这一版我们带来了不少更新：

1. 全新的设计系统。 在 v2 版本，我们基于基础变量、语义变量和组件变量三层 design token 搭建全新的设计系统，使修改组件样式和自定义主题变得随心所欲，同时升级了 UI 视觉体验。
2. 简化 form 及相关组件 我们简化了 form 相关组件的用法，提供基于 zod 的校验引擎以及支持自定义校验引擎，使用 form-item 替换 cell 作为表单项，优化各表单组件与非表单组件结合 form-item 使用的写法，不再区分「表单组件」和「非表单组件」。
3. 优化文档体验 重新整理文档结构，统一组件文档结构，将 @wot-ui/vitepress-theme 提取后发布为 vitepress 主题，统一多个 wot-ui 多个库的文档 UI，同时在每个组件文档中增加 css 变量的展示。
4. 优化 AI 支持

• 提供 cli 工具 @wot-ui/cli，其内部提供 cli 与 mcp，以优化 wot-ui 组件库的 AI 编程体验。
• 提供多个 skills 与 LLMs.txt。

5. 提供 Unocss 预设 提供了 Unocss 预设 @wot-ui/unocss-preset，内置主题变量、语义色、间距、圆角、字重、透明度、描边和排版相关原子类规则，把 wot-ui 的设计 token 和主题变量映射成可直接使用的原子类。

CLI

很多同学在用 AI 写 wot-ui 页面时，问题其实不在于模型不会写，而在于它总爱“凭感觉”写。比如 props 名字记错了、事件猜错了、slot 用法写得像对的，结果一跑就炸。

所以在 v2 里，我们专门提供了 @wot-ui/cli。它不是一个单纯的脚手架工具，而是把 wot-ui v2 的组件知识整理成一套可查询、可校验、可给 AI 调用的能力。

你可以把它理解成一个本地离线知识库，既能给开发者自己查，也能给 AI 客户端通过 MCP 调用。常见能力包括：

• 查询组件的 props、events、slots 和 CSS 变量
• 查看组件 demo，减少 AI 瞎猜用法
• 扫描本地项目，检查不合理或错误的组件写法
• 通过 MCP 接入 AI 工具链，让 Agent 先查再写

比如以前你让 AI 写一个表单页，它可能先吐出一份“看起来很像 wot-ui”的代码。现在更合理的流程是，先查组件约束，再生成代码，最后再跑一遍检查。这样出来的结果会稳很多。

简单来说，@wot-ui/cli 想解决的不是“怎么让 AI 更会猜”，而是“怎么让 AI 少猜一点”。这也是我们这次把「AI 友好」放进 v2 里的一个重点。

Starter

如果说组件库解决的是“页面怎么写”，那 Starter 解决的就是“项目怎么开”。所以这次我们也没有把它当成一个单纯的 demo 仓库来维护，而是持续把它往一套更适合真实开发、也更适合 AI 协作的 uni-app 起手方案去打磨。

1.5 之后，Starter 先补上了 skills，开始把项目里常用的开发约定、页面结构和组件使用方式整理出来，让 AI 在这个模板里写代码时不再完全靠猜。到了 2.0，Starter 进一步完成了对 wot-ui v2 的适配，示例、主题能力、反馈组件文档以及整体开发链路也一起升级。

你可以把现在的 Starter 理解成：它不只是“集成了 wot-ui 的模板”，而是一个默认就站在 v2 体系上的起点。新项目拉下来之后，从主题定制、页面组织到后续和 AI 配合开发，整个体验都会比 1.x 时代更顺手一些。

CSS 插件

再往下一层看，组件和模板之外，样式这一层我们也往前推了一步，提供了 @wot-ui/unocss-preset。它本质上是一个基于 UnoCSS 的预设，用来把 wot-ui v2 的设计 token 直接映射成可用的原子类。

这件事的价值在于，你在写页面时不需要一边翻设计变量、一边手写一堆样式映射了。像颜色、间距、圆角、字重、排版这些能力，现在都可以直接通过统一的 wot- 前缀类名来组织，主题切换时也能更自然地跟着整套 token 体系走。对于喜欢原子化 CSS 的同学来说，这一层会让 wot-ui v2 真正从“组件好用”变成“整套样式开发都更顺手”。

VSCode 插件

如果说前面这些更多是在补工具链和工程体验，那再落回到日常写代码，我们也补上了 VS Code 插件这一层，也就是 VS Code 插件 wot-ui-intellisense。

这个插件主要解决的是写页面时那些很碎、但又很烦的事情。比如组件名记不全、属性名老要回头翻文档、事件到底叫什么总要试一下。现在在 .vue 和 .html 文件里，输入 <wd-、空格、:、@ 这些常见场景时，都可以直接拿到补全提示。

除了补全之外，它还支持组件、属性、事件的悬停文档展示，以及一部分属性值校验和错误诊断。也就是说，很多以前要切出去查文档、或者运行后才发现的问题，现在在编辑器里就能先拦一层。

如果说 CLI 更像是给 AI 和工程化链路准备的，那 VS Code 插件就是给开发者日常写代码准备的。一个负责让模型少猜，一个负责让人少翻文档，配合起来，整个 wot-ui v2 的开发体验就会完整很多。

最后

回过头来看，这次 wot-ui v2 对我们来说并不只是一次常规升级。

它一边在补齐设计系统、表单体系、文档体验这些基础能力，一边也在认真回应这两年越来越明显的变化：大家写代码的方式，确实已经和以前不太一样了。

所以你会看到，这一版里不只有组件本身，也有 Starter、CLI、UnoCSS 预设、VS Code 插件这些围绕开发体验的配套。我们想做的，不只是一个“能用”的组件库，而是一套更顺手、更现代，也更适合和 AI 一起协作的 uni-app 开发方案。

v2 还有很多东西会在后面陆续展开，这篇文章先带大家看一个整体。如果你也在关注 wot-ui v2，或者也在想组件库怎么更好地拥抱 AI 编程，欢迎继续关注我们后面的更新。

参考资料

• Wot UI 2.x 文档：wot-ui.cn/
• Wot UI 仓库：github.com/wot-ui/wot-…
• @wot-ui/vitepress-theme：github.com/wot-ui/wot-…
• @wot-ui/cli / Open Wot：github.com/wot-ui/open…
• Wot Starter：github.com/wot-ui/wot-…
• @wot-ui/unocss-preset：github.com/wot-ui/unoc…
• wot-ui-intellisense 仓库：github.com/wot-ui/wot-…
• wot-ui-intellisense 下载地址：marketplace.visualstudio.com/items?itemN…

大家好，我是一名独立开发者。最近利用业余时间，我从零到一开发并上线了一款目标打卡/习惯养成类的小程序。

今天这篇文章，不仅是想向大家推荐一下我的心血之作，更想从创作灵感、核心技术实现、代码细节以及无数次踩坑的角度，和大家深度复盘一下整个项目的历程。如果你也想尝试用 Uni-app + Strapi 搞全栈独立开发，这篇“避坑指南 + 技术解析”绝对不容错过！

---

💡 创作灵感与产品心得：为什么还要做一个打卡应用？

市面上的打卡应用多如牛毛，为什么我还要自己造轮子？ 其实原因很简单：我觉得现有的工具太“冷冰冰”了，缺乏足够的情绪反馈。

打卡/坚持习惯本身就是一件反人性的事情，如果工具只是一个无情的“待办列表”，那用户很容易就会放弃。因此，在产品设计之初，我定下了几个核心基调：

1. 克制与聚焦：我限制了每天最多只能创建 12 个任务，到达 10 个时会温馨警告。目标泛滥等于没有目标。
2. 正向反馈拉满：任务完成不能只是打个勾，必须要有“爽感”。我加入了物理震动、纸屑爆裂动画（撒花）、以及 3D 翻转的徽章解锁系统。
3. 互助与抄作业：很多时候我们不知道该养成什么习惯，所以我做了一个“社区广场”（瀑布流布局），看到别人优秀的习惯，可以直接“一键 Copy”到自己的计划中。

---

🛠 技术选型：单兵作战的效率最优解

作为独立开发者，开发效率是第一生产力。我选择了这套组合拳：

• 前端：Uni-app (Vue 3) + Tailwind CSS
  • Vue 3 的 Composition API 逻辑复用非常爽。
  • 结合原子化 CSS（如 Tailwind/UnoCSS），极大提升了切图速度，摆脱了起 class 名字的内耗。
• 后端：Strapi v5 (Headless CMS)
  • 绝对的效率神器！不用手写繁琐的 CRUD 接口，建好模型直接生成 RESTful API。
  • 自带强大的 Admin 后台，数据管理极度舒适，让我能把 80% 的精力全放在前端交互和产品体验上。

---

💻 核心技术点与代码实现

1. 极致的微交互：让打卡“爽”起来

为了让用户点下“完成”的那一刻有真实的成就感，我结合了 CSS 动画和原生的触觉反馈：

// 核心打卡逻辑片段
const handleCheckIn = async (task) => {
  // 1. 触发 Haptic 震动反馈 (重震动带来物理按压感)
  uni.vibrateShort({ type: 'heavy' });
  
  // 2. 触发微动效：按钮自身的弹跳 + 全局撒花特效
  task.isBouncing = true; 
  uni.$emit('trigger-particle-confetti'); // 呼叫全局纸屑动画组件
  
  try {
    await api.completeTask(task.id);
    // 3. 检查是否触发徽章解锁
    checkBadgeUnlock(task);
  } catch (e) {
    // 错误处理...
  }
}

在徽章解锁时，我还写了一个 3D 翻牌效果（利用 CSS transform: rotateY 配合 animate-flip-y），让徽章展示更有仪式感。

2. Strapi 关系模型 Hack：如何优雅地记录“徽章解锁时间”？

在后端的开发中，我遇到了一个经典问题：多对多关联表的额外字段怎么存？ User 和 Badge 是多对多关系，但在 Strapi 原生模型中，中间表无法轻易添加像 unlockedAt 这样的字段。

我的解法： 直接在 User Schema 中扩展一个轻量级的 JSON 字段 badge_unlock_records。

// apps/api/src/extensions/users-permissions/strapi-server.ts
// 扩展 Strapi 默认的 User Schema
export default (plugin) => {
  plugin.contentTypes.user.attributes = {
    ...plugin.contentTypes.user.attributes,
    // 原生多对多关联
    badges: {
      type: 'relation',
      relation: 'manyToMany',
      target: 'api::badge.badge',
    },
    // 💡 Hack: 用 JSON 字段记录具体的解锁元数据
    badge_unlock_records: {
      type: 'json',
      // 数据结构示例: { "badge_id_1": "2023-10-01T12:00:00Z" }
    }
  };
  return plugin;
};

这样既保留了原生关系（方便在 Admin 面板查看），又解决了业务上的元数据存储需求。

3. 社区广场的“真”瀑布流与分页

社区页面的卡片高度是不固定的，传统的 Grid 布局会留下大片空白。我通过维护左右两列的数据数组，实现了原生的瀑布流效果：

// 瀑布流计算核心逻辑
const leftColumn = ref([]);
const rightColumn = ref([]);
let leftHeight = 0;
let rightHeight = 0;

const appendToMasonry = (items) => {
  items.forEach(item => {
    // 估算卡片高度 (基于内容长度)
    const estimatedHeight = calculateHeight(item);
    
    // 哪边矮往哪边塞
    if (leftHeight <= rightHeight) {
      leftColumn.value.push(item);
      leftHeight += estimatedHeight;
    } else {
      rightColumn.value.push(item);
      rightHeight += estimatedHeight;
    }
  });
};

配合 onReachBottom 触底事件，以及自己封装的 wd-loadmore 状态组件，整个信息流刷起来非常丝滑。

---

🚧 吐血踩坑录：那些让我熬夜的 Bug

全栈开发最怕的就是遇到莫名其妙的兼容性和环境问题。以下这几个坑，价值好几百根头发：

坑一：iOS 13 下 Swiper 圆角失效问题

症状：在旧版 iOS 中，给 <swiper> 设了 border-radius 和 overflow: hidden，但里面的图片滑动时依然会无视圆角溢出。 解法：这是 transform 堆叠上下文导致的渲染 Bug。不仅要给 swiper 和 image 都加上圆角类名，还必须强制加上 transform: translateY(0);！

<!-- 💡 注意 style 中的 transform 是精髓 -->
<swiper class="rounded-[5px]" style="transform: translateY(0);">
  <swiper-item>
    <image class="rounded-[5px]" src="..." />
  </swiper-item>
</swiper>

坑二：小程序下渐变文字（bg-clip-text）直接消失

症状：想用 Tailwind 的 bg-clip-text text-transparent 做炫酷的渐变文字，结果在微信小程序/iOS上文字直接隐身了。 解法：小程序对 <text> 标签的背景裁剪支持极差。如果要用，必须把 <text> 换成 <view> 标签来写文字，或者老老实实退回到纯色文本。

坑三：Strapi v5 生产环境部署大坑

1. 插件报错：初始化 v5 时，报 Middleware plugin::email.rateLimit not found。解法：手动执行 pnpm add @strapi/email 安装缺失依赖。
2. RTK Query 压缩报错：打包上线后 Admin 面板报 Cannot read properties of undefined (reading 'merge')。原因是 Vite 压缩把 RTK Query 的方法名压没了。 解法：在 src/admin/vite.config.ts 中关闭 minify，并清理缓存！

// src/admin/vite.config.ts
export default {
  build: {
    minify: false, // 💡 必须设为 false
  },
};

(执行 npx rimraf .strapi build 清除缓存后再 build)

---

结语

从一行代码都没有，到完整的前后端链路打通；从构思微交互，到处理数据备份（云端同步 + 剪贴板文本导出）；这个过程虽然辛苦，但当看到产品真正跑起来，有人开始用它记录生活时，一切都值了。

目前小程序已经上线，欢迎大家在微信搜索 简行一周 体验！

如果你对文章中的技术点感兴趣，或者在用 Uni-app / Strapi 的时候也遇到了头疼的问题，欢迎在评论区留言交流，我一定知无不言！

最后，如果你觉得这篇文章对你有启发，求个点赞 + 收藏，这对我这个独立开发者是莫大的鼓励！🚀

背景

大家好，我是 uni-app 的核心开发 前端笨笨狗。本篇是 uni-app 源码分析的第三篇文章，欢迎关注！

前两天有开发者在群里面问我 uni-app 中如何配置 styleIsolation，我告诉了他正确的配置方案，也计划写篇文章揭秘 uni-app 是如何通过运行时将开发者的配置转化为原生微信小程序的配置。

指南

选项式

在 uni-app 中，开发者可以通过在页面组件中添加 options 配置项来设置 styleIsolation，示例如下：

<script>
export default {
  name: 'MyComp',
  options: {
    styleIsolation: 'isolated'
  },  
}
</script>

<script>
import { defineComponent } from "vue";

export default defineComponent({
  name: "MyComp",
  options: {
    styleIsolation: "isolated",
  },
});
</script>

组合式

在使用组合式 API 的页面组件中，开发者同样可以通过 defineOptions 来设置 styleIsolation，示例如下：

<script setup>
defineOptions({
  name: 'MyComp',
  options: {
    styleIsolation: 'isolated'
  }
})
</script>

原理

createComponent 这个函数大家如果看过 vue 文件的 js 编译产物就一定不会陌生，比如

<script setup>
defineOptions({
  options: {
    styleIsolation: "shared",
  },
});
</script>

会被编译为

const _sfc_main = {
  __name: "comp",
  options: {
    styleIsolation: "shared"
  }
  setup(__props) {
    return (_ctx, _cache) => {
      return {};
    };
  }
};
wx.createComponent(_sfc_main);

也就是 script 中写的代码会被编译成一个对象，这个对象就是 vue 组件的配置项，而微信小程序又不认识 vue 组件的配置项，那么怎么把 vue 组件的配置项转化为微信小程序的配置项呢？这就要靠 uni-app 的运行时了，在 common/vendor.js 中，createComponent 函数会调用 parseComponent 函数来解析 vue 组件的配置项，parseComponent 的返回值就是微信小程序组件的配置项，也就是 Component 构造器 的参数，可以用来构造小程序原生组件。

function initCreateComponent() {
  return function createComponent(vueComponentOptions) {
    return Component(parseComponent(vueComponentOptions));
  };
}

const createComponent = initCreateComponent();
wx.createComponent = createComponent;

当 parseComponent 解析到页面组件时，会检查组件的 options 配置项，如果发现 styleIsolation，就会将其转化为微信小程序的配置项。

function parseComponent(vueOptions) {
  vueOptions = vueOptions.default || vueOptions;
  const options = {
    multipleSlots: true,
    // styleIsolation: 'apply-shared',
    addGlobalClass: true,
    pureDataPattern: /^uP$/
  };
  // 将开发者在 options 中设置的配置项转化为微信小程序的配置项
  if (vueOptions.options) {
    Object.assign(options, vueOptions.options);
  }
  const mpComponentOptions = {
    options,
    // 省略其他配置项
  };
  return mpComponentOptions;
}

这样一来，开发者在页面组件中设置的 styleIsolation 就会被正确地转化为微信小程序的配置项，从而自由控制样式隔离。

距离马斯克的「超级应用梦」落地，只剩最后三天。4 月 17 日，XChat 预计正式登陆苹果 App Store，全球同步开放下载。

这绝对不是一次普通的 App 上架。在马斯克那张疯狂且庞大的商业战略棋盘上，XChat 是他豪掷 440 亿美元买下 Twitter、将其暴力更名为 X 之后，又一枚核心、也最不容有失的落子。

他对这一天的期待，可以追溯到 2022 年。

收购 Twitter 之后，马斯克几乎在每个公开场合都会提到微信。他说：「在中国，你基本上是生活在微信里的，因为它对日常生活如此有用。如果我们能在 X 上实现这一点，哪怕只是接近，那都将是巨大的成功。」

马斯克痴迷的不是微信的聊天界面，是它作为数字生活操作系统的地位，支付、通讯、打车、外卖、水电费，全在一个 App 里。如果说收购 Twitter 是拿到了超级应用这场赌局的入场券，那么 XChat，就是他在牌桌上打出的第一张明牌。

顶着马斯克版微信的噱头，XChat 却活成了 Telegram 的模样？

从功能上看，XChat 主打的是隐私优先的独立聊天应用。

注册不需要手机号，直接用 X 账号登录，消息支持阅后即焚、撤回和编辑，群聊最多可容纳 481 人，文件传输上限高达 4GB，跨设备音视频通话全部内置，下载需要 iOS 26.0 或以上版本。

应用层面禁止截图和录屏，试图从源头堵住内容泄露的漏洞，这可能是一些科技圈老板最喜欢的功能，Grok AI 被直接嵌入聊天界面，可以在对话里随时调用，用于总结内容、实时翻译或规划行程。

XChat 的整体定位走的是干净、私密、少打扰的路线，界面剥离了 X 主应用里的信息流、广告和热搜，专门为私密对话留出空间。首发支持 46 种语言，包括简体中文和繁体中文。

带着马斯克极其鲜明的个人烙印，XChat 不仅在定位上大刀阔斧，其项目推进速度更是快得惊人，甚至透出几分激进与狂热。

去年 6 月，马斯克才在 X 上公开预告；到了 12 月，X 员工 Nikita Bier 就已经开始公开为其站台，惊叹团队「在短短三个月内完成加密私信迁移」，并顺脚踩了一下同行：「Facebook 花了三年时间才做到这一点。」

今年 3 月，iOS 版 TestFlight 测试名额开放，先是 1000 人，很快扩到 5000 人，名额在公告发出后短短两小时内被抢光但伴随高关注度而来的，是极其两极分化的口碑。

3 月就拿到 TestFlight 资格的用户 @Nicole_yang88 写道：「整体流畅度非常高，几乎没有卡顿感。界面走的是极简路线，层级清晰、配色克制，观感上确实有点接近 iMessage 的那种干净风格。」她还特别提到，与 X 主应用一键授权登录、账号数据无缝衔接，「完全没有切换应用的割裂感」。

但也有人完全不买账。

测试用户 @ohxiyu 发文：「打开一看，跟 X 私信像素级一样，那为什么要独立出来？私信、请求、骚扰全混在一起，跟现在的 DM 没区别。想找某个人聊天？没有联系人列表，只能翻聊天记录搜。」

更让人摸不着头脑的是私密模式的设计，对方开了阅后即焚，你这边完全没有提示，内容过一会儿就消失了。他说：「Telegram 好歹还弹个通知告诉你。连个菜单都没有。感觉就是把 DM 页面套了个壳扔出来了。」

甚至 XChat 还没正式开放下载，麻烦已经来了。

4 月 11 日预约开放当天，就有用户发出警告：App Store 里同期出现了一款俄语版 XChat，图标和名字与真品高度相似，下载后会要求用户提供信用卡信息和 ID 证明年龄。

博主 @Imlaomao 亲身中招：「不小心输入信用卡信息后，觉得不对，立刻把信用卡都注销了。」他虽然表示没有直接证据证明该 App 一定存在问题，但建议大家「安全第一，小心为好」。

一款把安全隐私刻在脑门上的应用，在发布首日就得靠用户自己去甄别李逵和李鬼。这个充满戏剧性的开局，很难说不是对 XChat 未来命运的一个隐喻。

所谓「比特币级加密」，只是文字游戏？

在 XChat 的所有宣传话术里，「比特币式加密（Bitcoin-style encryption）」无疑是最抓眼球的字眼。深谙流量密码的马斯克，用这个偏极客词汇，成功让无数人脑补出了一幅赛博朋克式的画面：聊天记录上链、去中心化存储。

理想很丰满，现实很骨感。

根据英伟达安全开发人员 Matthew Garrett 对 XChat 早期版本的技术分析，XChat 的消息加密层采用了 libsodium 的 box 加密方案。这套方案本身经过广泛审计，算得上扎实。但有一点马斯克没有说清楚：libsodium 的核心是 C 语言写的，X 调用的正是 C 语言版本，并非他对外宣称的「全新 Rust 架构」。

密钥管理方面，XChat 采用了开源协议 Juicebox——这套协议有独立白皮书，并非 X 自研。它的设计思路是：将你的私钥加密后分片，存储在 X 公司控制的多台服务器上。换新设备时，你输入一个 4 位数 PIN 码，系统从服务器检索分片、重组密钥，聊天记录全部恢复。

问题在于，X 目前使用的三个后端域名均在 x.com 之下，推测均由 Twitter 直接控制。Juicebox 协议本身支持引入独立第三方后端以分散信任，但 Garrett 在分析时未发现 X 有这方面的实质部署。

更致命的一点在于，XChat 的协议缺乏「前向保密性（Forward Secrecy）」。这意味着，如果某一天你的静态密钥被攻破，无论是设备被盗、密钥被收缴，还是服务器端组装解密，你过去所有的聊天记录都会在瞬间全部可读。

Signal 的「Double Ratchet」算法可以确保即使一次通讯密钥泄露，历史记录依然安全。XChat 没有这个机制。

此外，通过查询苹果 App Store 官方披露的隐私标签，网友发现 XChat 保留了收集并与用户身份关联的数据权利，涵盖联系人信息、通讯内容、使用数据、诊断数据以及用户 ID。与此对照的是，Signal 仅收集注册必需的极少量联系人信息，且从不与个体身份关联。

更深的问题在于元数据。XChat 可能加密了你发送的文字和图片本身，但 X 平台在后台完整记录的是：你在和谁聊、聊的频率、最活跃的时间段、传输文件的大小。

在当代数据经济里，元数据的商业价值往往高于内容本身。这些行为轨迹可以反哺 X 主站的广告引擎，也是训练 Grok AI 的绝佳语料。简言之，聊天内容加密、行为数据裸奔，成了 XChat 最大的隐私悖论。

醉翁之意不在酒，马斯克的超级应用野心

理解 XChat 的野心，得先理解马斯克真正想做什么。他如此大费周章，想要的绝对不是一个仅仅用来聊天的工具，而是一个让用户把日常生活都装进去的「超级应用」，既是你和朋友说话的地方，也是你转账、买东西的地方。

按照这个逻辑，XChat 只是第一步。它要和即将上线的 X Money 支付系统深度绑定，让用户在发消息的同时就能完成跨国汇款和日常转账，把「社交+支付」的商业闭环彻底打通。

不过，障碍在于监管。

美国没有统一的联邦金融汇款牌照，必须在五十个州逐一申请。截至 2026 年初，X Payments LLC 已拿下超 40 个州及华盛顿特区的许可，但北美金融的心脏纽约州，依然对马斯克紧闭大门。

美国纽约州参议员 Brad Hoylman-Sigal 和众议员 Micah Lasher 曾联名向纽约金融服务局递交公开信，措辞严厉，要求拒绝向 X 发放牌照，理由是马斯克「行为严重缺乏品格与一般适合性」。

对于一个志在全美乃至全球的支付网络来说，丢掉纽约州，XChat 内的支付网络就无法覆盖全美最有消费力的人群，更何况，西方用户本就对「把所有鸡蛋放进一个篮子」这件事天然抵触，支付功能再打折扣，这个故事就更难讲下去了。

种种受挫的现实固然让人对「超级应用」的说辞产生怀疑，但只要看透他底层的逻辑，眼下的一切就变得合理起来。

抛开那些关于阅后即焚、加密隐私的极客噱头，目前关于 XChat 最具想象力的传闻，是它将如何与自家的 AI 大模型 Grok 融合。

虽然我们还没法实际上手验证，但如果顺着这个思路展开推演，你会发现，马斯克真正想颠覆的，根本不是聊天体验，而是人机交互的底层逻辑，也就是在 AI 时代做一个超级应用，那应该是什么样子？

微信的超级应用模式可以概括为「入口聚合」：一个 App 把出行、外卖、支付、社保、健康全部塞进来，用户在一个界面里跳转不同的服务。这个模式基本定义了过去十年中国互联网的产品范式。但它的底层逻辑始终是「你来找服务」。你知道你要打车，你点进滴滴的小程序；你知道你要付款，你打开微信支付。

只是，入口聚合，是 App 时代的超级应用答案。AI 调度，可能才是 AI 时代超级应用的版本答案。与其把一百个功能塞给用户，不如让一个 AI 替用户搞定一切。

当然，从目前的爆料信息来看，XChat 离这个愿景还差得远，没有丰富的服务生态做支撑，Grok 就算再聪明，也只能在聊天框里做做翻译和文字总结的苦力活。马斯克的答卷也许潦草、充满争议，但他已经开始交卷了。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

99 年生的张舒昱，是腾讯电脑管家团队入职不久的产品经理，这在腾讯算不上核心业务线。

今年 1 月 OpenClaw 刚在中国爆火，她着了迷，拉上几个人攒了一个产品原型 QClaw：基于 OpenClaw，一键安装，通过微信直接操控智能体。

项目在腾讯体系里几乎没有存在感，没有立项审批，没有总办资源，几个年轻人凑在一起写代码。

3 月 9 日，QClaw 内测上线。一周之内，数百万用户注册。

然后事情开始失控，惊动了腾讯总办。

高层反应极快，随即调拨数十名员工和计算资源到张舒昱的团队。同日，另一支团队推出了 WorkBuddy，同样兼容 OpenClaw。再隔一天，腾讯港股大涨超过 7%，投资者把涨幅直接归因于这两只虾。

3 月 11 日凌晨 2:06，马化腾发了条朋友圈：「自研龙虾、本地虾、云端虾、企业虾、云桌面虾，安全隔离虾房、云保安、知识库……还有一批产品陆续赶来。」

这对腾讯 11 万员工是一个鲜明的信号，无数员工将其解读为：Pony 支持他们 all in 龙虾。

据 The Information 独家报道，截至本月，腾讯内部同时有 8 个团队在开发基于 OpenClaw 的产品和服务。加上在研和内测项目，总数已超过 10 个。

15 年前，腾讯内部三个团队赛跑移动 IM，张小龙的广州研发部跑出了微信，是腾讯史上赛马最成功的一次。这次换了个物种，叫赛虾。

一个 99 年产品经理做的边缘项目，两周之内变成一家万亿市值公司的战略支点，似乎有点不可思议。

张舒昱对 The Information 说了一句大实话：「我们都在用 AI Agent 做实验。此刻，没有人能说什么是最佳方法。」

翻译一下就是：我们也不知道答案，但先跑起来总比站着强。

全村的希望：腾讯为什么把命押在一只虾身上

要理解腾讯对龙虾的狂热，先要直面鹅厂当下在 AI 竞争中的处境。

过去两年，中国 AI 大模型军备竞赛打得昏天暗地。

阿里砸钱做千问，字节孵出豆包，在用户规模和模型能力上都拉开了身位。腾讯呢？手握游戏和微信广告的丰厚利润，但在 AI 赛道上远不及这两个对手激进。

自研的混元大模型尚且无法与竞争对手匹敌，又拖累了自家 AI 助手「元宝」的进展。

腾讯不是没努力。去年请来前 OpenAI 研究员姚顺雨执掌混元研究，重建了研发基础设施。 4 月即将发布的混元新一代模型，业内普遍视为腾讯模型能力的一次摸底考试。

但远水解不了近渴，在新模型交卷之前，缺乏强大的内部模型，让元宝在与豆包和千问的竞争中暂时落于下风。

所以当 OpenClaw 在中国引爆了 Agent 热潮，腾讯高层几乎是本能地抓住了这根绳子。这只龙虾证明了 AI 的下一个爆发点未必在聊天框里，可能在桌面上，在工具里，在无数个能替你干活的智能体身上。

腾讯高层的判断很清晰： OpenClaw 引发的这一轮 Agent 浪潮，将是 AI 战场重新洗牌的机会。

他们逻辑是这样的，如果腾讯能通过将 OpenClaw 类Agent 能力与微信深度整合，提供配套工具和服务，成为中国最好的 Agent 使用平台，那么即便其内部大模型不是最强大的、AI助手也不是最受欢迎的，腾讯依然有可能在 AI 下半场逆风翻盘。

2020 年，马化腾在腾讯内部将视频号称为「全村的希望」，寄望于它在短视频赛道上扳回一城。如今，「全村的希望」换了物种。

区别在于，视频号好歹是亲生的，龙虾来自一个奥地利独立开发者的 GitHub 。

某种意义上，这更像是 2014 年纳德拉接手微软后做做的事，承认在移动互联网上输了，放下「什么都要自己做」的控制欲，押注一条全新赛道。

纳德拉用了十年，腾讯希望快一点。

八虾夺嫡，腾讯赛虾背后

外界把多团队并行理解为经典赛马机制，腾讯内部更愿意说「多样性」。QClaw 和 WorkBuddy 是最先冒头的两只虾，路线截然不同。

QClaw 是张舒昱从电脑管家边缘团队杀出来的，直接拥抱 OpenClaw 开源生态，做微信一键安装，野蛮生长。设计理念就四个字：打开即用。不需要配置环境，不需要懂终端命令，微信扫一下就能让 AI 接管你的电脑。

WorkBuddy 则走了一条完全不同的路。负责人汪晟杰在接受 APPSO 采访时反复强调一件事：百分百自研，没用过一行 OpenClaw 源码。

它走半自动化路线，避开了 OpenClaw「透传」模式下信息暴露在公网上的风险，采用 bot 推送通知模型，每一步关键操作都需要用户确认。汪晟杰的定义很明确：龙虾是一个概念，不等于 OpenClaw。WorkBuddy 要做的是安全可控的龙虾，企业能放心用的龙虾。

汪晟杰透露了一个时间细节：WorkBuddy 在 1 月 17 号那个周末就已启动，三四个人通宵做出 MVP（最小化可行产品），原计划 3 月 16 日发布。看到龙虾热潮后提前了一周，撞上了 QClaw 同期发布。

也就是说，腾讯并非在 OpenClaw 火了之后才匆忙跟进。多个团队在不同时间点嗅到了同一个机会，OpenClaw 的爆火更像催化剂，把水面下的项目一夜之间推上了前台。

但赛虾机制的矛盾也摆在桌上。

QClaw 和 WorkBuddy 功能高度重叠，都能通过微信操控 AI 智能体，用户该选哪个？8 支团队同时跑，资源会不会内耗？

答案藏在张舒昱那句话里：「此刻没人知道什么是最佳方法。」8 支团队同时下场，与其说是信心爆棚，不如说谁都没有把握。

腾讯选择用数量对冲不确定性，多条路线同时跑，押中一条就够了。

赛马机制的精髓从来都是：靠数量提高命中概率。15 年前微信就是这么跑出来的。

马化腾的养虾哲学

赛虾的前提是有虾可赛，但这只虾不归腾讯管。

3 月 12 日，OpenClaw 创始人 Peter Steinberger 在 X 上公开批评腾讯，矛头直指腾讯的 SkillHub 服务复制了社区 Skills 却没有做出任何贡献。

两天后，腾讯通过 GitHub 捐款，随后被列为特色赞助商，与 OpenAI 并列。在上周英伟达 GTC 大会上，腾讯云 CEO 汤道生当面约见 Steinberger，提出由腾讯云贡献服务器和安全服务，并探讨与 OpenClaw 基金会更深层的合作。

中国市值最高的互联网公司之一的高级副总裁，飞到圣何塞跟一个开源项目创始人坐下来谈合作。在腾讯历史上几乎没有先例。当你需要别人的东西比别人需要你的东西更急迫时，身段自然就放下来了。

同一周的财报发布会上，腾讯总裁刘炽平宣布 2026 年将 AI 新产品的投资至少翻倍，从去年的 180 亿元起步。而在阐述钱花到哪里时，他只点了三个名字：混元、元宝、以及最新的 Claw 产品。

一个月前还是边缘项目的龙虾，一跃与腾讯自研大模型和旗舰 AI 应用并列。龙虾从「大家自己玩玩」正式升格为「公司战略」。

马化腾最近在财报会议上的发言，进一步回答了一个更本质的问题：腾讯想用龙虾做什么？

他的切入角度直接跳过了产品层面，落在生态上。

马化腾认为龙虾类应用有记忆和个性，更像助理，带有「活人感」，能让 AI 落地到办公、终端、小程序等各种场景中，不再全部挤在 chatbot 这条独木桥上。

但真正耐人寻味的是他关于「去中心化」的论述。微信本身是中心化的 App，但微信生态是去中心化的，数十万小程序商家构成了开放平台。马化腾认为 AI Agent 天然具有去中心化特征，可以融入微信生态。有一句话特别关键：

所有服务商的心态都是怕被 AI 智能体「短路化」「渠道化」。

意思是，他不想让 AI Agent 变成一个新的中间商，把微信里的服务商变成纯粹的后端 API。他想让小程序保留独立性，同时具备 AI 能力。「每一个小程序都可以智能化和龙虾化。」

这个思考比「我们也做龙虾」高出一个维度。马化腾看到的是一种范式转移的可能：AI 的价值分配方式，从「一个超级 chatbot 统治一切」变成「无数分布式智能体各显神通」。

如果这个判断成立，拥有全球最大通讯生态和最活跃小程序平台的微信，天然就是 Agent 时代最肥沃的土壤。

刘炽平在财报会上把这套逻辑做了明确的总结：「Claw 提出了一种去中心化的模型……有段时间，似乎每个人都在争夺成为 AI 智能体唯一的入口和垄断者。但现实并非如此。」

一句话概括腾腾讯的押注逻辑：模型之争输了一局，但生态之争的牌还没摊开。

当然，这套叙事也可以被翻译成另一句话：我们模型不够强，所以告诉你们模型没那么重要。

自洽和自欺之间，有时候只隔一层窗户纸。但关键在于，这一次腾讯确实有牌可打。微信不需要成为最强大模型的容器，只需要成为最好用的 Agent 运行环境。

这和纳德拉的 Azure 逻辑如出一辙，你不需要自己做出最好的 AI，你只需要让最好的 AI 都跑在你的云上。

养虾产品全景图，腾讯到底下了多少注

腾讯的「养虾」远不止做几个 C 端产品那么简单。腾讯周五公布了「养虾产品全景图」，这套从底层到应用层的完整龙虾矩阵，密度超出外界预期。

消费级产品打头阵。QClaw 主打微信一键安装，面向普通用户；WorkBuddy 走桌面端自研路线，强调安全可控；微信 ClawBot 负责让用户在微信聊天界面直接操控龙虾。

三个产品覆盖了「小白用户一键上手」「桌面深度使用」「微信生态无缝接入」三个核心场景。光是消费级这一层，腾讯就同时铺了三条路。

企业级产品紧随其后。ClawPro 面向企业和政务客户，主打安全隔离和精细权限管控，企业微信独占通道，账号权限分级，内置技能审核机制，代码生成类操作要过审，网页搜索走安全网关。

汤道生在腾讯云峰会上重点推介了 ADP（智能体开发平台），定位是企业构建定制化 Agent 的工具箱。配合 Claw Runtime 提供安全沙箱运行环境，Lighthouse 做安全管理。

整套企业方案的逻辑很清晰：OpenClaw 太野了，我帮你把它关进笼子里。

开发者生态也没落下。CodeBuddy 是去年下半年就上线的 AI 编程助手，现在被纳入龙虾矩阵成为开发者入口；SkillHub 是 AI 技能社区，做了本土化适配，也正是因为这个产品被 Steinberger 点名批评后才有了后面那笔捐款。TokenHub 则是模型服务市场，不光接混元，也接 DeepSeek、MiniMax、Kimi 等第三方模型，统一计费。

腾讯连「卖铲子」的生意都想好了。

从这张全景图可以看出，腾讯不想只在产品上做单点突破，要做一整条龙虾产业链——从安装到运行，从个人到企业，从消费到开发，每个环节都有人盯着。

这正是汤道生反复强调的「Harness 工程」思路：Agent 时代的胜负手不在模型本身，在于脚手架。工具调用、上下文工程、长期记忆管理、工作流设计，这些看起来不性感的苦活，才是决定 Agent 好不好用的关键变量。

汤道生在腾讯云上海峰会上表示：「AI 落地不只是算法题，Harness 工程能力是关键变量。不同的脚手架设计，会显著影响实际使用效果和 token 成本。」

翻译成人话就是：模型是发动机，但没有底盘和方向盘，跑不了多远。腾讯模型暂时跑不过别人，但如果能把底盘和方向盘做到最好，照样能赢。

虾潮退去之后

把所有线索串起来，这个故事可以被浓缩成一句话：腾讯用一家大公司能调动的所有资源，去拥抱了一个自己无法控制的开源项目。

这是一个充满张力的姿态。

OpenClaw 的更新节奏是每周两三个版本，API 说改就改，Breaking Changes 说来就来。Peter 点一下 merge，深圳大厦里好几支产品团队可能就要通宵救火。腾讯把战略命脉系于别人的 GitHub 仓库上，这需要的不只是勇气，还有一种前所未有的谦逊。

但换个角度想，腾讯可能也没有更好的选择了。

如果继续只在模型和 chatbot 赛道上硬碰硬，不是陪跑就是陷入同质化厮杀。但 Agent 浪潮撕开了一条新缝隙：谁能把 AI 变成最好用的工具，谁就能重新定义入口。

微信有 14 亿月活，有小程序生态，有支付，有社交关系链。这些东西造不出最强模型，但能造出最好的 Agent 使用环境，这是腾讯手里唯一一张别人没有的牌。

问题在于，这张牌的有效期有多长。

OpenClaw 仍在快速迭代，生态远未定型。今天的龙虾热，会不会像去年的 Manus 一样来得快去得也快？8 支团队赛虾，会跑出下一个微信，还是跑出 8 个半成品？马化腾的「去中心化 Agent 生态」蓝图很美，但从蓝图到现实之间，还有需要经历多少次「技术事故」？

不过，有一件事是确定的。

当一家公司的 CEO 凌晨两点发朋友圈，总裁在财报会上把龙虾和自研模型并列，高级副总裁飞到美国去约见开源项目创始人，8 支团队同时下场赛虾，AI 投资直接翻倍，它就已经不是在追热点了，它在押注这家公司的未来。

赌的不是这只虾能活多久。赌的是在 AI 重构一切的十年里，腾讯还能不能坐在牌桌上，以及坐在什么位置。

视频号当年也被叫做「全村的希望」。五年过去了，它还没打败抖音，但在微信生态内长出了自己的活法。龙虾能不能也走出第三条路？答案还早。

不过，当一个巨头被逼到墙角，终于想清楚自己要什么，把资源砸向同一个方向的时候，你永远不能低估它。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

一觉醒来，很多网友发现微信里的虾不能用了，原因是 OpenClaw 昨天一次大更新。

APPSO 在开头强烈建议，如果你想在微信养虾，先别升级到 OpenClaw 最新版。

当我们尝试把手边的 OpenClaw 更新到最新版本时，果然在更新的过程中，就接连报出好几个警告。

不只是微信（下图中 openclaw-weixin），我们之前配置的腾讯系 qqbot、企业微信 wecom-openclaw-plugin，以及飞书等聊天应用，都遇到了「包含危险代码模式」的警告。

所谓的检测到危险的代码模式警告，一般是说在相关的插件代码里，有一些写法，可能带来安全风险、稳定性问题，或者被恶意利用。

它和报错不同，报错是代码已经出现明确问题，程序没法正常继续，或者结果不可信。

更新完成后，我们尝试在微信里面和 Clawbot 对话，控制部署在本地的 OpenClaw，连发好几条消息都没有回应。

查看 OpenClaw 的官方日志，我们发现，在微信里发给 Clawbot 的信息，完全不能同步到 OpenClaw 处理。反而好几条都是 error 的报错信息，提示找不到 OpenClaw 的 plugin-sdk 的模块。

Error: Cannot find module ‘openclaw/plugin-sdk’

但是 QQ Bot 却还能正常回应。

在我们按照微信官方的 Clawbot 插件提示，重新在终端里输入命令安装 Clawbot 时，开始像 OpenClaw 的运行日志里面，报出找不到相关模块的问题。

OpenClaw 更新了什么，它也是「屎山」？

OpenClaw 现在可以说是 GitHub 上的顶流开源项目，几乎每天都有人在为他提交优化代码，而官方基本上也是保持在 2-3 天就会更新一个新的发布版本，每次都是大量的 fixes 代码修复、changes 变更，和 breakings 大改动。

在这次 2026.3.22-beta.1 的更新中，Openclaw 团队就进行了一次重构。对于插件系统，他们做了两个大幅度的变动。

拆除了原有的总大门： 以前所有的插件都可以直接从 openclaw/plugin-sdk 这个统一的入口拿到需要的功能。这次更新，官方直接把这个总入口给删了。

不提供任何过渡方案： 更新日志里明确写了 no compatibility shim（无兼容垫片）。意思就是，他们不仅直接把这个模块删除了，连个转移和过渡的接口都不给。

OpenClaw 为什么会这么大刀阔斧地更新？

虽然对用微信 Clawbot 的普通用户来说很折磨，但从软件工程的角度，官方这么做主要是还是为了性能和安全。

以前的统一入口的模式，会导致插件一口气把整个开发包（SDK）全加载进内存，哪怕它只用到了一小部分功能，这会让软件变得臃肿缓慢。

现在官方强制要求细分路径（比如必须写精确到 openclaw/plugin-sdk/core），就是要逼着插件作者「要什么拿什么」，从而大幅提升 Openclaw 的启动速度。

此外，更新日志里还提到了「阻断相对路径的跨包逃逸」。意思是以前的旧接口太宽松，稍微有点恶意的插件可能会越权访问你电脑里的其他数据。现在强制使用细分的新接口，是为了把每个插件严严实实地关在自己的小盒子里。

OpenClaw 在自己的官方文档里也立刻更新了说明，提到这个更新，主要就是为了实现按需加载，提升启动速度和省内存，另一方面是让 API 的接口更加清晰。

强制遵守 API 规矩，就是要求插件只能使用公开的、稳定的接口（也就是 openclaw/plugin-sdk/* 里面的东西）来获取能力。

如果大家都用相对路径去偷偷访问底层的私有代码，一旦官方修改了底层代码的文件夹名字，就会直接拦截报错。

发布才 72 小时，就这样被拦截了

原因已经很明显了，就是微信的 clawbot 插件找不到和 OpenClaw 对接的路线了。

微信和企微插件的作者在写代码时，使用的是旧版的规则，代码里写死了要去 openclaw/plugin-sdk 找工具。

而在我们启动新版 Openclaw 时，程序读到微信插件的这行代码，去系统里一找——发现官方已经把这个路径给删了。

OpenClaw 的运行环境使用的是 Node.js 平台，它是个一板一眼的机器，找不到东西它就会立刻报错：Error: Cannot find module 「openclaw/plugin-sdk」，然后直接原地罢工，导致我们的微信和企微甚至连加载都加载不出来。更不用说发消息给他，想要得到回复了。

而 QQBot 还能正常使用，主要是一开始的危险代码警告，仅针对这次更新引入的严格静态代码扫描工具，警告并不会阻止插件运行。

社交媒体上对这件事议论纷纷，有人说「微信想要继续好好利用这个插件，就必须认真学习开源生态系统的相关知识了。」

也有人反驳，是 OpenClaw 本身就很不稳定，一直在更新修改。

「即便微信要对开源做适配，为什么不直接说 OpenClaw 的 API 设计太糟糕呢？项目一开始的接口简直就是一堆乱七八糟的东西，稍微改动一下就崩溃」。

确实如此，通常开源社区负责任的做法是，会先标记旧接口为「已废弃（Deprecated）」，保留运行能力但弹窗警告，给开发者几个月的过渡期，下个大版本再彻底删除。

这次，微信辛辛苦苦更新了一个版本，推出了支持二维码登录、消息收发等功能的「真.微信龙虾」，甚至有网友发现在微信公开的这个插件安装包里面，是微信第一次开放个人机器人的协议。

但刚迈出了这么大的一步，反手就被 OpenClaw 的一次更新给「背刺」了。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。