周一试了个新命令：bl parsex 把 193 页 PDF 变成 Markdown 和一张带页码引用的字段表

周一早上桌上摊着一份一百多页的技术规范，要抄十几个字段进表，抄完还得翻回原文对页码。这种事做久了人会麻，于是我照例去翻阿里云百炼命令行的更新日志，看到 2.7 版本新加了一组 parsex 命令，说是能把文档解析成 Markdown、还能按 schema 抽字段。顺手试了一天，记一下。

装完先更新

这组命令是 2026 年 10 月 29 日的 2.7.0 才有的。我机器上原来那版没有，bl parsex 直接报找不到命令，更新到 2.7.2 才有。装和更新都在CLI 安装页，Key 在控制台密钥管理页。四条命令都只要 API Key，不用登录控制台。

第一个意外：它不吃本地文件

帮助里写得很直白：输入必须是能访问的 HTTP 或 HTTPS 地址，本地上传不属于这个接口。所以我先花了几分钟给文档找地址，最后全用公网现成的公开文档：一份英文协议规范、两份中文行业报告、一段公开示例视频。

想清楚之后觉得这个设计也合理：不用把文件传到任何第三方网页，输入就是一个可重试可审计的地址。但本地那摞扫描件确实进不来，这点得先认。

整篇变 Markdown 只要几十秒

193 页那份，提交后第一次轮询还在处理，隔二十秒再问已经完成。回来五个计数：2696 个解析块、18 张表、2675 段、3 张图、193 页。

有个默认行为坑了我一次：Markdown 正文要在提交时声明输出格式才有，我第一次没带参数，结果里只有计数没有正文，愣了一会儿才回去翻帮助。

中文那份 63 页的研究报告跑了 286 秒，451 个块、12 张表。Markdown 里表格是活的，91 行管道表，标题层级也跟着原文走。同一份只解析前三页的话 15 秒就完事，差出约十九倍，所以现在的习惯是先切几页试跑再放全量。

还有一次不算失败的失败：拿一份 2 页的中文数据报告试表格还原，表格计数是 0。查了半天才明白那份报告通篇是图表、没有一张表。选素材前先看看文档里有没有表，这步省不得。

schema 抽字段，还带页码

第二步是给它一个 JSON Schema，告诉它要哪几个格子。它不吃原文，吃上一步解析的任务号，所以 193 页不用重新解析，换 schema 重抽也只花一次抽取。

回来的字段值我逐字对过封面页，九项被替代的旧编号一个不差。真正让我愿意把它进流程的是引用：每个字段后面跟着一串引用，每条有原文引句、页码和一个坐标框。只出现一次的字段引用很干净，一条、第 1 页、框正好罩住原文那行。

但页眉上每页都重复的字段就惨了：标题 93 条引用、作者 98 条，跨几十页。作者数组回来八项，其实是三个真人的五种写法混排。所以引用是"去哪核对"的锚，不是"核对完了"的结论，进表前还得按页去重、数组去重。

它不编造，这点我专门验了

我故意在 schema 里放了两个文档里根本不存在的字段：商品售价和首席执行官姓名。允许推断的开关关着跑一次、开着跑一次，两次结果逐字相同：都是 null、引用 0。文档里没有的东西它不替我编，至少这组对照里是这样。

三个失败形态，位置各不相同

编一个不存在的文档地址提交，submit 照样接受，到取结果时才报"地址不可用"。拿一个普通网页首页提交，它不报错，success，回来两段网页文本、零页零表，静默成功比报错更危险。视频那次更直接：帧提取参数写成布尔值被本地拦下、退出码 2 还双语指名字段，改成对象后提交成功，但取结果时报服务端取不回源文件，视频这条路我这次没跑通，不做承诺。

合起来看就是：配置形状错本地拦，地址可达性错取结果时拦，地址类型错根本不拦。管线里得自己补两道半闸。

一个容易忽略的坑

解析回来的 Markdown 里，图片是带签名的临时链接，会过期，参数里还有凭证信息。我的处理是下载自存、签名串归档前替换掉，文章和知识库里不贴这种链接。不然转发给别人，隔天就是一排打不开的图。

感受

一天下来八次解析加三次抽取。那摞规范现在的处理顺序是：给地址、parse 存 Markdown、extract 填字段表、复核的人拿页码翻原文、数组去重一次进表。翻和抄两件事没了，对页码变成拿引用翻原文，快很多。

不适合的地方也清楚：本地文件进不来；只要全文的话一步 parse 就够，不必上 schema；要即时回答的对话场景别用，它是异步的。

要说还缺什么，缺的是对"输入不对"的表达：网页当文档、图表当表格，它都照收不误。所以白名单和素材预检不是可选项，是这条管线的前提。