WorkBuddy 更新日志全量台账：97 个版本、1,309 条改动里，57.8% 是修 bug，而 19 个版本连发布日期都没写
一、先说结论：五个数字
2026 年 10 月 15 日 18:0x，我把 WorkBuddy 官方更新日志整页抓下来做了结构化解析，回答一个很少有人问的问题：如果你想把 WorkBuddy 当生产工具用，它的更新历史到底能告诉你什么？
先放五个数字：
- 97 — 日志页里的版本条目总数（含 4.x 与 5.x 两代）
- 1,309 — 这 97 个版本下的全部改动条目数，一条不漏
- 57.8%（756 条）— 以「修复」开头的条目占比
- 15.0%（196 条）— 以「新增」开头的条目占比
- 19 — 标题里完全没有发布日期的版本数量
换句话说，这家产品一年多里写下的每一条改动，超过一半是在收拾前一版留下的坑。而更值得注意的是：这 97 个版本里，有 19 个版本的标题只有「X.X.X 版本发布 🚀」，连日期都没标——你无法从日志判断它们是什么时候发布的，也无法把它们排进一条可靠的时间线。
下面是日志页顶部的真实样子，5.7.7 到 5.7.0 一字排开：
二、口径说明：这篇文章怎么算出来的
先把方法讲透，否则下面的百分比都可以被质疑。
唯一数据源：workbuddy.cn 更新日志页，2026-10-15 实测 HTTP 200 / 178,473 字节。全文解析，未抽样。
解析方式：该页是 VitePress 生成的静态文档，正文由 97 个
版本标题加若干
列表项组成。我按
分类口径：按每条改动开头前 4 个字符归类——修复 / 新增 / 优化；三者都不匹配的记为「其他」。这是可复现的机械规则，不涉及主观判断。
已知局限（先声明，避免过度解读）：
- 「其他」类共 138 条（10.5%），其中不少其实是新增功能的另一种写法（如「海外版新增 Gmail 连接器」「定时任务页面焕新」），机械规则会漏判，因此「新增」的真实占比应高于 15.0%，本文按机械口径给出下限。
- 官方未提供下载页的历史数据，本文无法验证这 97 个版本是否等于客户端实际发过的全部版本。
- 4.x 段有 19 个版本无日期，因此版本号排序不能等同于时间排序。
三、核心发现一：修复是新增的近四倍
把 1,309 条改动按类型摊开：
| 改动类型 | 条目数 | 占比 |
|---|---|---|
| 修复 | 756 | 57.8% |
| 优化 | 219 | 16.7% |
| 新增 | 196 | 15.0% |
| 其他（机械规则未匹配） | 138 | 10.5% |
修复 : 新增 = 756 : 196 ≈ 3.9 : 1。 这个比例在两个大版本里高度一致：4.x 段修复占 55.7%，5.x 段修复占 59.3%——跨代没有变化。
如果把「其他」里的新增类条目按语义回捞（这部分未在表中重算，仅作定性说明），修复与新增的实际差距会比 3.9:1 更大，但方向不会反转。
这个比例意味着什么？一条 AI 办公产品要同时处理：本地文件读写、浏览器自动化、云端任务调度、移动端推送、第三方连接器授权、企业权限模型。每一条都是新的失败面。而 57.8% 的修复占比说明，产品处于「功能扩张速度快于稳定性收敛速度」的阶段。
对使用者的直接含义：不要把更新日志当成产品能力说明书，要当成稳定性风险清单。 当你考虑是否升级到某个版本时，真正该读的是那 71 条「修复」都在修什么，而不是那 19 条「新增」加了什么。
四、核心发现二：19 个版本没有日期，最长一整代几乎全是无日期条目
第二个发现更扎眼：97 个版本里只有 78 个带发布日期，19 个版本的标题里没有日期。
这 19 个无日期版本是：4.8.2、4.8.3、4.9.1、4.9.2、4.9.3、4.9.6、4.10.0、4.10.3、4.21.0 之后的 4.22.4、4.22.5、4.22.7、4.22.10、4.22.11、4.22.12、4.22.14、4.22.15、4.22.16、4.24.0、4.24.1。
它们几乎全部集中在 4.8 → 4.24 这一段。下面这张图就是证据——4.22.12、4.22.11、4.22.10、4.22.7、4.22.5 五个版本的标题后面，括号是空的：
这带来三个实际后果：
- 无法构建可靠时间线。 4.22.4 和 4.24.8 谁先谁后，日志本身没说。版本号只能当作排序线索，不能当发布日期用。
- 无法做回滚决策。 生产环境出问题时，管理员需要知道「降级到哪个版本是安全的」。无日期意味着你无法把这个版本和某个已知状态对应起来。
- 审计口径失效。 如果企业合规要求「记录软件变更时间」，这 19 个版本在日志层面无法自证。
需要说明的是：带日期的 78 个版本同样不能直接当真实发布时间用。它们之间存在同日多发的情况，例如 4.24.8 与 5.0.0 同为 2026-06-03、5.1.2 与 5.1.3 同为 2026-06-17、5.4.7 与 5.5.0 同为 2026-09-01、5.5.5 与 5.5.6 同为 2026-09-10。官方文档日期 = 文档撰写日期，客户端实际推送时间可能不同，本文无法验证后者。
五、核心发现三：版本号跳号，说明存在未公开的中间版本
第三个发现来自版本号本身。97 个版本号里，存在大量断号：
| 版本系列 | 实际存在的修订号 | 缺失的修订号 |
|---|---|---|
| 4.5 | 0, 2, 6, 8, 10, 12, 14 | 1, 3, 4, 5, 7, 9, 11, 13 |
| 4.22 | 4, 5, 7, 10, 11, 12, 14, 15, 16 | 1, 2, 3, 6, 8, 9, 13 |
| 5.3 | 3, 5, 6, 7, 8, 11, 12, 13, 14 | 1, 2, 4, 9, 10 |
| 5.7 | 0, 2, 3, 5, 6, 7 | 1, 4 |
4.5 系列从 4.5.0 直接跳到 4.5.2，中间 8 个修订号在日志里根本不存在（以当前最大修订号 14 为界）。
有两种解释，本文无法区分：
- 可能性 A：这些版本真实发布过，但改动太小或内部使用，日志未收录。
- 可能性 B：修订号被跳号分配（内部构建号与发布号分离），版本号与实际发布节奏不严格对应。
无论哪种，对使用者的影响相同：你不能假设「我升到了 4.5.14，就意味着 4.5.1 到 4.5.13 的所有改动我都有了」。 这与 4.10 之后直接跳到 4.21 的情况一致——4.10 系列停在 4.10.4，下一个出现的系列是 4.21，中间的 4.11 到 4.20 整段在日志里不存在。
六、核心发现四：两次大版本交替，都由超大单版本承担
第四个发现关于「一次发多少」。把条目数排序，最大的十个版本是：
| 版本 | 条目数 | 是否为该系列首个版本 |
|---|---|---|
| 5.1.0 | 71 | 是 |
| 5.3.11 | 57 | 否 |
| 4.22.4 | 55 | 否 |
| 5.3.3 | 51 | 否 |
| 5.1.1 | 46 | 是 |
| 4.22.12 | 45 | 否 |
| 5.2.6 | 43 | 否 |
| 4.21.0 | 43 | 是 |
| 5.6.0 | 41 | 是 |
| 4.24.2 | 41 | 否 |
中位数版本只有 10 条改动，而 5.1.0 一次发了 71 条。 也就是说，最活跃的一次发布，改动量是中位版本的 7 倍。
5.1.0 是全台账改动最多的版本，它的内容几乎是一次「能力总表」：新增 Skill 工具、团队工具目录、云服务、MCP 插件、自定义技能等一整套东西，同时修了两位数的老问题。这张长图是 5.1.0 的完整 71 条：
这类「大版本一次性堆大量变更」的发布方式，对生产环境是有风险的：你无法把 71 条改动拆开灰度，也无法在出问题时精确定位是哪一条引入的回归。
七、核心发现五：8 条修复文案在不同版本里重复出现
这是一个更细的观察。我把 756 条「修复」条目按文案完全一致做了去重，结果发现有 8 条文案在两个不同版本里各出现一次：
| 重复出现的修复文案 | 出现的版本 |
|---|---|
| 修复完全访问权限会话仍走沙箱执行的问题 | 5.1.0、5.1.1 |
| 修复后台任务消息到达时强制切换会话页面的问题 | 5.1.0、5.1.1 |
| 修复 Windows 下 file:// URI 解析错误导致的腾讯文档预览空白 | 5.0.2、5.1.0 |
| 修复 Windows 小窗口下欢迎页 Logo 与活动卡片被裁切的问题 | 4.21.0、4.22.4 |
| 修复套件 skill 嵌套目录结构无法扫描的问题 | 4.21.0、4.22.4 |
| 修复插件详情页数据解析与老版不一致的问题 | 4.21.0、4.22.4 |
| 修复自动化任务历史显示内部错误信息的问题 | 4.21.0、4.22.4 |
| 修复未安装元宝时点击”查看更多”不跳转下载页的问题 | 4.21.0、4.22.4 |
两种读法：
- 读法 A（合理）：同一个 bug 在两个连续版本里都被写了修复条目——说明第一次没修干净。4.22.4 一次出现 4 条与 4.21.0 重复，是个值得注意的信号。
- 读法 B（文档问题）：文案复制粘贴未做去重，实际只修了一次。
我倾向读法 A，因为重复集中在相邻版本（5.0.2→5.1.0、4.21.0→4.22.4、5.1.0→5.1.1），符合「回归修复」的时间分布。但这一条属于推断，官方未确认，请当作 UNKNOWN 处理。
顺带一个正面发现：756 条修复文案里，没有任何一条文案重复出现 3 次或以上。这说明大多数 bug 修一次就稳了，重复只是少数。
八、如果你是 WorkBuddy 的使用者，这份台账给出的三个动作
基于上面的数据，给出三条可执行建议：
- 升级前只读修复条目。 你的升级决策应该由「这 71 条修复里有没有你正在踩的那个坑」驱动，而不是由「这 19 条新增里有没有你想要的功能」驱动。前者影响可用性，后者只是锦上添花。
- 不要依赖日志做版本追溯。 19 个无日期版本 + 大量跳号 + 同日多发，意味着日志能告诉你「改了什么」，但不能可靠告诉你「什么时候改的」「中间跳过了什么」。企业环境请自行在客户端侧记录版本号与部署时间。
- 大版本（X.0.0）发布后建议观察期。 5.1.0、5.6.0 这类 40+ 条的版本是回归高发区，生产环境可考虑延后一个补丁版本再升级。
九、口径与未知项声明
本文全部数字来自 2026-10-15 对 WorkBuddy 官方更新日志的单次抓取与解析，未抽样。以下事项明确未验证，读者不应据此下结论：
- 客户端实际发布时间未知 —— 日志日期为文档撰写日期，与推送时间是否一致无法验证。
- 跳号版本的真实存在性未知 —— 4.5.1、4.11~4.20 等版本是否发布过，官方无说明。
- 8 条重复文案的性质未知 —— 是回归修复还是文档重复，官方无确认。
- 版本完整性未知 —— 是否存在日志未收录的版本，无法验证。
- 「其他」类 138 条的准确分类未知 —— 机械规则未匹配，其语义构成未做人工复核。
- 海外站数据未纳入 —— 本文只解析国内站 .cn；海外站 workbuddy.ai 的日志为另一份编辑口径，未做对照分析。
十、来源
| 来源 | 用途 | 实测状态 |
|---|---|---|
| WorkBuddy 更新日志（国内站） | 唯一数据源，97 版本 / 1,309 条目 | HTTP 200 / 178,473 B |
| WorkBuddy 官方文档 sitemap | 文档结构核对 | HTTP 200 / 864 B |
| WorkBuddy 官网首页 | 产品身份核对 | HTTP 200 |
| WorkBuddy 更新日志（海外站） | 双站对照（本文未纳入统计） | HTTP 200 / 34,969 B |
本文所有统计口径、解析方式与分类规则均已在上文公开，可复现。
