Karpo 的主动监测不是独立于系统日历之外的第二套数据源，它读到的上限，等于“已经写进系统日历数据库、并且所在账户被授权并勾选”的那部分事件。读者感觉“日程只被看到一半”，多数情况不是识别不准，而是同步链路某一段没通：账户没勾选、刷新没触发、后台被省电策略掐断，或兴趣类推送的输入根本没进来。所以判断准确度边界的方法，是按链路的顺序逐段核对，而不是先怀疑模型。
先跑通链路再看准确度：账户勾选决定“能读多少”，刷新触发决定“多久能看到”，后台与省电策略决定“能不能持续看到”，兴趣开关决定“推送依据什么”。建议按设备来源 → 刷新触发 → 后台策略 → 兴趣输入的顺序逐段核对，每段都用可见事件数量或到达时间做验证；任何一段无法验证时，先停在那一层排查，不要把延迟问题当成识别问题。这套判断只适用于日历数据已进入系统数据库的场景，对纯第三方 App 内未落库的日程不成立。
列出设备上所有日程来源并确认勾选状态
监测的第一步是把“系统里到底存了哪些账户”和“其中哪些被允许读取”分开看。很多设备同时存在本地账户、厂商账户、邮件账户和第三方日历账户，默认勾选的往往只有一两个。先在系统设置的“账户与同步”或日历 App 的“要显示的日历”里逐项核对，也可以用调试命令拉一份账户列表做交叉验证：
adb shell content query `--uri` content://com.android.calendar/calendars \
`--projection` _id,account_name,account_type,calendar_displayName,visible,sync_events返回结果里的 visible 是勾选状态，sync_events 表示该账户是否允许同步事件，account_name 是账户来源。部分系统版本会限制该 provider 的访问，拉不到时以设置页面为准，不要据此下结论。核对动作是：让每个账户的 visible 状态与日历页面里实际可见的事件条数一一对应，勾选后页面事件数不增加，就说明该账户本身是空的，或者根本没写进系统数据库——后者超出监测范围。
确认刷新触发方式与改动到达时间
“没监测到”要先区分是延迟还是范围问题。做法是找到当前的手动刷新入口：常见位置是日历列表下拉刷新、系统账户设置里的“立即同步”开关，或通知栏的同步快捷开关。先记录刷新前某一天的可见事件条数，手动触发一次同步，再记录刷新后的条数。条数发生变化说明链路是通的，只是被动刷新被系统延后；条数完全不变，才回到上一节核对账户层。
跨设备到达时间建议用一张固定表格记录，不要凭印象判断：
- 修改时间：在设备 A 上新建或改动事件的时间点；
- 触发同步时间：在设备 B 上手动刷新或等到系统同步的时间点；
- 可见时间：设备 B 日历页面出现该事件的时间点；
- 结论字段：两次核对结果是否一致、是否只在手动刷新后才出现。
连续记录几次即可看出规律：如果总是手动刷新才出现，问题在自动同步触发；如果手动刷新也不出现，问题在账户权限或服务器侧，而不是监测逻辑。
检查后台运行与省电限制
同步和提醒依赖后台存活，省电策略是最容易被忽略的一层。需要核对的开关通常有三类：应用的后台运行权限、自启动或关联启动权限、以及电池优化白名单。可以用命令确认当前状态，再和设置页面对照：
adb shell dumpsys deviceidle whitelist
adb shell cmd appops get <包名> RUN_IN_BACKGROUND
adb shell cmd appops get <包名> RUN_IN_ANY_BACKGROUND
adb shell dumpsys battery验证方式是记录“开启限制前”和“解除限制后”的行为差异：解除电池优化、允许后台运行后，同一批事件在无人操作时是否开始按期出现，提醒是否恢复。若解除限制后仍无变化，说明瓶颈不在省电策略，应回到刷新触发那一层；若限制一开就断，那监测的时间边界就是系统允许的后台窗口，而不是配置写明的刷新频率。
核对兴趣类监测的输入来源与开关
兴趣类推送依赖的是“已被读取并允许用于分析的可见数据”，以及推送频率这一项设置。先确认输入来源：查看设置里可见的兴趣标签由哪些字段生成，通常来自事件的标题、地点、参与人名称这类文本；如果这些字段在授权时被关闭，或者事件本身只有时间没有文本，兴趣标签就缺少输入，推送自然不准。再确认推送频率选项的档位含义，逐档切换观察列表与提醒的实际表现。
验证动作是关闭兴趣开关后记录两点：列表里的兴趣条目是否消失、提醒是否停止；重新打开后再记录一次。如果关闭后列表仍出现相关条目，说明该条数据来自别的入口而非兴趣模块，需要回到账户层确认来源。兴趣监测的边界很清楚：它看不到未授权字段，也看不到没有写进系统日历的事件。
按覆盖度清单做一次自测
把上面四层压成一张可复现的清单，按顺序做，每项只看预期结果是否成立：
- 账户勾选与可见事件数一致——预期：勾选的账户在日历页面都有对应事件。异常时下一步核对账户层：该账户是否允许同步事件、是否为空。
- 手动刷新后新增事件出现——预期：手动触发同步后条数增加。异常时下一步核对同步层：账户凭据是否失效、同步开关是否被关。
- 跨设备改动在预期窗口内到达——预期：无需手动操作也能出现。异常时下一步核对策略层：后台运行与电池优化是否拦截。
- 后台限制解除后行为恢复——预期：解除后按期出现。仍无变化则回到第 2 项，不要继续往下推。
- 兴趣开关与频率设置符合预期——预期：关闭后列表与提醒同步消失。异常时下一步核对输入层：兴趣标签来源字段是否被授权。
五项全部通过，说明同步链路已跑通，此时再出现的漏看属于识别或分类层面的问题；任何一项不通过，监测的准确度边界就停在那一段，先修链路，不必调其它设置。