leantext 为编程智能体过滤网页噪声

AI 编程助手查一个 API，读进上下文的却可能是整页导航、隐藏菜单和历史文件清单。leantext 想解决的就是这笔浪费：先把网页或文件提取成正文 Markdown，检查代码、表格等结构有没有丢失，再交给助手。

作者给出的结论是，网页噪声可以大幅削减，但不能只追求压缩率。对程序员更有参考价值的，是它把提取、校验和失败回退串成了一条流程。标题里的「最多减少 99% token」，也需要放回具体页面和统计口径里看。

省下多少，要先看拿什么作比较

作者举了 PyPI 上的 NumPy 页面：项目介绍约 2,000 token，整页按常规方式转成 Markdown，却达到 92,348 token。大头来自浏览器里看不到的文件列表，里面列着每次发布的文件和哈希。

这些内容未必没有用途，但如果助手只是想了解项目介绍，就没有必要全部读取。

leantext 接收 URL 或本地文件，把 Markdown 输出到 stdout。下面这条命令用于提取 Stripe 创建客户的文档，并显示节省报告：

leantext https://docs.stripe.com/api/customers/create --report

要留意 --report：它让你看到压缩效果，而不只是得到一份看起来干净的正文。

这个例子中，原始 HTML 是 521,378 token，常规整页 Markdown 是 3,958 token，最终输出是 1,194 token。报告分别显示节省 100% 和 70%；前者是取整显示，并不代表输出没有 token。

判断收益，应优先比较常规 Markdown，而不是原始 HTML。

因为作者设定的实际替代方案，就是助手原本会读取整页 Markdown。token 数由 tiktoken 统计。Stripe 示例仍保留请求、响应、参数类型和返回值，包括 https://api.stripe.com/v1/customers 请求，以及 name、email 等参数。

标题中的 99% 是上限表述，不能据此推算自己团队的平均收益。对于正文密集的文档，能删的东西本来就少。

真正难的不是删导航，而是保住代码

leantext 的流程分成几步：优先使用站点自己提供的 Markdown，Stripe、GitHub Docs、Docker docs 都属于作者列出的例子；否则先去掉隐藏元素、未选中的标签面板和关闭的对话框，再用 trafilatura 提取主要内容，最后校验并统计 token。

这里最容易踩坑的是：页面结构里的代码和表格，未必会被正文提取器正确识别。

作者首次测试 Python 的 pathlib 文档时，83 个代码示例只完整保留了 14 个。原因是 Sphinx 把示例放在 <dl><dd> API 结构里，提取器把代码压进了普通段落。Node 文档则丢失了 123 张版本历史表中的 116 张，它们藏在折叠的 <details> 中。

修复方法是，在提取前把每个 <pre> 和数据表格替换成占位符，提取后再把原块连同语言标签原样放回。哪些内容属于正文，仍由提取器决定，所以侧栏中的代码依然可能被排除。修复后的 pathlib 页面保住了全部 83 个示例，并被加入回归测试。

这也说明，「去掉不可见内容」不能只凭视觉状态判断。关闭的弹窗通常是噪声，折叠的版本历史却可能直接影响兼容性判断。

自动接入的前提，是允许它主动退让

leantext 不只处理网页，也支持 PDF、扫描版 PDF、截图和 Office 文件。截图先做 OCR，视觉模型只作为后备方案；原文没有交代具体模型和触发细节。

安装命令如下：

git clone https://github.com/shouvik12/leantext
cd leantext && ./install.sh

要留意 ./install.sh 的交互步骤：安装器会询问是否添加 Claude Code hook，接受后还需要重启 Claude Code。作者称普通网络下安装约需 20 秒，在 Mac 上占用约 39 MB，无需系统软件包；这些不是每次转换的耗时数据。

hook 会在转换后核对代码块、表格、标题、文本保留量和页面标题，也会识别反机器人拦截页，以及依赖 JavaScript 才能呈现内容的页面。如果结果可疑，或者节省不足 15%，就让助手读取原始内容。

每次决策都会记录原因，可以用 tail -3 ~/.cache/leantext/hook.jsonl 查看最近记录，也可以通过 LEANTEXT_HOOK=off 关闭。

作者报告，在 Claude Code 的端到端运行中，启用 leantext 后 21 个任务全部回答正确。不过，给出的原文没有展开任务清单和完整对照结果。

我的判断

我认可它把结构校验放进默认流程。API 文档中的一个代码块、一张版本表，往往比几段介绍更关键。单纯追求短文本，很容易得到一份流畅但缺信息的结果。

相比直接把整页转 Markdown，这套流程多了噪声过滤和回退机制；如果站点本身提供 Markdown，优先使用它也很合理。但结构完整不等于语义完整：代码块数量一致，仍不能证明解释条件、警告和参数约束全部保留。

21 个任务全部答对，是有限样本下的结果，不能当作普遍无损的证明。

作者称最坏情况等同于没安装，但原文没有给出额外耗时、漏检率或错误回退的对照数据。更准确的理解是，它提供了一个可检查的提取方案，可靠程度仍要用常读文档验证。项目采用 Apache-2.0 许可证。

能拿来做什么

• 给 Claude Code 接入 hook 前，先用 --report 跑一遍常查的前端框架或 Node 文档，核对代码、参数说明和版本表，再决定是否长期启用。
• 遇到依赖折叠面板、标签切换的 API 页面，重点检查兼容条件和示例是否保留，不能只看 token 降幅。
• 如果正在做文档读取流水线，可以借鉴「保护代码与表格、提取正文、校验、失败回退」的顺序，并记录每次回退原因。
• 对正文密集、节省不足 15% 的页面，接受直接读取原文；压缩收益小的时候，完整信息更有用。