Hermes Decision Trace

Albert-Lsk/wechat-notebank 综合调研与吸收评估

建议：可以吸收，但不要把它当成 Hermes 微信归档主干直接替换现有链路。

HTML完整论证

Wiki可检索归档

Feishu短入口交付

🎯

核心结论

建议：可以吸收，但不要把它当成 Hermes 微信归档主干直接替换现有链路。

🧭

推荐路径

#### 1. 不建议直接采用其四层知识库为 Hermes 标准

🛡️

关键边界

项目使用本机 Chrome 打开公众号文章。公开文章通常可读，但微信页面结构和反爬策略会变。

关键判断

判断项	摘要
推荐方案	#### 1. 不建议直接采用其四层知识库为 Hermes 标准
关键依据	见完整记录中的评分依据、状态摘要和证据链。
落地方式	按行动清单推进，保持可回退。
风险边界	项目使用本机 Chrome 打开公众号文章。公开文章通常可读，但微信页面结构和反爬策略会变。

证据摘要

由 Hermes 会话生成。证据点 1
如涉及外部事实，应在正文中保留来源或验证路径。证据点 2

行动清单

Progressive Summarization 四层结构适合个人 Obsidian，但 Hermes 已经有：

llm-wikis

decision traces

retain pointer

飞书主库

项目状态文档

边界 / 风险

风险点

项目使用本机 Chrome 打开公众号文章。公开文章通常可读，但微信页面结构和反爬策略会变。

风险点

风险包括：

风险点

页面结构变化导致 selector 失效

风险点

某些文章需要登录 / 验证

风险点

图片懒加载、视频、音频、引用卡片不一定完整保存

风险点

公众号历史文章列表、收藏夹、订阅号消息流并不在能力范围内

完整记录

本节目录结论证据摘要功能能力技术实现风险与限制对 Hermes 的吸收价值建议的 Hermes 集成路线

Albert-Lsk/wechat-notebank 综合调研与吸收评估

结论

建议：可以吸收，但不要把它当成 Hermes 微信归档主干直接替换现有链路。

更合适的定位是：把 wechat-notebank 作为“微信公众号文章 → 本地 Markdown / Obsidian 原文层”的轻量 CLI 参考实现或可选外部工具。它的价值在于流程清楚、依赖少、输出 Markdown + Frontmatter、支持 Excel 批量导入；但它目前仍是早期个人项目，能力边界集中在“网页抓取和落盘”，不包含账号体系、微信收藏同步、长期任务调度、去重索引、飞书/HTML/wiki/retain 等 Hermes 级知识治理闭环。

如果要纳入 Hermes 体系，我建议采用“三段式吸收”：

短期：作为外部工具观察 / wrapper 试用

不改 Hermes 主线。
通过 skill 或脚本封装 alskai-notebank <url> -o <folder>。
用少量公众号文章做解析质量验证。

中期：吸收其输入输出协议

Frontmatter 字段：title / author / wechatName / pubDate / sourceUrl / archivedAt / tags 有参考价值。
Excel 批量导入、按 sourceUrl 去重、按发布日期命名，也值得纳入 Hermes 微信归档规范。
但不要照搬其目录结构为唯一标准。

长期：如稳定，可拆出 parser/fetcher 能力

只吸收“微信文章 HTML → Markdown + metadata”的解析层。
把浏览器抓取、批量任务、去重、知识入库、飞书回执交给 Hermes 自己的 pipeline。

---

证据摘要

仓库基本情况

仓库：Albert-Lsk/wechat-notebank

地址：https://github.com/Albert-Lsk/wechat-notebank

GitHub API 显示：

Star：28
Fork：4
主语言：TypeScript
License：MIT
默认分支：main
创建时间：2026-04-13
最近 pushed：2026-05-26
最近 commit：docs: rewrite README for user onboarding
releases：暂无
PR：暂无
open issues：0

这说明它不是陈旧项目，最近仍在维护；但项目规模和社区成熟度都还很早期。

README 定位

README 明确说：

把微信公众号文章保存成可长期整理、搜索和复盘的 Markdown 笔记。

核心流程是：

微信公众号文章链接 -> 本机 Chrome 打开页面 -> 解析 HTML -> 保存 Markdown

它强调：

不需要大模型
不需要 OpenAI / Claude / Gemini API key
当前只做保存原文
摘要、标签、自动提炼未来才可能引入大模型

这个定位很清楚：它不是智能知识库，而是微信文章本地归档工具。

---

功能能力

单篇抓取

支持：

alskai-notebank fetch "https://mp.weixin.qq.com/s/xxxxx" --output ~/WeChatArticles

也支持省略 fetch：

alskai-notebank "https://mp.weixin.qq.com/s/xxxxx" -o ~/WeChatArticles

旧命令别名：

wechat-notebank fetch <url> -o <folder>

从 package.json 看，两个 bin 都指向 dist/index.js：

"bin": { "alskai-notebank": "dist/index.js", "wechat-notebank": "dist/index.js" }

这说明 alskai-notebank 是推荐新名，wechat-notebank 是兼容旧用法。

Excel 批量导入

支持：

alskai-notebank import ./articles.xlsx

README 描述支持两列表格：

| 微信文章 | 目标地址 |

也兼容旧三列表格：

| 序号 | 微信文章 | 目标地址 |

源码 src/lib/importer.ts 也能看到它的处理逻辑：

读取第一个 sheet
自动识别表头
支持两列 / 三列布局
缺少 URL 或输出路径则跳过
单行失败不阻断后续
汇总 success / failure / skipped
失败项保留 rowNumber、sequence、url、outputPath、message

这个批处理设计是项目里比较实用的部分。

输出结构

README 推荐 Progressive Summarization 四层结构：

your-knowledge-base/ ├── L1_原文/ │ └── WeChat/ │ └── 文章原文.md ├── L2_原子卡片/ ├── L3_引用素材/ └── L4_阅读复盘/

源码 src/lib/storage.ts 中也定义了：

export const FOLDER_L1 = 'L1_原文'; export const FOLDER_L2 = 'L2_原子卡片'; export const FOLDER_L3 = 'L3_引用素材'; export const FOLDER_L4 = 'L4_阅读复盘';

但注意：抓取保存函数 saveArticle() 实际保存到传入的 archivePath，而 init 创建配置时会把默认 archivePath 设置到 L1_原文/WeChat。这意味着四层结构更多是推荐知识库结构，不是每次强制全流程都填充 L2/L3/L4。

元数据

类型定义 src/types.ts 中 ArticleMeta 包含：

title author wechatName pubDate sourceUrl archivedAt tags

这套字段非常适合作为 Hermes 微信文章归档的最小元数据集。

去重

批量导入时会调用：

articleExistsBySourceUrl(row.outputPath, row.url)

src/lib/storage.ts 中通过扫描目标目录下 .md 文件 Frontmatter 的 sourceUrl 判断是否已存在。

这个方案简单可用，但有局限：

只扫描指定目录一层，不是全库索引。
大规模文件时性能一般。
如果 Hermes 未来做微信归档，应该用 SQLite / Bitable / registry 做去重，而不是每次扫文件。

---

技术实现

技术栈

从 package.json 看：

TypeScript
Node.js
puppeteer-core
cheerio
gray-matter
fs-extra
xlsx
inquirer
axios

依赖不复杂，适合 CLI 工具。

抓取方式

src/lib/parser.ts 中 fetchArticleHtml() 使用 puppeteer-core 启动 Chrome。

默认：

launchOptions.channel = 'chrome'

如果设置环境变量：

WECHAT_NOTEBANK_CHROME_PATH

则使用指定 Chrome 路径。

浏览器参数包括：

--no-sandbox --disable-setuid-sandbox --disable-dev-shm-usage --disable-accelerated-2d-canvas --disable-gpu

访问页面后：

page.goto(url, waitUntil: 'domcontentloaded')
等待 #js_content
超时后仍返回页面内容，让解析层报统一错误

支持环境变量：

WECHAT_NOTEBANK_NAVIGATION_TIMEOUT_MS WECHAT_NOTEBANK_CONTENT_TIMEOUT_MS

这说明作者已经遇到过微信公众号加载不稳定问题，并做了基础容错。

解析方式

parseWechatArticle(html, url) 使用 Cheerio。

标题选择器：

#activity-name
h1
.article-title

作者 / 公众号：

#js_name
.account_nickname

正文：

#js_content
.article-content
article

如果没有 title 或 content，则抛错：

解析失败：无法提取文章标题或内容。可能是反爬机制或页面结构变化。

代码块处理上有专门逻辑：

处理 .code-snippet__fix
标准化 <pre><code>
提取语言 class
清理嵌套结构

最近 commit 也有 fix: normalize WeChat code blocks，说明这是实际 bug 修过的点。

存储方式

saveArticle()：

确保目录存在
用发布日期 + 标题生成文件名
用 gray-matter 写 Frontmatter
同名文件自动追加 -2、-3

文件名规则：

YYYY-MM-DD-文章标题.md
标题只保留中文、英文字母、数字
最大文件名按 UTF-8 字节截断，避免超长路径

这个实现比较稳，但也会去掉标题里的标点，可能影响可读性。

---

风险与限制

1. 微信公众号反爬和登录态风险

项目使用本机 Chrome 打开公众号文章。公开文章通常可读，但微信页面结构和反爬策略会变。

风险包括：

页面结构变化导致 selector 失效
某些文章需要登录 / 验证
图片懒加载、视频、音频、引用卡片不一定完整保存
公众号历史文章列表、收藏夹、订阅号消息流并不在能力范围内

所以它适合“已知 URL 的文章归档”，不适合作为“微信资料全自动采集系统”。

2. Markdown 转换还比较粗

从源码看，cleanHtml() 清理 HTML 后返回的是 HTML 字符串，再由 gray-matter 写入 Markdown 文件。严格说，它并没有做完整 HTML → Markdown AST 转换。

这意味着输出文件可能是：

Frontmatter + HTML-ish body
对 Obsidian 可显示，但不一定是干净 Markdown
对后续 LLM/RAG 处理可能需要二次清洗

如果 Hermes 要吸收，应该在后处理层加：

HTML to Markdown
图片资源处理
链接规范化
正文噪声清理
结构块识别

3. 图片和附件长期可用性不确定

README 强调保存 Markdown 原文，但源码主要处理 img[data-src] 到 src。这通常仍指向微信 CDN。

如果没有本地下载图片，长期归档会有问题：

微信 CDN 链接可能过期
防盗链可能影响显示
离线知识库不可完整复现

Hermes 若要做“长期归档”，不能只留远程图片 URL。

4. 配置文件位置是当前工作目录

src/lib/config.ts 中：

const CONFIG_FILE = '.wechat-notebank.json'; export function getConfigPath(): string { return path.resolve(process.cwd(), CONFIG_FILE); }

配置文件在当前工作目录，而不是用户 home 目录。这对 CLI 简单，但对长期自动化不够稳：

不同 cwd 下配置不同
cron / agent / service 调用时容易找不到配置
Hermes wrapper 必须显式 -o 或固定 workdir

5. release / npm 发布不成熟

README 明确说还没发布到 npm registry。安装方式是：

npm install -g https://github.com/Albert-Lsk/wechat-notebank/archive/refs/heads/main.tar.gz --force

这代表：

无固定版本 pin
main 分支变化会影响安装结果
生产使用需要锁 commit 或 fork
没有 release notes / semver 稳定承诺

6. 社区成熟度有限

当前：

28 stars
4 forks
无 release
无 PR
open issues 为 0
仓库创建时间 2026-04-13

最近活跃是好事，但成熟度仍然低。

---

对 Hermes 的吸收价值

值得吸收的部分

#### 1. 微信文章归档的最小数据模型

建议把这套字段纳入 Hermes 微信归档规范：

title: author: wechatName: pubDate: sourceUrl: archivedAt: tags:

Hermes 可扩展：

sourcePlatform: wechat_mp sourceId: contentHash: fetchMethod: fetchStatus: imagePolicy: htmlPath: markdownPath: retainId: feishuDocUrl:

#### 2. Excel 批量导入交互

微信文章 / 目标地址 这种表格批量导入非常适合非技术用户。

Hermes 可以吸收为：

CSV/XLSX queue
每行一篇文章
每行有状态：pending / success / skipped / failed
结果回写到 Bitable 或本地 registry
失败原因可追踪

#### 3. sourceUrl 去重口径

按 sourceUrl 去重是合理最低标准。

Hermes 应升级为：

sourceUrl
canonical URL
content hash
title + pubDate fallback
registry / sqlite index

#### 4. CLI 技术路线

“本机 Chrome + Cheerio 解析 + Markdown 落盘”是低成本可行路线。对 Hermes 来说，可以把它作为一个 source adapter。

不建议直接吸收的部分

#### 1. 不建议直接采用其四层知识库为 Hermes 标准

Progressive Summarization 四层结构适合个人 Obsidian，但 Hermes 已经有：

llm-wikis
decision traces
retain pointer
飞书主库
项目状态文档
skill/reference/wiki 分层

直接套 L1/L2/L3/L4 会造成体系重复。

更合理做法：

只把 L1 原文归档作为原始层
L2/L3/L4 由 Hermes 后处理 pipeline 生成或映射到现有 wiki/retain

#### 2. 不建议用它承担长期调度

它没有：

cron
队列
失败重试
并发控制
资源监控
结果通知
飞书回执

这些应由 Hermes 自己负责。

#### 3. 不建议直接信任 main 分支全局安装

如果试用，建议：

npm install -g https://github.com/Albert-Lsk/wechat-notebank/archive/<commit>.tar.gz

或者 fork 到本地，固定 commit。

---

建议的 Hermes 集成路线

Phase 1：轻 wrapper，不入主线

目标：验证解析质量。

做法：

安装到隔离目录或 npx/git checkout 本地运行。
选 10–20 篇不同类型公众号文章：
普通长文
多图文
代码块文章
表格文章
视频/音频混排
已删除或受限文章
输出到临时目录。
检查：
标题是否正确
作者/公众号是否正确
pubDate 是否真实
正文是否完整
图片是否可用
代码块是否保真
Frontmatter 是否可被 Hermes ingest

停止点：如果核心字段和正文完整率不够，不进入下一阶段。

Phase 2：沉淀 Hermes skill / script

如果 Phase 1 通过：

新增 Hermes skill：wechat-notebank
触发词：
归档公众号文章
微信文章入库
批量导入公众号链接
skill 内只调用 CLI，不重写抓取逻辑。
输出固定到 Hermes staging 目录：

(1/2)