一問一答寫出來的系統，很快就沒人敢改
每一輪對話都得到一個令人滿意的答案，這些答案合起來的樣子，卻很少有人完整看過。
每一段都完整，整體沒有人規劃
以 AI 開發系統時，最順手的方式是想到什麼就提什麼。加一個匯出 Excel 的功能、讓客戶可以分等級、某個步驟要能退回重簽。每一項 AI 都做得出來，而且做得相當周到。
這樣進行幾個月之後，系統裡累積了許多功能，也常出現以下狀況：
- 同一件事有兩三種做法，因為分別在不同的對話裡完成。
- 同一份資料存在好幾個地方，其中一處修改後，其他地方沒有同步。
- 部分功能是為了某一次的特例加上的，事後已無人記得原因。
- 畫面上有許多設定與選項，沒有人用過，也沒有人敢移除。
這與 AI 的能力無關。它每一次都把當下的要求做得很好。把每一項要求做好，和把一套系統做好，中間還需要一個從頭到尾規劃過的人。
產出的成本低，功能就容易越做越多
過去加一個功能需要排工期與預算，團隊自然會先確認是否必要。現在加一個功能只需要一句話，這道確認就容易被省略。
AI 本身也有這個傾向。要求一張報表，它常會一併加上篩選、排序、多種匯出格式與權限控管。每多一項，之後就多一項需要有人理解與維護的東西。
製作時不費力，維護時仍然費力。這就是過度設計，在 AI 協作開發中特別容易發生。
沒人敢改的狀態
常見的情況是：某天需要做一個很小的修改，例如把單價由兩位小數改為三位。AI 完成修改，畫面也正確。隔天會計發現月報的總額有出入。再請 AI 修正，月報正確了，匯出檔的格式又出現問題。
幾次之後，維護的人會開始避免更動系統，原因是無法預期修改會影響哪些地方。系統仍在運作，卻已無法隨公司的需要調整，逐漸由資產變成負擔。
維護責任落在做出系統的人身上
系統由誰做出來，出問題時同事就找誰。這件事不會寫在任何規定裡，多數組織卻都是這樣運作。
以 AI 做出系統的人如果是一位主管，後續常見的發展如下：
- 同事無法登入，找他。
- 資料輸入錯誤需要更正，找他。
- 業務希望多一個欄位，找他。
- 月底報表數字有疑問，仍然找他。
這位主管原本的工作是決策、帶人與掌握方向。此後他的時間被切成許多小段，用於回答操作問題與修正資料。組織並未指派他擔任資訊承辦，實際上他已經是了，因為只有他了解那套系統。
這是角色的錯配。公司支付的是主管的薪資，得到的是一位兼任的系統維護人員，而且這個位置無法請假，也無人可以交接。時間一長，疲勞難以避免，原本該由他做的決策也被擠壓。
許多人一開始選擇自己動手，是因為這樣比較快。當下確實比較快，後續的維護負擔往往沒有被算進去。
常見的處理方式
- 開始對話之前，先把整體規劃一次。系統要管理哪些東西、資料之間的關係、使用者是誰，整理成一兩頁。有了這份規劃，AI 的每一次產出才有對照的依據。
- 每增加一項功能，同時確認由誰維護。找不到維護者的功能，可以延後再加。
- 定期整理與移除。無人使用的設定、為特例加上的分支，每隔一段時間清理一次。系統能夠變小，才容易修改。
- 一開始就確定系統的歸屬。製作的人與維護的人可以分開。主管決定需求，日常維護則由明確的承接者負責，可以是內部人員，也可以是外部顧問。
- 留下他人看得懂的紀錄。包括設計的理由，以及刻意不做的部分。這份紀錄的讀者是半年後的維護者，或是接手的人。
已經進入沒人敢改的狀態時：多數情況不必急著重寫。把現況讀過一遍之後，通常會發現確實有人使用的只有一部分。保留這一部分、整理資料、交接維護責任，往往比全部重來實際。
常見問題
為什麼用 AI 對話寫出來的系統很難維護？
每一次對話只處理當下提出的那一小塊，AI 會把那一塊做得很完整，整體卻沒有人從頭規劃。同一件事容易出現兩三種寫法，資料存在好幾個地方，改一處會牽動別處，久了便沒有人敢動。
什麼是過度設計？AI 為什麼容易過度設計？
過度設計是指做出比實際需要更多、更複雜的東西。AI 產出的成本很低，又傾向把每個要求做得周全，因此常順手加上用不到的設定、狀態與選項。這些東西當下不花力氣，之後每一項都需要有人理解與維護。
主管自己用 AI 做系統有什麼風險？
主要風險在責任歸屬。系統由誰做出來，出問題時同事就找誰。主管原本的工作是決策與帶人，之後卻要回答操作問題、修資料、改功能，時間被切碎，角色也隨之錯位。
已經用 AI 做了一套難改的系統，該怎麼辦？
多數情況不必急著重寫。常見的做法是先把現況讀一遍：資料存在哪裡、哪些功能確實有人用、哪些可以關掉，再留下有用的部分、整理資料結構，並把維護責任交接出去。