别把聊天记录直接塞进大模型

产品里有一个看起来很自然的需求：系统已经积累了很多用户对话，能不能每周自动给每个人生成一份周报？

这周聊了什么，推进了什么，做了哪些决定，卡在哪，下周要跟进什么。听起来像一个标准的大模型总结任务。

但真正做起来，最危险的方案恰恰是最直觉的方案：把一个用户一周的聊天记录全部捞出来，拼成一个大字符串，然后丢给大模型写周报。

这条路很快会撞墙。对话太长，塞不进上下文；就算塞得进，成本也会随着用户数线性爆炸；更麻烦的是，一锅烩出来的周报没有结构、没有溯源，用户问“这条结论从哪条对话来的”，系统答不上来。

所以这篇文章想回答的问题不是“怎么让模型总结聊天记录”，而是：

如果一个产品要长期、低成本、可追溯地生成个人周报，系统结构应该怎么设计？

我觉得 Claude Code 的 /insights 给了一个很好的范本。它解决的不是周报问题，但它解决的是同一类问题：从大量非结构化会话里抽取信号，再聚合成一份报告。

/insights 解的是同一个结构问题

/insights 是 Claude Code 的内置命令。你运行它之后，它会扫描本地历史会话，分析你最近在做什么项目、哪些工作流顺、哪些反复卡壳，最后生成一份 HTML 报告。

把它和产品里的周报系统放在一起看，会发现它们的问题结构很像：

这类问题的共同点是：输入很散、很长、很脏，但输出要短、准、有结构。

如果直接让强模型读全部原始数据，模型会同时承担三件事：读完所有材料、判断哪些有价值、组织成报告。这既贵，也难稳定。

更合理的做法是把它拆成两步：先把原始对话压成结构化信号，再在信号上做聚合和叙事。

这就是 /insights 背后的核心范式。

关键不是总结，而是先打标签

/insights 真正值钱的不是“能出报告”，而是它怎么在不爆上下文、不烧钱的前提下读完大量会话。

抽象下来，它是一条 map-reduce 流水线：

每个会话
  -> map：便宜模型读全文，抽出结构化 facets
所有 facets
  -> reduce：聚合、分析、生成报告骨架
报告骨架
  -> 强模型写成叙事

这里最重要的东西是中间层：facets。

facets 可以理解成一组固定字段的语义标签。它不是最终文章，也不是原始全文，而是“这段对话里有什么值得被后续系统使用的信号”。

对周报系统来说，一条 facet 可能长这样：

{
  "source_id": "msg_8842",
  "user_id": "u_123",
  "week": "2026-W26",
  "topic": "支付重构",
  "type": "decision",
  "people": ["u_123", "u_456"],
  "status": "resolved",
  "signal": 0.82,
  "quote": "最终决定先接 Stripe，自研网关推迟到 Q3"
}

这层结构化中间层解决了四个问题。

第一，控制上下文。后续 reduce 阶段不再处理几千条原始消息，而是处理几十条高信号 facets。

第二，控制成本。高频、格式固定的抽取可以用便宜模型做，只有最后写叙事时才用强模型。

第三，支持增量。抽过的消息不用重复抽，下周只处理新增消息。

第四，支持溯源。每条结论都能挂回 source_id，用户可以点回原始对话。

所以周报系统的核心不是“总结 prompt 写得多好”，而是有没有一个稳定的结构化信号层。

周报系统的整体链路

如果把这个范式搬到产品里，数据流可以这样设计：

messages 表
  │  按 user_id + 时间窗口查增量
  ▼
降噪过滤
  │  丢掉寒暄、系统通知、过短消息
  ▼
切分归一
  │  长对话切片，统一上下文格式
  ▼
[Map] 便宜模型逐段抽 facets
  │
  ▼
facets 表
  │  落库、缓存、保留 source_id
  ▼
[Reduce] 按主题和类型聚合
  │
  ▼
周报骨架
  │  进展、决策、阻塞、待办
  ▼
[Narrative] 强模型写周报草稿
  │
  ▼
周报表
  │
  ▼
推送 / 展示 / 用户编辑

这里有几个细节很重要。

Map 阶段不要直接写周报，它只负责抽信号。比如把消息归成 progress、decision、blocker、todo、idea 这些类型，再给一个 signal 分，判断这条值不值得进入周报候选。

Reduce 阶段不要再读全文，它只在 facets 上做去重、合并、排序和主题归类。比如同一个支付重构话题里，可能有三条进展、一条决策、两个阻塞。reduce 要把它们合成一个可读的主题骨架。

叙事阶段才让强模型出场。它读的是已经整理过的骨架，而不是几千条原始消息。

这个分工看起来麻烦，但它是系统能跑久的关键。

周报比 /insights 更难的地方

直接套 /insights 的范式，只能搭出骨架。真正做周报，还会遇到几个更产品化的问题。

第一个问题是 signal 排序。

/insights 更像是在统计和分析全部会话，而周报的本质是从一堆事里挑出最该说的 5 到 8 条。用户不需要一份流水账，他需要知道这一周最重要的变化是什么。

所以 signal 不是装饰字段，而是周报质量的核心。它要同时考虑消息本身的重要性、和用户的相关性、是否有明确进展、是否需要后续行动，以及主题之间的多样性。

第二个问题是可追溯。

自动周报最容易让人不信任。用户看到一句“本周完成了支付网关方案决策”，很自然会问：这从哪来的？如果每条周报结论都能点回原始消息，信任感会完全不一样。

这也是为什么 facets 必须落库，而不是只作为模型过程里的临时文本存在。

第三个问题是隐私边界。

个人周报只能读该用户参与的对话。涉及其他人的内容，要做最小化引述和脱敏。周报系统不应该因为“总结得更完整”，顺手把别人不该看的信息带出来。

第四个问题是趋势对比。

一旦 facets 按周沉淀下来，系统就不只能写“这周发生了什么”，还可以写“这个阻塞上周就在，本周仍未解决”“某个主题连续三周升温”。这是一锅烩总结做不到的。

第五个问题是反馈回流。

周报最好先出草稿，让用户删掉、置顶、改写条目。用户的编辑行为不是附属功能，而是训练 signal 的反馈。哪类条目经常被删，哪类条目经常被保留，下一轮抽取就应该变得更准。

最容易犯的错

这类系统最容易犯的错，是跳过中间层。

很多人会觉得 facets 表很重：为什么不直接从 messages 生成 weekly_report？一开始确实能跑，demo 甚至会很好看。但只要用户变多、消息变长、质量要求提高，问题就会集中爆发。

没有 facets，就很难增量。每周都要重新读大量历史消息。

没有 facets，就很难调试。周报写错了，你不知道错在抽取、聚合还是叙事。

没有 facets，就很难溯源。用户看到结论，只能相信模型。

没有 facets，就很难做趋势。因为历史被压成了不可分析的自然语言报告。

所以这套系统里最值得投资的不是最后那个“写周报”的 prompt，而是中间的结构化信号层。

一句话说：

先把非结构化对话变成可计算的信号，再让模型负责叙事。

这不只适用于周报

周报只是一个例子。

任何“让模型消化海量自有数据，再产出一份报告”的需求，都可以用这套范式重新看一遍：

• 客户成功团队想从大量沟通里提取客户风险。
• 运营想从社群聊天里提取热点和反馈。
• 产品想从用户访谈里提取需求和阻塞。
• 团队想从工程讨论里生成月度复盘。
• 个人想从自己的 AI 对话里提炼长期学习轨迹。

这些问题表面上都是“总结”，底层其实都是“信号抽取 + 聚合 + 叙事”。

下次遇到类似需求，我不会先问“prompt 怎么写”。我会先问四件事：

原始数据怎么切？
信号字段怎么定义？
facets 怎么落库和溯源？
最后叙事读的是全文，还是结构化骨架？

只要这个问题没想清楚，把全部聊天记录直接塞进大模型，迟早会变成一个又贵、又慢、又不好调试的系统。