「把这个仓库全部弄下来做成 Primer，每个行业一个」——一句意图指令，怎么变成 16 篇、再变成五集 43 篇、再变成两集 17 篇？答案是侦察-执行循环：意图 → 侦察 → 方案 → 分批执行 → 归档。
循环解剖
第一步：侦察先于承诺
收到「全弄下来」后第一动作不是动手，是克隆全仓库、盘出 17 个域 425 个文件、每域多少技能多少字节——先知道货有多少，再谈方案。对外部 GitHub 组织的扫描同理：API 列表 → 克隆候选 → 实测内容量 → 分梯队。
第二步：方案是一份可否决的计划
三梯队、每梯队几篇、什么形态、排除什么（partner-built 版权纪律）——写成清单交给运营者裁定。方案的价值是把「全部」变成「可否决的分期」。
第三步：分批执行，批间留验收
digest → 写作 → 构建部署验证 → 下一批。每批结束线上可看，任何一batch出问题不影响已上站的批次。43 篇分五集走完，每集独立验收。
第四步：归档即收尾
SYNC-LOG 记账、MANIFEST 重出指纹、记忆更新——三个真相源同步完，任务才算结束。没归档的任务是没结束的任务。
循环里的三个加速器
- digest 中间层：不直接读 3MB 原文，先蒸馏成结构化摘要（技能名+描述+骨架），写作从摘要出发、按需回原文——上下文预算花在刀刃上
- 模板复用：第 2 篇之后每篇都站在模板上，写作速度翻几倍而质量不降
- 产线肌肉记忆：封面、构建、部署的 v56 定型态——工具链的确定性让人把注意力全部留给内容
一个诚实的边界
机器编目的终审仍占整体时间的四成——324 条洞察逐条过目、弱条手写替换、截断标题净化。侦察-执行循环压缩的是执行，不是判断；判断的质量决定成品的上限。这与法务插件「机器分诊、律师裁决」是同一条铁律的两种人生。