在真實的軟體維護與開發場景中，任務往往不是從一份清晰的規格書開始，而是一長串雜亂的商業通訊或 Email。這篇文章將探討如何將 AI 融入日常工作流，從「接收業務抱怨」到「提交安全的程式碼變更」，把 AI 當作技術協作的思考夥伴，而不僅僅是一台代碼生成機。以下是運用 AI ，提升遺留系統（Legacy System）維護效率與安全性的協作方法：
從商業語言萃取技術問題 ( Issue Intake & Hypothesis)
- 輸入來源：雜亂的商業通訊記錄、Email 討論串或 PDF 。
- 協作模式：讓 AI 扮演第一線的「需求翻譯官」。
- 可以請 AI 閱讀長篇大論的討論串，從中剝離情緒與表面症狀，找出真正的需求。
- 接著，與 AI 討論根本原因的假設「這究竟是基礎設施層級的錯誤、系統整合失敗，還是單純的商業邏輯落差？」，這能有效避免我們在一開始就找錯系統層級，將「修復整合問題」的大方向，收斂為具體可行的技術行動。
系統勘查與新舊行為比對 (Reconnaissance & Comparison)
- 輸入來源：舊版系統的執行腳本與現有程式碼架構。
- 協作模式：在改動任何遺留系統前，釐清「過去的基準是什麼」至關重要。
- 我們可以將舊有的腳本或程式碼作為來源，讓 AI 協助比對現行程式碼中的執行路徑與邏輯斷層，透過比對列出遺失的商業規則（例如：時間視窗的處理、過濾邏輯的差異），而非不斷的對著錯誤代碼做猜測。
邊界談判與範圍收斂 (Scope Reduction & Constraint Negotiation)
- 輸入來源：比對結果與開發的限制及偏好。
- 協作模式：這是實務上最關鍵，卻常被忽略的一步。
- 告訴 AI 你的底線，例如：「不引入新的抽象層」、「不改動共用的核心模組」、「避免不必要的全域設定（Global config）重構」，甚至限制修改的檔案數量。
- 與 AI 進行條件談判，將原本龐大的系統修復目標，限縮為風險最低的最小程度變更，良好的維護不僅追求技術上的正確，更要契合團隊習慣、邊界與上線風險。
迭代規劃與微創實作 (Iterative Implementation)
- 輸入來源：收斂後的執行計畫與動態的環境反饋。
- 協作模式：在遺留系統中，修復計畫很少是一次到位的。
- 隨著開發進行或外部設定的調整，必須隨時與 AI 重新校準範圍。在撰寫程式碼時，嚴格要求 AI 僅針對痛點進行最小化修補，保留不想更動的既有邏輯，確保修改範圍集中，不引發大範圍的架構震盪。
版本控制與技術敘事 (Git Hygiene & Technical PR Narrative)
- 輸入來源：最終測試通過的程式碼差異 (Diff) 與工作紀錄。
- 協作模式：修補完成後，AI 也能協助提升版本控制的品質。
- 可以請 AI 協助檢視改動，並建議如何拆分為原子化提交（Atomic Commits，確保單一檔案或單一邏輯獨立提交）。
- 此外，在未審核的前提下，讓 AI 根據你的習慣草擬 PR(Pull Request)，好的 PR 能清楚交代修改動機、改變了什麼、沒改變什麼，這是給審查者最好的技術文件，也能大大加速 Code Review 的流程。
而透過上述方法，AI 能夠成為引導診斷與控制範圍的最佳助手，讓我們重新思考軟體維護的工作流，可以是「萃取意圖、比對行為、收斂範圍、最小化實作，將過程沉澱為可重複的技術」，讓每次的修復都更安全、更精準且具備高度可追溯性。
