如何从一条日常信息重新设计 AI 角色的文本回复
一条实用的 AI 角色回复始于发送者的实际诉求和当下语境，而非标志性的口头禅。对于虚构的短信对话，首先明确发送者需要什么、已知什么以及仍有哪些不确定之处。然后为回复编写几条简短的规则，并用该信息的细微变体进行测试。这一过程可以让角色形象保持一致，而无需复制真人的私信或假装成真人。
从一段虚构的对话开始
使用一个虚构的、日常的情景。例如：
> Maya：“明天能把那个蓝色文件夹带过来吗？我把它放在前门旁边了。” > > AI 角色：“好的，我会带过去的。”
这是为本练习设计的一个虚构示例。发送者请求了一项具体行动：带上文件夹。“明天”给出了时间，“蓝色”指明了物品，而“前门”则给出了位置线索。接收者可以直接回答，因为该诉求足够具体，完全可以理解。没有必要虚构背景故事、推测情绪，或添加冗长的修饰来让回复听起来更具个性。
这种初步理解是一种设计层面的解读，并非每个读者必然都会推导出的结论。Google 的对话设计指南将用户的目标和语境视为交互设计的一部分，这为分析信息提供了一种实用的方法：同时记录任务及其周遭的情境。Google 对话设计概述
在起草规则之前，用浅显的语言写一份简短的信息摘要：
诉求：带上蓝色文件夹。
时间：明天。
地点或具体哪一个：前门旁边的蓝色那个。
不明确的细节：信息中未说明明天具体几点。
回复需要做到的事：确认该行动，且不添加未经证实的具体时间或承诺。
这份摘要是本文的决策辅助工具：它将单条信息转化为四项检查——行动、语境、不确定性以及回应任务。它有助于区分文本实际包含的信息与写作者可能忍不住想要补充的细节。
将诉求与角色语气区分开来
在注入语气之前，先写出最朴素、正确的回复：“好的，我明天会把蓝色文件夹带过去。” 这句话回应了诉求，并复述了足够的细节以确认角色理解无误。在此之后，再决定角色会如何自然地表达——也许是“没问题，明儿我顺手把蓝色文件夹带上。” 措辞变了；任务本身并没有变。
这种顺序使语气成为角色特质的表达，而不是对“理解诉求”的替代。如果一句话机智幽默或充满温情，却未能确认行动，它就没有完成回复的基本职责。相反，简短的确认依然可以通过常用的缩略表达、温和的感叹或特定的正式程度来展现个性。
保持语气规则客观可见。“听起来迷人”留下了过多的解读空间；而“使用日常词汇，避免复杂的玩笑，并将常规确认控制在一句话内”则为写作者提供了可以实际应用和比对的准则。W3C 万维网无障碍倡议在其关于清晰简洁写作的指南中，建议使用适合语境的简短、清晰的句子和简单的语言。该页面针对的是网页内容，因此将其应用于虚构的文本消息是一种设计选择，并非声称它规定了角色对话的写法。
将初稿转化为回复规则
针对这一对话的一套简明规则可以如下拟定：
优先回应所请求的行动。
在有助于确认理解时，复述关键物品或时间。
对于常规确认，使用一句自然简短的话。
不要凭空捏造信息中未确定的时间、地点或额外承诺。
如果缺失的细节会改变角色能采取的行动，提出一个有针对性的问题。
这些规则将任务处理与语气约束结合在一起。它们还明确了角色的行为底线：该信息仅支持确认明天会带上文件夹；它不支持承诺在某个具体时刻带过去，也不支持声称自己已经拿到了文件夹。
OpenAI 的提示词生成文档建议明确任务、约束和预期输出，并将示例描述为展示预期结果的一种可选方式。对于写作练习而言，这支持了将模糊的方向转化为简短、可测试的规则集，并将其与示例对话进行配对。但这并不意味着某一套措辞就能保证在每个模型中都产生特定的结果。OpenAI 提示词生成指南
每次测试一个细微变量
适用于某一条信息的规则，在相邻的类似情形下可能会显得过宽或过窄。保留基础对话，然后在每次测试中仅更改一个细节。这可以揭示哪条规则在发挥实用价值，以及哪种回复需要进一步明确。
测试信息：“明天能把蓝色文件夹带过来吗？”；变更内容：移除了位置线索；尝试的回复：“好的，我明天会把蓝色文件夹带过去。”
测试信息：“明天早上能把蓝色文件夹带过来吗？”；变更内容：缩小了时间范围；尝试的回复：“好的，我明天早上带过去。”
测试信息：“明天能把文件夹带过来吗？”；变更内容：去掉了颜色；文件夹可能指代不明；尝试的回复：“可以——你指的是哪个文件夹？”
测试信息：“能把蓝色文件夹带过来吗？”；变更内容：省略了具体日期；尝试的回复：“没问题。你想让我什么时候带过去？”
这些回复示例仅用于说明设计思路，并非实测结果。设置变量的意义在于检查当缺少标识特征或时间时，规则集会做出怎样的反应。Microsoft 关于消除客户意图歧义的指南指出，澄清可以缩小用户意图的范围，同时建议设计人员在清晰度与避免提出不必要的问题之间取得平衡。在这里，只有当缺失的细节影响到行动时，才会提出针对性的问题。
避免同时改变多项内容。如果你在一次测试中既更改发送者的措辞，又添加新地点，还调整了角色语气，就很难判断回复为何发生变化。一份简单的测试记录可以记下信息内容、测试中的规则、实际回复以及该回复适用的理由。将任何意外的回答视为修改规则或示例的契机——而不是断定角色需要更复杂性格描写的证据。
在不捏造语境的前提下处理不确定性
简短的短信往往会省略细节，因为发送者预期对方已经知晓。该练习应当尊重这一局限。如果信息中写的是“文件夹”，但可能有好几个文件夹都符合，角色可以询问是哪一个。如果对话中只提到过一个文件夹，写作者可以使用该语境。如果没有这样的语境，强行捏造确定性反而会降低回复对对话的忠实度。
Microsoft 关于兜底和转接的指南区分了“旨在寻求理解的回应”与“在无法满足请求时进行重定向的回应”。对于这一日常虚构场景，可以借鉴的思路其实很简单：当角色无法确切完成当下的对话任务时，为发送者提供一个清晰的下一步。像“你指的是哪个文件夹？”这样自然的澄清，比一句笼统的“我不确定”更有用，因为它指出了缺失的具体细节。
此外，还要区分不确定的推测与已知的事实。如果虚构的发送者提出了该行动请求且角色可以同意，那么“我明天会把文件夹带过去”就是一个明确的确认。而“我 9 点带过去”则添加了信息中从未提供的内容。设计周密的回复不应悄悄将猜测变成承诺。
测试后修正规则
测试之后，寻找具体的错配情况。角色是否在细节无关紧要时仍要求澄清？它是否确认了一个从未给出过的时间？语气规则是否让回复变得更长却未能更清晰？修正能够解释该问题的最小规则，然后重新运行相同的变体测试，看看这一修改是否在解决某个情况的同时导致了另一个情况变得生硬。
例如，如果原本的信息中已经说明了“明天”，而“询问时间”这一规则却导致了不必要的追问，那就将其优化为：“仅在日期或时间对于完成请求必不可少且尚未给出时，才询问时间。” 该规则描述的是一种决策条件，而非一刀切的习惯动作。将测试信息保留在规则旁边，以便后续的修改能够对照同一组少量案例进行检查。
其目标是建立一套可复用的写作方法：使用一段虚构的对话，厘清其诉求和语境，将回复的任务转化为几条可观察的规则，并测试临近的变体。如此一来，角色的语气便源于服务于对话的选择，而信息本身则始终是角色所知内容的边界所在。