營運與維護 · 實作指南
別讓 AI 覆蓋同事剛改好的紀錄
用伺服器端版本條件、三方比較和雙視窗演練，保護 AI 寫回紀錄時同事的最新修改。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 香港粵語逐字稿 · 澳門粵語逐字稿
兩個人，一份紀錄
設想一家美國維修公司：AI 讀取客戶紀錄，準備補充服務摘要；排程員同時把到訪時間改到下午。若 AI 稍後把讀到的整份舊紀錄寫回，摘要可能正確，時間卻被改回上午。這是虛構情景，但問題不在模型是否聰明，而在寫入時有沒有發現紀錄已經變了。
依已核准文章重繪的解說示意圖。
把版本一起讀進來
讀取內容時，也儲存伺服器端傳回的版本標記，例如 ETag。它不是讓模型猜的編號，更不能用本機時間臨時替代。擬議更新應帶著“基於哪一版”的依據；紀錄編號回答改誰，版本標記回答改的是不是仍然那一版。
依已核准文章重繪的解說示意圖。
讓伺服器端決定能否寫入
支援條件更新的 HTTP 介面可用 If-Match 攜帶已讀取的 ETag。RFC 9110 將它用於避免併發覆蓋；比較應由伺服器端在執行操作前完成，而不是助手先查一次、隔幾秒再無條件儲存。先查後寫之間仍可能有人改動。[S1]
依已核准文章重繪的解說示意圖。
衝突不是請再按一次
通常的 HTTP 條件不相符會傳回 412；Google AIP-154 的資源 etag 約定則使用 ABORTED。必須查目標介面契約，不能把所有衝突都當成網路失敗重試。建議把任務標為“需要比較新版”，而不是刪掉版本條件強行成功。[S2][S3]
依已核准文章重繪的解說示意圖。
比較三份內容，而非整份覆蓋
保留讀取時的原件、AI 擬改的內容、現在的紀錄。若同事只改時間，AI 只加摘要，可按明確規則重新構造窄範圍更新；若雙方改同一欄位，交給負責人判斷。即使欄位不同，也要檢查它們是否有業務依賴。這是工作流程建議，不是自動合併保證。重建後的更新仍須帶上新讀取的版本條件；提交前若再次發生變化，仍應報告衝突。
依已核准文章重繪的解說示意圖。
這道檢查不替你授權
版本相符只說明符合該介面的版本條件，不說明 AI 有權修改，也不保證內容正確。權限和業務審核仍要檢查。另一個容易踩的坑是 If-Match 的星號：它檢查資源存在，不等於鎖定原先讀到的版本；弱 ETag 也不能用於強比較。[S1][S2]
依已核准文章重繪的解說示意圖。
用兩個視窗做一次演練
測試環境裡，讓視窗甲讀取紀錄，視窗乙修改並儲存，再讓甲提交舊版更新。預期結果是攔截衝突、保留乙的修改，並顯示可理解的差異。接著測試雙方改同一欄位、重新讀取後仍再次變化，以及介面根本不支援條件寫入的情況。
依已核准文章重繪的解說示意圖。
採購問題比提示詞更重要
本週就問聯結器供應商：能否傳回版本、條件是否在伺服器端執行、衝突怎樣報告、能否只改指定欄位？若沒有可靠條件更新，先保持建議模式或採用經驗證的單寫入流程。儲存成功回條與新版本，再向團隊報告完成；別用“最後一次儲存獲勝”代替協作。
依已核准文章重繪的解說示意圖。