真實的軟體維護任務，往往不是從清晰的規格書開始，而是一長串雜亂的商業 Email。這篇分享如何把 AI 當成技術協作的思考夥伴，而不只是代碼生成機，建立一套從「接收業務抱怨」到「提交安全程式碼變更」的完整流程。

1. 需求翻譯（Issue Intake）
把雜亂的討論串或 PDF 丟給 AI，讓它剝離情緒與表面症狀，找出真正的技術需求。再與 AI 討論根本原因假設——是基礎設施問題、整合失敗，還是商業邏輯落差？避免一開始就找錯系統層級。

2. 系統勘查（Reconnaissance）
在改動任何遺留系統前，先釐清「過去的基準是什麼」。將舊有腳本作為輸入，讓 AI 比對現行程式碼中的執行路徑與邏輯斷層，列出遺失的商業規則（如時間視窗處理、過濾邏輯差異），取代對著錯誤代碼無止境猜測。

3. 範圍收斂（Scope Reduction）
這是實務上最關鍵、卻最常被跳過的一步。告訴 AI 你的底線：「不引入新的抽象層」、「不改動共用核心模組」、「限制修改的檔案數量」。與 AI 進行條件談判，把龐大的修復目標壓縮為風險最低的最小程度變更。

4. 迭代實作（Iterative Implementation）
遺留系統的修復計畫很少一次到位，隨著開發進行或環境改變，要隨時與 AI 重新校準範圍。嚴格要求 AI 只針對痛點進行最小化修補，保留既有邏輯，確保不引發架構震盪。

5. 版本控制與 PR 敘事（Git Hygiene）
修補完成後，請 AI 協助將改動拆分為原子化提交（Atomic Commits），並根據你的習慣草擬 PR——清楚交代修改動機、改了什麼、沒改什麼，給審查者最好的技術文件，大幅加速 Code Review。

核心心法
萃取意圖 → 比對行為 → 收斂範圍 → 最小化實作 → 沉澱為可重複的技術

AI 在這套流程裡的角色是引導診斷、控制範圍的助手，讓每次修復都更安全、精準，且具備高度可追溯性。

感謝閱讀，為了方便日後系統化檢索，我將技術筆記同步收錄在個人知識基地 愷的大冒險 Kai's Adventure