个人工作台待办总漏掉，先别急着改提醒。用一个确定存在的待办做对照：工作台列表里根本找不到它，问题更可能在视图筛选或数据范围；工作台能看到它，但到期没有提醒，问题更可能在提醒机制。下面按“先确认看得见，再确认提醒到”的顺序，给出可复现的排查与处置方法。
要点总览（TL;DR）
- 判断入口是先确认工作台能否看到这条待办：列表里找不到，优先查视图筛选与数据范围；能看到但到期没提醒，优先查提醒机制。
- 视图筛选要逐项核对负责人、状态、标签、时间范围、所属项目，并重点检查字段空值；临时放宽条件后待办出现，即可作为筛选问题的证据。
- 提醒机制按触发条件、接收人、送达渠道、规则开关四个环节排查，再用一条测试待办验证提醒能否按预期送达。
- 字段缺失和查看习惯也会造成隐性遗漏，可连续记录一到两周的漏掉事件，按字段状态和查看行为反推原因。
- 处置后先用对照待办或测试待办验证恢复，再设一到两周观察期；修改共享视图或团队级提醒规则前先确认影响范围。
待办漏掉时先分清两类症状
“漏掉”是一个笼统感受，排查前要把它拆成可观察的具体症状。不同症状对应不同的排查入口，混在一起判断容易把筛选问题误当成提醒问题，反复调整提醒规则却始终无效。
常见的表现有三类：一是工作台列表里完全没有这条待办；二是列表里有，但排在视野之外，需要翻页或滚动才能看到；三是有且能看到，但到期或状态变化时没有被提醒。第一类优先查视图筛选和数据范围，第二类优先查排序与分组，第三类优先查提醒机制。第二类本质上仍是“呈现位置”问题，处置方式接近筛选，但原因在排序规则而非过滤条件。
| 症状 | 优先怀疑的环节 | 需要记录的观察信息 |
|---|---|---|
| 工作台列表里没有这条待办 | 视图筛选条件、字段取值、数据范围 | 待办名称、负责人、状态、标签、所属项目、截止时间 |
| 列表里有，但排在视野外 | 排序规则、分组方式、分页 | 期望出现的位置、当前排序字段、所在分组 |
| 能看到，但到期没被提醒 | 提醒触发条件、接收人、送达渠道 | 截止时间、提醒设置、接收人、渠道开启状态 |
排查前先做一次记录：挑一条最近被漏掉的待办，写下它的名称、负责人、状态、截止时间，以及你期望它出现在工作台的哪个位置。这份记录是后续对照验证的基准，也能在问题反复出现时帮助比对规律。记录时尽量使用系统里的原始字段值，避免用“应该快到期了”这类模糊描述。
用对照待办验证视图筛选是否把它挡在外面
判断视图筛选是否为原因，核心方法是找一个“确定应该出现”的对照样本。选一条你亲手创建、负责人是你自己、状态为进行中、截止时间在近期的待办，确认它在任务列表或项目里真实存在，然后回到个人工作台查找。找不到，就进入筛选条件逐项核对。
视图筛选通常由多个条件叠加，任何一个条件不满足都会把待办挡在外面。按以下顺序核对，每核对一项就记录该待办的实际取值：
- 负责人条件：视图是否限定为“当前用户”，而待办的负责人字段为空或指向他人；多人负责时，待办是否只挂在其中一人名下。
- 状态条件：视图是否只显示“进行中”或“未完成”，而待办处于待确认、已暂停等状态。
- 标签与类型条件：视图是否按标签、任务类型过滤，而这条待办没有打对应标签。
- 时间范围条件：视图是否限定“本周到期”或“未来七天”，而待办截止时间落在范围之外，或截止时间为空。
- 所属项目条件：视图是否限定在某个项目或空间内，而待办属于另一个项目。
核对字段取值时，重点关注空值。多数筛选条件对空值的处理是“不匹配”，一条没有截止时间或没有负责人的待办，可能同时被多个视图排除。这类情况表面看是筛选问题，根因在字段缺失，处置时要一并处理。
最后做一次放宽验证：临时把可疑条件去掉或改为“全部”，保存后刷新工作台，看对照待办是否出现。出现了，说明筛选条件就是原因，证据成立；仍然不出现，说明问题在数据范围或权限层面，需要继续向上排查待办是否进入了工作台的数据源。放宽验证完成后记得恢复原条件，避免影响他人使用共享视图。
确认工作台能看到后再查提醒机制
如果对照待办在工作台里能看到，只是没有被提醒到，排查方向转向提醒机制。提醒失效通常发生在四个环节：触发条件没有覆盖这条待办、接收人不对、渠道没有送达、规则本身被关闭。逐个环节验证，比反复新建提醒规则更有效。
先看触发条件。提醒一般绑定在截止时间、状态变化或自定义时间点上。核对这条待办的截止时间是否落在提醒规则的触发窗口内，例如规则设置为“提前一天提醒”，而待办是当天创建的，触发时点已经过去。状态变化类提醒则要确认待办是否真的发生了对应变更。
再看接收人。提醒的接收对象可能是负责人、关注人、项目成员或固定人员。多人负责的待办容易出现只提醒主负责人、其他协作者收不到的情况；负责人中途变更后，原提醒规则如果没有同步更新，提醒仍会发给旧负责人。核对当前负责人是否在接收人范围内。
然后看送达渠道。站内通知、邮件、即时消息等渠道各自有开关，也可能被系统静默、归入不常查看的入口，或被个人通知设置屏蔽。确认渠道处于开启状态，并检查是否存在免打扰时段覆盖了触发时间。
最后用一条测试待办验证：新建一条截止时间设在十几分钟后的待办，按同样的提醒规则配置，观察是否在预期时间收到提醒。收到，说明规则链路可用，原问题出在具体待办的字段或接收人；没收到，说明规则配置或渠道本身有问题，需要从规则层面修复。测试待办验证完成后及时关闭或删除，避免留在工作台里干扰后续观察。
字段设计与使用习惯造成的隐性遗漏
排除了筛选和提醒，仍有部分遗漏来自字段缺失和日常操作习惯。这类原因不会报错，也不会留下明显痕迹，只能通过一段时间的记录反推。
字段层面的典型情况是：待办创建时没有指派负责人，导致它不进入任何以“我的待办”为条件的视图；没有设置截止时间，导致时间范围类视图和到期提醒都无法命中；状态停留在草稿或未开始，被“进行中”视图过滤。这些待办在系统里真实存在，却在个人工作台上“隐身”。
习惯层面的典型情况是：创建待办后习惯性记在聊天记录或便签里，工作台只作为参考；每天只在固定时间扫一眼列表，新待办在两次查看之间到期；依赖记忆跟进，没有把待办状态回写到系统。这类遗漏的共同特征是，待办本身配置完整，只是没有被纳入日常查看路径。
区分两类原因，可以连续记录一到两周的漏掉事件，每条记录包含待办名称、漏掉时的表现、事后查到的字段状态、当时是否查看过工作台。如果多数漏掉事件的待办存在字段为空，优先修字段和必填规则；如果字段完整但当事人承认没有查看工作台，优先调整查看习惯和提醒触达方式。记录样本太少时不要急于下结论，至少积累五到十条再判断倾向。
处置步骤与恢复验证
排查结论不同，处置动作也不同。按原因分类处理，每类动作完成后都用对照待办或测试待办验证，确认恢复后再进入下一类。
| 原因类型 | 处置动作 | 验证方式 |
|---|---|---|
| 视图筛选 | 调整过滤条件或字段取值，使对照待办满足条件 | 刷新工作台，对照待办出现在预期位置 |
| 提醒机制 | 修正触发条件、接收人或渠道开关 | 测试待办在预期时间收到提醒 |
| 字段缺失 | 补齐负责人、截止时间、状态等关键字段，必要时设置必填 | 新建一条待办，确认关键字段被要求填写 |
| 使用习惯 | 约定固定查看时点，把待办创建纳入日常动作 | 观察期内漏掉事件数量下降 |
修改共享视图或团队级提醒规则前，先确认影响范围：这个视图有多少人在用，改动后哪些人的列表会变化，提醒规则变更会不会导致其他人收不到通知。影响范围不明确时，先复制一份视图做个人调整，验证有效后再决定是否推广。删除或重建提醒规则属于有风险的操作，执行前记录原规则配置，便于回退。
恢复验证分两步：先用对照待办确认它按预期出现在工作台并被提醒；再设定一到两周的观察期，期间记录是否还有新的漏掉事件。观察期内没有新增遗漏，可以认为问题已修复；仍有遗漏，回到症状分类重新判断，重点检查是否有第二类原因叠加。
在支持自定义视图和提醒规则的工作台工具中，这套排查可以落到具体配置上。以ONES为例，个人工作台可以按负责人、状态、时间等条件组织待办视图，提醒规则可配置触发时点与接收对象；排查时对照视图条件和提醒设置逐项核对，就能把“看不见”和“没提醒”分开定位。具体可配置项以你所用环境的实际界面为准。
减少复发的日常检查与规则约定
单次修复解决的是当前这条待办，复发预防要靠稳定的检查项和团队约定。以下检查可以按月执行，也可以在每个迭代开始时顺带完成。
- 核对视图条件：检查个人工作台视图的过滤条件是否仍符合当前工作方式，时间范围、状态条件是否随项目阶段变化需要调整。
- 核对字段必填：确认负责人、截止时间等关键字段在创建环节被要求填写，减少空值导致的视图不匹配。
- 明确提醒责任人：每条团队级提醒规则指定维护人，规则变更时记录变更时间、变更内容和影响范围，避免多人各自修改后互相覆盖。
- 新成员配置检查：新成员加入时，检查其个人工作台视图和提醒设置是否已按团队约定配置，避免因默认配置不同产生遗漏。
- 漏掉事件记录：保留一份简单的漏掉记录，写明待办、表现和事后原因，定期回看是否有重复出现的模式。
这些检查的价值在于把偶发问题变成可观察的信号。当漏掉事件连续出现且集中在同一类原因时，说明对应的配置或约定需要调整，而不只是修某一条待办。把检查结果和调整记录放在团队能看到的位置，下一次排查时就能直接对照，减少重复判断。
常见问题
工作台里能看到待办，但到期没有收到提醒，还需要回头查视图筛选吗？
通常不需要把视图筛选作为首要方向。工作台能看到这条待办，说明它已经进入视图的数据范围，筛选条件没有把它挡住。此时应集中检查提醒机制：提醒的触发时点是否覆盖这条待办的截止时间，接收人是否包含当前负责人，站内通知、邮件或即时消息渠道是否开启，规则本身是否被关闭。
有一种例外值得留意：如果待办在临近到期时被修改过状态或负责人，而提醒规则绑定的是变更前的条件，可能出现“看得到但提醒没跟上”。这种情况仍属于提醒配置问题，核对规则与待办当前字段是否一致即可。
放宽筛选条件后待办出现了，是不是直接改视图条件就行？
放宽验证只能证明筛选条件是直接原因，还要看这条待办为什么没有满足条件。如果原因是负责人、截止时间等关键字段为空，只改视图条件会让视图范围变宽，其他空值待办也会一起涌进来，列表反而更难用。更稳妥的做法是同时处理字段：补齐这条待办的字段值，并在创建环节对关键字段设置必填或提示。
修改共享视图前先确认有多少人在使用、改动后谁的列表会变化。影响范围不明确时，先复制一份视图做个人调整，验证有效后再决定是否推广到共享视图。
多人负责的待办，提醒经常只有主负责人收到，怎么排查？
先核对提醒规则的接收对象设置。接收人可能配置为负责人、关注人、项目成员或固定人员，多人负责时如果规则只取主负责人，协作者就不会收到提醒。其次检查负责人变更记录：待办中途更换负责人后，原规则若未同步更新，提醒仍会发给旧负责人。
验证方法是新建一条多人负责的测试待办，按现有规则配置截止时间，观察每位负责人是否都在预期时间收到提醒。缺谁的提醒，就回到接收人配置里补上对应角色或人员，而不是给每个人单独建一条重复规则。
漏掉事件记录要记到什么程度才有判断价值？
记录的目的是区分原因类型，不需要写得很长。每条记录包含待办名称、漏掉时的表现（列表里没有、排在视野外、到期没提醒）、事后查到的关键字段状态（负责人、截止时间、状态是否为空）、当时是否查看过工作台，这四项就够用。
样本太少时容易误判，建议至少积累五到十条再下结论。如果多数漏掉事件的待办存在字段为空，优先修字段和必填规则；如果字段完整但当事人确实没有查看工作台，优先调整查看时点和提醒触达方式。两类原因也可能同时存在，记录时要分开标注。
观察期内又出现新的遗漏，应该从哪里重新查起？
先回到症状分类，判断这次遗漏属于哪一类，不要直接沿用上次的结论。常见情况是只修复了第一类原因，第二类原因仍然存在，例如视图条件已调整，但新建待办时负责人字段仍经常为空，导致新待办继续被挡在外面。
重新排查时对照上次的记录逐项比对：同样的视图条件是否被其他人改动过，提醒规则是否在变更后覆盖范围缩小，新成员是否按团队约定配置了视图和提醒。把这次的原因补充进漏掉记录，连续出现且集中在同一类原因时，说明对应的配置或约定需要整体调整，而不只是修某一条待办。
