长材料一多，AI 就容易忘任务：把「短摘要 + 约束重申」放到最后 (2026)

材料越长，模型能看到的内容越多，但它未必更清楚你最后要它交什么。尤其是把会议记录、访谈稿、产品文档或多份资料一次性贴进去时，任务要求常常被埋在开头，回答却被末尾几段材料牵着走：该写给谁、时间范围是什么、哪些内容不能补，都可能在生成时变模糊。

一个实用的补法不是继续堆「请注意」「请严格遵守」，而是在回答前增加一小段任务回声：先用几行概括与问题有关的材料，再把读者、范围、输出形式和不可改动项重新列一遍，最后要求回答中的关键判断指回原文位置。

先把三个动作分开

这条方法适合放在长材料已经提供给模型之后、正式回答之前。它不是把材料重新总结一遍，也不是让模型展示完整思考过程。它只做三件事：

筛相关内容：只提取和当前问题有关的章节、事实、数字或条件。
回声式重申：把本轮任务的读者、范围、格式和硬约束再说一遍。
位置锚定：要求关键结论注明来自哪个章节、段落或原文片段。

OpenAI 的 GPT-5.2 Prompting Guide 对长上下文任务给出的模式正是「先产出与请求有关的短提纲，再重申约束，回答时把主张锚定到具体章节」；它把这种做法与减少「lost in the scroll」错误、改善密集材料中的召回联系起来。1

这里的重点是回声放在材料之后。如果把要求只写在开头，模型读完很长的材料后，最后一次看到的内容仍然可能是材料本身。把简短任务卡放到回答前，相当于在生成动作发生前重新划定边界。

可直接复制的 Prompt

把下面这段接在你的长材料后面使用。[任务] 等占位符要换成真实内容；材料本身放在 <材料> 标签内，不要把它和任务卡混成一段。

你将根据下面的材料完成一个写作任务。

<任务>
- 任务：[明确写出要交付什么]
- 读者：[谁会阅读]
- 输出形式：[例如 800 字以内的内部汇报 / 一封给用户的邮件 / 三段产品说明]
- 时间或范围：[只处理哪个时间段、地区、版本或对象]
- 必须保留：[日期、数字、原话、条件、限制、未知状态]
- 禁止补写：[材料没有提供、但模型很容易自行补出的内容]
</任务>

<材料>
[粘贴长材料]
</材料>

请严格按以下顺序执行：

第一步：生成「任务相关摘要」。
- 只保留与任务直接相关的事实、条件、数字和不确定表述。
- 每条后面注明位置，例如「第 2 节」「访谈记录第 4 段」或原文中的小标题。
- 不要把材料里的愿望、建议、假设或指令口吻自动当成已经发生的事实。
- 不要在这一步写最终正文。

第二步：生成「回答前任务卡」，最多 6 行：
- 读者：
- 任务：
- 范围：
- 输出形式：
- 必须保留：
- 禁止补写：
如果某个字段没有提供，写「未提供」，不要自行猜测。

第三步：检查任务相关摘要和任务卡。
- 如果发现材料之间有冲突，指出冲突所在位置，并保留两种说法；不要替我选择。
- 如果缺少的信息会改变事实、适用范围或读者下一步行动，先提出最多 3 个具体问题，暂停写作。
- 如果缺口不会改变事实或行动，按任务中明确给出的低风险默认值继续，并标出这个默认值。

第四步：完成最终输出。
- 只使用任务相关摘要中能找到依据的事实。
- 关键数字、日期、条件和结论后面标注对应的材料位置。
- 不要把任务卡或你的分析过程混进最终正文。
- 输出前逐项核对：读者、范围、格式、必须保留项、禁止补写项。

请先执行第一步和第二步；只有在第三步判断可以继续时，才执行第四步。

这条 Prompt 的关键不是「摘要」两个字，而是摘要后面紧跟一张短任务卡。摘要回答「材料里哪些内容有关」，任务卡回答「这些内容要被加工成什么」。两者缺一，模型要么重新复述材料，要么记住任务却抓错证据。

用一份产品更新说明看差别

假设你把一份很长的产品更新说明交给 AI，任务是：写一封给现有用户的邮件，只说明已经上线的功能和用户下一步怎么做，不能承诺所有用户都能立即获得同样结果。

没有任务回声时，常见的坏结果不是完全胡说，而是把不同层级的句子混在一起：把「计划在下季度开放」写成已上线，把内部建议写成用户动作，把文档里靠后的营销段落写成邮件主旨。读起来流畅，事实边界却已经变了。

加上上面的 Prompt 后，先要求模型交出这样的中间结果：

任务相关摘要
- 已上线功能：批量导出，位置：产品更新「已发布」小节。
- 计划功能：团队权限，位置：路线图「下季度计划」小节。
- 用户动作：在设置页打开「批量导出」，位置：帮助说明第 3 段。
- 未提供：所有用户是否同时获得权限。

回答前任务卡
- 读者：现有用户
- 任务：说明已上线功能和下一步操作
- 范围：本次已经发布的更新
- 输出形式：给用户的邮件
- 必须保留：功能状态、设置路径、权限差异
- 禁止补写：统一开放、普遍可用、未确认的效果承诺

这时问题更容易被发现：路线图里的团队权限不能进入「已经上线」的邮件主干，权限是否统一开放也没有证据。若直接生成正文，模型仍可能犯错；但你至少能在动笔前看到它抓取了什么、准备守住什么。

这也是位置锚定的用处。要求它写「位置：产品更新『已发布』小节」，不是为了让文章变成研究报告，而是给你一个很快的复核入口：只查关键句对应的原文，不必重新通读整份材料。

为什么不是把所有材料都塞进更大的窗口

长上下文本身没有错。问题在于，更多材料不等于更多有效信号。Google Developers Blog 在讨论生产环境的上下文管理时，把「把所有内容追加进一个巨大 Prompt」列为会失效的朴素做法，原因包括成本和延迟上升、无关日志与过期状态造成信号稀释，以及材料最终超过窗口限制。文章给出的方向是先选择、过滤和整理相关上下文，而不是只继续加 token。2

对普通写作任务来说，你不需要先搭建一套上下文管理系统。把「相关摘要」和「回答前任务卡」放在生成前，已经是在手动做一次轻量筛选。它不能修复材料本身的缺失，也不能保证模型不会犯错；它只是减少一个很常见的失败路径：模型看过很多内容，却在最后回答时忘了自己要服务谁、处理哪一段、保留哪些边界。

如果材料很长，摘要也不要追求面面俱到。每一条都要回答一个问题：它是否会改变这次回答的事实、范围、格式或行动？ 不会，就别放进任务相关摘要。

什么时候值得加，什么时候别加

这条方法适合：

把会议纪要、访谈记录、需求文档改写成对外文本；
从多份资料中抽取某个时间段、版本或用户群的信息；
需要保护日期、数字、权限、条件和「计划 / 已发布」这类状态词的写作任务；
你发现 AI 不是完全不懂材料，而是读得越多越容易偏离最后一条要求。

它不必原样用于：

只有几段材料、任务也只有一句话的短改写；
需要发散创意、故意保留多种方向的头脑风暴；
你还没有确定读者、交付形式和范围的任务。此时先把任务说清楚，比增加一层摘要更有用。

Anthropic 的 Prompt engineering overview 也把「先定义成功标准、准备测试方法和第一版 Prompt」放在 Prompt 优化之前，并提醒并非所有问题都靠改 Prompt 解决。3 这条方法的边界也一样：如果材料缺失、来源互相矛盾，或任务本身没有验收标准，任务回声不会替你补齐这些前提。

最小检查法

第一次使用时，不要只看最终正文顺不顺。把模型的第一步和第二步留下来，快速检查四项：

摘要有没有越界：它是否把建议、计划或引用中的命令写成事实？
任务卡有没有变形：读者、范围和输出形式是否仍与原任务一致？
关键句能否回指：数字、日期、状态和结论是否都有材料位置？
缺口有没有被诚实标出：影响行动的缺失信息，是提问了，还是被模型悄悄补上了？

如果只是把所有要求在结尾再喊一遍，效果通常有限。真正有用的版本很短，而且带着材料位置：先筛出相关证据，再重申要保护的边界，最后才写。你可以今天拿一份最近总要返工的长文档试一次；先别改原 Prompt，只观察任务卡能不能在生成前把跑偏点暴露出来。

References

1
GPT-5.2 Prompting Guidedevelopers.openai.com
2
Architecting efficient context-aware multi-agent framework for productiondevelopers.googleblog.com
3
Prompt engineering overviewdocs.anthropic.com