AI 寫的程式碼能跑。問題在後面

有人能講清楚這份程式碼嗎

交接時該問的第一個問題。不是畫面跑不跑得起來，而是還有沒有人能說明白當初為什麼這樣做。

人寫的程式碼，通常寫的人手上握著答案。問一句為什麼這裡把例外吞掉了、為什麼這個值是寫死的，都問得出來。用 AI 快速產出的程式碼，這個位置常常是空的。如果只是把提示詞的產物貼上去、跑得動就留著了，那連交付的人自己也講不清楚。

所以第一輪檢查不是程式碼審查，而是對話。這個功能該做什麼、哪些情況是刻意不做的、目前已知的問題有哪些。這裡問得出來的答案越少，交接要花的時間就越長。

金鑰就寫在原始碼裡

接手 AI 專案時最常撞上的事故。API 金鑰、資料庫密碼、金流商的 secret，直接寫在檔案裡。範例程式碼大多長這樣，而「之後再挪到環境變數」這種拖延，往往就這麼定型了。

危險不只在於儲存庫是否公開。這些值會跟著部署紀錄、備份，以及每個協作者的本機副本一路走。一旦外洩，從程式碼裡刪掉並不算完，金鑰本身必須重新簽發。對接手的人來說，這件事會落在第一週。

改是能改，但不知道能不能改

接過一個一行測試都沒有的專案，每次修改都成了賭博。你讀得懂、也改得動，卻沒有辦法確認這次改動沒弄壞別處。於是開發者只碰看起來安全的地方，不敢動的部分就擱著。時間一久，沒人敢碰的區域越來越大。

這個毛病在 AI 輔助的程式碼裡更常見，因為功能出得快，驗證就容易往後挪。交接當下把測試全部補齊並不實際，但涉及金流和刪除資料的路徑，背後必須有最起碼的檢查。光是守住這兩處，之後的修改就從賭博變回了普通工作。

同一份程式碼在你機器上跑不起來

接手第一天就會卡住的地方。把儲存庫拉下來一跑就出錯：版本沒有鎖定、有些檔案只存在於本機、混著只有某個帳號才過得去的設定。

驗證方法很單純。找一台乾淨的機器，拉下儲存庫，只照文件寫的步驟走一遍。卡住的地方，就是文件缺的內容。交接之前和原開發者一起做一次，之後要花好幾天的考古就在當場解決了。

先告訴我們你手上有什麼

一個儲存庫網址就夠，一個壓縮檔加一組登入資訊也行。Weple 的程式碼檢視從你拿到的原樣開始，把兩個問題分開看：今天跑不跑得動，往後維不維護得了。像外洩金鑰這類要立刻處理的，我們先告訴你；其餘的按輕重緩急排好再交回。就算你自己也還沒理清接過來的是些什麼，也沒關係。把這份清單列出來，本身就是檢視的一部分。