文章 / AI编程与办公自动化
同样是多维表格 Skill，官方版和我的版本到底差在哪？——我把自己 12245 行的踩坑笔记，摊开给你看
原创 李伟坚 Excel催化剂（附件请在原始资料库或公众号中获取）) 2026年9月20日 最近有不少读者问我一个问题： "我开发的 WPS 多维表格 Skill，和金山官方文档里自带的多维表格 Skill，内容到底有什么不一样？" 问的人多了，我觉得有必要认真地、系统地回答一次。今天，我就把两个
原创 李伟坚 Excel催化剂（附件请在原始资料库或公众号中获取）)
2026年9月20日
最近有不少读者问我一个问题：“我开发的 WPS 多维表格 Skill，和金山官方文档里自带的多维表格 Skill，内容到底有什么不一样？” 问的人多了，我觉得有必要认真地、系统地回答一次。今天，我就把两个 Skill 的源代码都摊开，一项一项地对比给你看。看完你就明白：同样是“多维表格”四个字，官方做的是“够用”，我做的是“死磕”。
一、先亮明：这两个 Skill，从“出身”就不一样
很多人以为这是“同一个东西的两种写法”，其实完全不是。
官方那个多维表格 Skill（wps-docs），它的定位是“接口说明书”。
它是金山官方给灵犀这类 AI 助手封装的一套 API 调用层：你要读记录，它给你一个命令；你要改字段，它给你一个命令。它的存在，是为了让 AI 能“合规地”操作云文档——核心诉求是受控、安全、够用就行。
我做的这套多维表格 Skill（wps-dbsheet），定位是“业务系统自动化平台”。
它要回答的问题是：一个业务人员，怎么用多维表格，搭出真正能用的业务系统？ 权限怎么分、自动化怎么跑、脚本怎么挂、外部系统怎么接、手机电脑怎么同步、要不要做个专属界面……
一个在“安全边界内提供基本操作”，一个在“帮你把业务干成”。目标不一样，做出来的东西，自然天差地别。
二、第一层差异：覆盖面——官方只有“增删改查”，我铺了整条业务链路
这是最直观的差异。我们直接看源码。
官方的多维表格模块（dbsheet），全部能力就这么些：
| 官方 SKILL 的能力 | 类型 |
|---|---|
| 查 Schema（表结构） | 数据面 |
| 记录的增、删、改、查 | 数据面 |
| 字段的增、删、改 | 数据面 |
| 表的增、删、改 | 数据面 |
| 视图的增、删、改 | 数据面 |
| 表单元数据查询 / 更新 | 数据面 |
清一色的“数据增删改查”（CRUD）。 它没有权限管理、没有自动化流程、没有脚本能力、没有外部系统对接——因为在官方的设计里，多维表格就是一坨“数据”，AI 能读能写就够了。
而我这边呢？同样以“多维表格”为对象，我的 Skill 覆盖了一整个业务系统需要的全部链路：
| 我的 SKILL 的能力 | 类型 |
|---|---|
| AirScript 脚本 / 按钮 / 任务脚本 / webhook | 业务逻辑 |
| SDK 内嵌（iframe 挂载 / 宿主交互 / 事件监听） | 界面层 |
| 静态 HTML / React 自定义前端（Dashboard） | 界面层 |
| 浏览器扩展（MV3 全链路） | 客户端 |
| DbSheet HTTP 直连（不写脚本直接增删改查） | 数据面 |
| 高级权限（Permission2 / 角色 / 细粒度权限） | 权限层 |
| 视图分享权限（开分享 / 指定人 / 导出审计） | 权限层 |
| 自动化流程（chatflow / 按钮绑定 / 启停） | 自动化 |
| 统计字段克隆（批量生成按月统计列） | 数据加工 |
| 公式编写（结构化引用 / LET / LAMBDA / XLOOKUP） | 数据加工 |
| 筛选 / 字段读写 / 级联 / 附件 / 联系人 | 数据面 |
| 结构分析（表 / 视图 / 字段 / 按钮 / 自动化） | 分析 |
官方给你的是“读写数据的遥控器”，我给你的是“从界面到权限到自动化到交付的整条产线”。
三、第二层差异：一次登录，长期复用 vs 每次从头开始——这就是“省 token”的秘密
有读者敏锐地发现：用官方的 Skill，token 消耗得像流水一样，没完没了。 为什么？
因为官方那套是纯 API 封装，它有几道绕不开的“消耗”：
- 每次操作都要走一遍鉴权流程，会话建立、SID 解析、接口调用，每一步都在烧 token；
- AI 每次都要现场读长文档——官方要求“使用前必须先读取完整文档”，ET 指南 656 行、DbSheet 指南 733 行，AI 得先把这些读一遍才知道怎么调用，读的过程就是 token；
- AI 还要现场设计请求体——参数怎么拼、JSON 怎么构造，让 AI 边想边写，反复试错，token 自然哗哗地流。
而我做这套 Skill 的时候，把这些“每用一次就要重新烧一遍”的东西，全部提前烧完了。
- 登录态三级回退：① 环境变量里已有登录态直接用；② 有浏览器会话在跑，直接读它的 Cookie，不重启、不打扰；③ 没有的话，自动启动带已登录 profile 的浏览器，读磁盘上持久化的登录凭证——只有从没登录过的那台机器，才会弹一次登录窗口。之后一直复用，不重新登录、不重复鉴权、不再烧登录的 token；
- 所有常用操作固化成确定性脚本：
python ./scripts/py/invoke_wps_dbsheet_http.py ...，一条命令就是一个完整动作，AI 不用现场读几百行文档、不用现场设计请求体，照着调用就是，能省一次是一次； - 33 篇主题路由 + 实测结论：AI 拿到你的需求，直接命中对应文档看结论，不用把官方文档从头扫到尾。
这就是我常说的“把试错成本填平”——该烧的 token，我早就在开发的时候替你们烧完了；你们用的时候，一分冤枉钱都不花。
四、第三层差异：官方明文“禁止浏览器”，我偏把浏览器这关死磕到底
这是我觉得最有意思的一个对比。
官方的 SKILL，第一条强制规则就是：
“禁止使用浏览器操作云文档”——对 kdocs 链接，禁止用浏览器做任何操作，所有操作必须且只能通过 API 完成。
为什么？因为浏览器自动化难、容易翻车、不可控。官方选择绕开它。
而我的态度恰恰相反：你越说不行，我越要把它做成。 因为我知道，业务系统的很多场景，光靠 API 根本走不通——脚本管理、权限核对、登录态、视图分享审计……这些全在浏览器这层。
所以我硬是把浏览器自动化做成了这套 Skill 的底座之一：
- 17 款 Chromium 内核浏览器全覆盖：Edge、Chrome、Chromium、Brave、Vivaldi、Opera、Yandex、Arc，加上国产的 360 安全 / 极速、QQ、搜狗、百度、2345、夸克、UC——你电脑上装的是哪款，它就用哪款，不挑食；
- 跨平台：Windows、macOS、Linux 一套脚本通吃，浏览器注册表、进程名、User Data 目录、自动化 profile 位置，全部收敛在一个模块里；
- 自动化专用隔离 profile：登录态持久化绑定，跟你的日常浏览器互不干扰，安全干净。
官方说“别碰浏览器”，我说“浏览器这关我替你趟平了”。 这就是两种做事哲学的分水岭。
五、第四层差异：实测验证 vs 文档封装——数字不会说谎
语言会夸大，数字不会。我把两边摊开给你看：
| 对比项 | 官方 Skill | 我的 Skill |
|---|---|---|
| 参考知识库 | 2192 行文档（含 ET/AP/kdocs 全部模块） | 33 篇路由 + workflows，合计 12245 行 |
| 自动化脚本 | dbsheet.py 969 行 + CLI 1521 行 | scripts/py 下 20 个可执行脚本，14929 行 |
| 子命令覆盖 | 约 20 个 CRUD 命令 | 脚本、SDK、HTTP、权限、自动化、导出、脚手架…… |
| 示例工程 | 无 | 4 类完整可运行工程（纯 HTML 嵌入 / 静态 Dashboard / React Dashboard / 浏览器扩展） |
| 实测证据 | 文档型（无实机结论） | SDK 兼容性矩阵真实页面存档 + 跨平台 mock 测试 + 真机回归 |
| 跨平台 | 仅限 Python 环境内 | Windows / macOS / Linux 三端通吃 |
| 浏览器 | 禁止使用 | 17 款 Chromium 内核浏览器探测与选择 |
12245 行参考知识，是什么概念？ 那是我在真实文档上一遍遍跑、一遍遍踩坑、把每一个坑都写成“别这么写”的结论——每一个坑，都是拿真金白银的 token 和数不清的深夜换来的。
写一个字段宽度，别人以为传个数字就行——我实测发现 fieldWidth 单位是“字符”、field.Width 单位是“缇”，不能直赋，得做转换，这个坑写进了知识库，AI 从此不再掉进去。
建一张表，别人以为调个接口就行——我实测发现 fieldWidth 可能失效，必须事后扫 View.Fields 补 Width，这个坑也写进了知识库。
这些细节，官方不会告诉你，官方也不屑于告诉你。 而我觉得，每一个“你迟早会撞上”的坑，都值得我提前替你撞一次。
六、第五层差异：交付物——官方给你命令，我给你成品
最后说说“你拿到手的是什么”。
官方的 Skill，你拿到手的是一堆命令：get-schema、list-records、create-records……AI 拿着这些命令，帮你操作云端表格。它是一套工具，不是一个作品。
我的 Skill，你拿到手的是整套交付能力：
- 想要个业务系统？React Dashboard、静态页面、纯 HTML 单文件，三种形态随你选，AI 直接生成可运行的前端工程，多维表格当数据后端；
- 想在网页里挂一张能交互的多维表？SDK 内嵌，内联 1.1.20 版本，打开即连真实数据；
- 想做个浏览器插件？生产级 MV3 扩展示例，主世界桥接、批量写入、二维矩阵，字段名替换成你自己的就能复用；
- 想对外分发？LicenseId、水印、授权追踪，我连交付规范都替你备好了。
同样是对着多维表格说话：官方让 AI“帮你操作表格”，我让 AI“帮你把系统做出来”。
写在最后
写这篇对比，不是为了贬低官方——官方的 Skill 有它的定位：安全、受控、够用，这没错。
但我想让你看见的，是另一种可能：
当别人在“够用”的标准上止步时，有人愿意把一个 API 封装，做成一套覆盖权限、自动化、界面、交付全链路的业务系统平台；愿意把每一个坑都提前踩平，把每一分 token 都替你省下来；愿意为一个“小众”的多维表格，写下 12245 行踩坑笔记、14929 行自动化脚本。
这就是我做事的标准：不是“能用就行”，而是“用起来舒服、用起来省、用起来有底气”。
多维表格不是一个多稀罕的东西，但把多维表格做成业务系统这件事，值得被认真对待——因为它是业务人员离“自己掌控系统”最近的一条路。
这套 Skill 背后的心血，如果你感受到了，请把它转给身边做业务系统、做数据管理、想用 AI 搭建系统的朋友。让更多人知道：在 AI 编程这条路上，有人愿意替你死磕到底。
公众号：Excel催化剂 | 微信：190262897 | 承接数据咨询解决方案、软件功能定制、AI编程培训服务等