RAG分块预览器为什么切不开你的Markdown

摘要：RAG分块预览器把一段内容按四种策略切开，让你看到AI检索时实际拿到的是哪一小段，再给每一块打一个自包含分，标出被切断的句子、开头的指代词和跨块引用。它解决的是一个平时看不见的问题：你的文章不是作为整体被引用的，被引用的是其中某一块。

但它有个第一次用几乎必踩的坑：点开自带的“加载示例”，切分策略选“按标题分节”，735个字符的示例整篇只会切出1块。原因是示例文本用的是两个井号的二级标题，而按标题分节的逻辑只认三个井号，纯文本又不会被转换。策略选错了，你看到的结论就是假的。

另外三条口径要知道：重叠参数只对固定长度这一种策略生效，其余三种调了也没用；概览里的“平均块长”在开了重叠之后会比真实值小一大截；英文内容会全线报红，因为句子结束的判定里没有英文句点。这篇把每条的复现方式和绕法说清楚。

做GEO这两年，最难跟人解释清楚的概念就是分块。大家能理解“内容要写好”，能理解“结构要清晰”，但一说到“你的文章会被切成一小段一小段，AI只读其中一段”，多数人的第一反应是：切就切呗，我写得好，切哪段都好。

这个反应错在哪儿，光靠讲是讲不明白的，得让人亲眼看见自己那篇得意之作被切开之后的样子——有的块从半句话开始，有的块通篇是“这样一来”“上文提到的那个方法”，单独拎出来谁也看不懂。保哥笔记的RAG分块预览器做的就是这件事。这篇教程会先讲清楚它每种策略在模拟什么，再把几处容易让人读出错误结论的口径逐条拆开。

为什么点了加载示例反而只切出一块？

先讲这个，因为它是第一次用最容易撞上的一堵墙，而且撞上了往往意识不到自己撞了。

复现过程

操作很简单：打开工具，点“加载示例”按钮，示例内容会自动填进输入框，目标查询词也一并填好；然后把切分策略从默认的“固定长度”改成“按标题分节”，点“切块并分析”。

结果是：概览里“切出的块”显示1，下面只有一个块，内容是整篇735个字符。而这份示例内容里明明写着两个小标题，看上去应该切成两节才对。

为什么会这样

三件事凑在一起造成的。第一，示例文本用的是两个井号的Markdown二级标题；第二，按标题分节的切分逻辑找的是三个井号开头的行；第三，输入内容会先过一道HTML转文本的处理，那道处理会把真正的HTML标题标签统一改写成三个井号，但它有个前置判断——内容里检测不到HTML标签就原样返回，不做任何转换。

纯文本的示例内容自然检测不到标签，于是直接原样返回，两个井号还是两个井号；接着按三个井号去切，一条也匹配不上，整篇就成了一块。三个环节各自都说得通，串起来就撞了车。

四种策略在同一份示例上的差距

同一份735字符的示例内容，四种策略切出来的结果差得相当远：

1块和9块之间差了9倍，而输入是同一份内容。所以用这个工具有一条前提纪律：先确认你选的策略在你这份内容上真的生效了，再去读那些评分。判断方法很土但有效——看块数，只切出1块或者块数明显不合常理，先怀疑策略没生效，而不是怀疑自己的内容。

块数不对时的自查顺序

把这几种情况记住，遇到反常的块数照着排一遍，基本一次就能定位：

• 按标题分节只出1块：内容是纯文本或Markdown，标题没被转成三个井号。这是最常见的一种。
• 按段落切出几十块，最短的只有十几个字符：正常现象。空行分隔的短行、列表项、单独成行的小标题都会各自成块。
• 按句子只出1块：内容是英文，切句子的分隔符不含英文点号。
• 固定长度调大重叠块数不变：落进了重叠失效区间，块大小不超过300时会这样。
• 块数正常但内容缺了一大段：纯文本里写了尖括号包着的标签名，整篇被当成HTML解析掉了一部分。

这五条覆盖了绝大多数“结果看起来不对”的情况。共同点是它们都不报错，工具会一本正经地给你一个基于错误切分的评分，而那个评分看起来跟正常结果没有任何区别。这类静默失败比报错难查得多，因为你根本不知道该去查。

粘Markdown和粘HTML，结果为什么天差地别？

上一节的坑往下追一层，就是这一节：同样一篇文章，你从哪儿复制过来的，直接决定了工具能不能正常工作。

那道HTML转文本的处理都做了什么

输入内容进来之后会先过一道预处理，它的动作有四个：先把脚本和样式整块删掉；再把所有h1到h6标题标签的文字改写成三个井号加标题文字，前后补空行；然后给段落、列表项、div、换行、表格行这几类标签各追加一个换行符；最后把连续三个以上的换行压缩成两个。

关键就在第二步：三个井号这个中间格式，只有从真HTML标签转过来才会有。你手写的Markdown不会经过这一步，因为它压根不算HTML。

怎么办

两条路，选一条：

第一条，粘HTML。在浏览器里打开你要检查的文章页，右键查看源代码，把正文那一段带标签的HTML复制进来。这是最贴近真实的做法，因为AI抓到的本来就是HTML，它面对的也是同一道从HTML提取文本的过程。这条路能让四种策略全部正常工作。

第二条，把两个井号改成三个。如果你手上只有Markdown原稿，最省事的做法是在输入框里把二级标题的两个井号统一替换成三个井号。这不影响其他三种策略，只为按标题分节这一种服务。

正文HTML具体怎么取

说“复制正文的HTML”容易，实际操作时新手常犯的错是把整页源码一股脑粘进去。那样导航菜单、侧栏推荐、页脚版权、评论区会全部混进来，切出来的块里一大半是站点框架而不是内容，评分自然一片红，而红的原因跟你的文章毫无关系。

取的方法有两种。图省事的做法是在页面上选中正文，右键选“检查”，在开发者工具里找到包住整篇正文的那个容器元素，右键复制它的外层HTML。讲究一点的做法是直接看页面源码，找到正文容器的起止标签，把中间那一段拷出来。两种都不难，关键是只要正文容器，不要它外面的任何东西。

还有一个细节：如果你的文章里有代码块，里面的尖括号在源码中通常已经是转义实体了，粘进来之后会被还原成真标签再被解析掉。检查以代码为主的技术文章时，建议先把代码块整段删掉再跑——反正代码块本来也不参与语义检索，留着只会干扰块长分布。

顺带说一个反向的坑：那道预处理判断内容是不是HTML的方式，是看有没有出现尖括号加一个字母的组合。所以如果你的纯文本里恰好写了尖括号包着的标签名，比如在讲HTML的教程里写到某个标签，整篇内容会被判成HTML走浏览器解析，那些被你当成正文的标签会被真的当标签解析掉，直接从文本里消失。写前端教程的人容易踩这一条。

重叠参数什么时候会静默失效？

重叠是分块里一个很实用的参数：让相邻两块共享一段内容，被硬切断的句子至少在其中一块里是完整的。工具里它是一个从0到300的滑块。

只有一种策略认这个参数

第一件要知道的事：重叠只在固定长度这一种策略下生效。按段落、按标题、按句子这三种，切分函数根本不接收这个参数。但界面上的滑块一直在那儿，你调它、数值跟着变，切出来的结果毫无变化。

这个设计其实说得通——按段落切本来就是以段落边界为准，谈不上重叠。但界面没有把这个滑块灰掉，也没有任何提示，就容易让人以为自己调的东西起作用了。选了后三种策略时，直接忽略这个滑块即可。

固定长度下也有一个失效区间

即使在固定长度策略下，重叠也有一段会失灵。它计算下一块起点的方式是用块大小减去重叠，如果结果不大于0，就退回用块大小本身当步长。

而滑块的取值范围是：块大小150到1500，重叠0到300。这两个区间一交叉，问题就出来了：

也就是说，块大小不超过300、同时重叠拉到300时，重叠被完全忽略，而滑块上那个300一直亮着。这个组合不算刁钻——想模拟小块检索的人很自然会把块大小往小了调，再把重叠往大了拉，正好落进去。

实用的判断办法是看块数：开了重叠之后块数应该明显变多（因为步长变小了），如果调大重叠块数纹丝不动，就是落进这个区间了。把块大小调到350以上就正常了。

重叠不是越大越好

知道怎么让重叠生效之后，还得知道它的代价。重叠的本质是让同一段内容在索引里存多份，块大小500、重叠250意味着每段内容差不多要存两遍，索引体积翻倍，检索时也更容易出现好几个高度相似的块同时被召回、互相挤占名额的情况。

所以真实系统里的重叠通常设得比较克制，常见配置是块大小的一到两成。工具默认给的50对500的块大小正好是一成，这个默认值是合理的，不必急着往上调。

更根本的一点是：重叠是给切分兜底的补丁，不是内容质量的替代品。它能让被硬切断的句子在某一块里保持完整，但救不了一段本来就依赖上文才能读懂的内容。指望调大重叠来解决自包含问题，方向就错了。

概览里那个平均块长为什么不能信？

结果区顶部有五个概览数字：切出的块、平均块长、平均自包含分、需要改的块、全文约token。其中“平均块长”这一项的算法有个口径问题。

它的算法是用清洗后的全文长度除以块数。在没有重叠的时候这没问题；一旦开了重叠，同一段内容会同时出现在相邻两块里，块的总长度大于原文长度，而分子用的还是原文长度。

实测的偏差不小：块大小设500、重叠设250时，界面上的平均块长显示240，而把每一块的长度加起来除以块数，真实的平均值是430。差了将近八成。

这个数字读错的后果是具体的：你可能会以为自己的块切得太碎、于是回头把块大小调大，而实际上块长本来就接近你设的值。所以有一条简单的替代做法——别看概览里那个平均值，直接看每一块头部标注的字符数，那个数字是每块的真实长度，没有任何折算。

顺带说一下同一排的“全文约token”。它的折算方式是中文按每字1.05个token、其余字符按每4个字符1个token。这是个量级参考，不同模型的分词器差异不小，真要精确值得用对应模型的分词器算。工具页对这一点也是明说的，不算隐瞒。

英文内容为什么会全线报红？

如果你拿一段英文内容跑这个工具，八成会看到满屏的红色警告。这不是你的英文写得不好，是判定规则里少了一个字符。

句子结束的判定不含英文句点

工具判断一块的结尾是不是完整句子，靠的是一个字符集合：句号、感叹号、问号、半角感叹号、半角问号、省略号，后面可以再跟一个引号或右括号。这个集合里没有英文的点号。

后果是每一块的结尾都过不了检查，全部被判“结尾被切断”，每块扣22分。实测同一段内容的中英文两个版本，固定长度策略下英文版3块全红、中文版只有1块被判切断。

按句子凑块也会失灵

同一个问题在另一处也出现了：按句子凑块这个策略，切句子用的分隔符同样不含英文点号。所以一整篇英文内容会被当成一个句子，凑块的循环把它整个塞进一块里输出。

这两处叠在一起，结论是：这款工具目前只适合检查中文内容。做外贸和出海的人得注意这一点，你的英文落地页在这里跑出来的分数没有参考价值——不是内容不行，是尺子上没有那一格。

要检查英文内容，一个笨但有效的临时办法是：把英文文本里的点号加空格批量替换成中文句号，跑完再看结构性问题。指代词和跨块引用那两项对英文本来就不适用，能看的主要是块的长度分布和切断位置。

中英混排的内容怎么读结果

做出海的人写的中文内容里，往往夹着大量英文产品名、参数和引文。这种混排内容不会全线报红，但会出现一种特定的偏差：凡是以英文句子结尾的那些块被判切断，以中文句号结尾的正常。

看到红标块集中在“这一块正好以一句英文结尾”上，就可以判定是尺子的问题而不是内容的问题。判断方法很简单：把那一块的最后一个字符看一眼，是点号就跳过，是别的才需要认真对待。

自包含评分扣的是哪几项，哪些是误伤？

每一块的右上角有一个自包含分，满分100，80分以上绿色、55到80橙色、55以下红色。扣分项一共六类：

开头不完整的白名单漏了几个常用符号

这一项的判定是看块的第一个字符在不在一个白名单里，白名单收了井号、汉字、字母数字下划线、以及几种引号和左括号。没收进去的常用开头字符有三个：书名号、破折号、省略号。

所以一段以书名号开头的话，比如介绍一本书的段落，会被判成“开头不完整”扣18分。以破折号或省略号起笔的文学性写法同理。这三种在中文写作里都不算罕见。

开头就是指代那一项收得太宽

这一项要抓的是“这样一来”“它的做法是”这类真正依赖上文的开头，抓得对的时候很有价值。问题是它的词表里除了指代词，还收了一批连词和序数词：因此、所以、于是、另外、其次、最后、同样、同理、反过来。

这就误伤了一批完全自足的句子。实测下面三句都被判“开头就是指代”扣20分：

• 最后一步是提交订单。——“最后”在这里是流程序数，不指代任何上文
• 同样的道理适用于移动端。——虽然有承接意味，但句子本身是完整陈述
• 因此我们把结论放在开头。——“因此”确实承上，但这一句读者能独立看懂

怎么用这一项才对：把它当成一个待复核清单，而不是判决书。被标出来的块自己扫一眼，真的看不懂就改，能独立看懂就跳过。列表里以“第一步、第二步、最后一步”组织的操作流程，几乎注定会被标一片红，那属于正常现象。

跨块引用这一项判得挺准

挑了这么多毛病，得说一项它做得对的：跨块引用的识别。它抓的是“前面提到”“上文”“如上所述”“下文”“下面会”“见上”“前一节”这类表述，这些词组的语义相当明确，几乎不会有误判，而它们标记出来的问题又是真问题。

一句话里写着“前面提到的那个方法”，等于明确告诉读取方信息不在这一块里。这种句子在长文里非常多，写的时候完全是自然的，因为作者默认读者是从头看下来的。被标出来之后处理方式有两种：要么就地补一句说明，要么把被引用的信息挪进同一段。这一项只扣12分，但它指出的问题往往比扣22分的那些更值得改。

主题词覆盖怎么填才有用

目标查询词那一栏是选填的，不填的话评分只看结构，填了会多一项覆盖检查。建议填，但要填对。

填的原则是：填你希望别人用来搜到这篇文章的那两三个词，不是填这篇文章里出现频率最高的词。这两者经常不一样。一篇讲分块的文章里出现最多的可能是“块”这个字，但真正的检索入口是“RAG分块”“检索单元”这样的词组。

填两到三个最合适。填一个太粗，几乎所有块都会命中；填五六个则每块都会拿到“仅覆盖部分主题词”的黄标，红黄一片反而失去了指示作用。填完之后重点看那些完全不含主题词的块——如果一段明明在讲主题却一次都没提到主题词，多半是整段都在用代词指代，那是真该改的地方。

主题词明明命中了，正文里为什么不高亮？

目标查询词那个输入框有两个作用：一是参与评分，检查每块是否包含这些词；二是在块的正文里把命中的词高亮出来。这两件事用的是两套判定，偶尔会打架。

评分那一步是在原始文本里找词；高亮那一步是在转义之后的文本里找词——转义是为了安全，会把尖括号之类的字符换成HTML实体。

大部分时候两边结果一致，看不出区别。但如果你的主题词本身带尖括号，比如检查一篇讲图片标签的文章、把标签名当查询词填进去，就会出现一个矛盾的画面：这一块被判定为命中主题词、评分里不扣分，正文里却一个高亮都没有。因为转义之后原文里的尖括号已经变成了实体，查询词按原样再也匹配不上。

这个问题只影响带尖括号或者带与号的查询词，日常填中文词不会碰到。知道有这么回事就行，看到“主题词齐全”的绿标但正文没高亮，不必怀疑自己眼花。

emoji被切成两半是怎么回事？

固定长度策略下还有一个细节值得提，虽然它更像趣闻而不是实用问题。

切分是按字符位置硬切的，而JavaScript里的字符串以16位为一个单位计数。绝大多数emoji和一部分生僻汉字要用两个单位才能表示，硬切正好落在这两个单位中间时，一个完整的emoji就被劈成了两半，页面上渲染出来是两个乱码方块。

实测把一串夹杂emoji的短文本按每3个字符切开，切出来的块里确实出现了半个emoji。Unicode的文本分段标准专门定义了什么样的边界才算安全的字符边界，按字符位置硬切显然不在此列。

实际影响很小，因为真实的块大小是几百字符，一篇文章里最多也就切坏一两个符号。但它是一个有用的提醒：固定长度切分对内容的完整性是零保护的，它连一个emoji都保不住，更别说一个论证的完整性了。这正是这个策略存在的意义——它演示的就是最坏情况。

一次完整的分块体检该怎么走？

把坑说完，说说正常流程。整套走下来大概三分钟。

准备输入

去浏览器里打开要检查的文章，查看源代码，复制正文那一段HTML粘进输入框。别粘整页源码，导航、侧栏、页脚会把结果搅乱。如果只有Markdown原稿，记得先把二级标题的井号补成三个。

四种策略各跑一遍

这是最容易被跳过、但价值最高的一步。工具模拟的这四种切法，对应的正是检索框架里通行的几类切分器——按长度切、按文档结构切、按句子边界切。四种策略不是让你挑一种，是让你从四个角度看同一篇内容：

• 固定长度：看最坏情况。这是各类检索框架最常见的默认行为，你的内容在这里的表现是下限。
• 按段落：看理想情况，同时暴露哪些段落长到需要二次切分——那些段落本身就该拆。
• 按标题分节：看每个小节能不能独立成立，顺便检验小标题写得够不够具体。
• 按句子凑块：看质量较好的实现下你的内容能到什么水平。

四轮跑完，对照的是同一篇内容在不同切法下的分数波动。波动越小说明内容的结构越稳，无论落到哪家引擎手里表现都不会太差；波动大说明你的内容严重依赖某一种切法，换一家就可能垮。

参数怎么设

块大小从500起步，这是常见实现的中间值。想看小块检索的表现就往300调，别调到300以下同时又把重叠拉满。重叠设50到100是常见配置，只在固定长度那轮有意义。

目标查询词填两到三个，填这篇文章最想被搜到的那几个词。填多了会让每一块都拿到“仅覆盖部分主题词”的黄标，反而看不出重点。

结果怎么读

顺序建议是：先看块数是否合理（排除策略没生效），再逐块看头部的真实字符数（不看概览的平均值），然后重点看红标块，最后才看平均分。平均分只适合自己跟自己比——改写前后各跑一次，看分数往哪个方向动，拿它跟别人比没有意义，因为分数高度依赖内容体裁。

一份真实结果长什么样

举个具体的读法。假设你粘进一篇三千字的教程正文HTML，固定长度策略、块大小500、重叠50，跑出来是7块，平均分68，需要改的块显示3。

第一步先确认块数合理：三千字符除以450的步长，7块正好对得上，说明策略生效了。第二步逐块看头部的字符数，发现6块都在490到500之间、最后一块只有180，这是正常的尾块。第三步看那3个红标块，扣分理由分别是“结尾被切断”“开头就是指代”和“结尾被切断加块过短”。

读到这里就能下判断了：三块里有两块的问题是硬切造成的，跟内容本身无关，因为固定长度策略本来就会切断句子；真正值得改的是那个“开头就是指代”的块，去看一眼它的第一句，如果确实是“这样一来……”开头，那就是内容问题。七块里真正需要动手的只有一块，剩下的是策略的固有代价。

这个例子想说明的是：红标数量本身没有意义，红标的理由才有意义。固定长度策略下切断类的红标必然大量出现，那是这个策略的定义决定的；真正该盯的是指代类和跨块引用类，那两种在任何策略下都是内容的问题。

看完评分之后，内容到底该怎么改？

工具下面会给一段改写方向，说的都对，但比较笼统。结合实际经验，真正见效的调整是这么几条。

把结论提到段落开头

一段的第一句就给结论，后面再展开论证。这样即使这一块被单独召回，开头那句本身就是一个可用的答案。这条是所有改法里性价比最高的，因为它同时解决了两个问题：块被切断时开头仍然完整，以及检索方看第一句就能判断这块有没有用。

让段落长度接近块大小

段落长度控制在四百到六百字符，段落边界自然就成了块边界，硬切造成的伤害大幅下降。段落太长会被二次切分，切出来的后半截通常是残的；太短则信息密度不够，容易被判块过短。

关键段落里把主题词写出来

这不是让你堆关键词，而是避免整段用“它”“该方法”“这个方案”指代主题。一段内容如果通篇没出现主题词，检索时很容易被判为不相关——人能从上下文推断，向量检索推断不了，它手里只有这一块。

小标题写具体

用按标题分节的策略时，标题就是这一块的身份标签。写“方法二”和写“用重叠窗口缓解语义断裂”，检索效果差得远。这条顺带也解决了页面本身的可读性问题，属于一举两得。

数据和结论别拆到不同段落

把数字放一段、结论放另一段，被切开之后每块都是残的：一块有数据没结论，另一块有结论没依据。两者放在同一段里，这一块才是完整可引用的。

一个实际的调整例子

保哥手上有个做出海宠物用品的独立站，产品指南写得相当扎实，但在这个工具里跑出来一片红。问题集中在两处：一是习惯用“这款”“它”指代产品，整段读下来不出现品类词；二是把测评数据单独列成一段，紧跟着的结论段落只有两句话，被判块过短。

调整只做了两件事：把每段第一句里的代词换成具体品类名，以及把数据和结论合成一段。改完重跑，红标块从大半降到两三块，那两三块都是列表页那种天然碎片，改不了也不必改。

这个案例里最值得说的其实是过程本身：他们原来觉得内容没问题，是看到自己那段被切开的样子之后才认可要改的。工具最大的价值可能不在评分，而在那个直观的切开效果——评分能吵，切开的样子吵不动。

哪些红标可以放着不管

改写这件事得有个止损点，不然会陷进去。下面这几类红标建议直接跳过：

• 固定长度策略下的切断类红标：这是策略的固有产物，不是内容问题。同一篇内容用按段落或按句子策略跑一遍，这些红标会自动消失。
• 列表和表格切出来的碎块：产品参数表、步骤清单被切开之后每块都很短、都不成句，这是数据本身的形态决定的，改不了也不必改。
• 流程类内容的序数词红标：以第一步、第二步、最后一步开头的段落会被判成指代，前面说过这是词表收得太宽，属于已知误伤。
• 正文最后一块的块过短：尾块短是必然的，除非你愿意为了凑长度多写两句废话，那显然不划算。

剩下值得改的，其实就集中在两类：真的以指代词开头、脱离上文看不懂的段落，以及明确写着“前面提到”这类跨块引用的句子。这两类在任何切分策略下都是问题，改了对所有引擎都有效。抓住这两类，其余的红标看一眼跳过即可。

跑完之后还能接什么

分块只是AI能不能引用你的其中一环。想弄清楚为什么AI要按块检索、块该切多大这些底层问题，站里有一篇专门讲内容分块优化机制的文章可以接着看；想验证改完之后会不会真被引用，可以再用模拟测试平台跑一轮。另外，检索方能不能顺利拿到你的内容清单也是同一条链上的事，站里那篇llms.txt校验器教程讲的就是这一层。

关于分块的底层原理，Anthropic那篇上下文检索的文章值得一读，它举的那个失效例子特别经典：一段写着某公司营收环比增长3%的话，单独拿出来根本不知道说的是哪家公司、哪个季度。这正是自包含这件事的全部意义。

常见问题解答

点了加载示例又选按标题分节，为什么只切出一块？

示例文本用的是两个井号的二级标题，而按标题分节的逻辑只认三个井号；输入内容里检测不到HTML标签时不会做任何转换，两个井号就保持原样，于是一条也匹配不上，整篇成了一块。解决办法是粘HTML源码而不是Markdown，或者手动把两个井号改成三个。

重叠滑块调了没反应是怎么回事？

两种可能。一是你选的策略不是固定长度，按段落、按标题、按句子这三种根本不接收重叠参数，滑块调了也没用。二是块大小设得不超过300、同时重叠拉到了300，此时计算步长时会退回用块大小本身，重叠被完全忽略而滑块仍显示300。把块大小调到350以上就正常了。

概览里的平均块长跟每块标注的字符数对不上？

以每块头部标注的为准。概览那个值是用全文长度除以块数算的，开了重叠之后同一段内容会重复出现在相邻块里，块的总长大于原文长度，而分子还是原文长度。实测块大小500、重叠250时，界面显示240而真实平均是430。

英文内容为什么每块都报结尾被切断？

句子结束的判定字符集里没有英文点号，所以英文块的结尾一律过不了检查。按句子凑块也受影响，切句子的分隔符同样不含点号，整篇英文会被当成一个句子塞进一块。这款工具目前只适合检查中文内容，英文的分数没有参考价值。

最后一步是提交订单这种句子，为什么被判开头就是指代？

因为指代词表里除了这、那、它这类真指代词，还收了因此、所以、于是、另外、其次、最后、同样、同理这批连词和序数词。流程类内容用第一步、第二步、最后一步组织时会被标一片红。把这一项当成待复核清单而不是判决书，自己扫一眼能独立看懂就跳过。

块的开头是书名号或者破折号，为什么算开头不完整？

判定用的是一个字符白名单，收了井号、汉字、字母数字、几种引号和左括号，没收书名号、破折号和省略号。以这三种符号起笔的段落会被扣18分。这属于已知误伤，内容本身没问题。

提示主题词齐全，正文里却没有高亮？

评分是在原始文本里找词，高亮是在转义之后的文本里找词。如果你的查询词带尖括号或与号，转义后就匹配不上了，于是出现判定命中但不高亮的矛盾画面。只影响这类特殊查询词，填中文词不会碰到。

四种策略我该选哪一种？

四种都跑一遍，别只选一种。它们不是让你挑最优解，是让你从四个角度看同一篇内容：固定长度看下限、按段落看理想值、按标题检验小标题写得够不够具体、按句子看较好实现下的水平。真正要看的是四轮之间的分数波动，波动小说明内容结构稳，换哪家引擎表现都不会太差。

权威参考资料