你 prompt 开头写”你是世界最资深的后端工程师，30 年经验，分布式系统博士。你以细致的 code review 和发现细微 bug 闻名”。然后请模型 review 代码。你拿到的 review 和没有角色行的 review 基本一样。也许个别用词偏”资深”语域，但发现的问题、深度、具体建议——全一样。角色只在边际偏置风格；不解锁新能力。把角色当咒语是常见误解，花 50 个 token 换 ~0 提升。
本文讲为什么冗长角色不能提升质量，以及怎么把角色槽用好，把真正功夫放在规则、schema、示例上。
常见原因
1. 相信”角色 = 咒语”
民间相信”详尽人设解锁专家模式”。研究和 A/B 测试很少支持。角色偏置表层语气，不偏置底层能力。
如何判断：你的角色 50+ 字是 credentials 和夸赞。
2. 角色与后续指令冲突
角色说”你写简洁代码”，后面要求”详尽解释”。指令赢，角色被覆盖。
如何判断：行为匹配你的具体规则，不是角色。
3. 没把可测规则绑到角色
“你很细致”——“细致”的 review 长什么样？你定义不出来，模型就表现不出。
如何判断：角色形容词没配可测规则。
4. 角色是装饰不是功能
“你是史上最强 AI”——纯吹捧，零功能。模型不靠夸激励。
如何判断：角色含最高级或”世界最强”。
5. 内容被角色淹没
80% prompt 空间给人设，20% 给真任务。人设压过任务。
如何判断：角色字数 > 规则 + schema 字数之和。
动手前先确认
- 保存当前 prompt 和输出。
- A/B：同 prompt 删掉角色再跑。输出一样就说明角色没用。
- 想清楚你真正想要什么行为——写成规则，不写成人设。
- 计划：短角色（1 句）+ 重投资规则 / schema / 示例。
- 需要专业知识就计划附参考资料，不要靠角色。
需要收集的信息
- 标出角色的当前 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 指令 / .cursorrules。然后 user message 只放本轮任务。
怎么确认已经修好
- 角色 1 句、≤20 字。
- 你想要的行为来自规则，不是角色。
- A/B：有 vs 无角色输出有明显你想要的方向差异。
- 输出深度和质量符合目标，无论角色措辞。
- 你能用一句话描述角色的贡献（而且这句是真的）。
如果还是没修好
- 你的 prompt 可能缺规则——加上常解锁你以为角色能给的”专业”。
- 任务可能需要模型缺乏的能力——任何角色都解锁不了。
- 试更强模型——角色替代不了能力差距。
- 高专业域用检索把文档作为上下文注入。
预防建议
- 默认：角色 1 句。其余投资在规则、schema、示例。
- 重复工作流用专门 persona（system prompt / project），不要一次性。
- 警惕”角色通胀”——加形容词很少是修法。
- 每个详尽角色都 A/B 测；大多数该精简。
- 团队工作流商定每类任务一个标准短角色。
- 想写”你是 X 最强”时改写”对此任务，做 X”。