文章摘要(AI生成)
**概要** 1. **痛点与经验** - 之前在 OpenClaw、WorkBuddy 等通用 Agent 平台上跑公众号写作时，流程被“抓热点 → 分析热点 → 脑暴研判 → 选题评分”四个环节卡住。 - 每一步都需人工确认，导致自动化节省的时间被操作摩擦抵消；而让 AI 通过技能抓取热点、总结、复述则消耗大量 token，成本高且不稳定。 - 结论：通用编排工具适合临时任务，但不适合需要稳定重复的公众号写作链路。 2. **“见字”工作台的诞生与演进** - 从 Codex 技能封装开始，搭建了一套专门针对公众号的 Agent 工作台。 - 逐步扩展为完整链路：**热点采集 → 研判 → 选题 → 编辑室 → 成稿 → 配图 → 排版**。 - 只在编辑室保留人工回路，前置环节实现自动化；真正卡住产出的往往是热点抓取、事件聚类与选题判断。 3. **核心设计取舍** - **专而精**：不做“一键生成文章”，而是“公众号编辑工作台”。 - **固定工具清单 & 审批点**：热点采集、AI 标注、事件聚类、选题评分、成稿链、配图与排版可全自动串联；编辑室负责补证、观点输入、立场判断。 - **技术栈**：本地 Windows 单用户，Node.js 24 + SQLite + 浏览器 ES Modules，数据与密钥本机存储，产出 Markdown/JSON/HTML。 - **开源与可扩展**：31 个技能、8 个工具插件，完整文档、CI、测试与扩展点。 4. **行业共鸣** - 腾讯云《别急着让 AI 接管一切，先给它搭一个可复用的 Agent 工作台》与阿里云《Agent Apps：Agent 时代，大家都在造工具箱，但真正缺的是“工作台”》均强调“环境级默认允许，行为级关键动作闸门”与“没有工位”。 - 认为让写作链路稳定的关键是固定工具、审批点与产物目录，而非单纯追求更强模型。 5. **适用边界与建议** - 适用于本地单用户、想把热点–选题–成稿–配图–排版的重复环节交给机器、观点与判断保留给自己的公众号运营者。 - 不适合多人在线协作或完全无人值守的自动发布。 - 邀请读者讨论：在自己的公众号流水线中，哪些步骤留给人，哪些交给 Agent？
之前我用 OpenClaw、WorkBuddy 这类通用 agents 平台跑公众号写作，卡在同一个地方：抓取热点、分析热点、脑暴研判、选题评分，每一步都要人工确认；如果让 AI 通过技能自己抓热点，每次执行都会烧掉不少 token。跑过几轮后我的结论是：通用编排工具适合临时任务，不适合公众号写作这种需要稳定重复的链路。所以我做了“见字”（wechat-newsroom-workbench）——一个专而精的公众号写作 Agents 工作台，把热点到选题自动化，只在编辑室保留人在回路。
从封装一个技能，到搭一个工作台
项目从 Codex 技能封装起步。随着不断改进，它逐步演进到“热点采集—研判—选题—编辑室—成稿—配图—排版”的完整工作台。这也说明，真正卡住产出的往往不是“写”，而是热点抓取、事件聚类、选题判断这些前置环节。
我遇到的两个真问题
用通用平台时，问题分两类。
第一类是流程确认成本。每个环节都被设计成需要人工确认的节点：抓取热点要确认，分析热点要确认，脑暴和选题评分也要确认。逐环节点下来，自动化省下的时间又被操作摩擦吃回去了。
第二类是 token 消耗。让 AI 用技能抓取、总结热点，每次执行都是一条完整工具链，token 花在“读取—总结—复述”上，而不是花在写作判断上。我的判断是：很多程序化操作根本不值得交给模型，改用代码更稳定，也更省。
设计取舍：专而精，而不是一键生成
“见字”的产品形态是“公众号编辑工作台”，不是“一键生成文章”。热点采集、AI 打标与事件聚类、选题评分、00~09 成稿链、配图与排版可以自动串联；编辑室环节负责补证、输入观点和心得。也就是说，选题值不值得写、文章立场怎么定、数据怎么补，这些靠编辑判断，重复劳动交给流水线。
技术选型也朝这个目标收敛：本地优先的 Windows 单用户工作台，Node.js 24 原生 HTTP + node:sqlite + 浏览器端原生 ES Modules，数据与密钥不出本机，产物是 Markdown/JSON/HTML 文件；内置 31 个技能与 8 个工具插件，文档、CI、测试与扩展点完整，仓库已开源。
这个取舍有同行印证
腾讯云开发者社区《别急着让 AI 接管一切，先给它搭一个可复用的 Agent 工作台》给出了相近方案：“环境级默认允许，行为级关键动作闸门”——在安全的工作台里让 Agent 默认做高频低风险动作，遇到发送、删除、公开发布再交回人工。阿里云开发者社区《Agent Apps：Agent 时代，大家都在造工具箱，但真正缺的是“工作台”》则把问题概括成“Agent 有手，但没有工位”，缺的不是工具，而是一个可操作、可理解、可持续工作的环境。
我的判断是：让写作链路稳定的，往往不是更强的模型，而是固定工具清单、固定审批点、固定产物目录。
适用边界
见字是本地优先的 Windows 单用户工作台，不是多人在线系统；“热点到排版自动串联”也不是全自动发布，发布前的人工闸门依然保留。如果你需要团队协作的内容平台，或者想要完全无人值守地生成并发布，这个项目不匹配。但如果你和我一样，一个人维护一条公众号编辑链路，只想把“热点—选题—成稿—配图—排版”里的重复环节交给机器，观点和判断留给自己，这个形态目前最顺手。
你会在自己的公众号流水线里，把哪一步留给人、哪一步交给 Agent？欢迎留言聊聊你的取舍。
评论区