第十三章：全流程实战——李明轩一晚上搞定 mx publish

案例背景

第五章里，李明轩让 Ralph 写出了"明轩说"工具箱的第一个命令 mx add——把选题灵感快速记到本地。那是一道小甜点。真正让他每晚凌晨 1 点睡不了觉的，是另一件事：

每写完一篇文章，他都要在 4 个平台（公众号、小红书、知乎、微博）上反复复制粘贴、手动配图、各自调整格式——一套流程下来一小时。

这一章，我们陪他用一晚上把这个痛点解决掉。目标：建一个 mx publish 命令，接受一篇 Markdown 源文稿，自动生成 4 个平台的差异化版本，并通过各平台的 API 或浏览器自动化一键发布。

这是全书的集大成案例。前面 12 章学的所有机制——帽子、事件、背压、记忆、并行、人机协作——你都会在这一个过程里看到它们协同工作。

第一步：环境准备

李明轩在第五章已经建好了 mx 项目目录，这一章直接在里面开工：

cd ~/code/mx
git status   # 确认工作区是干净的

他上次的 mx add 命令已经提交到 main 分支。现在他开启新的 Ralph 会话——Ralph 会自动从 .ralph/agent/memories.md 读回上次积累的项目经验（"项目用 pytest 做测试、灵感用 JSONL 存储"等），不需要重新介绍项目背景。

第二步：用 PDD 把想法问清楚（`ralph plan`）

模糊的想法不能直接交给 AI 实现，先问清楚。

ralph plan "我需要一个 mx publish 命令，读一篇 markdown 源文稿，
自动生成公众号、小红书、知乎、微博 4 个平台的差异化版本并发布"

审问者帽子开始工作。李明轩在键盘前一边回答，一边意识到很多细节他自己以前也没想清楚。

问题 1：

🎯 4 个平台的差异化规则你心里有固定套路吗？比如字数、语气、emoji、配图数量——还是每次看情况？

李明轩：有固定套路。公众号保持原长度、正式一些；小红书 800 字、口语化、带 emoji、分 5 段；知乎 1500 字、问答体；微博 3 条 140 字段子。

问题 2：

🎯 发布渠道你希望怎么对接？官方 API、还是用浏览器自动化（Playwright 之类）？

李明轩：优先官方 API。公众号、微博都有开放接口。小红书、知乎官方接口不对个人开放，这两个用浏览器自动化。

问题 3：

🎯 4 个平台并行发还是串行发？并行快，但一旦某个平台失败，另外三个已经发出去了，回滚会很麻烦。

李明轩：并行跑，但先加一个 --dry-run 模式：本地出 4 份成稿给我审一遍，确认无误再真正发布。

问题 4：

🎯 配图怎么处理？源文稿的图片引用，自动同步到 4 个平台，还是每个平台单独上传？

李明轩：源文稿的图片先统一存到本地 assets/，发布时各平台各自上传一次，返回各自的 CDN 地址。

问题 5：

🎯 失败处理：某个平台发失败了，怎么通知你？命令行报错、还是通过你配好的 Telegram？

李明轩：Telegram 推送。我发完基本就睡觉了，命令行看不到。

问答继续了十来轮。10 分钟后，架构师帽接过设计工作，生成了设计文档：

.agents/scratchpad/implementation/mx-publish/
├── requirements.md   # 澄清后的需求
├── design.md         # 架构设计
└── tasks.md          # 实现步骤分解

设计批评者帽又审查了一轮，提出"配图统一存入 assets/ 之前先做一次压缩，不然 4 平台重复上传大图太慢"。李明轩确认采纳，最终设计获批。

第三步：查看设计文档

花 5 分钟扫一遍设计文档（节选）：

概览：读一篇 markdown 源文稿，并行生成 4 个平台的差异化版本，通过官方 API 或浏览器自动化一键发布。

架构：

命令规格：

命令	说明
`mx publish <file.md>`	一次发到全部 4 平台
`mx publish <file.md> --dry-run`	只生成 4 份本地成稿，不真正发布
`mx publish <file.md> --platforms wechat,weibo`	只发指定平台

平台差异化规则（节选）：

wechat: 字数 ≈ 原长，正式语气，图片原尺寸
xiaohongshu: 800 字左右，口语 + emoji，分 5 段，段段配图
zhihu: 1500 字左右，问答体，引用原文数据要标来源
weibo: 3 条 140 字段子，第一条带链接，最后一条带话题

验收标准：

--dry-run 能本地生成 4 份成稿，风格符合规则
4 个平台各自有单元测试（mock 接口调用）
任一平台失败不影响其他平台，失败原因推送到 Telegram
4 平台并行，整个流程预期 2 分钟内完成

第四步：启动并行实现（`ralph run`）

设计文档准备好了。李明轩决定动用 Ralph 的并行能力——4 个平台各自是相对独立的模块，正好一个循环写一个。

他在项目里开 4 个终端，分别启动 4 个循环：

# 终端 1：主循环，实现公共框架（命令解析 / 调度 / 报告）
ralph run -H builtin:code-assist \
  --prompt ".agents/scratchpad/implementation/mx-publish/ 的 step-1-core"

# 终端 2：工作树循环，实现公众号平台（走 API）
ralph run -H builtin:code-assist \
  --prompt ".agents/scratchpad/implementation/mx-publish/ 的 step-2-wechat"

# 终端 3：工作树循环，实现小红书平台
ralph run -H builtin:code-assist \
  --prompt ".agents/scratchpad/implementation/mx-publish/ 的 step-2-xiaohongshu"

# 终端 4：工作树循环，实现知乎 + 微博两个平台
ralph run -H builtin:code-assist \
  --prompt ".agents/scratchpad/implementation/mx-publish/ 的 step-2-zhihu-weibo"

启动完最后一个，他关上屏幕去洗澡。晚上 23:10。

第五步：中途介入（Telegram）

23:45，他洗完澡躺下，顺手打开 Telegram。循环 3（小红书）推了一条：

⚠️  xiaohongshu loop blocked:
    Reason: "小红书没有公开的发帖 API。需要你确认改用 Playwright
    浏览器自动化，还是放弃这个平台？"

他在床上回了一句：

用 Playwright。另外把"小红书永远不要尝试走 API，直接浏览器自动化"写进记忆里，下次别再问了。

循环 3 自动继续。下一次迭代里它不仅切换到了 Playwright 方案，还把这条经验写进了 .ralph/agent/memories.md——日后任何涉及小红书的循环都会读到。

他关灯睡觉。

第六步：早上收割

06:45 起床，打开 Telegram：

✅ mx-publish main loop: 完成，8 次迭代，耗时 58 分钟
✅ wechat platform: 完成，12 次迭代，测试 9/9 通过，已合并
✅ xiaohongshu platform: 完成（中途切到 Playwright），测试 7/7 通过，已合并
✅ zhihu + weibo platform: 完成，18 次迭代，测试 13/13 通过，已合并

到电脑前查看结果：

ls -R mx/publish/

mx/publish/
├── __init__.py
├── cli.py                   # mx publish 命令解析
├── orchestrator.py          # 并行调度 + 结果收集
├── platforms/
│   ├── __init__.py
│   ├── base.py              # 平台抽象基类
│   ├── wechat.py            # 公众号（走 API）
│   ├── xiaohongshu.py       # 小红书（走 Playwright）
│   ├── zhihu.py             # 知乎（走 Playwright）
│   └── weibo.py             # 微博（走 API）
├── rewriters/
│   ├── wechat_rewriter.py
│   ├── xiaohongshu_rewriter.py
│   ├── zhihu_rewriter.py
│   └── weibo_rewriter.py
└── notifier.py              # Telegram 推送

tests/
├── test_wechat.py           # 9 个测试
├── test_xiaohongshu.py      # 7 个测试
├── test_zhihu.py            # 8 个测试
├── test_weibo.py            # 5 个测试
└── test_orchestrator.py     # 6 个测试

跑一遍完整测试：

python -m pytest
# 35 passed in 2.8s ✓

第七步：真·试用

李明轩拿昨晚定稿的一篇 3000 字文章测试：

# 先 dry-run，看 4 个平台的成稿对不对味
python -m mx publish articles/ai-transition.md --dry-run

# ✓ wechat: dist/ai-transition.wechat.md (2180 字)
# ✓ xiaohongshu: dist/ai-transition.xiaohongshu.md (790 字, 5 段, emoji ✅)
# ✓ zhihu: dist/ai-transition.zhihu.md (1480 字, 问答体 ✅)
# ✓ weibo: dist/ai-transition.weibo.json (3 条段子 ✅)

他 5 分钟扫完 4 份稿，两处小改后真发：

python -m mx publish articles/ai-transition.md
# ✓ wechat 发布成功：https://mp.weixin.qq.com/s/xxx
# ✓ xiaohongshu 发布成功：https://xiaohongshu.com/explore/xxx
# ✓ zhihu 发布成功：https://zhuanlan.zhihu.com/p/xxx
# ✓ weibo 发布成功：3 条 Thread
# 耗时：1 分 47 秒

以前要 1 小时的活，现在不到 2 分钟。

第八步：迭代加新功能——定时发布

第二天晚上，他想到一个新需求：定时发布——晚上写好，早上 8 点自动发出，这样早高峰能拿到更多自然流量。

他没有重新规划整个项目，直接用新需求启动增量循环：

ralph run -H builtin:code-assist \
  -p "为 mx publish 加一个 --schedule 参数，接受 HH:MM 格式，
  表示延迟到当天（或次日）那个时间点再真正发布。
  延迟期间用文件 + cron（或 apscheduler）实现，不要长驻进程。"

Ralph 读回已有代码和记忆里的项目经验（"小红书用 Playwright""测试放 tests/"），在已有基础上加了一个 scheduler 模块。35 分钟后完成，7 个新测试全部通过。整个增量迭代李明轩只在边上刷手机。

复盘：与手工方式对比

环节	手工方式	Ralph 方式
需求澄清	脑子里过一遍，常漏细节	问答式，10 分钟想清 10 个细节
设计	跳过，直接开写	有架构图、验收标准的设计文档
实现	串行写 4 个平台，精力耗尽	4 个循环并行，晚上睡觉时写完
测试	常常忘	每个平台都有覆盖测试
代码审查	自己审	独立的 Critic 角色挑剔
边界处理	漏掉（如小红书没 API）	中途 Telegram 提问，写进记忆
时间	约 2 天全投入	一晚上 + 早上 1 小时确认
物理在场时间	全程 10+ 小时	问答 10 分钟 + TG 2 分钟 + 审核 5 分钟 + 启动 ≈ 1.5 小时

一晚上，他一个人完成了过去两天的工作量，而且睡够了 7 小时。

什么时候 Ralph 表现最好

通过这个案例，可以总结出 Ralph 最适合的场景：

最适合：

能分解成多个独立模块的项目（4 个平台、N 个子命令）
有明确验收标准的功能开发
需要测试覆盖的代码
任务较为独立，不需要频繁的主观判断

需要更多人工介入：

需要大量创意和主观判断的工作（比如稿件最终定稿的文字取舍）
依赖外部系统鉴权的任务（账号密码要你亲自过）
需求非常模糊，连你自己也不清楚想要什么

本章小结

通过这个李明轩的真实案例，你见证了 Ralph 完整工作流的威力：

ralph plan：把模糊需求问成清晰设计
ralph run -H builtin:code-assist：多循环并行实现不同模块
循环内部：规划 → 构建 → 审查 → 终结，有测试、有质量门禁
Telegram 介入：关键决策远程回一句话即可
记忆机制：中途得到的经验（如"小红书不用 API"）自动沉淀，下次循环自动继承
增量迭代：新功能在已有代码上继续长，不用推翻重来

最关键的感受：这个项目从提需求到可用，李明轩物理在场时间不超过 1.5 小时。其余 8 个小时，Ralph 在他的电脑上一个人干了 4 个人的活。

下一章，我们深入 ralph.yml 配置文件，学习怎么把"明轩说的文风 + 审校规则"这类独特资产沉淀成自定义预设，让未来每一次循环都自动带上你的项目 DNA。

Keyboard shortcuts

让 AI 永不停歇：Ralph 自动化工作流实战指南