资料修改审计

为什么需要结构化的变更审计

客户资料一旦落库，后续的每一次写入都应该是可追溯的。但很多系统只存了最新一版 JSON，改了手机号、调整了跟进阶段之后，无法回答「谁在什么时候改了哪个字段、从什么值改成了什么值」。直接对两份 JSON 做字符串比对也不可靠：字段顺序、空白、嵌套对象的键排序都可能变化，误报率高。

这个技能把两份纯 JSON 对象交给 fast-json-patch 的 compare，直接生成符合 RFC6902 的 patch 数组，让每一次字段级改动都有结构化记录。

核心能力与工作步骤

• 字段级差异计算：输入 old 和 new 两个对象，compare 输出 add、remove、replace、move 等操作，精确到 JSON 路径。
• 可读摘要生成：patch 之外，同时输出人类可读的变更列表，每条包含 路径 / op / 旧值 / 新值，便于直接展示给审核人员。
• 敏感字段脱敏：手机号、证件号等字段在摘要中做掩码展示，完整值只写入审计库，防止审计界面本身泄露数据。
• 回放校验：需要验证变更合法性时，可用 applyPatch 把 patch 应用到旧对象上，失败时捕获并提示路径冲突。

典型接入方式是在保存钩子中调用：

1. 保存前拿到旧对象快照与当前新对象；
2. compare(old, new) 得到 patch；
3. patch 为空则跳过写入，有变更才生成审计记录；
4. UI 层把 /mobile、/stage 这类 JSON 路径映射成「手机号」「跟进阶段」等中文字段名。

适用边界与注意点

• 只面向结构化 JSON：本技能处理的是字段级 diff，不适用于纯文本行 diff。如果需要对跟进笔记这类长文本做逐行对比，应使用专门的文本 diff 方案。
• 路径冲突要显式处理：applyPatch 可能因目标路径被占用或中间节点缺失而失败，调用方需要捕获异常并定位到具体冲突路径，而不是静默吞掉。
• 快照策略要配合：技能本身不负责存储旧对象，上层需要自行在写入前留存快照，否则无法生成有意义的 patch。
• 摘要不是数据源：脱敏后的摘要仅用于展示和审核，完整字段值必须从审计库读取，不要拿摘要反推原值。