预答辩前夜我干了件蠢事把三十万字的学位论文整篇丢给 Claude Code让它全文校对错别字批注标出。它回了我一个错误码DOCUMENT_TOO_LARGE。文档超过约 80k 的文本阈值整篇读就不行了。当时离预答辩还有四十小时我差点直接开人肉模式好在冷静下来查了一下这个报错本身就是提示——超长文档走分块工具链里有现成的一整套。那晚之后我把大论文审校的节奏整理成了一套方法这篇写清楚适用于所有被长文档折磨的人。先看元信息再定打法第一件事不是校对是摸底。提示词一句话先读文档元信息报告字数、段落数和是否建议分块document_meta 会返回文档名称、字数、段数以及一条关键判断是否建议分块。三十万字的论文必然超阈值但超多少、怎么切先心里有数。摸底还有个附带好处模型端点通不通、文档连没连上这一步就验证了省得切到一半发现服务掉线。顺带说超阈值其实有个强制整读的选项但审校场景别用它三十万字硬塞进一次请求又慢又费注意力还被稀释分块是更聪明的路。分块的节奏按章推进只出清单核心工具是分页分块读取带游标和条数参数按顺序一块一块过。节奏上我的经验是三条第一以章为单位推进。别贪快全文连跑一章一块或几块出完这章的问题清单再进下一章。改论文是有手感的东西按章推进能顺手发现跨节的不一致——术语、称谓、图号风格这些恰恰是拼接痕迹所在。第二按问题类型分轮次。第一轮只跑错别字和标点第二轮跑术语一致性第三轮跑格式体例。一轮只盯一类问题比一轮全查的命中质量高得多清单也短人看得过来。第三每块只出清单不写回。所有块跑完再统一处理按分块顺序逐块校对每块只返回问题清单全部块完成后汇总去重再经我确认写成批注为什么要这样同一处问题可能在相邻块里被重复报告直接写批注会得到一堆重复批注更麻烦的是后面发现前面改错了逐块写回没法统一调整。汇总去重之后经确认一次性落批注文档里干干净净。批量写回一次最多两百条操作三十万字的论文分两三批提交足够。长文档的校对任务本身可能异步跑那就轮询等结果跑完再汇总。锚点长文档的定位生命线审校清单出来后要写回写回要定位三十万字里定位靠锚点。枚举段落的工具返回的每段都带锚点定位命中多个时会把候选锚点列出来让人选而不是自作主张挑一个。有一晚我遇到过 LOCATE_MISMATCH锚点校验失败。原因很简单——AI 读清单的间隙我又改了正文段落挪了位置锚点漂了。解法也简单重新枚举一遍段落拿新锚点再定位。长文档写作是活文档边改边审是常态锚点机制就是给这种常态兜底的。顺带一提分块读取顺带做了 Token 成本优化不需要每次把整本论文塞进上下文按需取块长会话的费用和速度都友好得多三十万字的全量会话和分块会话跑下来账单差距是实打实的。模型端本地用 Ollama 起一个也一样跑论文这种没发表的东西不出本机最稳妥。边界分块审校抓的是错别字、标点、术语一致性、格式类问题——机器擅长的机械一致性。论证是否成立、实验设计是否站得住、创新点是否立得住这些属于导师和评审的管辖范围AI 给不了答案。预答辩那晚我最后是凌晨两点跑完全部分块审校睡觉第二天白天专心改逻辑。体力活和脑力活分开排是我从那个错误码里学到的最重要的事。