内容自动化管线

什么是内容管线

一条完整的链路：

监控源 → 抓取内容 → 加工生成 → 发布 → 记录

典型场景：监测几个信息源的新内容 → 翻译/改写 → 自动发布到内容平台，全程无人值守。

设计原则

原则一：脚本必须“直跑不需要交互”

定时任务运行环境没有人在旁边。任何等待用户输入的地方都会让它卡死。

// ❌ 会卡住
const answer = await prompt('确认发布吗？')

// ✅ 配置化
const BACKFILL_ENABLED = false  // 历史补发开关
const HEADLESS = true           // 无头模式

所有可能需要人拍板的地方，提前做成配置项。

原则二：日志必须落文件

node monitor.js >> cron.log 2>&1

不落日志的自动化 = 出问题时只能靠猜。日志要记：跑了什么、抓到几条、成功几条、失败原因。

原则三：区分“新内容”和“历史内容”

新上线的监测任务如果不限定范围，会把几个月前的老内容全发一遍。

做法：加状态记录（已处理 ID 列表）+ 历史补发开关（默认关闭）。需要补发时手动开一次。

原则四：幂等

同一个任务跑两次，不应该产生重复结果。已处理的要记下来，下次跳过。

抓取环节的注意事项

网络环境 国内环境访问部分境外站点需要代理。在脚本里配好代理地址和端口，不要依赖系统设置。

页面加载策略 等待 networkidle 经常超时，改成 domcontentloaded + 显式等待目标元素，稳定性提升明显。

反爬 控制频率、加合理的请求头。批量抓取要给间隔，别把对方站点搞崩。

生成环节

抓取来的内容通常要加工：

• 翻译（指定目标语言、保留专有名词）
• 改写（调整结构和长度，符合目标平台调性）
• 格式化（按平台要求排版）

保留原文链接和出处，既是尊重也是给自己留溯源。

发布环节

通过平台 API 发布时注意：

1. 先排期测试：用定时发布而不是立即发布，验证内容没问题再手动放行
2. 记录发布结果：成功/失败的 ID 记进日志
3. 失败重试：网络抖动导致的失败要能重跑，但要防止重复发布

一个完整配置示例

config.js

module.exports = {
  accounts: ['@account1', '@account2'],
  checkInterval: '0 */2 * * *',
  headless: true,
  proxy: 'http://127.0.0.1:7897',
  backfillEnabled: false,      // 历史补发，默认关
  logFile: './cron.log',
  publishMode: 'scheduled',    // 排期发布，不立即发
}

监控与告警

自动化跑起来不是结束，要能知道它挂了：

• 日志里连续 N 次失败 → 需要人工介入
• 长时间没产出 → 可能源站结构变了
• 定期（每周）人工看一眼日志

最容易被忽略的一点：源站改版会让选择器失效，抓取变成空结果。这类“静默失败”最危险——任务看起来在跑，实际什么都没做。

实战篇到此结束

五个实战场景覆盖了最常见的批量任务。核心方法论是一样的：先只读扫描、分批执行、落日志、留撤销余地。

下一步是 高手篇——把效率再压一层。