100 份 PDF，建一份能搜的 Markdown 索引
实测于 2026-11-14 · 数字来自一次真实运行
这一页的运行记录来自一次真实运行，不是估计值。token用量没采集到就写「未采集」，不填数字。
适用场景
一个文件夹里堆着上百份PDF，文件名看不出内容，想按主题找得到。
准备
- 宿主版本
- 0.1.2-alpha.5
- 模型
- 待填
- 模式 / 权限
- --profile headless / workspace-write / Windows 11 / node 22.22.2
- 需装插件
- 无（如用到插件，在实测后补齐名称与版本）
- 输入材料
- 自造100份PDF（每5份1份无文本层），本次只跑前10份（按文件名排序，000–009）
完整指令
扫描【目录】下所有 PDF，给这个文件夹建一份 Markdown 索引。
每条记录写：文件名、一句话说明这份文件讲什么、从原文摘出的 3 个关键词、最后修改时间。
按主题分组，同主题下按时间倒序。
要求：
1. 一句话说明必须来自正文，不要根据文件名猜。读不到正文的，标注「读取失败」并单独列一节，不要跳过。
2. 先打印前 10 条给我确认格式，我确认后再写完整索引。
3. 索引保存为 索引.md，不要改动任何原始 PDF。
4. 最后报告：处理了多少份、成功多少份、失败多少份、失败原因各是什么。运行记录
| 项目 | 数值 | 备注 |
|---|---|---|
| 耗时 | 1分22秒 | 2026-11-14 |
| 结果 | 处理10份 / 成功8 / 失败2；产物index.md 3,736字节；原PDF一个未改 | |
| 输入 / 输出token | 未采集（headless输出不打印用量） | |
| 残留 | 无残留。 |
实测发现
- 「说明必须来自正文」这一句是有效的：它主动发现并标注了「文件名写冲泡参数、正文却在讲仓储地点」的矛盾，没有跟着文件名编。
- 失败的两份没有被跳过，而是单列一节，还给出页数、图像尺寸（80×80像素）、有无嵌入字体、有无注释附件，并说明本机无OCR可用。
- 它自己把跑过程中的临时脚本清理掉了，工作区只留下index.md——这一点不是配方要求的，属于它的自发行为。
- 8份可读文件的正文是同一模板，它照实写了「说明高度重复，这是原文如此，不是偷懒概括」。
教训（造数据时踩到的）：用PyMuPDF的insert_text写中文而不指定CJK字体，会静默写入占位符0xB7，抽出来是「····」。第一次跑就是因为这个，10份全被判「读取失败」——而它没有编造，直接报告了失败，这反而验证了配方在坏数据上的行为是对的。
产物
跑通后在这里给出文件清单与截图，并说明原始文件有没有被改动。
验收清单
点一下可勾选，用来逐条核对。
- 索引.md已生成，且原始PDF一个都没被改动
- 每条的一句话说明能在原文找到对应内容
- 读不到的文件单独列出，没有被静默跳过
- 处理总数 = 成功数 + 失败数
失败与边界
- PDF是扫描件时，没有文本层就读不出正文，会集中落在「读取失败」一节
- 目录层级很深或文件数上千时，先小范围试10份再全量跑