你 prompt 开头写”你是世界最资深的后端工程师，30 年经验，分布式系统博士。你以细致的 code review 和发现细微 bug 闻名”。然后请模型 review 代码。你拿到的 review 和没有角色行的 review 基本一样。也许个别用词偏”资深”语域，但发现的问题、深度、具体建议——全一样。在事实题和推理题上，冗长人设只在边际偏置风格，不解锁新能力。把角色当咒语，花 ~50 个 token 换几乎为零的提升。
最快修复： 把角色压成一句功能性陈述（你是一名 review Postgres 迁移的后端工程师。），把省下来的功夫放在可核对的规则清单、输出 schema、一个完整示例上。这才是真正改变答案的东西。
本文讲为什么冗长角色很少提升质量、截至 2026 年 6 月的研究怎么说，以及怎么把角色槽用好，把真正预算投在规则、schema、示例上。
研究到底怎么说（2026 年 6 月）
有两份大型研究值得知道，因为它们用数据击碎了”你是专家”的迷信：
- Wharton《Playing Pretend：专家人设不提升事实准确率》（Generative AI Labs，2025 年 12 月 7 日）。六个模型（GPT-4o、GPT-4o-mini、o3-mini、o4-mini、Gemini 2.0 Flash、Gemini 2.5 Flash），198 道 GPQA Diamond 题 + 300 道 MMLU-Pro 题，每题跑 25 次。专家人设没有可靠的准确率提升。低知识人设（“Toddler”幼儿人设）反而带来统计显著的准确率下降。域不匹配的专家人设让 Gemini 2.5 Flash 每 25 次约有 10.56 次拒答。
- 《When “A Helpful Assistant” Is Not Really Helpful》（EMNLP 2024 Findings）。162 个不同人设、2410 道事实题、四个开源模型家族。加人设没有统计显著提升，而且挑”最好”的人设基本等于随机。
反方向也真实存在：某次 MMLU 测试里，冗长人设把准确率从 71.6% 基线压低到 68.0%（短人设）、66.3%（长人设）。结论不是”永远别用角色”，而是：只有当角色能改变一个你说得出、核得了的行为时，它才值这些 token。
角色确实有用的地方：开放/创意类工作（语气和声音），以及 system prompt 里的安全/护栏框定。这两类都不是”让 code review 多抓几个 bug”。
你属于哪一类？
| 症状 | 可能原因 | 去看 |
|---|---|---|
| 删掉角色毫无变化 | 角色 = 咒语，没功能内容 | Step 1、Step 4 |
| 输出无视角色声明的风格 | 角色与后续指令冲突 | 原因 2 |
| 角色写”细致”但 review 很浅 | 没把可核对规则绑到形容词 | Step 2 |
| 角色全是最高级（“史上最强 AI”） | 装饰，不是功能 | Step 1 |
| 人设巨大、任务极小 | 内容被人设淹没 | Step 5 |
| 真需要专业域知识 | 缺参考资料，不是角色问题 | Step 3 |
常见原因
1. 相信”角色 = 咒语”
民间相信”详尽人设解锁专家模式”。上面的对照研究在事实题和推理题上不支持这点。角色偏置表层语气，不偏置底层能力。
如何判断：你的角色 50+ 字是 credentials 和夸赞。
2. 角色与后续指令冲突
角色说”你写简洁代码”，后面要求”详尽解释”。具体指令赢，角色被覆盖。
如何判断：行为匹配你的明确规则，不是角色。
3. 没把可测规则绑到角色
“你很细致”——一个细致的 review 到底该包含什么？你定义不出来，模型就表现不出。
如何判断：角色形容词没配可核对规则。
4. 角色是装饰不是功能
“你是史上最强 AI”——纯吹捧，零功能内容。模型不靠夸赞激励。
如何判断：角色含最高级或”世界最强”措辞。
5. 内容被角色淹没
80% prompt 空间给人设，20% 给真任务。人设挤掉了指令。
如何判断：角色字数 > 规则 + schema 字数之和。
动手前先确认
- 保存当前 prompt 和它的输出。
- A/B：同 prompt 删掉角色行再跑。输出基本一样就说明角色没用。
- 想清楚你真正想要什么行为，再把它写成规则，不写成人设。
- 计划：短角色（1 句）+ 重投资规则、schema、示例。
- 需要专业域知识就计划附参考资料，不要靠 credential。
需要收集的信息
- 标出角色行的当前 prompt。
- 有角色的输出。
- 无角色的输出（A/B 那次）。
- 角色没产出、但你想要的具体行为。
- 模型名 + 在用的 system prompt。
最短修复路径
Step 1：角色压成一句功能性陈述
差： "你是世界最资深的后端工程师，30 年经验，
以细致 code review 闻名……"
好： "你是一名 review Postgres 迁移的资深后端工程师。"“好”角色是功能性：点了任务上下文。“差”角色是夸赞。
Step 2：角色属性翻成规则
角色暗含："细致"
等价规则：
- 每个代码改动列出：
- 1 个潜在边界情况
- 1 个测试可能漏掉它的原因
- 1 行可能在生产坏掉的具体代码规则交付”细致”；形容词单独不交付。
Step 3：专业知识附参考资料
你是 SOC 2 合规审查员。
参考（评估只用此，不依赖先验）：
<粘当前 SOC 2 trust services criteria>
任务：……在域知识上，参考资料胜过任何角色。模型不会因 credential 解锁知识，它用上下文里的东西。这也是上面”域不匹配”那个失败模式的修法：当专家人设没有真实知识可依，强模型有时会拒答或含糊，而不是帮你。
Step 4：A/B 删除测试
删掉角色行重跑。输出一样就永久删，那块空间给规则。变差了就找出起作用的那 1-2 个词，只保留它们。
Step 5：真需要的人设用规则编码
要”怀疑型 reviewer”人设？把行为编码出来：
Review 规则：
- 默认立场：这代码有 bug。找出至少 2 个。
- 任何"看起来 OK"都要给证据。
- 每个函数找 1 个会让它出错的输入。这能在行为层面产出人设，不靠形容词。
Step 6：稳定角色挪到 system prompt
老在打同一个角色，就挪到 system prompt、project 指令或规则文件（Cursor 里是 .cursorrules 或较新的 .cursor/rules/*.mdc；Claude Code 里是 CLAUDE.md）。然后每条 user message 只放本轮任务。
怎么确认已经修好
- 角色 1 句、最多 20 字。
- 你想要的行为来自规则，不是角色。
- A/B：有 vs 无角色，输出在你想要的方向上有明显差异，或者角色已被删掉。
- 输出深度和质量符合目标，无论角色措辞。
- 你能用一句真话描述角色的贡献。
如果还是没修好
- 你的 prompt 很可能缺规则。加上规则常能补上你以为角色会给的”专业”。
- 任务可能需要模型缺乏的能力。任何角色都解锁不了新能力。
- 试更强的模型（比如 Thinking/推理模式，或从 Sonnet 4.6 升到 Opus 4.7）。角色替代不了能力差距。
- 高专业域用检索把相关文档作为上下文注入。
预防建议
- 默认角色 1 句。其余投资在规则、schema、示例。
- 专门 persona（system prompt / project）留给重复工作流，不要用在一次性任务。
- 警惕”角色通胀”。加形容词很少是修法。
- 每个详尽角色都 A/B 测；大多数该精简。
- 团队工作流商定每类任务一个标准短角色。
- 想写”你是 X 最强”时，改写”对此任务，做 X”。
常见问答
“你是专家”到底有没有用？ 在事实题和推理题上很少有用。截至 2026 年 6 月，Wharton 六模型研究和 162 人设的 EMNLP 研究都显示专家标签没有可靠的准确率提升。它最有用的地方是开放/创意类工作（语气重要的场合）和 system prompt 里的安全框定。
那为什么有些 prompt 教程力推人设？ 详尽、自动生成的人设（ExpertPrompting 那一套：让模型先生成一段量身定制的专家描述）确实能压过裸的”你是一名数学家”。但这点提升来自额外的任务相关细节，不是来自 credential。你完全可以靠写明确规则 + 附参考资料，更稳地拿到同样的细节。
坏人设会让答案更差吗？ 会。低知识人设（“Toddler”幼儿）带来统计显著的准确率下降；域不匹配的专家让某模型每 25 次约 10.56 次拒答；光是冗长人设就把某次 MMLU 分数从 71.6% 压到 66.3%。拿不准时，不设角色比设错角色更安全。
角色该放 system prompt 还是 user message？ 稳定角色放 system prompt / project 指令 / 规则文件，免得每轮重打；本轮任务放 user message。参见 Prompt 把 system 与 user 混用。
不用人设怎么拿到”专家级”输出？ 按影响力从大到小三招：(1) 明确的可核对规则，(2) 输出 schema 或完整示例，(3) 附上模型必须使用的参考资料。在这四样里，角色是最小的那根杠杆。