摘要：搭一套本地优先的公众号内容工作台，看起来是一堆 clone、install、配置文件的活。但实际上，整个过程我一个命令都没敲------克隆、安装、写 MCP 配置、配采集源、逐个测试，全是 AI Agent 干的。我做的事情只有两件：把要求说清楚，以及在它需要拍板的时候给一句话。这篇文章把那条指令模板原样给你，也把我踩的坑一起给你。
一、为什么自己搭
做公众号这段时间，我的工作流大概是这样的：开 10 个浏览器标签刷 36氪、虎嗅、Readhub，看到值得写的开另一个文档记选题，写完复制到排版工具调样式，再去 Canva 拼封面。内容生产本身可能只占 30%，剩下 70% 全是搬运和格式转换。
这套要介绍的工作台（wechat-editroom / wechat-newsroom-workbench）解决的正是这 70%：
- 采集：内置 RSSHub + 多种采集器，技术热榜、公众号、论文、GitHub 一个入口
- 成稿：热点 → 候选池 → 成稿 → 终稿，每一步可干预
- 排版与封面：基于账号画像自动定设计方向，过门禁校验后直接产出可用的 HTML 和封面图
- 本地优先：数据、配置、数据库全在自己机器上
但它最特别的地方不是功能，是它把整条流水线暴露成了 MCP 工具。这意味着操作者是 AI Agent，不是你。你不用打开任何管理界面，用自然语言就能驱动全过程------包括部署本身。
二、你只需要准备两样东西
- Git（任意近期版本）
- 一个支持 MCP 的 AI Agent 客户端：WorkBuddy 或 Codex
Node 都不用自己装：安装脚本会下载一份独立运行时到项目内的 .node-runtime\ 目录，不碰你的系统环境。版本要求也交给 Agent 去核实，它自己会查。
三、一条指令完成部署
新建一个任务，把下面这段话原样发给 Agent（把路径换成你想要的目录）：
请在本机将 github.com/shiker1996/... 的
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。门槛是你知不知道自己要什么，以及能不能把它说清楚。
回头看那条部署指令，它之所以好用，是因为做了四件事：
- 给了边界：「全新隔离项目」「不要复用其他项目的配置」------防止它图省事复用旧数据
- 设了检查点：「逐项问我」「保存前让我确认」「暂不创建批次」------把不可逆动作的开关留在自己手上
- 要求了证据 ：「实际调用
jianzi_doctor」「每个来源单独测试」------不允许它用「应该可以」交差 - 划分了责任：「先询问是否安装」------把需要判断的决策还给我
一句话总结：你不是在学一个工具，你是在学怎么当一个能派活的甲方。
仓库地址：github.com/shiker1996/... master分支）