Emoji 何时会让虚构角色显得 OOC（人设崩塌）？
对于虚构的 AI 角色，只有当 Emoji 符合角色设定、有助于传达信息且在预期的聊天格式中清晰易懂时，才应当使用。如果它带来的语气不符合该角色的选择、分散了对场景的注意力，或者让台词变得难以阅读，就应将其省去。一份简明的声音档案（Voice Profile）和一套可复用的审查流程，可以帮助你做出这一判断，而无需对每个角色都强推同一套规则。
从角色的习惯出发，而非套用通用的 Emoji 规则
Emoji 是角色书面语调（Voice）的一部分。在决定使用哪些符号之前，先确定角色在聊天中倾向于怎么做：他们是直接表达热情、文字精炼简短、以此缓和直白的言辞、用它来标注玩笑，还是干脆避免任何视觉修饰？答案应源自设定和具体场景，而不是源自“某种特定类型的人总是使用——或从不使用——Emoji”这种固有观念。
将这些特质转化为具体可见的选择。例如，一个言语简练的角色可能会偶尔使用一个 Emoji 来对朋友的好消息表示认可，但不会每句话都加一个。一个爱玩闹的角色可能会用一个表情来抖机灵，但在发出实用指令时则保持纯文字。这些都是写作层面的选择，而非社交规则；另一个角色完全可能会有不同的表现。
角色的声音还包括词汇、节奏、韵律以及典型的反应模式。出现 Emoji 时，对照这些已建立的模式进行检查，思考这听起来是否像是这个特定角色会发送的内容。Grammarly 的对话指南建议保持每个角色既定的声音风格，并确保任何变化在故事发展中都合情合理。
让 Emoji 在场景中发挥具体作用
一个有价值的 Emoji 能够立足，是因为它发挥了周围文字未能起到的作用。它可以标记一句玩笑性质的插话，让一句简短的回复显得更亲近，或者表明角色对某件小事感到高兴。如果去掉它之后，信息的含义和语气依然完好无损，那么它可能只是装饰性的，而非真正有用。
阅读整个对话来回，而不仅仅看单句话。一个在随性日常更新后显得很合适的 Emoji，如果出现在角色刚给出精确指示或转向严肃话题之后，可能会显得十分刺眼。如果场景给出了理由，风格的转变也可以是有意为之的：也许角色试图缓和气氛，或者他们的情绪发生了变化。如果没有这层语境，突然蹦出的一堆符号可能会让人觉得是无意间的语气崩坏。
尝试进行一次简单的修改测试：写下不带 Emoji 的句子，然后将其加回，对比发生的变化。如果 Emoji 以场景不支持的方式改变了角色表现出的态度，请将其删除或修改其前后的文字。
结合语境核实含义，而非仅看 Emoji 名称
Unicode 对 Emoji 进行编码主要是基于通用外观将其作为象形文字处理；它并没有为每一个符号赋予单一固定的含义。解释可能因语言、文化、语境以及不断变化的用法而异，而且 Unicode 字符名称可能无法准确捕捉发送者的本意。Unicode 的 Emoji 常见问题解答对此类差异进行了解释。
这就使得语境成为了比角色私下的符号名称词典更好的向导。留意 Emoji 前后的文字以及场景中所展现的关系。如果读者需要去猜测角色是在开玩笑、祝贺某人还是在结束对话，那么平实的文字措辞可能表达意图更为清晰。Emoji 可以辅助一句易读的台词，但不该由它来拯救一句含义本就模棱两可的话。
请记住，不同的读者对同一个标记可能会有不同的解读。如果这种模糊性对场景很重要，请用文字明确写出预期的行动或反应。如果无关紧要，少许的解读差异可能无伤大雅——但这应该是一种有意识的选择。
确保信息易于朗读和快速浏览
以读者接触到的方式来阅读聊天轮次：按顺序，连同相邻的消息一起读。重复的符号、扎堆的表情以及夹在句子各部分之间的 Emoji 可能会打断思绪，或者分散对对话本身的注意力。一个实用的审校标准是：读者是否能够快速理解消息，而无需在脑海中去翻译一连串视觉反应。
考虑这条消息被听见时以及被看见时的效果。W3C 的无障碍网页技术指出，Emoji 具有预定义的名称，可能与作者的本意不符；它还指出基于文本的颜文字可能会给屏幕阅读器用户带来困扰，并建议在网页内容中使用它们时提供文本替代。W3C WAI 的 H86 技术规范专门针对 HTML，但它的示例为写作者提供了一个实用的理由：避免让符号承担本可以用文字清晰表达的信息。
对于聊天角色而言，这并不意味着每条消息都需要无障碍注解。它的含义在于检查带有大量 Emoji 的台词在口语朗读时是否仍然讲得通，以及重要信息是否保留在文本中。如果 Emoji 仅仅是一种额外的点缀，它就不需要承担整条消息的核心要义。
在依赖某个符号之前，先测试跨设备渲染效果
Unicode 字符并不等同于各个设备上显示的图片。Emoji 可能以彩色或文本样式呈现，并且其视觉表现在不同平台之间可能会有很大差异。厂商还会自行决定其软件支持哪些字符和序列。Unicode 的常见问题解答描述了这种变异性，而 Unicode Emoji 规范 UTS #51 则记录了呈现样式选择器（Presentation Selectors）和 Emoji 序列。
对于虚构聊天体验，请在故事或产品所面向的重要环境中预览消息。检查该符号是否正常显示、是否会变成意外的文本样式字形或缺失字符图标（豆腐块），以及它是否会破坏换行或标点符号。Unicode 发布了针对特定数据版本的图表，包括来自主流来源的图像对比视图；这些都是有用的参考资料，但它们无法替代在实际目标界面中的检查。Unicode Emoji 图表说明了其图表源自带版本的数据，且相关图像可能会有更新。
如果渲染的变化会改变角色表面上的语气或使台词变得令人困惑，请选择更简单的符号或直接用文字表达想法。不要依赖某个特定厂商的绘图设计来让笑话或情绪起效。
执行精简的一致性检查
切合实际的审查可以使 Emoji 的决策具备复用性，同时不至于演变成死板的配额限制。对于每个角色，记录他们一般的聊天习惯、任何有特殊意义的例外情况，以及 Emoji 通常能发挥作用的场景时刻。然后用以下问题审查一部分消息样本：
这一选择是否符合角色已确立的习惯，或者场景是否明确促成了这一改变？
Emoji 在这行文字中起到了什么作用？
如果读者对该符号有不同的解读，或者听到其读音标签，消息是否依然清晰？
该符号在预期的聊天环境中渲染效果是否合格？
将不同角色的消息放在一起进行横向对比。如果每个人都在相同的地方使用相同的符号，寻找能够凸显他们各自节奏和反应的机会——不是通过给每个人分配死板的 Emoji 配额，而是回归他们各自的设定初衷。一致性意味着这种选择让人觉得是该角色自身做出的选择；它并不意味着角色在每个场景中的表现都必须千篇一律。
最终的检验标准很简单：当 Emoji 契合角色、服务于对话交流，并且能够经受住关键阅读环境的考验时，予以保留。只要其中任何一项未能通过，就修改这行文字，或者让词句本身来承载这一刻的情感。