审计人员抽到一笔由助手协助修改的供应商地址，要求说明依据和批准过程。团队有聊天截图、接口日志和审批单，却没有共同编号，只能靠时间猜哪几份材料属于同一次操作。
业务系统原有的修改记录应当继续作为主线。如果它已经关联审批和操作人，直接从那里出具材料更稳妥。跨了助手、规则服务和业务系统以后，缺的通常不是更多日志，而是这些记录之间可靠的连接。
可以从一次地址变更开始：业务服务保存变更编号、审批编号和实际字段差异，再关联 EasyNet 调用标识及规则版本。助手生成的说明只解释它做了什么，不能替代最终写入系统的那条变更记录。
审计查询入口接受获准的业务编号，返回相关证据和来源位置，而不是打包整个客户库。读取者的审计权限需要单独检查；运行方维护调用记录，业务负责人维护审批与变更记录，各自对自己产生的事实负责。
还需要约定保存期限、缺失记录的处理和可导出字段。如果某次调用没有留下规则版本，就应明确缺少这一项，不能拿当前规则补写历史。材料能互相关联，也不等于它天然满足所有审计要求。
用一笔测试变更准备材料，请没有参与执行的人复原请求、批准、运行和实际修改的顺序。再刻意移除一条审批关联，检查查询是否如实暴露缺口；这样才能判断它是否减少了临时拼截图的工作。
- 01
选中地址变更
明确业务变更编号
- 02
连接独立记录
批准、调用、实际差分
- 03
检查证据缺口
缺失记录不由模型补写
发现缺失的批准关联
本地合成证据关联检查，不生成审计证明，也不读取真实供应商资料。
本地示例 · python
change = {"id": "C-17", "approval_id": "A-9", "call_id": "demo-call-4"}
approvals = {"A-8": {"status": "approved"}}
missing = [] if change["approval_id"] in approvals else ["approval:A-9"]
assert missing == ["approval:A-9"]
print({"change": change["id"], "missing": missing})预期结果：C-17明确缺少A-9，不误用邻近的A-8批准。
接入时的检查项
- 审计人员能够区分任务请求、准入结论与业务修改成功三个事实。
- 人为移除一段证据时，报告显示缺失而不是推断其已发生。
- 相近时间的两次修改不会串用批准记录，敏感字段不进入普通日志。