微信笔记同步助手：转发给它，笔记自己进 Obsidian

背景

我日常的信息入口基本就是微信：看到一段话、一篇文章、一个链接，转发给”文件传输助手”就算存下来了。 但存下来之后再也没打开过。

想要的是：转发那一刻就自动变成一条结构化的笔记，落进 Obsidian，将来能搜到、能双链。

方案

三个组件，各干一件事：

微信转发
  → 服务端（Node）：接消息、调模型整理成 Markdown
  → 飞牛 NAS：存文件（家里常开，天然做中转）
  → Obsidian 插件：点一下拉取，写进 vault

几个设计取舍：

• 不做多端同步：Obsidian 自己已经有同步方案，插件只负责”从 NAS 取”
• AI 只做整理不做总结：把”这段话在讲什么”整理成标题、要点、标签，但不替我下结论
• 一切落成纯 Markdown：不引入数据库，将来换个工具也不用迁移

过程

服务端收到的原始内容很脏：可能是纯文本、可能是 HTML 片段、可能只有个链接。 先做一层清洗，再喂给模型，要求输出固定结构：

---
title: 自动生成的标题
tags: [标签1, 标签2]
source: 转发来源
date: 2026-09-15
---
正文（保持原意，只做分段和要点化）

插件那边就两个动作：拉清单、下载新文件。

踩坑

现象	原因	解法
转发图片时笔记里只有一个占位符	图片存在微信侧，服务端拿不到原图	只处理文字和链接，图片明确的场景手动补
生成的标题经常一模一样	模型对短文本倾向套模板	提示词里强制”标题必须包含具体对象”，并做去重校验
NAS 上跑起来路径全错	部署包用了开发机的绝对路径	改成从环境变量读，.env.example 里写清楚
插件偶尔重复导入	拉取时只看文件名不看内容，重名会覆盖	用内容哈希命名，导入前比对

结果

跑通了，一直在用——它现在是微信和 Obsidian 之间的收件箱。

• 服务端跑在飞牛 NAS 上，7×24 常开，转发进去就有人处理
• Obsidian 里点一下拉取，新笔记落进 vault；不是定时自动跑
• 落地是纯 Markdown + frontmatter，后续搜索、双链、归档都不受工具限制
• 部署包做了一份，换机器或帮别人装都能直接起

关于”手动点一下”这件事，一开始觉得是没做完，用久了发现这样反而对：

• 笔记是给”我想看的时候”用的，不需要它随时变化
• 手动触发 → 我知道这次拉了什么，出了问题也容易定位
• 省掉了定时任务、状态同步、失败重试这一整层复杂度

复盘

为什么这个小工具活得比很多”更厉害”的项目久：

• 每个组件只做一件事：接消息、存文件、拉文件，互不耦合，坏一个不影响其他
• 不碰多端同步：Obsidian 已经有方案，我不重复造轮子，也就少一半故障点
• 不做定时任务：手动点一下触发，少一整层失败重试和状态同步
• 落地格式足够”笨”：纯 Markdown 文件。十年后就算工具都换了，文件还在
• 它解决的是真实摩擦：不是我”觉得应该有”的功能，是每天都要转发东西这个动作

对比一下另一个同类项目（发布工作流）为什么停了：那个去碰了平台的登录态，一旦坏了整条链就断； 而这个从头到尾只依赖”文件 + 一次 HTTP 拉取”，脆弱点少得多。