文本概括 Prompt 工程化：约束设计、分块汇总与测试集验收

文本概括这个任务几乎是每个人接触 Prompt 工程时绕不开的第一道坎。它听起来毫无门槛——不就是让大语言模型把长文缩短吗可我在实际项目里见过太多人卡在这里要么概括出来的东西像流水账要么长度死活压不住要么模型自作主张补了一堆原文没有的结论。这篇就把我自己反复打磨文本概括类 Prompt 的整套思路拆开讲从任务边界怎么定、约束条件怎么写、迭代过程怎么记录到长文档分块概括的两次汇总设计再到怎么用一份固定测试集判断一条概括 Prompt 到底合不合格。无论你是刚入门想搞懂 Prompt 的基本写法还是已经在业务里跑着几条概括链路、被各种跑偏结果折腾过下面的内容应该都能直接拿去改。1. 文本概括看着最没技术含量却最容易做砸1.1 为什么我把概括当作 Prompt 入门的第一块试金石刚接触 Prompt 的时候大部分人喜欢先玩创意写作或者角色扮演因为输出好看、反馈即时。但我更建议从文本概括练起原因很朴素概括是一个有标准答案区间的任务你能立刻判断模型做得对不对。写诗你没法说它错但让它把一份三千字的会议记录压成五条要点漏了关键决策、多编了一条不存在的结论一眼就能看出来。这种可验证性对新手极其宝贵它让你在几十次调试里快速建立起对模型行为的直觉什么样的措辞会被忽略什么样的约束会被遵守什么样的指令会引发过度发挥。更深一层的原因是概括是所有下游任务的地基。信息抽取要先定位关键句问答要先判断哪些段落相关报告生成要先压缩素材这些动作的内核都是概括。你把概括这条链路练熟了等于把如何精确控制模型输出的信息密度和范围这件事练熟了后面迁移到别的任务上成本会低很多。我自己带人的经验是能把概括 Prompt 写到可复现、可回归的程度这个人对 Prompt 的理解基本就过关了。还有一点容易被忽略概括任务的失败模式特别丰富。长度失控、信息丢失、事实走样、格式漂移、语言混杂、视角错位几乎每一种 Prompt 层面的问题都会在概括任务里暴露出来。它是天然的试验场。1.2 概括任务的真实边界它到底在替谁省时间在动手写 Prompt 之前我习惯先问一句这份概括是给谁看的他要在多短时间内获取什么。这个问题的答案直接决定了后面所有的约束设计。给一线执行人员看的行动项摘要和给管理层看的决策摘要完全是两种东西。前者要保留具体的负责人、时间节点、依赖条件颗粒度细后者要的是趋势判断和风险提示具体到人的细节反而该砍掉。如果这两种需求你混用一条 Prompt结果一定是两头不讨好。我在一个内部知识库项目里就吃过这个亏。最初我写了一条通用的概括指令希望它能同时服务于检索摘要和人工阅读。跑了两周发现检索场景需要的是这段文字讲了什么主题、涉及哪些实体而人工阅读需要的是这段文字的核心结论是什么。同一条 Prompt 在两个场景下都只能做到六十分。后来拆成两条各自加了明确的受众描述和用途描述效果立刻不一样了。提示写概括 Prompt 前先用一句话写清这份摘要的读者是谁、他拿着这份摘要要做什么决定。这句话建议直接写进 Prompt 里模型对受众描述相当敏感。1.3 一个反直觉的结论概括质量的上限由约束决定不由文采决定新手常犯的一个错误是把精力花在形容词上——请用专业、精炼、流畅的语言概括。这类词对模型来说约等于没说因为它无法量化。真正拉开差距的是可数的、可检验的约束几句话、几个要点、必须包含哪几类信息、禁止出现哪类内容、输出用什么结构。我做过一个很粗糙的对照实验用的是同一批二十份产品反馈记录。A 组 Prompt 是请精炼地概括以下反馈B 组是输出恰好 3 条要点每条不超过 25 字第一条必须是出现频次最高的问题禁止加入原文没有的推测。人工评分时 B 组的可用率明显更高而且更关键的是B 组五次重跑的结果之间差异很小A 组则每次都不一样。可复现性在生产环境里比偶尔出彩重要得多。所以后面几章我会把重点全部放在约束设计上怎么把模糊要求翻译成硬条件怎么让长度、视角、格式这三样东西各自可控。2. 把概括这个动作拆开长度、视角、颗粒度三根调节杆2.1 长度约束怎么写才不是一句空话简短一点尽量精简这类表述模型基本只能靠猜。它猜的依据是训练数据里类似任务的常见长度而这个长度跟你需要的往往差着量级。我见过最多的情况是模型默认输出一段两三百字的连贯文字而你需要的是五十字以内的一句话摘要。可行的做法是把长度写成硬指标并且给出计量单位。比如不超过 40 个汉字恰好 5 条要点每条 15 到 25 字用一个 30 字以内的句子回答。注意一定要指明计量口径说不超过 40 字在中文里可能会被理解成 40 个词或者 40 个字符虽然多数时候模型能理解但加一句按汉字计数更保险。还有一种更稳的写法是给出示例长度。直接告诉模型参考这个长度本季度三条主线均按期推进其中供应链环节存在两周左右的延迟风险。模型对示例长度的对齐能力明显强于对数字的遵守能力。我的经验是数字约束加一条示例长度控制的命中率会有明显提升。需要提醒的是字数约束越紧模型越容易牺牲准确性来凑长度。所以一旦你把长度压到极致最好同时补一句如果信息量不足以填满宁可少写也不要补充原文没有的内容。这句补丁能挡掉相当一部分胡编。2.2 视角决定了你保留什么、丢弃什么同样一段文字从不同视角概括出来的结果可能完全没有交集。所谓视角我一般拆成三个变量主体是谁、关注什么维度、时间粒度多粗。主体这个变量最容易被忽略。一段跨部门协作的复盘文字如果主体设定为项目负责人摘要里会出现资源协调、进度风险如果主体设定为财务摘要里就会出现预算执行和成本偏差。模型的默认行为是尽量均衡地覆盖所有信息这恰恰是概括最忌讳的——均衡等于没有重点。关注维度也需要显式写出来。比如只关注与交付时间相关的信息重点提取用户提到的具体痛点忽略对功能的称赞从合规角度提炼需要留痕的环节。这类指令的本质是给模型一个过滤器让它知道哪些句子该进摘要哪些该丢。时间粒度主要影响长周期文本的概括。一份跨年的经营记录如果要求按季度概括模型会自然地做时间切分如果不指定它很可能把所有信息揉成一个整体结论。我在处理长周期日志类文本时会直接写按时间顺序分三段概括每段对应一个阶段并标注阶段起止。2.3 颗粒度与格式从一句话到结构化字段格式不只是排版问题它实际上是信息颗粒度的外在表现。一句话摘要意味着你必须做全局压缩取舍幅度最大要点列表意味着允许并列多个信息块结构化字段意味着你要求模型对每一类信息单独作答。我常用的几种格式及其适用场景整理成下面这张表方便对照输出格式信息颗粒度适合场景编写时的注意点单句摘要最粗列表页预览、检索结果标题必须限制字数并指明核心结论要点列表中等会议纪要、文档导读限定条数并要求每条独立成句分段概括较细长报告、多章节文档指定分段依据按章节或时间结构化字段最细下游程序消费、入库明确字段名、类型、缺省值问答对特定素材转训练数据要求答案只来源于原文结构化字段这种形式特别值得多说两句。当你需要把概括结果交给程序处理时让它输出带固定键名的结构比输出一段自然语言再写正则去解析要可靠太多。写法上不要只说输出 JSON而是把每个键的含义和取值范围都写清楚再给一个小样例。模型对有样例的结构服从度很高。有个细节结构化输出时一定要约定空值怎么表示。否则遇到原文没提到的字段模型有时会写无有时写未提及有时干脆编一个。统一成固定写法下游解析才不会崩。3. 一条概括 Prompt 的成型过程从裸奔到能上生产3.1 先跑基线看清模型默认会做什么我的习惯是先写一条最朴素的指令什么都不加跑三五条样本把输出记下来。这一步不是为了要结果是为了摸清模型的默认倾向。你会看到它默认多长、默认覆盖哪些信息、默认用什么结构、默认会不会加自己的评论。这一步的价值在于后面的每一条约束都是针对具体问题加的而不是凭想象堆上去的。很多人的 Prompt 写得又长又乱就是因为把所有可能的问题都预防性地写了一遍结果指令之间互相冲突模型无所适从。先看默认行为再精准补丁Prompt 会短很多效果反而更好。我一般会记录四个观察点输出长度分布、信息覆盖偏好偏开头还是偏结尾、是否出现原文没有的内容、格式是否自发统一。这四个点基本决定了后面要加哪几类约束。3.2 一次只改一处把变化记下来Prompt 调试最忌讳一口气改五处然后看结果。你不知道是哪个改动起了作用也不知道哪个改动引入了新问题。我的做法是维护一张很小的实验记录字段包括版本号、本次改动、样本编号、输出摘要、问题标记。改动一行重跑同一批样本对比。举个实际例子。我调一条会议纪要概括 Prompt基线版本输出的是六到八条要点长度偏长。第一个改动只加了一句恰好输出 4 条要点结果条数对了但模型的取舍变得很奇怪把一些次要的寒暄内容提上来了因为它在强行凑四条。第二个改动加了按决策、待办、风险三类组织每类至少一条结果结构清晰了但待办类经常空着模型又开始编造待办。第三个改动加的是若某一类在原文中不存在写无不要推测。三步下来这条 Prompt 才算能用。这个过程听起来慢但每一版改动带来的因果是清晰的最后沉淀下来的规则每一条都有依据。比起反复重写整条 Prompt这种方式更容易积累可复用的经验。3.3 用示例锁定风格比堆形容词管用十倍想让模型输出特定风格最有效的手段是给一到两个示例而不是写一堆形容词。简洁专业这种描述模型理解得很模糊但给一段你认可的摘要作为样例它立刻就能对齐语感、句式长度、专业术语密度。示例的写法有讲究。我一般给输入片段 期望输出的成对样例而且样例要覆盖边界情况。比如你要概括用户反馈样例里最好包含一条信息量很少的反馈展示这种情况下期望的输出是什么样这样模型遇到类似输入时不会硬凑。注意示例的数量不用多两到三个足够。给太多示例会挤占上下文而且容易让模型过度模仿示例的表面形式遇到稍微不同的输入就套模板。还有个小技巧示例放在指令之后、待处理文本之前效果通常比放在最前面好。这样模型读完规则马上看到示范紧接着就处理真实输入上下文连贯性更强。3.4 规则写进系统层变量留给用户层真正上生产的时候我会把 Prompt 拆成两部分。固定不变的部分——角色设定、输出格式、禁止事项、示例——放进系统层每次调用变化的部分——待概括的文本、可选的额外要求——放在用户层。这么拆的好处是规则部分可以被复用和统一维护业务侧调用时只需要传文本不用每次拼一大段指令。而且系统层的指令权重通常更高模型对它的服从度更好能有效压住用户输入里可能出现的干扰。调用层的代码大致长这样接口做抽象处理不绑定具体实现def summarize(client, text, max_points4, audience项目执行人员): system_prompt ( 你是一名信息整理助手。你的任务是把输入文本压缩成结构化摘要。 规则1) 按结论/依据/待确认三部分输出2) 每部分不超过 2 条每条不超过 30 字 3) 只使用原文出现的信息禁止推断4) 原文未涉及的类别写无 5) 输出语言与输入语言一致。 ) user_prompt f读者身份{audience}\n要点上限{max_points}\n待概括文本\n{text} return client.chat(systemsystem_prompt, useruser_prompt)注意最后一条规则输出语言与输入语言一致这是被坑出来的。早期我没写这条遇到中英混排的技术文档模型有时会用英文回有时半中半英下游做关键词匹配时全乱套。4. 我踩过的几个典型坑概括跑偏时的排查链路4.1 长度永远超标从尽量简短到可数约束这是出现频率最高的问题。你写了请简短概括输出还是一片汪洋。排查的时候别急着换模型先看你的约束是否可数。我的排查顺序是这样的第一步检查指令里有没有明确的数字或示例长度如果没有先加上再跑第二步如果有数字但还超标检查数字是不是被其他指令抵消了比如同时写了要覆盖所有要点和不超过三条模型会优先满足覆盖第三步如果约束明确还是压不住把限制提到系统层并且用更强的措辞比如严格限制超出部分视为错误。还有一个隐蔽原因文本本身太碎。如果输入是几十条零散短句模型会倾向于逐条转述而不是真正压缩。这种情况下要显式要求合并同类项把语义相近的内容归并为一条。实测下来最有效的组合是数字约束 长度示例 超限处理说明三者同时给。缺一个命中率都会下降。4.2 关键数字和专有名词被抹掉概括天然是丢信息的过程但有些信息是不能丢的金额、日期、数量、人名、产品代号、条款编号。模型在做压缩时会优先保留语义主干把修饰性的具体数值当成可省略部分这在很多业务场景里是致命的。解决办法是把必须保留清单显式写出来。比如原文中出现的所有日期、金额、百分比必须原样保留不得改写或省略。更稳的做法是要求模型在摘要末尾附一个关键数据小节把这些值单独列出来。这样即使正文摘要里丢了你还能从附录里捞回来。我在处理合同类文本时还加了一条数字与单位必须成对出现因为遇到过模型把三十个工作日概括成一个月的情况。语义上接近但法律含义完全不同。4.3 模型开始脑补原文没有的结论概括任务里的臆造通常不是凭空捏造而是合理推断。模型看到交付延迟两周和客户提出书面质询很自然地总结出客户对交付能力产生质疑。这个结论大概率对但原文没写一旦这份摘要进了正式文档就是风险。压制臆造有几个层次的办法。最轻的是加一句只使用原文明确陈述的信息禁止推断和补充。中等强度是要求模型对每条摘要标注原文依据哪怕是简短引用几个词。最强的是要求输出结构化结果每条摘要带一个原文片段字段你在程序侧做一次包含校验。我一般用中等强度因为标注依据会让输出变长但换来的是可追溯性。在需要严格合规的场景我会直接上第三层。4.4 多语言混输与格式漂移格式漂移指的是你要求输出要点列表结果模型给你一段连续文字你要求 JSON它给你包了一层说明文字再加 JSON。这类问题在长 Prompt 里特别容易发生因为约束太多模型顾此失彼。排查思路是先做减法把非必要约束去掉看格式是否恢复。如果恢复了说明是约束冲突如果没恢复把格式要求单独拎出来做成一条独立指令放在最后并且加一句直接输出结果不要添加任何解释性文字。多语言混输的处理更简单明确写输出语言与输入语言一致再补一句专有名词保留原文写法。症状最可能的原因第一手处理长度反复超标约束不可数或与覆盖要求冲突加数字、示例、超限说明数字丢失缺保留清单显式列出必留字段出现原文没有的结论未禁止推断加禁令并要求标注依据格式漂移约束过多互相干扰精简约束格式要求独立成条中英混杂未指定输出语言显式约定语言规则这张表我贴在工作笔记里很久了遇到问题先对照一遍能省掉不少试错时间。很多时候不是模型不行是 Prompt 里存在我们没意识到的内部矛盾。5. 长文档概括分块、递归与信息对齐5.1 为什么不建议硬塞进一次调用长文档概括最直觉的做法是把全文塞进去一次问完。文本不长的时候这确实可行但一旦超过一定规模问题就来了中间部分的信息容易被忽略越靠后的段落权重越低而且输出的摘要往往会严重偏向文档开头的内容。我做过分段对照同一份长材料一次性概括和分块概括的结果覆盖度差别很明显。一次性概括时文档后半部分的内容在摘要里的出现率明显偏低。这不是模型的缺陷是长上下文处理的普遍特性——注意力分布不均匀。所以我的做法是超过一定长度的文本一律走分块路线。分块本身也有讲究不要按固定字数硬切要按语义边界切章节标题、段落空行、编号条目这些天然的分隔点优先。硬切容易把一个完整论述劈成两半两块各自概括出来都是残缺的。5.2 分块概括的两次汇总分块之后不是简单拼接那样得到的是一堆平行碎片没有整体结构。我的标准流程是两步。第一步逐块概括。每块单独调用输出统一格式的中间结果比如本块主题 3 条要点 关键数据。这一步的 Prompt 要保证所有块完全一致否则后面没法合并。第二步对中间结果做二次概括。把所有块的中间结果拼起来再跑一次概括这次的任务是提炼跨块的主线和结论。第二次概括的 Prompt 和第一次不一样它需要的是归纳共性、识别演进脉络、找出前后矛盾而不是简单地再压一遍。有时候中间结果本身还是很长那就再来一轮形成递归。一般两轮足够三轮以上收益递减明显而且每一轮都会损失细节。分块还有个隐形成本块与块之间的指代会断。第二块开头写该方案你不知道指的是第一块里的哪个方案。处理办法是在每块的输入前面附上上一块结尾的 100 字给模型一点上下文衔接。这个技巧很土但效果实打实。5.3 跨块实体与数字的对齐检查分块概括最容易出的错是同一个实体在不同块里被写成不同名字或者同一个数字在不同块里出现不同值。比如第一块写某平台V2版第二块写新版系统合并之后读者以为是两个东西。我的处理办法是在二次概括的指令里明确要求统一实体称谓若同一对象在不同片段中出现不同表述合并为一个并说明。同时我在程序侧加了一层简单校验把各块中间结果里的数字全部抽出来比对是否存在同一指标的冲突值。有冲突就人工介入不交给模型自己判断。这套流程跑下来长文档概括的可用率比一次性塞入要高出一大截代价是多几次调用和一点工程代码。对于需要长期跑的链路这个投入完全值得。6. 怎么判断一条概括 Prompt 算合格一份可复用的验收清单6.1 三个维度忠实、覆盖、可读我评价一条概括 Prompt只看三件事。忠实度指的是摘要里的每一条信息都能在原文找到依据没有推断、没有臆造、数字和专有名词没有走样。这是底线不达标其他都免谈。覆盖度指的是原文的关键信息有没有被漏掉。这里的关键信息需要你事先定义通常是决策、数据、风险、待办这几类。覆盖度不足的典型表现是摘要读起来通顺但读完你还是不知道结论是什么。可读性指的是摘要本身作为一个独立文本能不能被直接使用。有些摘要信息是全的但句子之间没有逻辑连接读起来像关键词堆砌这种在下游使用时还得人工重写一遍等于没省时间。三个维度里忠实度优先于覆盖度覆盖度优先于可读性。这个优先级很重要因为它们在 Prompt 层面经常是互相拉扯的压长度会伤覆盖加约束会伤可读。知道哪个可以让步调试时就不会纠结。6.2 用固定测试集做回归Prompt 改一版就跑一批固定样本这是我坚持最久的一个习惯。测试集不用大十五到二十条就够但必须覆盖几类典型输入信息密集的长文本、信息稀疏的短文本、含大量数字的文本、中英混排的文本、结构混乱的口语化文本。每次改动后重跑全部样本把输出存下来做对比。你会发现很多改动是按下葫芦浮起瓢——修好了长文本短文本又出问题。有固定测试集这种副作用立刻就能发现没有的话往往要等上线后由用户反馈才发现。测试集的维护也有讲究。线上遇到新的失败案例脱敏之后补充进测试集它会越用越值钱。我手上那套样本已经从最初的十几条涨到六十多条基本覆盖了业务里能遇到的所有文本形态。6.3 别忽略调用层的隐性影响最后一件事很多人排查了半天 Prompt问题其实在调用参数上。采样温度的设置对概括任务影响很大温度偏高时模型更愿意做创造性的改写容易出现原文没有的表述温度偏低时输出更贴原文但可能过于机械地复制句子。概括类任务我一般会把随机性调到较低档牺牲一点表达的灵动换取结果的一致性。同一份文本跑五次输出差异越小越好因为下游往往要做缓存和比对每次都不同会很麻烦。还有输出长度上限这个参数如果设得太小模型会在句子中途被截断看起来像是概括没写完。这个坑我踩过一次排查了两小时才发现是参数问题而不是 Prompt 问题。所以排查顺序上我现在的习惯是先确认调用参数再看 Prompt 内容。这套东西没有多高深核心就是把模糊需求翻译成可检验的约束然后一次只改一处地往前推。文本概括这个任务看着简单真正把它做到能上生产需要的是耐心和记录习惯而不是什么奇技淫巧。