在面對擁有數百個儲存庫（Repositories）、跨越數十年歷史且涉及多種程式語言的大型工程系統時，工程主管面臨的最大挑戰往往不是「寫程式的速度」，而是「認知負荷（Cognitive Load）」。
當系統規模大到無法用單一文件描述，甚至無法全部裝進一個人的大腦時，我們需要的不再僅僅是自動補全程式碼的助手，而是一個能幫我們擴展「記憶體（RAM）」、協助合成碎片化資訊的思考夥伴。Google 的 Senior Staff Engineer Julie Qiu 分享了她如何將 AI 運用在大型系統重構中，將 AI 定義為五種不同的角色來降低認知壓力。
AI 的五種實務角色
第一，AI 作為考古學家（Archaeologist） 在老舊系統中，文件通常過時或殘缺，唯一可信的是運行中的程式碼。面對數百個 Repo，手動閱讀會耗盡心力。 實務做法：將特定模組的程式碼交給 AI，要求它分析輸入、輸出與核心行為，將數千行程式碼濃縮為精簡的行為描述。 價值：將原本需要數週的分析工作縮短至數小時，快速重建對遺留系統（Legacy System）的邏輯地圖。
第二，AI 作為實驗者（Experimenter） 在大型系統中，驗證一個設計假設的成本極高。如果需要跨九個語言團隊進行原型開發，協調成本將遠超開發成本。 實務做法：利用 AI 作為低成本的模擬引擎。在不同的 Git 分支上，讓 AI 嘗試將同一套設計理念實作在 Python、Go、Rust 等不同語言中。 價值：透過快速原型發現設計中的漏洞（例如：某些假設在 Rust 中可行但在 Python 中很尷尬），在投入大量人力前先壓力測試設計方案。
第三，AI 作為評論家（Critic） AI 傾向於給出「教科書式」的標準答案，但標準答案不一定適合複雜的實務情境。 實務做法：主動要求 AI 挑戰自己的設計，詢問「我的設計哪裡過度設計（Overengineered）？」或「哪裡可能出錯？」。 價值：強迫設計者為自己的決定提供正當理由，在面對真實工程師之前，先排除明顯的邏輯缺陷。
第四，AI 作為共同作者（Co-author） AI 能處理重複性高且正確性標準明確的任務，但不能完全放任其生成。 實務做法：將 AI 用於字母排序、重構 Import 路徑、修復編譯錯誤（將 Compiler Error 直接丟給 AI 修復）。 注意限制：AI 常會產生過多的冗餘註解、不自然的空格，或在不適當的地方過度檢查 nil 指標。必須提供明確的風格指南（Style Guide）來約束輸出品質。
第五，AI 作為審閱者（Reviewer） 在程式碼送交人類審閱前，先利用 AI 捕捉機械性的錯誤。 實務做法：使用 AI 插件檢查缺失的錯誤處理、硬編碼（Hardcoded）數值或不符合規範的格式。 價值：減少人類審閱者在瑣碎細節上的時間，讓團隊討論能集中在更深層的架構與路徑圖（Roadmap）上。
AI 的能力邊界與人類的價值
儘管 AI 能在分析與生成上提供巨大槓桿，但它在以下三個維度存在明顯限制：
第一，缺乏對「美感」與「直覺」的認知。 人類工程師在審閱時可能會說「這樣寫讓我感覺很難受」，這種直覺來自於對高品質程式碼的長期經驗，AI 無法理解這種關於「好壞」的直覺。
第二，無法處理上下文之外的決策。 AI 只能基於已有的資料分析，但工程決策往往涉及未來的產品路徑圖、團隊的人力配置以及對權衡（Trade-offs）的主觀判斷。
第三，無法解釋「為什麼」。 AI 可以告訴你系統現在是如何運作的（考古），但不能告訴你當年為什麼要這樣設計。這部分仍需要詢問參與過該決策的資深工程師。
總結：從產出導向轉向認知導向
對於資深工程師或技術領導者來說，AI 的真正價值不在於將開發速度提升十倍，而是在於將你從機械性的工作中解放，讓你能更專注於「判斷」與「合成」。
AI 處理的是過去的平均值（訓練資料），而最具挑戰性的工程問題通常存在於尚未被定義的未來。將 AI 視為思考夥伴，能讓你將有限的精力投資在只有人類才能完成的工作上：定義方向、做出艱難的抉擇，以及構建真正具有前瞻性的系統。
來源：infoq.com - Using AI as a Thinking Partner for Large-Scale Engineering Systems
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。