今天要來介紹一個很多人以為「不就是問 AI 問題而已嗎？」結果一上手就開始燒 token 😅，筆者最近在整理 /explain Prompt 的實作方式時，沒想到有些眉角其實超重要，尤其是你想叫 AI 幫你理解整包程式碼、整理架構、找出元件互動關係時，如果 Prompt 沒框好，AI 就很容易開始自由發揮，然後你荷包跟耐心一起被發揮掉啊~

這篇很適合給以下幾種人看：剛開始用 AI 幫忙讀 code 的工程師、想把專案交接搞得比較不痛苦的人，還有那種明明 repo 很大、卻還硬要一句話叫 AI 幫你「完整分析」的人。原本以為 AI 很神，結果 Prompt 沒寫好，燃燒吧 token。

🧭 Prompt 不是亂槍打鳥，是要有章法
原則其實很簡單，就是 Build Better /explain Prompts 這件事。不要把 AI 當通靈師，請把它當成超強的菜鳥工程師、但需要你交代清楚工作範圍的同事。你講得越精準，它越能幫你省時間；你講得越發散，它就越容易把 token 當流水席在辦。

1. 先說清楚意圖 🎯
   不要只丟一句「幫我解釋這段程式」。要明講你想理解什麼，是流程、架構、錯誤原因，還是元件互動。

2. 補上下文 📦
   可以加入檔案、資料夾，或直接用 #codebase 讓 AI 參考整包程式碼，這招實務上非常實用。

3. 加上限制 ✋
   限制格式、深度、回答對象，才能避免答案散掉。框得住，答案才靠譜啊~

4. 複雜問題分段問 🧩
   一次只解一題，AI 比較專心，也比較好驗收。

這 4 點看起來像常識，但老實說，常識最常被忽略。筆者自己也不是第一次踩坑，尤其忙的時候最容易偷懶，Prompt 直接一句打下去，然後再嫌 AI 回得爛。😆

🛠️ 怎麼問，AI 才比較不會走鐘？
Prompt Engineering 本質上不是炫技，是降低溝通成本。這邊提到一個超常用的關鍵字：#codebase。這個東西的價值很高，因為它不是只看你眼前貼的那幾行 code，而是把整包程式碼先去做 index，讓 AI 回答時有更完整的參考依據。

這差很多喔。你如果只貼單一檔案，AI 很可能回答得頭頭是道，但其實上下游完全沒接到；可是一旦把 codebase 納進來，它比較有機會看懂模組之間怎麼串、主要元件怎麼互動、哪段責任在哪裡。對要讀陌生專案、補完舊系統的人來說，這絕對必需要知道~

實務上非常實用的寫法：
就是用 /explain #codebase 然後再補一句 「請摘要主要元件，並說明它們如何互動」。 這樣 AI 不只知道你要它解釋，還知道你要它看哪裡、回答到什麼程度。限制要加，不然 token 就一直燒

筆者一直很愛講一句老話：問 AI，一定要框住。這不是裝專業，是省錢。你沒有限制回答範圍、格式、深度，AI 就可能開始海闊天空，回答越寫越長，然後你想看的重點反而被淹掉。

所以你可以很明確地下指令，例如：

請用 3 點條列說明
請以初階工程師能理解的方式回答
只說明登入流程，不要延伸到資料庫設計
先摘要，再列出可能風險

真的，答案短一點、準一點，比那種看起來很厲害但其實沒對焦的長文有用太多。

限制格式
像是表格、條列、摘要、步驟式說明，讓輸出更好讀，也更方便複製進文件。

限制深度
指定給 PM、主管、初階工程師或資深工程師看，答案深淺差很多。

限制範圍
只看某個功能、某個模組、某個流程，不要一口氣全專案都問，容易卡關。

🧪 複雜問題要拆，不要一次問到天邊海角
大家喜歡把十個問題包成一題，然後期待 AI 一次回完整、正確、可執行、還附上最佳實務。嗯，夢裡什麼都有啦 😂

如果問題太複雜，真的建議拆成 follow-up prompts。先問專案主要元件，再問某個模組責任，再問資料流，最後再問風險與優化建議。這樣 AI 一次專心回答一件事，你也比較能檢查它有沒有講歪。

筆者自己的做法：
先用 /explain 拿全貌，再針對可疑或看不懂的部分一層一層追問。這樣比較像在帶 AI 做 code review，不是把它丟進戰場後叫它自己活著回來。

更多 Demo，參考完整版影片

📌 今日結論：會問，比會打還重要
今天這段其實不是在展示花俏神技，而是在補一個很基本、卻超多人會漏掉的底層觀念：AI 好不好用，很多時候不是模型問題，是你有沒有把需求講清楚。

筆者自己整理下來，真的最有感的就這幾件事：

意圖要明確
先講你想知道什麼，不要叫 AI 猜。

上下文要餵夠
能用檔案、folder、#codebase 就用，別只丟半截資訊。

限制要框住
避免發散、避免燒 token、避免回一堆你根本不需要的內容。

問題要拆小
一步一步問，才不會一次把 AI 跟自己都搞暈。

Prompt 問得巧，分析沒煩惱；上下文餵得好，AI 才不會自由跑~