一、窗口变大了，问题解决了吗
百万上下文听起来很强，实际用起来常见两个现象：前面塞的内容被忽略，回答开始变慢。
前者叫中间遗忘，后者和计算量有关。
窗口从四 K 涨到一百 K，问题解决了吗？没有，换了个形式。
以前是「放不下」，现在是「放了但没读到」。后者更隐蔽，因为你不容易发现。
我做过一个测试：把关键条款放在两万字的位置，问模型。答错率比放在开头高了三倍。
二、中间遗忘是怎么回事
长上下文里，位于开头和结尾的信息更容易被利用，中间段落容易被跳过去。
这不是玄学，有实测支撑：把关键信息放在不同位置，回答准确率会明显波动。
所以用法要改：重要内容放开头或结尾，中间放背景材料。
字体最容易坏的地方是标点。中文标点占一个全角，拉丁字体里往往只有窄半角。
所以很多仿制字体看着像，但引号、书名号一出来就露馅。
做字体前先定标点集。前一百个字符就是这三个：逗号、句号、引号。
三、堆满窗口的三个代价
一、钱。token 按量计费，塞满就是按满算。
二、时间。输入越长，首字延迟越高。
三、准确率。无关内容会稀释注意力，长文里问细节反而更容易答错。
堆满窗口有三个代价。第一是钱，按 token 计费的话，一次长对话可能比十次短对话贵。
第二是速度，输入越长，首字延迟越明显。第三是准确率，无关内容会稀释关键信息。
三个代价里，第三个最容易被低估。上下文不是越多越好，是越相关越好。
四、怎么用才划算
我的四条做法：
一、先摘再问。长文档先让模型做分段摘要，再基于摘要提问，比直接丢全文准。
二、结构优先。给标题和章节目录，让它知道去哪找。
三、只带相关段落。检索出三段相关原文，胜过塞十页无关内容。
四、把关键约束复述一遍。在问题末尾重述一次限制条件，能明显减少跑偏。
共用规则的设计，我按三条来：重心一致、字面大小一致、以及笔画密度相近。
重心是字的重心高度，一条水平线上。字面是字的外框大小，看起来才一样大。
第三条最难。笔画多的字要适度收，不然整行会显得脏。
五、判断该不该用长上下文
问三个问题：
一、任务是否真需要跨段关联？只需要一段，就别塞全文。
二、错一次的代价高不高？高就分步做。
三、有没有结构化替代方案？能用检索解决的，就别硬塞。
怎么用才划算，我的四条经验。一、先让模型列目录，再按需取段。
二、关键约束写在开头和结尾，中间放过程材料。三、每几轮做一次摘要复述。四、同一任务别反复重发全文。
第四条是最省钱的一条。很多人怕模型忘，每轮都把全文再贴一次，token 花在重复上。
六、一句实话
上下文窗口是容量，不是能力。会把东西塞进去，和会用，是两件事。
判断该不该用长上下文，看三个问题：材料是不是非结构化、问题是不是需要跨段推理、错误代价高不高。
三个都是，用长上下文；只有第一个是，先做检索再喂。
最后一句实话：长上下文是能力，不是策略。有能力不等于该用。
打包命名，用「字重_字面_语言」三段式。比如「Regular_GB2312_SC」。
原因很实际：字体文件一多，靠记忆分不清。名字里有信息，选的时候才不犯错。
再给每个字体配一张样张图。三个月后看名字和样张，基本就能找到想要的那款。
补一句：字间距也要一起设计。中文的字间距和拉丁文完全不同，直接套用会显得挤。
这一点在标题字体里尤其明显。
再补一句：汉字的重心要统一在一条线上。高低不一，整行就像波浪。
先把重心画一条线，再排字，效率高得多。
再补一句：字体的「黑度」要一致。同一字重里，笔画密集的字会显得更黑。
设计时要做「视觉补偿」，把密集字的笔画稍微收一点。
这一步不做，整段文字会有斑。
再补一句：字体先做「常用三千字」。剩下的是补字，不是设计。
三千字覆盖九成文本。
先能用，再讲究。
延伸参考
遇到看不懂的参数名，前端 Wiki 的词条比搜索页干净。
留一句：长上下文最省的用法，是少塞。