智能體時代的調試藝術

一位初級工程師曾問我，如何能精準定位並非由自己編寫的代碼變更所引入的bug。起初我對這個問題感到驚訝，並沒有立刻給出完美答案。我能想到的最好解釋是，這種能力是通過實踐、模式識別以及對相關係統的認知逐漸培養起來的。

如今，隨着編碼智能體的興起，這個問題顯得更加重要。人們很容易將調試視為一項將被自動化的繁瑣軟件開發任務。但那些在生產環境中摸爬滾打過的軟件工程師，不僅記得bug帶來的挫敗感，也記得成功調試並修復棘手問題後的興奮。

有效的調試是假設構建、證據收集和嚴格檢驗的結合。有時，可觀測性工具、日誌或智能體能直接給出答案，但更多時候需要直覺與決策技巧的結合。

我熱愛編碼智能體，也看好AI在知識工作中的應用。但在過去幾個月調試一個相對大型的、預訓練語言模型之前的代碼庫時，我遇到了一種特定類型的失敗：智能體可能給出自信、詳細且錯誤的解釋，並附上看似嚴謹且有説服力的證據。

例如，最近一個編碼智能體將我調查的故障歸因於一個較新的代碼變更，然而相關行為在該變更之前就已存在。另一次，智能體的解釋因其與應用程序的數據模型相悖而根本不可能發生。

對抗這類智能體失敗的方法，正是優秀工程師早已應用的紀律。當某件事看似迴歸問題時，值得追問：這個迴歸真的是由正在審查的代碼或變更引入的嗎？還是另有源頭？這條代碼路徑是否真的在我擔心的場景中被觸發？數據模型是否允許所描述的失敗模式？

許多自信但錯誤的發現，在被迫回答這類問題時就會崩潰。否則，智能體可能愉快地將長期存在的歸因於一個新補丁，或者編造一個數據模型不允許的失敗模式。

圍繞智能體的輔助結構可以有所幫助：結構化的審查流程、良好的上下文檢索、模式信息、針對性搜索來驗證假設。但輔助結構只能縮小可能解釋與正確解釋之間的差距。目前，這種差距往往需要人類參與。

這一教訓對軟件開發新手尤為重要。智能體能自信地提出理論，有時也會在質疑下對自己的結果失去信心。如果開發者過度依賴智能體，而沒有培養足夠的代碼理解和故障模式分析能力，他們在關鍵時刻可能無法判斷智能體的輸出。

那麼，如何提高調試能力？我認為沒有重複的公式，但以下建議或許有幫助。

首先，養成從症狀出發逆向工作的習慣。明確故障，識別起點和最近的變更，追蹤可能負責的系統部分。

其次，明確你的假設。不要只説“可能是緩存”或“可能是查詢錯誤”。寫下解釋成立所需的條件，然後尋找證據來確認或否定它。

第三，學習你所用系統的不變量：哪些字段總是存在？哪些作業是冪等的？哪些路徑不可能？哪些服務是最終一致的？大量調試工作歸結為知道哪些可能解釋實際上不可能發生。

最後，使用智能體時，不要只問答案。要求它們展示調試路徑。詢問它們所做的假設以及支持任何主張的證據。你也要負責驗證智能體的假設。

是的，你應該有測試套件、可觀測性和優秀的上下文檢索管道來處理智能體。但生產代碼庫，無論新舊，都不完美。它們有各自的怪癖和技術債務，不會在一夜之間被徹底改造。

這就是調試技藝仍然重要的原因。作為構建軟件的人，你應該主動培養它。

感謝Ashutosh和Raghav審閲本文草稿。