你的文档的第一个读者，已经不是人了

上周四下午三点半，你写了一份会议纪要。

你在飞书文档里打了大概 800 字，格式还算清楚——有议题、有讨论过程、有决议、有行动项，每个行动项后面标注了负责人和截止日期。

写完，你关上电脑，去接了杯咖啡。

在你回来之前，以下事情已经发生了：

你的会议纪要被 Agent A 读取。Agent A 从中提取了四个行动项，推送给三个人的待办列表，同时在项目管理系统里自动创建了对应的任务卡片。

其中一个行动项是："联系供应商确认 Q4 交期。"Agent B 读取了这个任务，自动生成了一封邮件草稿，收件人是你们的供应商，主题是确认交期，语气是正式且友好的。草稿在等待你的确认。

与此同时，Agent C 把本周所有的会议纪要、邮件摘要和项目状态，汇总成一份三百字的周报，发给了你的老板。你老板读了那三百字，打了一个勾，没有再看原文。

你回来坐下，打开电脑。

那份会议纪要，依然整整齐齐地躺在飞书文档里。

但你并不知道，在过去二十分钟里，它已经被三个不同的 Agent 读取过了，触发了七个自动化动作，影响了五个人的工作安排。

而在整个过程中，没有一个人类打开过你的原文。

谁读了你的会议纪要？

三个 Agent。

零个人。

停一下。

如果你的文档的第一个——也可能是唯一一个——读者是 Agent，那你一直以来"为人类写文档"的所有习惯——

精心设计的标题层级，让人眼睛舒服的留白，那个把枯燥内容变得有趣的转折句，你在逻辑严密处用的"综上所述"，在重要结论前用的刻意顿号……

这些，还重要吗？

你写的所有东西，都藏着一个隐形的假设

我们从来没有公开说过这件事，但每次动笔的时候，它都在场。

"有一个人类会读这个东西。"

这个假设，像空气一样弥漫在我们所有的写作决策里。

因为读者是人类，所以我们用 PPT——因为人类喜欢视觉化，漂亮的图表比枯燥的文字更能引起注意。

因为读者是人类，所以我们写"参考第三章的相关规定"——因为人类可以翻回去找第三章，人类有空间感，人类可以记住"哦对，第三章讲的是这个"。

因为读者是人类，所以我们写"按最新政策执行"——因为跟这份文档打交道的人，大概知道"最新"指的是那个几个月前颁布的新规，有共享常识。

因为读者是人类，所以我们把"客服操作规范"写成一份 80 页的综合手册——因为人类读者理解这是一个系统，会在需要时查阅对应章节，而不是每次都从头读到尾。

现在把这个假设替换掉——读者不是人类，而是一个 LLM。

所有的决策，同时失效了。

LLM 看不到 PPT 里图片中的文字。那张你花了一个小时设计的流程图，对 LLM 来说是一张空白。图里的文字、箭头指向、节点关系——不存在。

LLM 找不到"第三章"。它接收到的是被切分成小块（chunk）的文档片段，不是一本完整的书。"参考第三章"对它来说是一个死链接，指向的目标可能根本不在它的检索范围里。

LLM 没有你的共享常识。"最新政策"是哪年的？生效日期是什么？覆盖范围是哪些场景？LLM 不知道，因为那是你们团队内部的隐性知识，从来没有被写清楚。

LLM 在处理 80 页综合手册时，关键信息会被稀释。当用户问"退款政策是什么"，检索引擎在 80 页文档里找到了五个不同位置都提到了"退款"——但切取的那一段，不一定是最准确的那一段。

你以为你在写文档。

其实你在为一个特定的受众——人类——优化阅读体验。

但那个受众，正在换人。

Karpathy 的判断：99.9% 的注意力迁移

Andrej Karpathy 在 2025 年初说了一句大多数人还没有真正消化的话：

"到 2025 年，大多数内容仍然是为人类而非 LLM 编写的。但 99.9% 的注意力，即将成为 LLM 的注意力，而不是人类的注意力。"

这句话有三层含义，每一层都比上一层更让人不舒服。

第一层：数量压倒性优势。

你公司的 Agent，每天处理多少文本？

如果你有一个客服 Agent，每天处理 3000 条用户投诉，意味着这个 Agent 每天读取 3000 份用户文本，同时检索你知识库里相关的文档，可能触发几百次对操作手册的查询。

而你们的客服团队，可能每天人工处理 100 份工单，其中实际读取知识库的，更少。

在这个场景里，你的知识库的主要读者，早就不是你的客服团队了。是那个 Agent。

这不是未来，这是今天。

第二层：受众已经迁移，但写作者还没有发现。

你的知识库、操作手册、流程文档——是按照"人类读者"的习惯写的。

但它们的主要读者，已经是 Agent 了。

这中间有一个时差。

写作的方式，还停留在旧受众的时代。

但消费的受众，已经换了。

第三层：99% 的人还在为旧受众优化。

大多数企业在维护知识库的时候，想的是"这份文档，我们的员工能读懂吗？"

几乎没有企业在问："这份文档，我们的 Agent 能准确理解并使用吗？"

这个认知时差，就是先觉者的机会窗口。

谁先学会为 LLM 写文档，谁的 Agent 就先变聪明。

不是因为他们用了更好的模型，而是因为他们给模型输送了更好的原料。

"写得好"正在分裂成两个定义

在过去，只有一种"写得好"：

人类读得懂，读得顺，读完知道该做什么。

这个定义统治了写作这件事几千年，从甲骨文到 Word 文档，从孔子的《论语》到你公司的周报模板。

现在，这个统一的定义，正在断裂。

"写得好"正在变成两件事：

为人类写得好：

有叙事弧线和情绪节奏，读起来不累。

用修辞和比喻帮助理解，抽象的东西变得具体。

适度省略共享常识，不要废话连篇。

视觉设计精美，排版让眼睛舒服。

长度克制，考虑读者的注意力上限。

为 LLM 写得好：

语义明确，没有歧义，每句话只有一种解读方式。

信息自包含，不依赖读者的背景知识和共享常识。

结构化：清晰的标题层级，用标签和元数据帮助定位。

纯文本优先，关键信息不藏在图片、表格截图、PPT 里。

完整性优先于简洁性——宁可啰嗦，也要把关键信息写清楚。

这两个定义，并不是相互排斥的。一份文档可以同时满足两种读者。

但满足两种读者，需要有意识的两份工作，而不是按照旧习惯写一份文档，然后假设两种读者都能看懂。

关键判断：谁是你的文档的主要读者？

如果是人类为主——品牌文案、对外报告、给客户的邮件——用为人类优化的方式写。

如果是Agent 为主——内部知识库、操作规范、流程手册、API 文档——用为 LLM 优化的方式写。

如果两者都有——会议纪要、项目文档、决策记录——有意识地同时为两种读者设计。

不知道自己的文档主要给谁读？

问这个问题："这份文档，在接下来的一个月里，会被 Agent 读的次数，多于被人读的次数吗？"

如果答案是"是"，或者"不知道"——那你应该开始思考为 LLM 优化的事了。

八条原则：让你的文档对 Agent 友好

这不是一份"最佳实践建议"，而是一份改造清单。

你可以把现有的知识库文档拿出来，对照这八条，一条一条检查。

原则一：消灭图片中的文字

流程图里的文字，全部提取到正文中描述。

表格截图，转换成 Markdown 表格或者文字描述。

PPT 里的要点，用纯文本重新写一遍。

如果你的文档里有"见下图"——问自己：如果下图不存在，这段话还完整吗？如果不完整，把图里的信息写进正文。

为什么重要：LLM 依赖文本检索。图片里的信息，对 LLM 来说等于不存在。你的知识库里有多少关键信息藏在图片里，就有多少信息对你的 Agent 永远隐形。

原则二：消灭模糊指代

这类表达，每出现一次，就是在给 Agent 埋一个地雷：

"参考第三章的规定" → 改为：直接把那条规定的核心内容复制过来，或者写清楚"第三章第4条：[规定内容]"

"按最新政策执行" → 改为："按[政策名称]执行，该政策自[日期]起生效，主要内容为……"

"详见附件" → 改为：把附件的核心信息内联到正文，附件作为备份而非主要信息来源

"如有特殊情况，参照惯例处理" → 改为：把几种最常见的"特殊情况"列出来，各自说明如何处理

为什么重要：LLM 没有"回头翻"的能力，没有"大家都知道"的常识，没有"惯例"这个概念。每一个模糊指代，都是一个信息黑洞。

原则三：让信息自包含

每篇文档，应该能够独立被理解，不依赖读者预先了解另一篇文档的内容。

为什么？因为 Agent 在检索时，找到的是这一篇，不一定能同时找到那一篇。

实操方法：

把关键前提信息直接写进这篇文档，而不是"参考[另一份文档]"。

如果确实需要引用，把引用内容的核心摘要内联进来，然后再提供引用来源。

测试方法：把这篇文档单独发给一个从来没见过你们公司内部资料的人，问他们：只看这一篇，能理解这篇文档的核心内容吗？如果不能，说明它不自包含。

原则四：一篇文档只讲一件事

大而全的操作手册是 RAG 的噩梦。

原因在于：检索的颗粒度，和文档的颗粒度是匹配的。

一篇 80 页的"客服综合操作规范"，当用户问"换货政策是什么"时，检索引擎可能找到这篇文档——然后从中截取一段——但那段内容可能是关于退款的，不是关于换货的。

正确做法：把综合文档拆分成颗粒度合适的小文档。

不是"客服操作规范"，而是：

《退款申请处理流程》（300 字）

《换货申请处理流程》（350 字）

《投诉升级标准与流程》（400 字）

《会员专属权益说明》（250 字）

每篇文档的主题极其明确，检索精准度会大幅提升。

原则：一个决策场景，一篇文档。

原则五：用结构化标记

标题层级清晰，使用 H1、H2、H3，而不是用字体大小或者加粗来区分层级。

关键概念加粗，帮助 LLM 在长文档里快速定位重要信息。

列表优先于连续段落，当你有三个以上并列的信息点时，用列表而不是连句子。

统一格式：所有日期用同一格式，所有金额用同一单位，所有人名用同一命名方式。

为什么重要：结构化标记是 LLM 的"路标"。标记越清晰，LLM 越容易在文档里找到正确的信息，而不是从一大段模糊的文字里猜测关键内容在哪里。

原则六：写出"为什么"，不只是"做什么"

大多数操作规范只写做什么，不写为什么。

"退款金额超过 500 元需总监审批。"

这条规则，执行起来很清楚。

但当 Agent 遇到一个边界情况——比如用户申请退款 498 元，但同时申请换货 3 元——Agent 不知道这两笔合并算不算超过 500 元，需不需要总监审批。

如果你写了"为什么"，Agent 可以判断：

"退款金额超过 500 元需总监审批。原因：超过此金额的退款可能涉及异常交易风险，或批量退款行为，需要更高权限确认。"

有了这个"为什么"，Agent 遇到边界情况时，可以根据规则的意图做出更合理的判断，而不是机械地比较数字。

原则：每一条规则，都应该附带它存在的理由。

原则七：标注信息的时效性

每篇文档的开头，加一个信息栏：

text

最后更新：2025年8月15日
适用范围：所有客服渠道
如与系统内规则冲突，以系统为准
下次审核：2026年2月

当知识库里有多个版本的同类文档，或者文档内容存在时效性时，这个信息栏让 Agent 能够判断优先级——优先使用最近更新的、范围最匹配的文档。

没有时效性标注的文档，对 Agent 来说都是"同等权威"的，它没有理由选新的而不选旧的。

原则八：写一段"Agent 摘要"

在每篇文档的最开头，写一段 50 字以内的摘要。

注意：这段摘要不是给人看的，是给 Agent 的检索引擎用的。

它的目标是：让检索引擎在扫描这篇文档时，能在 50 字以内判断"这篇文档适合回答哪类问题"。

写法示例：

text

[Agent 摘要]
本文档说明用户申请退款的处理流程，包括退款条件、
审批权限和处理时限。适用于：用户发起退款申请的
所有场景。

有了这段摘要，当用户问"我想退款，怎么操作"，检索引擎能更准确地命中这篇文档，而不是误命中一篇同样提到"退款"的营销文案。

从今天开始的一个小动作

读到这里，你可能觉得"改造知识库"是一件很大的工程。

是的，系统性地改造知识库，是一件需要时间和资源的事。

但有一件事，你今天就可以开始做，不需要任何额外资源：

从你们最常被 Agent 查询的那 10 篇文档开始。

不是全部，就是 10 篇。

用这八条原则，逐一检查，逐一改造。

10 篇文档，每篇花一个小时，一周内完成。

然后，观察你的 Agent 在这类问题上的回答质量，是否有明显提升。

这个小动作的价值，不只是让那 10 篇文档变好。

它的更大价值是：让你的团队第一次真正理解"为 LLM 写文档"和"为人类写文档"有多大的不同。

这个理解，会改变团队以后写所有文档的方式。

人类花了五千年，学会为人写作。

从甲骨文到古埃及纸草，从印刷术到互联网，五千年的时间里，我们把"清晰地把一个想法传递给另一个人类"这件事，做到了极致。

现在，那个"另一个"，开始变化了。

不是人类消失了，而是出现了一个新的读者，它的数量正在以指数级增长，它的阅读速度是任何人类都无法企及的，它的理解方式和人类根本不同。

我们有五年时间，在已有的五千年写作智慧基础上，学会为这个新读者写作。

这不是放弃旧的写作，是扩展写作的边界。

下次你打开文档准备写的时候，在开始之前，问自己一个新问题：

"这份文档的主要读者，是人，还是 Agent？"

这个问题的答案，会让你做出不一样的选择。

而那些不一样的选择，会积累成你的 Agent 的智识资产。