企业官网建设流程全解析

文本概括这个任务，几乎是每个人接触 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_points=4, audience="项目执行人员"): system_prompt = ( "你是一名信息整理助手。你的任务是把输入文本压缩成结构化摘要。" "规则：1) 按'结论/依据/待确认'三部分输出；2) 每部分不超过 2 条，每条不超过 30 字；" "3) 只使用原文出现的信息，禁止推断；4) 原文未涉及的类别写'无'；" "5) 输出语言与输入语言一致。" ) user_prompt = f"读者身份：{audience}\n要点上限：{max_points}\n待概括文本：\n{text}" return client.chat(system=system_prompt, user=user_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 内容。

这套东西没有多高深，核心就是把模糊需求翻译成可检验的约束，然后一次只改一处地往前推。文本概括这个任务看着简单，真正把它做到能上生产，需要的是耐心和记录习惯，而不是什么奇技淫巧。