需求2026-08-14-26574 日程冲突判定的逻辑优化_产品方案

来源:需求2026-08-14-26574_日程冲突判定的逻辑优化_产品方案_v0.1_20260814.md

需求2026-08-14-26574 日程冲突判定的逻辑优化_产品方案

版本:v0.1 | 创建日期:2026-08-14

需求来源:CRM 产品需求池(object_dHaQq__c,编号 2026-08-14-26574

优先级:P1

文档状态:待确认

使用原则:本模板结构固定适用于 PRD、需求方案、评审方案和研发宣讲材料。初稿、简版、提纲或评审摘要也必须保留全部模板章节;“简”仅表示章节内容简洁,没有事实或不涉及时写“无”“不涉及”或“待确认”。复杂需求或方案点较多时,建议先补充整体流程图,再展开流程、规则、异常、权限、字段和影响范围。关键判断应在对应段落就近标注依据,不建议只集中放到文末。


需求变更记录

变更日期变更人变更内容
2026-08-14孙浩创建需求(原文:日程冲突判定的逻辑优化)
2026-08-14孙浩用通俗语言重写冲突判定规则,去除技术符号表达(“首尾相接不冲突”口径不变)
2026-08-14孙浩修正全天日程口径:代码核实后“两个全天日程同一天必冲突”证据不足,先列入待确认
2026-08-14孙浩产品拍板两个全天日程口径:同一天冲突、跨天不冲突;写入正文目标与规则,待确认项改为研发核对代码实现
2026-08-14孙浩实测确认:同一天两个全天报冲突、跨天不报冲突,当前实现符合口径,本期不改动;从正文与待确认中移除“需修正”表述,全天判定不再作为需求范围

依赖需求 Story 列表

ID需求描述涉及端与开发人员是否有依赖项备注
独立逻辑修正,无阻塞性依赖

一、需求概述

1.1 客户反馈

客户反馈结论: 用户新建日程时,与参会人已有日程只是“首尾相接、没有重叠”却被系统提示为时间冲突。用户期望优化为“首尾相接不算冲突”。本需求暂未关联独立需求反馈记录(关联反馈数=0),场景原文取自需求池需求简介。

需求编号反馈客户客户级别反馈人业务场景示意图
2026-08-14-26574内部(孙浩整理,无独立客户记录)未识别孙浩参与人为我和 B;
B 当前已占用日程为 10:00-11:00 与 12:00-13:00。
此时我新建一个日程 11:00-12:00,系统提示日程冲突。期望逻辑:11:00-12:00 与 10:00-11:00、12:00-13:00 都只是首尾相接、时间上没有重叠,应判定为不冲突。
无(详情接口未返回示意图下载地址,待页面复核)

1.2 系统现状

当前日程冲突判定存在首尾相接被误判为冲突的问题。用大白话解释根因:

  • 一个正确的地方:判断两个日程“有没有重叠”的主逻辑,用的是“结束早于对方开始、开始早于对方结束”这种方式,首尾相接(比如 11:00 整结束、11:00 整开始)不会算成重叠,这部分是对的。
  • 一个不一致的地方:另一处(日视图、小日历取日程数据的入口)用的比较方式“松”了一档,把首尾相接也算成了重叠,于是出现误判。
  • 全天日程:没有结束时间的那类日程(如“出差”“休假”一整天)有单独一套处理。已实测确认其“同一天冲突、跨天不冲突”的口径正确,本期不在需求范围内。

结论:同一条“日程时间是否冲突”的判断,在不同页面入口的口径不完全一致,导致首尾相接的相邻日程有时被误报冲突,与需求描述现象一致。旧日程服务 fs-appserver-schedule 里有完整实现;新日程服务 fs-new-schedule 本地未见完整实现,前端最终走哪套需研发运行时确认。

1.3 竞品现状

竞品竞品分类竞品现状来源
Google Calendar主流日历产品不同日程首尾相接(前一段刚结束、后一段立即开始)默认不视为冲突,可无缝背靠背排期通用产品行为,待补充官方文档链接
Outlook / Microsoft 365主流日历产品默认首尾相接不冲突;但可通过“忙碌标记”影响忙闲呈现待补充官方文档链接

备注:竞品截图暂未采集,本期以竞品公开行为作为业务合理性佐证,来源链接待补充。

1.4 产品价值

消除日程冲突判定的误报:用户在背靠背排期(前一场刚结束、下一场立即开始)这一高频场景下不再被错误阻断,可以顺畅连续安排日程,减少“明明有空却提示冲突”的困惑,提升协同日程的可信度与排期效率。

1.5 需求目标

  1. 首尾相接不冲突:新建/编辑日程时,新日程与参会人已有日程只要时间上没有重叠(哪怕差一秒),就不算冲突。
  2. 全天日程视为整天被占用:没有结束时间的全天日程(如“出差”“休假”),视为占用当天全部时间,与当天任意时间段的普通日程都算冲突。
  3. 判定口径全局一致:所有页面入口对“是否冲突”的判断标准统一,消除首尾相接被误报的差异。
  4. 全天日程之间按日期重叠判定(已实测确认):两个全天日程,同一天视为冲突、跨天视为不冲突(如 8/19 全天与 8/20 全天互不冲突,各占各的天)。已实测验证:同日两个全天报冲突、跨天两个全天不报冲突,当前实现符合该口径,本期不改动。

二、产品方案

2.1 整体产品方案

把日程冲突的判定规则统一成一句大白话:

两个日程只要有一点点时间重叠,就算冲突;仅仅是“首尾相接”(一个刚结束、另一个接着开始),不算冲突。

“有没有重叠”按精确到秒的时间来算:只要两个日程存在哪怕 1 秒的共同时间,就判定冲突;如果只是前一个在 11:00:00 结束、后一个在 11:00:00 开始,这一秒不重叠,就不冲突。

全天日程单独处理:没有结束时间的日程(如“出差”“休假”),视为这一天全天都被占用。它和当天任何时间段的其他日程都算冲突。两个全天日程之间按“是否同一天”判定:同一天视为冲突,跨天视为不冲突(8/19 全天与 8/20 全天各占各的天,互不冲突)。该口径已实测确认(同日报冲突、跨天不报冲突),当前实现正常,本期不改动。

本方案不引入“忙碌/占用”状态标记能力——当前系统没有这个能力,本期不涉及。

时间有重叠

只是首尾相接、时间没重叠

时间完全没重叠

对端是当天全天日程

新建/编辑日程,选定时间与参会人

和任一参会人已有日程比时间

判定为冲突,提示参会人时间冲突

判定为不冲突,允许创建

2.2 具体方案说明

方案原则(一句话一个规则)

规则说明例外
有重叠才算冲突两个日程存在哪怕 1 秒的共同时间就算冲突
首尾相接不算冲突一个刚结束、另一个接着开始(时间无重叠)不冲突
全天日程占用全天全天日程视为整天被占用,与当天任意时间段日程冲突两个全天日程:同一天冲突、跨天不冲突
判定标准全局统一所有页面入口用同一套口径

用户操作主流程

  1. 用户新建日程,选好开始/结束时间,添加参会人。
  2. 系统针对每个参会人,查找他在目标时间段里已有的日程。
  3. 逐条对比:新日程和参会人的已有日程在时间上是否重叠。
  4. 只要和任一个人的日程时间重叠 → 提示“与 XX 时间冲突”,无法继续或需调整;如果只是首尾相接、或者时间完全不重叠 → 判定不冲突,允许创建。

关键规则

  • 怎么算重叠:只要两个日程存在哪怕 1 秒的共同时间段,就判定冲突;首尾相接(一个结束的瞬间 = 另一个开始的瞬间)不算重叠,因此不冲突。
  • 全天日程:开始时间按当天 00:00 算,视为结束时间是当天 23:59:59,所以和当天任何时间段的普通日程都重叠、都冲突。两个全天日程之间:同一天冲突、跨天不冲突。
  • 多个人:参会人里只要有一人的日程与新建日程重叠,就提示冲突;仅提示第一个冲突的人即可(沿用现状,是否列全可确认)。

异常场景

场景处理
新日程和 A 首尾相接、但和 B 时间重叠判定冲突(因 B 重叠),正常提示
新日程和某人当天全天日程同日判定冲突
两个全天日程同日判定冲突
两个全天日程跨天(如 8/19 全天 与 8/20 全天)判定不冲突(各占各的天)
历史上已经排好的背靠背日程只影响新建/编辑时的判定,历史数据不动(判定是实时的)

影响范围

  • 涉及端:Web 端 / 移动端日程创建、编辑、冲突提示;日视图与小日历的忙闲呈现。
  • 涉及代码:fs-appserver-schedule 的冲突判定与取数查询口径统一;fs-new-schedule 需同步核对(本地未见完整实现,需研发确认)。
  • 无新增对象、字段、接口、消息、埋点、报表、开放能力。

2.3 待确认事项

ID待确认事项影响范围负责人结论
1前端最终走fs-appserver-schedule 还是 fs-new-schedule 的冲突判定?两套口径是否都需要统一?判定代码落点研发待确认
2冲突提示是否仅显示首个冲突人员(沿用现状),还是需列出全部冲突人员?提示交互产品待确认
3需求池记录的示意图未取到下载地址,是否需要在页面复核补充?文档证据孙浩待确认

说明:全天日程“同一天冲突、跨天不冲突”已实测确认当前实现正常,不再列入待确认(见 1.5 需求目标第 4 条)。


三、规范检查项

3.1 业务文案多语言 Key

本需求主要调整判定逻辑,冲突提示语沿用现有文案,不新增多语言维护项。

模块功能点示意图中文英文多语言 Key

3.2 需求埋点

本期不涉及产品埋点,写“无”。

埋点模块埋点描述示意图Key研发负责人备注

3.3 沙盒/更改集能力

模块功能点是否支持沙盒是否支持更改集说明
本期无新增对象/配置,不涉及

3.4 PaaS 国际化兼容检查

ID多语接入事项是否需要注意事项
1接入翻译工作台不新增多语模块
2CRM提醒无提醒改动
3企信消息提醒无消息改动
4修改记录无字段改动
5审计日志
6支持快捷翻译能力无输入框新增
7支持数据多语能力
8预置配置多语
9预置示例数据多语

3.5 新对象/新字段 BI 分析申请

对象/字段是否已做流程支持申请是否已做 BI 分析申请内容
本期无新增对象/字段

3.6 操作日志说明

本期无用户可见操作日志改动,写“无”。

3.7 需求风险点检测

ID风险分组风险类型有无该风险涉及风险的功能点影响的企业数是否报备响应策略
1对现逻辑有影响的风险点功能逻辑的调整日程冲突判定口径统一全体使用日程企业属逻辑修正,需灰度观察误报下降,无破坏性
2对现逻辑有影响的风险点交互体验有变化背靠背日程从“提示冲突”变为“允许创建”全体使用日程企业符合用户期望,属正向调整
3新能力风险点逻辑不完善
4新能力风险点有性能压力

3.8 上线策略

3.8.1 收费标准

  • [X] 不收费
  • [ ] 收费

3.8.2 上线节奏

  • [ ] 全网
  • [X] 灰度
灰度发布的原因属全局逻辑调整,建议灰度验证误判是否消除、是否引入新边界问题
预计全网时机待确认
期间分几次灰度待确认
各灰度批次的时间节点及灰度的客户范围待确认

3.8.3 适用版本

资源名称标准版专业版旗舰版无限版扩展资源包
日程冲突判定逻辑适用适用适用适用适用