# 【实战避坑】WorkBuddy 办公实战心得：从反复翻车到沉淀技能，AI 同事如何帮我维护 10MB 单文件汉字识字工作台

最近深度使用腾讯 WorkBuddy 做一件"吃力不讨好"的事——维护一个 10MB+ 的单文件 HTML 汉字识字工作台（给小朋友认字用，内含 1170 个生字配图、多册课文数据）。本以为"让 AI 改几个字"是分钟级小事，结果一路踩坑、反复翻车，硬是把一次"小改动"做成了一场工程复盘。本文把真实的痛点、翻车现场、Prompt 写法和最终沉淀成技能的过程摊开讲，希望能帮到做"重文件 / 教育类内容生产"的伙伴，也聊聊积分消耗的误区。

一、场景一：10MB 单文件改一字配图，整文件回写直接翻车（大文件 + CRLF 双坑）

痛点： 工作台主文件 10MB+，要批量替换/修正几十个生字的 base64 配图。我第一反应是用 Python 读全文 → 改 → 写回。结果① WorkBuddy 的 Python 沙箱读 >10MB 文件直接被强杀（exit 1，无任何输出，连报错都看不到）；② 即便绕过沙箱，用"字符串读 → 替换 → 字符串写"整文件回写，会把全文件的 CRLF 换行全部变成 LF。单文件 HTML 的渲染脚本依赖精确字节，CRLF 一变，部分逻辑就错乱。

实战 Prompt：

用 Node 字节级注入：只替换一下册"霜哭借"等 49 字的 GLYPH_PNG 配图，其余字节原样保留，且全文件 CRLF 换行数前后必须相等。注入后做冒烟测试：括号计数确认无 SyntaxError。

解决：

• 大文件一律改用 Node fs.readFileSync 做字节级操作。UTF-8 多字节序列不含 ASCII 引号/括号字节，按字节匹配是安全的。
• 从 CRLF 备份出发，用 data.find(start_b) / data.find(end_b) 定位要改的块，只对该字节块做 Buffer.replace，其余 CRLF 原样保留；改完用脚本核对 CRLF 计数前后相等。

前后对比： 整文件回写 → CRLF 全变 LF、偶发文件损坏、调试无头绪；字节级注入 → CRLF 计数守恒、未改动区零影响、一次到位。

二、场景二：配图注入"假成功"——双 GLYPH_PNG 陷阱与双层数组坑（数据结构雷）

痛点： 注入配图后页面却不显示图。排查发现：渲染代码只读全局 const GLYPH_PNG，而我把图误注入进了 DICT_DATA.GLYPH_PNG（一段惰性数据，没有任何代码引用）——忙活半天是"注入到了没人读的地方"。另一次，写 '"xiezi":' + json.encode() + b']' 时，末尾多余的 ] 和 JSON 自带的 [...] 叠加成 [[...]] 双层数组，解析直接崩。

实战 Prompt：

注入前先 grep -c 'data:image/png;base64,' 数全局字典配图数量；确认配图只进全局 GLYPH_PNG；数组序列化不要手拼括号，统一用 JSON.stringify / JSON.parse。

解决：

• 立纪律：配图必须注入全局字典，不是 books 里的惰性字段。
• 数组 JSON 一律用 JSON.stringify / JSON.parse，绝不手拼 ]。
• 验证正解：提取整个 DICT_DATA JSON.parse + 全 script 块 new Function 冒烟 + 各册唯一字对全局 GLYPH_PNG 覆盖率 = 0 缺失。

心得： AI 改数据结构时，"看起来写进去了" ≠ "写对了地方"，必须用"读回校验"闭环，而不是相信返回值。

三、场景三：红绿字 PDF 切图把拼音切进来（列检测铁律）

痛点： 用红绿字脚本把二上写字表 PDF 切成单字图，最初按"row0 的红/绿投影段锚定列边界"，结果最左两列被并进"课号框" → 漏切；或者相邻列纵向重叠、没有竖直空缝 → 两列被并成宽框。裁出来的图要么含拼音行、要么只切到字边，用户一眼就挑出 46 个字"没切好"。

实战 Prompt：

列检测绝不能用 row0 R/G 投影段锚定，也不能用全页连续段；改用列中心峰聚类（局部极大）+ 中点定边界，或直接固定七中心常量；裁切统一 X_CENTERS + 校准后的 PAGE_ROW_YS，裁 110×110 居中。

解决：

• 放弃"投影锚定"，改用"列中心峰聚类 + 中点定边界"。二上左上 1/4 实测 7 列中心固定为常量，每格宽均匀、0 合并、0 越界。
• 裁切 y 中心用校准值（原值偏低 80–110px 才会切到拼音），重切后 46 字 + 追加 3 字全部干净。

前后对比： r62 裁切 46 字有拼音残留 → r68 重切后用户核对"与目标截图一致"，一次通过。

四、场景四：本地环境连环坑——Bash 不能用、.ps1 被禁、回收站 API 被拦

痛点： 本机用户名目录含单引号 C:\Users\x'x\，WorkBuddy 的 Bash 工具彻底不可用；.ps1 脚本执行策略禁止、连 bypass 都启动不了；想用 Shell.Application COM 回收站 API 做"安全删除"，结果被安全策略拦截。

实战： 清理工作台缓存时，不能用 rm、不能走回收站。改为 PowerShell 内联命令 + 受管 Node/Python；删除用 Move-Item 先移入 _trash_日期 暂存区（完全可逆），用户确认后再用 Node fs.rmSync 永久删除。

心得： 本地系统策略是隐藏雷区，所有"删除 / 移动"操作先做成可逆暂存，比任何 -Force 都安全。

五、场景五：把踩坑变成技能——积分消耗误区的真正解法

痛点（积分误区）： 最初我习惯"让 AI 逐页用视觉模型看图转录""整文件重写"，积分刷刷掉。用户一句"只改以上有误的字，其他不动节约积分"点醒我：WorkBuddy 积分不该花在重复劳动上。

解决——沉淀技能：

• pdf-to-images：本地 pypdfium2 离线把 PDF 拆成逐页高清图，零积分。
• 红绿字：本地像素处理切单字图，零积分。
• 单文件 HTML 字节级注入流程写成可复用 SOP。

心得： WorkBuddy 的"经验变现"不在一次跑通，而在把跑通的流程固化成技能——下次同类型任务直接调用，又快又省积分。

总结与建议

核心心得：

1. WorkBuddy 极擅长"跨格式整合、固定逻辑、大批量"任务，但大文件、编码（CRLF）、数据结构（注入到哪）、本地环境是四大雷区。
2. Prompt 公式 = 角色 + 任务 + 背景 + 硬约束（如"字节级、CRLF 守恒、其余不动"），越具体的约束越能避免翻车。
3. 凡是"删除 / 大额改动"，先做可逆暂存；凡是"数据注入"，必做读回校验闭环。

对工具优化的建议：

• 大文件读写应有沙箱保护提示与字节级 patch 原生能力，避免用户自己踩 CRLF / 强杀坑。
• 技能市场增加"教育 / 汉字 / 文档处理"类官方模板，降低同类任务起步成本。
• 提供"积分消耗预估"，帮用户在"视觉模型逐页"和"本地脚本离线"之间做理性选择。