文章摘要(AI生成)

利用AI Agent（如WorkBuddy/CodexNode）搭建本地优先的公众号内容工作台，实现从克隆到出稿的全流程自动化，仅需提供Git和MCP兼容的AI Agent客户端即可完成部署。核心做法是通过一套指令模板让AI Agent负责环境配置、采集源设置和内容生成，最终产出可用的HTML和封面图，解决了传统内容生产中70%的搬运和格式转换工作。关键优势在于将整条生产线暴露为MCP工具，让操作者是AI Agent而非人工，支持本地优先的独立运行时和配置隔离。文章分享了实际部署中的三大坑点：配置层级不匹配导致连接不弹出、单测与真实采集不一致的需求以及部分采集器未正确启用。

我一句话让 AI 把公众号工作台搭完了：部署指令模板 + 实测记录

摘要：搭一套本地优先的公众号内容工作台，看起来是一堆 clone、install、配置文件的活。但实际上，整个过程我一个命令都没敲——克隆、安装、写 MCP 配置、配采集源、逐个测试，全是 AI Agent 干的。我做的事情只有两件：把要求说清楚，以及在它需要拍板的时候给一句话。这篇文章把那条指令模板原样给你，也把我踩的坑一起给你。

---

一、为什么自己搭

做公众号这段时间，我的工作流大概是这样的：开 10 个浏览器标签刷 36氪、虎嗅、Readhub，看到值得写的开另一个文档记选题，写完复制到排版工具调样式，再去 Canva 拼封面。内容生产本身可能只占 30%，剩下 70% 全是搬运和格式转换。

这套要介绍的工作台（wechat-editroom / wechat-newsroom-workbench）解决的正是这 70%：

• 采集：内置 RSSHub + 多种采集器，技术热榜、公众号、论文、GitHub 一个入口
• 成稿：热点 → 候选池 → 成稿 → 终稿，每一步可干预
• 排版与封面：基于账号画像自动定设计方向，过门禁校验后直接产出可用的 HTML 和封面图
• 本地优先：数据、配置、数据库全在自己机器上

但它最特别的地方不是功能，是它把整条流水线暴露成了 MCP 工具。这意味着操作者是 AI Agent，不是你。你不用打开任何管理界面，用自然语言就能驱动全过程——包括部署本身。

二、你只需要准备两样东西

1. Git（任意近期版本）
2. 一个支持 MCP 的 AI Agent 客户端：WorkBuddy 或 Codex

Node 都不用自己装：安装脚本会下载一份独立运行时到项目内的 .node-runtime\ 目录，不碰你的系统环境。版本要求也交给 Agent 去核实，它自己会查。

三、一条指令完成部署

新建一个任务，把下面这段话原样发给 Agent（把路径换成你想要的目录）：

请在本机将 https://github.com/shiker1996/wechat-editroom.git 的 codex/external-agent-tools 分支克隆到 E:\Jianzi。这是全新隔离项目，请使用自己的配置、数据库和数据目录，不要复用其他项目的本地配置或 RSSHub。运行 setup-workbench.cmd，安装选项逐项问我，RSSHub 先询问是否安装；然后运行 start-workbench.cmd 和 npm run jianzi -- install --agent workbuddy。

在客户端信任项目并刷新 MCP 后，实际调用 jianzi_doctor 确认连接，并确认能看到 jianzi_* 工具和项目 Skills。

再带我配置账号画像和采集源：保存前让我确认，每个来源单独测试，暂不创建批次。

这段指令里藏了几个关键设计，最后一节会拆。先说它启动后 Agent 会自动干完什么——以下全部是真实执行过程：

环节	Agent 实际做的事
环境核实	检查磁盘可用性、git 版本、Node 版本，发现系统 Node 不满足 ≥24，转而确认脚本会自动下载独立运行时
克隆	拉指定分支到目标目录
安装	后台执行 setup 向导，含 Node 24 下载、依赖安装、配置生成、独立 RSSHub 克隆
启动与接入	跑 start-workbench.cmd、注册 Agent 集成
MCP 打通	发现配置层级问题并自行修正（见踩坑一），写入用户级配置
连接验证	真的调用一次 jianzi_doctor，拿回 connected: true 和进程 PID 才算完
采集源	建 7 个源、逐个单测，附测试结果表格

图 1：WorkBuddy 汇报实际克隆目录、隔离方案、Node 环境和安装选项。

注意最后两行：它没有「配置完成，请你测试」这种把活推回来的说法，而是自己调到通为止。

四、你真正要动手的只有三件事

1. 把工作空间切到项目目录

Agent 客户端必须在项目目录下开会话，项目的 Skills 和 MCP 才会被加载。WorkBuddy 里是：新建任务 → 输入框左下角「选择工作空间」→ 定位到项目目录。首次访问会请求目录授权，点允许。

这一步为什么不能交给 Agent？因为它跑在哪个目录，是客户端决定的，Agent 改不了自己脚下的地。

图 2：切换到 E:\Jianzi 工作空间后，项目 Skills 和 MCP 才会进入当前任务。

2. 在客户端里点「信任」

MCP 服务是新进程，客户端需要你手动信任。这里有个坑，见下一节。

3. 回答它的提问

这就是我全部的输入了。真实对话里我只回了四句：

我说的	它在等什么
「AB吧」	采集源分组方案二选一（A 组技术热榜、B 组技术公众号，共 7 个源）
「我公众号是技术一线，定位是关注我每天追踪新的技术动态，面向技术人、程序员」	账号画像里它猜不了的事实：名称 + 定位
「这个咋切换？」	我反过来问它工作空间怎么切
「ok，确认了」	信任完成，让它继续

注意第二行：它当时明确说了「这 4 项还需要你给事实，我不能替你猜」。账号名称、定位、核心读者这类事实，不要指望 AI 编——它编出来的画像会让后续所有成稿和排版都跑偏。

图 4：账号画像按确认内容保存，七个采集源分别测试通过，尚未建批次。

五、踩坑实录

坑一：让你信任服务，但你找不到弹窗

这是最消耗时间的一个。根因不在客户端，在配置层级：

安装脚本把 MCP 条目写进项目级 .mcp.json，而 WorkBuddy 读的是用户级 ~/.workbuddy/mcp.json。后者不存在 → 没有条目 → 连接器列表里没有「待信任」项 → 当然不弹窗。

你只需要说一句「没看到弹窗啊」，然后让它去查配置层级。 它会发现这个差异，把条目挪到用户级文件，重写、校验、重启服务，再用 MCP 通道复核一次（确认走的是 MCP 而不是命令行兜底）。

图 3：连接修复并刷新后，客户端显示 47/47 个 jianzi_workbench 工具已启用。

坑二：source_test 通过 ≠ 真能用

配置新采集源时，单测通过只说明路由能返回内容。真实采集走的是另一条代码路径。所以我在指令里写了「每个来源单独测试」，而 Agent 在单测之后又自己加跑了一次小规模真实采集——这一步值得坚持，否则你会以为源是好的，直到某天采集任务静默失败。

坑三：部分采集器默认不启

第一次采集只跑了 RSSHub，Reddit、GitHub 等因为未配置/未认证被跳过。jianzi_doctor 会把 ✅ 和 ❌ 列清楚（我那次 Reddit 是 9333 端口没起、GitHub 无 token），先看诊断再决定补哪些。

六、效果

部署完的第一次真实采集：

项	结果
采集范围	近 24 小时
上报 / 入库	126 条 / 121 条
耗时	约 9 秒

之后写稿的流程是这样的：我说「就第一条吧」，它加候选池、抓原文、多来源互证事实；确认后转终稿、排版、做封面。排版设计方向会参考账号画像——我那篇讲 Codex 额度合并的稿子，它给的方案是「账本感」：米白纸底、铁锈橙点色、细线分章，理由是「这篇讲的本来就是一笔算不清的账」。封面同样先出设计说明再渲染，都过门禁校验。

七、这套方法真正的门槛

不是命令行——那部分完全可以外包给 Agent。门槛是你知不知道自己要什么，以及能不能把它说清楚。

回头看那条部署指令，它之所以好用，是因为做了四件事：

1. 给了边界：「全新隔离项目」「不要复用其他项目的配置」——防止它图省事复用旧数据
2. 设了检查点：「逐项问我」「保存前让我确认」「暂不创建批次」——把不可逆动作的开关留在自己手上
3. 要求了证据：「实际调用 jianzi_doctor」「每个来源单独测试」——不允许它用「应该可以」交差
4. 划分了责任：「先询问是否安装」——把需要判断的决策还给我

一句话总结：你不是在学一个工具，你是在学怎么当一个能派活的甲方。

---

仓库地址：https://github.com/shiker1996/wechat-editroom（master 分支）