用 Qoder 写这本书
从手动写书到 Agent 流水线
这本书本身就是用 Qoder 写的。从章节内容生成到配图编排到网站发布，全流程都有 Agent 参与。
这不是一个"AI 帮我写书"的故事——AI 写不出有体系的技术书。这是一个怎么用 Agent 搭一条出书流水线的故事。
传统的写书流程是这样的：
规划章节 → 逐章写作 → 配图 → 排版 → 发布
人 人 人 人 人每个环节都是人做。不是不能做，是不可持续——一本书 30 多章，每章 3-5 轮修改，加上配图、排版、发布，一个人干完至少要 3 个月。
如果你读过前言中关于 Qoder Agent 基座的介绍，你会注意到：出书领域同样遵循那套四层架构。跟编程领域和自媒体领域的结构完全一致，只是绑的 Harness 不同。
四个 Agent 的出书流水线
我把写书流程拆成了 4 个环节，每个环节一个独立的 Agent：
- Agent 1 章节内容：已实现，核心流程
- Agent 2 配图编排：已实现，含配图生成和插入
- Agent 3 网站发布：已实现，构建 Vitepress 并部署
- Agent 4 PDF 生成：规划中
下面逐个拆解。
Agent 1：章节内容生成
解决的问题：30 多章的书籍，每章要从零构思结构、组织案例、写完整的论述。纯手工写工作量巨大，但完全交给 AI 写质量又不可控。
工作流
这个 Agent 的核心是一个 Skill——qoder-content-write。它封装了完整的章节生成模板：
输入：章节名 + 核心论点
│
1. 加载「使用→实践→知识」三层结构模板
2. 按结构逐层展开：
- 使用篇：内置功能列表、基础命令、最简单的操作路径
- 实践篇：真实项目案例、设计原则、管理策略
- 知识篇：运行原理、设计思想对比、框架对照
3. 逐节生成内容，每节配示例代码或对比表格
4. 章节收尾：一句话总结 + 场景描述 + 渐进式深入呼应
│
输出：完整的章节 Markdown 文件核心约束
qoder-content-write Skill 自带了书籍的写作规范：
| 约束 | 说明 |
|---|---|
| 三层结构 | 每章必须按「使用→实践→知识」组织，从浅到深 |
| 真实案例 | 所有案例必须有 Growth 产品矩阵的真实来源 |
| 术语统一 | "Qoder"保持英文、"Skill"不翻译、"SubAgent"不写成"子代理" |
| 配图规范 | 指定位置插入 Mermaid 流程图、截图、对比表格 |
这些约束不是每次写作时临时叮嘱的——它们写在了 Skill 的定义里。每次调用 qoder-content-write，AI 自动遵守这些规则。
人的角色
章节生成后，我通读全文，做三件事：
- 修正论点：AI 偶尔会把论据展开偏了，我需要把方向拉回来
- 替换案例：AI 用的案例可能是通用案例，我换成 Growth 产品的真实数据
- 补充真实感：AI 写的太"教科书"了，我加上自己的经验和吐槽
平均每章修改 3-5 轮，我的时间投入在 40% 左右。如果没有 Agent，这个比例会倒过来——我投入 100%，周期拉长 3 倍。
Agent 2：配图编排
解决的问题：纯文字的书没有吸引力。配架构图、对比图、流程图、产品截图是刚需。但每张图从构思到产出的周期很长——想构图、找工具、画出来、调颜色、插到正确位置。
工作流
这个 Agent 走的是四步法——分析章节、规划配图、生成配图、插入配图：
输入：章节文件
│
1. 分析章节内容（识别概念对比/流程/并列项/截图需求）
2. 输出配图规划清单，人确认
3. 逐张生成：
- 概念配图 → generate-illustration Skill（Compare/Grid/Flow 模板）
- Growth AIOS 产品截图 → product-screenshot Skill
4. 按「先图后文」原则插入到章节文件
│
输出：章节文件 + 配图 PNG + 可编辑 HTML组合的 Skill
这个 Agent 内部组合了多个 Skill：
| Skill | 用途 |
|---|---|
generate-illustration | 概念配图：对比 / 网格 / 流程 三种模板，科技暗色风格 |
product-screenshot | 产品截图：通过 Playwright 自动访问产品页面并截图 |
insert-illustration | 配图插入：按先图后文原则插入到章节正确位置 |
核心约束
配图受两条 Rule 约束：
- 视觉规范：科技暗色风格、深蓝黑底色、人=紫色/AI=青色/流程=琥珀色、最小字体 12px
- 先图后文：配图必须出现在对应文字描述之前，禁止在文字后插入
人的角色
配图规划清单出来后，我确认：这个构图思路对不对？描述准不准确？确认后再批量生成。生成的配图我快速浏览一遍，检查文字清晰度和颜色是否正确。
Agent 3：网站发布
解决的问题：书写完了、图配好了，最终要发布成一个可访问的网站。手动构建 Vitepress、上传服务器、配置 Nginx——流程固定但繁琐，还容易漏步骤。
工作流
输入：书稿目录 + 素材文件
│
1. 构建 Vitepress 站点（npm run build）
2. 打包产物
3. 上传到 BT Panel 服务器
4. 更新 Nginx 配置
│
输出：可访问的书籍网站人的角色
发之前我确认两件事：
- 构建是否通过：Vitepress 构建报错时，Agent 修复后重新构建
- 域名和路径配置：确认部署地址、资源路径正确
发完之后验证网站是否正常访问、配图是否展示、样式是否正确。
Agent 4：PDF 生成（规划中）
解决的问题：书稿目前是 Markdown 格式 + Web 网站，但很多读者习惯阅读 PDF 版本。手动转 PDF 面临排版错乱、配图丢失、代码格式损坏等问题。
规划中的工作流
输入：书稿目录 + 素材
│
1. 转换为标准文档格式（如 LaTeX 或 Pandoc 兼容格式）
2. 应用书籍排版模板（封面/目录/页眉页脚/页码）
3. 处理跨页配图和代码块分页
4. 输出 PDF
│
输出：可打印/分发的 PDF 文件目前这个 Agent 还处于规划阶段，实现后再更新。
Harness 在出书领域的体现
回顾本书第二部分第 8 章 Harness 工程的五个缺陷，在出书场景中同样有对应：
| 缺陷 | 在写书中的表现 | 应对 |
|---|---|---|
| 模型偏好 | AI 喜欢写"在当今数字化浪潮下"这种废话、结构总往通用模板偏 | qoder-content-write Skill 的约束强制使用三层结构 |
| 模型无边界 | AI 写着写着就偏离了本章的核心论点，开始发挥无关内容 | 章节内容 Agent 只负责生成骨架，不做排版和配图 |
| 模型迎合 | AI 写的论点"你看着都对"，但缺乏冲击力和个人观点 | 每章 3-5 轮人肉审查，修正论点和替换案例 |
| 模型一根筋 | AI 在一个例子上展开过长，忽略了整体节奏 | 章节骨架先给人看，确认结构后再展开 |
| 模型偷懒 | AI 生成的配图描述里写"此处插入架构图"但不实际生成 | 配图编排 Agent 必须实际输出 PNG，不可跳过 |
看看整个流程中"我"在做什么
把 4 个 Agent 拉通看：
| 环节 | 人的角色 | Agent 的角色 |
|---|---|---|
| 章节内容 | 修正论点、替换案例、补充真实感 | 按三层结构生成骨架和展开 |
| 配图编排 | 确认规划清单、审核配图质量 | 分析章节→规划→生成→插入 |
| 网站发布 | 确认构建、检查站点 | 构建→打包→上传→配置 |
| PDF 生成 | 确认排版效果 | 格式转换→排版→输出 |
人在每个环节做判断和决策。Agent 做执行。
跟自媒体章节一起看
把本章跟上一章（用 Qoder 做自媒体）放在一起看，你会发现完全相同的模式：
| 维度 | 自媒体领域 | 出书领域 |
|---|---|---|
| 基座 | 同一套 Qoder Agent 基座 | 同一套 Qoder Agent 基座 |
| Harness | 7 条内容创作 Rule | 三层结构 + 配图规范 + 术语统一 |
| Agent 数量 | 6 个（采集→分析→选题→文案→剪辑→发布） | 4 个（内容→配图→发布→PDF） |
| 人的角色 | 决策者，不做执行 | 决策者，不做执行 |
| 输出物 | 短视频 | Web 网站 + PDF |
这就是前言讲的那套四层架构的威力——同一基座，不同领域绑上不同的 Harness，就变成了该领域的专业流水线。
一点感悟
这本书是我用 Qoder 写的。这本身不是一个噱头，而是一次验证——验证那套 Agent 基座架构不止能写代码、做自媒体，还能写书。
写书跟写代码最大的区别是什么？代码错了可以编译报错、可以单元测试。写书写错了没有报错——你写错了读者看不懂，不会有人告诉你。所以人在写书过程中的判断力比在写代码中更重要。
这也是为什么出书领域的 Agent 流水线跟编程领域完全一样——Agent 负责展开和执行，人负责判断和把关。Harness 工程解决的是"AI 在展开过程中不跑偏"的问题，而"方向对不对"永远是人说了算。
AI 时代写书的能力，不是"写"，是"搭流水线"——跟做自媒体一样。
关联：本书的自媒体章节（第五部分第 2 章）和本书本身，都是用同一套 Agent 基座架构搭建的流水线产物。下一章探讨 AI 时代个人的成长方向。