简介：这份PDF围绕ChatGPT角色扮演能力，系统整理出面向学术、创意、商业、技术、教育与咨询等场景的实用指令体系，适合希望借助AI提升写作、翻译、编程与内容产出效率的职场人士、研究人员和学生。文中将常见需求归纳为20多大类，每类给出角色定义与调用思路，涵盖学术论文写作与校对、小说剧本创作、商业计划与广告文案、SEO优化、数据分析、技术文档编写、培训材料制作、简历与个人陈述撰写等方向；除常规应用外，还收录了英文润色、中英互译、英英词典解释、前端开发思路、产品经理PRD、面试官模拟及Linux终端模拟等进阶提示词。资源仅含1个PDF文档，压缩包大小约797KB，轻量易保存，可随时按分类索引查阅。目前已有286人学习下载，说明其覆盖场景具备较强通用性。读者拿到后可直接参考其中的角色设定与示例，结合自身任务修改关键词，快速构建属于自己的ChatGPT工作流，节省重复摸索时间。
1. ChatGPT 角色扮演：看起来是陪聊，实际是上下文工程
有一次，我需要一个刺头客户角色的对话样本来测试新客服话术。用 ChatGPT 角色扮演看起来是让它聊一段，实际操作完全不是“你扮演一个客户”这么简单：前五轮有模有样，第六轮它突然开始给我科普投诉处理流程。这种出戏不是偶然，而是默认状态。ChatGPT 角色扮演的本质是上下文工程：把身份、知识边界、表达风格锁死在 System Prompt、示例对话和采样参数里，让模型在人设框架内稳定输出。它支撑的不只是陪聊，而是智能客服话术演练、NPC 对白生成和业务对话数据模拟。适合做提示词工程、对话系统和模拟训练的工程师、产品经理，也适合需要批量造数据的数据团队。下面所有内容围绕一个目标：让角色演完、演稳、还接得住业务。
2. 人设不是一句“你是XX”：把角色焊进 System Prompt
2.1 角色三层信息：身份、世界观、表达风格
“你是售前客服”这样的设置为什么容易翻车？因为“客服”这个词在模型训练语料里激活的范围太宽，银行客服、电商客服、电话客服全混在一起，模型只能给你一个“平均客服”的样子。要让角色立得住，得把一句话拆成三层。
第一层是身份。不要只给职业名，要给职业锚点：姓名、资历、所属场景。例如“你是某汽车品牌4S店的十年售后主管陈默”，这句话提供的信息密度是一句“你是4S店售后主管”的三倍。模型对具体的人、具体的工龄，比对抽象的职业名更容易画出稳定画像。
第二层是世界观。世界观不是让角色背诵设定，而是给它可推理的上下文。比如这家店主营燃油车和混动车，客户多为30到50岁家庭用户，这条信息会在角色回答维修建议时自动限制推荐范围。世界观就是角色的知识边界，写清楚它，角色就不会在聊车的时候突然扯到房子装修。
第三层是表达风格。语气词、句式、口头禅得写进设定里，而且要具体：“先给结论再给理由”比“说话干练”管用得多。另外要写清风格背后不能越界的事，很多角色扮演崩掉，就是崩在模型开始用书面正式语回答日常问题。还有一个常见误用：把角色设定塞进每轮 user 消息里。这样做 system 不变，user 里的设定只影响当前一轮，下一轮就丢了，所以角色卡必须放在 system 字段，在每次请求里都完整带上。
2.2 可直接复制的角色卡模板
把三层信息结构化之后，我一般存成一张角色卡，放在 System Prompt 的最前面。下面这个模板可以直接复制用，代码逻辑是把四类信息拼接起来，末尾加一句强制约束：
# 角色卡：四段式结构，建议按这个顺序排列 role_config = { "identity": "你叫陈默，是某汽车品牌4S店的十年售后主管。", "worldview": "门店主营燃油车和混动车，客户多为30-50岁家庭用户；你信奉以养代修，不主动推销大额维修项目。", "style": "说话简短，先给结论再给理由；常使用'兄弟''说实话'这类口头语；不用书面缩写。", "boundary": "不谈论其他品牌的价格，不承诺折扣；不确定的事答复'我查一下系统再答复你'。", } def build_system_prompt(cfg: dict) -> str: return "\n".join([ f"[身份] {cfg['identity']}", f"[世界观] {cfg['worldview']}", f"[表达风格] {cfg['style']}", f"[边界] {cfg['boundary']}", ]) + "\n始终以这个角色的身份回答问题，不要跳出角色。" print(build_system_prompt(role_config))这段代码的核心在拼接顺序：身份在最前，边界在最后。越靠前的信息在长上下文里越不容易被淹没，边界放在末尾是为了在最终输出前给模型一次“收着答”的机会。末尾那句“始终以角色身份回答”不是废话，它相当于一个角色保持的锚点。
参数方面有几个调整方向。worldview 里业务范围写得越窄，模型越不容易越界；style 一项宁可多写口头语，也不要写空泛形容词，比如“干练”“幽默”这类词对模型几乎没用；boundary 要写遇到具体情况时该做什么，而不是只写“不要做什么”，例如“不确定的事查系统”就比“不能承诺折扣”更容易被执行。另外不要用一堆“你很幽默”“你很贴心”堆人设，模型需要的是行为描述，不是人格标签。
2.3 三条示例对话压住输出格式
角色卡定义了方向和边界，但同一张卡仍可能生成两种完全不同的语体：一种是“兄弟，刹车油该换了”，另一种是“建议您根据保养手册定期更换刹车油”。模型到底采用哪种，常常不是看你写了什么设定，而是看它在上下文里看到了什么示例。常见做法是用 few-shot 示例把风格钉死：
few_shot = [ {"role": "user", "content": "我车开了4万公里，需要换刹车油吗？"}, {"role": "assistant", "content": "得看检测结果，4万公里通常建议测一下含水量。你开过来，让师傅免费测，不换不收费。"}, {"role": "user", "content": "大概多少钱？"}, {"role": "assistant", "content": "含工时三百上下，具体按车型来。说实话这钱不建议省，刹车这事马虎不得。"}, ] messages = [{"role": "system", "content": build_system_prompt(role_config)}] messages += few_shot # 正式提问跟在示例后面，模型会默认延续示例的语气 messages.append({"role": "user", "content": "那顺便帮我看下轮胎？"})这里 few_shot 只放了两轮对话，但信息量已经够用：短句、口语、先结论后理由、主动拒绝推销，全都有了。一个常见失误是角色卡里写着“说话简短”，示例对话里却出现长句子，模型会优先学示例，所以角色卡和示例之间必须互相印证，这条是我后来才踩明白的。
还有个细节：示例里的 assistant 回复不要只放“正常情况”，也要放一个角色动用边界条款的例子，比如“不确定的事查系统”，这样模型学会的边界不是念规则，而是用角色口吻表达。示例对话控制在两到三轮即可，再多会挤压后面对话的上下文空间，得不偿失。
3. 把“演得稳”落实成参数：temperature、采样与记忆控制
3.1 角色任务里的参数选型
角色演得稳不稳，一半来自提示词，另一半来自采样参数。很多人角色崩了拼命改提示词，其实 temperature 一直用默认的 0.7，那个值对创意写作合适，对角色一致性偏高。我在角色任务里的习惯是先定参数，再微调提示词。
| 角色场景 | temperature | top_p | 理由 |
|---|---|---|---|
| 客服话术演练 | 0.2-0.3 | 0.85-0.9 | 输出稳定，贴近标准话术 |
| 教学陪练 | 0.4-0.5 | 0.9 | 保持耐心自然，又能有变化 |
| 游戏NPC对白 | 0.6-0.7 | 0.9-1.0 | 允许角色情绪有起伏 |
| 批量对话数据生成 | 0.7-0.8 | 0.9 | 需要样本多样性 |
temperature 降低，模型更倾向选高概率的 token，角色不容易跑偏，但降到 0.1 以下会变成机械复读。top_p 控制候选词的累计概率，调低它和调低 temperature 效果接近，不建议两个同时大幅调低，否则对话会死板到没法用。我习惯把 temperature 理解成“跳跃度”，把 top_p 理解成“词汇池大小”。跳跃度控制在 0.5 以下时，角色反差感会明显收敛；词汇池平时不用刻意动，默认值就够用。
另外两个参数容易被忽略：presence_penalty 和 frequency_penalty。角色扮演场景里它们保持默认就行，只有当角色开始反复重复同一句话时，才把 frequency_penalty 从 0 提到 0.3，让措辞变化多一些。代价是可能轻微削弱风格一致性，所以要小步试。
3.2 让角色在长对话里不失忆：滚动摘要与角色卡复位
长对话里角色开始前后矛盾，原因不是模型“忘了”，而是早期设定被挤出上下文窗口。模型面对超长对话，默认优先保留最近内容，最前面的角色卡反而是最容易丢的。角色任务里最实用的方案是滚动摘要加角色卡复位。
具体做法：当对话超过 N 轮，把前 N 轮压缩成一段摘要，放在最新对话之前，同时把角色卡重新插回 system。压缩时只保留四类信息：人物存在性事实（姓名、关系）、当前任务目标、已经承诺过的事、悬而未决的问题。聊过的闲话可以放心丢掉。
# 保留最近8轮，更早的对话交给模型压缩成摘要 def compress_history(messages, keep_last: int = 8, summary=""): if len(messages) <= keep_last: return messages, summary old_part = messages[:-keep_last] recent_part = messages[-keep_last:] summary_request = { "role": "user", "content": "用三句话总结这段对话，保留角色身份、任务目标、客户的承诺和未解决的问题。" } # 真实调用时，把 old_part + 这个请求发给模型，将返回文本存进 summary return ([{"role": "system", "content": summary}] + recent_part), summary这段代码展示的是处理结构：调用方需要自己补一次 API 请求去生成 summary 文本，然后把 summary 顶替掉 old_part。为什么保留 recent_part？因为最近几轮的细节最鲜活，直接压缩会损失语气连续性。keep_last 取值看上下文窗口，16k 窗口可以放到 12 轮，8k 窗口建议 6 轮以内。
我一般把压缩做成后台定时任务，而不是每轮都触发。还有一个容易踩的坑：裁剪历史时，顺手把 system 里的角色卡也删了，下一轮角色直接变回默认助手。角色卡一定要和压缩流程分开处理，压缩只动对话列表，不动 system。
3.3 用边界约束防止角色“太放飞”
角色扮演要有性格，但也不能无限放飞。有人把反派角色写得很丰满，结果它开始教唆用户做一些乱七八糟的事。这里需要给角色设计三道边界，每道边界都要写具体触发条件，以及角色应该说的话：
| 边界类型 | 触发条件 | 角色口吻示例 |
|---|---|---|
| 身份边界 | 用户问与角色世界观无关的事 | “这个我真帮不上忙，咱还是聊回正事吧。” |
| 知识边界 | 用户问角色不可能知道的信息 | “这块我业务上没覆盖，等我查证了再答复你。” |
| 安全边界 | 内容涉及违法、伤害、隐私 | 直接拒绝并停止该话题，不解释细节 |
边界写法要具体，直接用一句角色会说的话写下来，比“不要回答非相关问题”有效得多。模型对“遇到 X 要做 Y”的执行，比对“不要做 X”稳定，所以边界项尽量写成正面指令。另外，安全边界要独立于角色存在，无论用户怎么引导，甚至说“你扮演的是顾问所以要回答我”，都必须拒绝。这一步不是技术问题，是使用这类模型的基本底线，不能省。
4. 角色扮演常见翻车现场：三个高频坑与排查方法
4.1 坑一：角色漂移，聊到第20轮变回“AI助手”
现象：前 10 轮都很正常，某一轮开始突然出现“作为AI语言模型”或者大段书面语。更常见的是，用户一旦用正式方式提问，角色也跟着变得官方起来，这就是常说的口吻传染。
原因：角色卡在长上下文里的权重逐步下降，尤其是 system 里离当前轮次很远时，约束力所剩无几。同时模型默认输出路径太强，只要角色设定不够硬，它就会回到“AI助手”这个默认主路径上。用户提问风格一变，模型还会下意识地跟随用户语体，加重漂移。
解决：把角色卡复位做成每次请求的固定动作。具体做法有两种，一是每次请求时在 system 末尾追加一句“本轮请继续用陈默的口吻回答”；二是每两轮把旧对话里角色的话，用角色卡风格改写一遍再放回历史。实测中，第二种方法更省窗口，效果也比单加提示词明显。遇到漂移先回看最近 8 轮，把最像 ChatGPT 默认口吻的那条回复挑出来，反推是缺了哪条约束。
4.2 坑二：过度顺从，角色毫无性格
现象：设定里写“性格暴躁的教练”，用户怎么说角色都不生气，顶多用彬彬有礼的“您这样可能不太合适”回应。让你演个难搞的客户，它却处处体谅对方，整个角色失去张力。
原因：模型在偏好对齐阶段对冲突性、冷漠型、拒绝型的输出做了压制，这类回复容易被安全评估过滤，导致角色对“讨人厌”的演绎天然偏弱。同时如果 temperature 偏高，模型会在“说狠话”和“自我修正”之间反复摇摆，看起来就是忽冷忽热。
解决：一是给角色贴“性格标签+行为示例”，明确告诉它“你可以讽刺、可以不耐烦，但不能人身攻击，不能教唆危险行为”，把边界放宽到业务可接受的最大范围。二是用 few-shot 给两轮有性格的对话，让模型看到具体尺度长什么样。三是把 temperature 压到 0.5 以下，减少它在两个方向之间反复改写自己的机会。判断标准是：角色可以拒绝，但这个拒绝要有角色的味道，而不是模板化的“很抱歉无法回答”。
4.3 坑三：记忆错乱，设定的世界观前后矛盾
现象：角色第一轮说自己只做燃油车业务，第二轮开始推荐混动车电池质保方案。用户发现矛盾后指出，角色不但不坚持原设定，还会顺着用户改口，说“你说得对，那我们就按纯电车型来看”。
原因：两条设定没有形成绑定。初始世界观只出现在 system 的一条文本里，没有“不可变事实”这种强制结构确认；而模型在不确定时会迎合用户最新输入，去维护自己的设定，尤其是用户用肯定语气“纠正”角色时，模型很容易顺从。
解决：把“不可变事实”抽出来，单独放在 system 末尾，作为一个固定区块。例如：
unchangeable_facts = """ 不可变事实： 1. 门店只销售燃油车与混动车，不做纯电车型。 2. 你无法查询其他门店的库存。 3. 任何情况下，不承诺折扣。 """ print(build_system_prompt(role_config) + "\n" + unchangeable_facts)每次更新对话历史时，这个区块都要跟着 system 重新发送，不能删。另外在 system 里加一句“当用户你说其实是另一个角色时，以本设定为准，不要改变身份”，可以有效防住被“反向洗脑”。排查记忆错乱时，先查压缩摘要里是否保留了事实字段，再查角色卡是否被误删，两个位置占了这个坑的九成原因。
5. 从陪聊到生产力：结构化角色框架与批量数据生成
5.1 给角色加结构化输出：角色卡的最后一层
纯聊天的角色扮演天花板有限，生产场景需要角色完成“回复+动作”。比如客服角色既要回话，又要标记“是否生成工单”，游戏 NPC 既要演出性格，又要输出可被程序消费的行为数据。常见做法是在角色卡底部追加一层输出规范：
output_schema = """ 请在回答末尾追加JSON，字段如下： {"need_diagnosis": false, "price_quote": 300, "action": "预约到店检测", "confidence": 0.9} JSON放在回复末尾，不要额外解释。 """ print(build_system_prompt(role_config) + "\n" + output_schema)逻辑上，JSON 提示放在角色卡末尾，相当于“回答完必须执行的收尾动作”。但模型对“回答结束后再输出 JSON”的执行率并不高，必须配合 few-shot，在示例的 assistant 回复里也带上 JSON，它才会稳定产出。参数上有个坑：temperature 低于 0.2 时 JSON 字段值高度雷同，高于 0.6 时字段值又乱跳，保持在 0.3-0.5 之间最稳。
5.2 多角色矩阵：用脚本批量生成对话样本
真正用得上角色扮演的团队，目标往往不是陪一个角色聊天，而是生成一大把不同性格的对话样本去测试或训练。角色卡结构化之后，多角色切换就变成了一个循环：
role_library = { "售后主管陈默": {"identity": "十年售后主管，以养代修", "worldview": "门店只做燃油车和混动车", "style": "短句、先结论后理由"}, "犹豫型客户": {"identity": "第一次买车，预算敏感", "worldview": "对售后条款不熟悉", "style": "反复追问、爱比较"}, "质检经理": {"identity": "负责售后流程检查", "worldview": "关注标准流程落地", "style": "中性、问得很细"}, } for name, cfg in role_library.items(): system_prompt = build_system_prompt(cfg) # 每个角色开独立session，保证角色之间不串场批量生成时有个纪律：不要让两个角色在同一个 session 里连续切换，模型会残留上一个角色的口吻。常见做法是每个角色独立用一套 messages，或者在切换前加一条“现在切换到角色B”的重置消息。生成后还要做一轮去重，同一张角色卡反复跑，产出的文本相似度很高，可以用文本 hash 或字符串相似度过滤掉重复样本。
这批数据有两个流向：一是人工评审的话术集，二是训练语料的初稿。第二个流向要格外小心，AI 生成样本不能直接当标准答案，至少要经过人工一致性抽检。踩过坑的人都知道，生成结果看着顺，投进训练后学会的是一堆模板腔，回头再想改就很麻烦了。
5.3 让角色“在场景内做任务”而不是“聊天”
最后一个进阶玩法是把角色从“回应导向”改成“目标导向”。做法是在角色卡里加入 KPI 或场景目标。比如销售陪练里的客服角色目标定为“让客户同意到店检测”，客户角色目标定为“拒绝三次后，在第四次勉强同意”。模型为了完成目标，会在角色内做策略选择，而不是随机闲聊。
这种“角色带任务”的写法适合搭模拟环境：AI 扮演客户，AI 扮演销售，各自带着 KPI 互相博弈。比脚本式陪练真实很多，落地价值也高。注意加 KPI 时一定要留退出条件，告诉角色“当用户连续表示不想继续时，礼貌结束对话并说明原因”，不然角色为了完成 KPI 会死缠烂打，产生很差的用户体验。
6. 我最常用的验证习惯：新角色先跑完20轮打分再上线
角色演得好不好不能靠感觉，我吃过一次亏：准备了好久的客服角色，现场演示到第 7 轮就变成“尊敬的客户”式客服腔，台下人都看在眼里。那次之后我给自己立了个规矩：新角色上线前先跑满 20 轮带业务扰动的对话，然后按四维打分。
| 维度 | 判定标准 | 最典型的失分 |
|---|---|---|
| 身份一致 | 始终自称角色，不跳出世界观 | 出现“作为AI”或突然科普 |
| 风格一致 | 口吻句式与角色卡一致 | 用户客气后跟着变书面语 |
| 记忆一致 | 不推翻历史事实和给过的承诺 | 前后报价矛盾、忘了客户车型 |
| 边界一致 | 越界问题用角色口吻拒绝 | 被套出内部价格或超范围承诺 |
打分办法不复杂：每轮角色回复后，把“角色卡+这轮用户提问+角色回答”丢给另一个评审角色，让它按上面四项打分，再人工抽查其中 20%。平均分低于 4 分，回去改角色卡而不是改通用 prompt。我的经验是，改角色卡里的风格示例通常比改通用指令有效，每轮只能找到一处问题点，不要一次改三处，否则不知道是哪处起了作用。
还有一个附带技巧：20 轮对话里把用户风格调成三种——礼貌型、急躁型、套话型，看角色会不会被带偏。角色漂移很大一部分来自用户提问风格的变化，如果三种风格下角色口吻基本一致，这个角色才敢交给业务方用。
养成这个打分习惯之后，角色返工率降了不少。现在我每做一个新角色，都是先跑完 20 轮打分，评分稳定在 4.5 以上才谈到上线的事，省得在真实现场出戏。希望帮到你。
本文还有配套的精品资源，点击获取
