对话档案 D13 · 小任务合辑：文档转换与整站长图（11-11）
一句话：一晚上两个「顺手做掉」的小任务——把微信里收到的 Word 转成能进站的 Markdown，把网页截成一张图——前者靠「转不了就截图」的妥协收场，后者被反复用到第三次，最终被抽成了一个可复用的 skill。
一、这段对话怎么走的
两段独立会话，都在 11-11 晚上，前者 21:06 开始，后者 21:27 开始，前后脚。任务性质完全不同：一个是一次性数据加工，一个是工具化。
| 阶段 | 用户要求 | 产出 | 卡点 |
|---|---|---|---|
| 1 文档转换 | 「表格法.doc 转化成 markdown 格式，公式要用美元符号包裹」 | 表格法.md（8999 字节、20 处图片引用、95 个 $…$ 公式） | .doc 是旧二进制格式；原表含合并单元格与斜线表头，Markdown 表格结构上还原不了 |
| 2 兜底方案 | 「对于无法转化的格式，尝试使用截图的方式吧」 | 表格法_原表截图/table01–table20.png 共 20 张；正文改为「所有表格均以 Word 原版截图呈现」 | 截图会丢可检索性，需在文首显式声明取舍 |
| 3 清理 | 「把原来的错误表格删掉就好了」 | 删除转错的表格块，保留截图 | 用户选择删而不是修，说明「正确但不可编辑」优于「可编辑但错误」 |
| 4 网页长图 | 「截图这整个网页，生成一张长图」（/notes/note/cmwc5i7qo0001t516bhe6fdyq/） | 整页长图 PNG | 固定顶栏、懒加载图片、动画导致拼接重复或空白 |
| 5 手机版 | 「同样的方法截图一下手机版效果」 | 390 宽视口长图 | 视口切换后布局重排，需重新预热滚动 |
| 6 工具化 | 「写一个skill，给定网站，截图全网站生成一张长图」 | C:/Users/cag/.workbuddy/skills/site-longshot/：SKILL.md + scripts/capture.mjs + references/troubleshooting.md；支持 --check 自检、单页整页、--max-pages N 同域 BFS 多页纵向拼接 | 不依赖 sharp/Pillow/ImageMagick，改用浏览器 canvas 拼接 |
| 7 复用 | @skill:site-longshot + 另一篇笔记 URL | 带 20 张图的笔记整页长图 | 图片懒加载必须靠预热滚动触发 |
文档转换那一段值得细看。.doc 里的表格不是普通表：Punnett 方阵有跨行跨列、有斜线表头、有底色。转成 Markdown 管道表，合并信息全丢，读者看到的是错位的格子。用户没有要求「想办法还原」，而是直接给了退路——「转不了的用截图」。于是正文变成「文字与公式是文本、表格是图」的混合体，文首加了一句说明：「原表含合并单元格、斜线表头等结构，Markdown 表格无法还原其排版，因此所有表格均以 Word 原版截图呈现。」这句话把技术妥协变成了对读者的诚实交代。
工具化的触发点很清晰：同一件事做到第三次（正文页、手机版、另一篇笔记），就抽 skill。capture.mjs 的做法是「预热滚动触发懒加载 → 冻结动画与 fixed/sticky 元素 → fullPage 或分段截取 → canvas 纵向拼接」，输出 PNG 加一行 JSON 报告。全程不装图片处理库，这对一台已经装了 Node 和 Playwright 的机器来说，等于零成本扩展。
二、用户的关键原话
「@"…/2026-11/表格法.doc" 转化成markdown格式，公式要用美元符号包裹。」
一句话两个约束：格式（Markdown）、公式定界符（$…$）。后者不是随口说的——站点用 remark-math + rehype-katex 渲染，$…$ 才能出公式；写成 \(…\) 或图片公式都会退化成纯文本。给目标格式时把「目标系统的方言」一起说清，是这条指令高效的原因。
「上面的格式转化，对于无法转化的格式，尝试使用截图的方式进行吧。」
这是全段最关键的一句。它把「完美转换」的目标改成了「可用转换」，直接终止了在表格还原上的无底洞。工程上很多任务的成本失控，就失控在「不肯承认某一小部分做不到」。
「把原来的错误表格删掉就好了。」
七个字，没有追问原因、没有要求修复。用户对「错误产物」的处理偏好是删除而非修补——这也解释了后续为什么 versions 页要做「只留当前版」的批量清理。
「写一个skill，给定网站，截图全网站生成一张长图。」
从「帮我截这张图」到「写个 skill」，是一次明确的资产化动作。注意它没说验收标准，模型自己补了 --check 自检和 JSON 报告——这是 skill 化的隐性要求：能被下一个会话在不知道上下文的情况下直接用。
三、成本与效率
两段合计 2588 万 token（2130.8 万 + 457.1 万），10 条用户消息，283 次工具调用。
- 文档转换段：2130.8 万 / 7 条消息 = 每条 304 万；202 次工具 = 每次 10.5 万。202 次工具主要花在逐页解析
.doc、逐张截图、逐处校对公式上。 - 长图 skill 段：457.1 万 / 3 条消息 = 每条 152 万；81 次工具 = 每次 5.6 万。写 skill 本身不贵，贵在反复试截图参数（视口宽、等待时长、拼接缝隙）。
按产出折算：20 张截图 + 95 个公式 + 9000 字正文，约 2130 万 token；一个可复用 skill 约 457 万 token。后者的性价比明显更高——skill 在当晚就被第二次调用（带 20 张图的笔记页），之后每次截图都不再需要重新探索参数。
四、曲折点与评判
1. 表格还原的结构性失败（★★★☆☆） 不是实现不好，是格式本身不兼容：Markdown 管道表没有合并单元格概念。尝试过的路径（转成 HTML 表、用占位符保留合并）都会让正文变得不可读。最终「截图 + 文首声明」是正确取舍，但代价是这 20 张表永远无法被检索、无法被复制、无法在手机上横滑查看——这个债在两天后的「表格系统」里才真正还上（站内表格支持合并、逐边边框、可复制到 WPS）。回头看，D13 的失败恰好是 D11 表格功能的现实需求来源。
2. 长图的三个技术坑（★★★★☆）
固定顶栏会在每一段拼接处重复出现；loading=lazy 的图片不预热滚动就是空白；CSS 动画会让同一区域两次截取结果不同。解法是「先滚一遍触发加载 → 注入样式把 position:fixed/sticky 改成 static、animation/transition 全关 → 再截」。这三个坑任何一个不处理，长图都会出现「顶栏刷了十遍」或「中间一段全白」。写进 references/troubleshooting.md 之后，下一个会话不必再踩。
3. 手机版不是「换个宽度」（★★★☆☆）
390 宽下布局重排，原本两栏变一栏、导航变底栏，同一个 URL 的截图高度可能差一倍。必须重新设视口、重新预热、重新量高度，不能复用桌面版的坐标。这条经验后来直接用在 D11 的手机端巡查（9 个页面 390×844，断言 scrollWidth-clientWidth = 0）。
4. 顺手改的贴纸按钮（★★★☆☆）
同一段会话末尾插了一条「贴图的旋转按钮会被选项条覆盖，修改一下，改成竖着的选项条」。根因是 .sticker-tools 横条从右侧向左延伸，贴纸较窄时压住顶部居中的旋转把手。改法是竖排挂右侧外部，并把 place() 的视口补偿从只 translateX 改成同时处理垂直居中。小需求、真 bug、当场修完——这类「顺手」在 11 月出现了十几次，构成了产品打磨的主要来源。
五、提示词与流程改进
反例：「把这个 Word 转成 Markdown，尽量还原格式。」 「尽量」没有终点，模型会花大量 token 尝试还原合并单元格，最后交出一份结构错乱、读者看不懂的表。
正例：「转成 Markdown，公式用 $…$；结构还原不了的（合并单元格、斜线表头）改用原表截图，并在文首说明取舍。」一次说清「能转的转、不能转的截图、并把取舍写进正文」，成本立刻收敛。
反例：「帮我截个长图。」
正例：「截 https://…/note/xxx/ 整页长图，390 宽再来一张；固定顶栏不要重复、懒加载图要全部加载出来。」把已知的三个坑写进指令，比让模型自己撞一遍省一半 token。
反例：「这个功能做成工具吧。」
正例：「写一个 skill：给定 URL 输出整页长图；不带参数是单页，--max-pages N 是同域多页拼接；带 --check 自检依赖；输出 PNG + 一行 JSON 报告。」接口、参数、自检、输出格式四件齐了，skill 才能被别的会话直接调用。
六、可复用结论
- 格式转换要先问「目标系统吃什么」。
$…$这种方言细节，比「转成 Markdown」这句更重要。 - 允许一部分做不到，是控制成本的手段。 「转不了就截图 + 文首声明」比死磕还原便宜一个数量级，而且对读者更诚实。
- 同一操作第三次出现就抽成 skill。 457 万 token 买一个带自检和故障手册的工具，当晚就回本。