feishu-doc-scraper

飞书文档抓取器

将飞书/Lark 源内容提取为忠实的本地 Markdown。优先使用 lark-cli API——它以编程方式提取正文（不会由模型改写），沿着集合的引用图进行递归，并根据错误代码读取权限边界，而不是猜测。将浏览器渲染页面视为备用方案，而非事实来源：在实际的集合抓取工作中，API 路径总能完成全部工作，浏览器路径则完全不需要。

范围（请先阅读）

此 Skill 的约定是为每个来源生成忠实的 Markdown，并记录提取内容。命名、索引、去重和知识所有权属于接收方的归档工作流。对于归档请求（包括允许选择合适位置的请求），请先遵循归档目标交接。在目标位置尚未确定时，可以继续进行临时提取；永久归档和上传则遵循宿主选定的所有权和存储约定。

每次读取或归档文档时，都要加载评论和反馈。 它规定正文加讨论的工作流、选定范围、仅正文的例外情况、 快照命令、解读方式和覆盖检查。

提取和持久化存储是两个不同的决定。 已下载的 MP4/XLSX/DOCX/图片是工作副本，并不能证明该文件应存入 Git 或 Git LFS。对于知识库归档，默认采用：

• Git：忠实的 Markdown，以及结构化 CSV/JSON/HTML、来源定位信息、版本/权限状态、字节数、MIME 类型和哈希值。
• 平台原件：只要仍可通过稳定的文档/文件令牌检索，飞书就仍是原始二进制附件的记录来源。本地下载是可选缓存，新克隆时可以不存在。
• OSS/对象存储：仅当归档需要独立的持久副本，或者平台来源无法作为可靠的长期检索途径时使用。上传是单独授权的操作，不是由提取器自行选择的备用方案。

归档前，先在制品清单中声明这一划分，并运行随附的存储验证器。完整的架构和示例见**references/archive-storage-contract.md**。

在加载备用或读取器流程之前，根据用户要求的结果选择交付范围。对于原始文件下载，请使用 附件归档：先获取正文， 列出其中实际存在的资源类型，然后仅加载对应的处理器。分别记录正文、 附件、独立保留和读取器验收情况。仅完成附件批处理绝不代表已完成文档的引用图处理。

对于媒体导出失败、原始预览获取或 Obsidian 阅读交接，请加载 原始媒体和阅读器交接。 在扩大批处理范围前，使用其中已验证的预览下载器和 API 捕获渲染器。 其交付完成门槛（check_reader_delivery.py finalize）是阅读器交付的完成入口；转换、字节和搜索成功并不能替代当前有效的实际阅读器证据记录。 对于用户指定的个人收藏目标位置，其来源目录生成器会将任务交接给收藏搜索，而不会改变此 Skill 的归档所有权。

选择路径

Is the source a Feishu/Lark URL (wiki / docx / sheets / minutes / base)?
├── YES → is lark-cli installed and authenticated to that tenant?
│        ├── YES → PATH A: lark-cli API extraction  (primary — start here)
│        │         └── hit code 131006 / 99991679 (permission denied)?
│        │              └── PATH B: owner-exported .docx → faithful Markdown
│        └── NO  → install/auth lark-cli first (it is worth it); only if
│                  truly impossible → PATH D: browser DOM fallback
├── the URL is a Minutes / 妙记 link, or a doc references one → PATH C: Minutes transcript
└── you were handed an exported .docx (not a URL) → PATH B

⚠️ base（Bitable）目前尚未在路径 A 中实际实现——提取器只会记录令牌（DISPATCH["url-base"]：“Bitable API（不属于此 Skill）——记录令牌”），而下文的步骤 2 中没有对应条目。此处列出仅为完整说明飞书 URL 可能的类型，并不表示路径 A 能端到端提取 Bitable 内容。

集合/枢纽只是正文中引用了其他文档的 docx——路径 A 通过递归跟踪引用图来处理它，无需在浏览器中逐页访问。

路径 A——lark-cli API 提取（主要路径）

完整命令目录、递归引擎、跨租户和个人空间注意事项：references/lark-cli-api-extraction.md。常见场景的要点如下：

如果有 lark-cli-router，请通过它解析当前 CLI 命令、身份和权限处理方式；否则，请使用已安装的 lark-cli skills list 及其选中的 lark-* 指南。下方的历史示例用于说明捕获格式；如果标志、响应封装或方法有所不同，请使用已安装的指南。 对于源卡片文件，批量归档流程使用经过验证的下载命令。提供了分享密码，并不能确定当前身份是否需要通过浏览器访问；请先尝试授权的 API 读取，并遵从其权限结果。

1. 对飞书国内域名禁用代理。 在中国大陆，飞书的 *.feishu.cn 端点应直连；通过本地代理路由会导致凭据经代理泄露，并遭到 DNS 劫持。lark-cli 本身也会对此发出警告。务必：

export LARK_CLI_NO_PROXY=1

这与任何“Claude/Anthropic 域名必须使用代理”的规则并不冲突——飞书是不同的主机，应直连。

2. 判断 URL 类型，然后解析为可抓取的文档 token。

• …/wiki/<node_token> —— wiki 节点 token 不是文档 token。请先解析：

  lark-cli wiki spaces get_node --params '{"token":"<node_token>"}'
  # → .data.node.obj_token  and  .data.node.obj_type  (e.g. "docx")
  

• …/docx/<doc_token> —— 已经是文档 token，可直接抓取。
• …/sheets/<token> —— 电子表格，请使用 sheets 命令（参见参考文档）。
• …/minutes/<token> —— Minutes，请转到 路径 C。

3. 以编程方式抓取正文——绝不能通过模型抓取。 正文字段在不同版本的 lark-cli 中位置有所变化，因此请同时探测两种方式，而不要硬编码其中一种（这样无论安装的是哪个版本都能正常工作）：

lark-cli docs +fetch --doc <obj_token> --format json > /tmp/fetch.json 2> /tmp/fetch.err
# ≤1.0.32: clean Markdown in .data.markdown.
# 1.0.55: body moved to .data.document.content as HTML (.data.markdown is null).
if jq -e -r '.data.markdown // empty' /tmp/fetch.json > "<sanitized-title>.md" && [ -s "<sanitized-title>.md" ]; then
  : # got clean Markdown directly
else
  jq -r '.data.document.content' /tmp/fetch.json > "<sanitized-title>.html"
  pandoc -f html -t gfm "<sanitized-title>.html" > "<sanitized-title>.md"
fi

⚠️ <sanitized-title> 必须为每篇文档使用不同的名称，绝不能在多次抓取中重复使用字面字符串 "source"。 下方的第 4 步会将多篇文档（主文档，然后是它引用的每篇子文档）抓取到同一工作目录中——如果原样运行这段代码，并硬编码使用 source.md/source.html，第二次抓取会在你检查之前悄然覆盖第一篇文档保存的正文。本节其余部分仍会用 "source.html"/"source.md"作为简称，表示你当前正在查看其保存文件的那篇文档——而不是整个文档集合共用的一个文件名。 ⚠️ 在此 pandoc 分支上，pandoc -f html -t gfm 会悄无声息地剥除 Feishu 的若干自定义嵌入标签——已于 2026-08-16/17 对照真实文档验证，而且越深入检查，发现的问题越严重：

• whiteboard（<whiteboard token="…">，内嵌图表块）会消失得无影无踪。已在真实文档中确认：.data.document.content 中有 3 个原始标签，而 pandoc 转换后的 source.md 中没有任何痕迹（对原始 HTML 执行 grep -c whiteboard 找到 3 处，对转换后的 Markdown 执行则找到 0 处）。
• mention-doc——其真实原始标签是 <cite doc-id="…" file-type="wiki|docx" title="…" type="doc"></cite>，并非此技能最初假定的 <mention-doc token="…" type="…">Title</mention-doc> 形式——同样会消失得无影无踪，而且损失不只是 token/type：标题存放在 title="…" 属性中，标签体为空，因此 pandoc 会丢弃整个元素，甚至连单独的标题文本也不会保留下来。
• sheet 无论如何都尚未得到确认（没有找到真实的表格引用文档来测试）——在证明它不会悄无声息地消失之前，应视其也可能发生此情况。
• image——其真实原始标签是标准的 <img src="<drive-token>" alt="…" …>，而非 <image token="…">——不会消失：pandoc 基本会原样保留原始 <img> 元素（src/id/href/width/height/alt 均会保留；name= 会被丢弃；mime=/scale= 会重命名为 data-mime=/data-scale=）。
• lark-table 实际上并不是普通 docx 表格使用的真实标签——它们使用普通的 <table> HTML，pandoc 通常会完整转换（单段落单元格会转换为规范的 GFM 管道表格语法，多段落单元格则会转换为原始 <table> HTML 块）——因此不属于这种悄无声息丢失的情况。

由于这种损失确实存在且因类型而异，如果使用了此 pandoc 分支，第 4 步（提取）和第 5 步（检查残余标签）必须基于 source.html 执行，绝不能基于 source.md 执行。 如果实际响应提供了 .data.markdown，则检查保存下来的 Markdown。应根据当前响应选择分支，而不是依据记忆中的 CLI 版本；1.0.80 的 HTML 测试证明了 pandoc 会造成这种损失，但不能证明后续每个版本都会返回哪个字段。

--format markdown 不是有效值（lark-cli 会发出警告并回退到 json）。stdout 和 stderr 必须分开处理——无害的 [deprecated] 行会写入 stderr，而在实际操作中，将 2>/dev/null 和 jq 一起管道处理会产生错误的 Exit code 5。必须通过 jq/pandoc 将正文写入磁盘，绝不能由模型重新输入或概述——改写会悄无声息地破坏源文本，这是最重要的保真规则。（pandoc 只会将 HTML 结构重新渲染为 Markdown，不会改写正文——上述标签剥除属于结构损失，而非正文保真度问题；因此 source.html 必须保留在磁盘上，并作为富媒体引用的权威来源。）

4. 如果这是集合/枢纽，请沿引用图进行广度优先搜索（BFS）。 枢纽正文包含 <mention-doc>（真实原始标签：<cite doc-id="…">）、<sheet>、<image>（真实原始标签：<img src="…">）标签、<whiteboard token="…"> 块，以及跨租户 / Minutes / Tencent-Meeting URL。提取每个引用，按类型分派、获取文档，并对每个新获取的文档重复此过程，直到没有新引用为止（即遍历至叶节点）——但 whiteboard 永远不获取也不递归：它是内嵌视觉内容，不是指向其他文档的链接（见下方专门说明）。使用随附的提取器，避免悄无声息地遗漏内容（遗漏一个引用 = 缺少一个文档，这是枢纽抓取失败的首要原因）：

python3 scripts/feishu_extract_refs.py "<sanitized-title>.html"   # → JSON list of {type, ref, title, dispatch}

每份获取到的文档都运行一次——先处理根文档，再处理每个新获取的子文档——并使用该文档自己的 <sanitized-title>.html（有关命名注意事项，请参见步骤 3）。提取器会扫描引用文本并解析 source-card 标签；对于给定文档，无论使用 .html 还是 .md 都能工作，因为它只检查文件文本是否包含这些标签；但如果两者都存在，应以 .html 为准；只有在该文档从未保存过 .html 时，才回退使用 .md（.data.markdown 分支，见步骤 3）。递归循环、分派表以及跨租户和 my.feishu.cn 个人空间规则均见参考资料。

白板块不是可跟随的引用——应就地导出并阅读。 whiteboard token="…" 标签是飞书原生的图表／流程图块，内嵌在当前文档中——它不是指向其他文档的指针，因此不要像处理 mention-doc／sheet 一样尝试递归获取。必须通过视觉方式理解它：仅凭原始节点坐标／文本片段列表，无法可靠还原流程图的含义。请导出预览图并实际查看：

lark-cli whiteboard +export --whiteboard-token <token> --output-type preview --output <path>.jpg --overwrite

然后使用 Read 工具读取生成的 .jpg，查看图表的实际内容。也可以使用 --output-type raw（结构化节点 JSON——可用于交叉核对／建立可搜索索引，但不能替代查看渲染后的图像）；此外还提供 svg 和 source 输出类型。输出路径必须使用与命令实际生成格式相符的真实图像扩展名（如果实际格式是 .jpg，却指定 .png，命令会报错——扩展名要与命令报告的格式一致，或按照命令自身的 --help 省略扩展名）。默认情况下，预览图只是工作缓存：在制品清单中记录白板 token、观测到的 MIME／字节数／哈希，以及可选的缓存路径；不要在未说明的情况下将 JPEG 纳入 Git／LFS。如果持久化归档需要独立的二进制副本，应明确将其存入 OSS。这一点很重要，因为图表中经常包含文档纯文本部分没有、但与决策相关的内容——例如，泳道／流程图可能包含按角色划分的步骤和具体数值阈值，而这些内容在文档其他部分完全没有体现。如果不打开这些块就将文档视为“已完整提取”，就会悄然丢弃最可能承载其实际操作逻辑的内容。

5. 最终残留标签检查（验收门槛——每份获取到的文档都要检查，不限于集合）。 即便是没有跨文档引用的独立文档，也需要进行这项检查：内嵌的 whiteboard 或未解析的引用标签可能会出现，且完全不涉及其他文档（这正是 2026-08-16 一次实际的单文档提取中发生的情况——没有中心文档，没有递归，只有 3 个未读取的白板）。每个富媒体引用都必须已解析并渲染。请在整个工作目录中递归运行，而不是只检查单个文件——一个集合中的每份文档都有一组 <sanitized-title>.html／.md 文件（步骤 3），而 pandoc 转换后的 .md 单独检查时可能显示“干净”，但实际标签已被静默丢弃（见步骤 3 的提示），因此扫描必须覆盖磁盘上的每个 .html：

grep -rlE '<(source|file|lark-table|lark-tr|sheet token=|mention-doc|cite doc-id=|whiteboard token=|view type=)' . \
  && echo "UNRESOLVED — keep recursing" || echo "clean"

该模式中的 lark-tr 和 view type= 是预先存在、未经真实 HTML 验证的术语。它们在 feishu_extract_refs.py 中没有对应的正则表达式，也没有分派条目，因此命中这些内容时并无结构化工具支持；应视为“停止并手动检查原始标签”，而不是认为提取器已经理解这些内容。

将每个 <source>／<file> 命中项与附件 token 及已验证的本地文件逐一核对，前提是已请求原文件。提取器会保留 source-card 的文件名、大小和 MIME；缺失 token 属于 unresolved-attachment，绝不是叶节点。在检查原始捕获标签之前，不要把零引用结果等同于内容完整。 ⚠️ 对于每份文档保存的 .html，“empty” 并非字面上的停止条件——应将每个匹配项视为待办事项，而不是循环失败。 每个 <sanitized-title>.html 都是该文档不可变的原始捕获内容（获取后，此技能不会就地改写文档自身的文件——请参阅步骤 3 中有关按文档命名的注意事项），因此，确实引用了 N 份其他文档或 M 个图表的父文档，即使这些内容都已正确处理完毕，其自身文件中仍会一直显示 N+M 个匹配项——试图让整个目录中的 grep 结果字面上归零，对真正的枢纽文档来说永远不会结束。相反，对于每个匹配项，都要确认对应的产物已存在于磁盘上：mention-doc/cite doc-id=/sheet 匹配项在引用的子文档已实际获取并保存后即视为已解决（步骤 3，应用于该子文档）；whiteboard 匹配项在其预览 .jpg 已导出并通过 Read 读取后即视为已解决（步骤 4）——绝不能通过获取另一份文档来解决，它不是可跟随的引用。只有在每个匹配项都对应到经过验证的磁盘产物后才停止。（在 .data.markdown 回退分支中，获取的正文就是要交付的 Markdown，而非不可变的原始捕获内容，因此结果为空仍是更简单的信号——但目前尚未确认任何现有 lark-cli 版本能够进入该分支，请参阅步骤 3。）

路径 B — 权限被拒绝 → 文档所有者导出的 .docx

lark-cli wiki spaces get_node 返回 code 131006 … node permission denied, user needs read permission（或获取时返回该错误）意味着飞书端的硬性权限边界。lark-cli、匿名 curl 和浏览器都会失败——对此已进行过全面验证；不要浪费时间尝试绕过。唯一正确的做法：请有权限的用户将文档导出为 .docx，然后通过其他渠道发给你，再进行保真转换（将字号还原为标题、将 w:shd 还原为高亮，然后进行视觉核验）。完整流程：references/docx-export-to-markdown.md。

路径 C — 飞书妙记 (Minutes) 转录文本

lark-cli minutes 只会返回元数据并下载音频/视频——无法导出文本转录内容。转录文本来自通过 lark-cli api 调用的原生端点，需要通过设备流登录额外授予一个 scope。原生 AI 转录远胜于下载媒体后重新运行 ASR——绝不要采用后者。端点、scope 名称、设备流超时陷阱，以及按单条妙记（而非按租户）生效的权限行为：references/feishu-minutes-transcript.md。

路径 D — 浏览器 DOM 回退（最后手段）

仅在 lark-cli 确实无法访问内容时使用（无法安装，且文档未被权限阻挡）。这是旧版基于虚拟滚动和目录驱动的 DOM 捕获工作流。速度较慢，依赖已连接的浏览器界面（浏览器内扩展经常无法连接）；匿名调试 Chrome 只能告诉你页面是否公开可访问——无法读取需要登录才能访问的内容。工作流：references/browser-dom-fallback.md。经过实战验证的 DOM 规则（虚拟滚动、data-block-id 排序、表格/项目符号提取、图像流）：references/browser-failure-rules.md。

硬性规则

违反这些规则会悄无声息地毁掉输出。每条规则都有其原因——遵循原因，而不只是照字面执行。

• 绝不要让文档正文经过模型。 使用 jq/cat/脚本直接提取到磁盘。模型改写源文本，事后无法察觉，并会破坏忠实度。这就是 Path A 在结构上优于浏览器路径的原因。
• 针对 *.feishu.cn，请设置 export LARK_CLI_NO_PROXY=1。 否则凭据会经过本地代理传输，且 DNS 会遭到劫持。
• 转录文本必须来自平台原生转录，绝不能重新执行 ASR。 下载媒体并再次转录会丢失说话人标签、时间戳，且准确度会下降。
• 生成的 docx Markdown 在与源文件进行目视核对之前都不能算完成（渲染成图像并阅读）。 Feishu 导出的 docx 使用字号和粗体来表示标题，而不是 Word 标题样式，因此“没有错误、字数一致”的检查会通过，但整个标题层级实际上已悄然变得扁平。文本级检查无法发现这一点。
• 不要在旧版 docx 图像 CLI 方法上反复折腾。 它们在 1.0.32 及之前版本中的失败，不能决定当前浏览器的原始预览权限。当正文捕获成功但导出/预览失败时，请使用 原始媒体和阅读器交接 中针对具体操作的分支；否则，登记源令牌并报告尚未解决的图像缺失问题。
• 在 pandoc 回退路径中，必须针对每份文档各自的 .html（绝不能是 .md）验证富媒体标签，而且每份文档都必须使用自己的文件名，不能共用字面值为 source.html 的文件。 pandoc -f html -t gfm 会悄无声息地剥除 Feishu 的自定义嵌入标签——已在真实文档中验证：.data.document.content 中的 3 个原始 whiteboard token="…" 标签，在转换后的 .md 中毫无痕迹（2026-08-16）。在此路径中仅检查 .md 是否残留标签，永远会报告“干净”，即使内容已被悄然丢弃；在一个 hub 的多次抓取中（步骤 3）重复使用一个硬编码文件名，还会导致后续文档悄然覆盖先前文档的原始捕获内容，使其在检查前就被覆盖。
• 绝不要把“已下载”等同于“应纳入 Git/LFS”。 原始视频、Office 文件、PDF 和图像默认保留 Feishu 原件并使用稳定定位符；本地文件只是缓存。Git 存储结构化/可搜索的衍生内容及来源信息。若仅保留源文件不足以满足持久性要求，可明确选择 OSS 路径。提交软件包前，请运行 python3 scripts/check_archive_storage.py <artifact-manifest.json>。
• 匿名 curl 返回 HTTP 200 ≠ 可访问。 Feishu 登录墙会返回 200，但响应正文包含 accounts.feishu.cn、login、passport 或空的 <title>。请检查正文，绝不要仅凭状态码推断“公开”。
• 搜索 Agent 报告某文件“未找到”，不具权威性。 得出结论前，请对照权威来源核实（这是一般性的推理纪律；在查找已摄取内容所在位置时尤其适用）。
• 对每个生成的文件进行 U+FFFD 最终检查： LC_ALL=C grep -rl $'\xef\xbf\xbd' . 必须无匹配结果。替换字符意味着某个编码步骤破坏了文本。

验收标准

仅当以下所有适用条件都满足时才停止：

• 每个获取到的正文都通过 jq/脚本写入磁盘，而不是由模型重新输入。
• 按照 comments and feedback 中的讨论验收规则执行。
• 每份获取到的文档——无论是单独一份还是一组文档：对递归检查整个工作目录时，Path A 第 5 步的富媒体标签残留检查命中的每一项，都必须对应一个已处理的产物——每个 mention-doc/cite doc-id=/sheet/跨租户引用都已跟进到获取的叶子文件，每个 whiteboard 引用都已导出并阅读（不是跟进——白板是内嵌视觉内容，绝不是需要递归跟进的链接）。原始二进制文件随后必须对应一个稳定的平台/开源软件定位符，以及可选的已验证本地缓存；结构化/可搜索的衍生文件必须存为带版本的文件。这项检查不只适用于文档集：独立文档也可能包含尚未处理的 whiteboard，且不涉及其他文档。每份文档自己的 .html 中始终会保留其标签，这是正常的（它是不可变的原始捕获文件，绝不重写——前提是第 3 步为每份文档使用了各自的文件名）；不要为了让 grep 结果变成零而继续追查。
• 产物清单通过 python3 scripts/check_archive_storage.py <manifest> 检查：没有原始二进制文件被声明为 Git 存储，每个外部产物都有稳定的定位符，且每个本地缓存都明确标记为非权威来源。
• 原始文件请求还必须满足附件归档验收标准：核对所有请求的原件以及任何单独的保留要求。在读者门槛通过之前，实际阅读者状态必须保持为未验证。
• 面向本地读者的交付遵循完成门槛。转换或存储检查不等于读者验收。用户排除的检查仍应保持排除且未验证；不要扩大任务范围，也不要伪造回执来强行标记为就绪。
• LC_ALL=C grep -rl $'\xef\xbf\xbd' . 结果为空。
• docx 路径：已渲染为图像并与源文件进行视觉比较；标题层级和高亮内容一致（参见 docx 参考中的检查清单）。
• 仅限浏览器回退方案：目录覆盖率 + 缩放检查（参见 browser-failure-rules.md）。
• 每个输出文件的 frontmatter 都记录 source（原始 URL/令牌）；如果进行了任何后处理，还要记录 post_process 溯源行——使用**逐文件收尾流程**。
• 明确列出权限缺口（尚未导出的 131006 文档、无法下载的图片）并告知用户——透明说明缺口胜过悄然遗漏。

请勿尝试

已验证的死路——重试只会浪费会话时间。包含失败模式和根本原因的完整表格见 references/permission-and-failure-boundaries.md。主要包括：

• 以任何方式绕过 131006 权限拒绝（lark-cli / curl / 匿名浏览器）——这是服务端边界。
• 重试通过 1.0.32 测试过的 docx 图像 CLI 方法：docs +media-download、api …/drive/v1/medias/<t>/download（带或不带 extra），或 schema drive.medias.download——这些方法均已失败；但这不排除获授权的当前原件预览请求。
• 使用 WebFetch 获取 open.feishu.cn/document/server-docs/... 中的 API 规范——后端不稳定；请改用 open.feishu.cn/llms-docs/zh-CN/llms-<module>.txt（适合大模型阅读且稳定）。
• AppleScript/JXA executeJavaScript、端口 9222 上的 Chrome CDP——在此环境中已禁用/为空（仅限浏览器路径）。
• 使用 minimax-docx 将 docx 转换为 md——它是 docx 创作工具；请改用文档转 Markdown 技能。

捆绑资源

• scripts/fetch_comments.py — 可执行的评论采集接口。
• scripts/archive_attachments.py — 下载已采集的源卡片原件，验证字节和 Office/ZIP 结构，并生成存储清单；范围和恢复方式请参阅附件归档。
• scripts/render_api_capture.py — 使用已采集的标题和清单本地附件来渲染已保存的 API 正文；转换并不能证明读者已接受。
• scripts/feishu_extract_refs.py — 确定性引用令牌提取器；递归引擎的核心。每份已获取的文档运行一次，并针对该文档自身的 <sanitized-title>.html 运行（优先于 .md — 步骤 3），以 JSON 枚举 <mention-doc>/<sheet>/<image>/<whiteboard>/跨租户/Minutes/Tencent-Meeting 引用。
• scripts/restore_docx_headings.py — 用于路径 B：通过 python-docx 读取实际字号，将其映射到标题级别，并将 w:shd 高亮还原为 Obsidian ==…==，无需重新输入正文。
• scripts/feishu_dom_capture.js — 路径 D：可注入的端到端浏览器 DOM 采集。
• scripts/download_feishu_images.py — 路径 D：浏览器自动化不可用时进行 SSR 图像提取。
• scripts/build_feishu_markdown.py — 将采集清单渲染为 Markdown 的路径 D 工具。
• scripts/check_heading_coverage.py — 覆盖率验证（两种路径）。
• scripts/check_archive_storage.py — 针对源文件/Git/OSS 存储划分的失败关闭验证器；会阻止将原始二进制文件声明为 Git 制品。
• references/lark-cli-api-extraction.md — 路径 A 完整参考（命令、递归、表格、跨租户）。
• references/feishu-minutes-transcript.md — 路径 C 原生转录 API + 范围授权。
• references/permission-and-failure-boundaries.md — 错误代码 + 完整的“禁止尝试”表格。
• references/docx-export-to-markdown.md — 路径 B 忠实转换流程。
• references/browser-dom-fallback.md + references/browser-failure-rules.md — 路径 D。
• references/capture-manifest.md — build_feishu_markdown.py 的清单结构。
• references/archive-storage-contract.md — 结构化 Git 制品、平台原件、可选缓存和 OSS 副本的持久存储约定。

下一步

使用用户已选定的目标位置。对于个人收藏，请遵循 源目录交接流程，前往收藏搜索。不要重新将该选择作为 PKM 建议提出，也不要将私人材料提升到团队收藏中。当用户授权选择合适的归档位置时，请遵循主机的约定完成目标位置交接。对于仅提取内容、未授权归档的请求，请提供忠实采集结果并明确列出缺漏，不要选择永久知识库。