我用 WorkBuddy 造了个工作台，踩了 12 轮坑才修好一个"数据自己翻倍"的 Bug

一次真实的资料库 + 数据表 + 双向同步项目复盘。附完整避坑清单。

一、先说结论：这次任务烧了多少积分，为什么

用 WorkBuddy 做了个"个人办公工作台"（在线 HTML + 三张数据表 + 双向同步），用户不满意返工两轮。

翻 ~/.workbuddy/workbuddy.db 的 session_usage 表，逐次消耗是：

再拆开看 jsonl 里的 usage：

最扎眼的一个数字：355 次模型调用，274 次单次输入超过 20 万 token。

问题不在某一次输出太多，而在上下文只增不减。看增长曲线：

从 3.8 万一路涨到 62 万，再靠压缩回落——每一次工具调用都要把整个历史重新喂一遍。这就是积分曲线陡峭的原因。

二、最大的坑：数据自己翻了 9 倍

用户没报这个 bug，是我截图验证时眼尖发现的：线上"把 Q3 增长方案的结论页写完"重复出现 3 次，查数据库发现任务表被写到了 112 条（应该是 12 条）。

根因链条

原页面的同步逻辑是这样的：

四个问题叠在一起：

1. 用标题当主键 —— 示例数据里有好几条同名任务，合并时互相覆盖
2. 每个标签页都 seed 一份示例数据 —— 浏览器开了 4 个标签页，就有 4 份
3. 示例数据没有"我是示例"的标记 —— 推送时不知道该跳过
4. 代码里存在两套示例标记 —— 原作者用 _s，我一开始用 sample，推送判断和打标逻辑对不上

结果就是：4 个标签页 × 12 条示例数据，各自 addRecord 往云端写。

修法（核心就一句话：别用内容当主键，用记录 ID）

配套三件事：

验证方式（这个必须做）

光看代码不够，得造出触发条件：

结果：4 个并发标签页压测后，云端仍是 12/4/3，零重复。

顺带修掉一个更危险的：原来的 doPull 里有一段"云端没有就反向删云端"。多设备下这会导致 A 删了、B 把删除撤销，然后 B 又把别的记录删掉——两边互删。已改成只由用户删除动作触发远端删除。

三、其他踩过的坑

1. 锚点对不上，改用断言式构建脚本

用正则批量改一个 20 万字符的单文件 HTML，锚点空白差异就悄悄改失败、产出坏文件。改成每步都断言命中数：

锚点不匹配立刻炸，而不是产出一个坏页面让你去 debug。

2. 页面质量 lint 的 PQ001 / PQ005 是误报

• PQ001（括号不配平）：它的正则字面量剥离器把模板串里的 </b> 当成正则起始，计数就乱了。node --check + 自己写的括号平衡计数器（剥离字符串/模板串/注释/正则）验证为 0
• PQ005（XSS 风险）：它看不穿模板串内部逐个 esc() 的转义。逐个数据出口扫一遍，未转义出口为 0 才敢声明误报

误报也要写清楚理由再 ack，不能糊过去。

3. 无头浏览器不可用时，用"本地服务 + 真实浏览器 + 截图"验证

这台机器没装 playwright/puppeteer。替代方案：

再配合桌面截图看真实渲染。比纯静态代码检查可靠得多——我就是在截图里发现数据重复的。

4. 截图会拍到全屏

截图工具默认抓全屏，把微信聊天窗口也拍进去了。必须用 --region 精确截页面区域。

四、省积分的实操清单

按性价比排序：

第一条最关键。上下文是复利增长的：第 50 轮的每次输入是第 1 轮的 10 倍。 手上正在做的事写完就 /clear 或开新对话，是最省积分的习惯。

五、最后

这次返工根本原因是我没先读需求就去找"同款"克隆，结果用户要的「周视图·日历排程」源页面里根本没有（只有复盘页的"本周/上周"偏移），配色也完全不对——白底，用户要深色。等于先白干一遍再重做。

先读需求逐条列清单，再决定用不用现成方案。 这一步能省掉的积分，比任何省积分技巧都多。