在易歪歪里使用时间变量，核心是把系统时间、对话时间和时区信息绑定到预设话术的占位符，并通过条件分支按时间触发或调整话术。先确定需要的字段（当前时间、对话开始时间、工作时段），再在规则中引用变量并设定格式（如YYYY-MM-DD HH:mm），最后在不同时间段和时区下测试输出是否符合预期，确保时区统一，避免夏令时混乱，逐步验证、再上线。
理解时间变量的基本概念
时间变量其实就像一个会随时变换的“标签”，它在对话进行时被替换成真实的时间信息。用简单的话说，你把一个空位留给时间，系统来填充这个空位，这样你的话术就会在不同时间段显示不同的内容。把这个概念拆开来看，时间变量至少包含两个方面：一个是时间的来源（它来自哪儿，是系统时钟、对话发生时刻还是客户所在地的时间？），另一个是时间的呈现方式（需要用什么格式来呈现，是年月日时分秒，还是仅显示星期几等信息）。下面用几组要点把它讲清楚。
- 时间来源：系统当前时间、对话开始时间、客户时区、公司时区等。不同来源在跨时区场景下会影响最终的显示文本。
- 时间格式：常用格式有 ISO 8601、中文常用格式（2026年03月31日 14:25）、简洁格式（14:25）。在易歪歪中，最好统一使用一种明确的格式，以方便规则解析和后续对比。
- 时间场景：工作日/周末、工作时段、非工作时段、节假日、客户首次对话/再次对话等，这些场景通常通过条件分支来驱动不同话术。
- 时区与夏令时：时区偏移、夏令时规则会影响时间的显示和触发条件。务必在全局规则里固定一个统一的时区，或对关键场景做时区独立处理。
- 占位符的替换时机：变量通常在消息发送前夕替换成实际值，确保文案里的时间信息是“刚好现在”的，而不是久未更新的快照。
常用时间变量的命名与用途示例
下面列出一些常见的占位符思路，便于理解与设计。注意：具体字段名需以你所在平台的实际变量名为准，以下只是示例以帮助理解。
- {{current_time}}：当前系统时间，常用于在对话中给出“现在的时间”。
- {{dialog_start_time}}：对话开始时间，便于计算对话持续时长或在第一条消息中给出开场时间。
- {{weekday}}：星期几，用于区分工作日与周末的回复策略。
- {{timezone}}：时区信息，用于在跨地区场景中对齐时间显示。
- {{date_only}}：年月日，适合只显示日期的场景。
- {{time_only}}：时分，用于简短的“现在是几点”的场景。
| 变量名 | 用途 | 示例值 |
| {{current_time}} | 当前系统时间的完整显示 | 2026-03-31 14:25 |
| {{dialog_start_time}} | 对话开启时刻 | 2026-03-31 14:15 |
| {{weekday}} | 当前是工作日还是周末 | 星期三 |
| {{timezone}} | 所用时区 | Asia/Shanghai |
在易歪歪中设定时间变量的具体做法
把时间变量落地到实际规则里，核心是把“时间字段的获取”和“话术的输出文本”这两件事绑定到一起。你可以把它看作两个环节的对话：第一步从系统拿到时间，第二步把拿到的时间填进话术里并决定要不要根据时间来切换措辞。
- 第一步：确定时间字段
- 需要当前时间时，用 current_time；
- 需要对话起始时刻，用 dialog_start_time；
- 需要对工作日与非工作日区分，用 weekday；
- 需要知道时区，用 timezone。
- 第二步：在规则中引用变量
- 在你要发送的话术文本中，插入占位符，例如“现在是 {{current_time}}，请问需要我在这个时间段继续为您服务吗？”
- 设置一个时段条件：若 current_time 在 09:00-12:00 之间，则走“上午问候”分支；若在 18:00-21:00，走“晚间问候”分支。
- 第三步：设定格式与时区
- 统一格式：YYYY-MM-DD HH:mm，避免歧义；
- 统一时区：大多数场景建议以公司所在时区为准，必要时对客户时区进行转换。
- 第四步：测试与上线
- 用不同时间点进行模拟对话，观察变量是否正确替换并触发正确的分支；
- 在真实场景中并行监控，记录异常时间点以便后续调整。
工作时段与时区处理的要点
要点1：统一时区。在规则编辑器中统一设定时区，不要让不同规则环节因时区解耦而产生错配。
要点2：夏令时的影响。夏令时会导致“某些时段不存在”或时间跳变，尽量用区域化规则或明确的时段范围来规避。
要点3：测试覆盖。覆盖工作日、周末、上午、下午、夜间等典型场景，确保每种场景下输出文本正常。
示例场景与模板
下面给出几个常见场景的简易模板，便于你直接理解和改造。注意占位符请按你实际平台的变量名来替换。
- 工作日早间问候
- 条件：weekday 为工作日，current_time 在 09:00-12:00
- 话术：早上好！ 现在是 {{current_time}}，请问今天有什么可以帮您的？
- 工作日午间提醒
- 条件：weekday 为工作日，current_time 在 12:00-13:00
- 话术：中午好，记得休息一下，当前时间是 {{current_time}}，需要我帮您安排回访吗？
- 非工作日自动安静模式
- 条件：weekday 为周末，current_time 在任意时间段
- 话术：周末好，若需要紧急协助，请留言，我会在工作日第一时间处理。 当前时间是 {{current_time}}。
常见坑与排查
在真实场景里，时间变量容易遇到一些“看不见的坑”。下面把几类常见问题和排查思路整理给你，方便你快速定位与修正。
- 时区错配：确认全局时区设置是否一致，尤其是在跨区域客服组和跨平台对话中；若不可控，考虑在变量中显式传入时区信息。
- 格式不一致：统一采用同一文本格式，避免格式错乱导致变量替换失败或呈现异常。
- 变量未渲染：检查占位符是否被正确识别为变量而非原文文本，排查模板中是否有转义符或错误语法。
- 夏令时异常：特别是在跨时区运作时，某些时段可能不存在，需在规则中写清楚边界条件。
- 跨平台差异：不同聊天工具对占位符的语法支持可能不同，确保在目标平台的文档中核对变量名称和用法。
进阶用法：与条件逻辑和数据对接结合
与时间触发条件结合的高级场景
把时间变量与条件逻辑结合，可以实现更加灵活的分支策略。核心思想是“在某个时间段输出A，在另一个时间段输出B”。
- 多段时段分支：09:00-12:00 发送问候A，12:00-18:00 发送问候B，18:00-23:00 发送晚间提示C。
- 工作日与周末差异：工作日使用正式模板，周末使用休息/温柔模板。
- 节假日的特殊文案：节假日根据日期段落调整，或调用外部日历数据注入特殊祝福文案。
示例逻辑（伪代码，便于实现理解）：
| 逻辑片段 | 描述 | 示例文本 |
| 条件 | 如果 weekday 为工作日且 current_time 在 09:00-12:00 | 输出工作日早晨文案 |
| 条件 | 如果 weekday 为工作日且 current_time 在 12:00-18:00 | 输出工作日午间文案 |
| 条件 | 如果 weekday 为周末 | 输出周末文案 |
与 CRM/工单系统的数据对接
时间变量还可以与后端数据结合，提升自动化效率。例如：根据客户最近一次联系时间决定是否触发催单提醒，或者在对话开始时带上最近一次跟进的时间戳，以增强人性化与时效性。
- 从 CRM 拉取最近联系时间，存入 {{last_contact_time}}，在对话中用于判断是否需要紧急跟进。
- 根据工单的 SLA 时间，使用 {{sla_deadline}} 来提醒客户当前进度和预计完成时间。
- 结合对话上下文，若对方在约定时间后仍未回应，可以触发一次“温故知新”的跟进模板。
边想边写的自然风格：把时间变量融入生活化的场景
很多时候时间变量不是生硬的“公式”，而是日常对话里的自然铺垫。你可以把它想成一个懂时髦、会记日程的朋友：现在几点了、我们正在谈论的事在什么时候开始、以及你所属的时区对话里应该怎么呈现。通过这样的思维，你的机器人就不会仅仅是一台冷冰冰的文本输出机器，而是一个“会时间的助手”，能根据时间给出更贴近人类习惯的回复。
- 把“时间感”融入开场白，让对话显得自然，例如在工作日的早上，用更正式的语气；在晚间用更温和的语气。
- 用时间来区分场景：在高峰时段减少冗长文本，提供简短的行动指引；在空闲时段给出更多可选项。
- 对跨时区的用户，明确告知当前显示的时间和你所在的时区，避免误解。
如果你愿意，我可以把其中一个场景直接改造成可直接上线的模板，或者把多个场景合并成一个自适应的规则集合。就这样先从一个简单的场景开始试水，慢慢扩展到更复杂的时间策略吧。