前言

本人从事软件开发工作已有 15 余年。早期有 5 年时间专注于直播行业开发，随后转型从事商城系统开发。

在直播行业期间，主要模式是将软件销售给客户，并根据客户需求进行定制化功能修改。由于部分客户群体（如秀场直播等）无法直接对接银行、微信或支付宝等主流支付渠道，他们往往自行寻找第三方支付平台，并要求我将其接入系统中。因此，我积累了大量不同支付接口的对接经验。

后期转向商城开发后，为了利用银行的营销补贴活动（例如：某银行推广网上支付，用户支付 38 元立减 20 元，实际用户支付 18 元即可获得 38 元商品，差额由银行补贴），我又直接对接了多家银行的支付接口。

技术选型策略：统一 H5 支付接口

我们的支付场景覆盖 PC 端、H5 网页、Android App、iOS App 以及微信小程序。为了降低维护成本，除微信和支付宝使用原生 SDK 外，其他所有支付渠道均统一接入 H5 支付接口。

这种策略的优势在于：

• 代码复用率高：一套核心逻辑可服务于多个终端。
• 维护成本低：无需为每个平台单独维护一套支付逻辑。
• 兼容性较好：H5 页面在 App 内通过 WebView 加载，或在浏览器中直接打开，体验相对统一。

通用支付流程

除中信银行等特殊案例外，大多数支付流程如下：

1. 发起请求用户在商户平台（我方开发系统）选择充值金额（如 100 元）及支付方式（如 A 支付）。
2. 跳转网关：系统生成订单并跳转至 A 支付的网关页面。
3. 用户支付：用户在网关页面完成支付操作。
4. 回调验证：支付完成后，用户跳回商户平台。同时，支付平台异步通知商户服务器。
5. 业务处理：商户服务器验证签名及数据合法性，确认无误后为用户账户充值相应金额。

开发效率与沟通成本分析

接入一个支付平台的纯开发时间通常在 半天到 1 周 之间（不包含前期沟通与审核时间）。不同机构的对接难度差异巨大：

1. 高效案例：招商银行一网通

• 开发耗时：约半天。
• 优势：文档完善，Demo 齐全，提供测试账号。
• 沟通：拥有专属微信沟通群，遇到问题可直接咨询银行技术人员，响应迅速。

2. 困难案例：中信银行

• 开发耗时：纯开发约 1 周，但整体周期长达 2 个月。
• 劣势：文档和 Demo 不完整。
• 沟通瓶颈：审核流程繁琐，需多次发送邮件沟通，每次审核耗时 1 周或更久。在审核期间无法进行下一步开发，极大拉长项目周期。

3. 一般规律

• 小型第三方支付：接入简单，签名算法通常仅为 MD5，从开发到上线可在 1 天内完成。
• 银行系支付：相对复杂，常使用 SHA256 等更安全的签名算法，且线下审批流程各异。招商银行流程顺畅，而中信银行等则沟通成本极高。

各支付平台对接详情

以下列出我曾对接过的 16 种支付渠道，并对重点渠道进行简要说明。

主流支付

1. 支付宝

• 特点：文档极其完善，Demo 丰富，社区资料多。
• 开发体验：无需沟通客服。下载官方 Demo，替换配置参数，调整跳转逻辑及回调处理即可快速完成。
• 官方文档：支付宝开放平台

2. 微信支付

• 特点：文档规范，无人工客服支持。
• 开发体验：无需沟通。下载 Demo，修改配置，处理支付发起与回调逻辑即可。
• 官方文档：微信支付 H5 开发文档

银行系支付

3. 招商银行一网通支付

• 语言：PHP
• 详情：对接体验良好，文档清晰。
• 参考文章：PHP 接入招商银行一网通支付

4. 光大银行 H5 支付

• 语言：PHP
• 参考文章：PHP 接入光大银行 H5 支付

5. 中国农业银行 H5 支付

• 语言：PHP
• 参考文章：PHP 接入中国农业银行 H5 支付

6. 宁波银行 H5 支付

• 语言：PHP
• 参考文章：PHP 接入宁波银行 H5 支付

7. 中信银行 H5 支付

• 语言：PHP
• 特点：沟通成本高，审核周期长。
• 参考文章：PHP 接入中信银行 H5 支付

第三方支付平台

8. 国边四方支付 (bbnpay)

• 状态：官网已无法访问，不再详细介绍。

9. 网银在线 (chinabank)

• 官网：https://chinabank.com.cn/
• 特点：文档和 Demo 质量较好，开发速度快。

10. 国付支付 (guofu)

• 状态：官网已无法访问，不再详细介绍。

11. 汇银通支付 (huiyintongpay)

• 状态：官网已无法访问，不再详细介绍。

12. IPS 支付 (ips17)

• 状态：官网已无法访问，不再详细介绍。

13. 快钱支付 (kuaiqian)

• 官网：https://www.99bill.com/
• 特点：接入简单，依据文档和 Demo 即可快速完成。

14. 连连支付 (llpay)

• 官网：https://www.lianlianpay.com/
• 特点：提供 Demo，直接基于 Demo 开发，复杂度低。

15. 通汇支付 (tonghui)

• 官网：http://41.cn/
• 状态：官网已无法访问，不再详细介绍。

16. 易宝支付 (yee)

• 官网：https://www.yeepay.com/
• 特点：文档和 Demo 质量较好，开发效率高。

总结

在支付接口对接工作中，“文档质量” 和 “沟通渠道” 是决定开发效率的关键因素。

• 推荐优先选择：支付宝、微信、招商银行、网银在线、易宝支付、连连支付、快钱支付。这些平台文档健全，流程规范，能显著缩短开发周期。
• 需谨慎选择：沟通流程冗长、文档缺失或官网稳定性差的中小型支付平台。虽然初期接入可能看似简单，但后续的维护风险和沟通成本可能远超预期。

希望以上经验能为正在面临支付选型和对接开发的同行提供参考。

在步入职场之前，我对浏览器的认知仅局限于 Internet Explorer (IE) 和 Firefox (火狐)。从事 Web 开发工作后，由于需要频繁调试网页在不同内核下的兼容性，我不得不在电脑上安装五到六款不同的浏览器。在日常测试与浏览的过程中，我逐渐被 Chrome 浏览器所吸引，并习惯将其作为主力工具。

Chrome 给我的工作和生活方式带来了显著的改变，主要体现在以下几个方面：

1. 高效的书签同步与数据管理

在转向 Chrome 之前，我长期使用 Firefox。虽然 Firefox 的 Firebug 插件在当时是前端调试的神器（至今我仍会在需要深度调试时启用它），但其内存占用过高的问题一直令人困扰。

Chrome 的同步功能极大地提升了我的工作效率。它不仅能够同步保存的网页书签，还能同步应用主题、保存的密码以及其他个性化设置。当我更换电脑或在新设备上工作时，只需登录账号，所有配置和数据即可瞬间恢复，无需重新配置环境。

此外，Chrome 的书签栏设计也颇具人性化。默认情况下，书签栏仅在打开新标签页时显示，或者可以设置为始终显示但布局紧凑。这种设计为我提供了更大的页面可视空间，让浏览体验更加专注。

2. 界面清爽，可视面积大

许多 Chrome 用户都有同感：Chrome 的界面极其简洁。它去除了大量不必要的边框和装饰元素，将屏幕空间最大限度地留给网页内容本身。

这种“极简主义”的设计不仅让视觉体验更加舒适，也在心理上给人一种浏览器运行轻快、响应迅速的感觉。相比于其他传统浏览器繁杂的工具栏，Chrome 的留白艺术确实独树一帜。

3. 操作逻辑简单直观

Chrome 的设置入口统一集中在浏览器右上角的菜单中。无论是调整隐私设置、管理扩展程序，还是清除浏览数据，用户都可以轻松找到对应的选项。这种扁平化的操作逻辑降低了学习成本，让用户能够专注于内容而非工具本身。

4. 丰富的插件生态

Chrome 拥有强大的扩展程序商店，能够满足各种个性化需求。目前我安装了不到 10 个插件，其中高频使用的包括：

• Neat Bookmarks：用于快速查找和管理书签，提升导航效率。
• AdBlock：有效屏蔽网页广告，净化浏览环境。
• Proxy SwitchySharp：方便地切换网络代理，满足开发测试需求。

这些插件极大地增强了浏览器的功能性，使其不仅仅是一个查看网页的工具，更成为一个高效的生产力平台。

5. 广阔的发展前景

Google 对 Chrome 的持续投入令人印象深刻。当时 Chrome 正计划内置语音和视频聊天功能，这一举措展示了其成为全能型互联网平台的野心。

正如 Android 系统在移动领域的普及一样，我相信凭借卓越的性能、开放的生态以及 Google 的技术支持，Chrome 将在桌面浏览器市场占据主导地位，甚至成为Web标准的重要推动者。

结语

综上所述，Chrome 浏览器以其高效的同步机制、清爽的界面设计、简单的操作逻辑、强大的插件生态以及广阔的发展前景，深刻地改变了我的开发习惯和网络生活。它不仅是我的工作利器，更是我探索互联网世界的首选窗口。

BLE/低功耗蓝牙

基于 UTS 的低功耗蓝牙插件，支持 App 端：

• Android
• iOS
• HarmonyOS

支持能力：

• 蓝牙初始化
• 扫描设备（名称/服务过滤）
• 连接与断开
• 获取服务和特征
• 读特征
• 订阅通知（notify）
• 写特征（字节/字符串、UTF-8/GBK/HEX）
• 获取/设置 MTU（iOS/Harmony 根据平台能力做兼容处理）

BLE插件主页

BLE插件Android体验包

经典蓝牙

基于 UTS 的经典蓝牙插件，支持 App 端：

• Android
• HarmonyOS

支持能力：

• 搜索周边设备
• 获取已配对蓝牙
• 连接蓝牙设备（未配对会先配对再连接）
• 读取蓝牙数据
• 向蓝牙写入数据支持UTF-8、Hex、gbk数据格式。支持分片下载（设置MTU）

经典插件主页

经典插件Android体验包

十年全栈开发经验，人工编写代码为主，AI仅作为辅助工具
绝非AI全自动生成式开发，代码结构清晰、逻辑严谨、可维护性强、无AI屎山代码，尽可能减少后期BUG和技术陷阱。
可先开发，验收满意后再付费！

【服务范围】
✅ APP开发（Android / iOS）
✅ 小程序开发
✅ PC网站开发
✅ 管理后台开发
✅ API接口开发
✅ 服务器部署、运维及优化
✅ 项目二次开发与功能升级

【技术栈】
前端：
• UniApp跨平台开发
• 一套代码可编译为 Android、iOS、鸿蒙，PC，网页等多个平台

后端：
• PHP + MySQL 高性能架构设计
• 易部署、易维护、低运营维护成本

【合作优势】
✔ 先开发后付费，降低合作风险
✔ 全栈开发，前端后端服务器均能搞定
✔ 一人抵一个团队，沟通容易成本低
✔ 免费提供1年技术支持与售后服务
✔ 可长期维护运营项目

📩 有需求的各位老板请联系我。

微信：476519913

以前用的虹软的号称免费的，但是每年都必须强制升级更新SDK发布版本，测试也烦
可以付费购买一个不是很贵的，预算5000 -7000. 必须有活体检测，我们就App内考勤用不太很严格

源码地址：http://hetaipack.com/xiaozhi.zip

插件地址：https://ext.dcloud.net.cn/plugin?id=27909
Xiaozhi AI通过websocket协议自动接受播放语音，录音PCM编码供websocket发送

最近做了一个开源的 AI 智能客服平台：Supportly。

项目定位是：基于 Cloudflare 的免费自部署客服系统，不做 SaaS 绑定，适合个人开发者、小团队、独立产品先快速搭建一套自己的客服和 AI 问答能力。

QQ 交流群：1081883123

主要能力

• Web Chat Widget：网站一段 JS 接入客服
• UniApp SDK：App / 小程序 / H5 可接入客服聊天
• Admin 后台：查看会话、人工回复、切换 AI / 人工接管
• RAG 知识库：上传文档后，AI 基于知识库自动回复
• WebSocket 实时消息：客服回复和 AI 回复可以实时推送
• Telegram Bot 接入
• Custom Webhook 接入
• Cloudflare D1 存储会话和消息
• Cloudflare AI Search 做知识库检索
• Workers AI 生成回复

技术栈

后端：

• Cloudflare Workers
• Hono
• TypeScript
• Cloudflare D1
• Cloudflare AI Search
• Workers AI
• Durable Objects WebSocket

前端：

• Admin 后台
• Web Chat Widget
• UniApp JS SDK

UniApp SDK

UniApp SDK 是纯 JS Headless SDK，不绑定 UI。

消息链路是：

• 发送消息：HTTP
• 接收消息：WebSocket
• 历史消息：HTTP
• 断线后：自动重连并补消息

业务项目可以自己做聊天 UI，SDK 只负责初始化会话、发送消息、实时接收、历史同步和重连。

适合什么场景

• 独立站接入在线客服
• UniApp App / 小程序接入客服聊天
• 小团队自建 AI 客服
• 用自己的知识库做智能问答
• 不想一开始就接入收费客服 SaaS
• 想基于 Cloudflare 免费额度先跑起来

项目地址

主项目：

https://github.com/unicornB/Supportly-Ai

UniApp SDK：

https://github.com/unicornB/Supportly-Ai-UniApp-SDK.git

Web Widget：

https://github.com/unicornB/Supportly-Ai-Web-Widget.git

Admin 后台：

https://github.com/unicornB/Supportly-Ai-Admin.git

说明

客户发消息 -> 后台会话 -> AI 检索知识库 -> 自动回复 / 人工接管。

如果大家对 UniApp 客服 SDK、Cloudflare 免费自部署、AI RAG 客服这类方向感兴趣，欢迎交流建议。

截图

这是 DCloud（uni-app 官方）造成的，不是你的问题。

原因
DCloud 目前在做大版本升级：

版本 状态
uni-app 2.x ✅ 稳定版，但已经停止更新
uni-app 3.x ❌ 只有 alpha，从未发布正式稳定版
你的项目创建时用的是 CLI 创建模板（npx degit dcloudio/uni-preset-vue#vite-ts），模板默认拉的就是最新的 alpha 版本。而 DCloud 从 2024 年开始就把所有新功能都只发在 alpha 频道了——npm 上根本没有 3.x 的稳定版。

为什么会这样
DCloud 的策略是：

大力推 uni-app x（原生渲染，需要新编译器）
传统 Vue3 模式被边缘化，不再发稳定版
HBuilderX 5.x Alpha 只内置 uni-app x 编译器
传统 Vue3 编译器停留在 4.x 时代
你的选择
路径 做法
A. 继续用 alpha 装 HBuilderX 4.86-alpha 匹配当前依赖，能用但未来有风险
B. 回退到 2.x 稳定版 改 package.json 用 @dcloudio/uni-app@^2.0.0，完全稳定，但缺少一些 3.x 新特性
C. 等 DCloud 发 3.0 正式版 时间未知
我建议先试 A（4.86-alpha），如果还不行就走 B（降级到 2.x 稳定版），项目代码基本不需要改。

开发支持OpenHarmony

打包日志如下：

容器启动，准备执行打包任务...
目标脚本路径: /opt/pack.sh
输出目录: /opt/apppack

开始执行打包脚本...
bash: warning: setlocale: LC_ALL: cannot change locale (zh_CN.UTF-8)
开始执行 HBuilderX 自动化构建和发布流程...
正在克隆代码仓库...
Cloning into 'lhz-app-shop'...
正在启动 HBuilderX CLI...
/usr/bin/bash: warning: setlocale: LC_ALL: cannot change locale (zh_CN.UTF-8)

正在打开项目...
正在导入项目...
项目导入成功

正在登录用户...
0:user login:OK
正在更新版本号...
当前 versionName: 1.1.3
新 versionName: 1.1.4
当前 versionCode: 113
新 versionCode: 114
manifest.json 文件已成功更新！
正在构建 APP 资源包...
19:22:50.743 项目 lhz_shop 开始导出...
19:22:51.280 5.07
19:22:51.329 正在编译中...
19:22:51.611 ​Browserslist: caniuse-lite is outdated. Please run:
19:22:51.612 npx update-browserslist-db@latest
19:22:51.613 Why you should do it regularly: https://github.com/browserslist/update-db#readme​
19:23:02.116 WARNING: Module Warning (from ./node_modules/postcss-loader/src/index.js):
19:23:02.117 Warning
19:23:02.117 (327:3) Gradient has outdated direction syntax. New syntax is like to left instead of right.
19:23:02.127 项目 lhz_shop 编译成功。
19:23:02.222 项目 lhz_shop 正在导出...
19:23:02.260 项目 lhz_shop 导出成功，路径为：/opt/lhz-app-shop/lhz_shop/unpackage/resources
19:23:02.260 本wgt文件由HBuilderX 5.07.2026041610-alpha 版本生成，运行的基座sdk也需配套相同版本，否则在手机端部分功能可能无法正常使用。详见 http://ask.dcloud.net.cn/article/35627

正在执行打包...
19:23:03.470 检查云端打包状态...
19:23:03.643 检查打包资源...
19:23:03.970 <ul style="margin-left: -30px; margin-top: -30px;"><li>[Warning] 为落实《网络安全法》《消费者权益保护法》的要求，有效治理App强制授权、过度索权、超范围收集个人信息等现象，保障个人信息安全，国内各大应用市场都加强了应用审核，要求应用必须符合相关政策才能上架，当前应用缺少相关配置，<a href="https://uniapp.dcloud.net.cn/tutorial/app-privacy-android">查看如何解决</a>。不上架国内应用市场无需处理。</li></ul>
19:23:03.971 正在编译打包资源...
19:23:03.982 项目 'lhz_shop' 开始编译...
19:23:04.511 5.07
19:23:04.512
19:23:04.564 正在编译中...
19:23:04.565
19:23:04.838 ​Browserslist: caniuse-lite is outdated. Please run:
19:23:04.838 npx update-browserslist-db@latest
19:23:04.839 Why you should do it regularly: https://github.com/browserslist/update-db#readme​
19:23:04.839
19:23:04.848
19:23:04.848
19:23:15.323 WARNING: Module Warning (from ./node_modules/postcss-loader/src/index.js):
19:23:15.324 Warning
19:23:15.324
19:23:15.324 (327:3) Gradient has outdated direction syntax. New syntax is like to left instead of right.
19:23:15.324
19:23:15.330 项目 'lhz_shop' 编译成功。
19:23:15.330
19:23:16.445 压缩打包资源...
19:23:17.664 向云端发送打包请求...
19:23:36.006 打包成功后会自动返回下载链接。 打包过程查询请点菜单发行-查看云打包状态。 周五傍晚等高峰期打包排队较长，请耐心等待。 如果是为了三方SDK调试，请使用自定义调试基座（菜单运行-手机或模拟器-制作自定义调试基座），不要反复打包。 项目 lhz_shop [UNI]已成功提交到云端，正在获取打包状态...
19:23:36.129 项目 lhz_shop [UNI]的打包状态： 时间: 2026-04-24 19:23:35 类型: Android自有证书 队列中
19:23:40.671 项目 lhz_shop [UNI]的打包状态： 时间: 2026-04-24 19:23:35 类型: Android自有证书 队列中
19:24:34.261 项目 lhz_shop [UNI]的打包状态： 时间: 2026-04-24 19:23:35 类型: Android自有证书 正在云端打包 [Output]预计 2-5 分钟完成打包，请稍等片刻。
19:25:30.381 项目 lhz_shop [UNI***]的打包状态： 时间: 2026-04-24 19:23:35 类型: Android自有证书 正在云端打包 [Output]预计 2-5 分钟完成打包，请稍等片刻。

加V：china-lsl 获取脚本haha：

1、镜像脚本
2、打包配置
3、下载apk脚本
4、修改版本号脚本
5、一键打包脚本

我现在使用的是Minimax coding plan
接入的时候 使用的是 openai的格式

UNI_AGENT_BASE_URL=https://api.minimaxi.com/v1
UNI_AGENT_API_KEY=你的_MINIMAX_TOKEN_PLAN_API_KEY
UNI_AGENT_PROVIDER=openai-compatible
UNI_AGENT_MODEL=openai-compatible/MiniMax-M2.7
UNI_AGENT_SMALL_FAST_MODEL=openai-compatible/MiniMax-M2.7

但是提示
❌ 错误: invalid params, invalid chat setting (2013)
使用Codex分析uniapp文档和Minimax文档 再提供Hbuilder X的路径后 Codex给出答复是

然后我切换为 anthropic 格式 Minimax支持anthropic

UNI_AGENT_BASE_URL=https://api.minimaxi.com/anthropic
UNI_AGENT_API_KEY=你的_MINIMAX_TOKEN_PLAN_API_KEY
UNI_AGENT_PROVIDER=anthropic
UNI_AGENT_MODEL=anthropic/MiniMax-M2.7
UNI_AGENT_SMALL_FAST_MODEL=anthropic/MiniMax-M2.7

这次提示的错误是
Model not found anthropic/MiniMax-M2.7
anthropic/MiniMax-M2.7 改为 MiniMax-M2.7 也是报错
再次使用Codex分析 给出的答复为
识别不到这个模型名

在 C:\Users\用户名\AppData\Roaming\HBuilder X\extensions\hbuilderx-ai-chat\uni-agent\config 这个路径下修改（没有则创建）
直接拷贝下面的内容 然后修改为你需要的模型ID即可 模型id无需前缀

{
"provider": {
"anthropic": {
"models": {
"你的模型ID": { "id": "你的模型ID", "name": "显示名" }
}
},
"openai-compatible": {
"models": {
"你的模型ID": { "id": "你的模型ID", "name": "显示名" }
}
}
}
}

然后我顺手问了一句Codex 现在能识别什么 答案是5.4

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

进入 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 文档：https://wot-ui.cn/
• Wot UI 仓库：https://github.com/wot-ui/wot-ui
• @wot-ui/vitepress-theme：https://github.com/wot-ui/wot-ui/tree/main/packages/vitepress-theme
• @wot-ui/cli / Open Wot：https://github.com/wot-ui/open-wot
• Wot Starter：https://github.com/wot-ui/wot-starter
• @wot-ui/unocss-preset：https://github.com/wot-ui/unocss-preset
• wot-ui-intellisense 仓库：https://github.com/wot-ui/wot-ui-intellisense
• wot-ui-intellisense 下载地址：https://marketplace.visualstudio.com/items?itemName=wot-ui.wot-ui-intellisense