【AI】提示词技巧：让大模型“总结”长文本时保留关键信息的方法

最新推荐文章于 2025-11-16 08:42:45 发布

原创最新推荐文章于 2025-11-16 08:42:45 发布 · 1.1k 阅读

20 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #AI #大模型 #提示词

前沿应用专栏收录该内容

243 篇文章

订阅专栏

提示词技巧：让大模型 “总结” 长文本时保留关键信息的方法

1. 前言

在日常工作和学习中，我们经常需要用大模型总结长文本，比如总结一篇万字的行业报告、一份几十页的会议纪要、一本厚书的核心观点。但很多时候，大模型给出的总结会丢失关键信息 —— 可能漏了报告里重要的数据支撑，可能少了会议纪要中明确的任务分工，也可能忽略了书中核心的理论框架。

这种情况的出现，不是大模型能力不足，而是我们的提示词没有明确 “要保留哪些关键信息”“如何组织总结内容”。想要让大模型精准总结长文本并保留关键信息，关键在于设计有针对性的提示词。本文会从 “关键信息的类型定义” 入手，逐步讲解提示词的基础设计方法、进阶优化策略、不同场景的实战案例，以及常见问题的解决方案，帮助大家彻底解决 “总结丢关键信息” 的痛点。

2. 先明确：长文本中的 “关键信息” 有哪些类型？

在设计提示词之前，我们需要先清楚长文本中常见的关键信息类型。不同类型的文本（如报告、会议纪要、书籍、新闻），关键信息的侧重点不同。只有明确了要保留的信息类型，才能在提示词中精准指令，避免大模型遗漏。

2.1 数据类关键信息

这类信息是文本中支撑观点、体现结果的核心数据，常见于行业报告、研究论文、业务复盘文档中，主要包括：

具体数值：如 “2024 年行业市场规模达到 5000 亿元”“产品用户留存率提升了 15%”“研究样本量为 2000 人”；

对比数据：如 “同比增长 20%”“环比下降 5%”“A 产品销量是 B 产品的 3 倍”；

分类数据：如 “按年龄段划分，18-25 岁用户占比 30%，26-35 岁用户占比 50%”“成本结构中，原材料占比 60%，人工占比 20%”。

数据类信息是文本的 “量化支撑”，丢失后会让总结失去说服力。比如总结行业报告时，漏了 “市场规模” 和 “增长率”，就无法让读者了解行业的发展现状。

2.2 结构类关键信息

这类信息是文本的 “框架骨架”，决定了内容的逻辑层次，常见于会议纪要、项目计划、书籍章节中，主要包括：

时间节点：如 “项目启动时间为 2024 年 6 月，上线时间为 2024 年 12 月”“会议确定 3 月 10 日前完成需求调研，3 月 20 日前输出方案”；

任务分工：如 “张三负责需求文档撰写，李四负责原型设计，王五负责技术评估”“市场部负责推广，运营部负责用户运营，技术部负责功能开发”；

章节逻辑：如 “书籍分为 3 个部分，第一部分讲理论基础，第二部分讲实践方法，第三部分讲案例分析”“报告先分析行业现状，再指出问题，最后给出解决方案”。

结构类信息是文本的 “逻辑线索”，丢失后会让总结变得混乱。比如总结会议纪要时，漏了 “任务分工” 和 “时间节点”，读者就不知道谁要做什么、什么时候完成。

2.3 观点类关键信息

这类信息是文本的 “核心思想”，体现作者或发言者的核心主张，常见于评论文章、书籍序言、演讲文稿中，主要包括：

核心论点：如 “作者认为‘用户体验是产品成功的关键’”“演讲提出‘企业数字化转型要以数据为核心’”；

论证逻辑：如 “支持‘用户体验重要’的理由有两点：一是提升用户留存，二是增强品牌口碑”“观点‘数字化转型要以数据为核心’通过三个案例证明：A 企业通过数据优化流程，B 企业通过数据精准营销，C 企业通过数据驱动创新”；

反驳或补充：如 “针对‘价格战能提升市场份额’的观点，作者反驳‘短期有效，但长期会损害品牌利润’”“报告在‘解决方案’部分补充‘需注意成本控制，避免过度投入’”。

观点类信息是文本的 “价值核心”，丢失后会让总结失去灵魂。比如总结评论文章时，漏了 “核心论点” 和 “论证理由”，读者就无法了解文章的核心主张。

2.4 特殊类关键信息

这类信息是文本的 “特殊重点”，根据文本类型有不同的体现，常见于合同条款、产品说明、故障排查文档中，主要包括：

约束条件：如 “合同约定‘付款方式为月结，逾期违约金为 0.5%/ 天’”“产品使用条件为‘温度 0-40℃，湿度≤80%’”；

注意事项：如 “故障排查时需注意‘先断电再操作，避免触电’”“使用该方法时需注意‘数据需提前备份，防止丢失’”；

异常情况：如 “报告指出‘行业存在两个异常现象：一是中小企业倒闭率上升，二是头部企业市场份额集中’”“项目计划提到‘若需求变更，需重新评估时间和成本’”。

特殊类信息是文本的 “风险提示” 或 “特殊要求”，丢失后可能导致误解或失误。比如总结合同条款时，漏了 “逾期违约金”，就可能让使用者忽略违约的后果。

3. 基础方法：3 步设计 “保留关键信息” 的提示词

掌握了关键信息的类型后，我们可以通过 “明确文本类型→指定保留信息→设定输出格式” 三步，设计基础的提示词，让大模型总结时不丢失关键信息。这是最通用、最易上手的方法，适合所有类型的长文本总结。

3.1 第一步：明确文本类型和核心目标

在提示词开头，先告诉大模型 “要总结的文本是什么类型” 以及 “总结的核心目标”，让大模型建立初步的认知。比如 “要总结的是行业报告，核心目标是让读者快速了解行业现状和未来趋势”“要总结的是会议纪要，核心目标是让参与者明确任务和时间节点”。

明确文本类型能让大模型匹配对应的关键信息侧重点 —— 比如总结行业报告，会自动关注 “数据类信息”；总结会议纪要，会自动关注 “结构类信息”。明确核心目标能让大模型聚焦重点，避免无关信息干扰。

示例：“我需要你总结一份‘2024 年中国新能源汽车行业报告’（文本类型），总结的核心目标是让读者快速了解行业的市场规模、增长率、主要企业份额，以及未来 3 年的发展趋势（核心目标）。”

3.2 第二步：指定必须保留的关键信息

这是最关键的一步，需要根据文本类型，明确列出 “必须保留的关键信息类型”，甚至具体到 “某类信息中的具体内容”。比如总结行业报告时，指定 “必须保留数据类信息：市场规模、同比增长率、TOP3 企业的市场份额；必须保留观点类信息：报告对未来 3 年的趋势预测，以及支撑预测的核心理由”。

指定信息时要 “具体、无歧义”，避免用 “重要信息”“关键内容” 这类模糊的表述。比如不说 “保留重要数据”，而说 “保留‘用户数’‘收入’‘利润率’这三个核心数据”。

示例（承接 3.1 的行业报告）：“总结时必须保留以下关键信息：

数据类信息：2024 年新能源汽车行业的整体市场规模（单位：亿元）、同比 2023 年的增长率；TOP3 企业（比亚迪、特斯拉、蔚来）的市场份额占比；

观点类信息：报告对 2025-2027 年行业增长率的预测数值；支撑该预测的 3 个核心理由（如政策支持、技术进步、消费需求增长）；

结构类信息：报告分析行业现状时提到的 3 个主要问题（如产能过剩、电池成本高、充电设施不足）。”

3.3 第三步：设定清晰的输出格式

指定输出格式能让大模型的总结更有条理，也能间接提醒大模型 “不要遗漏指定的关键信息”。常见的输出格式有 “分点式”“段落式”“表格式”，可根据核心目标选择：

分点式：适合需要清晰呈现多个关键信息的场景，如总结会议纪要、项目计划，示例：“1. 市场规模：XXX；2. 增长率：XXX；3. 主要问题：XXX”；

段落式：适合需要连贯呈现逻辑的场景，如总结评论文章、书籍章节，示例：“2024 年新能源汽车行业市场规模达到 XXX 亿元，同比增长 XXX%，其中比亚迪占比 XXX%，特斯拉占比 XXX%，蔚来占比 XXX%……”；

表格式：适合需要对比呈现数据的场景，如总结行业报告中的企业份额、分类数据，示例：

关键信息	具体内容
2024 年市场规模	XXX 亿元
同比增长率	XXX%
比亚迪市场份额	XXX%

示例（承接前两步）：“请按以下格式输出总结：

行业现状数据（分点列出，每个数据标注单位）：

1.1 2024 年市场规模：

1.2 同比 2023 年增长率：

1.3 TOP3 企业市场份额：

未来趋势预测（先总述预测结论，再分点说明支撑理由）：

2.1 预测结论：2025-2027 年行业年均增长率为 XXX%；

2.2 支撑理由：

行业主要问题（分点列出 3 个问题，每个问题简要说明）：”

3.4 基础提示词完整示例

将三步结合，形成完整的提示词，示例如下：

“我需要你总结一份‘2024 年中国新能源汽车行业报告’，总结的核心目标是让读者快速了解行业的市场规模、增长率、主要企业份额，以及未来 3 年的发展趋势。

总结时必须保留以下关键信息：

数据类信息：2024 年新能源汽车行业的整体市场规模（单位：亿元）、同比 2023 年的增长率；TOP3 企业（比亚迪、特斯拉、蔚来）的市场份额占比；

观点类信息：报告对 2025-2027 年行业增长率的预测数值；支撑该预测的 3 个核心理由（如政策支持、技术进步、消费需求增长）；

结构类信息：报告分析行业现状时提到的 3 个主要问题（如产能过剩、电池成本高、充电设施不足）。

请按以下格式输出总结：

行业现状数据（分点列出，每个数据标注单位）：

1.1 2024 年市场规模：

1.2 同比 2023 年增长率：

1.3 TOP3 企业市场份额：

未来趋势预测（先总述预测结论，再分点说明支撑理由）：

2.1 预测结论：2025-2027 年行业年均增长率为 XXX%；

2.2 支撑理由：

行业主要问题（分点列出 3 个问题，每个问题简要说明）：”

4. 进阶策略：针对不同文本类型的提示词优化

基础方法能解决 “不丢失关键信息” 的基本需求，但针对不同类型的长文本（如报告、会议纪要、书籍），还需要进一步优化提示词，让总结更贴合场景需求。下面针对 4 类常见文本类型，给出进阶的提示词策略和示例。

4.1 策略一：总结 “行业报告 / 研究论文”—— 聚焦 “数据 + 结论”

行业报告和研究论文的核心是 “数据支撑结论”，总结时最容易丢失 “数据来源” 和 “结论的限定条件”。进阶策略需明确：1. 保留数据的 “来源和时间范围”；2. 保留结论的 “适用场景和限制条件”；3. 区分 “确定结论” 和 “推测结论”。

4.1.1 进阶提示词设计要点

数据部分：指定 “数据来源（如‘国家统计局’‘企业年报’）”“时间范围（如‘2024 年 Q1-Q4’）”“样本量（如‘调研样本 1000 份’）”；

结论部分：指定 “结论的适用场景（如‘该结论仅适用于一线城市’）”“限制条件（如‘该结论基于当前政策不变的前提’）”“结论类型（如‘确定结论：XXX’‘推测结论：XXX’）”；

输出格式：用 “数据 + 结论 + 备注” 的结构，备注说明数据来源和结论限制。

4.1.2 进阶提示词示例

“我需要你总结一份‘2024 年中国在线教育行业研究论文’，核心目标是让读者了解论文的核心数据、研究结论，以及结论的可靠性。

总结时必须保留以下关键信息：

数据类信息：

1.1 调研对象：在线教育用户的年龄段分布（分 3 个年龄段：18 岁以下、18-30 岁、30 岁以上），标注数据来源（如‘教育部调研数据’）和调研时间（如‘2024 年 5-6 月’）；

1.2 核心指标：2024 年在线教育用户付费率（单位：%）、平均客单价（单位：元），标注样本量（如‘有效样本 2000 份’）；

观点类信息：

2.1 确定结论：论文明确的‘在线教育用户最关注的 3 个因素（如课程质量、价格、师资）’，说明每个因素的占比（如‘课程质量占比 40%’）；

2.2 推测结论：论文推测的‘2025 年在线教育行业的 2 个发展方向（如‘AI + 教育’‘职业教育细分’）’，说明推测的依据（如‘基于当前 AI 技术的发展速度’）；

2.3 结论限制：论文提到的‘结论适用限制’（如‘仅适用于 K12 和职业教育领域，不适用于高等教育’）。

请按以下格式输出总结：

核心调研数据（每个数据后括号标注来源、时间或样本量）：

1.1 用户年龄段分布：

1.2 付费率和客单价：

研究结论（区分确定结论和推测结论，结论后括号标注限制条件或依据）：

2.1 确定结论：

2.2 推测结论：”

4.2 策略二：总结 “会议纪要”—— 聚焦 “任务 + 责任 + 时间”

会议纪要的核心是 “明确行动项”，总结时最容易丢失 “任务的具体要求” 和 “逾期处理方式”。进阶策略需明确：1. 保留任务的 “具体内容和交付标准”；2. 保留 “责任人、协作方”；3. 保留 “截止时间和逾期处理方式”。

4.2.1 进阶提示词设计要点

任务部分：指定 “任务的具体内容（如‘撰写需求文档 V1.0’）”“交付标准（如‘包含功能清单、用户流程图、界面原型链接’）”；

责任部分：指定 “主要责任人（如‘张三’）”“协作方（如‘李四提供需求输入，王五提供技术评估’）”；

时间部分：指定 “截止时间（如‘3 月 10 日 18:00 前’）”“逾期处理（如‘逾期需在会议上说明原因，并制定新的交付时间’）”；

输出格式：用表格呈现 “任务 - 责任人 - 协作方 - 截止时间 - 交付标准 - 逾期处理”，清晰直观。

4.2.2 进阶提示词示例

“我需要你总结一份‘产品需求评审会议纪要’，核心目标是让参会者明确会后的任务分工、交付要求和时间节点，避免遗漏行动项。

总结时必须保留以下关键信息：

结构类信息：

1.1 任务列表：会议确定的 3 个核心任务（任务 1：撰写需求文档 V1.0；任务 2：输出技术评估报告；任务 3：组织用户访谈）；

1.2 每个任务的具体信息：

- 责任人：主要负责完成任务的人；

- 协作方：需要配合的人及配合内容；

- 截止时间：具体到年月日时分（如‘3 月 10 日 18:00 前’）；

- 交付标准：任务完成后需要交付的内容及要求（如‘需求文档需包含功能清单、用户流程图、界面原型链接，并发到项目群’）；

- 逾期处理：若未按时交付，需要做什么（如‘需在 3 月 11 日的项目例会上说明原因，并制定新的交付时间’）；

特殊类信息：会议提到的‘任务优先级’（如‘任务 1 优先级最高，需优先完成，再处理任务 2 和任务 3’）；会议提到的 “风险提示”（如‘若需求文档未按时完成，会导致后续开发延期’）。
请按以下格式输出总结：
核心任务分工表（表格需包含 “任务名称、责任人、协作方、截止时间、交付标准、逾期处理” 六列）；
补充说明（分点列出任务优先级和风险提示）：
2.1 任务优先级：

2.2 风险提示：”

4.3 策略三：总结 “书籍 / 长文”—— 聚焦 “框架 + 核心观点”

书籍和长文的核心是 “逻辑框架 + 核心观点”，总结时最容易丢失 “观点之间的关联” 和 “关键案例支撑”。进阶策略需明确：1. 保留 “整体框架（章节逻辑）”；2. 保留 “核心观点及观点间的逻辑关系”；3. 保留 “支撑观点的关键案例（名称、核心内容）”。

4.3.1 进阶提示词设计要点
框架部分：指定 “书籍 / 长文的整体结构（如‘分为 5 章，每章主题’）”“章节间的逻辑关系（如‘第 1 章提出问题，第 2-4 章分析问题，第 5 章解决问题’）”；
观点部分：指定 “每章的核心观点（如‘第 1 章核心观点：XXX’）”“观点间的关联（如‘第 2 章观点是对第 1 章问题的原因分析’）”；
案例部分：指定 “支撑核心观点的关键案例（如‘第 3 章用 “XX 企业案例” 证明观点 XXX，案例核心内容是 XXX’）”；
输出格式：用 “框架→观点→案例” 的层级结构，先呈现整体框架，再分章节拆解观点和案例。
4.3.2 进阶提示词示例

“我需要你总结一本名为《数字化转型：从战略到落地》的书籍，核心目标是让读者了解书籍的整体框架、各章节核心观点，以及支撑观点的关键案例。

总结时必须保留以下关键信息：
结构类信息：
1.1 书籍整体框架：书籍分为 4 章，说明每章的主题（如‘第 1 章：数字化转型的必要性，第 2 章：转型战略制定，第 3 章：落地执行方法，第 4 章：案例分析’）；

1.2 章节逻辑关系：说明章节间的关联（如‘第 1 章提出 “为什么要转型”，第 2 章讲 “转型做什么”，第 3 章讲 “转型怎么做”，第 4 章用案例验证前 3 章的方法’）；
观点类信息：
2.1 每章核心观点：第 1 章的‘数字化转型不是技术升级，而是业务模式重构’；第 2 章的‘转型战略需对齐企业核心目标，避免盲目跟风’；第 3 章的‘落地执行需分 “试点 - 推广 - 优化” 三阶段’；第 4 章的‘成功转型的企业都具备 “高层重视 + 组织协同” 两个特点’；

2.2 观点关联：说明第 2 章战略与第 3 章执行的关联（如‘战略制定时需明确 “试点领域”，为后续执行提供方向’）；
案例类信息：
3.1 关键案例：第 4 章提到的 2 个案例（‘A 传统制造企业转型案例’‘B 互联网企业转型案例’），每个案例需说明‘企业背景、转型措施、转型结果’，以及该案例支撑的观点（如‘A 企业案例支撑第 3 章 “分阶段执行” 的方法’）。

请按以下格式输出总结：
书籍整体框架（先说明章节数量和整体逻辑，再分点列出每章主题）：
1.1 整体逻辑：

1.2 各章主题：
各章节核心观点及关联（分章说明观点，再说明观点间的联系）：
2.1 第 1 章观点：

2.2 第 2 章观点：

2.3 第 3 章观点：

2.4 第 4 章观点：

2.5 观点关联：
关键案例（分点说明每个案例的背景、措施、结果，及支撑的观点）：
3.1 A 传统制造企业案例：

3.2 B 互联网企业案例：”

4.4 策略四：总结 “合同 / 条款类文本”—— 聚焦 “权利 + 义务 + 风险”

合同和条款类文本的核心是 “明确权利义务和风险边界”，总结时最容易丢失 “责任认定” 和 “违约处理”。进阶策略需明确：1. 保留 “双方 / 多方的权利和义务”；2. 保留 “责任认定标准”；3. 保留 “违约情形及处理方式”。

4.4.1 进阶提示词设计要点
权利义务部分：指定 “甲方 / 乙方的核心权利（如‘甲方有权要求乙方按时交付产品’）”“核心义务（如‘乙方有义务保证产品质量符合约定标准’）”；
责任认定部分：指定 “责任划分的标准（如‘因乙方原因导致交付延期，责任归乙方；因甲方需求变更导致延期，责任归甲方’）”；
违约处理部分：指定 “常见违约情形（如‘乙方交付延期、产品质量不达标；甲方未按时付款’）”“每种情形的处理方式（如‘乙方延期 10 天内，按合同金额 0.1%/ 天支付违约金；超过 10 天，甲方有权解除合同’）”；
输出格式：用 “权利义务→责任认定→违约处理” 的结构，分甲方、乙方清晰呈现，避免混淆。
4.4.2 进阶提示词示例

“我需要你总结一份‘软件采购合同’（甲方：采购方企业，乙方：软件供应商），核心目标是让双方明确各自的权利义务、责任划分，以及违约后的处理方式。

总结时必须保留以下关键信息：
特殊类信息（权利义务）：
1.1 甲方权利：要求乙方在合同签订后 30 天内交付软件；要求乙方提供 1 年免费售后服务（含故障维修、版本更新）；若软件质量不达标，有权要求乙方整改；

1.2 甲方义务：在合同签订后 7 天内支付 50% 预付款；向乙方提供软件部署所需的环境信息（如服务器配置）；验收合格后 7 天内支付剩余 50% 款项；

1.3 乙方权利：按合同约定收取预付款和尾款；若甲方未按时提供环境信息导致延期，有权顺延交付时间；

1.4 乙方义务：保证交付的软件符合合同附件中的‘功能清单’；提供 3 次免费操作培训（交付后 1 个月内完成）；售后服务响应时间不超过 24 小时；
特殊类信息（责任认定）：
2.1 交付延期责任：因乙方开发进度滞后导致延期，责任归乙方；因甲方未按时提供环境信息或需求变更导致延期，责任归甲方；

2.2 质量问题责任：若软件功能缺失（不符合功能清单），责任归乙方；若因甲方操作人员误操作导致软件故障，责任归甲方；
特殊类信息（违约处理）：
3.1 甲方违约情形及处理：未按时付款，每逾期 1 天按未付金额 0.5% 支付违约金；无正当理由拒绝验收，超过 15 天视为验收合格，需支付尾款；

3.2 乙方违约情形及处理：交付延期，每逾期 1 天按合同总金额 0.1% 支付违约金；软件质量不达标且整改后仍不符合要求，甲方有权解除合同，乙方需退还已收款项，并支付合同总金额 20% 的违约金。

请按以下格式输出总结：
甲乙双方权利义务（分甲方、乙方，每部分分权利、义务）：
1.1 甲方：

1.1.1 权利：

1.1.2 义务：

1.2 乙方：

1.2.1 权利：

1.2.2 义务：
责任认定标准（分交付延期、质量问题）：
2.1 交付延期责任：

2.2 质量问题责任：
违约处理方式（分甲方违约、乙方违约，每部分分情形、处理方式）：
3.1 甲方违约：

3.2 乙方违约：”

5. 实战案例：不同场景下的完整提示词与输出效果

为了让大家更直观地掌握提示词设计方法，下面提供 3 个不同场景的实战案例，每个案例包含 “文本背景”“完整提示词”“大模型输出示例”“案例分析” 四部分，展示从提示词设计到最终输出的完整过程。

5.1 案例一：总结行业报告 ——2024 年中国短视频行业报告

5.1.1 文本背景

文本类型：行业报告；核心内容：2024 年中国短视频行业的市场规模、用户结构、主要平台份额、未来趋势；关键信息：数据类（市场规模、用户年龄分布、平台份额）、观点类（未来趋势预测及理由）。

5.1.2 完整提示词

“我需要你总结《2024 年中国短视频行业报告》，核心目标是让读者快速了解行业的核心数据和未来发展方向，方便用于业务决策参考。

总结时必须保留以下关键信息：
数据类信息：
1.1 市场规模：2024 年中国短视频行业的整体市场规模（单位：亿元），同比 2023 年的增长率，数据来源（如‘艾瑞咨询’）；

1.2 用户结构：用户年龄分布（18 岁以下、18-25 岁、26-35 岁、35 岁以上四个年龄段的占比），用户性别分布（男性、女性占比）；

1.3 平台份额：TOP3 短视频平台（抖音、快手、视频号）的市场份额占比（按日活跃用户数计算）；
观点类信息：
2.1 未来趋势：报告预测的 2025 年行业 3 个主要趋势（如‘短视频 + 电商融合加深’‘垂类内容（如知识、财经）增长’‘AI 生成内容占比提升’）；

2.2 趋势理由：每个趋势对应的支撑理由（如‘短视频 + 电商趋势的理由：2024 年短视频电商 GMV 同比增长 50%，用户消费习惯养成’）。

请按以下格式输出总结：
2024 年短视频行业核心数据（每个数据后括号标注来源或计算维度）：
1.1 市场规模：

1.2 用户结构：

1.2.1 年龄分布：

1.2.2 性别分布：

1.3 平台份额（按日活跃用户数）：
2025 年行业未来趋势及理由（分点列出趋势，每个趋势后说明理由）：
2.1 趋势一：

2.1.1 趋势内容：

2.1.2 支撑理由：

2.2 趋势二：

2.2.1 趋势内容：

2.2.2 支撑理由：

2.3 趋势三：

2.3.1 趋势内容：

2.3.2 支撑理由：”

5.1.3 大模型输出示例
2024 年短视频行业核心数据（每个数据后括号标注来源或计算维度）：
1.1 市场规模：2024 年中国短视频行业整体市场规模达到 4800 亿元（数据来源：艾瑞咨询），同比 2023 年增长 20%（2023 年市场规模为 4000 亿元）；

1.2 用户结构：

1.2.1 年龄分布：18 岁以下用户占比 15%，18-25 岁用户占比 35%，26-35 岁用户占比 30%，35 岁以上用户占比 20%（数据来源：艾瑞咨询用户调研）；

1.2.2 性别分布：男性用户占比 48%，女性用户占比 52%（数据来源：艾瑞咨询用户调研）；

1.3 平台份额（按日活跃用户数）：抖音占比 55%，快手占比 25%，视频号占比 18%，其他平台合计占比 2%（计算维度：2024 年 12 月日均活跃用户数）；
2025 年行业未来趋势及理由（分点列出趋势，每个趋势后说明理由）：
2.1 趋势一：

2.1.1 趋势内容：短视频 + 电商融合加深，直播带货和短视频种草的转化效率进一步提升；

2.1.2 支撑理由：2024 年短视频电商 GMV 达到 1.8 万亿元，同比增长 50%，超过传统电商平台增速；用户在短视频平台的 “种草 - 下单” 链路逐渐缩短，70% 的用户表示 “看到短视频推荐后会直接购买”（数据来源：艾瑞咨询消费行为调研）；

2.2 趋势二：

2.1.1 趋势内容：垂类内容（尤其是知识类、财经类）用户增长加快，平台开始加大对垂类创作者的扶持；

2.1.2 支撑理由：2024 年知识类短视频用户同比增长 45%，财经类用户同比增长 38%，远超整体用户 15% 的增速；抖音、快手均推出 “垂类创作者补贴计划”，鼓励专业内容生产（数据来源：艾瑞咨询内容生态报告）；

2.3 趋势三：

2.1.1 趋势内容：AI 生成内容（AIGC）在短视频创作中的占比提升，从 “辅助创作” 向 “核心内容生产” 转变；

2.1.2 支撑理由：2024 年已有 30% 的短视频创作者使用 AI 工具生成脚本、剪辑视频；平台推出 “AI 创作助手” 功能，降低创作门槛，预计 2025 年 AI 生成内容的占比将超过 20%（数据来源：艾瑞咨询技术应用报告）。

5.1.4 案例分析

该案例的提示词设计符合 “数据 + 观点” 的行业报告总结需求：
数据类信息明确要求 “标注来源和维度”，避免数据模糊（如平台份额标注 “按日活跃用户数”），大模型输出时完整保留了数据来源和计算依据；
观点类信息要求 “趋势 + 理由”，且理由需结合 2024 年数据，大模型输出的每个趋势都有对应的 GMV 增速、用户增速等数据支撑，符合 “数据支撑观点” 的行业报告特点；
输出格式采用 “分点 + 层级” 结构，数据和趋势分类清晰，读者能快速抓取关键信息，满足 “业务决策参考” 的核心目标。
5.2 案例二：总结会议纪要 —— 项目上线前协调会议

5.2.1 文本背景

文本类型：会议纪要；核心内容：项目上线前的任务分工、时间节点、风险应对；关键信息：结构类（任务、责任人、时间、交付标准）、特殊类（风险提示、应对措施）。

5.2.2 完整提示词

“我需要你总结一份‘项目上线前协调会议纪要’（项目名称：XXAPP V2.0 版本），核心目标是让参会的技术部、运营部、市场部人员明确各自的上线前任务，避免遗漏关键环节。

总结时必须保留以下关键信息：
结构类信息：
1.1 核心任务列表：会议确定的 4 个上线前任务（任务 1：技术部完成最终测试和 Bug 修复；任务 2：运营部完成 APP 内活动配置；任务 3：市场部完成推广文案和渠道准备；任务 4：各部门联合进行上线前演练）；

1.2 每个任务的详细信息：
- 责任人：具体负责部门或个人（如‘技术部 - 李工’）；
- 截止时间：具体到年月日时分（如‘5 月 20 日 18:00 前’）；
- 交付标准：任务完成后需交付的内容（如‘技术部需提交测试报告，确保无高危 Bug’）；
- 协作要求：需要其他部门配合的内容（如‘运营部配置活动时，需技术部提供活动配置接口’）；
特殊类信息：
2.1 上线时间：项目最终上线时间为‘5 月 25 日 00:00’；

2.2 风险提示：会议提到的 2 个主要风险（风险 1：技术测试延期导致上线推迟；风险 2：推广渠道审批未通过）；

2.3 应对措施：每个风险对应的应对措施（如‘风险 1 应对：技术部提前 2 天（5 月 18 日）完成初测，预留 2 天缓冲时间；风险 2 应对：市场部同时准备 3 个备选推广渠道，若主渠道审批未通过，立即启用备选渠道’）。

请按以下格式输出总结：
XXAPP V2.0 上线前核心任务表（表格包含 “任务名称、责任人、截止时间、交付标准、协作要求” 五列）；
关键信息补充（分点列出上线时间、风险提示及应对措施）：
2.1 项目上线时间：

2.2 风险提示及应对措施：

2.2.1 风险 1：
- 风险内容：
- 应对措施：
2.2.2 风险 2：
- 风险内容：
- 应对措施：”
5.2.3 大模型输出示例
XXAPP V2.0 上线前核心任务表
| 任务名称 | 责任人 | 截止时间 | 交付标准 | 协作要求 |

|------------------------------|------------------|-------------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------|

| 技术部完成最终测试和 Bug 修复 | 技术部 - 李工 | 5 月 20 日 18:00 前 | 提交《最终测试报告》，报告需标注 “无高危 Bug”“中低危 Bug≤3 个”，并经产品经理确认 | 需产品部配合提供《测试用例清单》，5 月 15 日前交付给技术部 |

| 运营部完成 APP 内活动配置 | 运营部 - 张姐 | 5 月 22 日 12:00 前 | 完成 “新用户注册领券”“老用户召回返利” 两个活动的配置，配置后需自测 3 次无异常 | 需技术部在 5 月 20 日前提供活动配置接口，接口文档同步至运营部共享文件夹 |

| 市场部完成推广文案和渠道准备 | 市场部 - 王哥 | 5 月 23 日 18:00 前 | 输出 3 版推广文案（适配朋友圈、抖音、小红书），完成主渠道（应用商店）的上架申请 | 需运营部提供活动核心权益（如优惠券金额、返利比例），5 月 21 日前确认文案方向 |

| 各部门联合进行上线前演练 | 技术部 + 运营部 + 市场部 | 5 月 24 日 14:00-16:00 | 演练 “上线前环境检查”“异常突发处理（如服务器卡顿）”“用户反馈响应” 三个场景，输出《演练报告》 | 技术部负责搭建演练环境，运营部准备用户反馈模拟案例，市场部准备推广应急方案 |
关键信息补充
2.1 项目上线时间：5 月 25 日 00:00（北京时间），上线前 1 小时（5 月 24 日 23:00）各部门需安排 1 名人员值班，确保上线顺利；

2.2 风险提示及应对措施：

2.2.1 风险 1：
- 风险内容：技术部最终测试发现高危 Bug，导致测试延期，影响后续运营配置和演练；
- 应对措施：技术部 5 月 18 日 18:00 前完成初测，初测若发现高危 Bug，立即启动 “紧急修复流程”（安排 2 名核心开发人员优先修复）；预留 5 月 19 日 - 20 日两天缓冲时间，确保 5 月 20 日 18:00 前完成最终测试；
2.2.2 风险 2：
- 风险内容：主推广渠道（应用商店）上架审批未通过（如资质材料不全），无法在上线当天同步推广；
- 应对措施：市场部 5 月 20 日前同时准备 3 个备选渠道（朋友圈广告、抖音信息流、行业 KOL 合作），并提前完成备选渠道的资质备案；若 5 月 23 日主渠道审批未通过，当天 18:00 前切换为 “朋友圈广告 + 抖音信息流” 组合推广，确保上线当天有推广曝光。
5.2.4 案例分析

该案例的提示词设计精准匹配会议纪要 “行动导向” 的核心需求：
任务表包含 “协作要求” 列，解决了会议纪要中常见的 “部门配合不明确” 问题，大模型输出时明确了各部门的配合节点（如技术部提供接口的时间），避免后续协作矛盾；
风险提示部分要求 “风险 + 应对措施” 成对呈现，大模型输出的应对措施具体可落地（如 “预留缓冲时间”“准备备选渠道”），而非笼统的 “加强沟通”，满足 “实际执行参考” 的需求；
输出格式用表格呈现任务，用分点呈现补充信息，既清晰又便于参会人员快速查阅（如技术部人员可直接定位自己负责的任务），符合会议纪要 “实用、高效” 的特点。
5.3 案例三：总结合同文本 —— 软件采购合同（甲方：A 企业，乙方：B 科技公司）

5.3.1 文本背景

文本类型：合同文本；核心内容：A 企业向 B 科技公司采购 “客户管理系统（CRM）” 的权利义务、付款方式、交付要求、违约处理；关键信息：特殊类（权利义务、付款节点、交付标准、违约条款）。

5.3.2 完整提示词

“我需要你总结一份‘软件采购合同’（甲方：A 企业，乙方：B 科技公司，采购产品：客户管理系统 CRM V3.0），核心目标是让甲乙双方负责人快速了解合同核心条款，避免后续执行中的争议。

总结时必须保留以下关键信息：
特殊类信息（核心权利义务）：
1.1 甲方权利：要求乙方在合同签订后 45 天内完成 CRM 系统的部署和上线；要求乙方提供 2 年免费售后服务（含系统升级、故障响应）；系统上线后 3 个月内，若发现功能与合同附件《功能清单》不符，有权要求乙方免费修改；

1.2 乙方权利：按合同约定收取货款；若甲方未按时提供系统部署所需的硬件环境（如服务器），有权顺延上线时间；

1.3 甲方义务：合同签订后 10 天内支付 30% 预付款；系统上线验收合格后 15 天内支付 60% 进度款；系统稳定运行 1 年后（验收合格起算）支付 10% 尾款；向乙方提供系统部署所需的硬件环境和客户基础数据（如现有客户名单），并确保数据真实性；

1.4 乙方义务：按《功能清单》开发 CRM 系统，确保系统支持 “客户信息管理、销售流程跟踪、数据报表生成” 三大核心功能；系统上线前提供 3 次操作培训（覆盖甲方 10 名核心用户）；售后服务响应时间不超过 4 小时（工作日 9:00-18:00）；
特殊类信息（交付与验收）：
2.1 交付内容：乙方需交付 “CRM 系统部署包、操作手册（电子版 + 纸质版）、培训视频、《功能测试报告》”；

2.2 验收标准：系统功能 100% 符合《功能清单》；系统并发用户数≥50 人时，响应时间≤2 秒；数据导入准确率≥99%；

2.3 验收流程：乙方完成部署后，甲方需在 7 天内组织验收；验收合格的，签署《验收确认书》；验收不合格的，甲方需书面说明不合格项，乙方在 10 天内整改后重新验收；
特殊类信息（违约处理）：
3.1 甲方违约：未按时付款，每逾期 1 天按未付金额 0.3% 支付违约金；逾期超过 30 天，乙方有权暂停售后服务；

3.2 乙方违约：未按时上线，每逾期 1 天按合同总金额 0.2% 支付违约金；系统功能整改后仍不符合验收标准，甲方有权解除合同，乙方需退还已收款项，并支付合同总金额 15% 的违约金。

请按以下格式输出总结：
甲乙双方核心权利义务（分甲方、乙方，每部分分权利、义务）：
1.1 甲方：

1.1.1 权利：

1.1.2 义务：

1.2 乙方：

1.2.1 权利：

1.2.2 义务：
系统交付与验收条款（分交付内容、验收标准、验收流程）：
2.1 交付内容：

2.2 验收标准：

2.3 验收流程：
违约处理条款（分甲方违约、乙方违约，每部分分违约情形、处理方式）：
3.1 甲方违约：

3.2 乙方违约：”

5.3.3 大模型输出示例
甲乙双方核心权利义务
1.1 甲方：

1.1.1 权利：
- 要求乙方在合同签订后 45 天内完成 CRM 系统（V3.0）的部署和上线；
- 享受 2 年免费售后服务，服务内容包括系统升级、故障响应（工作日 9:00-18:00 响应不超过 4 小时）；
- 系统上线后 3 个月内，若功能与《功能清单》不符，有权要求乙方免费修改；
1.1.2 义务：
- 付款义务：合同签订后 10 天内支付 30% 预付款，系统验收合格后 15 天内支付 60% 进度款，系统稳定运行 1 年后支付 10% 尾款；
- 配合义务：提供系统部署所需的硬件环境（如服务器）和客户基础数据（需确保数据真实），硬件环境需在合同签订后 15 天内准备就绪；
1.2 乙方：

1.2.1 权利：
- 按合同约定收取三笔货款（预付款、进度款、尾款）；
- 若甲方未按时提供硬件环境，有权顺延系统上线时间（顺延天数 = 甲方延迟提供环境的天数）；
1.2.2 义务：
- 开发义务：按《功能清单》开发 CRM 系统，确保支持 “客户信息管理、销售流程跟踪、数据报表生成” 三大核心功能；
- 交付义务：系统上线前提供 3 次操作培训（覆盖甲方 10 名核心用户），培训需包含 “系统操作、常见问题处理” 内容；
- 售后义务：2 年免费售后服务期内，及时响应甲方故障需求，工作日 9:00-18:00 内响应不超过 4 小时，24 小时内提供解决方案。
系统交付与验收条款
2.1 交付内容：乙方需在系统上线当天向甲方交付以下材料：
- 电子版 CRM 系统部署包（含安装程序、数据库脚本）；
- 操作手册（电子版发送至甲方指定邮箱，纸质版 10 份邮寄至甲方办公地址）；
- 培训视频（MP4 格式，包含各功能模块操作演示）；
- 《功能测试报告》（需乙方技术负责人签字确认，证明系统功能符合《功能清单》）；
2.2 验收标准：
- 功能标准：系统所有功能 100% 匹配《功能清单》，无缺失或无效功能；
- 性能标准：并发用户数≥50 人时，系统响应时间≤2 秒，无卡顿或崩溃；
- 数据标准：甲方提供的客户基础数据导入系统后，准确率≥99%（错误数据≤1%）；
2.3 验收流程：
- 乙方完成系统部署后，需书面通知甲方验收（提供《验收申请单》）；
- 甲方收到申请后 7 天内组织验收，验收小组由甲方产品部、销售部各 2 名人员组成；
- 验收合格：甲方签署《验收确认书》，并在签署后 15 天内支付 60% 进度款；
- 验收不合格：甲方需在验收结束后 3 天内书面告知乙方不合格项（如 “数据报表生成功能缺失”），乙方需在 10 天内完成整改，整改后重新提交验收申请，直至验收合格。
违约处理条款
3.1 甲方违约：
- 违约情形 1：未按时支付预付款 / 进度款 / 尾款（如预付款超过 10 天未付）；
- 处理方式 1：每逾期 1 天，按未付金额的 0.3% 支付违约金（如未付 10 万元，每天违约金 300 元）；逾期超过 30 天，乙方有权暂停售后服务，直至甲方付清款项及违约金；
3.2 乙方违约：
- 违约情形 1：未在合同签订后 45 天内完成系统上线（非甲方原因导致）；
- 处理方式 1：每逾期 1 天，按合同总金额的 0.2% 支付违约金（如合同总金额 50 万元，每天违约金 1000 元）；
- 违约情形 2：系统整改后仍不符合验收标准（如两次整改后数据准确率仍＜99%）；
- 处理方式 2：甲方有权解除合同，乙方需在解除合同后 15 天内退还甲方已支付的预付款 / 进度款，并额外支付合同总金额 15% 的违约金（如 50 万元合同，违约金 7.5 万元）。
5.3.4 案例分析

该案例的提示词设计精准抓住合同文本 “权责清晰、风险可控” 的核心需求：
权利义务部分按 “甲方 / 乙方”“权利 / 义务” 分类，大模型输出时补充了 “义务的具体时间节点”（如甲方硬件环境准备时间 “15 天内”），避免合同条款中的 “模糊时间” 导致争议；
验收条款明确 “交付内容、标准、流程” 三要素，大模型输出时细化了验收小组组成（甲方产品部 + 销售部）、不合格项反馈时间（3 天内），让验收流程可执行，而非 “口头约定”；
违约条款要求 “违约情形 + 处理方式”，大模型输出时加入了 “违约金计算示例”（如 50 万元合同每天违约金 1000 元），让双方直观了解违约成本，降低违约概率，完全符合合同总结 “规避风险” 的目标。
6. 避坑指南：避免大模型总结丢失关键信息的 6 个常见错误

在设计提示词时，若忽略一些细节，可能导致大模型总结时仍丢失关键信息。下面总结 6 个常见错误及对应的避免方法，帮助大家避开误区，提升总结质量。

6.1 错误 1：提示词中 “关键信息” 描述模糊，大模型无法识别

6.1.1 常见问题

用 “重要信息”“关键内容”“核心数据” 等模糊表述替代具体的关键信息类型，大模型无法判断 “哪些信息需要保留”。例如，总结行业报告时，提示词写 “保留报告中的重要数据”，大模型可能只保留 “市场规模”，而遗漏 “用户结构”“平台份额” 等同样重要的数据；总结会议纪要时，写 “保留关键任务”，大模型可能只保留任务名称，而遗漏 “责任人”“截止时间”。

6.1.2 避免方法

将模糊表述替换为 “具体的信息类型 + 具体内容”，让大模型有明确的识别标准。例如：
错误示例：“总结报告中的重要数据”；
正确示例：“总结报告中的 3 类数据：2024 年市场规模（亿元）、用户年龄分布（18 岁以下 / 18-25 岁 / 26-35 岁 / 35 岁以上占比）、TOP3 企业市场份额（%）”；
错误示例：“保留会议中的关键任务”；
正确示例：“保留会议中的每个任务的 4 个信息：任务名称、责任人（部门 + 姓名）、截止时间（年月日时分）、交付标准（如‘提交测试报告’）”。
拆分文本：将万字报告按 “章节” 拆分为 3-4 段（如 “第 1-2 章：行业现状”“第 3-4 章：未来趋势”“第 5 章：风险提示”），每段字数控制在 2000-3000 字；
分段总结：为每段文本设计针对性提示词（如总结 “未来趋势” 段时，提示词明确 “保留 3 个趋势及支撑理由”），让大
6.2 错误 2：未考虑 “长文本上下文限制”，关键信息被截断

6.2.1 常见问题

直接将超长文本（如万字报告、几十页会议纪要）粘贴到提示词中，超过大模型的上下文窗口限制（如 GPT-3.5 约 4096 tokens，GPT-4 约 8192 tokens），导致后半部分文本的关键信息被截断，大模型无法总结。例如，粘贴万字报告后，大模型只能识别前 3000 字的内容，遗漏后 7000 字中的 “未来趋势预测”“风险提示” 等关键信息。

6.2.2 避免方法

根据大模型的上下文限制，对长文本进行 “分段处理”，具体步骤：模型专注总结每段的关键信息，避免信息截断；

3. 合并总结：待所有分段总结完成后，设计提示词 “将以下 3 段总结内容（分别对应行业报告的现状、趋势、风险）合并，保留各段的核心数据和观点，确保逻辑连贯，不遗漏关键信息”，让大模型生成完整总结。

若使用支持长上下文的大模型（如 GPT-4 Turbo，上下文窗口达 128k tokens），可适当放宽文本长度限制，但仍建议按 “章节” 拆分提示词，让大模型聚焦每部分的关键信息，避免因文本过长导致注意力分散。

6.3 错误 3：未 “指定输出格式”，大模型自由组织内容导致信息遗漏

6.3.1 常见问题

提示词中未明确输出格式，大模型按自由段落形式总结，可能将多个关键信息混在一起，导致部分信息被淹没或遗漏。例如，总结会议纪要时，大模型用大段文字描述任务，未区分 “责任人”“截止时间”，读者需逐句查找，且容易漏看 “协作要求”；总结行业报告时，大模型未分 “数据”“观点” 分类呈现，导致 “未来趋势” 的支撑理由被遗漏。

6.3.2 避免方法

根据文本类型和核心目标，指定 “结构化输出格式”，让大模型按格式填充内容，确保关键信息不遗漏。常见的结构化格式包括：
分点式：适合呈现多个独立的关键信息，如任务分工、风险提示，示例格式：“1. 任务 1：XXX；1.1 责任人：XXX；1.2 截止时间：XXX；1.3 交付标准：XXX”；
表格式：适合呈现多维度关联的信息，如任务表、数据对比，示例格式：“| 任务名称 | 责任人 | 截止时间 | 交付标准 |”；
层级式：适合呈现逻辑关联的信息，如书籍框架、观点论证，示例格式：“1. 整体框架：XXX；1.1 第 1 章主题：XXX；1.1.1 核心观点：XXX；1.1.2 支撑案例：XXX”。
示例（总结会议纪要）：
错误格式要求：“用文字总结会议中的任务”；
正确格式要求：“用表格总结会议中的任务，表格包含‘任务名称、责任人、截止时间、交付标准、协作要求’五列，每列内容需填写完整，不遗漏信息”。
6.4 错误 4：未 “验证关键信息完整性”，直接使用总结结果

6.4.1 常见问题

生成总结后，未检查大模型是否遗漏关键信息，直接将总结用于工作（如发送给团队成员、作为决策参考），导致后续出现问题。例如，总结合同文本时，大模型遗漏 “尾款支付时间”，团队按总结执行时未按时支付尾款，引发乙方不满；总结项目计划时，大模型遗漏 “风险应对措施”，项目遇到风险时无预案，导致延期。

6.4.2 避免方法

生成总结后，通过 “人工核对” 和 “提示词二次验证” 确保关键信息完整，具体步骤：
人工核对：将总结与原文关键部分对比，检查是否遗漏 “必须保留的信息”（如合同中的付款节点、会议纪要中的截止时间），重点核对数据类信息（如数值、单位）和特殊类信息（如违约条款、风险提示）；
提示词二次验证：若文本较长，可设计验证提示词让大模型自查，示例：“请检查你之前总结的《软件采购合同》内容，是否遗漏以下关键信息：1. 甲方支付尾款的时间；2. 乙方售后服务的响应时间；3. 乙方违约时的违约金计算方式。若有遗漏，请补充完整”；
场景化验证：假设实际使用场景，检查总结是否满足需求，如总结会议纪要时，假设 “技术部人员查看总结，是否能明确自己的任务、配合部门及时间节点”；总结行业报告时，假设 “业务决策时，是否能从总结中获取‘市场规模’‘增长率’‘未来趋势’及支撑理由”。
6.5 错误 5：提示词中 “混入无关信息”，干扰大模型判断

6.5.1 常见问题

提示词中加入与 “总结目标无关的信息”，如个人感受、无关背景，导致大模型注意力分散，遗漏关键信息。例如，总结行业报告时，提示词写 “这份报告是我上周从网上下载的，内容很复杂，我花了 3 天才看完，你帮我总结一下里面的重要数据”，其中 “下载渠道”“阅读时间”“个人感受” 均为无关信息，大模型可能受 “内容很复杂” 影响，简化总结，遗漏部分数据；总结会议纪要时，提示词加入 “会议开了 2 小时，大家讨论很激烈”，大模型可能关注 “讨论过程”，而遗漏 “任务分工”。

6.5.2 避免方法

提示词需 “简洁聚焦”，只包含 “文本类型、核心目标、必须保留的关键信息、输出格式” 四个核心要素，删除无关信息（如个人感受、文本获取渠道、阅读时长）。示例：
错误提示词：“这份《2024 年短视频行业报告》是我同事传给我的，我看了开头觉得数据很多，你帮我总结一下，要有用的信息，不要太复杂”；
正确提示词：“我需要你总结《2024 年短视频行业报告》，核心目标是获取行业核心数据用于业务参考。必须保留的关键信息：1. 2024 年市场规模（亿元）及同比增长率；2. 用户年龄分布（18 岁以下 / 18-25 岁 / 26-35 岁 / 35 岁以上占比）；3. TOP3 平台市场份额（%）。输出格式：分点列出，每个数据标注单位”。
6.6 错误 6：未 “适配大模型能力”，要求超出模型范围

6.6.1 常见问题

对大模型提出超出其能力范围的要求，导致总结无法保留关键信息。例如，让基础大模型（如 GPT-3.5）总结 “包含专业公式推导的学术论文”，要求保留 “公式推导过程和逻辑”，但基础模型对复杂公式的理解和呈现能力有限，可能遗漏推导关键步骤；让不支持长文本的模型总结 “5 万字的书籍”，未分段处理，模型无法完整识别文本，导致大部分关键信息被遗漏；要求模型总结 “模糊不清的手写会议纪要”（文本有多处涂改、语句不完整），模型无法准确识别原文关键信息，自然无法保留。

6.6.2 避免方法

根据大模型的能力范围设计提示词，不提出超出其能力的要求，具体：
了解模型基础能力：提前了解模型的 “上下文窗口大小”（如 GPT-3.5 约 4096 tokens，GPT-4 约 8192 tokens）、“专业领域适配性”（如学术模型更擅长总结论文，通用模型更擅长总结报告、纪要）；
拆分超出能力的需求：若模型不支持复杂公式推导，总结学术论文时，提示词调整为 “保留论文的核心结论、数据支撑和公式最终结果，无需推导过程”；若模型上下文窗口小，将长文本拆分为多段总结；
预处理不清晰文本：若原文模糊（如手写纪要、扫描件识别错误），先人工整理原文，修正涂改和错误语句，再输入模型总结，避免模型因原文模糊导致信息遗漏。
7. 工具推荐：提升长文本总结效率的辅助工具

除了设计优质提示词，搭配合适的辅助工具，能进一步提升大模型总结长文本的效率，确保关键信息不遗漏。下面推荐 4 类常用工具，包含工具功能、使用场景和操作示例，帮助大家快速上手。

7.1 长文本拆分工具：解决 “上下文窗口限制” 问题

7.1.1 工具推荐：Text Splitter（在线工具）、Python LangChain 库
Text Splitter（在线工具）：无需代码，上传长文本（支持 TXT、DOCX 格式），按 “字数”“段落”“章节” 拆分，可自定义拆分长度（如每段 2000 字），拆分后自动生成分段文件，直接复制到提示词中使用；
Python LangChain 库：适合有代码基础的用户，通过代码实现 “智能拆分”（如按书籍章节、报告标题拆分），支持对接大模型 API，实现 “拆分 - 总结 - 合并” 自动化流程。
7.1.2 使用场景

处理万字以上的长文本（如书籍、行业报告、长篇会议纪要），避免因超出模型上下文窗口导致信息截断。

7.1.3 操作示例（Text Splitter 在线工具）
打开工具官网（如https://text-splitter.com/）；
点击 “上传文件”，选择需要总结的《2024 年新能源汽车行业报告》（DOCX 格式）；
选择拆分方式为 “按章节拆分”，设置 “每段最大字数” 为 3000 字；
点击 “开始拆分”，工具自动按报告章节拆分为 3 段（第 1-2 章：行业现状，第 3-4 章：未来趋势，第 5 章：风险提示）；
点击 “下载拆分结果”，获取 3 个 TXT 文件，分别复制每个文件内容到提示词中，分段总结。
7.2 提示词模板工具：快速生成 “结构化提示词”

7.2.1 工具推荐：PromptBase（模板市场）、ChatGPT Prompt Builder（在线生成器）
PromptBase（模板市场）：提供各类 “长文本总结” 提示词模板，按文本类型分类（如报告总结、会议纪要总结、合同总结），可直接购买或参考模板修改，适合新手快速设计提示词；
ChatGPT Prompt Builder（在线生成器）：通过 “选择文本类型→填写核心目标→勾选关键信息类型→选择输出格式” 的可视化操作，自动生成结构化提示词，无需手动组织语言。
7.2.2 使用场景

新手设计提示词时，避免因 “关键信息描述模糊”“格式不清晰” 导致信息遗漏；需要快速生成提示词，提升工作效率（如每天需总结多份会议纪要）。

7.2.3 操作示例（ChatGPT Prompt Builder）
打开工具官网（如https://chatgpt-prompt-builder.com/）；
在 “文本类型” 下拉框选择 “会议纪要”；
在 “核心目标” 输入框填写 “让团队成员明确任务分工、截止时间和协作要求”；
在 “关键信息类型” 勾选 “任务名称、责任人、截止时间、交付标准、协作要求、风险提示”；
在 “输出格式” 选择 “表格 + 分点”，点击 “生成提示词”；
工具自动生成提示词：“我需要你总结一份会议纪要，核心目标是让团队成员明确任务分工、截止时间和协作要求。总结时必须保留以下关键信息：1. 任务名称；2. 责任人；3. 截止时间；4. 交付标准；5. 协作要求；6. 风险提示。请按以下格式输出：1. 核心任务表（表格包含‘任务名称、责任人、截止时间、交付标准、协作要求’五列）；2. 风险提示（分点列出风险内容及应对措施）”；
复制生成的提示词，粘贴到 ChatGPT 中，再输入会议纪要原文，即可生成符合要求的总结。
7.3 信息验证工具：确保总结 “关键信息准确完整”

7.3.1 工具推荐：Grammarly（文本检查）、自定义 Excel 核对表
Grammarly（文本检查）：检查总结中的 “数据错误”（如数值单位遗漏、百分比计算错误）、“语句歧义”（如模糊时间表述 “几天后”），确保关键信息准确；
自定义 Excel 核对表：按 “必须保留的关键信息” 制作核对表（如合同总结核对表包含 “付款节点、交付标准、违约条款、权利义务”），总结生成后，逐一勾选核对，确保无遗漏。
7.3.2 使用场景

总结包含大量数据的文本（如行业报告、财务报表），避免数据错误；总结对准确性要求高的文本（如合同、法律条款），避免遗漏关键条款。

7.3.3 操作示例（自定义 Excel 核对表）
制作 “合同总结核对表”，列名为 “关键信息类型、原文内容、总结内容、是否完整准确”；
在 “关键信息类型” 列填写 “预付款支付时间、进度款支付时间、尾款支付时间、乙方交付内容、验收标准、甲方违约处理、乙方违约处理”；
从合同原文中提取 “原文内容”（如预付款支付时间：合同签订后 10 天内）；
将大模型生成的总结内容填入 “总结内容” 列（如预付款支付时间：合同签订后 10 天内）；
对比 “原文内容” 和 “总结内容”，在 “是否完整准确” 列勾选 “是” 或 “否”，若勾选 “否”（如总结遗漏尾款支付时间），返回大模型用提示词补充：“请补充总结中遗漏的‘尾款支付时间’，根据原文内容填写准确”。
7.4 自动化总结工具：实现 “长文本总结全流程自动化”

7.4.1 工具推荐：ChatGPT Plus（结合插件）、Notion AI（文档集成）
ChatGPT Plus（结合 Web Pilot 插件）：上传长文本文件（支持 PDF、DOCX），插件自动拆分文本，结合自定义提示词，实现 “拆分 - 总结 - 合并” 全流程自动化，无需手动分段；
Notion AI（文档集成）：在 Notion 中直接创建长文本文档（如会议纪要、报告），使用 “总结” 功能，选择 “保留关键信息类型”（如数据、任务、观点），AI 自动生成结构化总结，支持实时修改补充。
7.4.2 使用场景

需要批量总结长文本（如每周总结 5 份行业报告、10 份会议纪要），提升工作效率；希望在日常办公软件（如 Notion、Word）中直接完成总结，无需切换工具。

7.4.3 操作示例（Notion AI）
打开 Notion，创建新页面，粘贴《项目上线前协调会议纪要》全文；
选中全文，点击右键，选择 “Ask AI”→“Summarize”（总结）；
在弹出的对话框中，选择 “Custom summary”（自定义总结），输入需求：“总结时保留以下关键信息：1. 核心任务（名称、责任人、截止时间、交付标准）；2. 项目上线时间；3. 风险提示及应对措施。输出格式：先表格呈现任务，再分点呈现补充信息”；
点击 “Generate”（生成），Notion AI 自动生成总结，若发现遗漏 “协作要求”，点击 “Edit”（编辑），补充提示词：“请在任务表中添加‘协作要求’列，补充各任务的协作内容”，AI 自动更新总结内容。
8. 常见问题解答（FAQ）

在使用大模型总结长文本、设计提示词的过程中，大家可能会遇到一些高频问题。下面整理 10 个常见问题及解答，覆盖 “提示词设计”“信息遗漏处理”“工具使用” 等方面，帮助大家快速解决问题。

8.1 问：提示词中已经明确关键信息类型，大模型还是遗漏了怎么办？

答：可通过 “二次提示补充” 和 “细化提示词” 解决：
二次提示补充：直接告诉大模型遗漏的信息类型，示例：“你之前总结的行业报告中，遗漏了‘TOP3 企业的市场份额占比’，请根据原文补充这部分数据，标注具体数值和单位”；
细化提示词：若二次补充后仍遗漏，细化关键信息描述，示例：“总结报告中的 TOP3 企业市场份额，需明确企业名称（如比亚迪、特斯拉、蔚来）和对应的占比（%），每个企业的信息单独列出，不合并表述”。
8.2 问：长文本包含多类关键信息（如数据、观点、任务），如何确保大模型都能保留？

答：采用 “分类指定 + 结构化输出” 的方法：
分类指定关键信息：在提示词中按 “类型” 分点列出必须保留的信息，示例：“1. 数据类信息：XXX；2. 观点类信息：XXX；3. 任务类信息：XXX”；
结构化输出格式：要求大模型按 “类型” 分类呈现总结，示例：“输出时先呈现‘数据类信息’，再呈现‘观点类信息’，最后呈现‘任务类信息’，每类信息用分点或表格呈现，确保不混淆、不遗漏”。
提示词强调单位：在关键数据后明确标注单位，示例：“总结 20
8.3 问：大模型总结时，将关键数据的单位写错（如 “亿元” 写成 “万元”），如何避免？

答：通过 “提示词强调单位” 和 “人工核对” 避免：24 年市场规模时，需明确标注单位为 “亿元”，如‘2024 年市场规模 5000 亿元’，不可简写为‘5000 万’或‘5000’”；

2. 人工核对：总结生成后，重点核对数据类信息的单位，可将原文中的数据单位（如 “亿元”“%”“人”）与总结中的单位对比，发现错误后用提示词修正：“你总结的‘2024 年市场规模 5000 万元’单位错误，原文为‘5000 亿元’，请修正总结中的单位”。

8.4 问：总结法律类文本（如合同、法规）时，如何确保大模型不遗漏 “专业条款”（如免责条款、管辖法院）？

答：需在提示词中 “明确专业条款类型” 并 “要求引用原文表述”：
明确专业条款类型：直接列出法律文本中的核心专业条款，示例：“总结《软件采购合同》时，必须保留以下专业条款：1. 免责条款（如‘因不可抗力导致无法履约的责任免除’）；2. 管辖法院（如‘争议由甲方所在地法院管辖’）；3. 合同生效与终止条件；4. 违约责任划分”；
要求引用原文表述：法律条款对表述准确性要求高，提示词中加入 “专业条款的总结需尽量引用原文关键表述，避免意译导致歧义”，示例：“管辖法院条款需按原文表述总结，如原文为‘因本合同引起的争议，由甲方所在地有管辖权的人民法院管辖’，总结时不可简化为‘甲方所在地法院管辖’”。
8.5 问：用大模型总结外文长文本（如英文行业报告）时，如何确保关键信息（如数据、专业术语）准确翻译且不遗漏？

答：通过 “提示词明确翻译要求” 和 “双语核对” 确保：
明确翻译要求：在提示词中说明 “需将外文文本总结为中文，关键数据保留原数值 + 中文单位翻译，专业术语保留英文原文 + 中文释义”，示例：“总结英文报告时，‘market size 50 billion USD’需翻译为‘市场规模 500 亿美元（USD 为美元）’，‘AI-generated content’需翻译为‘人工智能生成内容（AI-generated content，简称 AIGC）’”；
双语核对：若具备基础外文能力，将总结中的关键信息（数据、术语）与外文原文对比，确认翻译准确；若不具备外文能力，使用 “DeepL 翻译” 等工具将外文原文关键部分翻译为中文，再与大模型总结对比，避免翻译错误或信息遗漏。
8.6 问：批量总结多份相似文本（如 10 份每周会议纪要）时，如何确保所有总结的格式和关键信息类型一致？

答：使用 “统一提示词模板”+“批量处理工具” 实现：
设计统一提示词模板：针对相似文本，固定 “关键信息类型” 和 “输出格式”，示例：“总结每周会议纪要时，必须保留：1. 本周完成任务（名称、责任人、完成情况）；2. 下周计划任务（名称、责任人、截止时间）；3. 待解决问题（问题描述、关联部门）。输出格式：分‘本周完成’‘下周计划’‘待解决问题’三部分，每部分用分点呈现，责任人需标注部门 + 姓名”；
用批量处理工具：使用 “ChatGPT API+Python 脚本” 或 “Notion AI 批量处理” 功能，将统一模板提示词与多份会议纪要文本批量输入，自动生成格式一致的总结，无需逐份手动输入提示词。
8.7 问：大模型总结长文本时，出现 “信息重复”（如同一数据多次提及），如何让总结更简洁且不遗漏关键信息？

答：在提示词中 “明确去重要求” 和 “信息优先级”：
明确去重要求：加入 “总结时需去除重复信息，同一关键数据（如市场规模）仅保留一次，选择原文中最新或最权威的表述”，示例：“报告中多次提及 2024 年市场规模，分别为‘4800 亿元’和‘5000 亿元’，总结时以‘5000 亿元（艾瑞咨询最新数据）’为准，去除重复的‘4800 亿元’表述”；
明确信息优先级：若不同部分提及同一类信息（如不同章节提及的用户年龄分布），提示词中说明 “优先保留数据更详细的表述”，示例：“报告第 2 章提及用户年龄分布（仅分 2 个年龄段），第 3 章提及详细分布（分 4 个年龄段），总结时保留第 3 章的详细分布，去除第 2 章的简略表述”。
8.8 问：总结包含 “图表” 的长文本（如带折线图的行业报告）时，如何让大模型保留图表中的关键信息（如趋势变化、峰值数据）？

答：需在提示词中 “描述图表内容” 并 “指定提取信息类型”：
手动描述图表内容：大模型无法直接识别图片，需先将图表信息转化为文本，示例：“报告第 5 页有‘2020-2024 年行业市场规模折线图’，数据为：2020 年 3000 亿元，2021 年 3800 亿元，2022 年 4200 亿元，2023 年 4000 亿元，2024 年 5000 亿元，趋势为‘2020-2022 年增长，2022-2023 年小幅下降，2023-2024 年快速增长’”；
指定提取信息类型：提示词中要求 “保留图表中的关键数据（每年数值）、趋势变化（增长 / 下降 / 持平）、峰值数据（如 2024 年为近 5 年峰值）”，示例：“总结折线图信息时，需包含：1. 2020-2024 年每年市场规模（单位：亿元）；2. 各阶段趋势（如 2022-2023 年下降原因：原文提及‘受疫情影响’）；3. 近 5 年峰值年份及数值”。
8.9 问：新手刚开始学习设计提示词，有没有快速上手的 “通用模板” 可直接使用？

答：有，以下是适用于大部分长文本总结的通用提示词模板，新手可根据文本类型调整括号中的内容：

“我需要你总结一份【文本类型，如行业报告 / 会议纪要 / 合同 / 书籍章节】，核心目标是【总结目标，如获取核心数据用于业务参考 / 明确任务分工 / 了解权利义务 / 掌握核心观点】。

总结时必须保留以下关键信息：
【第一类关键信息，如数据类】：【具体信息，如 2024 年市场规模（单位：亿元）、同比增长率、用户年龄分布】；
【第二类关键信息，如结构类 / 观点类 / 特殊类】：【具体信息，如任务名称、责任人、截止时间 / 核心论点、支撑理由 / 权利义务、违约条款】；
【第三类关键信息（可选，根据文本类型增减）】：【具体信息】。
请按以下格式输出总结：
【第一部分标题，如核心数据 / 任务分工 / 权利义务】：
1.1 【子项 1，如市场规模】：

1.2 【子项 2，如增长率】：
【第二部分标题，如未来趋势 / 待解决问题 / 违约处理】：
2.1 【子项 1】：

2.2 【子项 2】：
【第三部分标题（可选）】：”
示例（总结会议纪要）：

“我需要你总结一份【会议纪要】，核心目标是【明确团队成员的任务分工和时间节点，避免遗漏行动项】。

总结时必须保留以下关键信息：
【结构类信息】：【本周完成任务（名称、责任人、完成情况）、下周计划任务（名称、责任人、截止时间）、待解决问题（问题描述、关联部门）】；
【特殊类信息】：【会议确定的项目里程碑时间、需要跨部门协作的任务】。
请按以下格式输出总结：
【本周完成任务】：
1.1 【任务 1】：名称：XXX，责任人：XXX（部门 + 姓名），完成情况：XXX；

1.2 【任务 2】：名称：XXX，责任人：XXX（部门 + 姓名），完成情况：XXX；
【下周计划任务】：
2.1 【任务 1】：名称：XXX，责任人：XXX（部门 + 姓名），截止时间：XXX（年月日时分）；

2.2 【任务 2】：名称：XXX，责任人：XXX（部门 + 姓名），截止时间：XXX（年月日时分）；
【待解决问题与项目里程碑】：
3.1 【待解决问题】：问题 1：XXX，关联部门：XXX；问题 2：XXX，关联部门：XXX；

3.2 【项目里程碑】：XXX 时间完成 XXX 阶段，XXX 时间完成整体项目。”

8.10 问：使用辅助工具（如 Text Splitter）拆分长文本后，如何让大模型合并总结时不遗漏各段的关键信息？

答：通过 “明确合并规则” 和 “提供分段总结关键点” 实现：
明确合并规则：设计合并提示词时，说明 “合并需保留每段总结的核心信息，不可删减某段的关键数据或观点，逻辑按原文顺序（如现状→趋势→风险）组织”，示例：“请合并以下 3 段总结（段 1：行业现状数据，段 2：未来趋势预测，段 3：风险提示及应对），要求：1. 保留段 1 的‘市场规模、用户结构’，段 2 的‘3 个趋势及理由’，段 3 的‘2 个风险及应对措施’；2. 按‘现状→趋势→风险’的顺序组织内容，用标题区分各部分，避免信息混淆”；
提供分段总结关键点：若担心大模型合并时遗漏，在合并提示词中列出各段的关键点，示例：“段 1 关键信息：2024 年市场规模 5000 亿元、用户 18-35 岁占比 85%；段 2 关键信息：趋势 1（短视频 + 电商）、趋势 2（垂类内容增长）、趋势 3（AIGC 应用）；段 3 关键信息：风险 1（监管政策收紧）、风险 2（用户增长放缓）及对应应对措施。合并时需确保这些关键点全部保留”。
9. 实战练习：设计提示词总结不同类型长文本

为帮助大家熟练掌握 “让大模型保留关键信息” 的提示词设计方法，下面提供 3 个不同类型文本的实战练习任务，每个任务包含 “文本背景”“设计要求”“参考提示词”“预期输出效果” 四部分，读者可按步骤完成练习，巩固所学技巧。

9.1 练习一：总结行业报告（数据类文本）

9.1.1 文本背景

文本类型：《2024 年中国直播电商行业报告》（节选）；

核心内容：2024 年直播电商行业市场规模、用户结构、主要平台份额、2025 年趋势预测；

关键信息：
数据类：2024 年市场规模 1.8 万亿元（同比增长 25%，数据来源：易观分析）；用户年龄分布（18-25 岁 30%、26-35 岁 45%、35 岁以上 25%）；TOP3 平台份额（抖音 50%、淘宝直播 30%、快手 15%）；
观点类：2025 年 3 个趋势（品牌自播占比提升、跨境直播电商增长、AI 虚拟主播应用普及），每个趋势的支撑理由（如品牌自播理由：2024 年品牌自播 GMV 同比增长 60%）。
9.1.2 设计要求
提示词需包含 “文本类型、核心目标、必须保留的关键信息（数据类 + 观点类）、输出格式”；
数据类信息需标注 “单位、数据来源、计算维度（如平台份额按 GMV）”；
观点类信息需包含 “趋势内容 + 支撑理由”；
输出格式需分 “核心数据”“未来趋势” 两部分，每部分用分点呈现。
9.1.3 参考提示词

“我需要你总结《2024 年中国直播电商行业报告》（节选），核心目标是让读者快速了解行业核心数据和 2025 年发展趋势，用于业务规划参考。

总结时必须保留以下关键信息：
数据类信息：
1.1 2024 年市场规模：1.8 万亿元，同比 2023 年增长 25%，数据来源：易观分析；

1.2 用户年龄分布：18-25 岁占比 30%、26-35 岁占比 45%、35 岁以上占比 25%；

1.3 TOP3 平台份额：按 GMV 计算，抖音 50%、淘宝直播 30%、快手 15%；
观点类信息：
2.1 2025 年趋势 1：品牌自播占比提升，支撑理由：2024 年品牌自播 GMV 同比增长 60%，品牌方更注重私域流量运营；

2.2 2025 年趋势 2：跨境直播电商增长，支撑理由：2024 年跨境直播 GMV 突破 2000 亿元，东南亚、欧洲市场需求旺盛；

2.3 2025 年趋势 3：AI 虚拟主播应用普及，支撑理由：2024 年已有 40% 的头部直播间使用 AI 虚拟主播，降低人力成本。

请按以下格式输出总结：
2024 年直播电商行业核心数据（每个数据标注单位、来源或计算维度）：
1.1 市场规模：

1.2 用户年龄分布：

1.3 TOP3 平台份额（按 GMV）：
2025 年行业发展趋势及支撑理由（分点列出每个趋势，说明理由）：
2.1 趋势 1：品牌自播占比提升
- 支撑理由：
2.2 趋势 2：跨境直播电商增长
- 支撑理由：
2.3 趋势 3：AI 虚拟主播应用普及
- 支撑理由：”
9.1.4 预期输出效果
2024 年直播电商行业核心数据（每个数据标注单位、来源或计算维度）：
1.1 市场规模：2024 年直播电商行业市场规模 1.8 万亿元，同比 2023 年增长 25%，数据来源：易观分析；

1.2 用户年龄分布：18-25 岁用户占比 30%，26-35 岁用户占比 45%，35 岁以上用户占比 25%；

1.3 TOP3 平台份额（按 GMV）：抖音占比 50%，淘宝直播占比 30%，快手占比 15%；
2025 年行业发展趋势及支撑理由（分点列出每个趋势，说明理由）：
2.1 趋势 1：品牌自播占比提升
- 支撑理由：2024 年品牌自播 GMV 同比增长 60%，且品牌方越来越重视私域流量运营，通过自播可直接触达用户，减少对达人主播的依赖；
2.2 趋势 2：跨境直播电商增长
- 支撑理由：2024 年跨境直播电商 GMV 已突破 2000 亿元，东南亚（如印尼、马来西亚）和欧洲（如英国、德国）市场对中国商品需求旺盛，直播形式更易展示商品细节，提升转化率；
2.3 趋势 3：AI 虚拟主播应用普及
- 支撑理由：2024 年已有 40% 的头部直播间引入 AI 虚拟主播，虚拟主播可 24 小时不间断直播，且人力成本仅为真人主播的 1/10，大幅降低运营成本，尤其适合标品直播（如美妆、3C 产品）。
结构类：3 个核心任务（任务 1：产品部输出需求文档 V2.0，责任人：小李，截止时间：6 月 10 日 18:00，交付标准：包含功能清单、用户流程图；任务 2：技术部完成核心功能开发，责任人：老王，截止时间：6 月 25 日 18:00，协作要求：需产品部 6 月 12 日前确认需求文档；任务 3：测试部完成功能测试，责任人：小张，截止时间：6 月
9.2 练习二：总结会议纪要（结构类文本）

9.2.1 文本背景

文本类型：“产品迭代会议纪要”（节选）；核心内容：产品 V3.0 版本迭代的任务分工、时间节点、协作要求、风险提示；

关键信息：30 日 18:00，协作要求：技术部 6 月 26 日前提交开发完成的版本）；
特殊类：项目上线时间为 7 月 5 日 00:00；2 个风险提示（风险 1：技术开发延期，影响测试和上线；风险 2：需求文档确认延迟，导致开发启动滞后）及应对措施（风险 1 应对：技术部 6 月 20 日进行中期进度检查，预留 5 天缓冲时间；风险 2 应对：产品部 6 月 10 日前完成需求文档 V2.0，6 月 11 日组织快速确认会议，1 天内完成确认）。
9.2.2 设计要求
提示词需包含 “文本类型、核心目标、必须保留的关键信息（结构类 + 特殊类）、输出格式”；
结构类信息需明确 “任务名称、责任人、截止时间、交付标准、协作要求”；
特殊类信息需包含 “上线时间、风险提示及对应应对措施”；
输出格式需用 “表格呈现核心任务，分点呈现补充信息”，确保清晰易读。
9.2.3 参考提示词

“我需要你总结‘产品 V3.0 版本迭代会议纪要’（节选），核心目标是让产品部、技术部、测试部人员明确各自任务、协作要求及风险应对，确保迭代按时完成。

总结时必须保留以下关键信息：
结构类信息（核心任务）：
1.1 任务 1：产品部输出需求文档 V2.0，责任人：小李，截止时间：6 月 10 日 18:00，交付标准：包含功能清单、用户流程图，协作要求：无（需独立完成）；

1.2 任务 2：技术部完成核心功能开发，责任人：老王，截止时间：6 月 25 日 18:00，交付标准：开发完成的功能版本（无严重 Bug），协作要求：产品部需在 6 月 12 日前确认需求文档；

1.3 任务 3：测试部完成功能测试，责任人：小张，截止时间：6 月 30 日 18:00，交付标准：《功能测试报告》（标注无高危 Bug），协作要求：技术部需在 6 月 26 日前提交开发版本；
特殊类信息：
2.1 项目上线时间：7 月 5 日 00:00；

2.2 风险提示及应对措施：
- 风险 1：技术开发延期，影响后续测试和上线；应对措施：技术部 6 月 20 日进行中期进度检查，若进度滞后，增加 1 名开发人员支援，预留 5 天缓冲时间（6 月 26 日 - 30 日）；
- 风险 2：需求文档确认延迟，导致开发启动滞后；应对措施：产品部 6 月 10 日前完成需求文档 V2.0，6 月 11 日组织技术部、测试部开快速确认会议，1 天内完成确认，避免开发延迟启动。
请按以下格式输出总结：
产品 V3.0 迭代核心任务表（表格包含 “任务名称、责任人、截止时间、交付标准、协作要求” 五列）；
关键补充信息（分点列出上线时间、风险提示及应对措施）：
2.1 项目上线时间：

2.2 风险提示及应对措施：

2.2.1 风险 1（技术开发延期）：
- 风险影响：
- 应对措施：
2.2.2 风险 2（需求文档确认延迟）：
- 风险影响：
- 应对措施：”
9.2.4 预期输出效果
产品 V3.0 迭代核心任务表
| 任务名称 | 责任人 | 截止时间 | 交付标准 | 协作要求 |

|------------------------------|--------|-------------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------|

| 产品部输出需求文档 V2.0 | 小李 | 6 月 10 日 18:00 前 | 需求文档 V2.0，需包含 “功能清单”（明确各模块功能点）和 “用户流程图”（标注用户操作路径） | 无，由产品部独立完成，完成后同步至项目群 |

| 技术部完成核心功能开发 | 老王 | 6 月 25 日 18:00 前 | 核心功能开发完成的版本，通过技术部内部自测，确保无严重 Bug（如崩溃、功能无法使用） | 需产品部在 6 月 12 日前确认需求文档 V2.0，确认后才可启动开发 |

| 测试部完成功能测试 | 小张 | 6 月 30 日 18:00 前 | 《功能测试报告》，需标注 “测试用例覆盖率≥90%”“无高危 Bug”“中低危 Bug≤3 个” | 技术部需在 6 月 26 日前将开发完成的版本提交给测试部，逾期会影响测试进度 |
关键补充信息
2.1 项目上线时间：产品 V3.0 版本最终上线时间为 7 月 5 日 00:00（北京时间），上线前 1 天（7 月 4 日）各部门需安排 1 名人员值班，处理上线前的突发问题；

2.2 风险提示及应对措施：

2.2.1 风险 1（技术开发延期）：
- 风险影响：若技术开发超过 6 月 25 日完成，会导致测试部无法在 6 月 30 日前完成测试，进而影响 7 月 5 日的上线计划；
- 应对措施：技术部 6 月 20 日 16:00 前召开中期进度会议，同步各功能模块开发进度；若某模块进度滞后超过 2 天，立即协调 1 名备用开发人员支援；预留 6 月 26 日 - 30 日共 5 天缓冲时间，即使开发延期 1-2 天，测试仍可按时完成；
2.2.2 风险 2（需求文档确认延迟）：
- 风险影响：若产品部未在 6 月 10 日前完成需求文档，或确认超过 6 月 12 日，会导致技术开发启动滞后，后续测试和上线时间可能被迫推迟；
- 应对措施：产品部 6 月 9 日完成需求文档 V2.0 初稿，内部审核 1 天，6 月 10 日 18:00 前定稿并发送给技术部、测试部；6 月 11 日 10:00 组织线上确认会议，会议时长控制在 1 小时内，各部门针对文档疑问现场沟通，当天 18:00 前完成书面确认，确保技术部 6 月 13 日正常启动开发。
9.3 练习三：总结合同文本（特殊类文本）

9.3.1 文本背景

文本类型：《网站建设服务合同》（甲方：C 公司，乙方：D 网络科技公司）；

核心内容：乙方为甲方提供企业官网建设服务的权利义务、付款方式、交付要求、违约处理；

关键信息：
特殊类（权利义务）：
甲方权利：要求乙方在合同签订后 30 天内完成官网建设并上线；要求乙方提供 1 年免费维护服务（含内容更新、故障修复）；官网上线后 15 天内，若发现功能与合同附件《需求清单》不符，有权要求乙方免费修改；

甲方义务：合同签订后 7 天内支付 50% 预付款（合同总金额 10 万元，即 5 万元）；官网验收合格后 10 天内支付 40% 进度款（4 万元）；免费维护期满前 15 天内，若续签维护合同，支付剩余 10% 尾款（1 万元）；向乙方提供官网所需的企业资料（如 Logo、产品图片、公司介绍），并确保资料真实性；

乙方权利：按合同约定收取三笔款项；若甲方未按时提供企业资料，有权顺延官网上线时间；

乙方义务：按《需求清单》建设官网，确保包含 “首页、产品展示页、公司介绍页、联系我们页” 四大核心页面；官网上线前提供 2 次操作培训（覆盖甲方 3 名操作人员）；免费维护期内，故障响应时间不超过 8 小时（工作日 9:00-18:00）；
特殊类（交付与验收）：
交付内容：乙方需交付 “上线后的官网地址、后台管理账号密码、操作手册（电子版）、培训视频”；

验收标准：官网功能 100% 符合《需求清单》；页面加载速度≤3 秒（电脑端 + 手机端）；兼容性支持主流浏览器（Chrome、Edge、Safari）；

验收流程：乙方完成官网建设后，书面通知甲方验收；甲方需在 5 天内组织验收，验收合格签署《验收确认书》，不合格需书面说明问题，乙方 5 天内整改后重新验收；
特殊类（违约处理）：
甲方违约：未按时付款，每逾期 1 天按未付金额 0.5% 支付违约金；逾期超过 15 天，乙方有权暂停服务（如维护、整改）；

乙方违约：未按时上线，每逾期 1 天按合同总金额 0.3% 支付违约金；整改后官网仍不符合验收标准，甲方有权解除合同，乙方需退还已收款项，并支付合同总金额 20% 的违约金。

9.3.2 设计要求
提示词需包含 “文本类型、核心目标、必须保留的关键信息（权利义务、交付验收、违约处理）、输出格式”；
权利义务需分 “甲方、乙方”，明确 “权利、义务”；
交付验收需包含 “交付内容、验收标准、验收流程”；
违约处理需分 “甲方、乙方”，明确 “违约情形、处理方式”；
输出格式需分 “权利义务、交付验收、违约处理” 三部分，每部分用层级分点呈现。
9.3.3 参考提示词

“我需要你总结《网站建设服务合同》（甲方：C 公司，乙方：D 网络科技公司，合同总金额 10 万元），核心目标是让甲乙双方明确各自权利义务、交付验收要求及违约后果，避免后续执行争议。

总结时必须保留以下关键信息：
权利义务（分甲方、乙方）：
1.1 甲方：
- 权利：要求乙方 30 天内完成官网建设上线；1 年免费维护服务（内容更新、故障修复）；上线 15 天内功能不符可要求免费修改；
- 义务：7 天内付 50% 预付款（5 万元）；验收合格 10 天内付 40% 进度款（4 万元）；维护期满前 15 天续签则付 10% 尾款（1 万元）；提供真实企业资料（Logo、产品图片等）；
1.2 乙方：
- 权利：按约定收款；甲方未按时提供资料可顺延上线时间；
- 义务：按《需求清单》建设四大核心页面；上线前 2 次操作培训（3 人）；维护期故障响应≤8 小时（工作日）；
交付与验收：
2.1 交付内容：官网地址、后台账号密码、电子版操作手册、培训视频；

2.2 验收标准：功能 100% 符合《需求清单》；加载速度≤3 秒（电脑 + 手机）；支持主流浏览器；

2.3 验收流程：乙方书面通知验收；甲方 5 天内验收，合格签《验收确认书》，不合格书面提问题，乙方 5 天内整改重验；
违约处理（分甲方、乙方）：
3.1 甲方：未按时付款，每逾期 1 天按未付金额 0.5% 付违约金；逾期超 15 天，乙方可暂停服务；

3.2 乙方：未按时上线，每逾期 1 天按合同总额 0.3% 付违约金；整改后仍不达标，甲方可解除合同，乙方退已收款并付 20% 违约金（2 万元）。

请按以下格式输出总结：
甲乙双方权利义务：
1.1 甲方：

1.1.1 权利：

1.1.2 义务：

1.2 乙方：

1.2.1 权利：

1.2.2 义务：
官网交付与验收要求：
2.1 交付内容：

2.2 验收标准：

2.3 验收流程：
违约处理条款：
3.1 甲方违约：

3.1.1 违约情形：

3.1.2 处理方式：

3.2 乙方违约：

3.2.1 违约情形：

3.2.2 处理方式：”

9.3.4 预期输出效果
甲乙双方权利义务：
1.1 甲方：

1.1.1 权利：
- 要求乙方在合同签订后 30 天内完成企业官网建设并正式上线，若乙方未按此时间完成，有权询问进度并要求说明原因；
- 享受官网上线后 1 年的免费维护服务，维护内容包括 “每月不超过 5 次的内容更新（如产品信息添加）” 和 “24 小时内响应的故障修复（如页面无法打开、功能报错）”；
- 官网上线后 15 天内，若发现官网功能与《需求清单》中的约定不符（如缺失 “产品展示页筛选功能”），有权要求乙方免费修改，直至符合需求；
1.1.2 义务：
- 付款义务：合同签订后 7 天内，向乙方支付 50% 预付款，金额为 5 万元（合同总金额 10 万元）；官网验收合格后 10 天内，支付 40% 进度款，金额为 4 万元；免费维护期满前 15 天，若决定续签维护合同，支付剩余 10% 尾款，金额为 1 万元；
- 配合义务：合同签订后 3 天内，向乙方提供官网建设所需的企业资料，包括 “企业 Logo（高清版）、产品图片（至少 10 张）、公司介绍文本（500 字以内）、联系方式（电话、邮箱、地址）”，并确保所有资料真实有效，若资料有误导致官网内容错误，需承担修改责任；
1.2 乙方：

1.2.1 权利：
- 按合同约定的时间和金额收取三笔款项（预付款、进度款、尾款），若甲方未按时付款，有权暂停后续工作（如官网开发、维护）；
- 若甲方未在合同签订后 3 天内提供企业资料，或提供的资料不完整（如缺少产品图片），有权顺延官网上线时间，顺延天数与甲方延迟提供资料的天数一致；
1.2.2 义务：
- 开发义务：严格按照合同附件《需求清单》建设官网，确保包含 “首页、产品展示页、公司介绍页、联系我们页” 四大核心页面，且每个页面的功能和设计符合需求描述；
- 培训义务：官网上线前，为甲方 3 名操作人员提供 2 次线上操作培训，培训内容包括 “后台登录、内容发布、订单查看（若有）”，培训后提供录屏视频供后续参考；
- 维护义务：免费维护期内，工作日 9:00-18:00 期间，接到甲方故障反馈后，响应时间不超过 8 小时，24 小时内提供故障解决方案（如远程修复、给出临时替代方案）；
官网交付与验收要求：
2.1 交付内容：乙方完成官网建设并测试无误后，需向甲方交付以下内容：
- 正式上线的官网访问地址（如https://www.ccompany.com）；
- 官网后台管理账号和密码（包含权限说明，如 “超级管理员可修改所有内容”）；
- 电子版《官网操作手册》（PDF 格式，包含图文步骤，如 “如何添加产品信息”）；
- 操作培训录屏视频（MP4 格式，分模块存储，如 “首页 Banner 修改.mp4”“产品展示页管理.mp4”）；
2.2 验收标准：甲方验收时需按以下标准判断官网是否合格：
- 功能标准：官网所有功能 100% 匹配《需求清单》，无缺失、无无效功能（如 “联系我们页表单提交功能可正常使用，提交后甲方邮箱能收到信息”）；
- 性能标准：电脑端和手机端访问官网，各核心页面加载速度均≤3 秒（可通过 “百度测速” 工具检测），无明显卡顿；
- 兼容性标准：支持 Chrome（90.0 及以上版本）、Edge（88.0 及以上版本）、Safari（14.0 及以上版本）主流浏览器，页面显示无错位、功能无异常；
- 乙方完成官网建设后，需通过邮件向甲方发送《验收通知》，说明验收所需的资料（如官网地址、测试账号）和验收时间要求；
- 甲方收到通知后，需
2.3 验收流程：在 5 天内组织验收工作，验收小组由甲方市场部 2 名人员（负责页面设计和内容准确性）、技术部 1 名人员（负责功能和性能测试）组成；
若验收合格，甲方需在验收完成后 1 个工作日内，由负责人签署《验收确认书》并扫描发送给乙方，作为支付进度款的依据；
若验收不合格，甲方需在验收完成后 3 个工作日内，向乙方发送书面《验收整改意见》，详细说明不合格项（如 “产品展示页无法筛选产品”“手机端加载速度超过 5 秒”）；乙方需在收到意见后 5 天内完成整改，整改完成后再次发送《验收通知》，甲方重新组织验收，直至验收合格。
违约处理条款：
3.1 甲方违约：

3.1.1 违约情形：
- 情形 1：未按合同约定时间支付预付款（合同签订后 7 天内）、进度款（验收合格后 10 天内）或尾款（维护期满前 15 天内）；
- 情形 2：逾期支付款项超过 15 天，经乙方书面提醒后仍未支付；
3.1.2 处理方式：
- 针对情形 1：每逾期 1 天，按未支付金额的 0.5% 向乙方支付违约金（示例：预付款 5 万元逾期 3 天，违约金 = 50000×0.5%×3=750 元）；违约金需与未支付款项一并支付；
- 针对情形 2：乙方有权暂停提供所有服务，包括官网维护、故障修复、整改支持等，直至甲方付清全部未支付款项及违约金；若暂停服务超过 30 天甲方仍未履约，乙方有权终止合同，且已收取的款项不予退还；
3.2 乙方违约：

3.2.1 违约情形：
- 情形 1：未在合同签订后 30 天内完成官网建设并上线（非甲方未提供资料导致的顺延除外）；
- 情形 2：官网经 2 次整改后，仍不符合验收标准（如功能缺失、加载速度不达标）；
3.2.2 处理方式：
- 针对情形 1：每逾期 1 天，按合同总金额（10 万元）的 0.3% 向甲方支付违约金（示例：逾期 5 天，违约金 = 100000×0.3%×5=1500 元）；逾期超过 15 天，甲方有权选择继续履行合同（乙方仍需支付违约金）或解除合同；
- 针对情形 2：甲方有权单方面解除合同，乙方需在合同解除后 10 天内，退还甲方已支付的所有款项（如预付款 5 万元、进度款 4 万元）；同时，乙方需向甲方支付合同总金额 20% 的违约金（100000×20%=20000 元），违约金需在退款时一并支付；若因乙方违约给甲方造成额外损失（如因官网未按时上线导致的推广延误损失），甲方有权另行追偿。
10. 不同水平用户的提示词设计建议

为了让不同基础的用户（新手、进阶、资深）都能高效设计 “保留关键信息” 的提示词，下面根据用户水平差异，给出针对性的学习路径和实操建议，帮助大家逐步提升技能。

10.1 新手用户：从 “套用模板” 到 “理解关键信息类型”

10.1.1 核心痛点

新手对 “关键信息类型” 的判断不清晰，设计提示词时容易遗漏核心内容；对输出格式的把控能力较弱，导致大模型输出混乱。

10.1.2 具体建议
从 “通用模板” 起步，降低设计难度
直接使用第 8.9 节中的 “通用提示词模板”，根据文本类型替换括号内容，无需自主设计整体结构。例如，总结行业报告时，只需在模板中填写 “文本类型 = 行业报告”“核心目标 = 获取核心数据”“关键信息类型 = 数据类（市场规模、增长率）+ 观点类（未来趋势）”，即可生成基础提示词。
先聚焦 “单一信息类型”，逐步扩展
初期优先总结只包含 “单一关键信息类型” 的文本，如只总结行业报告中的 “数据类信息”，或只总结会议纪要中的 “结构类信息（任务分工）”，避免同时处理多类型信息导致混乱。例如，设计提示词时明确 “仅保留数据类信息：2024 年市场规模、用户年龄分布、TOP3 企业份额”，专注练习数据类信息的保留技巧。
借助 “信息核对表” 验证结果
制作 “关键信息核对表”，按文本类型列出必查项（如行业报告核对表包含 “市场规模、增长率、数据来源”），总结生成后逐一勾选，确保无遗漏。例如，总结完成后对照核对表检查：“市场规模是否标注单位？增长率是否包含同比 / 环比？数据来源是否明确？”

10.2 进阶用户：从 “精准保留” 到 “优化输出逻辑”

10.2.1 核心痛点

进阶用户已能确保关键信息不遗漏，但输出内容的 “逻辑连贯性” 和 “实用性” 不足，例如总结会议纪要时，任务分工与风险提示的关联性不强；总结行业报告时，数据与观点的支撑关系不清晰。

10.2.2 具体建议
在提示词中 “明确信息关联要求”
设计提示词时，加入 “信息间的逻辑关系要求”，让大模型输出更具连贯性。例如，总结行业报告时，提示词补充 “用数据支撑观点，如‘2024 年市场规模增长 25%’需对应支撑‘未来趋势 1：行业持续扩张’”；总结会议纪要时，补充 “每个风险提示需对应说明‘影响哪些任务’，如‘技术开发延期会影响测试部 6 月 30 日的测试任务’”。
按 “使用场景” 优化输出格式
根据总结的实际用途调整输出格式，提升实用性。例如，若总结用于 “团队同步会议”，输出格式设计为 “口语化分点 + 重点标注”（如 “【紧急】任务 1：小李需在 6 月 10 日前完成需求文档，逾期会影响开发启动”）；若总结用于 “正式报告附件”，输出格式设计为 “结构化表格 + 书面化语言”，确保专业规范。
加入 “个性化需求”，提升总结价值
根据用户身份调整提示词，让总结更贴合使用人群。例如，为 “业务决策者” 总结行业报告时，提示词补充 “需包含‘数据结论 + 业务建议’，如‘市场规模增长 25%，建议加大华东地区推广投入’”；为 “执行人员” 总结会议纪要时，补充 “需在每个任务后标注‘优先级’，如‘任务 1（高优先级）、任务 2（中优先级）’”。

10.3 资深用户：从 “单文本总结” 到 “批量自动化”

10.3.1 核心痛点

资深用户已能熟练处理单文本总结，但面对 “批量总结多份相似文本”（如每天总结 10 份会议纪要、每周总结 5 份行业报告）时，手动设计提示词的效率低；需要将总结结果与其他工具（如 Excel、Notion）联动，实现自动化流转。

10.3.2 具体建议
设计 “批量提示词模板”，结合工具实现自动化
使用 Python 脚本或自动化工具（如 Make、Zapier），将提示词模板与文本数据源（如 Excel 中的会议纪要列表）关联，自动生成批量提示词。例如，用 Python 读取 Excel 中的 “会议名称、会议时间、核心议题”，自动填充到提示词模板中，生成 10 份不同会议的提示词，再调用大模型 API 批量生成总结。
定义 “结构化输出格式”，便于后续工具联动
设计提示词时，要求大模型输出 “JSON” 或 “CSV” 格式的总结结果，方便直接导入 Excel、数据库或 Notion。例如，总结会议纪要时，提示词明确 “输出 JSON 格式，包含‘会议名称、任务列表（数组）、风险提示（数组）’字段”，示例：
{

"会议名称": "产品V3.0迭代会议",

"任务列表": [

{

"任务名称": "输出需求文档V2.0",

"责任人": "小李",

"截止时间": "6月10日18:00",

"交付标准": "包含功能清单、用户流程图"

}

],

"风险提示": [

{

"风险内容": "技术开发延期",

"应对措施": "6月20日中期进度检查，预留5天缓冲时间"

}

]

}

生成 JSON 后，可通过脚本自动导入 Notion 数据库，实现 “总结 - 存储 - 查看” 的全流程自动化。
搭建 “总结质量监控机制”，确保批量结果可靠
批量总结时，加入 “随机抽样验证” 环节，用脚本随机抽取 10% 的总结结果，调用大模型进行 “关键信息完整性检查”（如提示词 “检查该总结是否包含‘任务名称、责任人、截止时间’，若缺失请标注”），若合格率低于 90%，则暂停批量处理，优化提示词后重新执行，确保结果质量。