上下文不是记忆

文本是按 Token 计量的

模型不直接读字符。输入的文字先被切成一串片段，这些片段叫 Token。常见的切分方法是把高频词整体保留、把低频词拆成更小的构件，这样既能覆盖生僻词，词表又不会无限膨胀。这类方法在神经机器翻译时期已经成型，今天仍是主流。^S1

对中文使用者而言有两个实际后果。其一，同样一段内容，中文往往比英文占用更多 Token，因此在长度受限时中文材料更早触顶。其二，异体字、罕用字、生僻的古文用字会被切得更碎，处理长篇古籍时的 Token 消耗常常高于直觉估计。真要精确估算，应当用厂商提供的分词工具实测，而不是按字数折算。^S1S2

窗口有多大，以及它为什么不等于「能用多少」

上下文窗口指一次交互中所有内容加起来的 Token 上限，包括系统指令、此前的对话、你贴进去的材料，以及模型即将生成的输出。窗口大小随模型不同而不同，且更新频繁，任何具体数字都应以当日的官方文档为准。^S2

放在哪里，会影响用不用得上

把材料放进窗口，不等于模型会平均地使用它。有研究测试了模型在长上下文中定位关键信息的表现，发现同一条信息放在开头或结尾时被正确利用的比例，明显高于放在中间的情形，而且上下文越长，这一落差越明显。这一现象常被称为「迷失在中间」。^S3

由此可以得到几条不依赖具体产品的操作原则：关键的任务定义与验收标准放在最前面，需要模型逐条落实的清单放在最后重述一次，真正重要的原文尽量不要埋在一大堆背景材料的中段。这不是玄学，而是对已知规律的顺应。^S3

所谓「记住」是怎么回事

模型在一次生成结束之后并不保留任何状态。你在第五轮里说「按刚才那个体例」，之所以有效，是因为前四轮的文字被重新送进了这一次的上下文。一旦这些内容被截断、被摘要压缩，或者你换了一个会话，约定就不复存在。有些产品提供跨会话的记忆功能，那是外部系统在替你保存并重新注入文本，属于产品能力，不是模型能力。^S2

对本站这类长期项目，稳妥的做法是把所有需要沿用的东西外部化：体例约定写成一份文件，术语对照存成一张表，每次开工时显式贴入相关部分。这样做的好处不止于防止遗忘，还在于这些文件本身成了可以被审阅、被修订、被版本管理的对象。

把长材料拆开的几种做法

既然一次投喂不可靠，长材料就必须拆。拆法有三种，各适用于不同的文体。第一种是按结构拆，依卷、章、篇、条目的自然界限切开，每一段自成单位。这种拆法最省事，也最不容易破坏文意，适合体例整齐的著作、书目与年表。第二种是按任务拆，同一批材料过若干遍，每遍只做一件事：第一遍只抽取人名，第二遍只抽取年份，第三遍只标出存疑处。这种拆法的好处是每一遍的任务定义都极为单纯，出错时容易定位；代价是要多跑几遍。第三种是按疑难拆，先用程序或粗筛把明显无问题的部分挑出去，把剩下的疑难集中处理。这一种最省人力，但要求你事先能说清楚什么叫「明显无问题」。

无论哪一种拆法，接缝处都要有显式交接。所谓交接，是指每一段的处理不依赖你的记忆，而依赖一份写下来的东西。可行的做法是每处理完一段，就让模型输出一份极简的交接单，内容包括本段处理到哪里、沿用了哪些约定、留下了哪些待决问题、下一段需要注意什么。下一轮开工时，把交接单连同新的一段一并贴入，而不是指望上一轮的对话还在。交接单本身也是成果的一部分，它记录了这批材料是被怎样处理的。

还有一个常被忽略的细节：摘要不能代替原文。为了省空间而先让模型把前文压成一段摘要，再据以处理后文，等于把一次可能的失真固化下来，后面所有判断都建立在这份摘要之上。若确实需要压缩，应当压缩成结构化的要点清单而非散文式摘要，因为清单的每一条都还能回到原文核对，散文则不能。^S3