这次我们来看一个关于大语言模型（LLM）使用技巧的讨论。核心议题是：当我们在与 ChatGPT、Claude、Gemini 等模型进行长对话时，模型的表现是否会随着上下文长度的增加而“退化”？以及如何通过一个简单的“工作摘要”技巧来缓解这个问题。

这个话题源于宾夕法尼亚大学沃顿商学院教授 Ethan Mollick 的观察和建议。对于经常使用 AI 进行长文档分析、多轮复杂对话、代码调试或学术研究的用户来说，这直接关系到最终输出的质量和效率。本文不涉及复杂的模型微调或部署，而是聚焦于一个可立即上手的实用策略：在长对话中，主动要求模型压缩并总结当前的工作摘要（Working Summary）。

我们将拆解这个现象背后的可能原因，并通过具体的操作步骤，演示如何在日常使用中应用这一技巧，以保持甚至提升 AI 在长上下文任务中的表现。无论你是开发者、研究者还是内容创作者，只要你的对话轮次经常超过几十轮，或者处理的文本上下文很长，这篇文章都值得你仔细阅读并实践。

1. 核心能力速览：理解“对话退化”与“工作摘要”

在深入操作之前，我们先通过一个表格快速把握核心概念和 Ethan Mollick 建议的价值所在。

2. 适用场景与使用边界

这个技巧的价值在于其普适性和即时性，但它并非万能药。理解其适用边界能帮助你更有效地运用它。

最适合谁用？

• 深度AI协作者：那些不满足于单次问答，而是将AI作为“思考伙伴”，进行长达数十甚至上百轮对话的用户。
• 复杂项目管理者：利用AI进行项目规划、任务分解、文档起草和修订，过程中涉及大量细节和反复调整。
• 研究与创作者：进行文献综述、理论推导、故事创作、剧本编写等需要保持长期逻辑一致性的工作。
• 开发者与工程师：与AI结对编程，调试复杂代码，设计系统架构，需要AI记住大量的技术上下文和既定决策。

能解决什么问题？

1. 指令遗忘：AI忘记了对话早期设定的核心规则或目标。
2. 上下文稀释：关键信息被淹没在海量的中间对话中，导致AI的回应变得泛泛而谈或偏离主题。
3. 性能波动：在长对话的后半段，AI的推理深度、创造性和准确性出现可感知的下降。
4. 协作效率低下：用户需要不断重复之前已讨论过的内容，以“唤醒”AI的记忆。

不适合什么场景？

• 简短问答：只有寥寥数轮的简单信息查询或翻译，无需此技巧。
• 单次文档处理：虽然输入文档很长，但只需AI执行一次总结、改写或问答任务，之后便结束对话。
• 追求极限上下文：如果你的唯一目标是测试模型能“吞下”多长的文本，而不关心多轮交互质量，此技巧无助于扩展上下文窗口本身。

使用边界与注意事项

• 非官方解决方案：这是基于社区观察和经验总结的提示工程技巧，并非OpenAI、Anthropic等厂商的官方功能。其效果可能因模型版本、具体任务和随机性而异。
• 无法根治根本限制：它旨在优化现有上下文窗口内的信息组织，但不能突破模型固有的上下文长度限制（如128K、200K）。如果任务本身所需的信息量远超窗口，仍需借助RAG（检索增强生成）等其他技术。
• 依赖用户主动性：需要用户在对话过程中有意识地插入摘要生成指令，对使用者的对话管理和节奏把控有一定要求。
• 摘要质量是关键：生成的“工作摘要”本身必须准确、精炼。如果摘要歪曲了原意，反而会将后续对话引入歧途。因此，生成后需人工复核。

3. 环境准备与前置条件

应用此技巧无需复杂的环境配置，但确保一个良好的基础对话环境能让效果更佳。

1. AI 平台/工具选择：

   • 主流云服务：OpenAI ChatGPT (Plus)， Anthropic Claude (Pro)， Google Gemini Advanced， 国内如 Kimi、DeepSeek、通义千问等支持长上下文的模型。
   • 关键要求：所选模型需支持足够长的上下文窗口（通常 > 32K tokens），并且允许进行多轮、持续的对话。

2. 对话策略准备：

   • 明确对话目标：在开始长对话前，尽可能清晰地向AI说明最终要达成的目标。例如：“我们将共同撰写一篇关于‘可持续能源政策’的报告大纲，并逐步细化各部分内容。”
   • 结构化你的请求：将复杂任务分解为阶段性子任务，并在每个阶段自然引入“工作摘要”环节。

3. 心理预期管理：

   • 理解“对话退化”可能是一种概率性现象，并非每次长对话都会发生。本技巧是一种“预防性”和“优化性”措施。
   • 准备好对AI生成的“工作摘要”进行审阅和微调，确保其准确性。

4. “工作摘要”技巧的操作流程

下面我们通过一个模拟的“撰写技术博客”的长对话场景，来分步演示如何应用这一技巧。

场景设定：我们要求AI协助完成一篇题为《基于Python的实时数据管道设计》的技术博客，从构思大纲到完成初稿。

4.1 第一轮：设定目标与初步构思

首先，我们给出清晰的初始指令。

用户：我们将合作撰写一篇技术博客，主题是“基于Python的实时数据管道设计”。目标是面向中级开发者，讲解使用Apache Kafka和FastAPI构建管道的关键步骤、常见陷阱和最佳实践。请先为这篇博客构思一个详细的目录大纲，要求结构清晰，涵盖从理论到实战的完整闭环。

AI会生成一个目录大纲。假设我们经过几轮讨论，对大纲进行了修改和确认，确定了最终包含“引言”、“核心组件选型”、“Kafka生产者/消费者实现”、“FastAPI实时接口”、“错误处理与监控”、“部署考量”等章节。

4.2 引入“工作摘要”的时机

在确认大纲，并即将开始深入撰写第一个章节“核心组件选型”时，这是引入第一个“工作摘要”的理想时机。因为我们已经完成了“规划阶段”，即将进入“执行阶段”。

操作指令： 在对话框中，输入类似以下的提示词：

用户：好的，大纲已经确定，非常清晰。在我们开始深入撰写“核心组件选型”这一部分之前，为了确保我们后续的协作始终聚焦在正确的轨道上，请你基于到目前为止的全部对话内容，生成一份简短的“工作摘要”。 这份摘要需要浓缩： 1. 本次协作的终极目标（一篇什么样的技术博客）。 2. 当前已达成共识的博客核心结构（目录）。 3. 我们接下来要立即执行的具体任务（撰写“核心组件选型”章节）。 4. 任何需要特别注意的约束条件（如面向中级开发者、强调实战）。 请将摘要控制在200字以内，力求精准。

4.3 解析AI生成的摘要

AI可能会返回如下内容：

AI：**【工作摘要】** **终极目标**：合作撰写一篇面向中级开发者的技术博客，主题为《基于Python的实时数据管道设计》，重点讲解使用Apache Kafka和FastAPI的实战方案。 **已达成共识**：博客目录已确定，包含引言、核心组件选型、Kafka实现、FastAPI接口、错误处理与监控、部署考量等六大核心章节。 **下一步任务**：立即开始撰写第二章“核心组件选型”，需详细对比并选择Python生态中适用于实时管道的Kafka客户端、序列化库、连接管理工具等，并给出选型理由。 **关键约束**：内容需兼顾易懂性与实战性，避免过于理论化，代码示例需完整可运行。

你的行动：快速浏览这份摘要。检查它是否准确反映了对话历史。如果有细微偏差，你可以直接指出并修正。例如：“摘要基本正确，但在‘关键约束’里补充一点：需要提及云原生环境下的替代方案。” 这个修正过程本身也是对上下文的一次强力对齐。

4.4 利用摘要推进对话

现在，你可以直接基于这份摘要，开始下一阶段的工作。指令可以非常简洁，因为上下文已被“摘要”刷新和锚定。

用户：很好，摘要准确。现在，请开始撰写“核心组件选型”章节。首先，请列出Python中主流的Kafka客户端库（如confluent-kafka-python, kafka-python），并从性能、易用性、社区活跃度等方面做一个对比表格。

AI的回应将会更有可能紧扣“选型”这个主题，并且记得“对比表格”和“实战性”的要求，因为它刚刚被“工作摘要”强化了这些核心信息。

4.5 周期性重复摘要流程

在完成“核心组件选型”章节，并准备进入“Kafka生产者实现”时，可以再次触发摘要流程。此时的提示词可以更简短，引用之前的摘要作为上下文的一部分。

用户：第二章“核心组件选型”的初稿已完成。现在，请基于最新的对话（包括已完成的章节内容），更新我们的“工作摘要”。然后，我们将进入第三章“Kafka生产者实现”的撰写。

AI会生成一份更新的摘要，其中会包含新完成的“核心组件选型”章节的核心结论。这个迭代过程，就像在漫长的航行中不断校准航向。

5. 功能测试与效果验证：如何评估技巧是否生效？

由于“对话退化”并非一个可精确量化的错误，而是一种质量感知，因此我们的测试更侧重于对比和主观评估。

5.1 对比测试设计

为了直观感受“工作摘要”技巧的效果，你可以设计一个简单的A/B测试：

1. 测试A（无摘要组）：

   • 开启一个新对话线程。
   • 直接进行一个长达30-40轮的多步骤复杂任务（例如，设计一个系统，并逐步讨论其API、数据库、前端界面）。
   • 在对话中途（第15-20轮）和结尾，故意问一些与最初目标相关，但信息分布在早期对话中的问题。例如：“回顾一下，我们最初设定的系统核心设计原则是什么？”
   • 记录AI回答的准确性和相关性。

2. 测试B（有摘要组）：

   • 开启另一个新对话线程。
   • 执行相同的复杂任务。
   • 在任务的关键阶段转换点（例如，完成需求分析后、开始设计前；完成设计后、开始实现前），插入“生成工作摘要”的指令。
   • 在同样的中途和结尾节点，提出相同的回顾性问题。
   • 记录AI的回答。

5.2 评估维度

对比两组对话中AI的表现，可以从以下维度评估：

• 一致性：AI的后期回答是否与早期设定的目标、约束保持一致？
• 记忆力：AI是否能准确引用早期对话中确定的细节（如某个技术选型理由、某个已否决的方案）？
• 深度与专注度：在对话后期，AI的回复是否依然具体、深入，还是变得笼统、敷衍？
• 用户心智负担：你是否需要频繁地翻看前文或重复解释，来纠正AI的“遗忘”？

5.3 判断成功的标准

如果“有摘要组”在以上一个或多个维度上，显著且稳定地优于“无摘要组”，那么就可以认为“工作摘要”技巧在你的使用场景和所选模型上是有效的。

常见“失败”原因分析：

• 摘要指令不清晰：你的提示词没有明确要求摘要应包含哪些要素，导致AI生成的摘要过于空泛，未能有效锚定关键信息。
• 摘要时机不当：在信息量尚未积累到需要“重置”的时候就生成摘要，或者间隔太久，退化已经发生。
• 任务本身过于跳跃：如果对话主题频繁、无规律地切换，即使有摘要，也可能难以跟上节奏。这时需要更频繁地生成摘要，或主动管理对话主线。
• 模型固有局限性：对于某些超长或极度复杂的上下文，该技巧可能只能缓解，而不能完全消除退化现象。

6. 高级技巧与批量任务模拟

虽然“工作摘要”本身是交互式的，但其思想可以衍生出一些半自动化的使用模式，特别是在处理一系列相关联的独立任务时。

6.1 为系列对话创建“主摘要”

假设你需要就一个大型项目的不同模块（如用户模块、订单模块、支付模块）分别与AI进行深入对话。你可以这样做：

1. 首先，在一个独立的“主规划”对话中，与AI确定项目的整体架构、技术栈、统一规范等。
2. 在结束“主规划”对话前，生成一份最终的、权威的“项目主摘要”。
3. 当你开启关于“用户模块”的新对话时，第一件事就是将这份“项目主摘要”粘贴进去，并说：“这是我们的项目基础设定，请基于此，开始讨论用户模块的数据库设计。”
4. 在“用户模块”对话中，依然可以使用周期性的“工作摘要”来保持聚焦。
5. 处理“订单模块”时，重复步骤3。

这种方法模拟了“批量”处理相关子任务时，如何通过一个共享的“上下文种子”来保证所有子任务对齐到同一基准。

6.2 利用“摘要”作为API调用的上下文（概念模拟）

在通过API调用大模型时，我们通常会受到上下文token数的严格限制。虽然无法直接模拟多轮对话，但“工作摘要”的思想可以应用：

• 在每次API请求的messages列表中，除了最新的用户查询（user）和系统指令（system），你可以精心维护一个assistant角色的消息，其内容就是不断更新的“工作摘要”。
• 这个摘要消息需要你在客户端逻辑中，根据历史交互的核心结果，手动或通过一个简单的总结模型来生成和更新。
• 这样，每次API调用时，模型都能从这个高度浓缩的“摘要”中获取最关键的上下文，而不是依赖完整的、可能已超长的历史记录。

# 概念性代码示例，展示如何将“摘要”融入API调用上下文 import openai # 假设这是你维护的、不断更新的工作摘要 current_working_summary = """ 项目：客户数据分析仪表盘。 已达成：确定使用Streamlit框架，数据源为Snowflake，核心KPI包括DAU、留存率、转化漏斗。 进行中：正在设计‘用户留存’页面的具体可视化图表（趋势图、 cohort 表）。 待决定：颜色主题和图表库（Plotly vs Altair）。 """ # 构造API请求的消息列表 messages = [ {"role": "system", "content": "你是一个数据分析助手，帮助设计可视化仪表盘。"}, {"role": "assistant", "content": current_working_summary}, # 关键：注入工作摘要 {"role": "user", "content": "基于我们当前的进度，为‘用户留存’页面推荐一个具体的Plotly图表类型，并给出选择理由。"} ] # 发送请求（此处为示例，需填写真实API密钥和端点） # response = openai.ChatCompletion.create(model="gpt-4", messages=messages)

7. 资源占用与性能观察

由于本技巧完全运行在提示词层面，不涉及本地计算，因此不存在传统意义上的GPU显存或CPU占用问题。其“性能”主要体现在两个方面：

1. Token 消耗：

   • 成本：生成“工作摘要”本身需要消耗额外的输入和输出tokens。对于按token计费的API服务（如OpenAI），这会增加单次对话的成本。
   • 收益评估：需要权衡这部分额外成本与因对话质量提升、减少重复解释和错误返工所带来的总体效率收益。对于商业或重要项目，这点成本通常是值得的。

2. 注意力资源优化：

   • 这是本技巧的核心“性能”收益。它将模型有限的注意力资源，从可能已冗余或杂乱的超长上下文中，重新引导至由“工作摘要”所定义的、高信息密度的核心上下文中。
   • 类比：就像清理电脑的内存，关掉不必要的后台程序，让当前正在运行的主要软件更流畅。

8. 常见问题与排查方法

9. 最佳实践与使用建议

为了最大化“工作摘要”技巧的效益，遵循以下最佳实践：

1. 首次使用，从小处着手：不要一开始就在最重要的项目上使用。找一个中等复杂度的任务（如规划一次旅行、学习一个新概念）进行练习，熟悉生成和利用摘要的节奏。
2. 摘要模板化：为你最常处理的几类任务（如写作、编程、研究）创建固定的摘要提示词模板，保存在记事本中，需要时快速调用。例如：

   请生成当前对话的工作摘要，需包含： - 核心目标：[此处AI自动总结] - 已完成的里程碑：[此处AI自动总结] - 当前面临的决策或问题：[此处AI自动总结] - 接下来的具体行动步骤：[此处AI自动总结] 摘要请控制在150字以内。

3. 摘要所有权在你：始终记住，你是对话的引导者和最终决策者。AI生成的摘要是一个辅助工具，你必须对其内容负责，进行必要的审核和修正。
4. 与“系统指令”结合使用：许多AI平台允许设置永久的“系统指令”（System Prompt）。你可以将项目最核心、最不变的要求（如写作风格、代码规范）放在系统指令中，而将动态的、阶段性的上下文通过“工作摘要”来管理。
5. 管理对话分支：对于极其复杂的项目，考虑开启多个对话线程，分别处理不同的子任务。每个线程都有自己的“工作摘要”，并在需要时互相引用。这比在一个线程中塞入所有内容更清晰。
6. 合规与隐私：摘要中可能会浓缩大量项目细节。如果对话内容涉及敏感信息、未公开数据或个人隐私，请注意不要在公开场合分享这些摘要内容。对于企业级应用，应考虑相关的数据安全政策。

10. 总结

Ethan Mollick 提出的“压缩工作摘要”技巧，本质上是一种高级的对话管理艺术。它不增加任何技术门槛，却能显著提升我们与大型语言模型进行深度、长程协作的体验和产出质量。

这个技巧最值得尝试的点在于它的即时性和低成本。你不需要等待模型更新，不需要学习新的工具，只需要在下一轮对话中，有意识地插入那条简单的指令。它迫使你和AI一起进行阶段性的“复盘”和“对齐”，将散乱的思维线索收拢，确保巨轮在漫长的航行中不偏离主航道。

最容易踩的坑是过度依赖或错误使用。记住，摘要不是银弹，它不能替代清晰的初始指令，也不能弥补任务本身定义的模糊。它最佳的使用场景是结构化的创造性工作，比如写作、设计、编程和复杂问题解决。

下一步，你可以将这一技巧与你常用的AI工作流相结合。无论是用于学术研究、商业分析还是创意开发，定期生成“工作摘要”都能成为一个强大的质量控制和效率提升的杠杆。建议收藏本文提及的提示词模板和排查清单，在下次进行长对话时，立刻实践一下，亲身感受它带来的不同。