大模型使用手册三版本拆解：提示词与实战流程避坑指南

一份大模型使用手册在群里转了三天，我留意了一下：收藏的人不少，真正从第一页翻到最后一页的，据我观察不超过五个。这次流传出来的三个版本——入门篇、进阶篇、实战篇，加起来上百页，内容其实相当扎实，但绝大多数人卡在同一个地方：不知道该先看哪本，也不知道三本之间到底差在哪，于是干脆全存进收藏夹，然后再也没打开过。我把这三个版本从头到尾过了一遍，顺手在实际项目里验证了里面大部分方法，也发现了不少手册没写、但用起来一定会撞上的坑。这篇就把三份手册的骨架拆开给你看：它们各自解决什么问题、哪些内容可以直接抄作业、哪些地方需要按自己的场景改，以及我在真实工作流里踩过的那些坑。适合刚接触大模型、想系统上手的人，也适合已经在用、但输出质量一直不稳定、想把提示词和流程管起来的人。核心关键词就三个：大模型使用手册、提示词、三个版本，下面全围绕这三样展开。

1. 三个版本先看清定位，再决定从哪本翻起

拿到一套多版本的手册，最忌讳的是从第一页硬啃。这三份材料的组织逻辑其实非常清晰，分别对应"知道它能干什么""让它干得准""让它干得快且可复用"三个阶段。你要是跳过前两本直接抄实战篇的流程模板，大概率会得到一堆看起来很美、跑起来全是错的配置。下面我按自己的理解把三本的定位重新标一遍，顺便说说哪些章节值得精读、哪些可以快速翻过。

1.1 入门篇解决的是"预期管理"，不是"操作教学"

很多人以为入门篇是教你怎么点按钮，其实不是。这一版真正的价值在于把大模型从"玄学"拉回"工具"的位置：它会告诉你这个模型的训练数据截止在什么时间、上下文能吃多长、哪些任务它天生不擅长、哪些看起来很难的事它反而做得不错。这些认知如果一开始没建立起来，后面所有的提示词技巧都是在给一个错误的前提打补丁。我见过最常见的翻车场景，就是有人拿它当搜索引擎用，问一个昨天刚发生的事，得到一段编得很像样的答案，然后照着去汇报。问题不在模型，在于使用者对"知识截止"这件事毫无概念。

入门篇里我建议精读的是"能力边界"和"输入输出规格"这两块，尤其是上下文长度的实际含义。手册里通常会给一个 token 数，但不会告诉你中文的换算关系。按常见分词器估，一个汉字大约对应 1 到 1.5 个 token，取保守值 1.5 来算，标称 64K 上下文的模型，实际能塞进去的中文正文大概在 4 万字上下，还得扣掉你提问和它回答所占的部分。这个换算我建议你自己动手算一遍，算完你对"能一次喂多少文档"就有了直觉，不会再出现把一整本几十万字的资料直接丢进去、结果只被读到开头几章的情况。

1.2 进阶篇的核心不是"话术"，是需求说明书的写法

进阶篇讲提示词，这是三个版本里被误解最深的一本。市面上很多教程把提示词包装成咒语，好像加一句"请一步一步思考"就能质变。实际用下来，提示词的本质是把一个模糊的人类需求，翻译成机器能无歧义执行的工单。你写需求给一个刚入职的实习生，会写清楚背景、目标、交付物格式、不能碰的红线；写提示词是同一件事，只不过对方不会反问你"您说的这个是什么意思"。

所以进阶篇里真正有用的部分，是那些强调"结构化"的章节：把角色、任务、约束、输出格式拆成四块分别写，而不是揉成一大段话。我自己在项目里把这套骨架固定下来之后，同一个任务的输出稳定性提升非常明显，尤其是需要机器解析结果的场景，格式错误率从经常要人工返工，降到了偶尔才需要修一次。手册里那些具体的措辞范例可以背，但更值得学的是它为什么这么组织——这个逻辑我在第 3 节会展开。

1.3 实战篇讲的是流水线，前提是你已经有稳定的单步

实战篇是这三本里门槛最高的，因为它默认你已经能稳定地让模型完成单个步骤，现在要解决的是"一件事需要十几步、每步输出还要接下一步"的问题。它涉及任务拆分、长文档处理、外部知识接入、结果验收这些工程化的话题。如果你连单次提问都还没调稳，直接看这本会觉得每一步都很对、合起来就是跑不通。

我自己的经验是，实战篇适合在完成三到五个真实的小任务之后再回头读。那时候你手里有失败的案例，看它讲"为什么要做结果校验""为什么要把任务切成原子步骤"，才会有共鸣。空着手读，那些流程图像是别人的项目管理经验，跟你没什么关系。这一版的精读重点是"分块策略"和"验收标准"两节，前者决定你能不能处理超出上下文的长材料，后者决定你的产出能不能直接交给下游使用。

2. 入门篇拆解：新手最容易卡住的四个认知关口

把入门篇压缩一下，我认为真正决定后面顺不顺的，就四个关口：能力边界、上下文与记忆、幻觉、参数。这四个东西没搞明白，提示词写得再漂亮也只是撞运气。下面逐个说，每个都带上我自己的实测数据和判断标准。

2.1 能力边界：画一张自己的"能用/别用"清单

几乎所有手册都会列能力清单，但列完之后你还是要结合自己的业务重新画一遍。我的做法是拿一张纸分两列，左边写"这类任务我愿意交给它做第一稿"，右边写"这类任务它只能做辅助、最终必须人来看"。左边我放了：格式转换、信息抽取、提纲扩写、代码片段生成、文档摘要、多语言初翻。右边我放了：涉及具体数字的财务测算、需要引用确切来源的事实陈述、涉及对外承诺的文案定稿、任何要签字负责的判断。

这个划分不是拍脑袋，是有依据的。模型擅长的是"在已有模式上做变换"，不擅长的是"对不确定的事实负责"。你让它把一段会议记录整理成结构化纪要，它是在做变换，出错你一眼能看出来；你让它告诉你某个指标去年是多少，它是在做事实陈述，错了还编得很像，你反而看不出来。这张清单我建议每接一个新类型的任务就更新一次，用不了几次你就会形成直觉，知道什么该给、什么不该给。

2.2 上下文窗口的真相：它没有记忆，只有一次性输入

这是入门篇里最容易被跳过、但后果最严重的一节。很多人把模型当成一个有记忆的助手，聊了二十轮之后觉得"它应该记得我前面说过什么"。真相是：每一轮对话，系统都会把之前的完整历史重新拼进输入里再发一次。所以它会"记得"，是因为历史一直在被重复提交；它一旦"忘记"，通常是因为历史太长被截断，或者中间某段被压缩掉了。

理解这件事之后，两个实际问题就有解了。第一个是长对话后期质量下滑——不是模型变笨了，是早期的关键信息被挤出了窗口。解决办法是把关键约束在每轮开头重述一遍，别指望它一直记着。第二个是成本——历史越长，每次请求要处理的输入越多，开销越大。我的习惯是一个话题聊到一个阶段就新开一轮，把上一阶段的结论手动摘要成三五条带过去，比拖着几百轮的历史划算得多，输出质量也更稳。

2.3 幻觉不是bug，是它的工作原理决定的

新手最容易愤怒的一点是"它明明不知道，为什么要编"。答案很简单：它的训练目标是根据上文生成最可能的下文，而不是"不确定就说不确定"。在训练数据覆盖充分的领域，最可能的下文往往是对的；在覆盖稀疏的地方，最可能的下文就变成了"看起来最像真的"的编造。所以幻觉不是偶发故障，是这套机制在信息不足时的默认行为。

低成本的校验方法我常用三个。一是要求它给出依据位置，比如"引用原文中的哪一句支持这个结论"，能引出来的可信度高一档，引不出来或者引的位置对不上的直接判为可疑。二是交叉提问，同一个事实换个问法再问一次，两次答案不一致就说明这个点它没把握。三是把关键事实丢回给它做判断题，而不是问答题——"这段话里的年份和原文一致吗"比"这段话说的是哪一年"更容易暴露问题。这三个方法都不需要外部工具，纯靠对话就能做，日常够用了。

2.4 参数调节：温度不是越高越有创意

入门篇通常会简单带过几个参数，但实际调起来差别很大。我把常用参数整理成一张表，附上我的经验取值，你可以直接拿去当起点，再按任务微调。

这里有个细节值得说：温度和 top_p 一般不建议同时大改，两个都在控制随机性，一起调会让结果变得难以归因——你压根不知道是哪一项起了作用。我的做法是固定 top_p 不动，只调温度，一次只改一个变量，改完跑同一批测试输入看结果差异。这套"单变量对照"的思路看着笨，但省下来的时间远比多试几次多。另外提醒一句，温度调到 0 也不等于完全确定性，不同批次调用之间仍可能有细微差别，凡是对结果一致性要求高的场景，别指望靠参数解决，要靠输出校验和格式约束。

3. 进阶篇拆解：把提示词写成一份能落地的工单

进阶篇的方法论我认为是对的，但它给的例子偏通用，直接抄到具体业务上常常水土不服。这一节我把它那套骨架翻译成我自己在用的版本，并且补上几个手册里没讲透的点：角色设定为什么经常失效、示例该怎么挑、格式约束怎么写成机器能校验的样子。

3.1 四段式骨架：角色、任务、约束、输出格式

我把提示词固定成四块，顺序也固定，这样排查问题时能快速定位是哪一块出了问题。第一块是角色与背景，一句话交代"你在这个任务里扮演什么、服务对象是谁、背景信息有哪些"。第二块是任务，用动词开头，一句话说清要产出什么。第三块是约束，把所有"不要做什么""必须满足什么"列清楚。第四块是输出格式，明确到字段名、层级、长度上限。

举个具体的：做合同条款摘要，我的提示词是这样组织的。角色背景是"你是法务助理，服务对象是不懂法律的业务同事"。任务是"从下面这段条款中提取义务方、义务内容、触发条件、违约后果四项"。约束是"只依据原文，不补充推测；原文没有的项写'未约定'，不要留空；金额和时间必须原样保留，不做换算"。输出格式是"按四项分条输出，每条不超过 40 字，不使用编号以外的符号"。这四块写完整，输出基本就能直接贴进表格里，不需要我再手工整理一遍。

3.2 角色设定为什么经常失效

手册里都讲"给模型设定角色"，但很多人设了没效果，原因有两个。第一个是角色和任务不匹配——你设一个"资深文案"的角色，却让它做数据核对，角色提供不了任何额外信息，反而可能让它更倾向于写得漂亮而不是写得准确。第二个是角色写得太空，"你是一个专业的助手"这种话不携带任何约束，等于没写。

有效的角色设定要能改变输出的取舍。比如"你是审核岗，职责是找出问题而不是润色"——这句话会显著提高它挑错的倾向；再比如"你是给非技术读者写说明的人，遇到术语必须先解释再用"——这会直接改变用词风格。判断一个角色设定有没有用，我的标准是：删掉这句话，输出会不会明显变化？不会变就删掉，省下的 token 留给约束部分更值。

3.3 少样本示例：挑对比挑多重要得多

给例子是最有效的手段之一，但大多数人给例子的方式是错的——随手贴两个正确案例，期待它学会规律。真正决定效果的是例子的分布：你给的例子要覆盖你会遇到的边界情况，尤其是那些"看起来像但处理方式不同"的案例。

我做信息抽取时踩过一个典型的坑。任务是从一段描述里抽出"主体"和"动作"，我给了五个例子，全都是标准的主谓结构，模型学得很好。结果上线后遇到一句"如果条件满足，由甲方负责后续跟进"，它把"甲方"抽成了主体，而正确结果应该是"条件满足"作为触发前提单独标注。问题出在我的例子里从来没有出现过条件句。后来我把示例改成三个正例加两个"含条件、需要特殊标注"的对比例，这类错误就消失了。所以挑示例的原则是：先想清楚你在真实数据里遇到过哪几类难例，每类挑一个放进去，比堆十个同类正例有用。

3.4 输出格式约束：写成能被程序解析的样子

只要下游要接程序处理，格式约束就必须写到"机器能校验"的程度，而不只是"人看着舒服"。最省事的做法是直接要求输出 JSON，并在提示词里给出字段结构和类型，甚至给一个空模板让它填。下面这段是我常用的写法，字段名用下划线，类型标清楚，枚举值列全。

prompt = """ 从下面的文本中抽取信息，严格按以下 JSON 结构输出，不要输出任何解释性文字， 不要使用 markdown 代码块包裹，字段缺失时填 null，不要省略字段。 { "party": "责任主体名称，字符串", "action": "需要执行的动作，字符串", "deadline": "截止时间，字符串，原文没有则 null", "risk_level": "风险等级，只能是 high / medium / low 三者之一" } 文本： {text} """

配套的解析代码也要做好容错，因为即使约束写得再死，偶尔还是会多出一句"好的，以下是结果"。我的处理是先做一次大括号匹配截取，失败再退回正则提取，最后才抛出异常。这一段看着琐碎，但它是把"模型输出"变成"程序输入"的关键一环，少了它，整个自动化流程就会因为一次格式跑偏而中断。

import json, re def parse_output(raw: str) -> dict: raw = raw.strip() # 第一层：直接解析 try: return json.loads(raw) except json.JSONDecodeError: pass # 第二层：截取第一个完整的 JSON 对象 start = raw.find("{") end = raw.rfind("}") if start != -1 and end > start: try: return json.loads(raw[start:end + 1]) except json.JSONDecodeError: pass # 第三层：兜底，返回带原始文本的结构，交给人工复核 return {"_parse_error": True, "_raw": raw}

4. 实战篇拆解：把单次对话拼成可复用的流程

单次提问能解决的事其实很有限，真实工作里的大部分任务都需要多步：先理解材料，再抽取要点，再组织成文，最后校验。实战篇讲的就是怎么把这些步骤串起来，同时保证每一步的产出都是下一步能吃的。这一节我按"拆分—喂料—接知识—验收"四条线来说。

4.1 任务拆分：按"输出物"切，不按"动作"切

拆分最容易犯的错是按动词切：先总结、再分析、再写结论。这样切出来的步骤之间耦合太紧，前一步的输出很难直接被后一步消费。我现在的切法是按输出物切——每一步都产出一个明确的、可以落盘的东西：一份要点清单、一张字段表、一段带标注的原文片段。上一步的产物就是下一步的输入文件。

拿"把一份几十页的材料变成一份汇报稿"举例。我切成四步：第一步产出章节标题清单（输出物是列表）；第二步按章节产出每章的三条要点（输出物是结构化表）；第三步把要点扩写成段落（输出物是带小标题的正文）；第四步做事实校验，逐条比对段落里的数字和原文（输出物是问题清单）。每一步都可以单独重跑，某一步结果不满意不用从头再来，这在实践中省的时间非常可观。

4.2 长文档处理：分块、重叠、摘要链

材料超出上下文窗口是常态，处理方式就是分块。分块本身不难，难的是块与块之间的信息衔接。我的参数是这样定的：每块正文控制在 800 到 1200 字，块间重叠 100 到 150 字。重叠的作用是让跨块的句子至少在一块的完整上下文里出现过一次，避免一句话被从中间切断导致抽取错误。块太小会让模型缺少上下文、判断失准，块太大则一旦出错整块都要重跑，中间值比较稳。

分完之后走"摘要链"：先对每块单独产出要点，再把所有要点汇总成一份总览，最后基于总览去回答具体问题。这样做的原因是，直接问一个跨越全文的问题，模型只能看到被截断的部分；而先摘要后汇总，等于把全文信息压缩进了窗口。下面这段是我常用的分块逻辑，按段落边界切，不硬切句子。

def split_by_paragraph(text: str, max_len: int = 1000, overlap: int = 120): paras = [p.strip() for p in text.split("\n") if p.strip()] chunks, buf = [], "" for p in paras: if len(buf) + len(p) + 1 <= max_len: buf = (buf + "\n" + p).strip() else: if buf: chunks.append(buf) # 保留尾部若干字作为重叠部分 tail = buf[-overlap:] if overlap and buf else "" buf = (tail + "\n" + p).strip() if buf: chunks.append(buf) return chunks

这里有个坑要提前说：重叠部分会在摘要时被重复计算两次，导致某些要点在最终汇总里权重偏高。解决办法是在汇总阶段明确要求"相同要点合并为一条，标注出现次数"，把它从缺陷变成一种信号——出现次数多的，往往确实是重点。

4.3 接一点外部知识：极简检索的落地方式

模型不知道的东西，靠提示词是问不出来的，只能喂给它。最简单的做法是把相关资料切片、向量化、存起来，提问时先检索再拼进提示词。这套东西听起来复杂，实际最小可用版本很小：文档量在几百到几千片时，用一个本地向量库就够，不必上分布式方案。

具体参数上，切片大小我一般取 300 到 500 字，比长文档分块要小，因为检索需要的是语义聚焦；检索时取相似度最高的 3 到 5 片，太少容易漏，太多会把窗口塞满并且引入噪声。拼进提示词时一定要加一句约束："仅根据以下资料回答，资料中没有的内容明确说明无法回答"。不加这句，模型会习惯性地用自身知识补全，检索就白做了。这套流程的实际效果，我测下来在"有明确答案且答案集中在一两片资料里"的问题上很稳，在"需要跨多片综合推理"的问题上就弱一些，这个预期要提前建立。

4.4 验收标准：先定"什么算能用"，再谈优化

实战篇里我最认同的一句话是，没有验收标准就没有优化方向。每类任务的验收标准应该在动手之前就写下来，而不是跑完之后凭感觉说"还行"。我的标准分三层：硬性格式是否合规（能不能被程序解析）、事实是否可追溯（关键结论能不能在原材料里找到出处）、表达是否达标（长度、语气、术语是否合适）。

三层里最先保证的是第一层，因为它是自动化的前提；第二层靠抽样人工核对，抽 10% 到 20% 就够，重点看数字、时间、专有名词这类硬信息；第三层最主观，通常靠给几个正反例来对齐。实操中我发现，绝大多数"效果不好"的抱怨，拆开看都落在第一层——格式不稳定导致后面全乱，而不是模型能力不够。所以优化顺序永远是先修格式，再看事实，最后才调表达。

5. 三个版本都没写透的几个坑

手册写得再全，也覆盖不了实际使用中的琐碎问题。这一节是我自己踩过和看别人踩过的，整理成速查表加几条经验，都是文档里不会写、但真上手一定会遇到的东西。

5.1 常见问题速查表

5.2 提示词也要做版本管理

这条经验来自一次很尴尬的返工。我当时给一个任务调提示词，前后改了十几版，每版都直接在对话框里覆写，改到满意的那一版忘了存，第二天想回退到三天前的某个版本，发现已经找不回来了，只能凭记忆重写，结果还不如之前那版。从那以后我把提示词当代码管：每一版存成独立文件，文件名带上编号和一句话说明，比如extract_v03_加空值处理.md。

再进一步，我会在文件头写三行注释：这一版解决了什么问题、相比上一版改了什么、在什么测试集上验证过。这三行看着多余，但过两周再回来看，能省掉大量的回忆成本。如果团队里多人协作，把这个目录放进版本管理工具里，谁改的、改了什么、为什么改，一目了然。这件事对个人用户同样成立，但凡一个提示词你要反复用超过五次，就值得建个文件存起来。

5.3 团队推广时真正卡住的地方

手册传开之后，经常有团队想把它变成内部规范。根据我见过的几次尝试，卡点通常不在技术，而在两件事。第一件是预期没对齐：有人期待接入后效率翻倍，结果发现前期要花时间调提示词、定验收标准，短期反而更慢，于是很快失去耐心。第二件是没人负责维护：提示词和流程是会随业务变化而失效的，如果没人定期回头看，三个月后就没人敢用了。

比较务实的做法是先选一个边界清晰、重复度高的小任务做样板，比如固定格式的信息整理或者常规材料的初稿，跑通之后把提示词、验收标准、常见错误整理成一页说明，再往外推。样板的价值在于它证明"这套方法在具体场景里确实省时间"，比讲十遍原理都管用。另外一定要留一个人做维护，哪怕只是每季度花半天时间跑一遍回归测试，也比完全没人管强。

我自己在这套手册上花的时间，前两周基本都在改提示词和建验收标准，真正感觉到顺手是在第三个任务之后。那个时候我不再需要对着文档一条条抄，而是形成了自己的一套起手式：先想清楚输出物长什么样，再倒推需要哪些输入，最后才动笔写提示词。这个顺序反过来，往往写出一大段漂亮但跑不通的东西。