系统整合 · 实作指南
让 Webhook 先进验证收件箱，再交给 AI
把接收、真伪验证与业务处理拆开，降低事件驱动流程的混乱。
收到事件不代表可以执行
Webhook 是外部系统进入工作流的公开入口。假设发票试点收到一份看似合理的 JSON，内容完整也不代表可以启动审批。应先按提供方的文件验证来源，再排入正式工作。GitHub 的签章文件是其中一个参考，但不能把另一家平台的演算法直接照搬。验证前可记录必要接收资讯，却不应让模型读取附件、寄信或修改客户帐目。
建立精简的事件收件纪录
验证後保存提供方事件编号、公司对应、收到时间与处理状态；持久接收成功後尽快确认，再由背景工作进行较慢的分类。使用事件本身的身份辨识重送，不依赖模型摘要。接收成功与业务完成必须分开：传输层已确认，并不表示会计系统已接受发票。介面可同时显示已接收、验证失败、等待处理及已完成，方便追查卡点。
流程一览
预先设计乱序与重播
不要假定事件必定按顺序到达。旧事件晚於新状态出现时，应先决定哪个系统是正式依据。涉及重要修改前，可重新读取来源纪录，同时保留事件历史以解释过程。管理员按重播也不能跳过权限检查；重播应沿用原本操作身份，检查现在的资料状态，避免把已取消的工作再启动。这项规则要写入操作手册，而不只藏在程式里。
用真实故障形状验收
用无害测试事件验证错误签章、重复传送、延迟更新，以及接收成功後处理失败。员工应能分辨遭拒流量与只是延误的工作。除了错误率，也要监察最旧未处理事件及核对结果。收件纪录会增加储存和维护成本；流量很少时可以采用较简单的受监察队列，但来源验证、重送与重播的决策仍须清楚，不能因此省略。
让事件收件纪录可见
可准备一个操作画面，显示收到时间、验证结果、处理状态和业务参考，支援人员不需开原始内容也能找到延误事件。用伪造事件与合法但未处理事件测试，确保两者原因不混淆。再确认事件被搬到失败队列後，画面仍保留可追查关系，避免工作离开主路径便消失。把这项能力列入交付，有助客户自己处理常见查询。
来源与延伸阅读
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。