系統剛開始開發時，修改速度很快。功能少、邏輯集中、資料流單純，開發者可以在短時間內找到要改的位置。需求一來，改條件、補畫面、調 API，整個流程看起來很直接。
時間拉長後，系統裡的關聯會變多。某個欄位原本只出現在一個畫面，後來被報表、匯出、通知與權限判斷一起使用。
某個服務原本只支援一種流程，後來又被加上例外規則、客製條件與歷史相容邏輯。這些關聯一多，修改一個地方就很難只影響一個地方。
耦合會迫使開發者在修改前，先確認其他功能是否被牽動、資料格式是否改變、舊流程是否壞掉、下游系統是否收到不同結果。
當影響範圍沒有清楚邊界時，修改工作就會從「改程式」變成「查關係」。花在判斷副作用的時間，也會超過真正撰寫程式的時間。
這正是系統越改越慢的第一個訊號。需求看起來很小，討論時也像是只要改一個條件，進到程式裡才發現牽涉多個模組、資料表、批次作業與外部介面。
開發者願意處理需求，只是每一步都要先確認會不會踩到看不見的地雷。
測試不只是在功能完成後確認結果正確，也是在修改時提供安全感。
當系統有穩定的自動化測試、整合測試與關鍵情境測試，開發者改完後可以快速知道主要行為是否壞掉。測試通過不代表風險歸零，卻能先擋住一部分明顯錯誤。
缺少測試時，修改會變得很依賴人工判斷。開發者需要靠讀程式、問同事、手動操作、查舊文件與看正式環境資料來推測影響。
這些工作都需要時間，也容易漏掉邊界情境。系統變大後，手動檢查很難完整覆蓋所有行為。
安全感不足會改變團隊的行為。大家會開始避免動到某些模組，遇到需求時傾向用局部補丁處理，減少對原有結構的整理。
改動範圍看起來變小，邏輯卻會變得更分散，下一次修改也需要花更多時間理解。
AI 可以協助產生測試草稿，也可以快速補上一些測試案例，情境選擇仍要回到風險判斷。
若測試只是為了讓數字看起來漂亮，沒有覆蓋關鍵流程、重要資料轉換與高風險邊界，修改時就缺乏足夠保護。測試的價值，來自它能讓團隊更敢做必要的變更。
系統每經過一次修改，都會留下新的痕跡。有些痕跡來自需求演進，有些來自緊急修補，有些來自過去的技術限制。
當這些背景沒有被記錄下來，後來的人只能從程式碼裡反推原因。程式碼能告訴我們現在做了什麼，卻不容易說清楚當時為什麼這樣做。
理解成本會出現在很多地方。開發者要知道這段邏輯服務哪個業務流程，哪些角色會使用，哪些資料狀態需要保留，哪些舊行為不能破壞。
若文件過期、架構決策沒有留下、測試不足，理解就會變成大量閱讀與口頭確認。關鍵知識集中在少數人身上時，修改還會被等待確認拖住。
AI 進入開發流程後，理解成本不會自動消失。
AI 可以幫忙整理程式、摘要模組、推測呼叫關係，也能協助找出重複邏輯。這些能力對理解遺留系統有幫助，前提是 AI 取得足夠上下文。
若系統命名混亂、測試不足、歷史決策缺失，AI 產出的解讀仍需要被檢查。
系統修改速度下降，常是多個問題交疊後的結果。耦合讓影響範圍變大，缺少測試讓團隊缺乏安全感，理解成本讓每次修改前都要重新建立上下文。
三件事連在一起，就會形成所謂的「技術債（Technical Debt）」，小改動會變成大工程。要恢復修改速度，第一步是讓系統容易理解、容易驗證，也容易控制變更影響。
耦合高的系統，開發者很難只理解眼前那一段程式。
看起來只是修改訂單狀態，實際上可能牽涉庫存、付款、通知、報表、客服後台與批次作業。每個模組都拉到一點關係，修改前就需要先把這些關係重新串起來。
理解範圍一變大，開發者不能只問「這段程式怎麼寫」，還要問「誰會呼叫它」、「它改了之後誰會受到影響」、「資料流到下游後會不會被解讀成別的意思」。系統邊界不清楚時，這些問題就很難快速回答。
耦合也會讓人對程式碼失去信心。開發者看到一個條件判斷，不確定它只服務眼前功能，還是同時保護某個舊流程。看到一個欄位，不確定它只是畫面顯示用，還是外部系統也依賴它。這種不確定感會拉長修改前的閱讀時間。
理解範圍擴大後，每次需求進來，團隊都要花更多時間做影響分析。
若知識集中在少數熟悉系統的人身上，其他人就會傾向先問人再動手。時間一久，修改速度會受限於「誰知道這段歷史」，也受限於「誰敢碰這段程式」。
當開發者沒有足夠時間理解系統，常會選擇最小範圍的局部修改。
趕交付時，這種做法看起來改動少、風險低，也能在短時間內完成。局部修改若沒有處理好邊界，新的條件就會被塞進原本不適合的位置。
舉例來說，原本某段程式只負責訂單金額計算，後來因為促銷需求加進會員等級判斷，再後來又加進特定通路例外。這些規則都跟訂單有關，放在一起看起來很方便。時間一長，這段程式就開始同時理解金額、會員、通路與活動規則。下一次修改時，開發者需要理解的內容也會變得更多。
理解不足也會讓團隊複製既有做法。看到某個模組已有類似邏輯，就複製一份再改一點點。
短期看來避開了重構風險，長期卻讓重複邏輯分散在不同地方。當規則要調整時，團隊需要找出所有副本。若漏掉其中一處，系統行為就會開始不一致。
這種情況會讓耦合變得更隱性。表面上每個修改都很小，實際上系統裡多了更多相依、重複與例外。
後續開發者閱讀程式時，要花時間判斷哪些邏輯代表同一個規則，哪些邏輯來自歷史遺留。理解不足製造耦合，耦合又把下一次理解推得更遠。
AI 很擅長依照眼前上下文產生可執行的修改。當開發者提供一段程式與一個需求，AI 能快速補上條件、產生方法、調整資料轉換，甚至一起產生測試草稿。
明確、小範圍的任務，很適合用這種方式加快起步。
在高耦合系統中，AI 的局部能力也會帶來新的風險。AI 看到的是開發者提供的上下文，未必掌握完整系統邊界。
若輸入只包含局部程式碼，AI 會傾向在局部完成需求。它可能補上一個新的條件判斷、複製既有邏輯、沿用眼前的錯誤結構，讓程式能跑，也讓系統變得更難整理。
這類修補不一定會立刻壞掉。它能通過眼前測試，也能解決當下需求。下一次修改時，開發者才發現同一條規則出現在更多地方，例外條件散在不同模組，命名與責任邊界更加模糊。
AI 加快了局部產出，也讓缺乏整體判斷的修改更快進入系統。
使用 AI 修改遺留系統時，審查焦點要放在結構影響上。程式能不能執行只是第一層檢查，還要看它有沒有增加不必要的相依，有沒有複製既有壞味道，有沒有把新規則放到錯誤的位置。
若只要求 AI 快速完成眼前需求，耦合與理解成本也會被一起放大。
耦合與理解成本的關係，是系統越改越慢的重要原因。耦合拉大理解範圍，理解不足又推著團隊選擇局部補丁，AI 會讓這個循環跑得更快。
當系統缺少清楚邊界、測試保護與足夠文件時，每次修改都會帶著不確定感。開發者改完眼前問題後，仍然很難確認其他流程是否受到影響。時間一久，修改會從技術工作變成壓力來源。
團隊會開始用保守方式面對變更。需求進來時，第一個反應常是評估會不會碰到高風險區域。
某些模組被標記成「不要亂動」，某些邏輯只有特定幾個人敢改，某些需求會複製出一堆只有小差異的方法，避免牽動太多不確定的地方。
這種保守有它的合理性。面對高風險系統，謹慎是必要的工程判斷。
保守一旦變成固定習慣，團隊會開始迴避必要的整理。明知道某段邏輯已經難以維護，仍然選擇在旁邊補一段新的判斷。明知道資料流已經混亂，仍然用轉換與例外處理把需求先撐過去。
每一次看似安全的局部補丁，都會讓下一次修改更像賭博。系統裡累積更多例外、更多重複、更多難以解釋的條件。開發者越不敢整理，系統越難整理。
修改風險提高後，需求回應速度也會受到影響。產品端提出一個看起來簡單的調整，工程團隊卻需要花很多時間評估。
資料是否會受影響、舊使用者行為是否要保留、報表、批次、外部介面與權限規則會不會一起變動，都要先確認。
這些確認工作有它的價值。高風險系統不能只靠直覺修改。只是當系統長期缺少測試與清楚結構，每次確認都會變成繁重的工作。
原本應該由自動化測試、模組邊界與文件支撐的判斷，最後都回到人工閱讀、詢問與試錯。
需求排程也會被拉長。影響分析、風險討論、手動驗證與上線觀察會吃掉更多時間。小需求進來後，不一定能很快開始實作。即使開始實作，也常需要等待熟悉系統的人確認。
需求沒有變複雜，是回應需求所需要的系統知識變多了。
AI 能加快實作草稿產生，卻不會自動消除這些風險確認。當團隊對系統缺乏信心時，AI 生成得越快，後面的驗證壓力越大。
產品端看到程式好像很快寫完，工程端承擔修改後能否安全上線的責任。這個落差會讓交付節奏變得更難預估。
修改風險長期存在，會讓團隊成員承受心理壓力。開發者擔心一個小改動引發正式環境事故，也擔心漏掉沒人知道的舊流程，或在修完問題後帶出更多問題。這些壓力會改變大家面對變更的態度。
壓力會轉成各種流程阻力。拉取請求（Pull Request）需要更多人批准，測試週期被拉長，上線前增加確認會議，連小幅修改也被要求附上大量說明。
這些做法都有合理原因，目的都是降低錯誤進入正式環境的機率。流程補強若缺少系統改善，整體流程就會變得沉重。
流程變重後，高風險區域會更少人願意碰。每次修改除了處理程式問題，還要投入大量時間溝通、審查與等待。
新進成員難以參與核心模組，資深成員也會被確認工作綁住。系統風險依然存在，團隊的移動速度卻先被拖慢。
修改風險會改變團隊行為，讓決策變得保守，需求回應速度下降，也讓心理壓力轉成流程阻力。
AI 可以協助加快局部工作，修改能力仍取決於系統是否容易理解、驗證與控制影響。基礎問題沒有處理，速度壓力只會讓抗拒更加明顯。
恢復系統修改能力，可以先從測試保護開始。當團隊不確定修改會不會破壞既有行為時，每次變更都會變慢。開發者需要反覆確認、手動測試、找熟悉系統的人判斷，很多時間都花在降低不安感。
補測試時，不需要一開始就追求完整覆蓋。務實的做法，是先找出最常被修改、最容易出事、最接近營收或正式流程的區域。這些地方若沒有保護，任何小修改都會放大風險。核心流程先有自動化測試，重要行為才有基本安全網。
測試要先保護行為。對遺留系統來說，很多程式結構不一定乾淨，命名也不一定清楚。若一開始就急著重構，風險會很高。
可以先用特徵測試（Characterization Test）描述目前系統需要維持的外部行為，例如輸入什麼資料、經過什麼流程、最後應該產生什麼結果。重點是描述並鎖定系統現有的行為，好幫助團隊確認整理前後的行為是否一致。
AI 可以協助加快測試草稿產生，例如根據既有程式找出分支條件、補上邊界案例、產生測試資料。
測試是否代表真實業務情境，仍要由人判斷。若 AI 只根據程式現況產生測試，容易把歷史錯誤也固定下來。測試保護的重點，是建立修改信心，同時保留修正錯誤設計的空間。
團隊不應為了降低耦合，一次性進行大型重構。大型重構牽涉範圍廣，容易碰到太多相依關係，也會讓產品需求被迫等待。
較可行的方式，是採用絞殺者模式（Strangler Fig Pattern）漸進式替換，避免高風險的大換血。從小範圍、常修改、風險可控的地方開始整理。每次只處理一個清楚問題，系統才會慢慢變得容易修改。
可以先觀察哪些地方經常出現重複判斷、跨模組呼叫、資料格式轉換混亂、業務規則散落。這些地方都是耦合偏高的訊號。
當某個規則被複製在多個地方，每次需求變更都要到處找副本。當某個方法同時處理太多責任，任何修改都會牽動多種情境。
小範圍降低耦合，可以從命名、抽取、隔離開始。把模糊命名改成業務能理解的名稱，能降低閱讀成本。把重複邏輯抽成單一位置，能減少規則分歧。把外部依賴包在清楚介面後面，修改範圍也會更容易控制。
這些改善看起來不大，卻能讓下一次修改少走很多路。
這類整理適合跟正在進行的需求一起做。當團隊正在修改某個區域，代表這個區域有真實變更需求，也代表開發者正在建立上下文。
這時候順手整理一小段，比另外安排一個大型清債專案較容易落地。前提是要保留時間做整理，不能把所有工作都壓成只交付功能。
遺留系統難改，常是因為團隊看不懂它。
程式碼裡有許多歷史條件、例外流程、隱性規則與過去決策。原本熟悉的人離開後，後來的人只能靠讀程式、查資料、翻舊文件來拼湊理解。這個過程很慢，也容易漏掉重要脈絡。
AI 可以在理解遺留系統時提供幫助。它能摘要模組責任、整理呼叫關係、找出重複邏輯、解釋複雜條件判斷，也可以把一段程式轉成接近業務語言的說明。對剛接手的人來說，這些摘要能降低進入門檻，讓他們較快知道該從哪裡讀起。
許多 AI 工具可以搜尋整個儲存庫（Repository）、追蹤呼叫關係、讀取測試、檢查設定檔，甚至在多個檔案之間建立修改計畫。
AI 能讀到程式碼，仍然需要知道這次要分析的變更目標、不能破壞的流程、需要保留的歷史相容行為，以及代表關鍵保護的測試。團隊需要補足任務邊界與業務脈絡，讓 AI 的分析能對準實際變更情境。
若指令只寫「幫我看這段功能怎麼運作」，AI 可能會整理出技術流程，卻不一定能判斷哪些邏輯具有業務意義。
因此，團隊使用 AI 工具時，可以把問題描述成一次小型影響分析。除了讓 AI 讀取專案，也要交代變更目的、預期行為、相關錯誤案例、測試入口與可修改範圍。
AI 產出的模組摘要、呼叫關係與風險清單，可以作為分析起點，後續仍需要透過測試、文件與實際系統行為進行驗證。
AI 產出的理解結果，可以進一步變成團隊資產。像是模組說明、資料流筆記、常見例外規則、重構前觀察、測試補強清單，都可以整理進文件或工作項目。下一個人接手時，就不用重新從零開始讀。
恢復系統修改能力，需要一起處理安全感、結構與理解。測試讓團隊敢改，小範圍降低耦合讓系統好改，AI 輔助理解讓接手成本下降。
這些改善不會一次完成，只要能跟日常需求一起推進，系統就有機會從「每次修改都很怕」回到「可以有把握地調整」。
iThome鐵人賽
看影片追技術