长文润色后后半段内容消失，通常不是单一原因。妙笔生花这类写作端负责把整篇稿切成可提交的片段、再把结果拼回去；推理服务负责在给定上下文长度内完成生成与改写。丢内容要么发生在写作端的切分与回拼，要么发生在模型侧的输入被截断、输出被长度上限截住。判断顺序建议先记账再动手：把同一次提交的输入长度与返回长度对齐，再用单块提交和整篇提交做对比，最后才考虑调上下文长度。

适用场景：润色或改写长文时，后面若干段缺失、整块内容消失，或提交后直接返回空。操作动作：先记录每次提交的文本长度、返回长度、耗时与失败提示原文，再用同一篇稿分别做单块提交与整篇提交。验证方式：比较两种切分粒度下结果是否覆盖原稿全部段落。风险边界：调大上下文会抬高显存与单次耗时，切得过碎可能破坏段落间衔接，两边都要留复测记录。

记录一次丢内容链路的完整输入输出

先把可比较的数字拿到手，再谈原因。最少记四项：提交文本长度（字符数或 token 数，同一口径前后保持一致）、返回文本长度、耗时、失败提示。耗时建议拆开记——排队等待和实际生成分开，否则看不出是模型慢还是任务堆住了。失败提示要原样抄下来，包括错误码和那句超限文案，不要只写“报错”。

可以在写作端每次发请求前落一条结构化日志，字段如下，键名按你实际用的写作端和推理服务替换：

{"doc_id": "draft-001", "chunk_index": 3, "chunk_total": 8, "submit_chars": 1200, "return_chars": 0, "latency_ms": null, "error": "context length exceeded"}

关键是记录“写作端真正发出去的内容长度”，而不是原稿长度。提示词模板、系统指令、前文拼接都会计入提交长度，只记原文字符数会一直对不上账。

判断丢内容发生在写作端切分还是模型侧截断

把问题收敛到一层，靠两个对比。

• 对比提交长度与返回长度：提交 1200 字返回 300 字且没有报错，常见于输出被最大长度截住，属于模型侧；提交后返回 0 或直接失败，多半是输入加提示词已经超过上下文上限。
• 对比单块提交与整篇提交：把缺失的那一块单独提出来跑一次。单块能完整返回、整篇才丢，问题在写作端的切分或回拼（比如某块没被调度、拼接顺序错、重叠区被覆盖）；单块也缺尾，往模型侧看。

回拼环节要单独查一遍：有些写作端按返回顺序拼接，某块超时被跳过时不会补位，整篇看起来就“少了一段”。可以要求写作端输出每块的首尾各一小段，作为锚点核对原稿段落是否都被覆盖。

在写作端调小单次提交规模复测同一篇稿

如果怀疑是一次提交过大，先在写作端改粒度，不动模型参数。调整入口通常有两处：页面上润色/改写设置里的分段大小、最大字符数、并发数；以及配置文件里的 chunk_size、max_chars、overlap 之类字段。字段名各家不同，按实际界面和配置修改。

{"pipeline": "polish", "chunk_size": 800, "chunk_overlap": 80, "concurrency": 1}

建议保留少量重叠（如相邻块共享一小段尾部），避免把句子或论点从中间切断，导致改写后语气接不上。复测判定标准：用同一篇稿，以更小粒度重跑，逐块对比提交长度与返回长度是否接近，再检查拼接后是否覆盖原稿所有段落和锚点。如果调小后完整了，说明瓶颈在单次提交规模；如果仍然缺尾，再回到模型侧排查输出上限。

在模型侧调上下文长度前先算清占用

上下文长度不是单看输入，它是“这次提交的全部内容 + 期望输出”的总和：提示词模板、系统指令、前文拼接、当前块正文，再加你给输出留的额度。切分粒度越小，单次需要的上下文越短；粒度越大，越依赖把上下文开大。

所以先算账再改参数：单块正文长度加提示词开销加期望输出长度，是否已经贴近当前上限。调大之后要盯几个观察点——显存占用（或服务侧内存）、单次生成耗时、并发跑起来后的排队情况、以及输入与输出额度之和是否触顶。建议一次只改一个参数、小步调整，改完立即用同一篇稿复测，避免同时动粒度和上下文导致结果无法归因。把上下文当作“按需留余量”的资源，而不是越大越好。

把调整后的参数与结果写进对照记录

每次调完留一行记录，下次同类问题可以直接复用，不用从零试。

判读方式：优先选能保证完整性、且单次耗时和资源占用都能接受的组合。完整性用段落锚点核对，别只看总字符数接近就以为没丢。如果只有把上下文开到很大才完整，先问一句是不是切分粒度本身太粗；反过来，如果为了完整把块切得很碎、段落衔接变差，也属于没解决问题。记录里顺手写下这次改动的原因，比只记参数值更有用。