營運與維護 · 實作指南
客户沒提電話，不等於讓 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《缺少欄位需要工作流程》；本篇補上寫入端的語義檢查。模型越容易生成結構化輸出，這一道業務翻譯就越值得明確。
- 讀取狀態：已知 / 未知
- 寫入意圖：保留 / 設置 / 移除
- 負責人審核差異，不只審核句子
已接受的區域說明圖重繪，並非未經修改的原始截圖。