先确认缺的是功能，还是配置与使用方式
假设团队已有订单系统，却经常漏看即将到期但尚未发完的订单，希望增加提醒。开始开发前先核对三件事：当前账号是否有相关权限，系统是否已有可配置的筛选或提醒，现有功能是否因为数据缺失而无法使用。
如果交期字段大多为空，新增提醒工具仍然无从判断；如果已有提醒只是未配置收件人，先调整配置更直接；如果功能原本可用却失效，应按故障处理。只有确认是尚未满足的需求，才进入扩展方案比较。
补一项提醒，有三条常见路径
| 路径 | 适合什么条件 | 需要注意 |
|---|---|---|
| 使用原系统配置 | 已有筛选、计划或提醒能力 | 核实权限、字段含义和实际触发条件 |
| 导出后生成提醒清单 | 能取得包含交期和发货状态的文件 | 显示导出时间，提醒结果不是实时状态 |
| 通过获准接口扩展 | 接口开放必要数据，存在明确授权 | 确认更新频次、失败反馈、字段与权限边界 |
接口文档中的具体能力才是依据，不能因为“系统有接口”就假设所有数据都可读取或修改。若只能通过页面取得信息，还应评估登录、页面变化和运行维护，确认增加的负担是否值得。
用一个具体提醒说明边界
假设订单 SO105 的承诺日期为 6 月 14 日，订购 20 件，已发 8 件。团队约定在 6 月 12 日检查“未来两天内到期且未发完”的订单，日期范围包含 6 月 12 日至 6 月 14 日。小工具据此显示 SO105 剩余 12 件，并给出原订单编号和数据取得时间。
人员应进入原订单系统查看并处理。若导出后又发了 12 件，旧清单仍可能显示未完成，因此清单要提示数据时点，并支持重新取得最新数据。它是一份帮助定位的待办，不能把过期副本包装成实时事实。
订单数据与提醒状态分开负责
核心订单数量、交期和发货事实继续由订单系统负责。小工具可以保存“已查看”“暂缓到某日”“负责人员备注”等提醒工作状态，但这些状态不能直接改写成“已发货”。如果确实要写回原系统，需要另行明确允许修改的字段、确认方式和失败核对。
例如人员在提醒工具里标记“已查看”，仅表示看过这项待办；订单是否完成仍要从原系统读取。把两者混成一个完成按钮，容易造成业务人员以为已经发货，而仓库实际没有处理。
第一期只验证一条完整路径
可以先支持一份约定格式的导出表、一个日期范围和一份待办清单，验证临近到期、已发完、交期缺失、订单取消四类记录。重复导入同一份文件时，不应产生多条相同待办；新文件到来后，应更新数据时点并重新判断业务状态。
交接时写清：怎样刷新数据、哪些信息来自原系统、哪些备注只保存在工具内、导出格式变化后找谁处理。如果后续原系统已支持所需提醒，还应能够导出必要的工作记录并停用辅助工具。一个合适的小工具应减轻一项具体负担，而不是不断复制整套业务系统。