12G 本地推理生产线 ⑥ 本地模型长文写作 SOP：回声退化、毒上下文与四条对策

任务背景：131K 窗口的本地模型（第 5 篇主线配置）+ Cherry Studio 客户端，写三万字长篇小说。完成度 ≈ 一半（累计回答 14,095 + 382 + 327 + 2,029 ≈ 16.8K tokens ≈ 1.5 万字），服务侧全程健康（无上下文满、无死旋，全部正常 stop）。但写作过程暴露的四个问题，每一个都值得沉淀成 SOP。

问题一：单段远端回声退化

一条 15,083-token 的单段生成：前 10K 正常，远端（10K+ 之后）开始出现"他——他——“破折号结巴式重复，尾段整段报废。

这不是显存/参数问题——同期命中率、速度全部正常。这是模型单段长度的能力上限：一段生成越长，远端的重复倾向越重。

问题二：毒上下文回喂（更致命）

下一段续写请求把坏尾段整段塞回 prompt（16,780 = 前文 1,689 + 坏尾 15,083 + system）。模型看到满屏"他——"，模仿退化模式，“一种——一种——“锁死重复，整段作废。

关键点：服务侧日志再次全部正常。故障链是客户端侧的上下文管理造成的——把退化文本喂回去，等于教模型继续退化。

四条客户端 SOP

问题三：开放"继续"会提前 EOS

实测：开放指令"继续” → 模型想 311/279 tokens 后只写 71/48 tokens 就收笔。体感像"上下文满了"，实际可用空间还有 11 万——(stop) 是模型自己收笔。改成 “继续写第十一章，不少于 2000 字” → 单段 2,029 tokens @ 29.9 t/s 达标。

续写指令三件套：① 点名具体章节/节拍；② 给最低字数；③ system 加"禁止提前结束故事、禁止（未完待续）、禁止总结"。

问题四：客户端显示是误导

Cherry Studio 显示"1.9 万 Tokens"——那是请求合计（prompt 16,537 + 回答 2,029），不是回答长度。判断产出一律看服务端日志的 done: N tokens ... (stop) 行。客户端数字只能看个大概。

结语

本地模型写长文的正确姿势不是"调参调到不退化"（调不到，这是能力层事实），是把长文切成短段接力 + 交接点保持干净 + 指令给足约束。四条 SOP 落地后：单段 4–6K、坏尾不接、temp 0.9、反重复 system prompt——12G 本地卡 + 零成本推理，批量出章节初稿的流程就成立了。

下一篇：把这条生产线接进 Hermes Agent。