它是一個外掛，不是一個目的地

Baidu Comate 是以百度自家文心大模型為基礎的 AI 編碼助手，訓練資料除了公開的開源程式碼，還包含百度長年累積的實際研發資料。真正關鍵的決定在於它的送達方式：它以「外掛」的形式進到人們本來就在用的整合開發環境裡 —— Visual Studio Code、IntelliJ IDEA、PyCharm、GoLand、WebStorm、CLion、PhpStorm、Android Studio 等等 —— 而不是做成一個自己帶編輯器的獨立應用。

這個選擇不是表面功夫。編碼助手只有在看得到「程式碼正在什麼脈絡裡被寫」的時候才有用，而獨立編輯器什麼都得從頭被告知。住在既有環境裡，助手就免費繼承了開著的檔案、專案結構與游標位置，而開發者也不必交出自己熟悉的快速鍵、除錯設定與習慣。

補全與生成，是兩種不同的承諾

這類工具能做的其實是兩件事，而它們經常被混為一談。補全，是猜下一個 token、一行的後半、你剛打開的那個區塊的內容：它延續的是你已經在寫的東西，價值來自對「最近的未來」猜得準。生成，是從一段描述產出整個函式，價值來自對「意圖」理解得對。

兩者靠同一個機制運作，也就是在一個脈絡窗口裡做預測，也共有同一個失敗模式：模型對不存在的東西講得非常流利。一段補全若憑著半記得的方法名編出一個 API，比沒有補全更糟，因為讀它要花注意力，測它要花時間。讓這類工具值得用的習慣，不是多按幾次接受，而是真的把它讀過。

先寫註解，是被低估的用法

由註解生成程式碼聽起來像小把戲，實際上可能是使用這類模型最有紀律的一種方式。一段說明「這個函式該做什麼、收什麼、回什麼」的註解，就是一份迷你規格；先寫它，會逼出平常會被跳過的那段思考，而生成出來的本體，則變成可以拿上方那句話來核對的草稿。

註解驅動還有一個容易被忽略的好處：規格會留下來。後來的讀者拿到的是解釋意圖的那句話，而不只是剛好實作了它的程式碼。本體是人寫的還是模型建議的，其實遠不如「上面那句話是不是真的」重要。

單元測試是生成最好打的靶

在這類工具能產出的所有東西裡，測試是最站得住腳的一種。理由不是技術性的，而是結構性的：測試可以被執行，而且它有判決。一段被建議的函式可以既合理又錯，一個月都沒人發現；一段被建議的測試，要嘛跑過要嘛不跑過，而無論哪一種，你都在幾秒內學到東西。

能為單一函式生成測試、也能整個模組批次生成，改變的是一件長期被跳過的工作的成本結構。測試是期限壓力下第一個被砍掉的東西，因為它枯燥，而它的缺席要很久以後才看得出來。一支能產出初稿的工具 —— 涵蓋顯而易見的情況、邊界、一兩個刻意刁鑽的輸入 —— 會把一小時的枯燥換成十分鐘的審閱與補強。而「審閱」不是可選的：生成的測試經常驗證的是程式碼現在做了什麼，而不是它應該做什麼 —— 一旦那個 bug 已經存在，這就等於在描述 bug。

重構建議與「行為等價」這個難題

這套工具能認出行內所謂的壞味道 —— 長得太誇張的函式、可以攤平的巢狀條件 —— 並提出重構，例如把一個長函式拆成幾個名字清楚的函式。作為「看見問題形狀」的方法，這真的有用：長函式難讀，正是因為它的各段沒有名字。

風險值得講清楚。重構只有在行為不變時才算正確，而模型無法保證這件事。它可以產出讀起來很漂亮、卻微妙地改掉某個邊界情況的程式碼，尤其是在錯誤處理、空值，以及副作用發生的順序上。這就是為什麼真正有效的搭配是「重構＋測試」：有一套會大聲失敗的測試，重構就是幾秒內可驗證的提案；沒有的話，它就是一個偽裝成整理的改寫。

讀程式碼，是工作的另一半

解釋一段函式 —— 整個或選取的部分 —— 處理的是一個很容易被低估的成本：理解別人寫的、或者半年前自己寫的程式碼。解釋不是程式的真相，而是關於它的一個假設，程式才是真相；但一個用日常語言寫成的假設，正是人在決定「該往哪裡看」之前需要的東西。

技術問答是同一個道理。問一個錯誤訊息或一個 API，會立刻得到讀得懂的東西，比過去那個「搜尋、開四個分頁、自己拼出答案」的循環好得多。但要小心的地方沒變：關於函式庫行為的答案，是最容易「自信地錯」的一類答案，而官方說明文件仍然是權威。

語言覆蓋廣，是一件實務上的事

支援一百多種語言 —— 後端從 C、C++、Java、Python、Go、PHP 到 Rust，前端從 HTML、JavaScript、CSS 到各種樣式與樣板方言，行動端再到 Objective-C、Kotlin 與 Swift —— 並不是一句行銷話術。大多數真實專案不是單語言的：一個儲存庫裡同時裝著應用程式、建置腳本、設定、資料庫遷移與說明文件，用的是四五種不同語法。一支只會講其中一種的助手，就是一支會不斷消失的助手。

老實的但書是：廣度與深度會互相排擠。在最主流的語言上表現最強，單純因為那裡的訓練資料最密；而在冷門方言裡的建議，應該比 Java 裡的建議受到更多懷疑。

它適合哪裡，以及它修不好什麼

這套工具處理的是寫軟體裡機械的那一部分：產出初稿、填樣板、寫沒人想寫的測試、解釋不熟悉的東西。它不決定程式該做什麼，也不為它產出的東西負責。由此有兩個後果。它吐出來的一切都得當成陌生人寫的來審，因為確實是陌生人寫的；而由模型來的程式碼，值得一個同事的程式碼很少被問的問題 —— 這是從哪來的，帶的是什麼授權。在任何在意來源的組織裡，這個問題都很要緊，而它恰好是助手無法替你回答的那一件。