如何写出AI能准确引用的页面内容

检索系统并不会把整页内容交给模型，而是从中截取两三百个词，没有标题，没有前文，也没有办法查阅任何东西。一篇从头读到尾很流畅的文章，在这种形式下可能毫无意义，而修复工作只能在句子层面进行，枯燥且不引人注目。

检索的单位是段落

检索管道在给任何内容打分之前，会先把文档拆分成块，因为针对特定问题对整个文档打分，会把相关句子淹没在一万个无关句子之中。典型的块大小是几百个 token，带有一点重叠。这个计算值得内化：

chunk size        600 tokens
chars per token   ~4 for English prose
                  ------------------------
chunk in chars    ~2,400
chunk in words    ~380
                  ≈ three to four ordinary paragraphs

所以，一个用不到四百个词回答一个问题的小节，有很大机会完整保留。一个需要一千二百个词才能给出答案的小节会被拆分，而拆分不会尊重你的论述逻辑——标准的拆分器按字符数、段落间隔或标题的顺序粗暴切割。读到中间块内容的读者，既看不到前因，也看不到后果。关于结构层面的更多内容，见 chunking strategies and what chunk boundaries do to meaning。

接下来的规则很简单，而且这就是整页的核心：每个段落都应该能让只读过这个段落的人读懂。这比好文章的通常要求更严格，需要少量的重复。

句子丢失主语的六种方式

段落开头的代词指代不清。"It also fails when the token budget is small." 什么失败了？

对结构的回指。"As mentioned above"、"the second approach"、"this method"——这些都指向了不在块中的文本。

只在标题下才有意义的列表项。"Faster, and cheaper per request" 放到任何其他地方都不是一个完整的句子。

没有单位或主语的数字。"About 40% in our testing" 无法引用，更糟糕的是可以错误地引用。

条件句的前件在其他地方。"In that case, use the batch endpoint." 哪种情况？

从不重复术语的定义。一个小节引入一个缩写后只使用缩写，那么后面的小节讲的是一个从未解释过的字符串。

这些在常规写作规则下都不是错误。但它们对独立传播的段落都是致命的。

八处改写。每个案例的改写后版本只是多了几个词，但能独立成篇。

1. 消除代词歧义

BEFORE
  It only applies to requests that already carry an idempotency key.

AFTER
  Automatic retry only applies to requests that already carry an
  idempotency key.

2. 消除结构回指

BEFORE
  The second option above is usually the right one for batch jobs.

AFTER
  Queueing the request and polling for the result is usually the right
  choice for batch jobs.

3. 给列表项添加主语

BEFORE
  Advantages of the streaming endpoint:
  - Lower time to first token
  - No timeout at 60 seconds

AFTER
  Advantages of the streaming endpoint:
  - The streaming endpoint returns a first token in well under a second,
    against several seconds for the buffered endpoint.
  - Streaming responses are not subject to the 60-second gateway
    timeout, because bytes keep arriving.

4. 把数字与其主语、单位、日期绑定

BEFORE
  This cut latency by about 40%.

AFTER
  Moving the embedding step out of the request path cut median
  end-to-end latency from about 900 ms to about 540 ms in this
  configuration, measured on the setup described in the previous
  section.

5. 重述条件

BEFORE
  In that case, raise max_tokens.

AFTER
  If the response is being cut off mid-sentence with a finish reason of
  length, raise max_tokens.

6. 重复术语本身，而非缩写

BEFORE
  TTFT is the number that decides whether the interface feels alive.

AFTER
  Time to first token — the delay before the first character of the
  answer appears — is the number that decides whether the interface
  feels alive.

7. 把答案放在小节的第一句

BEFORE
  There are several things to weigh here. Cost matters, and so does
  latency, and the answer depends on your traffic shape. Broadly,
  though, most teams end up caching the system prompt.

AFTER
  Cache the system prompt. It is the largest block of tokens that is
  identical across requests, which is exactly the condition prompt
  caching pays for. The rest of this section is when that is wrong.

8. 让标题成为一个论断，而非标签

BEFORE
  ## Considerations

AFTER
  ## Why retries make duplicate charges more likely, not less

先说答案，再加限定

顺序规则值得单独成节，因为它与技术严谨的人自然写作的方式相冲突。本能会促使人在陈述结论之前先说明前提条件，以免读者误解。在碎片化的世界里，这种本能会产生这样的段落：前两百词都是铺垫，而结论落到了下一个块里。

反过来。 先陈述答案，再缩小范围。"Use a 300-token chunk for FAQ content. That figure comes from the length of a complete question-and-answer pair; for reference documentation, where a single concept can run to a page, it is too small." 论断及其适用范围现在都在同一两句话里，而这是可以被引用而不会失真的最小单元。

这种格式也能抵御 why models produce confident wrong answers 中描述的失败模式：放在论断之后的限定可以被删掉。而适用范围如果和论断在同一个句子里，就无法被删掉。

数字需要单位和日期

数字是页面上最容易被引用的事物，因此也是最危险的。任何希望被正确引用的数字，都需要四个要素放在同一句话里：它测量的是什么、它的单位、它的条件、以及它在什么时候是成立的。

WEAK     Throughput roughly doubled.

STRONG   Throughput rose from about 40 to about 85 requests per second
         on a single 8-core instance after connection pooling was
         enabled, measured in March 2026 against the same synthetic
         workload.

长版本不是废话——这就是一个可以被引用的句子和一个无法被负责任地引用的句子之间的区别。这也能保护你自己：携带了条件的数字不会被重复引用为关于你产品的一般性声明，而数字就是这样脱离其作者的。

如果一个数字既不是在页面上推导出来的，也没有归属到某个具名的发布者和年份，正确的做法是把它删掉。这个领域的一页如果带着一个没有出处的百分比，就会破坏页面上所有其他数字的可信度，技术内容的读者会核实。

表格、列表和代码提取效果很差

以上都是关于句子的。页面上不是句子的部分有其独特的失败模式，而且很容易看出来：对你的页面跑一个 HTML 转文本的转换器，然后读读看结果如何。

两列的表格通常能以交替行的形式保留下来，仍然可读。宽表格通常不行：列标题只出现在顶部一次，单元格以一串值的形式出现，所以到第四行时已经没有任何东西表明一个数字属于哪一列。如果一个事实只存在于第七行和第五列的交叉处，它就消失了。

WHAT YOU WROTE
  Model       Context   Input $/M   Output $/M   Tools
  alpha-1     200,000   3.00        15.00        yes
  beta-2      128,000   0.50         1.50        no

WHAT A NAIVE EXTRACTOR PRODUCES
  Model Context Input $/M Output $/M Tools
  alpha-1 200,000 3.00 15.00 yes
  beta-2 128,000 0.50 1.50 no

WHAT SURVIVES FOR CERTAIN
  alpha-1 has a 200,000-token context window, costs $3.00 per million
  input tokens and $15.00 per million output tokens, and supports tool
  calling.

解决办法不是停止使用表格——对人类扫描来说表格更好，这更重要。 而是要确保任何一个你不想让它丢失的事实，也在页面的某个地方作为句子存在。表格加上概括你所关心的两行的段落，只需要四十个词，就能免疫这个问题。

嵌套列表会扁平化。两级缩进变成一级，修饰父项的子项现在读起来像是在否定它的同级项。

代码块通常能完整保留，但到达时没有任何关于其用途的说明。每个代码块前面紧跟一句说明它是做什么的，就是让它可以被引用的关键，而这恰恰是最常被省略的那句话。

图片中的文字完全无法保留。带标签的图表——其标签承载了论述——那么论述就不在页面上了。在图表下方用文字描述它，这也恰好是屏幕阅读器所需要的。

标题是拆分器可以利用的

结构感知的拆分器在标题处切分，这意味着你的标题就是块边界，不管你是否有意如此。

描述性标题成为块的标题。许多拆分器会在每个块前加上标题路径，所以 "Notes" 什么也没加，而 "Why the retry loop double-charges" 把主语加了回来。

没有标题的小节会与相邻小节合并。如果两个主题共用一个标题，它们会被当作同一个东西来打分。

跳级会混淆路径。h2 后面跟 h4 会产生无论拆分器如何重建都错误的嵌套结构。

页面规划的推论见 retrieval-friendly site architecture：每个小节一个问题，每个问题一个规范的小节，小节足够短以保持完整。

这会成为不好的写作

不加判断地应用这些规则，每一条都会产生令人疲惫的阅读体验。一篇在每个句子中都完整写出主语的页面，读起来像法律通知，而人类在第一段就放弃你的页面，比需要多一个名词的块要糟糕得多。

可行的折中方案：在每个小节的开头和每个段落的开头严格应用这些规则，在其内部则放松。这些是拆分器最有可能切割的位置，也是人类扫描页面时着陆的位置。这两个受众在这些位置想要的是一样的东西，这就是为什么这种特定的优化是安全的，而大多数伴随它销售的优化都不是。

还要有诚实的警告：这篇文章的所有内容都是关于可提取性的论断——一个段落能否独立阅读——你可以自己验证，复制你页面任意四百个词读一读。它是否改变了助手引用你的频率，这是另一个论断，在你所在的规模上无法验证，这篇文章不会对此做出论断。

What Makes a Page Worth Quoting

Retrieval-Friendly Site Architecture