我用 AI 排查了一次程式碼報錯：真正省時間的不是生成程式碼，而是這套流程

很多人第一次用 AI 程式設計，都會直接問一句：“幫我把這個功能寫出來。”

結果往往不太理想。程式碼看起來完整，放進專案卻跑不起來；模型給了很多建議，但沒有真正定位問題。不是 AI 不會寫程式碼，而是輸入裡缺少了專案上下文和驗收標準。

我更推薦把 AI 當成一個可以持續協作的工程助手。開啟 https://trymodel.chat/zh-tw/chat，從一個具體報錯開始，讓模型經歷“理解、假設、修改、驗證”四個步驟。

第一步：先給最小可復現上下文

一次提供下面四類資訊就夠了：

• 使用的語言、框架和執行命令；
• 出錯檔案中相關的最小程式碼片段；
• 完整錯誤資訊和發生步驟；
• 你期望看到的正確行為。

不要一上來貼上整個專案。上下文太大，模型容易把注意力放在無關檔案上，回答也會變得模糊。

可以這樣提問：

專案使用 React、TanStack Router 和 TypeScript。執行 pnpm build 時，src/routes/chat.tsx 報以下錯誤：……請先判斷錯誤來自型別、路由還是執行時，不要修改檔案，先列出需要核對的三項資訊。

第一輪只做定位，通常比讓模型直接改程式碼更穩。

第二步：讓模型明確假設

當模型給出原因時，繼續追問：

你的判斷依賴哪些假設？哪些資訊還沒有確認？請把“已確認事實”和“推測”分開。

這一步很重要。AI 的回答可能聽起來很確定，但其中一部分只是根據經驗做出的推斷。讓它顯式列出假設，你就知道下一步該查什麼。

第三步：只接受小補丁

確認原因後，再要求模型給出最小改動：

只修改解決該錯誤所需的檔案，不重構無關程式碼。給出補丁後，說明每一處修改為什麼必要。

小補丁更容易審查，也更容易回滾。對於登入、支付、資料庫和許可權等敏感模組，尤其不要直接接受大範圍重寫。

第四步：把驗證命令寫進任務

一個完整的 AI 程式設計任務，結尾應該包含驗證方法：

修改完成後執行最快的相關檢查。如果檢查失敗，保留完整輸出並解釋下一步，不要假裝任務已經完成。

你可以讓模型同時生成單元測試、手工檢查清單和上線前風險說明。這樣輸出就不只是程式碼，而是一份可審閱的交付結果。

Trymodel 為什麼適合這種工作流

在 https://trymodel.chat/zh-tw 中，可以根據任務切換不同模型：複雜推理、程式碼解釋、長文件閱讀和快速改寫不必使用同一種模型。

需要看截圖或報錯圖片時，可以直接上傳檔案；需要查最新庫文件時，可以開啟 https://trymodel.chat/zh-tw/search。任務完成後，登入賬號還可以從歷史記錄繼續對話，不必重新解釋全部背景。

最後檢查四件事

在提交 AI 生成的程式碼前，至少檢查：

1. 改動是否只涉及需求範圍。
2. 是否引入了未稽核的依賴或網路呼叫。
3. 錯誤處理、許可權和敏感資訊是否完整。
4. 構建、測試和關鍵路徑是否真的跑過。

AI 程式設計真正省下來的，不只是敲程式碼的時間，而是定位問題、整理上下文和反覆解釋的時間。流程越清楚，模型越像工程助手；流程越含糊，模型越容易變成程式碼隨機生成器。

從一個真實報錯開始，在 https://trymodel.chat/zh-tw/chat 裡把這套流程跑一遍，通常比繼續收集“萬能提示詞”更有用。