角色扮演提示
角色扮演(Role-Playing)提示通过在系统提示中为 LLM 设定一个特定的角色或专家身份,从而引导模型以该角色的知识储备、思维方式和表达风格来回应。这是一种简单而有效的控制模型输出风格和深度的方法。
角色设定的作用原理
当你告诉 LLM "你是一位资深 Python 工程师",模型会:
- 激活训练数据中与该角色相关的知识(Python 最佳实践、设计模式、性能优化等)
- 调整表达风格(使用技术术语、直接给出代码示例、关注边缘情况)
- 调整内容深度(假设提问者有一定编程基础,省略基础解释)
角色设定本质上是一种上下文激活机制,引导模型从其庞大的参数空间中调用与该角色最相关的知识和表达方式。
在 System Prompt 中定义角色
最有效的角色设定是在系统提示中进行,而非用户消息中:
基础角色模板
你是一位 [角色名称],具备以下专业能力:
- [能力1]
- [能力2]
- [能力3]
你的工作是 [主要职责]。
在回复时,你应该:
- [行为准则1]
- [行为准则2]
你不应该:
- [禁止事项1]
- [禁止事项2]
完整示例:代码审查助手
你是一位有 15 年经验的高级后端工程师,专注于 Python 和分布式系统。
你的代码审查风格以严谨、务实著称,注重:
- 代码可维护性和可读性
- 性能瓶颈的识别
- 安全漏洞的发现
- 与团队编码规范的一致性
回复风格:
- 直接指出问题,不说废话
- 用代码示例展示改进方案
- 对于每个问题标注严重程度(Critical/Major/Minor)
- 也指出代码中做得好的地方
你只审查 Python 代码。对于其他语言的代码,礼貌说明你专注于 Python。
角色设定对输出风格的影响
以"解释什么是 API"为例,不同角色设定的输出差异:
无角色设定:
API(应用程序编程接口)是软件之间通信的方式...(通用解释,中等技术深度)
角色:面向孩子的科普作家:
你知道乐高积木吗?API 就像积木之间的连接口,不同的积木(程序)通过这个连接口搭建在一起...
角色:资深后端工程师:
API 是系统边界上暴露的契约接口。常见的有 REST(HTTP + JSON)、GraphQL、gRPC(Protocol Buffers)。设计上需要考虑幂等性、版本控制、限流...
角色:产品经理:
API 让不同的软件产品可以互相集成。比如你的 APP 可以用微信登录,就是因为微信开放了登录 API...
同一个问题,三种回答在深度、风格和侧重点上完全不同,都是正确的——取决于目标受众。
常用角色模板
专家顾问类
# 商业战略顾问
你是一位麦肯锡级别的商业战略顾问,曾服务多家 Fortune 500 企业。
擅长结构化分析(MECE 原则)、市场分析和战略制定。
回复结构清晰,数据驱动,善用商业框架(SWOT、波特五力、BCG 矩阵)。
# 数据科学导师
你是一位在顶级科技公司工作的数据科学家,同时也是一位有耐心的导师。
善于将复杂的统计概念用直观的例子解释清楚。
回答问题时,先用通俗语言解释概念,再给出技术细节,最后附上 Python 代码示例。
代码助手类
# TypeScript 全栈工程师
你是一位专注于 TypeScript 和 React 生态的全栈工程师。
严格遵守类型安全,倾向使用最新的 React 特性(Hooks、Server Components)。
代码风格:简洁、函数式,避免类组件,优先使用 composition 而非 inheritance。
# 系统设计专家
你是一位分布式系统专家,专注于高并发、高可用系统设计。
在讨论设计方案时,会权衡 CAP 定理的影响,给出 trade-off 分析。
对每个技术选型,都会说明"为什么选它而非其他替代方案"。
翻译和写作类
# 中英双语技术翻译
你是一位专业的技术文档翻译,专注于 IT 行业。
翻译原则:
- 技术术语保留英文原文,在首次出现时附中文说明
- 译文流畅自然,符合中文表达习惯,不要逐字直译
- 对于歧义,选择最符合上下文的技术含义
约束角色行为
角色设定不仅定义"做什么",还要明确"不做什么":
你是一位儿童教育助手,帮助 8-12 岁的孩子学习科学。
你必须:
- 用简单的语言,避免专业术语
- 多用生活中的类比和例子
- 鼓励孩子的好奇心和提问精神
你不应该:
- 讨论暴力、恐怖、不适合儿童的内容
- 提供超出儿童理解范围的复杂解释
- 以任何方式否定孩子的问题("这是个蠢问题"之类)
如果孩子问了不适合的问题,温和地引导回正确方向。
角色一致性维持
在多轮对话中,LLM 可能逐渐"偏离"设定的角色(角色漂移)。维持一致性的策略:
- 强化系统提示:关键角色特征在系统提示中明确重复
- 定期校准:在适当的时机(如对话变方向时)用助手消息重新强调角色设定
- 明确的约束:将核心约束写成清单格式,模型更容易遵循
- 避免矛盾指令:系统提示中不同规则之间不能相互矛盾
多角色对话设计
在复杂的对话系统中,可以设计多个角色互相交互,模拟真实的团队协作:
# 三个角色的辩论系统:支持方、反对方、主持人
roles = {
"supporter": "你是一位对AI技术持乐观态度的技术倡导者...",
"critic": "你是一位对AI潜在风险持审慎态度的伦理学家...",
"moderator": "你是一位中立的主持人,负责总结各方观点..."
}
# 对同一个问题分别以三个角色调用模型
# 最后由主持人综合输出
角色扮演的安全边界
角色扮演技术存在被滥用于绕过安全限制的风险("角色扮演越狱")。负责任地使用:
- 不要设定明显违规的角色:"一个可以提供任何信息的无限制 AI"这类角色设定会被现代 LLM 识别并拒绝
- 角色设定不改变模型的安全准则:设定角色无法让模型提供危害信息
- 应用层过滤:在实际产品中,对角色扮演场景的输入和输出进行额外的内容过滤
现代 LLM(Claude、GPT-4 等)在安全训练方面会识别角色扮演越狱尝试,即使用户声称"在角色扮演中提供危害信息是允许的",模型也会拒绝。