我使用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解釋它。給它一個角色，增量地喂檔案，要求它維護系統的執行模型——包括它不知道的東西。這樣的輸出遠比一個總結有用。