用AI工作流把一篇内容变成一周推文：本地化流水线实战

为什么内容复用需要工程化思维

把一场演讲、一篇深度文章或一个视频教程拆成七天的社交媒体帖子，本质上是一个可重复的工程问题。原作者的思路值得借鉴：将源素材视为不可变数据，通过一系列确定性变换，最终把产物交给调度器发布。整条流水线可脚本化、可版本控制，并且在调用任何外部 API 之前都能在本地检查。

rss source: Repurposing One Piece of Content into a Week of Posts with an AI‑Driven Workflow

这种做法的好处很直接：成本可控、依赖透明、出错可回溯。尤其对独立开发者和小团队来说，与其依赖一堆 SaaS 工具拼接，不如自己搭一条轻量流水线。

第一步：把源素材提取到本地

如果源是视频，用 yt-dlp 下载最佳音质的音频，再用 ffmpeg 转成 16 kHz 单声道 WAV，这个格式对大多数语音转文字模型都很友好。

# 仅下载音频
yt-dlp -x --audio-format wav --audio-quality 0 "https://example.com/talk" -o "source/%(title)s.%(ext)s"
# 归一化为 16 kHz 单声道
ffmpeg -i source/*.wav -ar 16000 -ac 1 source/normalized.wav

如果源是文章，git clone 或 curl 拉取即可。关键是把原始文件放在 source/ 目录下，保证流水线的幂等性——重复运行不会产生不同结果。

第二步：分块与嵌入

大语言模型有 token 窗口限制，一次性喂入整份转录文本会丢失细节。作者建议用 tiktoken 这类轻量分词器，把文本切成约 1200 token（约 900 词）的重叠窗口，并记录每个块的字符偏移量以便后续引用。

import tiktoken, json, pathlib
enc = tiktoken.get_encoding("cl100k_base")
text = pathlib.Path("source/normalized.txt").read_text()
tokens = enc.encode(text)
chunks = []
for i in range(0, len(tokens), 1000):
    window = tokens[i:i+1200]
    chunks.append({
        "index": len(chunks),
        "text": enc.decode(window),
        "start_token": i,
        "end_token": min(i+1200, len(tokens))
    })
pathlib.Path("intermediate/chunks.json").write_text(json.dumps(chunks, indent=2))

如果后续需要语义检索，可以用一个 7–8B 参数、4 比特量化（Q4_K_M）的模型为每个块生成嵌入。模型文件约 5GB，在 16GB 内存的笔记本上运行绰绰有余。嵌入可以存在本地向量数据库（如 sqlite-vec）中，完全避免外部调用。

token 与分词器：LLM 并不直接处理字符，而是先把文本切分成 token——可能是完整的词、词的一部分或标点符号。tiktoken 是 OpenAI 开源的分词库，cl100k_base 是其常用编码方案，一个英文词通常对应 1–2 个 token，中文则更多。token 窗口是模型单次能处理的 token 上限，超出部分会被截断，所以长文本必须分块。

嵌入（embedding）：把一段文本映射成一个高维向量，语义相近的文本在向量空间中距离更近。嵌入不用于生成文字，而是用于语义检索、聚类和去重。原文提到的 Q4_K_M 是 GGUF 量化格式中的一种等级，对 7–8B 模型做 4 比特量化后体积约 4–5GB，精度损失可接受，是本地部署的常见折中。

第三步：生成草稿帖子

把每个块（或相邻几个块）交给 LLM，用严格的提示词要求输出单平台帖子：一个钩子、三条要点、一个行动号召、一组标签。要求返回 JSON 格式，方便下游步骤校验 schema。

# 向本地 llama.cpp 服务发起请求的示例
curl -s http://localhost:8080/completion \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "<|system|>You are a concise technical copywriter. Return JSON with fields: hook, bullets[3], cta, tags[5].<|user|>Chunk: '"$(jq -r '.[0].text' intermediate/chunks.json)"'
  }'

循环处理所有块，把每个响应写入 drafts/post_<n>.json。这里有个容易被忽略的细节：Webhook 或异步回调是“至少一次”投递，意味着同一个请求可能到达两次。因此生成器必须幂等——在输出文件名中包含块索引，并跳过已存在的文件。

第四步：护栏与校验

发布之前，跑一套确定性校验：

Schema 检查：用 jq 确保每份草稿包含必需字段。
长度检查：强制执行平台限制，例如钩子不超过 280 字符。
事实核查：用一个更小的模型扫描每条要点中出现的数字，只允许源块或 FACTS 列表中存在的数字（如模型大小、GPU 限制），防止幻觉。
去重：计算钩子加要点的哈希值，丢弃与之前某天重复的草稿。


**幻觉（hallucination）**：指 LLM 生成看似合理但实际不存在或与源材料不符的内容，例如编造数字、日期或引用。在自动化内容流水线中，幻觉会直接变成公开的错误声明，因此需要专门的事实核查环节。原文的做法是：用更小的模型抽取每条要点中出现的数字，与源块及 FACTS 白名单比对，不在列表中的数字一律拦截。这是确定性的字符串级校验，比让另一个 LLM 判断“是否准确”更可靠、更便宜。
# schema + 长度校验
for f in drafts/post_*.json; do
  jq -e 'has("hook") and has("bullets") and has("cta") and has("tags")' "$f" >/dev/null || { echo "bad schema: $f"; exit 1; }
  hook_len=$(jq -r '.hook|length' "$f")
  if (( hook_len > 280 )); then echo "hook too long: $f"; exit 1; fi
done

第五步：调度与发布

一个小型调度器（cron、systemd timer 或 GitHub Actions）按字典序取下一个未发布的草稿，调用平台发帖 API，然后把文件标记为 posted_<timestamp>.json。同样因为 Webhook 可能重复到达，发布步骤要记录平台返回的帖子 ID，并拒绝重复发布已存在于本地 SQLite 日志中的 ID。

幂等性（idempotency）：同一个操作执行一次和执行多次，系统状态应保持一致。在发布场景中，幂等意味着重复调用发帖 API 不会产生两条帖子。Webhook 的“至少一次”投递语义保证消息不丢，但允许重复，因此接收方必须自行去重。常见做法是为每个请求分配唯一键（如块索引或帖子 ID），在本地日志中记录已处理键，新请求到达时先查日志再执行。

运维实践中的几个坑

Mac GPU 的限制：Docker Desktop、Colima 和 OrbStack 都在 Linux 虚拟机中运行容器，无法通过 Metal 访问 Apple GPU。作者在重建 Mac 集群演示时，把推理迁移到了原生 llama.cpp 二进制，直接链接 Metal。

模型大小与硬件匹配：7–8B 模型 4 比特量化后约 5GB，16GB 笔记本能跑，但要给操作系统和向量数据库留余量。

权重转换：把 fp32 权重转成 fp16 可以把下载体积减半，加快首次拉取模型的速度。

人在回路：作者经营一个小型数字产品业务，AI 代理负责起草内容，但每一条声明上线前都由他本人审核。这正好对应上面的校验步骤——自动化不等于放弃把关。

内容审计的教训：作者审计自己九个产品的目录后，发现缺少视频课程、一个私有仓库和一个社区论坛。在推广前重写这些承诺，避免了后续的信誉问题。

早期文章数据：他最早 26 篇技术文章每篇阅读量不超过 30，说明分发机制比产出数量更重要。

纯浏览器工具：他做了一个免费的 10 题工具来估算每周自动化节省的时间，完全在浏览器端运行，证明了重计算也可以留在客户端。

Metal 与容器隔离：Metal 是 Apple 的 GPU 图形与计算 API，只有在 macOS 原生进程中才能直接调用。Docker Desktop、Colima、OrbStack 等方案本质是在 macOS 上跑一个 Linux 虚拟机，容器运行在该虚拟机内，无法穿透到宿主机 GPU，因此 Metal 不可用。这就是原文把推理迁移到原生 llama.cpp 二进制的原因——原生进程直接链接 Metal，才能用上 Apple 芯片的 GPU 加速。

这套流水线适合谁

如果你每周都在手动把长内容拆成短帖，这套方案值得一试。它的核心价值不在于用了多先进的模型，而在于把内容复用变成了可验证、可重复的工程流程。每一步都是纯函数式的变换，版本可控，本地可查，从一场演讲扩展到一个月的内容也不会带来意外成本或隐藏依赖。

原作者把完整测试版整理成了分步指南，并提供了一个免费的 AI 自动化审计工具，帮助判断先从哪个环节开始自动化。