AI不會取代你的導師，但它可能是唯一可用的導師

在軟體開發的工作中，作者發現自己在開發內部工具時常常陷入孤立無援的境地。雖然團隊關係融洽，但同事們對這些“旁支”專案缺乏熱情，無法提供深入的指導或建設性反饋。這種狀態讓作者在技術決策時頻繁遇到“寫作瓶頸”——不確定如何設計系統、實現模式，或是確保程式碼的可擴充套件性和可維護性。作者曾嘗試尋求同事幫助，但得到的反饋往往是批評而非引導，例如“這個專案不重要，你隨便做吧”或“這看起來很複雜”，甚至還有“我憑經驗說話，你沒有，所以相信我”。這種缺乏建設性的反饋讓作者倍感沮喪。

然而，作者發現AI工具（如Claude）可以成為有效的替代性導師。與AI的互動並非尋求現成答案，而是將其作為“理性夥伴”來探討問題。透過提供多種選項而非單一“正確”答案，AI幫助作者理清思路，並允許作者挑戰它的建議。例如，在構建圖資料庫API時，AI給出了三種設計方案：使用map[string]any、反射any介面和定義ToProperties()介面。AI推薦使用反射，但作者最終選擇了map[string]any，並自主決策跳過了介面層，因為自己覺得這樣更直接。

AI的另一大優勢是提供具體可測試的程式碼片段，並願意承認資訊來源（如語法規則而非實際庫函式），這避免了作者因缺乏經驗而產生的盲目信任。作者還透過與AI的對話式互動，不斷挑戰其建議，從而加深了對問題的理解。例如，在構建Cypher屬性字串時，AI提供了一個完整的buildPropsString函式，並指出了輸入清理、單引號轉義和巢狀物件處理等注意事項。作者發現這些建議是基於Cypher語法規則而非實際庫函式，從而避免了依賴可能不存在的庫功能。

儘管AI無法完全替代人類導師的經驗和直覺，但在缺乏其他指導的情況下，它確實成為了一種寶貴的資源。作者強調，關鍵在於將AI視為輔助思考的工具，而不是自動生成的解決方案。透過主動提問、質疑和驗證，作者不僅克服了技術障礙，還逐步建立了自信和獨立解決問題的能力。此外，AI在程式碼審查方面也存在不一致性，可能會前後矛盾，因此作者通常只做一次審查，並自己新增註釋以確保未來可維護性。總的來說，AI雖不能完全取代導師，但至少提供了一個隨時可用的思考夥伴。