抱怨很真實，但不能直接拿來排工作

假設 API 有時回傳數字、有時回傳字串；UI/UX 又把固定折扣改成可展開的優惠明細。
前端夾在中間，很容易覺得所有變動都落在自己身上。

開發中有些 murmur 可以理解，但「後端很爛」無法轉成可驗收的修正。

這篇會先把問題改寫成觀察：同一欄位在兩個成功回應中型別不同，導致加總行為不一致。
這樣對方才能確認、重現與決定要修哪裡。

先分類，才能找對人

有些是契約缺陷，例如已約定金額為整數卻回傳文字。
有些是規格未定，例如 null 到底代表零還是未知。
有些是需求變更，例如現在要支援多張優惠券。

三者的處理不同。缺陷需要修復；未定問題需要決策；需求變更需要更新範圍與估算。
如果這時全部叫 bug，會把新增需求藏進修正工時。

對 UI 變更也一樣。 純粹更換間距，可能只影響樣式；把直接提交改成確認視窗，則新增取消、焦點管理與返回草稿等行為。 視覺上只多一個框，系統上可能多一段流程。

建一份小型決策紀錄

優惠報價的問題可以寫成：

• 觀察：折扣金額出現 null，畫面目前無法判定是無優惠或計算失敗。
• 影響：若補成零，可能讓使用者誤認可以用此總額結帳。
• 暫行處理：顯示報價尚未確認，保留購物車。
• 待決策：由 API 契約負責人確認 null 語意及錯誤格式。
• 完成證據：更新契約範例，串接環境能重現成功與失敗。

負責人與日期應填真實共識，不讓 AI 自動指派某位同事或捏造「已確認」。

Adapter 可以隔離變動，但不能替規格擦掉問題

Adapter 可以先理解成「轉接頭」或「翻譯員」。
如果後端回傳的欄位名稱、巢狀結構或資料格式和前端內部需要的格式不同，就在邊界集中轉換，讓 UI 和流程只使用自己的資料形狀。
例如後端回傳 money.value，內部可以轉成 amount；之後後端改格式時，主要只需要調整 Adapter。

若新舊 API 明確允許兩種格式，Adapter 可以在邊界做轉換，讓內部資料一致。
但轉換應可追蹤、有測試與移除條件。
它不是把壞資料修成好資料：如果收到未知狀態碼就一律當成功，或把未知金額補零，畫面看似可用卻失去可信度。
Adapter 可以隔離格式差異，不能自行創造業務語意。

也可以提議契約凍結點：先以某一版本開發，之後新增需求另記影響。
凍結不是拒絕變更，而是讓變更看得見。

可以交給 AI 的 Prompt

請把以下跨團隊問題整理成「可觀察現象、契約證據、影響、暫行處理、待決策與驗收方式」。不要推測責任歸屬，不替未知資料指定預設值。請區分契約缺陷、規格未定與需求變更。案例：優惠金額有時為 null；UI 新增優惠明細與確認步驟。

這段用的是 SA 的可追溯性：讓每個結論有來源，每個問題有待決事項。

今日練習與筆記

把最近一句「對方一直改」換成具體的前後差異，再列出受影響的畫面、契約與驗證。
會更容易談資源，也更容易找到能先完成的部分。

接著明天把第一週所有提問濃縮成一份開工前用得上的檢核表。