每次手抄公众号文章都想掀桌？werss-cli 这套 Rust 工具把抓取到落盘一次打通

做内容归档最烦的，不是“拿不到文章”，而是“拿到了但流程像拼乐高”。 账号列表一份、时间范围一份、失败重试一份、最后还得自己转 Markdown。 多来几次，整个人直接进入机械劳动模式。

werss-cli 干的事很直接：通过 WeRSS API 拉公众号文章，转成带 YAML frontmatter 的 Markdown，并且把增量同步、并发、失败重试、token 管理都塞进一条 CLI 工作流里。

这工具到底是什么

一个面向“公众号文章抓取+归档”的 Rust 命令行工具：从 API 拉文，按规则落盘 Markdown，支持增量同步、并发抓取和安全凭据管理。

值得看的核心原因

现实里的破事	工具给的解法	放进工作里意味着什么
每次要重复抓同样的文章	增量同步：记录 fetched/failed，跳过重复，失败可重试	节省无效请求，流程更稳定
抓取慢、任务堆积	并发抓取（最多 3 个同时）	同样时间能跑完更多账号
中途 Ctrl+C 一断就乱	优雅退出：完成当前文章并保留状态	下次能接着跑，不会烂尾
凭据散落在配置里有风险	token 自动存系统 keyring，支持自动刷新	安全和可用性同时保住
参数来源混乱	CLI / 环境变量 / TOML / .env 有明确优先级	排障时能快速定位生效配置

类比一下：它像一个只干脏活累活的“内容管家”，把钥匙（token）放保险柜，把流水（状态）记账本，不需要每次人工补台词。

能力拆开看，哪些点最硬

安全认证不是“可选项”，而是默认路径

能力：首次用用户名密码换 token，后续自动从 keyring 读，过期自动刷新，刷新失败才回退到凭据或密码输入。
实际价值：日常跑任务时不反复输入凭据，减少明文暴露面。
边界：首次接入仍需要可用的 API 地址和账号信息。

增量同步把“重复劳动”砍掉

能力：跟踪 fetched/failed，跳过重复抓取，失败支持重试。
实际价值：批量同步长周期运行时更省心，不会每次从零开始。
边界：状态管理依赖本地记录文件，建议固定输出目录。

并发有上限，稳定优先

能力：并发抓取带并发控制，最多 3 个同时任务。
实际价值：比串行快，又避免把服务端打爆。
边界：并发上限是受控值，不是无限拉高。

输出格式天然适合知识库/发布链路

能力：输出 Markdown + YAML frontmatter，目录结构固定。
实际价值：后续喂给 Obsidian、静态站点、内容流水线都顺滑。
边界：字段结构按工具定义走，二次加工建议在后处理阶段做。

配置优先级清晰，排障不扯皮

能力：CLI flags > Environment variables > werss.toml > .env > Built-in defaults。
实际价值：谁覆盖了谁一眼可判，不会出现“为什么本机和 CI 不一样”。
边界：多入口并存时要先统一团队约定。

上手门槛高不高

不高。核心门槛就是：有可访问的 WeRSS API、可用账号、以及一个能跑 CLI 的环境。工具本身已经把认证、同步和输出形态打包好了。

首次认证命令（原样）：

./target/release/werss-cli --api-base http://your-server:8001 \
                          --username your-username \
                          --password your-password \
                          --mp all

后续运行命令（原样）：

./target/release/werss-cli --mp all

快速开始（原样）：

cargo build --release

# generate config template
./target/release/werss-cli --init-config

# edit werss.toml with your API credentials, then run
./target/release/werss-cli

配置优先级（原样）：

CLI flags > Environment variables > werss.toml > .env > Built-in defaults

最小配置示例（原样）：

[api]
base = "http://your-server:8001"
username = "your-username"
password = "your-password"

[sync]
target_mps = "all"   # or ["MP_WXS_123", "MP_WXS_456"]

常见用法（原样）：

werss-cli                                    # fetch all (uses werss.toml + saved token)
werss-cli --mp MP_WXS_123,MP_WXS_456         # specific accounts
werss-cli --output ./data                     # custom output directory
werss-cli --since 2026-01-01 --until 2026-03-31  # date range
werss-cli --limit 10                          # max 10 articles
werss-cli --workspace ./workspace             # publish to workspace

输出目录（原样）：

articles/{mp_id}/YYYYMMDD/{seq}/{slug}.md

怎么放进真实工作流

上面这部分是工具原生能力。
下面是组合工作流示例（额外实践），用于把抓取结果接进 OpenClaw / Hermes 的内容生产链路。

1) 安装/接入过程（组合工作流示例）

flowchart LR
    A[部署 WeRSS API] --> B[配置 werss.toml]
    B --> C[werss-cli 首次认证并抓取]
    C --> D[落盘 Markdown frontmatter]
    D --> E[OpenClaw/Hermes 读取目录]
    E --> F[生成摘要/改写/归档]

2) 实际使用过程（组合工作流示例）

先用原生命令拉取指定账号与时间段：

werss-cli --mp MP_WXS_123,MP_WXS_456 --since 2026-01-01 --until 2026-03-31 --workspace ./workspace

再在 OpenClaw 里把输出目录作为输入源，触发后续文章整理与发布流程（例如摘要、标签、归档到知识库）。

3) 产出结果 / 适合放进什么流程

• 产出：结构化 Markdown 文章库（含 frontmatter 字段：title、author、coverImage、url、mp_id、description、publish_time）。
• 适合流程：内容监控、行业资讯沉淀、公众号素材池、自动化周报。

这工具真正香在哪

第一，认证和 token 刷新做成默认自动化，省掉一堆手工操作。
第二，增量同步+失败重试这套机制对长期跑批非常友好。
第三，输出就是可消费的 Markdown，不用再做一次格式搬运。

哪些团队更该上

• 有固定公众号监控需求的内容运营/技术情报团队。
• 需要把文章自动沉淀进知识库的工程团队。
• 做资讯归档、研究跟踪、竞品情报的分析团队。
• 想要“命令行可控 + 配置可审计”的平台工程团队。

用之前先知道的边界

• 依赖 WeRSS API 服务可用性，服务端异常会直接影响抓取任务。
• 首次认证仍需要账号凭据，后续才进入 keyring 自动化路径。
• 并发抓取上限是 3，追求稳定而不是极限压榨吞吐。
• 有一条运行时约束：html2md 需要 panic_unwind，因此 release 配置里不能用 panic = "abort"。
• 许可证为 MIT，落地到商业流程前建议按团队合规要求复核。

依赖与文档入口（便于二次扩展）

依赖组件：reqwest、tokio、clap、html2md、serde/serde_json、chrono、toml、anyhow、keyring。
文档页覆盖安装、配置、使用、增量同步、输出格式、架构、API 参考、故障排查，扩展时有完整落点。

如果团队每天都在重复“抓取—清洗—归档”这套脏活，werss-cli 属于那种装上就能立刻回本的工程工具。

https://github.com/decbe/werss-cli

#GitHub热门项目 #Rust #CLI工具 #公众号抓取 #内容工程 #自动化 #知识库 #OpenClaw #Hermes #Markdown