Wechatsync v2（文章同步助手）把网页文章提取、多平台格式转换、图片上传和草稿创建集中在 Chromium 浏览器扩展中，再通过 CLI 与 MCP Server 把这些能力接入命令行或 AI 工作流。与只提供一个发布按钮的扩展不同，它的源码把平台适配、运行时、扩展界面和外部调用入口拆成独立包，适合研究“如何复用浏览器登录态完成跨平台内容分发”。
截至 2026 年 9 月 12 日核对，仓库默认分支为 v2，主要语言为 TypeScript，根目录许可证为 GPL-3.0。当前扩展包版本是 2.0.9，CLI 与 MCP Server 均为 1.1.0，根包和 core 包则标记为 2.0.0。这些编号对应不同交付物，不能互相替代。
为什么浏览器扩展是整个同步链路的执行中心？
CLI 和 MCP Server 本身不保存各平台账号的登录状态，也不直接代替浏览器完成发布。它们通过 WebSocket 把“提取文章、检查登录、上传图片、创建草稿”等请求交给 Chrome Extension；扩展再利用浏览器中已有的 Cookie 和页面环境调用目标平台 Web 接口。由此形成一条清楚的链路：外部工具负责发起任务，扩展负责带着浏览器权限执行，平台适配器负责翻译各站点的字段与请求。
这一设计解释了两个常见误区。第一，只在服务器安装 @wechatsync/cli 并不会自动获得知乎、掘金或公众号的登录态；浏览器扩展必须安装、启用桥接，并保持对应账号有效登录。第二，“本地执行”也不等于正文永远停留在设备里，真正同步时文章和图片仍会从浏览器发送到所选平台。
四个工作区包分别承担什么职责？
v2 使用 monorepo 组织代码，packages/* 下的四个包形成从共享逻辑到具体入口的分层。阅读源码时，从 core 的类型和适配器注册开始，再追踪 extension 的运行时实现，比直接从某个平台请求代码切入更容易建立全局关系。
| 包 | 当前版本 | 主要职责 |
|---|---|---|
@wechatsync/core |
2.0.0 | 平台适配器、运行时接口、Markdown/HTML 转换、ZIP 打包和共享类型 |
@wechatsync/extension |
2.0.9 | Manifest V3 扩展、文章提取、同步对话框、后台服务与浏览器权限实现 |
@wechatsync/cli |
1.1.0 | 读取本地文章、选择平台、检查登录状态并通过桥接发起同步 |
@wechatsync/mcp-server |
1.1.0 | 把同步、鉴权检查、文章提取和图片上传暴露为 MCP 工具 |
core 不绑定单一浏览器实现，而是通过运行时接口获得带 Cookie 的请求、请求头规则和存储能力；extension 提供真实的 Chrome 运行时。这样平台适配器可以共享文章结构与转换逻辑，同时把浏览器专属能力留在扩展侧。
新增平台不是加一个名称，而是实现一套适配器契约
packages/core/src/adapters/platforms/ 中按平台拆分了知乎、掘金、CSDN、公众号、B站专栏、博客园等适配器，registry.ts 负责集中登记。一个可用适配器需要处理账号身份、文章字段、图片上传、内容格式与草稿创建，还要通过 RuntimeInterface 使用扩展环境中的网络和 Cookie 能力。
对二次开发者而言，最稳妥的顺序是先阅读 docs/adapter-spec.md、base.ts 和一个结构相近的现有平台，再实现目标站点差异。不同编辑器对标题长度、HTML 标签、Markdown、封面和图片地址的要求并不一致，复制另一个平台的请求参数通常不足以完成接入。
README 列出的 29+ 平台包含自媒体、技术社区、自建博客和静态博客，但它们的“同步”含义并不完全相同。WordPress、Typecho 等通过相应接口创建内容；Hexo 和 Hugo 对应的是 Markdown 与图片 ZIP 下载，后续仍需放入站点工程并自行构建部署。
CLI 与 MCP 提供两种外部调用方式
CLI 适合脚本和本地内容库，可以先检查登录状态，再预览任务，最后选择目标平台：
npm install -g @wechatsync/cli
wechatsync platforms --auth
wechatsync sync article.md --dry-run
wechatsync sync article.md -p zhihu,juejin--dry-run 只做预览；实际同步默认以草稿为目标，仍应在各平台编辑器中检查标题、封面、代码块、表格和图片。CLI 还可以从浏览器当前页面提取文章并保存为 Markdown。
MCP Server 则面向 Claude Code、Claude Desktop 等支持 MCP 的宿主，提供 list_platforms、check_auth、sync_article、extract_article 和 upload_image_file。它适合把分发放在写作流程的最后一步，但模型生成的标题、平台列表和正文仍需人工审核，不能因为调用入口变成自然语言就跳过草稿检查。
远程桥接的 9527 端口与 Token 需要单独保护
CLI 和 MCP 文档说明桥接默认监听 0.0.0.0:9527，并允许本地扩展连接远程开发机。WECHATSYNC_TOKEN 或 MCP_TOKEN 用于连接校验，但 Token 会以明文通过 WebSocket 发送。远程使用时应配合 SSH 隧道或 VPN，并限制防火墙访问范围；不应把端口直接暴露到公网。
构建 v2 时需要先处理包管理器说明差异
根 package.json 要求 Node.js >=20.0.0。README 给出的入口是 pnpm install、pnpm dev 和 pnpm build，仓库也包含 pnpm-workspace.yaml；但根 scripts 内部仍调用 yarn workspace 与 yarn workspaces。这意味着“使用 pnpm 安装”与“脚本委托给 Yarn”同时存在，实际构建前应核对本机包管理器和锁文件，不宜只复制一条命令就认定环境完整。
扩展构建成功后的目录是 packages/extension/dist，可在 Chromium 扩展管理页以开发者模式加载。扩展当前使用 React 18、Vite 5、Zustand 和 Manifest V3；core 则集中使用 unified、remark、rehype、Turndown、JSZip 等工具处理 HTML、Markdown 和资源打包。本文未在本机执行构建，因此这些步骤属于源码与文档核对，不是运行测试结论。
扩展权限和许可证决定了部署边界
扩展清单申请了 cookies、tabs、scripting、downloads、declarativeNetRequest 等权限，并将 HTTP/HTTPS 主机权限覆盖到所有网站。这与跨站读取页面、修改请求头和上传内容的工作方式一致，也意味着扩展能接触较广的页面与账号环境。安装前应核对来源，及时更新，并避免在保存敏感业务账号的浏览器配置中随意加载未经审查的修改版。
仓库根 LICENSE 为 GPL-3.0，重新分发整套程序或修改版时应按该许可证履行源码与许可义务。CLI 和 MCP Server 的 package.json 另示为 MIT，但仓库没有在这两个目录中分别提供独立许可证文件；如果要抽取子包并闭源分发，不能只依据 package.json 的一个字段下结论，应向权利人确认具体授权范围。
版本判断与官方入口
GitHub 的 latest Release 仍指向 2021 年的 1.0.10，而 v2 README、扩展 package.json 和更新日志已经标注 2.0.9。判断当前扩展版本时应以 v2 分支清单和官方安装入口为准，不把旧 GitHub Release 徽章当作 v2 的最新版本。仓库在 2026 年 5 月 27 日仍有推送记录，但平台接口是否可用仍需结合自己的账号逐项验证。
- GitHub 仓库：https://github.com/wechatsync/Wechatsync
- 项目官网：https://www.wechatsync.com/
- 平台适配器规范：https://github.com/wechatsync/Wechatsync/blob/v2/docs/adapter-spec.md
- CLI 文档：https://github.com/wechatsync/Wechatsync/tree/v2/packages/cli
- MCP Server 文档：https://github.com/wechatsync/Wechatsync/tree/v2/packages/mcp-server
- GPL-3.0 许可证：https://github.com/wechatsync/Wechatsync/blob/v2/LICENSE
暂无评论内容