为什么机器人的错误时段问候会打破真实感假象
针对特定时间的问候看似只是一句微不足道的客套话，但它其实也提出了一项事实性声明：系统知晓当前对话发生地的时间。如果在深夜说“早上好”，这种不匹配会使整个交互显得机械呆板或不可靠。切实可行的解决办法是：将任何时间表述建立在当前时间戳和明确的时区之上，确保问候语与界面其他位置显示的时间保持一致，并对边界情况进行测试。当缺失这些上下文时，一句简单的“你好”远比盲目猜测对方身处早晨更为稳妥可靠。
为什么时间错误给人的感觉不仅仅是措辞失误
诸如“早上好”之类的问候不仅是一种社交暗示，它同时也承载着信息。用户可以将其与同一屏幕上的时钟或自己所处的当地时间进行比对。当两者发生冲突时，这种不一致会立刻显现出来，并可能让问候显得机械冰冷。这是基于可见的不一致性得出的设计推论；它并不意味着每位用户都会产生相同的反应。
对对话式智能体（Conversational Agent）的研究表明，错误会影响人们对智能体的看法，尽管不同类型的错误所产生的影响各异。在一项关于具身对话智能体的研究中，轮次轮换（turn-taking）错误降低了用户的好感度，而某些连贯性错误产生的影响则有所不同。这一发现给我们带来的有益启示并不是说错误的问候时间一定会引发某种特定的反应，而是交互错误所塑造的印象会超出即时对话内容的本身。Adobe Research，《人机交互中的对话错误分析》
带有时间属性的问候还可能暗示系统具备它实际上并不拥有的感知能力。知晓当前的钟表时间，并不等同于知晓用户何时醒来、在做什么，或者他们将一天的哪个阶段视为“早晨”。可靠的时钟记录能为准确的措辞提供支持；但它并不能证明系统具备对个人的理解。
从时间戳和已知时区入手
应将当前时间和用户所在的本地时区作为两个独立的输入项对待。时间戳标识了时间线上的某一个点；时区则提供了将该瞬间表示为当地实际时间所需的规则。W3C 的指南对这些时间表示法进行了区分，并指出时区包含针对偏移量和夏令时调整的规则。指南建议在需要计算本地时间时使用时区标识符。W3C，《处理时间与时区》
对于软件生成的问候语，一个健壮的执行顺序是：
从系统时钟或其他可信的时间源获取当前瞬间。
获取已知能够代表目标用户或对话上下文的时区设置。
使用支持时区感知的格式化工具将该瞬间转换为对应时区的时间。
根据转换后的本地时间选择问候语，如果上下文不可用或已失效，则省略时间相关的表述。
在 JavaScript 中，Intl.DateTimeFormat 接受一个用于格式化日期的 timeZone 选项。如果应用程序忽略了该选项，则会使用宿主环境的当前时区，这可能是服务器或设备的时区，而非用户的时区。该格式化工具还可以根据同一时间瞬间生成界面中显示的时间和日期。MDN，《Intl.DateTimeFormat》
仅凭数值偏移量可能不足以应对未来或周期性的时间行为。类似于 Europe/London 这样的具名时区代表了一套区域规则；其偏移量可能会随日期而变化。IANA 解释称，其时区数据库会持续更新，以反映边界、UTC 偏移量和夏令时规则的变化。因此，软件既依赖于合适的时区，也依赖于相对最新的时区数据。IANA，《时区》
让问候语和可视时钟共用同一数据源
问候语和屏幕上显示的时钟应当派生自相同的时间戳和相同的时区上下文。如果一个组件使用浏览器的本地时区，而另一个组件使用服务器默认值，它们就可能在午夜前后或用户出行跨时区时产生冲突。如果界面显示了日期，请结合问候语一同检查：本地日期可能与服务器所在地的日期不同。
一个实用的实现规则是：针对对话事件计算一次本地时间，然后将该结果同时传递给问候语逻辑和界面显示。切忌单独要求语言模型从对话文本、设备上下文或记忆中的日程去推断时间。模型可以根据经过验证的值来组织措辞，但时钟计算必须来自时间数据。
如果用户未提供时区，且产品也没有可靠的本地设置，请避免声称当前处于某一特定的时段。“你好”在跨时区和跨时间时始终是准确的。如果某项任务必须明确时区，请以清晰、低阻力的方式向用户询问，而不是默默地将服务器的时区当作用户的时区。
审慎设定问候语的时段边界
早晨、下午和傍晚之间并不存在普遍通用、客观确定的界限。团队应将本地时间范围的划定视为一种产品层面的措辞选择，并验证所选的表述是否符合预期的基调。在配置或代码中明确界定这些范围，以便评审人员能够清楚看到每个边界点上的处理逻辑。避免使用暗示知晓用户作息规律的措辞，例如“你起得真早”，除非用户确实提供了此类信息且该信息在此情境下相关。
安全的回退机制应纳入整体设计之中。如果时间戳无效、时区标识符缺失或无法识别、亦或是转换失败，请使用中立的问候语。切勿在没有明确做出这种选择的情况下默认替换为服务器时钟。如果时钟读取可能存在延迟，一句宽泛的“你好”其时效性也远优于在消息等待显示的过程中就可能失效变错的问候。
测试转换节点与上下文，而不仅仅是普通下午的场景
在普通的本地时间进行常规正常路径（happy-path）测试，无法发现许多潜在的时间缺陷。请使用固定的时间戳和明确的时区，以确保结果具有可复现性，并重点检查以下情况：
紧接每个问候时段边界之前和之后的时间点。
本地午夜，包括本地显示日期与服务器日期变更不一致的情况。
在同一瞬间，处于不同本地日期的两个时区。
在实行夏令时的时区中，夏令时转换发生的时刻。
具有半小时或一刻钟偏移量的时区。
时区缺失或无效的情况，此时预期结果应为中立的问候语。
延迟发送的消息，检查其措辞是基于生成时间还是显示时间——以及该选择是否与产品的整体行为保持一致。
这些用例源自时区将瞬间映射到本地实际时间的方式，以及区域时钟规则可能会发生变动这一客观事实。测试套件应当让选定的行为显式可见，而不是依赖隐式的机器默认值。IANA 的版本发布历史记录了实际的规则变更，这也提醒我们：测试环境和部署的时区数据可能会过时。IANA，《时区数据库发布记录》
对于产品团队而言，切实的决策规则如下：
产品团队的实用决策准则
仅在满足以下三个条件时，才使用特定时间的问候语：可靠的当前时间瞬间、与对话上下文绑定的时区，以及问候语与任何可视时钟之间保持一致的格式。只要有任何一个要素存在不确定性，就应选择中立的措辞。如果系统仅仅知道时间，它可以准确地提及一天中的时段；但不应暗示它了解该人的日程安排、心情或活动。
单纯的一句问候并不能让助手显得细致体贴。它的价值取决于其所表达的微小声明是否与界面的其余部分相符。准确、克制的措辞能为交互奠定一个逻辑自洽的开端，同时将个性化的上下文留给真正能够提供它的人。