我使用AI解構了一個從未接觸過的遺留服務
一位工程師分享如何利用AI快速理解並修復一個陌生的遺留Node.js微服務中的間歇性字段丟失bug。關鍵方法是角色驅動、分步輸入代碼文件，讓AI充當結構化思考夥伴，而非簡單問答。最終在90分鐘內定位根因，修復僅需11行代碼。
文章情報
要點
- 面對遺留代碼，不要直接問AI“這是什麼”，而是賦予它角色並逐步輸入文件
- 通過AI識別出導致bug的函數路徑：靜默返回undefined的字段轉換函數
- 總耗時90分鐘定位問題，修復僅11行代碼
- 該方法適用於代碼庫入職、重構前偵察和文檔編寫
為甚麼重要
這條新聞值得關注，因為面對遺留代碼，不要直接問AI“這是什麼”，而是賦予它角色並逐步輸入文件。
技術影響
可能影響模型選型、推理成本、產品能力和評測基準。
三週前，我接手了一個支持升級事件，涉及一個我從未打開過的服務。這是一個大約有四十年曆史的Node.js微服務，由兩位已離職的工程師編寫。沒有有意義的README，測試已有數月未在CI中運行，Slack線程中充滿了“這東西是個黑箱”的抱怨，持續了兩年。
這次bug是真實存在且影響客户的。我有一天時間來處理。
該服務位於API網關和第三方履約提供商之間。請求轉換邏輯中間歇性地丟失字段——但僅發生在特定的請求形狀和負載組合下。輸出錯誤，日誌無幫助，代碼分散在14個文件、3200行中，邏輯在三個中間件層間交錯，責任劃分不清。
通常，這種情況意味着半天的console.log驅動的考古工作，然後才能形成值得測試的理論。但這次我嘗試了不同的方法。
我的第一直覺是將主處理器粘貼到AI聊天框中詢問“這是做什麼的？”這給了我一個表面級別的總結——沒錯，但並不有用。它告訴我代碼説了什麼，而不是在整個系統上下文中的含義。
真正解鎖服務的關鍵提示模式是將AI視為新加入團隊的工程師，而不是搜索引擎。我按順序餵給它核心文件，並賦予它具體角色和具體目標：“你是新加入的後端工程師。我將一次展示一個遺留微服務的核心文件。每個文件後，更新一個運行列表：1）此文件負責什麼；2）你能看到的任何假設或隱式契約；3）在觸碰此代碼前你想得到答案的問題。不要總結代碼。識別承載邏輯，標記任何看起來脆弱的地方。”
三個文件後，它發現了我忽略的東西：一個字段轉換函數在輸入不符合預期形狀時靜默返回undefined——沒有錯誤，沒有日誌，只是下游字段丟失。那就是bug，已在代碼庫中存在了四年。
有了理論後，我用了第二個提示來壓力測試：展示函數和示例載荷，要求逐路徑分析輸出是否可能靜默丟失或轉為undefined。它分析了五個代碼路徑，標記了兩個可能產生undefined的路徑，並正確識別出與間歇性故障模式相關的路徑。
端到端來看：根因定位總耗時約90分鐘（通常至少半天），手動閲讀的文件4/14，修復代碼11行，後續AI輔助撰寫了一個迴歸測試。關鍵不是AI替我做工作，而是AI作為結構化思考夥伴，而我保留診斷的所有權。
如果你被丟進不熟悉的遺留代碼中，不要問AI解釋它。給它一個角色，增量地喂文件，要求它維護系統的運行模型——包括它不知道的東西。這樣的輸出遠比一個總結有用。