编辑一份会议记录时，很多人会顺手把零散材料丢给大语言模型，让它先“理一理”。这一步很轻，屏幕那头却发生了不少事：切分句子、寻找关联、补上过渡，再把结果写得像一份已经想清楚的稿子。问题也在这里——输出越顺，人越容易跳过核对。
我倾向于把这类使用看成“借一副临时眼镜”，而不是“请一位替身”。眼镜能帮你看清字，替身会替你做判断。它擅长前者：归纳、改写、按条件筛选、把不同来源的说法摆在一起。它不天然擅长后者：确认哪条信息可信、哪句话该由谁负责、以及这个结论在真实场景里会不会伤人。
上下文不是记忆，检索也不是理解
围绕“记笔记”这个动作，常被混在一起的是三件事。第一件是上下文窗口：这一次对话里，模型能看到的材料有多少。第二件是外部检索：它能不能去别处找资料，再把相关片段带回来。第三件是长期记忆：系统是否把过去的信息留下来，供以后调用。三者都能让回答看起来更“懂你”，但边界并不一样。
上下文像一张摊开的桌面，材料放得下，不代表每份材料都可靠；检索像让助手去档案室取几页纸，取回什么、漏掉什么，取决于索引和提问方式；长期记忆则更像在桌面之外留了一个抽屉，放什么、留多久、谁能打开，都是产品设计问题。把这些都叫作“记住”，容易让人误以为模型已经形成了稳定的理解。
- 材料进来时，先看来源和日期，别让过期信息借着流畅表达混过去。
- 要求模型区分“原文写了什么”和“它推断什么”，把两件事分开摆。
- 涉及对外发布的内容，保留人工复核这一步，不把审稿责任交给生成结果。
这不意味着要贬低工具。恰恰相反，大语言模型在“把混乱变整齐”上很有用：一份散乱访谈可以按主题归并，一封长邮件可以压缩成待办，一组产品反馈可以按场景重新分组。只是整齐不等于正确，条理也不等于判断。编辑真正要做的，是在整齐之后追问：这句话的依据在哪里？有没有被删掉的反例？换个读者看，会不会产生误解？
真正的门槛在“接手”
我见过一种稳妥的用法：让大语言模型先产出一份“可修改的草稿”，而不是“可发布的答案”。草稿的价值在于暴露结构，让人看到哪些地方材料不足、哪些地方逻辑跳跃。接着，人再补来源、换措辞、删掉不确定的推断。这个流程不快，却把模型放回了它擅长的位置。
反过来，如果一开始就追求“直接能用”，人会被流畅度带着走。句子越顺，越难发现其中混着的假设；段落越完整，越容易忘记它只是根据有限材料拼出来的版本。对这种工具保持一点不信任，不是姿态，而是工作方法：先问它依据什么，再决定自己信到什么程度。
所以，当模型开始“记笔记”，真正的问题不是它记得够不够多，而是人是否还愿意接手后面的判断。工具把材料整理好，责任并没有跟着被整理掉。