企业官网建设流程全解析

简介：ChatGPT指令集与角色扮演PDF围绕Prompt工程展开系统讲解，清晰界定Prompt概念及其在对话问答中的核心作用，并分类解析特定指令、指令模板、代理模式、示例模式四种交互策略。针对代理模式，文中附有角色扮演情景应用说明与实用参考清单；指令模板模式则以STAR原则总结工作经历为例，展示如何获得结构化输出。内容结合K12教育、智能客服、智能助手等场景说明优化提问的具体方法，适合刚接触大语言模型、希望提高Prompt设计能力的初学者与教育工作者。这份PDF为单文件文档，整体约1.57MB，可方便在电脑或移动设备上随时打开学习。目前已有1282人浏览学习，是快速上手ChatGPT交互设计的入门资料，既帮助读者理解不同模式核心逻辑，又为撰写结构化指令、模拟角色对话提供直接可参考的范例。

1. 拿到「ChatGPT指令集&角色扮演.pdf」先别急着复制：这份材料到底在解决什么问题

很多人拿到一份 ChatGPT 指令集和角色扮演的 PDF，第一反应是挑几条看起来厉害的提示词复制进对话框，敲下回车，然后发现效果远没有材料里展示的那么神。这不是提示词本身的问题，而是你把它当成了「咒语」，它其实是「工程」。这份 PDF 真正值钱的部分不是那几十条模板，而是藏在模板背后的结构化思路：什么时候该给模型一个身份，什么时候该限定输出格式，什么时候要把几条指令拆开而不是堆在一起。这篇文章会带你把这些东西拆成能直接落地的手段，包括怎么改造一份现成的指令集、怎么设计一个不容易「出戏」的角色卡、参数怎么配合，以及那些让人反复翻车的隐蔽坑。适合正在把 ChatGPT 接入日常工作流、却发现结果时好时坏的开发者和内容从业者。

2. 指令集 PDF 的正确打开方式：先把几十上百条指令拆成三类再谈复用

2.1 用三个标准快速判断一份指令集值不值得花时间

市面上的指令集 PDF 质量参差不齐，有的把几十条提示词堆在一起就敢出版，有的则真的含金量很高。我拿到一份这类材料，不会先逐条读，而是先抓三个特征。

第一，看它有没有「反例说明」。一条好的指令，除了告诉模型要做什么，还会告诉它不要做什么。比如角色扮演类指令里如果写了「不要承认自己是 AI」「不要使用列表式的官腔开场」，说明作者是真的在工程现场调过这条指令，而不是坐在家里凭想象写出来的。如果一个指令只有正面描述、没有边界条件，那它大概率只是半成品。

第二，看它有没有「变量槽位」。真正可复用的指令，不会把具体的任务名称、行业术语、输出语言写死，而是会用「你是{{职业}}领域的专家」这种占位符，标注出哪些位置是需要使用者替换的。没有槽位的指令，换一个场景就失效，你只能跟着它的例子生搬硬套。

第三，看它有没有「输出格式约束」。指令末尾是否指定了输出结构，比如「先给结论，再给理由，最后给行动建议」，或者「用 Markdown 表格输出对比结果」。格式约束直接决定了你能不能把模型输出接到下游流程里，没有格式约束的指令等于让模型自由发挥，稳定性无从谈起。

用这三个标准过滤之后，一份 PDF 里通常只剩下三分之一的内容值得进你的收藏。剩下的不是不能用，而是可迁移性太差，你花力气改造成本高于收益。

2.2 把 PDF 指令拆成「固定骨架」和「可变槽位」：一条角色指令的拆解过程

拿到一份还不错的指令集，下一步就是把它拆开。我习惯把每条指令拆成两部分：固定骨架和可变槽位。固定骨架是那个让模型理解任务本质的句式，可变槽位是每次使用时需要更换的具体内容。

举个例子，假设 PDF 里有一条角色扮演类的指令，原文是「你是一位资深数据分析师，擅长通过异常指标定位业务问题，请结合我给你的数据给出诊断结论」。这条指令里，「你是一位……擅长……」「请结合我给你的数据给出……」是骨架，而「资深数据分析师」「通过异常指标定位业务问题」「诊断结论」是槽位。你可以把骨架抽出来，填进任何职业和任务。

这种拆解用一段小脚本可以做得更高效。PDF 里的指令往往被排版格式弄得很乱，手工识别槽位容易漏，我用下面这段代码快速扫描一份粘贴过来的指令文本，把用双大括号标记的槽位全部提取出来：

import re # 把 PDF 里的指令原文粘贴进这个字符串（注意先去掉 PDF 页眉页脚残留） raw_text = """ 你是{{职业}}领域的专家，拥有{{年资}}年经验。 你擅长{{核心技能}}，请针对用户的问题{{任务描述}}。 回答时先给结论，再给{{支撑材料}}，最后给{{行动建议}}。 """ pattern = re.compile(r"\{\{(.*?)\}\}") slots = pattern.findall(raw_text) for slot in slots: print(f"发现槽位: {slot}")

这段代码做的事很简单：用正则匹配所有{{...}}结构并打印出来。它的真正作用是帮你在拆解时养成一个习惯——从手抄原文转向结构化扫描。你不需要把整份 PDF 都做成这种格式，只需要对自己高频使用的十条左右指令做这个处理。

参数说明：raw_text是你要分析的原始指令，pattern里的正则\{\{(.*?)\}\}用非贪婪匹配提取双大括号之间的内容，findall返回所有匹配项。如果你拿到的 PDF 指令没有用双大括号标记槽位，可以把正则改成r"你是一位[^，。]+"之类能匹配中文短语的模式，先把候选位置扫出来，再人工确认。

拆完槽位之后，我给每一个槽位补一条说明：这个位置填名词还是填动宾短语、有没有默认值、能不能留空。这一步决定了这条指令在下一次使用时你要做多少决策。槽位越少、默认值越多，指令的复现成本越低，团队里其他人也越愿意用它。

2.3 把拆好的指令装进 System Prompt：四段式组装与第一条用户消息的配合

拆解不是终点，最终要落成一次能稳定复现的对话。我组装 System Prompt 时固定用四段式：身份段、任务段、约束段、输出格式段。身份段写角色和立场，任务段写目标，约束段写负面清单和边界条件，输出格式段写结果的呈现结构。

下面这个模板可以直接抄，它把前面拆出来的骨架和槽位重新组合，并且把「示例」从「指令」里剥离开来：

你是一位{{职业}}领域的专家，拥有{{年资}}年相关经验。 你的任务：{{任务描述}}。 必须遵守的约束： 1. 不确定的信息要明确说不知道，禁止编造。 2. 不要用列表式官腔开场，直接进入问题核心。 3. 涉及{{敏感字段}}时只陈述事实，不做主观评价。 输出格式： 1. 先给结论，不超过三句话。 2. 再给判断依据，使用无序列表。 3. 最后给一个可执行的行动建议。 以下内容只是示例，不要照抄示例的句式输出，只参考它的结构。 示例： {{可选示例}}

这个四段式模板是我做角色扮演和任务类指令都通用的底座。为什么要把示例单独拎出来放在末尾并加一句「不要照抄」？因为模型对示例的模仿倾向比对约束的遵守更强，把示例和约束混在一起，它常常会输出示例的复制品而不是按约束生成新内容。这是从多次翻车里得出的血泪经验。

把模板组装好后，第一次调用时不要把完整指令放在用户消息里。System Prompt 放角色和长期约束，用户消息只放当前这一次的具体问题。这样做的优势在于：系统提示在每轮对话里都是优先上下文，而用户消息会随对话累积变得越来越长，如果角色设定放在用户消息里，它会被后续的新消息逐渐「挤出」注意力范围。这一点在长对话里差别尤其明显。

3. 角色扮演的底层逻辑：为什么一句「你是一个资深教师」经常失效

3.1 角色扮演失效的三个隐藏原因：角色卡里缺了哪几层信息

很多人对角色扮演的理解就是「你是一个XX」，然后期望模型瞬间切换人格。实际上，这个指令在模型眼里只是一个「身份标签」，它没有带来任何行为约束。一个能稳定扮演的角色卡，需要包含三层信息：行为边界、知识边界、表达特征。行为边界决定了这个角色什么话能说、什么话不能说；知识边界决定了它知道自己知道什么、不知道什么；表达特征决定了它的用词习惯、句式长短、语气温度。

只给身份标签，就等于让模型自由发挥，它会把标签通话成一种浮夸的「角色腔」，比如突然开始每句话都用感叹号，或者频繁自称本专家。真正让角色立得住的，是那些负面约束和语言细节。举个例子，你要扮演一个谨慎的风险分析师，单写「你是一位风险分析师」没用，要写「你在给出判断时永远先列出不确定因素，措辞里必须保留余地，不轻易使用必然、一定这类词」，这种行为层描述才会让输出发生可感知的变化。

另外还有一个经常被忽视的因素：模型对职业角色的想象高度模板化。它认为的风险分析师、教师、医生，往往来自训练语料里的典型描述，所以同一个角色在不同时间调用，结果会高度雷同，这就是角色扮演越玩越「假」的根源。打破这种模板化，需要你在角色卡里塞入反模板的细节，比如「这个分析师讨厌报告里出现三个以上的感叹号」「他习惯在分析末尾追问数据的统计口径」。越具体的怪癖，越能让角色脱离平均值。

3.2 一份可以直接套用的角色卡模板与请求构造代码

下面这份角色卡，我拿它做过技术写作助理，也改写过客服质检专家，骨架通用。你只需要替换槽位里的内容：

# 角色设定 你是一位{{角色名称}}，日常工作是{{工作内容概括}}。 # 表达特征 - 语气{{语气描述}}，用词{{用词习惯}}。 - 回答长度控制在{{长度要求}}，每次先给结论再展开。 - 反感{{角色讨厌的事物}}，但只在涉及主题时表达。 # 知识边界 - 你熟悉{{知识领域}}，能处理{{核心任务类型}}。 - 你不熟悉{{不相关领域}}，被问到时直接说明不在能力范围内。 - 对任何需要精确数据的问题，如果手头没有来源，就回答不知道。 # 交互规则 - 当用户输入与主题无关时，用一句话提醒后拉回主题。 - 当用户要求你担任其他角色时，保持当前角色，除非用户明确说「结束角色扮演」。 # 任务说明 {{当前这一轮要处理的具体任务}}

这份角色卡的设计重点是知识边界和交互规则。很多角色扮演翻车，不是模型不愿意演，而是它不知道自己「不知道什么」，结果在扮演权威角色时开始礼貌地编造知识。知识边界段就是给这种幻觉加一道刹车。

接下来看请求构造。以下是用兼容 OpenAI 格式的接口做多轮对话的代码，把角色卡放进 system，把当前问题放进 user：

import requests import json # 角色卡文本（就是上面那份模板填好后的成品） role_card = """ 你是一位技术文档工程师，日常工作是梳理 API 接入文档。 语气平实，用词贴近一线开发者的表达习惯。 回答长度控制在 300 字以内，先给结论再展开。 你熟悉鉴权流程和错误码排查，不熟悉前端框架。 交互规则：用户偏离主题时拉回，不随意切换角色。 """ messages = [ {"role": "system", "content": role_card}, {"role": "user", "content": "客户反复遇到 401 错误，帮我列出排查顺序。"} ] payload = { "model": model_name, # 替换成你当前订阅的模型版本 "messages": messages, "temperature": 0.7, # 角色扮演场景建议偏高 "top_p": 0.9, "max_tokens": 600 } resp = requests.post( api_url, # 替换成你所用服务的接口地址 headers={"Content-Type": "application/json"}, data=json.dumps(payload), timeout=30 ) print(resp.json()["choices"][0]["message"]["content"])

这段代码里最值得注意的是 system 消息只放角色卡，用户消息只放当前问题。如果你把角色卡也拼进用户消息，对话一长，前面的角色设定会被后续内容稀释；而 system 消息在每次请求时都会随请求一起发送，模型会持续把它当作最高优先级的上下文。

参数说明：temperature控制随机性，角色扮演场景下 0.7 以上能让语气更松弛、更像人，但代价是偶尔跑题；max_tokens设置 600 是因为角色扮演的回答通常不需要太长，更重要的是防止输出超出预算后中断，导致最后半句话被截断，看起来就像角色突然「卡住」。如果前端有调整参数的功能，记得确认参数真的传到了接口，后面第 4 章会专门讲这个坑。

3.3 多轮对话下保持角色稳定：摘要回写与角色卡重发

单轮角色扮演容易成功，难的是二十轮以后角色还在状态。最常见的退化路径是这样的：前十轮角色还带着设定里的用词习惯，到后来渐渐开始出现「作为人工智能我无法回答」之类的破防句式。这通常不是模型失智，而是上下文里累积的用户消息和助手回复占据了大半窗口，system 里的角色卡在注意力上输给了近在咫尺的最新消息。

我一般会在每次请求前判断一下当前对话的累计 token 数，超过设定阈值就触发一次摘要回写，核心思路是：保留最近几条完整对话，把更早的内容压缩成一段状态摘要，保留其中的关键事实和尚未完成的任务，然后把摘要塞回 system 的末尾。这样既保住了上下文里的重要信息，又给角色卡留出了足够的注意力空间。

实现上不需要复杂的框架，只要在构造 messages 之前多一步判断即可。整理摘要可以用模型自己完成，让另一个没有角色设定的对话会话来总结，再把结果作为一条续写的 system 消息插入。需要注意，摘要不要交给当前这个扮演中的角色自己做，因为它会带着角色的倾向性去歪曲事实。这是实践里容易忽略的细节。

4. 参数怎么配合角色扮演：温度、top_p、频度惩罚的实用设置

4.1 四个主要参数对角色稳定性的影响：一张表看懂职责分工

很多人在角色扮演时只关注提示词，忽略了采样参数对「像不像」的决定性影响。同样一份角色卡，温度 0.2 和温度 1.2 跑出来的结果，一个像严格执行剧本的复读机，一个像喝了两杯咖啡即兴发挥的话痨。下面这张表是我日常调参时用的基准，四个参数各有分工，不要混为一谈。

temperature 和 top_p 经常被当成一回事，实际上它们作用在不同环节。temperature 拉高会让整个概率分布变平缓，低概率词被选中的机会变大，所以温度一高角色说话就更「放飞」；top_p 则是把概率累加超过阈值的候选词之外全部砍掉，它更像一把剪刀，去掉尾巴上那些没必要的生僻词。两者同时调时有一个经验法则：先动 temperature，top_p 只做微调，不要两个一起大幅变动，否则输出会变得不可控。

频度惩罚这两个参数在角色扮演里容易被忽略，但它们决定了长对话里角色会不会开始重复自己。presence_penalty 高的时候，模型更倾向于引入新话题新词汇，适合需要角色不断主动推进剧情的场景；frequency_penalty 高的时候，模型会刻意回避刚刚用过的词，适合需要表达多样性的场景。需要注意，这两个参数调太高会让角色说话变得绕，严重的连主语都开始换来换去。

4.2 按场景推荐的参数组合与「一次只动一个变量」的调参顺序

结合角色扮演的不同使用场景，参数不应该一套打天下。下面三个组合是我实测下来比较稳的起点，你可以在此基础上微调：

调参顺序比参数本身更重要。我的固定流程是：先固定提示词完全不动，只调 temperature，跑三轮对比；然后固定 temperature 再微调 top_p；最后才动惩罚项。一次只动一个变量，否则一旦输出发生变化，你根本不知道是哪个参数引起了漂移。这个原则听起来简单，但绝大多数人调参时都是同时改三个参数，跑一次发现效果变好，却不知道怎么复现——这就是典型的黑匣子式调参，运气好一次成功，运气不好就陷入反复试错。

每轮对比我建议录下完整的原始输出而不只是印象中的「感觉变好了」。因为角色扮演的输出评估很容易被主观感受带偏，你觉得语气更活泼了，可能只是因为这一轮随机到了更短的句子。把输出文本保存下来，做简单的对比，比靠记忆判断靠谱得多。

4.3 参数怎么调都无效：先查三个地方再怀疑模型

如果参数改了又改，角色的表现纹丝不动，问题大概率不在参数本身，而在请求链路。我排查时按下面的顺序走，基本能定位九成的问题。

第一，确认参数真的传到了接口。很多套壳客户端在界面上有 temperature 滑块，但底层代码写死了默认值，你拖动滑块只改了界面状态，根本没有传给服务端。排查办法很简单：直接抓一下实际发出的请求体，看 payload 里 temperature 的值是不是你设置的那个。如果不会抓包，就换一个能显示原始请求的工具，或者干脆直接用代码调接口，绕过界面。

第二，确认模型版本没有悄悄切换。同一个角色卡在旧版本模型和新版本模型上的表现可以差别很大，尤其在对指令的遵循度、对负面约束的理解上。服务商升级模型后，你明明什么都没改，角色却像换了一个人，遇到这种情况先查你实际命中的模型版本，再决定是调整参数还是调整提示词。

第三，确认消息列表里没有其他系统级提示干扰。有些 API 网关会在你的 system 前面自动注入一段安全或行为指令，这段注入对角色扮演影响很大，它会抬高模型对「我是 AI」的自我认知，导致你的角色卡再怎么用力也压不过那句默认设定。排查办法是打印出请求的完整消息列表，看看除了你自己构造的 system 之外还有没有额外内容。

参数排错的核心态度是：先怀疑基础设施，再怀疑提示词，最后怀疑模型。这三个排查方向都不需要太多技术深度，但能帮你省下大量「明明什么都调了就是不行」的无效时间。

5. 角色扮演与指令集应用中的五类常见坑：现象、原因、解决办法

5.1 角色演到一半「出戏」：长对话里角色设定被遗忘

现象：前几轮角色还维持着设定的语气和边界，到了十几轮之后，突然冒出一句「作为 AI 我可以帮你……」这种完全脱离角色的回答。

原因：每次请求时，模型会把整个消息列表作为上下文，而接近对话末尾的消息在注意力机制里权重更高。当用户消息和助手回复越来越长，system 里角色卡的相对位置越来越远，它就被「挤」出了有效注意力范围，导致角色设定失效。

解决：在对话长度达到阈值时，触发上一节讲的摘要回写，把核心角色设定压缩到一两句话里，追加到 system 消息的末尾。另外，我习惯每五轮主动重发一次角色卡的「核心设定」，不需要发全文，只发行为边界和表达特征那两段。这两种做法本质上是同一个思路：让角色卡在上下文窗口里「保持新鲜」。

5.2 角色风格忽好忽坏：温度设置与提示词次序的双重作用

现象：同一个角色卡，早上跑还像模像样，下午再跑语气完全不对，甚至像是换了个模型。

原因：最常见的是客户端在不同时间用了不同的参数默认值。有些工具会在会话标题或用户偏好改变时重设温度，你不会感知到。另一个原因是角色卡和用户消息之间的相对顺序变了，比如某些客户端把最近的用户消息插到了 system 之前，导致模型优先响应用户消息而忽略角色卡。

解决：参数方面，每次请求显式传 temperature，不要依赖默认值。提示词方面，固定角色卡放在 system 第一位，用户消息永远在最后；如果客户端不允许看实际消息顺序，就换用接口方式调用。还要注意模型端更新导致的漂移，这种漂移无法通过调参完全消除，只能定期校准角色卡。

5.3 「角色越生动，内容越敢编」：拟人化带来的幻觉放大效应

现象：一个被设定为「资深行业顾问」的角色，在回答具体数据时面不改色地给出精确到小数点的统计数字，而这些数字完全没有来源。

原因：角色扮演让模型进入了「流畅生成」的模式。生动的角色设定鼓励它像人一样自信作答，而这种自信恰恰会压制它在面对不确定信息时常见的保守倾向，于是编造细节、编造来源、编造数据就变得格外流畅。

解决：在角色卡的知识边界段里强化两条规则。第一条是「当需要精确数据而你没有可靠来源时，直接说明你无法提供这一项，并给出获取该信息的建议渠道」；第二条是「涉及数字时，先声明数据可能不准确，再给出数量级而非精确值」。测试时可以故意问一个非常冷门的数据点，看看角色会不会开始编。如果它编造了，就继续增加约束措辞的强度。

5.4 指令一长模型就开始丢细节：长 System Prompt 的注意力坍缩

现象：把一份 PDF 里抄来的长指令完整贴进 system，角色不但没有变得更聪明，反而连最基础的要求都开始遗漏，比如要求输出的格式突然不遵守了。

原因：System Prompt 过长时，模型会对中段内容产生「注意力坍缩」，首尾的内容获得更高权重，中间段的约束被悄悄忽略。这跟人读长文档时记不住中间段落是一个道理。很多 PDF 指令集为了显得专业，把背景、原理、示例、注意事项全堆在一起，整段超过一两千字，结果最关键的输出格式约束落在了中段，自然被模型跳过。

解决：把长指令拆成短段落，每段加一个明确的前缀标签，比如「身份」「约束」「输出格式」，标签本身就是注意力锚点，能帮助模型定位。把最重要的约束放在最前面或最后面。如果指令确实长，尝试压缩句式，去掉修饰性形容词，只保留动词和宾语。我给自己定了一个经验值：System Prompt 主体在 400 字以内时稳定性最好，超过这个长度就要考虑拆分成多轮指令下发。

5.5 PDF 里抄来的提示词直接失效：排版残留与示例污染

现象：照着 PDF 原文把提示词一字不差地复制进对话框，效果跟文档里展示的完全不同，有的甚至输出一些毫无意义的重复内容。

原因：PDF 排版会在复制时残留大量不可见字符，比如全角引号被转成特殊编码、换行符变成多个空格、制表符错乱。这些残留字符混进提示词后，会干扰模型的指令解析。更隐蔽的原因是，PDF 里的「示例」往往和「指令」连在一起，模型把示例当作执行目标，输出就成了示例的仿写而不是对指令的执行。

解决：复制后先做文本清洗，把全角标点统一成半角，多余空行压缩掉。然后把指令和示例物理分离：指令放在 system 或消息开头，示例放到末尾，加上「以下只是示例，参考其结构而不是内容」这句隔离指令。如果清洗后还是效果不对，手动重新打字输入一遍，排除不可见字符问题。

6. 把静态 PDF 变成自己的指令库：一套可以持续复用的最小工作流

6.1 用「变量卡」维护角色设定，让每次改动都留痕

PDF 里的指令集是静态的，但你的需求是变化的。我用一个 JSON 变量卡来管理拆解后的槽位，每份角色配置对应一个文件，文件里记录所有变量的取值和修改时间。这样角色扮演出现问题时，可以快速回溯是哪一次改动引入的：

{ "role_card_id": "tech_writer_assistant_v3", "base_prompt": "你是一位技术文档工程师，语气平实……", "variables": { "职业": {"value": "技术文档工程师", "last_modified": "2025-01-12"}, "知识领域": {"value": "API 鉴权与错误码排查", "last_modified": "2025-01-12"}, "表达特征": {"value": "先结论，后依据，不超过300字", "last_modified": "2025-01-15"} }, "notes": "2025-01-15 修改表达特征后，回复变短了，但结论更清晰。" }

每次只改一个变量、跑一轮测试、再更新 notes，这个习惯能让你避免「改了三个变量之后效果变差但不知道是哪个改坏的」的窘境。我吃过这个亏：调整了角色卡的语气描述、知识边界和输出长度，结果输出风格变得不伦不类，最后只能靠 git 历史一行行 diff 找出问题。JSON 变量卡加上简短备注，本质上就是给提示词工程加版本管理。

6.2 建一个十条左右的回归测试集，每次改动后跑一遍

角色卡改完之后，除了看一两条即时效果，还要防「按下葫芦浮起瓢」——语气改好了，但知识边界变松了。我维护了一个固定的问题集，覆盖角色扮演的五个维度：语气保持、知识边界、格式遵守、话题拉回、幻觉倾向。每次修改角色卡后，用同一个温度设置把测试集完整跑一遍，记录每个维度有没有漂移。

这个测试集不需要太复杂，每条问题对应某一个维度的极端情况，比如测知识边界就问一个跟角色领域完全无关的问题，测幻觉倾向就问一个极其冷门的精确数据。跑一遍的成本不高，但能让你在改动后十分钟内就知道这次变更是正向的还是负向的。我现在改任何角色设定的第一反应都是先跑测试集，而不是直接跟真人聊天测试——后者太容易因为随机性给出错误判断。

这是我做提示词工程以来养成的最值钱的一个习惯。它不解决所有问题，但能帮你保住已经调好的成果，不至于一次手滑把前面积累的优势全部推翻。希望帮到你。

本文还有配套的精品资源，点击获取