Edit: 15.9小时，106万字：我的全自动 AI 商业史写书流程与工业化 Agent

编辑文章

标题 *

URL 别名 *

内容 * (支持 Markdown 格式)

# 15.9小时，106万字：我的全自动 AI 商业史写书流程与工业化 Agent 架构全公开

> **作者**：雨轩 
> **项目**：《科技公司兴衰传奇》系列全自动写作工程  
> **技术栈**：Dual-Agent 并行调度器 / Python 代码质检闸口 / 大模型上下文双门限滞后环 / 长上下文宏观重构  
> **开源协议**：CC BY-NC-SA 4.0（作品） / MIT（引擎工具链）

---

## 序言：当人类最顶尖的手速遇到硅谷的算力军团

作为一个习惯用五笔打字的人，我的极限手速大约可以达到 **250 字/分钟**。在人类物理世界中，这已经是专业法院听打或速记员级别的顶峰水平。如果让我手不停歇、脑不卡顿、不喝水不上厕所地连续打字 15 个小时，我的理论产出上限大约是 **22 万字**——而且这还没有算上查阅资料、构思大纲和语法修正的脑力消耗。

然而，在刚刚过去的十几小时里，我的**双线 Agent 自动化写书系统（book-writer）**完成了这样一组令人震撼的数据：

* **核心系列（《科技公司兴衰传奇》）完稿**：**13 本** 商业史专著（含《苹果》《诺基亚》《雅虎》《摩托罗拉》《IBM》《微软》《仙童》《施乐》《SUN》《DEC》《网景》《康柏》《Palm》）+ **1 本** 《黑莓传奇》；
* **系列纯汉字总量**：**1,060,033 字**（纯中文文本，不含标点符号与 Markdown 格式标记）；排版后约 **130 万字**，共计 **170 余章**；
* **跨项目总产出**：若算上《AI-Agent 通史》《OpenCode》《智争未来》等其他项目，全套自动化系统已累计产出 **212 章，143.8 万纯汉字**；
* **真实墙钟耗时（Wall-Clock Time）**：**约 6~7 小时**（双 Agent 并发线同时推进）。

更重要的是，这 106 万字**绝非传统的 AI 垃圾废话堆砌**。每一本书都包含了严格的史实考据、去重机制、反 AI 句式检测、以及基于管理学框架（如克里斯坦森《创新者的窘境》、路径依赖、先行/滞后指标）的深度商业洞察。

这篇文章将毫无保留地公开这套 **“工业级 AI 写作流水线”** 的全部架构设计、Python 质检脚本逻辑、上下文调度算法、以及我对于“AI 时代创作者角色重构”的深度思考。

---

## 一、 系统总架构：三段式工业级写作流水线

很多尝试用 AI 写作的人都会遇到以下四大毒瘤：**“几千字就逻辑发散”**、**“跨章节严重复读”**、**“套路化伪升华（AI味浓郁）”** 以及 **“后见之明的傲慢”**。

为了彻底根除这些问题，我将写书系统设计为**“三段式流水线（Pipeline）”**：

```text
┌────────────────────────────────────────────────────────────────────────┐
│ 阶段 1：多 Agent 异步并发生成引擎 (Sourcepack / book-writer)           │
│ └── 任务分配 ➔ 联网搜索 ➔ BRIEF ➔ OUTLINE ➔ 分章生成 (双线并行)         │
└──────────────────────────────────┬─────────────────────────────────────┘
                                   │ 产生 8~10 万字/本 初稿 Markdown
                                   ▼
┌────────────────────────────────────────────────────────────────────────┐
│ 阶段 2：Python 自动化代码质量闸口 (Quality Gate)                        │
│ ├── dedup_check.py  ➔ 跨章文字/语义相似度检测 (>=88% 告警)            │
│ └── style_check.py  ➔ 句式黑名单监控 + 段尾升华密度控制 (<=25%)         │
└──────────────────────────────────┬─────────────────────────────────────┘
                                   │ 触发微观去重与句式修剪
                                   ▼
┌────────────────────────────────────────────────────────────────────────┐
│ 阶段 3：Ima / 听雨轩长上下文宏观结构重构 (Macro Refactoring)            │
│ └── 消除事件重述 ➔ 章节合并 ➔ 章末预告清零 ➔ 导出最终出版级定稿          │
└────────────────────────────────────────────────────────────────────────┘
```

### 1. 阶段 1：多 Agent 异步并发生成引擎

在阶段 1 中，系统通过调度器并发运行多个 Agent 线程：

* **Agent A 线程**：专攻技术史源头与先驱者篇章（如《仙童》《SUN》《Palm》）；
* **Agent B 线程**：专攻巨头对决与平台生态篇章（如《雅虎》《苹果》《微软》《康柏》）；
* **Agent C 线程（润色守护线）**：专门跟在 A/B 后面做实时语法校验、格式清洗与初级润色。

### 2. Supervisor（PID 52035）上下文双门限滞后环调度

在长运行的 Agent 系统中，上下文爆满会导致严重的**记忆残留与逻辑衰减（Prompt Rot）**。如果 Agent 带著上本书 70% 的上下文直接开写新书，上一本书的人名和叙事习惯会严重污染新书。

为此，我在 Supervisor 中设计了**控制论中的“双门限滞后环（Hysteresis Loop）”算法**：

```text
写完一本停住 ➔ 检测 Context 使用率
  ├── Context > 60% ➔ 触发 /compact（带保护指令：保留已写章节与 BRIEF/OUTLINE 要点）
  │                   └── 强制等待直至 Context < 40% (或 8 分钟超时) ➔ 派发下一本书
  └── Context ≤ 60% ➔ 零等待，立即派发下一本书
```

这种设计完美避免了上下文在 60% 临界点频繁触发压缩的抖动（Thrashing）问题，同时确保每一本新书都在一个“干净、清爽”的启

---

## 二、 攻克 AI 写作“四大毒瘤”的工程解法

为了确保生成的文本具备传统出版物的高级质感，我们在 SOP (`SKILL.md` / `book-sop.md`) 中硬性集成了四套工程规约：

### 1. 跨章复读：`dedup_check.py` 与交叉引用规则

* **痛点**：由于大模型分章生成时缺乏全局视角，同一个经典金句（如乔布斯的“糖水论”）或历史事件（如黑莓 Storm 的退货潮）会在第 3 章、第 5 章、第 8 章被反复当成新故事展开。
* **解法**：
  * 开发 `dedup_check.py` 脚本，对全书进行 `Jaccard + 文本距离` 扫描，检测完全重复句与 `>=88%` 高相似变体段落。实测中，在未经处理的《苹果》卷中抓出了 61 处重复，在《诺基亚》卷中抓出了 34 处。
  * **写作纪律**：全书任何金句或核心事件**只允许在一处详细展开叙述**，其余章节若需提及，必须强制使用交叉引用（例如：“*关于斯卡利‘糖水论’的完整经过，详见第 3 章 3.1 节*”）。

### 2. 套路化句式与伪升华：`style_check.py` 与三种收尾法

* **痛点**：AI 极度喜欢使用转折句式，且每个小节结尾都要硬拽一段“人生哲理/商业终极真理”，读起来充满浓郁的“AI 油腻味”。
* **解法**：
  * 开发 `style_check.py` 监控句式黑名单。如转折套路（`不是……而是……`）、断言套路（`这不仅是……更是……`）、宿命套路（`这大概就是……`）。实测发现《黑莓》第 8 章单章竟出现了 23 次「不是…而是…」，脚本直接触发告警，**强行限制每章黑名单句式不得超过 3 次**。
  * **三种段尾收尾法**：强制要求段落结尾采用 **“事实收尾”**（以冰冷的数据或事件结束）、**“留白”** 或 **“自然小结”**。哲学升华类段落的占比必须 **$\le 25\%$**。

### 3. 宿命论与后见之明：“30% 必然性与当期理性规则”

* **痛点**：AI 站在后视镜视角时，容易把高管的失误简单归结为“愚蠢、傲慢或作死”，失去了商业史的严肃性。
* **解法**：
  * **硬性规则**：在分析任何失败决策（如诺基亚拒绝 Android、黑莓坚持全键盘）时，**必须先花至少 30% 的篇幅，阐述该决策在当时的财务、渠道、供应链与历史背景下的 100% 合理性**。
  * 严禁站在当今的立场去嘲笑历史人物。只有还原当时的抉择困境，商业史才具备真正的参考价值。

### 4. 语气切换：告别单一情绪，引入冷峻平实

* **规则**：在涉及财务报表、技术架构、供应链演进、专利诉讼的段落，**语气必须切换为绝对冷峻、客观、平实的工科分析视角**；戏剧性与情感张力只允许在历史的关键转折节点（如 1997 年长城合影、2011 年《燃烧的平台》备忘录）爆发。

---

## 三、 双口径性能 Benchmark 与实测数据

为了给 AI 创作社区提供最真实、客观的数据，我们记录并分析了这 14 本书的完整时间戳：

### 📊 14 本巨著生成数据汇总表

> **数据说明**：带 `*` 号的书籍表示已完成 Agent C 的精细化润色。由于润色线写入文件时覆盖了初始完工时间戳（延后了 `mtime`），导致计算出的“速度”包含了排队等待与润色耗时，数据被拉低；未带 `*` 的新书反映的是原生创作线程的真实极速。

| 卷名 | 纯中文字数 | 统计耗时 | 速度 (字/分) | 状态与口径特征 |
| :--- | :---: | :---: | :---: | :--- |
| **02 IBM** | 81,242 | 272 min | 298 * | 已润色（时间戳被润色覆盖，速度低估） |
| **03 仙童** | 63,348 | 200 min | 317 * | 已润色 |
| **05 摩托罗拉** | 91,334 | 326 min | 280 * | 已润色 |
| **06 雅虎** | 97,118 | 333 min | 291 * | 已润色 |
| **07 SUN** | 61,760 | 181 min | 341 * | 已润色 |
| **08 DEC** | 90,409 | 139 min | 649 | 润色进行中 |
| **09 诺基亚** | 78,938 | 313 min | 252 * | 已润色 |
| **11 网景** | 46,259 | 35 min | **1314** | 新写未润色（原生极速） |
| **12 施乐** | 67,574 | 90 min | 748 * | 已润色 |
| **14 康柏** | 64,525 | 45 min | **1432** | 新写未润色（原生极速） |
| **21 Palm** | 74,797 | 36 min | **2052** | 新写未润色（原生极速） |
| **25 苹果** | 84,141 | 301 min | 279 * | 已润色 |
| **29 微软** | 63,961 | 64 min | **1004** | 未润色（原生极速） |
| **黑莓传奇** | 94,912 | 477 min | 199 | 早期手工 Session（含人机互动/改写） |
| **汇总 / 平均** | **1,060,033** | **约 31 小时** | **--** | **14 本全定稿，纯汉字破 106 万** |

### ⏱️ 双口径效率提炼

根据上述实测数据，我们可以提炼出两组极其精准的工业级 Benchmark：

```text
┌────────────────────────────────────────────────────────────────────────┐
│ 口径 A：纯 Agent 写作引擎速率 (未润色新书/干净时间戳)                   │
│ ➔ 1300 ～ 2050 字/分钟 (平均约 1500 字/分)                            │
│ ➔ 含义：双 Agent 并行下，墙钟时间仅需 6~7 小时即可吐出 106 万字初稿！   │
└────────────────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────────────────┐
│ 口径 B：出版级全流程交付速率 (写作 + 润色 + 脚本质检 + 整合)            │
│ ➔ 250 ～ 350 字/分钟 (约 1.5 万 ～ 2 万字/小时)                         │
│ ➔ 含义：包含去重、AI味修剪、文本回补与格式校验在内的完整端到端交付。  │
└────────────────────────────────────────────────────────────────────────┘
```

---

## 四、 宏观重构：Ima / 听雨轩长上下文精修法

在经过阶段 2 的 Python 脚本微观质检后，书籍会进入阶段 3——交给长上下文模型（如 Tencent Ima 或 128k+ 窗口大模型）进行**全书级宏观重构（Macro Refactoring）**。

以我们在实践中处理 16.6 万字著作《不被锁死》为例，Ima 展示出了惊人的“宏观外科手术”能力：

```text
优化前：166,513 字 (同一场“断供”事件在序章、第9章、第10章、第12章被反复讲了 4.5 遍)
  ↓
Ima 宏观精修动作：
1. 第 11 章「不眠之夜」并入第 10 章（33 节压缩为 14 节，删除重复环境描写，保留独特数据）；
2. 序章精简 65%，仅保留氛围，删除对第 10 章的提前剧透；
3. 第 9 章删去后半段重复叙事，仅保留成本账与数据战前兆；
4. 彻底清零所有章末的“下集预告式”过渡段。
  ↓
优化后：147,463 字 (-11.4% 篇幅) | 完全重句：15 组 ➔ 0 组 | 信息密度提升 30%
```

这种**“微观靠代码脚本，宏观靠长上下文重构”**的组合拳，彻底解决了传统 AI 写作“单章看很惊艳，整本书看很拖沓”的通病。

---

## 五、 创作者宣告：从“写作者”到“Showrunner 制作人”

很多朋友看到这里会问一个问题：**一分钟生成 1500 字，打字速度高达 250 字/分钟的我，在这个系统中究竟扮演什么角色？**

我的五笔打字速度是 250 字/分钟，如果我不吃不喝不上厕所纯手打 15 个小时，我也只能打出 22 万字。但在这个 Agent 系统中，**15 个小时产出的是 106 万字具有深度洞察的出版级图书**。

这带来的不是“AI 替代了人类”，而是**创作者身份的彻底升维**：

```text
【传统作者】➔ 演员（Actor）   ：逐字逐句书写，90% 脑力消耗在打字与修辞上。
【新代作者】➔ 制作人（Showrunner）：设计 SOP、编写质检脚本、设定黑名单、在关键节点喊“Cut”或“Action”。
```

### 瓶颈的转移：从“生成瓶颈”到“审品与裁决瓶颈”

在拥有了多 Agent 管道后，文字不再稀缺，**真正的生产力天花板转移到了两个新地方**：

1. **阅读与审品速度**：AI 1 小时吐出 9 万字，而人类顶级速读一小时只能看 4~5 万字。**你的阅读与审美速度，成了系统的第一天花板**。
2. **决策与裁决效率**：面对 Agent 提出的 10 种历史叙事角度，只有人类的“碳基大脑”能基于同理心、道德感和商业直觉，拍板决定采用哪一条主线。

**碳基大脑负责“战略、审美、选材与裁决”，硅基算力负责“搜索、架构、体力与执行”。** 这才是人机协同最舒适、最震撼的状态。

---

## 六、 开源计划 (Open Source Roadmap)

这套包含了 **106 万字《科技公司兴衰传奇》** 的项目即将正式在 GitHub 开源！我们将采用**双仓库开源策略**：

1. **作品仓库 (`tech-company-legends`)**
   * **内容**：收录 14 本已完稿的 Markdown 电子书，支持 VitePress 在线阅读与 EPUB 导出。
   * **协议**：采用 **CC BY-NC-SA 4.0** 协议，允许免费阅读与非商业性传播。
2. **引擎仓库 (`book-writer-engine`)**
   * **内容**：完整开源 `book-writer` 系统的 SOP 规范（`SKILL.md`）、Supervisor 调度逻辑、`dedup_check.py` 去重脚本、`style_check.py` 句式监控脚本。
   * **协议**：采用 **MIT** 协议，供全球 AI 开发者与创作者自由使用与二次开发。

如果你对这个项目感兴趣，欢迎关注即将上线的 GitHub 仓库！

让我们一起，用代码与算力，重新定义文字创作的未来！🚀

配图 (可多选)

选择新图片文件或拖拽到此处

标签