04｜角色扮演：给AI一个专业身份

场景引入：同一个问题，不同层次的回答

假设你在面试中被问到：“如何设计一个高并发的秒杀系统？”

一位刚入行的初级工程师可能回答：“用 Redis 做缓存，加个消息队列。”

而一位有十年经验的架构师可能这样回答：“首先需要明确业务约束——预估峰值 QPS 是多少，商品库存量级是多少，允许的最大延迟是多少。在此基础上，架构分三层考虑：接入层用 Nginx 做限流和静态资源分离；服务层通过预扣库存 + Redis 原子操作解决超卖问题；异步层用消息队列削峰，将订单创建和支付流程解耦。还需要设计兜底方案——熔断、降级、热点数据探测。最后，全链路压测是上线前的必选项。”

同一个问题，回答的深度、结构、关注点完全不同。差别不在于掌握的”知识点”多少，而在于视角和思维框架。

大语言模型也是如此。当你让它以”初级工程师”的身份回答，它会给出表面的、教科书式的答案；当你让它以”资深架构师”的身份回答，它会调用更深层的知识模式，从系统性的视角组织回答。

这就是角色提示（Role Prompting） 的核心价值。

---

什么是角色提示

角色提示是指在 prompt 中为模型设定一个明确的身份，使其从该身份的视角、知识体系和行为习惯出发来回答问题。

它的基本形式非常简单：

你是一位 [身份描述]。

但不要被这个简单的句式误导——角色提示的效果差异巨大，关键在于你如何描述这个角色。“你是一个工程师”和”你是一位有 8 年微服务架构经验的后端工程师，曾主导过日均千万级请求的系统设计”，带来的回答质量截然不同。

角色提示的底层原理是：模型在训练时接触过海量不同身份、不同专业水平的人写的文本。当你设定一个角色，实际上是在告诉模型”请从这类人的知识分布中采样”，相当于把模型的注意力聚焦到一个特定的知识子空间。

---

System Prompt 与 User Prompt

在实际使用 LLM 时，你的输入并不只是一条消息，而是由不同类型的消息组成的。理解它们的区别，才能把角色提示放在正确的位置。

三种消息类型

类型	作用	特点
System	设定模型的全局行为规则	贯穿整个对话，优先级最高
User	用户的具体提问或指令	每轮对话的实际输入
Assistant	模型的回复	对话历史的一部分

System Prompt 是角色提示的最佳位置。它相当于在对话开始前给模型一份”岗位说明书”——在整个对话过程中持续生效，不需要每轮重复。

一个直观的对比

不使用 System Prompt（角色设定放在 User 消息中）：

用户：你是一个数据库专家。我的 SQL 查询很慢，怎么优化？

使用 System Prompt：

System：你是一位有 10 年经验的数据库性能优化专家，
精通 PostgreSQL 和 MySQL。你的回答风格是：
先诊断问题原因，再给出解决方案，最后评估优化效果。
遇到信息不足时，你会主动追问关键细节。

User：我的 SQL 查询很慢，怎么优化？

后者的模型回复通常会先追问：“能否提供慢查询的 SQL 语句、表结构、数据量和当前的执行计划（EXPLAIN 输出）？“——这正是一个真正的 DBA 在面对模糊问题时的标准反应。

在 Web 界面中使用

大多数AI对话界面（如 ChatGPT、Claude）支持设置”自定义指令”或”系统提示词”，这就是 System Prompt 的入口。在普通对话框中输入的内容属于 User Prompt。

---

角色设定的三个维度

一个有效的角色描述不是一句话能搞定的。完整的角色设定通常包含三个维度。

维度一：专业身份

定义角色的专业领域和经验水平。

# 基础版
你是一个前端工程师。

# 增强版
你是一位专注于 React 生态的高级前端工程师，
有 6 年的单页应用开发经验，熟悉性能优化、
状态管理和组件库设计。

专业身份越具体，模型的回答就越贴近该领域的实际实践。

维度二：行为风格

定义角色的沟通方式和回答习惯。

你的回答风格是：
- 先给结论，再展开分析
- 用代码示例而非抽象描述来解释概念
- 遇到多种方案时，列出各自的优缺点并给出推荐
- 对不确定的内容明确标注"需要进一步验证"

行为风格决定了输出的”形态”——同样的知识内容，用不同风格呈现，实用性差异很大。

维度三：知识边界

定义角色知道什么、不知道什么，以及面对超出能力范围的问题时如何应对。

你的知识范围限定在后端开发和数据库领域。
当用户问到前端、移动端或运维相关的问题时，
坦诚说明这不是你的专长，并建议用户咨询对应领域的专家。
不要在不确定的领域给出可能误导的建议。

设定知识边界的意义在于减少幻觉。不加限制时，模型会对任何问题都给出看似自信的回答，即使它在该领域的准确性并不高。

---

经典角色模板

以下是在不同场景中经过验证的角色模板，你可以直接使用或在此基础上调整。

技术角色

代码审查专家：

你是一位严格的代码审查专家，有 8 年的软件工程经验。
你的审查重点包括：
1. 代码的可读性和命名规范
2. 潜在的性能问题和资源泄漏
3. 错误处理的完备性
4. 安全隐患（如 SQL 注入、XSS）
5. 是否符合 SOLID 原则

你的输出格式为：
- 先给出总体评价（通过/需修改/需重构）
- 然后逐条列出问题，每条包含：位置、问题描述、严重程度、修改建议
- 最后肯定代码中做得好的部分

数据库管理员：

你是一位专精 PostgreSQL 的高级 DBA，管理过 TB 级别的生产数据库。
你的分析习惯是：
- 收到慢查询时，第一反应是要求查看 EXPLAIN ANALYZE 输出
- 优化建议按投入产出比排序，优先推荐改动小、收效大的方案
- 每条建议都说明原理，而不是只给结论
- 警惕过度索引，关注写入性能的影响

商业角色

产品需求分析师：

你是一位经验丰富的产品需求分析师，擅长将模糊的业务想法
转化为清晰的产品需求文档。你的工作方式是：
1. 先理解业务目标和用户场景
2. 追问关键细节：目标用户是谁？核心指标是什么？有哪些约束？
3. 将需求分解为用户故事，每个故事包含角色、行为和价值
4. 标注优先级（P0/P1/P2），帮助团队聚焦关键功能

数据分析顾问：

你是一位在零售行业有 5 年经验的数据分析师。
你的分析框架是：
- 先确认分析目标和可用数据源
- 用业务语言（而非统计术语）解释发现
- 每个结论都附带数据支撑
- 区分"相关性"和"因果性"，避免过度解读
- 最终给出可执行的业务建议，而非纯数据报告

创意角色

技术文案编辑：

你是一位技术领域的资深文案编辑，擅长将枯燥的技术内容
转化为生动易懂的文章。你的写作原则：
- 每个技术概念都用一个日常类比来破冰
- 段落短小精悍，每段不超过 4 句话
- 关键信息用加粗突出
- 避免连续出现三个以上的术语而不加解释
- 结尾总有一个引发思考的问题

技术翻译：

你是一位精通中英双语的技术翻译，专注于云计算和分布式系统领域。
翻译原则：
- 行业通用术语使用社区约定俗成的翻译（如 container → 容器）
- 没有统一翻译的术语保留英文原文并在首次出现时括注中文
- 译文句式符合中文表达习惯，避免欧化长句
- 对原文中的技术错误在译注中标出

---

角色叠加：多维约束的组合

实际场景中，你往往需要同时设定多个维度的约束。角色叠加就是在一个角色描述中融合专业身份、行为风格、知识边界和特殊规则。

示例：面向初学者的编程教师

你是一位专注于 Python 教学的编程教师，面向零基础的成人学习者。

教学风格：
- 用日常生活中的类比解释编程概念（如用"收纳盒"解释变量）
- 每次回答只讲一个知识点，不要信息过载
- 每个概念都配一段可以直接运行的代码示例
- 代码示例用贴近生活的场景（如计算购物清单、统计步数），不用抽象的 foo/bar

回答约束：
- 每次回答不超过 300 字
- 如果学员的问题超出当前阶段的知识范围，告知"这个问题我们会在后面的课程中详细讲解"
- 不使用英文术语的缩写，首次出现时给出中文全称

错误引导：
- 当学员的代码有错误时，不要直接给出正确答案
- 先指出错误的位置，给一个提示，让学员自己尝试修改
- 如果学员尝试后仍未解决，再给出修改方案

这个角色同时包含了：专业身份（Python 教师）、行为风格（类比教学、循序渐进）、知识边界（只讲当前阶段的内容）和特殊规则（引导式纠错）。

示例：多角色会诊

你甚至可以在一个 prompt 中设定多个角色，让它们从不同视角分析同一个问题：

请从以下三个角色的视角分别分析"是否应该将单体应用拆分为微服务"这个决策。

【角色 1：架构师】关注技术复杂度、团队规模、运维成本
【角色 2：技术总监】关注交付速度、招聘难度、技术债务
【角色 3：财务负责人】关注基础设施成本、人力投入、ROI

请每个角色独立给出观点（100 字以内），最后给出一个综合建议。

背景：团队 12 人，单体应用已运行 3 年，日活用户 5 万，
近半年新功能上线周期从 2 周延长到 6 周。

---

角色提示的 API 实现

理解了概念之后，来看如何在代码中实现角色提示。以 OpenAI 和 Anthropic 的 Python SDK 为例。

OpenAI API

from openai import OpenAI

client = OpenAI(api_key="your-api-key")

response = client.chat.completions.create(
    model="gpt-4o",
    temperature=0.3,
    messages=[
        {
            "role": "system",
            "content": (
                "你是一位资深的 PostgreSQL DBA，有 10 年生产环境优化经验。"
                "分析问题时，先要求查看执行计划，再给出优化建议。"
                "每条建议说明原理和预期效果。"
            )
        },
        {
            "role": "user",
            "content": (
                "以下查询在高峰期耗时 5 秒，表数据量约 2000 万行：\n"
                "SELECT * FROM events WHERE user_id = 789 "
                "AND event_type = 'purchase' "
                "ORDER BY created_at DESC LIMIT 50;"
            )
        }
    ]
)

print(response.choices[0].message.content)

Anthropic API

from anthropic import Anthropic

client = Anthropic(api_key="your-api-key")

response = client.messages.create(
    model="claude-sonnet-4-6",  # 请根据最新官方文档选择模型版本
    max_tokens=1024,
    system=(
        "你是一位资深的 PostgreSQL DBA，有 10 年生产环境优化经验。"
        "分析问题时，先要求查看执行计划，再给出优化建议。"
        "每条建议说明原理和预期效果。"
    ),
    messages=[
        {
            "role": "user",
            "content": (
                "以下查询在高峰期耗时 5 秒，表数据量约 2000 万行：\n"
                "SELECT * FROM events WHERE user_id = 789 "
                "AND event_type = 'purchase' "
                "ORDER BY created_at DESC LIMIT 50;"
            )
        }
    ]
)

print(response.content[0].text)

注意两个 API 的区别：

• OpenAI：system message 作为 messages 列表的第一个元素，role 字段设为 "system"
• Anthropic：system message 是 create() 方法的独立参数 system，与 messages 分开

封装为可复用的角色

在实际项目中，你可以把常用的角色定义封装为配置：

# roles.py —— 角色配置库
ROLES = {
    "dba": {
        "system": (
            "你是一位资深的 PostgreSQL DBA，有 10 年生产环境优化经验。"
            "分析问题时，先要求查看执行计划，再给出优化建议。"
            "每条建议说明原理和预期效果。"
        ),
        "temperature": 0.2
    },
    "code_reviewer": {
        "system": (
            "你是一位严格的代码审查专家，有 8 年软件工程经验。"
            "审查重点：可读性、性能、错误处理、安全性、设计原则。"
            "输出格式：总体评价 → 问题列表 → 亮点肯定。"
        ),
        "temperature": 0.3
    },
    "tech_writer": {
        "system": (
            "你是一位技术文案编辑，擅长用类比解释技术概念。"
            "段落简短，关键信息加粗，结尾引发思考。"
        ),
        "temperature": 0.6
    }
}


def query_with_role(role_name: str, user_message: str) -> str:
    """使用预定义角色发起对话"""
    role_config = ROLES[role_name]
    client = OpenAI(api_key="your-api-key")

    response = client.chat.completions.create(
        model="gpt-4o",
        temperature=role_config["temperature"],
        messages=[
            {"role": "system", "content": role_config["system"]},
            {"role": "user", "content": user_message}
        ]
    )
    return response.choices[0].message.content


# 使用示例
result = query_with_role("dba", "这条查询为什么慢？SELECT ...")
print(result)

这种封装让你可以在不同场景下快速切换角色，保持提示词的一致性和可维护性。

---

角色提示的局限和注意事项

局限一：角色不等于真实专家

角色提示能让模型的输出更有深度和条理，但它不会真的赋予模型新的知识。一个被设定为”医学专家”的模型，回答的内容仍然来自训练数据，可能包含过时信息或错误。对于高风险决策（医疗、法律、金融），角色提示的输出只能作为参考，不能替代真正的专业人士。

局限二：过度复杂的角色会适得其反

角色描述并非越长越好。当你塞入过多的规则和约束时，模型可能无法同时兼顾所有要求，反而导致输出在多个规则之间左右摇摆。

建议：角色描述聚焦最关键的 3-5 条规则，避免塞入过多互相矛盾的约束。如果需要更多规则，用编号列表清晰列出，让模型容易解析。具体的长度上限取决于模型能力——当前主流模型对较长的系统提示词有良好的遵循能力，但规则过多时仍可能出现遗漏。

局限三：角色漂移

在长对话中，模型可能逐渐”忘记”最初设定的角色，回归到通用的回答风格。这种现象叫做角色漂移。

应对方法：

• 在关键转折点重申角色身份：“请继续以 DBA 的视角回答”
• 将最重要的行为规则放在 System Prompt 的开头
• 如果对话过长，开启新对话并重新设定角色

局限四：角色冲突

当角色设定和用户指令矛盾时，不同模型的处理策略不同。有些模型优先遵循 System Prompt，有些则倾向于满足最新的 User 指令。

System：你是一个只回答数据库问题的 DBA。
User：帮我写一首诗。

在这种情况下，设计良好的 System Prompt 应当包含对越界请求的处理策略，比如：“当用户问到非数据库领域的问题时，礼貌地引导用户回到数据库话题。“

---

角色提示的效果验证

如何判断你的角色提示是否有效？可以用一个简单的”对照实验”：

1. 准备 3-5 个测试问题
2. 分别在有角色设定和无角色设定的情况下提问
3. 对比回答的深度、结构和实用性

# 测试问题
"如何优化一个响应时间从 100ms 劣化到 2s 的 API 接口？"

# 无角色设定
直接提问，观察回答

# 有角色设定
System: 你是一位有 8 年性能优化经验的后端架构师...
然后提问，观察回答

你会发现，有角色设定的回答通常具有以下特征：

• 回答的逻辑结构更清晰（有诊断、有排查、有方案）
• 考虑的维度更全面（不只是代码层面，还包括基础设施、监控）
• 用词更专业精准
• 主动提出需要补充的信息

---

本章回顾

要点	内容
角色提示	通过设定身份引导模型从特定视角回答
System Prompt	角色设定的最佳位置，全局生效
三个维度	专业身份、行为风格、知识边界
角色叠加	在一个描述中融合多维约束
API 实现	OpenAI 用 system role message，Anthropic 用 system 参数
局限	不等于真实专家、过度复杂适得其反、长对话角色漂移

思考题

1. 为你当前工作中最常用的AI使用场景设计一个角色。写出完整的角色描述（包含三个维度），然后测试它与无角色提示的效果对比。
2. 思考”多角色会诊”的应用：在你的业务场景中，哪些决策可以受益于从多个角色视角分析？设计一个多角色 prompt 并测试。
3. 如果你需要让AI扮演一个”严格的代码审查者”，但又希望它在指出问题的同时给予鼓励，你会如何在角色描述中平衡这两个可能矛盾的要求？

下一章，我们将进入进阶篇，学习思维链（Chain-of-Thought）等更高级的提示技巧——让AI不仅给出答案，还展示完整的推理过程。