第 28 章 内容生产工作流
第 27 章把代码审查做成了可复用的对抗式流水线,本章把同一条思路搬到写作上:长文档不是"聊"出来的,而是"编排出"来的。前面所有章节的功夫——Plan Mode、Subagents、Bash 校验、Skills——在这里汇成一条可复用的内容生产线。
28.1 结论:长文档生产靠分而治之,不靠单次生成
一句话结论:用 Claude Code 做长文档内容生产,核心策略是分而治之——主代理出大纲 → 并行子代理写章 → 主代理汇总审校。任何试图让模型"一次写完三万字"的做法,都会撞上 token 截断或质量衰减,二者必居其一。
分而治之的落地图:
┌──────────────────────────────────────────────────────────┐
│ 长文档生产三步法(Divide & Conquer) │
├──────────────────────────────────────────────────────────┤
│ Step 1 大纲 主代理 8-12 章 + 论点树 用户确认 │
│ Step 2 写章 子代理 每代理 2-3 章 并行执行 │
│ Step 3 汇总 主代理 衔接 + 一致性审校 增量合并 │
└──────────────────────────────────────────────────────────┘这条策略把第 06 章的可执行闭环从"代码"迁到"文档":完成状态从"测试通过"换成"字数达标 + 事实核实 + 术语一致 + 标题层级统一",而这些都是机器可检查的。一旦可检查,Claude 就能自己跑校验、读失败、自我修正。
本章给出两条已验证的工作流——学术论文六阶段(28.5)、案例驱动技术白皮书七阶段(28.6),以及通用技巧(事实核实、合并校验、增量写入)。子代理并行编排的底层机制在第 19 章(Subagents)与第 20 章(Dynamic Workflows,research preview)详述,本章只讲怎么把它们拼成写作流水线。
28.2 长文档生成的两个必然失败
为什么不能"一句话让它写完整篇"?两个物理限制:
失败一:token 截断。即便上下文窗口有 200K tokens,单次输出上限远小于此(Opus 4.8 单次输出约 64K tokens 上限,实际写作质量在 8-10K tokens 后明显下降)。三万字的中文稿约 4-6 万 tokens,看似塞得下,但模型不会"匀速写完"——它会在中段开始省略、在后段开始套话。
失败二:注意力衰减。长上下文里,模型对早期指令的遵循率随长度下降(第 11 章详述)。你在大纲里规定"每案例必须含 ATT&CK 表",写到第六个案例时它已经忘了。表现为:前两章结构严谨,后两章结构坍塌;同一术语前后两种翻译;数字前后不一致。
两个失败的共同解法是把一次大生成拆成多次小生成,每次小生成都在新鲜上下文里只做一件事。这就是分而治之的物理依据。
28.3 分而治之三步法
Step 1:大纲(主代理,用户确认)
主代理在 Plan Mode 下产出大纲,这是整条流水线的承重墙。
任务:
- 阅读用户提供的素材 @素材路径
- 产出大纲 outline.md,包含:研究问题、论点树、8-12 章目录、每章 200 字摘要、图表清单
- 不要写正文
约束:
- 每章摘要必须可独立成稿(子代理只读自己那章摘要)
- 章节间依赖显式标注(如"第 5 章引用第 3 章数据")
- 字数:大纲本身 2000-4000 字
完成输出:
- outline.md
- 在对话里给出目录树,等我确认后再进 Step 2命令:在 Claude Code 里进入 Plan Mode(Shift+Tab 两次,或 /plan),贴入上述任务。
预期输出:outline.md 文件 + 对话内的目录树。
验证:
wc -w outline.md字数在区间内- 人工检查:每章摘要是否自洽(不依赖其他章的隐含上下文)
grep -c "^##" outline.md章节数在 8-12
失败边界:大纲未确认就进 Step 2 是最贵的返工。一章返工 = 一个子代理白跑,8 章返工 = 整批白跑。Step 1 的产出必须经用户明确确认(口头"继续"或修改大纲后再确认),才能进 Step 2。
Step 2:并行写作(子代理,每代理 2-3 章)
主代理把大纲拆成 N 个子任务,每个子代理拿 2-3 章 + 共享的术语表 + CLAUDE.md,在独立上下文里写。
子代理任务模板(每代理一份):
- 读取 @outline.md 中你负责的第 X-Y 章摘要
- 读取 @glossary.md(术语表,强制遵循)
- 读取 @CLAUDE.md(风格、字数、质量标准)
- 写 drafts/v1/{NN}-{slug}.md,每章 2000-3000 字
- 禁止联网(事实已沉淀在 sources/facts/,只读不改)
- 禁止修改其他章节
完成输出:
- 章节文件路径
- ≤80 字摘要(用了哪些 facts、是否缺数据)命令:用 Agent 工具批量 spawn,run_in_background: true,在一条消息里发出所有 Agent 调用以并发执行(详见第 19 章)。
预期输出:drafts/v1/ 下若干章节文件。
验证:
ls drafts/v1/*.md | wc -l文件数 = 预期章节数wc -w drafts/v1/*.md每章字数达标grep -L "待复核" drafts/v1/*.md排查未核实标记
失败边界:
- 章节间术语不一致——子代理各自翻译同一术语。根治:Step 1 同步产出
glossary.md,子代理 prompt 里强制"术语只读 glossary,不得自创翻译"。 - 数字漂移——同一事实在不同章写成不同数字。根治:事实先沉淀到
sources/facts/(见 28.6),子代理只读不造。 - 子代理联网撞 429——WebSearch 限流会让一批子代理同时失败。根治:Step 2 子代理禁用联网,事实核实前置到 Step 1.5(见 28.7)。
Step 3:汇总(主代理,衔接与一致性)
所有章节写完后,主代理做衔接与一致性审校,产出终稿。
任务:
- 读取 drafts/v1/*.md 全部章节
- 补写:执行摘要、各章过渡段、总论章
- 统一:术语(对照 glossary.md)、标题层级、引用编号
- 合并:用 awk 状态机统一标题层级(代码块感知)
- 产出 whitepaper.md / paper.md
约束:
- 不改写章节正文,只做衔接与统一
- 发现事实冲突 → 标注"待复核",不擅自改数
验证:
- 运行 checks/verify.sh(标题清单、CVE 一致性、术语一致)
- 字数压缩到目标区间命令:主代理在 default 模式下执行,Bash 跑合并脚本与校验脚本。
预期输出:终稿 + 校验报告。
验证:
bash checks/build.sh # 合并
bash checks/verify.sh # 校验
wc -w whitepaper.md # 字数失败边界:事实未核实就成稿是内容生产的致命伤。Step 3 不会新增事实核实,它只做衔接——所以 Step 1.5 的事实核实必须先做完。如果到 Step 3 还在发现"这个数字没来源",说明 Step 1.5 偷工了,回退重做。
28.4 两种辅助策略:增量写入与骨架→扩写
三步法之外,两种策略在特定场景更优:
增量写入(顺序追加)。适合连续叙事、强依赖前文的内容(如教程、连载)。主代理写完第 1 章 → 追加写入第 2 章 → ... 每章都读前一章结尾。优点是衔接自然、无 429 风险(单代理顺序跑);缺点是慢(无并行)。实现:每轮对话用 Edit 在文件末尾追加,或用 Bash cat >> file。
骨架→扩写(精确控结构)。适合结构高度敏感的内容(如合规文档、标书)。第一步让模型只产出骨架(每节标题 + 一句话),第二步对每个骨架节点单独扩写。优点是结构完全可控、可逐节点验收;缺点是轮次多。实现:骨架存 skeleton.md,扩写时 @skeleton.md + 指定节点 ID。
| 策略 | 适用 | 速度 | 结构控制 | 衔接自然度 |
|---|---|---|---|---|
| 分而治之三步法 | 通用长文档 | 快(并行) | 中 | 中 |
| 增量写入 | 连续叙事 | 慢(顺序) | 低 | 高 |
| 骨架→扩写 | 合规/标书 | 中 | 高 | 低 |
选型原则:结构敏感选骨架,叙事敏感选增量,通用选三步法。复杂项目可混用——白皮书的框架章用骨架(精确控结构),案例章用三步法(并行加速)。
28.5 实战 A:学术论文写作六阶段
这是一条已验证的可复用工作流,源自一次"虚构主题"压测:主题"基于大语言模型的高校智能信息服务系统设计与实践",117 个 Agent、约 22 分钟产出 ~15,747 字初稿 + 26 篇文献索引。
目录结构(必建)
~/papers/{paper-name}/
├── CLAUDE.md # 论文项目指令(定位/格式/红线)
├── outline.md # 大纲与论点结构
├── sources/
│ ├── index.md # 文献索引表
│ └── notes/ # 阅读笔记
├── drafts/v1/ # 初稿(01-06 章节)
├── paper.md # 最终合并稿
├── references.bib # BibTeX 参考文献
└── meta.md # 目标期刊/格式/进度六阶段
| 阶段 | 工具 | 产出 | 并行度 |
|---|---|---|---|
| 1. 选题论证 | /deep-research(Bundled Workflow) | outline.md | 1 |
| 2. 文献检索 | 3 个并行 Agent(按维度分头) | sources/index.md + references.bib | 3 |
| 3. 方法设计 | Agent(方法论专家角色) | drafts/v1/03-methodology.md | 1 |
| 4. 结果分析 | Agent + Bash(Python/R) | drafts/v1/04-results.md | 1 |
| 5. 章节撰写 | 6 个并行 Agent(每章一个) | drafts/v1/0X-*.md | 6 |
| 6. 审校成稿 | Bash 一致性脚本 + Agent 审校 | paper.md | 1 |
Stage 1 的 /deep-research 是 Bundled Workflow(第 06 章命令真实性 D 类),它自己做扇出搜索 + 对抗验证 + 引用报告,最耗时(约 10 分钟),但能产出带引用的研究现状——这是学术论文的文献底座。其余阶段并行执行,总耗时被 Stage 1 主导。
Stage 5 的 6 个并行 Agent 是三步法 Step 2 的实例:每代理一章,读 outline 中自己那章的摘要 + sources/index.md,禁联网(文献已沉淀),写 drafts/v1/0X-*.md。
Stage 6 的审校 三个动作:引用一致性(正文 [1] 与 references.bib 对齐)、数据跨章节一致(同一数字不能两章不同)、字数压缩(初稿通常超标)。
验证与失败边界
验证:
# 引用一致性
grep -oE '\[[0-9]+\]' drafts/v1/*.md | sort -u
# 字数
wc -w drafts/v1/*.md paper.md失败边界:
- 虚构数据/案例未替换——压测用的虚构主题产出的是虚构数据,正式投稿前必须替换为真实内容。Agent 不会自己声明"这是编的",需人工逐数字核对。
- 架构图缺失——Claude 可生成图表描述文本,但不直接出图,需人工用工具补。
- 初稿字数超标——Stage 6 必须压缩到目标范围,不要直接交。
- 红线——不自动 push/publish(继承用户全局 CLAUDE.md),投稿是人工动作。
28.6 实战 B:案例驱动技术白皮书七阶段
与学术论文的区别:白皮书弱化学术环节(文献综述、方法论专家),加重事实核实(SoT)与可操作检查表。这条工作流源自一次实战:Linux/Windows 近十年安全事件 8 案例,约 14 个 Agent、30 分钟产出 ~3.02 万字终稿。
三条不变量
- 案例驱动——用代表性案例承载论点,每案例按统一模板展开。
- 事实单一来源(Single Source of Truth, SoT)——所有数字/CVE/日期先沉淀到
sources/facts/,撰写只读 facts 不再造数;权威元数据单独成基准文件(如cve-verified.md)。 - 双轴分析框架——每案例用统一框架拆解(如 ATT&CK 杀伤链 × CIA 三性),使异质案例可横向对比。
七阶段
| 阶段 | 谁做 | 产出 | 关键纪律 |
|---|---|---|---|
| 0. Plan 确认骨架 | 主代理 + 用户 | plan 文件 | 先问 3 参数(见下) |
| 1. 项目骨架 | 主代理 | CLAUDE.md / meta.md / outline.md | 无规范不动手 |
| 2. 事实核实 | 并行 Agent(每案例 1 个) | sources/facts/{slug}.md | 禁可运行代码、≤100 字摘要 |
| 3. 框架章 | 主代理自写 | 引言/框架/对比/总论 | 论点性强,自写质量更高 |
| 4. 案例章 | 并行 Agent(每案例 1 个) | drafts/v1/case-{slug}.md | 禁联网、数字只来自 facts |
| 5. 检查表附录 | 主代理自写 | Checklist(含命令/配置) | 白皮书的核心实用价值 |
| 6. 审校合并 | 主代理 + Bash | whitepaper.md | awk 代码块感知合并 |
Stage 0 的 3 参数(AskUserQuestion 首问):
- 产出定位:行业白皮书 / 学术论文 / 技术报告
- 组织方式:按维度分章 + 对比章 / 按时间线 / 按类型分章
- 案例策略:每维度 N 个深度案例 / 旗舰案例 + 概述 / 广覆盖
Stage 3 vs Stage 4 的关键取舍:框架章(引言、分析框架、对比、总论)论点性强、需跨章统一口径,主代理自写质量更高且无 429 风险;案例章量大、模板化,并行 Agent 高效。这是"什么该并行、什么该串行"的判断样本——模板化的并行,论点化的串行。
验证与失败边界
验证(Stage 6 的两条脚本):
# build.sh: 合并,awk 状态机只对代码块外标题降级
awk 'BEGIN{c=0}/^```/{c=!c;next}!c&&/^#+/{sub(/^#/,"##")}{print}' \
drafts/v1/*.md > whitepaper.md
# verify.sh: 代码块外标题清单、CVE 一致性、估算措辞、残留旧标题
bash checks/verify.sh失败边界:
- awk 代码块感知合并——纯
sed/perl会破坏代码块内 shell 注释#,把注释行误降级为标题。awk 状态机(进出 ``` 切换c标志)是根治,不是优化。 - 影响规模数字必须"约/估算"——无权威精确数据时,用"约 X" + 标注来源性质(政府/厂商/年报),严禁给精确数字。
- 不含可运行攻击代码——白皮书面向运维,防御清单含具体命令/配置,但不含 exploit。
- "待复核"条目——在 facts 头部声明,定期回核(如 Web 配额恢复后)。
28.7 事实核实:NVD API 绕过 WebSearch 限流
长文档生产最容易卡在事实核实环节。WebSearch 是 US-only 且有配额(见第 15 章 MCP 与官方文档),一旦 429,整批子代理都会撞墙。破局方案:权威 API + curl 直取,绕过 WebSearch。
CVE 核实用 NVD(National Vulnerability Database)API:
# 单个 CVE 核实(无 key,限 5 req/30s)
curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' \
| python3 -c "
import sys, json
d = json.load(sys.stdin)
v = d['vulnerabilities'][0]['cve']
print('ID:', v['id'])
print('描述:', v['descriptions'][0]['value'][:200])
print('发布:', v.get('published', 'N/A'))
"批量核实时的限速纪律:NVD 无 key 限 5 请求/30 秒,循环里加 sleep 6:
for cve in CVE-2021-44228 CVE-2014-0160 CVE-2017-5638; do
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=$cve" \
| python3 -c "import sys,json; v=json.load(sys.stdin)['vulnerabilities'][0]['cve']; print(v['id'], '|', v['descriptions'][0]['value'][:120])"
sleep 6
done核实结果沉淀到基准文件 sources/facts/cve-verified.md,供 Stage 3 撰写与 Stage 6 校对引用。纪律:每条数字标注来源 URL;无权威数据写"无公开权威数据";不确定标"待复核"。
这套思路不限于 CVE——任何有权威 API 的事实(厂商公告、CVSS、CPE、国家标准编号)都优先走 API + curl,把 WebSearch 留给没有 API 的模糊检索。子代理 prompt 要点:带已知锚点提效(告诉它 CVE 编号让它去取详情,而不是让它"查一下这个漏洞")、禁可运行代码、返回 ≤100 字摘要。
28.8 合并与一致性校验
终稿合并不是 cat *.md > final.md——会出三个问题:标题层级错乱、代码块内 # 注释被误降级、术语前后不一致。
标题层级统一:用 awk 状态机,只在代码块外做标题降级(见 28.6 的 build.sh)。状态机进出 ``` 切换标志位,代码块内的 # 注释原样保留。这是根治,sed 's/^#/##/' 会把 shell 注释全变成二级标题。
术语一致性:glossary.md 作为单一来源,Stage 6 校验脚本扫一遍正文,把 glossary 里每个术语的"禁用译法"grep 出来:
# 术语禁用译法扫描
while IFS='|' read -r term banned; do
hits=$(grep -rn "$banned" drafts/v1/*.md)
[ -n "$hits" ] && echo "[术语冲突] $term: $hits"
done < glossary.md引用/编号一致性:CVE 编号、图表编号、参考文献编号,跨章必须一致。校验脚本扫一遍正文出现的所有编号,与 sources/facts/ 基准文件对齐:
# CVE 一致性:正文出现的 CVE 必须在 cve-verified.md 里有记录
grep -ohE 'CVE-[0-9]{4}-[0-9]+' drafts/v1/*.md | sort -u > /tmp/used.txt
grep -oE 'CVE-[0-9]{4}-[0-9]+' sources/facts/cve-verified.md | sort -u > /tmp/verified.txt
comm -23 /tmp/used.txt /tmp/verified.txt # 未核实的 CVE,应为空三条校验都通过,终稿才算"机器可检查的完成"。这与第 06 章的可执行闭环同构——把"完成"从一句"写好了"变成脚本退出码。
28.9 失败边界总表
长文档生产的高频翻车点,按出现频率排序:
| 失败 | 症状 | 根治 |
|---|---|---|
| 大纲未确认就并行写 | 整批返工 | Step 1 产出必须用户明确确认 |
| 章节间术语不一致 | 同一术语两种译法 | Step 1 同步产 glossary.md,子代理禁自创 |
| 数字漂移 | 同一事实两章数字不同 | 事实先沉淀 sources/facts/,子代理只读 |
| 子代理联网撞 429 | 一批子代理同时失败 | Step 2 禁联网,事实核实前置 |
| 事实未核实就成稿 | 终稿数字无来源 | Stage 2 必须先于 Stage 4 完成 |
代码块内 # 被降级 | shell 注释变标题 | awk 状态机,不用 sed |
| 初稿字数超标 | 交稿超限 | Stage 6 必须压缩 |
| 虚构数据未替换 | 投稿/发布事故 | 人工逐数字核对,Agent 不会自声明 |
| 自动发布 | 红线 | 不自动 push/publish,继承全局 CLAUDE.md |
九条里前四条是流程纪律(靠 Step 顺序防),中间两条是技术纪律(靠脚本防),后三条是人工纪律(靠人防)。流程防不住的,脚本防;脚本防不住的,人防。三层叠加,才是可信任的内容生产线。
28.10 与后续章节的衔接
本章的并行子代理编排,底层机制在第 19 章(Subagents)与第 20 章(Dynamic Workflows,research preview)详述。本章只讲了"怎么用"——run_in_background: true、一条消息发多个 Agent 调用、worktree 隔离。如果你想自己造一条可重放的写作流水线(而不是每次手动 spawn),第 20 章的 Workflows 是正式入口;想理解子代理的 context 隔离与失败传播,看第 19 章。
本章是第五部分(实战)的收尾。第六部分(产品化,第 29-32 章)把这套内容生产能力变成一人公司的产品——内容即产品、工作流即资产。学术论文工作流可用于知识付费内容生产,技术白皮书工作流可用于行业咨询交付,两者都是"把 Claude Code 变成生产资料"的具体路径。
下一章:一人公司产品化总论