营运与维护 · 实作指南
客户没提电话，不等于让 AI 删除电话
辨别 JSON Merge Patch 的省略、null 与阵列取代语意，避免把未知资料变成删除指令。
AAHouse 原创解说视频，采用 AI 辅助概念画面、合成旁白及原创音乐。
英文逐字稿 · 简体中文普通话逐字稿 · 台湾华语逐字稿 · 澳门粤语逐字稿
一张交班便条
设想一家美国自行车维修店：客户说“请把取车备注改成周五下午”，AI 便生成客户资料更新。旧资料里还有联系电话。危险不在备注写得是否流畅，而在工具把“没提到电话”编码成了什么。以下是虚构的变更评审，不是客户事故或实测成果。
- 客户只改取车备注
- 旧记录仍有联系电话
- 先看变更含义，再看文案
未经修改的原始来源说明图。
候选甲：没有 phone 字段
如果接口明确采用 JSON Merge Patch，补丁只写 pickupNote，而不包含 phone，原电话成员保持不变。[1] 我们建议模型先输出“修改备注、保留其他字段”的业务意图，再由确定性代码生成允许的字段。不要为了让对象看起来完整，把未提到的值补成 null。
- 补丁：只包含 pickupNote
- phone 未出现
- 结果：原电话保持不变
未经修改的原始来源说明图。
候选乙：phone 为 null
同一协议中，{"phone":null} 的含义是移除现有 phone 成员，不是“我不知道电话”。[1] 因此，抽取阶段的未知状态不能直接复用为写入补丁。删除电话应有明确的用户意图与相应权限；“语法合法”不等于“业务获准”。
- 补丁：{"phone": null}
- 合并补丁中的 null → 移除成员
- 未知信息 ≠ 删除指令
未经修改的原始来源说明图。
还有一张容易误读的清单
客户若说“加上周末可联系标签”，也别让 AI 直接提交只含新标签的数组。Merge Patch 对数组采用整体替换，不是按项目追加。[1] 评审应展示更新前后完整列表，以及将消失的项目；若接口有专用追加操作，先核实它的实际契约。
- 原列表：[维修提醒, 邮件联系]
- 提交：[周末联系]
- 整体替换：旧项目不再保留
未经修改的原始来源说明图。
先核对门牌，再解释便条
这些规则只适用于已确认采用该格式的接口。JSON Patch 是另一种格式，以有序的 add、remove、replace 等操作表达更改。[2] 不能因为请求方法都是 PATCH，就把两者混用。记录实际 Content-Type、供应商文档与字段约束；若业务确实要保存 null，也应确认协议能清楚表达该需求。
- Merge Patch：对象描述变更
- JSON Patch：有序操作列表
- 同为 PATCH，不代表相同语义
未经修改的原始来源说明图。
给交班人一张验收单
建议用合成客户资料演练四种输入：未提及、明确删除、空字符串和新列表。预先写好期望差异，检查最终序列化请求，再在隔离环境读回结果。我们的验收目标是“未提及不变、删除有据、列表无意外丢项”，不是让 JSON 校验器只亮绿灯。这里给出测试方案，并未替你在业务系统执行。
- 输入：未提及 / 删除 / 空字符串 / 列表
- 核对：意图 → 序列化请求 → 结果
- 通过：无意外删除或丢项
未经修改的原始来源说明图。
把“不知道”留在读取端
给团队的最终约定可以很短：读取时允许“未知”，写入时必须说清“保留、设置、移除”。相关的缺值处理见 AAHouse《缺少栏位需要工作流程》；本篇补上写入端的语义检查。模型越容易生成结构化输出，这一道业务翻译就越值得明确。
- 读取状态：已知 / 未知
- 写入意图：保留 / 设置 / 移除
- 负责人审核差异，不只审核句子
未经修改的原始来源说明图。