在 AI 輔助開發的日常中，你是否常遇到這種情況：你描述了一個功能，AI 立刻吐出一堆程式碼。這些代碼雖然跑得動，但邏輯鬆散、沒有考慮極端狀況，甚至與你現有的專案風格完全不搭。最後，你還是得花大量時間重構（Refactor）。
問題的根源在於：我們習慣把 AI 當成「搜尋引擎」或「打字員」，而非「架構師」。
真正的高效協作，不是依賴 AI 的運算力，而是依賴你的提問深度。以下將透過一個通用的開發場景——「設計一個後台批量數據匯出功能」，示範如何透過 6 個關鍵提問步驟，讓 AI 的產出從「初級水準」躍升為「專家級」。
🚀 第一部分：6 個提問心法，將 AI 升級為資深架構師
1. 謀定而後動：設定「角色」與「暫停指令」
許多人一開口就是：「寫一個 Python Script 幫我匯出使用者資料到 CSV。」這會讓 AI 進入「執行模式」，忽略了效能與架構。
✅ 高手這樣問：
「我要開發一個『百萬級別的使用者資料匯出』功能。但在寫任何程式碼之前，我需要進行充分的架構討論。
請你扮演資深後端架構師。請先不要實作，而是針對我的需求提出風險評估（如記憶體溢出、Timeout 問題）以及可行的架構選項。」
💡 效果： AI 會從「寫 Loop」轉變為思考「非同步處理」、「排程隊列（Queue）」或「串流（Streaming）」等高階概念。
2. 提供負面約束：用「背景」過濾過度工程
AI 容易因為不知道場景而「過度設計」或「設計不足」。如果這是給內部營運人員用的，就不需要做成給外部眾多 Client 端那樣精美且高併發的介面。
✅ 高手這樣問：
「這個功能僅供內部營運團隊使用，每天使用頻率極低（< 10 次）。
因此，我不需要極致的高併發處理，也不需要複雜的 UI 動畫。我希望能優先考慮開發速度與維護的簡易性，請基於這個前提簡化剛才的設計。」
💡 效果： AI 會自動收斂發散的思路，捨棄複雜的微服務拆分建議，轉而推薦一個簡單穩定的單體（Monolithic）解決方案。
3. 拒絕模糊：逼出「畫面與流程」的細節
如果你只說「幫我做一個匯出按鈕，點了之後下載 CSV」，AI 通常會給你最簡單的解法：點擊按鈕 → 畫面轉圈圈（Loading）→ 下載開始。這種寫法在小數據量沒問題，但一遇到大數據就會導致瀏覽器卡死。
✅ 高手這樣問：
「不要只列出『點擊後下載』這種簡單邏輯。請詳細描述長時任務（Long-running Task）的使用者流程：
假設這個匯出過程需要 5 分鐘，在這段期間：
- 使用者必須停留在當前頁面等待轉圈圈嗎？
- 如果使用者切換頁面或不小心關閉視窗，匯出任務會中斷還是繼續執行？
- 任務完成後，使用者要如何收到通知並取得檔案？」
💡 效果： 這個問題會逼迫 AI 承認「簡單的 Loading 動畫」無法滿足需求。它會立刻自我修正，從原本簡單的同步請求（Synchronous Request），升級為「背景排程（Background Job）+ 通知系統」的完整架構，甚至主動建議：「我們應該將檔案生成後寄送 Email 下載連結，或者在導覽列做一個『通知中心』來讓使用者隨後下載。」
4. 指定座標：讓 AI「讀懂」你的程式碼風格
AI 最常犯的錯就是「自創風格」。你的專案用 snake_case，它偏要用 camelCase；你用 MVC，它給你寫 MVVM。
✅ 高手這樣問：
「請參考專案中
src/modules/reports/ExportController.js這個檔案的寫法。請分析它的錯誤處理模式（Error Handling）與命名慣例，並在接下來的新功能實作中，嚴格遵守相同的設計模式。」 (註：若使用網頁版 AI，需手動複製參考代碼貼上)
💡 效果： AI 會瞬間變身為熟悉你專案的團隊成員，寫出能無縫整合（Copy-Paste ready）的程式碼。
5. 探討權衡：不求最快，但求「最合適」
技術選擇永遠是取捨（Trade-off）。不要只問「怎麼做」，要問「有什麼代價」。
✅ 高手這樣問：
「針對 CSV 生成的過程，如果我們選擇『在記憶體中組裝字串』vs『直接寫入硬碟暫存』，這兩種方式在 記憶體消耗 與 I/O 效能 上的權衡是什麼？針對我的伺服器規格（2GB RAM），你會建議哪一種？」
💡 效果： 這能避免 AI 給你一個在小數據量沒問題，但上線後會把伺服器記憶體吃光的危險代碼。
6. 激發批判性思考：拒絕當應聲蟲
AI 為了討好人類，常常會順著你的壞點子走。你必須訓練它「反對」你。
✅ 高手這樣問：
「我知道你照著我的指示設計了同步 API，但你剛剛承諾要給我『專業意見』。
如果你是負責 Code Review 的資深工程師，你會以什麼理由拒絕這段程式碼？ 請誠實指出潛在的致命缺點。」
💡 效果： AI 往往會在這時才吐露真話：「其實同步 API 在數據量大時會導致 Nginx 504 Gateway Timeout，這在生產環境是不可接受的...」這才是能救你一命的建議。
⚠️ 第二部分：現實檢核——AI 協作的隱性侷限
雖然上述技巧很強大，但在實戰中，我們必須清醒地認識到 AI 目前的技術天花板，以免踩坑。
1. 「誠實」不代表「正確」：小心幻覺（Hallucination）
- 誤區： 當你要求 AI 提供「專業數據」或「效能分析」時，它給出的數字看起來很權威。
- 現實： AI 擅長邏輯推演，但不擅長精確計算或引用最新事實。它可能會說「這個方案只有 2% 的效能損耗」，這數字很可能是它「編」出來讓語句通順的。
- 對策： 把 AI 的建議當作定性分析（方向參考），而非定量分析（絕對數據）。關鍵的效能指標與安全性配置，務必由人工查證或進行 Benchmark 測試。
2. 溝通成本 vs. 開發成本：殺雞焉用牛刀
- 誤區： 不管什麼功能都要進行上述的「6 步驟深度對話」。
- 現實： 如果你只是要寫一個簡單的 Regex（正規表達式）或者一個純靜態頁面，與 AI 來回討論架構反而比自己寫還慢。
- 對策： 建立分級機制。
- 簡單任務（CRUD、單一函數）： 直接下精確指令生成代碼。
- 複雜任務（系統設計、涉及多模組互動）： 啟用上述的「架構師對話模式」。
結語
在 AI 時代，工程師的價值不再取決於「你能多快寫出程式碼」，而取決於「你能多精準地定義問題」。
試著將你的思維從「指令者（Do this）」轉變為「引導者（Let's discuss this）」。當你開始用問題去挑戰、引導與約束 AI，你會發現它不再是一個單純的自動化工具，而是你身旁那個博學、不知疲倦，且隨時準備好與你激盪火花的最佳技術夥伴。
