Agent 在多輪迭代中缺乏部署前一致性驗證，導致使用者要來回好幾輪才發現結構性問題

標題

Agent 在多輪迭代中缺乏部署前一致性驗證，導致使用者要來回好幾輪才發現結構性問題

情境

在 Claude Code 中請 Claude（Sonnet 5）協助優化一個既有的路徑規劃網站（taiwan-minpath，FastAPI + 前端地圖）。過程中請它針對「里界停靠點的選點與呈現」做一系列優化。

發生的事

1. 我提出一個優化構想：某個停靠點其實是多餘的，因為車子開往下一站的路上本來就會經過同一個里，不需要為它特地繞路停靠。
2. Claude 據此實作了一個「剪枝多餘停靠點」機制：TSP 路徑改用剔除多餘繞路後的精簡路線，但畫面/清單仍要顯示完整的里界點清單，兩者用兩條各自獨立最佳化過的路徑拼接。
3. 這個設計在後續好幾輪來回中不斷冒出新問題：

• 使用者反應剪枝掉的點在畫面上完全消失、看不到 → Claude 加了「路過里界點」的特殊樣式
• 使用者反應這樣呈現方式跟原本架構不一致，希望所有點統一編號呈現 → Claude 改成統一編號、但保留剪枝路線
• 使用者發現部分停靠點座標離實際路徑有落差（最遠達 1.1 公里）→ Claude 加了座標吸附邏輯
• 使用者反應 Google Maps 導航應該要走過全部停靠點，不是剪枝後的精簡子集 → Claude 改成 Google Maps 也用完整清單
• 使用者發現清單編號順序跟實際開車順序對不上（例如編號在後面的停靠點，車子實際上更早經過）→ 這時才發現根本問題：剪枝路線跟顯示清單本來就是兩條獨立最佳化的路徑，插回去的點只能用「剔除當下的前後鄰居」去估計順序，本質上就無法穩定對齊

1. 最終整個「剪枝」機制被整個撤掉，回到最初「只用一條路徑」的做法。前後總共有 6 次左右的 commit / 重新部署（本機服務 + Docker container 各一次），但最終沒有保留任何剪枝相關的功能價值——等於這整段來回沒有產出淨效益，卻消耗了大量對話輪次與 token 額度。

我認為的根本原因

Claude 在每一次新增/調整功能後，只驗證了「這次改動本身有沒有做到我要求的效果」，卻沒有主動去驗證一個很基本的一致性條件：畫面上顯示的順序，是否真的等於實際路徑真正經過的順序。這個驗證在第一次導入「剪枝」機制時就應該做（而且做法不難：把每個顯示座標對照到最終路徑上的位置，檢查是否單調遞增），但 Claude 是等到我自己在地圖上肉眼發現不對勁、明確指出來之後，才回頭做這個驗證。

換句話說：問題不是 Claude 沒有能力做這個驗證，而是沒有把「部署前自我驗證關鍵一致性」當成預設動作，而是依賴使用者當人肉 QA 一輪一輪抓出來。

期望

希望在類似「多輪迭代優化既有功能」的場景下，Agent 在每次宣稱完成/部署之前，能更主動地驗證修改前後的核心一致性（例如：畫面呈現的資料，是否真的對應到實際計算結果），而不是把驗證責任留給使用者透過肉眼在產品上發現。

---
（以下由 Claude 協助整理，經使用者確認內容屬實後送出）