第一层 · 先解决接力
换一个 session，进度和红线就断了
长任务会跨 session，也会由不同 agent 接手。只把状态留在 context 里，下一位接手者并不知道已经做过什么。
于是加上每个 topic 一份 STATUS 合同，进度、红线和交付路径都贴着工作文件保存。
About · 一条跑了几个月的 agent 流水线
从一整天，
到几个字
最初，做完一个选题会占掉我一整天。几个月后，同一条流程只需要几句很短的输入：agent 自己完成收集、筛选、核验、重组、双语网页和发布，我主要在关键节点做 verification。
以前1 天 / 选题
迭代几个月
现在几个字 / 步骤
人的角色verification
01 · 最初的一天
自动化开始之前，每一步都要有人把它推到下一步
genai-playbook 主要做的是把分散在不同来源里的材料收进来，筛选、核验，再重组成可以直接阅读和调用的双语页面。真正耗时间的不是打字，而是一个人要一直记着：现在做到哪、哪些数字还没核、哪条红线不能越、下一步该交给谁。
找材料、筛选、去重
先判断什么值得看，再确认没有和已经做过的主题撞车。
读原文、核事实和数字
把原始材料读完，逐项确认数字、引文和上下文没有走样。
重组、双语网页、配图
不是简单复制，而是重新搭结构，再分别生成中英文页面。
检查、部署、补发布状态
检查链接和图表，更新索引、站点地图以及发布记录。
一整天
这条链只要有一步忘了，后面就会带着错误继续跑。那时我既是调度器，也是执行者和检查者。流程能完成，但每个 topic 都要重新把整套工作手动走一遍。
02 · 中间的几个月
不是找到一个更聪明的 prompt，而是把人做的事一层层拿走
这条线不是一次设计出来的。它先跑起来，再暴露问题；每遇到一种重复失败，我就在 harness 里补一层。几个月后，人退出了大部分执行环节，但当初那些判断没有消失，它们换了一个地方继续工作。
人是这样一步步退出执行的
先让流程能跨 session 接力，再把“自己查自己”拆开，然后用代码接走稳定红线，最后才把日常调度压缩成几个字。自动化程度不是一次跳上去的。
第二层 · 再拆开自查
写稿的 agent 很容易批准自己的结果
它带着“我原本想表达什么”回头读稿，会自动补全缺失信息，也会顺着自己刚才的判断继续走。
于是加上全新的干净上下文来复查，写和评彻底分开，每一轮也不继承上一轮的判断。
第三层 · 拿走人眼检查
越靠近红线，模型的判断越容易飘
“差不多能放行”的边缘案例最危险。只靠模型临场判断，同一条规则今天和明天可能得到不同结果。
于是加上确定性兜底：能写成规则的红线由代码硬卡，模型判错也过不去。
第四层 · 拿走人工调度
每天把所有来源重跑一遍，只是在烧 token
深度雷达覆盖十四天窗口，一次全刷约 3M token、要 15–20 分钟；天天运行，大部分结果只是“已经覆盖”。
于是加上由编排层持有 plan 和刷新节奏：官方追踪每天刷，深度雷达超过三天才刷。
第五层 · 留下校准痕迹
看不见的判断，没法校准
只留下最后推荐结果，看不出候选在哪一关被剔除，也无法发现过滤器是不是误杀了好东西。
于是加上剔除和 verification 记录；去重同时检查索引表与磁盘目录两个真相源。
01Dynamic Workflow
脚本持有 plan，agent 只填每一格
选题不交给一个 agent 从头想到尾。约 190 行的 topic-selection.js 把控制流写死成四个 phase，脚本决定并行、等待和放行，agent 只填当前这一格。
脚本持有 plan
何时并行 · 何时等待 · 什么结果能进下一段，都写死在脚本里
phase 1
收集
一源一 agent
agent · 官方源agent · 深度源
并行 fan-out一源一 agent
phase 2
去重
三处一起比对
1 agent
废弃名单 · 索引 · 磁盘目录三处一起比对
phase 3
打分
一候选一评审
insight-filterinsight-filterinsight-filter
并行 fan-out一候选一评审
phase 4
排序
写进当天 shortlist
1 agent
入选 + 剔除记录写进当天 shortlist
schema · SCORE_SCHEMA每个 subagent 按固定 JSON 字段返回，不能交一段散文。
await parallel(...)并行只在 phase 内；barrier 保证残缺结果不提前流入下一段。
filter(isReal)就算 agent 说 keep，PR 内容或硬凑的 so-what 仍被代码踢掉。
02Subagent Loops
生成者不兼任裁判，复查也不继承上一轮的确信
复查不是“让原 agent 再看一眼”，而是每一轮都换一个全新 context 的 subagent 从零判断，一直循环到零问题或触达轮数上限。
Generator
生成产物
重组、写作或页面生成，不拥有放行权。
每一轮 · 全新 context
新审计员读原文＋产物列出问题清单主 agent 修复
下一轮再换全新 context：复核旧修复，但不把上一位审计员的判断惯性带进来
零问题 / 触达轮数上限退出 · 通过
FACT · 最多 6 轮逐条对照原始来源，零问题才退出。STYLE · precheck先由脚本清掉可确定的机械问题。STYLE · 最多 4 轮再让 fresh auditor 处理语义和语气。03Lifecycle Gates
Hook 的价值，是把检查钉在正确的生命周期里
这里的 hook 只指 genai-playbook 自己的流水线检查点，不是 ~/.claude 里的全局工具 hook。每道检查在固定时机由项目脚本触发：该拦的返回非零退出码，该留给人的集中列成待办。
Web 生成后
number-drift.py
report 与中英页面的可见数字做集合对账，页面多出的直接报漂移。
exit 1 · 拦截上传之前
publish-precheck.py
模板残留、登记、首页卡片、内链、双语互链、图表出处逐项查。
exit 1 · 拦截构建发布物
published.txt
已发布清单驱动统计、sitemap、搜索、MCP，避免各出口各记一份。
唯一真相源部署收尾
pending-status.py
扫每个 topic 的 STATUS，把 GSC、git push 等未勾人工项端出来。
人工待办03 · 今天的操作面
几个月的工程，最后折叠成了几句很短的输入
现在我仍然一段一段地启动流程，但不再亲手执行每个步骤。每句话只表达意图，harness 根据 PIPELINE 和当前 topic 的 STATUS 展开 plan，agent 和确定性检查负责把这一格填完。
今日选题
刷新信息源 → 去重 → 候选独立打分 → 排序落盘
人：看结果
做第一个
建立 topic → 读取原始材料 → 重组报告 → 两道复查
人：确认方向
生成 Web
中英分别生成 → 还原图表 → 数字对账 → 页面检查
人：验收
部署
发布门禁 → 更新索引 → sitemap → 页面上线
人：最终确认
输入很短，背后的计划很长
今天看起来简单，不是因为这件事本来就简单，也不是因为找到了一个万能 prompt。短输入只是几个月工程之后留下来的操作面；搜索逻辑、质量标准、失败处理和上下文接力都已经被放进 harness。
04 · 人在流程里的位置
人还在环里，但已经不在流水线上干活
我的工作从 execution 变成了 verification：给方向、触发下一段、在关键节点确认或驳回。重复执行交给 agent，不能波动的红线交给代码。
Human
方向与 verification
- 决定今天是否启动，以及先做哪个候选
- 在关键节点确认、驳回或调整方向
- 根据运行结果继续修改标准和红线
Harness + agents
执行、接力与逐项核验
- 展开 plan，并行调度，跨 session 保存状态
- 收集、去重、重组、双语页面、配图与发布
- 事实复查、风格复查、数字对账和发布门禁
写和评不是同一个脑子
事实核查最多 6 轮，用词风格审最多 4 轮。每轮使用新的干净上下文，先确认内容正确，再处理表达。
关键红线不看模型心情
数字对账曾抓到“接近 50%”被改成“约 48%”。能确定判断的部分由脚本硬卡，不靠人眼发现。
状态不放在模型记忆里
STATUS 保存 topic 状态，published.txt 是 sitemap 和首页统计的唯一真相源。新的 agent 只读文件就能继续接力。
对我这个单人站来说，这套分工的价值不是把人彻底拿掉。恰恰相反，它把人的注意力从大量重复动作中拿回来，只留在真正需要判断的地方。39 篇双语 Web 文章上线之后，我仍然会改规则，但已经很少再手动重走整条流程。
彩蛋 · 最后一件证据
这页不是这条流水线的说明书。
它是这条流水线刚刚交付的一件产物。
我给出方向和 verification；Claude 整理结构与约束，GPT-5.6 按 brief 生成正文，再由独立复查和确定性检查完成收尾。彩蛋不在页面的某个角落，而在这页是怎么被做出来的。
human direction
structured brief
cross-model draft
independent review
verification