上一篇讲了内容管道，但里面每个环节都还是我手动在跑。这一篇讲怎么把这些环节交出去：一条用户提 issue 许愿、机器人自己选点写稿开 PR 的「城市许愿」流水线，和支撑它的 8 个自定义 skills。

为什么要自动化

TestFlight 内测铺开之后，朋友们最常提的需求高度一致：能不能加我的城市？

手动加一座城市的完整流程是：选点、查坐标、写故事、定风险分级、生成插画、质检、发布。第四篇讲过，每一步都有讲究，人肉走一遍就是一个周末。朋友微信里说一句我手动加一座，或者我自己哪天拍脑袋想加一座，这么搞下来其实也可以，但听城最终是一个内容发布 App，之后是可能要 scale up 的，不自动化，这一点之后一定会把人累死。

于是干脆把「加城市」做成一条正式的流水线。

城市许愿 pipeline

流程大概长这样：

  1. 用户在 App 里反馈或者直接在 GitHub 上提一个城市许愿 issue；
  2. 我人工审一眼，打上 city-request 和 approved 标签（这是整条流水线里唯一的人工闸门）；
  3. GitHub Actions 检测到标签，把任务派发到隔离的 self-hosted runner；
  4. runner 调起 Codex，按选点 skill 的标准生成这座城市的候选点清单；
  5. Codex 开一个 draft PR，我 review，通过后走内容管道正式生产发布。
 1
 2
 3
 4
 5
 6
 7
 8
 9
10

city-request issue
        │ 我打 approved 标签
        ▼
GitHub Actions ──► 隔离的 self-hosted runner
        │                    │
        │                    ▼
        └──────────────► Codex 按 skill 起草候选清单
                             │
                             ▼
                        draft PR ──► 人工 review
GitHub Actions 中一次成功的 Build candidate PR 任务，日志展示纽约候选地点清单

6 月 28 日的一次真实运行：worker 用六分多钟生成纽约候选清单，表里已经带上优先级、现场可见线索、为什么是这里、来源和编辑风险。手机上可点图放大。

runner 喂给 Codex 的任务书值得贴一段，因为它先写的全是「不许做什么」：

你正在处理一条 City Whisper 的城市许愿。请使用选点 skill 的标准，但本次只生成候选清单 PR，不写正式运行数据。除了候选文档，不要修改其他文件，也不要发布内容……

V1 的边界收得很紧：只产出候选清单文档，不改 App 数据，不发布 R2，更不碰 TestFlight。自动化的每一级扩权，都必须是一个显式的决定，而不是「顺手就让它多干点」。候选数量也分了档：已有城市扩点给 10 到 15 个，普通新城市 25 到 35 个，遇到「大温」「湾区」「大洛杉矶」这种城市群直接 40 到 50 个。

工程边界收在两处：runner 使用独立 checkout，不复用日常开发目录；任务只获取生成候选清单需要的代码和资料。工作流按最小权限设计，自动步骤止于 draft PR，合并和发布仍要等我 review。

哦对，前两个愿望的来历：issue #1 温哥华是我自己提的，给整条流水线当端到端测试；issue #3 纽约是朋友许的，就是第三篇里那位在纽约玩、后来被我丢了数据的朋友。她的愿望算是圆满了，数据的事我们两清了吧。

翻车实录

流水线正式上线那天（6 月 25 日），git log 一天出现了 17 个 commit，其中一大半在修 runner 自己。任务参数、重复运行和 macOS shell 兼容性轮流出错，修好一个才暴露下一个。

session 记录里还留着更直接的证据：issue #1 的那段任务书 prompt，在当天的记录里出现了三次。同一个任务，重试了三遍才跑通。

让机器人干活的第一天，人类全程在给机器人修水管。不过水管修好之后，这套流程就一直很省心了。

为什么第一版用了 self-hosted runner

当时选 self-hosted runner，主要看中两件事。第一，Codex session 可以同步到手机，我出门时也能看到任务进度；第二，验证流水线时可以使用已有的订阅额度，不必先为云端调用单独做一套成本控制。

跑通以后，维护成本也摆在面前：自托管执行环境需要单独守住凭证、权限和任务输入。runner 应该与日常开发环境隔离，每次任务只拿完成候选 PR 所需的权限。托管 runner 能不能提供同样的可观察性，同时减少长期维护成本，成了这条流水线留下的后续题目。

8 个 skills：给机器人写岗位说明书

流水线能转起来，靠的是提前把领域知识写成了 skill。这件事我是一开始就规划好的：这个项目要 scale up 的话，选点、加插图、审计这些流程明显是重复的、可以按设计好的流程操作的任务，而且从一开始我就打算让多个 sub-agent 并行去做。

最后攒出来 8 个：选点撰稿、城刊策展、城刊封面、回声主题、地点插画、内容发布、Android 打包、iOS 审核预检。每个 skill 就是一份岗位说明书：干什么、怎么干、边界在哪、什么情况下要去找别的岗位。skill 之间还有显式路由，描述里互相指路：新增点位找选点 skill，组刊找城刊 skill，发布找发布 skill。像不像一个小公司的职责矩阵？

写 skill 的过程本身就是把流程想清楚的过程。而且有些规矩写在 skill 里比记在脑子里可靠得多，比如封面 skill 里写死的那条：城刊封面必须用户亲自过目确认才能定稿发布。

用量也能侧面印证哪些活儿最重：按 Codex 自己的统计，用得最多的是生成插画的 skill，其次是选点的。内容生产果然是这个项目真正的大头。

并行 subagent：插画量产

skills 里最有流水线感的是插画的多 worker 并行。直接贴一段当时给 worker 的任务书，这是全系列我最喜欢的一段 prompt：

你是 City Whisper 地点插画 worker E。任务：为大温 city pack 的 10 个点生成简洁黑白地点插图……你不是唯一 worker，其他 worker 会同时写同目录不同文件；不要修改/删除别人的文件，不要改 JSON、registry、git、发布脚本，不要跑 publish。风格要求：黑色细线、松散 urban sketchbook……

worker 编号到了 E，也就是说至少五个画手在同时开工。分工是这样的：worker 们只管画，一人领十个点，各画各的互不越界；主 agent 当美术总监，在 worker 干活的同时做风格一致性质检和审核。

这个方案是对比出来的。我实际试过三种方式：一张一张顺序生成、一个主 agent 自己生成多张、多个 worker 并行生成。结论是质量都差不多，但并行快得多。既然质量不掉，那当然是人多力量大。

顺便回答一个可能有人好奇的问题：五个 agent 同时生图，电脑烫不烫？一点都不烫，图是在 OpenAI 的服务器上生成的，我的 Mac 只是个调度台，风扇都不带转的。

接下来

这套自动化跑顺之后，加一座城市的边际成本从「一个周末」降到了「review 一个 PR」。但注意每个环节的最终判断还在人手里：approve 标签是我打的，PR 是我 review 的，封面是我过目的。自动化的是机械执行，不是审美taste。

下一篇这个系列就告一段落了：复盘这一个月「Claude 当产品经理、Codex 当工程师」的完整工作流，账单、翻车、以及哪些事到最后仍然只有人能做。