内容管线2.0：
从一次实验到自动化生产系统

一个月前，我做了一个实验：用一个输入主题，同时产出 PPT、公众号、网站文章、视频四篇内容。实验结果不错，但离"可持续"还有距离。之后几周，我把那个实验变成了一条真正的生产线——有编排器、有选题感知、有质量门禁、有外部信号触发。这篇是系统设计总结和优化路线图。

一、起源：为什么要从实验走向系统

上一篇 《一个主题，4个产出》 记录了我们用 AI 从单一主题同时产出四种内容形态的实验。那次实验的核心发现：

• 一次性实验做得再好，也不能自动化复用。 脚本之间靠手动拷贝文件，配图提示词写死在代码里，发布用不同的入口甚至不同的机器。
• 选题靠拍脑袋。 每次都是"想到了什么就写什么"，没有体系化的选题管理，也没有外部信号驱动。
• 质量没有反馈。 发出去的公众号文章如有排版问题、配图挂了，只能等读者反馈才知道。

结论很清晰：内容生产的前半段（创意→文稿）需要人，后半段（格式化→配图→分发→质量监控）可以交给系统。这个系统不能是一个巨大的单文件脚本，而应该是一组可组合、可独立演进的模块。

二、系统总览

当前管线系统部署在 ~/Documents/ 目录下，由以下组件构成：

2.1 编排层

2.2 产出层

2.3 自动化层

三、关键架构决策回顾

3.1 content-pipe.mjs：一切从这里过

content-pipe 是管线的大脑。它接收一个主题，按顺序执行：研究 → 内容包生成 → 并行产出 → QC → 知识库索引 → 报告。架构上的关键决策：

• 生产批次目录：每个主题一个独立目录 生产批次/{date}_{slug}/，各环节的中间产物都在这里，方便回溯。
• 干运行：--dry-run 模式只打印计划不执行，适合预览。
• 预览模式：每个产出类型都有 --preview，发布前检查。
• --suggest 双管道：先 domain-watch 扫外部信号，再 topic-sense 分析知识库缺口，双源交叉推荐。

3.2 公众号管线的三次迭代

公众号发布脚本经历了三次完整重写：

1. v0 (publish_didi_*.mjs)：硬编码版本，每个文章一个独立脚本，配图提示词写死在代码里。不可复用。
2. v1 (publish-via-api.mjs + publish-article.mjs)：通用化，支持参数传入，但两个脚本功能重叠。
3. v2 (publish.mjs + publish-playwright.mjs)：整合为单入口 publish.mjs（API 方案），publish-playwright.mjs 作为 Playwright 后备方案。新增 --config 参数支持 JSON 配置驱动，--preview 自动触发 QC 门禁。

三次迭代的教训：管线基础设施不要做文章定制。第一次我把图片 URL 硬编码了，第二次把配图提示词写死了。直到通用化为 JSON 配置文件驱动，才真正做到了"一次配置，多篇复用"。

3.3 选题感知的四个数据源

topic-sense 的选题策略最终演化为四个数据源交叉验证：

1. 知识库缺口：扫描 30-Notes / 40-Reading 目录，按 8 个领域标签统计覆盖度 🔴🟡🟢。
2. 外部信号：domain-watch 每天扫 Google News RSS + DuckDuckGo，按领域分类并评分相关度。
3. 产出历史：已产出内容自动延伸到系列文章。
4. 时间节点：季节性选题（夏季用电高峰、年中年末政策窗口）。

交叉推荐逻辑：当一个领域的外部信号密集（>3 条高相关度），同时知识库覆盖度低（🔴 缺口），这个选题自动提升为最高优先级。

3.4 质量门禁：从无到有

发布前最怕什么？配图挂了、标题太短、摘要超限。article-quality-gate.mjs 在 --preview 保存预览 HTML 后自动运行：

• 图片可达性：每张配图发 HEAD 请求检查 HTTP 状态码
• 标题完整性：标题不空、不超 64 字（微信限制）
• 摘要合法性：不超过 120 字
• 正文完整性：有足够段落，不是只有标题

G1 正确性检查在 30 秒内完成，G2 规范性和 G3 Taste 品味检查则交给人工判断。

四、还需要优化的地方

以下按 P0-P3 优先级排列：

🔴 P0 — 最痛

1. 研究阶段是占位符。 runResearch() 函数目前只写了一个骨架模板，没有真正的 LLM 研究能力。它应该在收到主题后，自动执行 web search + 知识库检索 + 研报消化，输出结构化的 research.md。

   目标：研究阶段自动产出 2000 字 + 关键数据 + 来源列表。

2. 生成 ≠ 发布。 publish.mjs 只创建微信草稿，不自动发布。原因是未认证订阅号没有 API 发布权限。这意味着即使管线全自动化，最后一步还是得手点。

   思考：这或许不是技术问题，而是平台限制。可以接受"草稿到达"作为管线终点。

🟡 P1 — 应优化

3. 视频管线质量不足。 SST 固态变压器视频是 HyperFrames 的第一个完整项目。虽然 QC 全通过（lint/validate/inspect 均零错误），但用户反馈"字体表现力不足、视觉效果偏静态、无字幕"。核心瓶颈是中文字体在 HyperFrames 中的渲染和深度科普视频的视觉叙事设计。

   方向：先建立一个视频模板库，再优化单篇质量。

4. 外部信号源单一。 domain-watch 目前只用了两个免费引擎（Google News RSS + DuckDuckGo）。对于中文行业动态，这两者的覆盖度一般。期望的信号源：RSSHub（公众号文章转 RSS）、雪球/东方财富（资本市场信号）、国家能源局/发改委官网更新。

   方向：逐个添加 RSS 订阅源，先到 5 个关键源。

5. 配图是单点故障。 Pollinations.ai 免费但不稳定——偶尔超时、偶尔返回空图、没有 fallback 机制。理论上微信 CDN 上传成功后图片就安全了，但上传前的下载环节是脆弱的。

   方向：本地缓存 + 多源 fallback（Unsplash / Pexels API 作为备选）。

🟢 P2 — 值得做

6. 没有失败告警。 launchd 定时任务失败没有人知道。脚本内部 try/catch 吞掉了很多错误。需要一个集中式的运行日志 + 关键失败通知渠道。
7. 网站管线未接入编排器。 目前这篇文章是手动写的 .astro 文件 + git push。content-pipe.mjs 虽有 --types website 但只生成 website.md 骨架，没有自动构建和部署。
8. 内容版本管理。 公众号草稿创建后，如果修改需要重新跑整个管线。不支持"增量更新"——改一段文字就得重新生成全文。
9. 测试缺失。 650 行的 content-pipe.mjs 和 480 行的 domain-watch.mjs 没有任何单元测试。每次修改靠手动运行验证。

🔵 P3 — 锦上添花

10. 多语言输出。 当前管线只产出中文内容。对于关注领域（电力市场、储能、AI+能源），部分优质来源是英文的。自动翻译 + 双语分发会增加覆盖面。
11. 信号热度衰减。 domain-signals.json 里的信号没有过期机制。一周前的政策信号如果没有被消费，应该自动降低优先级。
12. 内容日历可视化。 在个人网站上增加一个"已规划→生产中→已发布"的内容日历页面，既是编排工具也是透明度展示。

五、一些数据

六、小结：系统架构的一个原则

回顾整个过程，如果只用一个原则来总结，那就是：编排器不能替执行器做决定。

content-pipe 知道要产出什么，但它不决定选题。topic-sense 知道哪些领域缺内容，但它不能写研究稿。domain-watch 知道外面发生了什么，但它不判断值不值得写。每一层都只做自己擅长的事，通过结构化的数据契约（JSON、Markdown、exit code）和下一层通信。

这个原则在软件工程里叫"关注分离"（Separation of Concerns），在内容生产里叫"让 AI 做 AI 擅长的，让人做人擅长的"。

下一阶段的目标：把研究阶段从占位符变成真正能工作的模块，同时把视频管线的质量拉到和其他三条管线相同的水平。但那是下一篇文章的事了。

相关文章：
→ 《一个主题，4个产出：我用AI搭了一条从研究到交付的内容管线》
→ 《微信公众号配图自动化》
→ 《HUIIHONG PPT 模版开发》

道雷说道

每周推送投资框架与行业研究心得

深度研究抢先看

每周更新通知

互动交流探讨