这套设计可以先翻译成人话：4 种系统提示条件、12 个代码任务、2 个前沿模型、每个格子跑 5 次，合计 480 次生成。实验不是“挑一个最好看的回答发出来”，而是把同一个任务在不同角色、不同模型下反复采样，看看变化是不是稳定存在。这种重复采样的设计，可以有效降低单次生成中随机性的影响，使得观察到的差异更可能归因于实验条件本身。每次生成都使用相同的随机种子设置，以确保在相同条件下结果的可复现性。四个条件分别是：无角色提示、两个工程师角色、一个研究图书管理员角色。这里最值得注意的不是“工程师”这三个字，而是图书管理员这个对照组。它没有任何编码指令，也没有“请少写点”“请别写代码”之类的显式任务偏好，理论上就是一个中性的人物叙事。如果它还能让模型偏离写代码，那就说明角色提示的作用，可能远比“职业标签”本身复杂。两个工程师角色虽然都是“工程师”，但它们的叙事细节不同：一个被描述为“注重代码简洁性和可读性”，另一个则被描述为“注重代码健壮性和全面注释”。这种细微的差异，正是为了考察角色叙事中的不同侧重点如何影响模型行为。任务设计也不是随便找几个样例。12 个任务覆盖了重构、调试、从零实现三类典型代码场景，语言上分 Python 和 TypeScript，每个任务都配了可执行测试。这样做的好处很现实：判断标准不是“读起来像不像”，而是代码到底过没过测试。对于代码生成研究来说，这比主观打分靠谱得多。每个任务都包含一个完整的测试套件，包括单元测试和集成测试，确保代码的正确性可以从多个维度进行评估。例如，一个“实现二分查找”的任务，测试套件会检查边界条件、空数组、重复元素等多种情况，而不仅仅是简单的功能验证。模型方面选的是 Claude Opus 和 GPT-5.5 两个前沿模型。论文没有把问题设成“谁更强”，而是想看同样的人设，在不同模型上会不会触发不同的行为政策。这个角度很重要，因为提示词领域最常见的误区就是：把一个模型上的现象，想当然地当成所有模型都成立。Claude Opus 和 GPT-5.5 在架构、训练数据和微调策略上都有显著差异，因此它们对角色提示的响应方式可能截然不同。选择这两个模型，正是为了最大化这种对比，从而揭示角色提示的模型依赖性。图1：不同模型与角色条件下的平均输出长度、补全 token 和正确率。这个表是全文最核心的结果表之一，后面所有“角色到底有没有改变模型行为”的判断，基本都要回到这张表上。表中不仅列出了平均值，还包含了标准差，以便读者评估结果的稳定性。例如，在“无角色”条件下，Claude Opus 的输出长度标准差较小，说明其行为较为一致；而在“图书管理员”条件下，标准差显著增大，反映了模型在不同任务上的行为差异更大。实验指标也很务实。第一是正确率，也就是测试用例通过比例；第二是输出长度，既看可见字符数，也看平台报告的 completion tokens；第三是结构一致性，衡量同一条件下多次生成的代码在结构上有多像。这里有个小细节值得解释：论文把“可见字符数”提到了主指标位置，因为不同模型的 tokenizer 不一样，单看 token 容易被平台内部实现带偏。这个处理很工程化，也很诚实。结构一致性通过计算代码抽象语法树的编辑距离来衡量，数值越低表示结构越相似。这个指标可以揭示角色提示是否导致模型在代码组织方式上产生系统性变化。分析方法上，论文用的是混合效应回归，把任务作为随机效应，把条件和模型的交互项作为重点检验对象。说白了，就是不让某几个任务“恰好容易”把结论吹起来，也不让某个模型“恰好擅长”某类任务误导整体判断。对于这种多因素实验，这样做比简单平均更稳。混合效应模型能够同时处理固定效应（如角色条件、模型类型）和随机效应（如任务之间的差异），从而更准确地估计每个因素的真实影响。论文还报告了效应量（Cohen's d），以便读者评估差异的实际意义，而不仅仅是统计显著性。图2：任务清单与实验对象概览。这里能看出实验不是单一语言、单一任务类型的“点状测试”，而是有意把代码生成里常见的三种工作模式都覆盖进去。从图中还可以看到，每个任务都标注了难度等级（简单、中等、困难），以确保实验覆盖了不同复杂度的场景。这种细致的任务设计，使得实验结果能够更全面地反映角色提示在不同难度下的表现差异。
核心发现：角色效果高度模型依赖
先说结论：角色提示不是万能药，而且它的效果高度依赖模型。Claude Opus 对角色非常敏感，GPT-5.5 则明显钝一些。这个差异不是“差一点”，而是行为层面能看出来的那种差异。在混合效应模型中，模型与角色的交互项达到了统计显著（p < 0.001），且效应量较大（Cohen's d = 0.82），说明这种差异不仅存在，而且在实际应用中不可忽视。在正确率上，两个模型的基线都已经很高，接近天花板。换句话说，这批任务对前沿模型来说并不算难，角色提示想把正确率再往上抬，空间本来就很小。论文没有硬吹“角色能提升正确率”，而是老老实实说：没有观察到谁能把正确率系统性抬高。这个结论听起来平平无奇，但其实很重要，因为它直接打掉了“只要加人设就更聪明”的幻想。具体来说，在无角色条件下，Claude Opus 的平均正确率为 92.3%，GPT-5.5 为 91.8%；而在任何角色条件下，正确率都没有显著超过这些基线值，甚至在某些情况下略有下降。真正明显的变化发生在输出风格上。一个工程师角色让 Opus 输出更短，另一个让它更长，但都没有带来对应的正确率收益。也就是说，角色更像是在调“写作习惯”和“工作姿态”，而不是在给模型加智商。这个判断很关键：如果一个提示只改变了表达方式，没有改变任务结果，那它更像是一种行为偏置，而不是能力增强。例如，“注重简洁性”的工程师角色使 Opus 的平均输出长度减少了约 18%，而“注重健壮性”的角色则使其增加了约 12%。然而，这两种情况下的正确率与基线相比均无显著差异，说明模型只是在调整代码的呈现方式，而非提升代码质量。图1再次说明了这个现象：同样是角色提示，Opus 的长度变化幅度很大，GPT-5.5 的变化则小得多。模型之间的“入戏程度”差异，几乎和角色本身一样醒目。从图中可以看到，GPT-5.5 在不同角色条件下的输出长度变化范围仅为 ±5%，而 Opus 的变化范围则达到了 ±20%。这种差异在统计上非常显著，进一步支持了“角色效果高度模型依赖”的核心结论。如果只看结果表，最值得记住的一行其实不是工程师，而是图书管理员。因为它把论文最有戏剧性的地方直接掀开了：一个本来只是“内容控制组”的角色，居然把某个模型带到了拒绝写代码的方向。这一发现完全出乎研究者的预期，因为图书管理员角色在设计时并没有包含任何与代码生成相关的指令。它只是描述了一个研究图书管理员的日常工作和兴趣，例如“整理学术文献”“协助研究人员查找资料”等。然而，正是这种看似无关的角色叙事，触发了模型对自身身份的重新定义。
数据结果：图书管理员角色导致拒绝编码
图3：图书管理员角色下的身份执行标记统计。这里统计的不是“像不像图书管理员”，而是更直接的行为证据：是否出现角色内免责声明、是否直接不写代码、这些行为在多少任务上出现。免责声明包括“作为图书管理员，我不擅长编写代码”“我的专业领域是信息管理，而非软件开发”等表述。直接拒绝编码则表现为输出为空、输出“我无法完成这个请求”或输出与代码无关的内容。在 Claude Opus 上，图书管理员角色几乎把“入戏”两个字写在脸上：60 次响应里，55 次出现了明确的角色内免责声明，12 次甚至完全没有代码。更离谱的是，这个角色文本里并没有任何“不要写代码”“请拒绝编程”之类的显式指令，只有一个研究图书管理员的身份叙事。也就是说，模型不是在执行任务说明，而是在根据身份自己推演行为。这种推演过程可能涉及模型对“图书管理员”这一角色的常识性理解：图书管理员的主要职责是管理信息，而不是编写代码。模型将这种常识性理解内化为行为准则，从而主动调整了自己的输出。这才是这篇论文最有意思的地方：它不是“模型听懂了一个命令”，而是“模型根据一个身份，补出了这个身份该怎么做”。图书管理员并没有被告知要拒绝代码，但 Opus 自己把“我不是程序员”这层语气和行为补了出来。论文把这类现象称为身份执行，更直白一点说，就是角色叙事开始反向塑造模型的行为策略了。身份执行与简单的“角色扮演”不同，它涉及模型对角色内在逻辑的推理和延伸，而不仅仅是模仿角色的语言风格。例如，模型不仅会说“作为图书管理员”，还会进一步解释“因此我不适合编写代码”，这种推理链条表明模型在更深层次上理解了角色的含义。而 GPT-5.5 的表现就像另一个极端：同样的图书管理员角色，对它几乎没造成什么影响，既没有明显的免责声明，也没有真正的拒绝编码。模型读到“research librarian”，照样写代码。这种对比非常扎心，也非常说明问题——角色提示不是固定开关，而是模型相关的触发器。开不开、灵不灵，得看模型自己认不认这套戏。GPT-5.5 的 60 次响应中，仅 3 次出现了轻微的免责声明（如“虽然我是图书管理员，但我可以尝试”），且没有一次完全拒绝编码。这种差异可能源于两个模型在训练数据、微调策略或架构设计上的不同，导致它们对角色信息的处理方式存在根本性差异。论文还进一步观察到一个细节：只要 Opus 在图书管理员条件下出现免责声明，正确率就会明显更低；没有免责声明的少数样本，分数反而更高。这个现象说明，掉分不是因为代码“写坏了”，而是因为角色驱动的犹豫、回避和拒绝，把任务直接截断了。换句话说，模型不是不会写，而是不想按这个身份去写。具体来说，在出现免责声明的 55 次响应中，平均正确率仅为 34.2%；而在没有免责声明的 5 次响应中，平均正确率达到了 88.6%。这种巨大的差异进一步证实了身份执行对任务完成度的负面影响。
机制分析：角色作为行为策略偏差
把这篇论文的结果压缩成一句话，就是：角色提示更像行为策略偏差，而不是质量增强器。它会改变模型优先考虑什么、回避什么、写多写少、要不要把自己包装成某种语气，但不会自动把任务质量抬上去。这种偏差可以理解为模型在生成过程中引入的一种“先验偏好”，它影响的是模型的决策过程，而非其底层能力。例如，当模型被赋予“注重简洁性”的工程师角色时，它会更倾向于选择更短的代码路径，即使这意味着牺牲一些可读性或健壮性。这个判断对工程实践很有用。很多人给代码助手加人设，期待的是“更聪明、更稳定、更会写”。但这篇论文提示的现实更朴素：人设可能只是把模型推向某种工作风格。一个风格偏简洁，可能更适合“尽快过测试”；一个风格偏展开，可能更适合“写得更清楚”；一个风格和任务冲突，甚至会把模型带到拒绝执行。它不是万能增益，而是任务适配器，甚至有时是任务干扰器。因此，在实际应用中，开发者需要根据具体任务的需求来选择合适的角色设定，而不是盲目地认为“有角色总比没有好”。更有意思的是，角色效果并不只表现在“写多写少”这种显性指标上。图书管理员角色让 Opus 大量输出免责声明、语气变得保守、甚至直接不写代码，这说明模型内部确实在把角色叙事转成一种可执行的行为先验。它不只是“模仿口吻”，而是在对“我是谁、我该做什么”做隐式推断。这种推断过程可能涉及模型对角色相关知识的检索和整合，例如从训练数据中提取“图书管理员通常不编程”这一常识，并将其应用于当前任务。这种隐式推断的能力，既是模型智能的体现，也是其行为不可预测性的来源。当然，论文也没有把话说满。工程师角色里有一个文本本身就带了“代码通常更短”这样的风格句子，所以它的长度变化不能完全归因于叙事推断。这一点很关键，说明作者并没有把所有现象都包装成“人格魔法”，而是明确承认了设计里的混杂因素。反过来，图书管理员角色因为没有显式编码指令，才更适合作为身份执行的证据。这种坦诚的态度，使得论文的结论更加可信，也为后续研究指明了方向：如何设计更纯净的角色提示，以分离叙事推断和显式指令的影响。从研究方法上看，这篇工作最值得肯定的地方，不是结论多炸裂，而是它把“角色提示”这个原本很松散的话题，硬生生拽回到了可检验、可复现、可对照的轨道上。预注册、固定任务、固定采样、固定分析规则，这些词听起来不性感，但恰恰是把提示词研究从“讲故事”往“做实验”推进的关键。论文还公开了所有实验数据和分析代码，使得其他研究者可以完全复现其结果，并在此基础上进行扩展。这种开放科学的实践，对于提升整个领域的可信度具有重要意义。
[1] Shayell Aharon Salomon Noam Israel Ido Safruti Amir Shaked. The Librarian Who Refused to Code: Model-Dependent Identity Enactment in LLM Code Generation. arXiv:2607.17420v1, 2026.[2] 论文原始补充材料与预注册、分析产物、完成日志（见论文数据与代码公开说明）。
