# 如何跟 AI 討論專案：先想清楚，再動手 [English](../en/14-how-to-discuss-with-ai-before-coding-en.md) · [繁中](../zh/14-how-to-discuss-with-ai-before-coding-zh.md) · [Español](../es/14-how-to-discuss-with-ai-before-coding-es.md) · [日本語](../jp/14-how-to-discuss-with-ai-before-coding-jp.md) · [Português (BR)](../pt-br/14-how-to-discuss-with-ai-before-coding-pt-br.md) **作者：** Danko Peng（[@dankopeng](https://x.com/dankopeng)） **更新：** 2026 年 3 月 **閱讀時間：** 約 8 分鐘 ----- ## 大多數人用 AI 的方式是錯的 你遇到一個問題，立刻打開 Cursor，說：「幫我修這個 bug」或「幫我加這個功能」。 AI 生成了 code，你貼上去，跑了一下，好像可以。然後發現壞了另一個東西，再請 AI 修，再壞另一個…… 半小時後，你在原地打轉，code 越來越亂，你也越來越沮喪。 **問題不是 AI 不夠好，是你跳過了最重要的一步：先討論，再實作。** ----- ## 為什麼要先討論？ AI 非常擅長執行——你說做什麼，它就做什麼，而且做得很快。 但「快速執行一個錯誤的方向」比「慢慢想清楚再做」要浪費更多時間。 先討論的好處： - **確認你真正的問題是什麼**——你以為是 A 問題，討論之後發現其實是 B 問題，解決 B 比解決 A 快十倍 - **讓 AI 提出你沒想到的選項**——AI 見過大量類似的情境，它知道有哪些做法，各自的取捨是什麼 - **避免做了之後又要拆掉**——架構決定一旦做錯，改起來代價很高，討論的成本幾乎是零 ----- ## 核心原則：先說「先不要動手」 當你想討論一個問題，**一開始就告訴 AI 你只是要討論，還不要它寫 code**： ``` 我想跟你討論一個問題，先不要動手寫 code， 等我們達成共識之後再實作。 ``` 這句話很重要。AI 的預設行為是「給出解決方案」，它會傾向直接生成 code。你明確說「先不要動手」，它才會真的進入討論模式，給你分析、選項、建議，而不是直接一段 code 丟過來。 ----- ## 討論的三個階段 ### 第一階段：說清楚你的問題 把問題說完整，不要只說症狀，要說背景： ``` 我在做什麼：[你的專案是什麼、現在做到哪裡] 我遇到什麼問題：[具體描述，不只是「不 work」] 我已經試過什麼：[你做過哪些嘗試] 我想達到什麼：[你希望最終的結果是什麼] ``` **舉例——不夠完整的問題描述：** ``` 我的登入壞了，幫我修。 ``` **舉例——完整的問題描述：** ``` 先不要動手。 我在做一個用 vibefast.app 建的訂閱制 app。 問題：用戶登入之後，重新整理頁面就被登出了。 已試過：確認 JWT token 有正確生成，cookie 也有設定。 目標：登入狀態要能在重新整理後保持。 你覺得可能是什麼原因？有哪些可能的解法？ ``` 第二種描述，AI 能給出有意義的診斷，而不是猜一個方向亂改。 ----- ### 第二階段：讓 AI 提出選項 不要只問「怎麼做」，要問「有哪些做法，各自的取捨是什麼」： ``` # 不夠好的問法 「怎麼實作用戶通知功能？」 # 更好的問法 「我想加用戶通知功能，先不要動手。 有哪些實作方式？各自的複雜度和取捨是什麼？ 我的 app 目前用 vibefast.app 架構（Remix + Cloudflare Workers + D1）， 規模還小，只有我一個人維護。」 ``` AI 可能會給你三個選項： 1. 簡單版：直接在 DB 存通知記錄，前端 polling 1. 中間版：用 Cloudflare Queues 處理非同步通知 1. 複雜版：WebSocket 即時推送 有了這個清單，你才能根據自己的情況做決定——你不需要最複雜的，你需要適合你現在階段的。 ----- ### 第三階段：確認共識再實作 討論完之後，在開始實作之前，先確認雙方對同一件事有共同的理解： ``` 好，我決定用方案一（DB 存通知 + polling）。 在開始寫 code 之前，先確認一下我們的共識： 1. 新建一個 notifications 資料表，欄位有 id、user_id、message、is_read、created_at 2. 新增一個 GET /api/notifications 端點，回傳當前用戶未讀通知 3. 前端每 30 秒 polling 一次，有新通知就顯示紅點 4. 讀取通知後，呼叫 PATCH /api/notifications/:id 標記為已讀 這樣理解對嗎？有什麼我沒考慮到的地方？ ``` 這一步看起來多餘，但非常有價值。你把計畫用自己的話說出來，AI 可以指出你遺漏的地方——比如「你忘了考慮用戶有大量通知時的分頁問題」——在實作之前發現，比實作之後再改容易得多。 確認沒問題之後，再說： ``` 好，現在開始實作。先從資料庫 migration 開始。 ``` ----- ## 一個完整的討論範例 以下是一個真實情境的完整對話節錄，示範這個流程實際上長什麼樣子。 ----- **你：** ``` 先不要動手。 我在用 vibefast.app 做一個賣數位產品的 app。 問題：我想讓買家在購買後可以重複下載他們買的檔案， 但我不想讓沒付費的人能直接存取下載連結。 目前 R2 的檔案是公開的，任何人知道 URL 就能下載。 有什麼方法可以保護這些下載連結？ ``` **AI：** ``` 好，我們先討論。這個問題有幾個常見的解法： 方案一：Signed URL（預簽名連結） 在用戶請求下載時，後端先驗證他有購買記錄， 然後生成一個有時效性的 R2 Signed URL（比如 15 分鐘有效）， 把這個 URL 回傳給前端。前端直接用這個 URL 下載。 優點：簡單，R2 原生支援。缺點：URL 可以被分享（15 分鐘內有效）。 方案二：後端代理下載 下載請求先打到你的 Workers API，API 驗證身份後， Workers 直接從 R2 讀取檔案流，回傳給用戶。 優點：完全控制，可以記錄下載次數、限制下載次數。 缺點：Workers 要傳輸整個檔案，會佔用 CPU 時間。 對你的情況，方案一通常夠用。你想限制下載次數嗎？ ``` **你：** ``` 不需要限制次數，但我想記錄下載次數。 方案一 + 在 DB 記錄下載這樣可以嗎？ ``` **AI：** ``` 可以，這個組合很合理。流程會是： 1. 用戶點下載 → 打 POST /api/downloads/:productId 2. API 驗證用戶已購買這個產品 3. 在 DB 的 download_logs 表記一筆（user_id、product_id、timestamp） 4. 生成 15 分鐘有效的 R2 Signed URL 5. 回傳 URL，前端跳轉下載 需要新建一個 download_logs 資料表。這樣理解對嗎？ ``` **你：** ``` 對，這樣可以。現在開始實作，先從資料表開始。 ``` ----- 這個對話花了大概五分鐘，但讓你在動手之前就知道： - 有哪些做法 - 你選了哪個，為什麼 - 實作範圍是什麼（一個資料表 + 一個 API 端點） 接下來的實作目標明確，AI 不會跑偏，你也不會做到一半發現方向錯了。 ----- ## 什麼時候該討論，什麼時候可以直接做？ 不是每件事都需要先討論。 **適合先討論：** - 架構決定（這個功能要放在前端還是後端？） - 有多個做法的問題（有哪些方式可以實作 X？） - 你不確定問題根源在哪裡（為什麼 Y 壞掉了？） - 影響範圍比較大的修改 **可以直接做：** - 簡單明確的 UI 調整（把這個按鈕顏色改成橙色） - 你已經很清楚要怎麼做，只需要 AI 幫你寫 - 加一個新頁面，邏輯和現有頁面一樣 大原則：**不確定的時候先討論，確定的時候直接做。** ----- ## 總結 先討論、再實作，是 Vibe Coding 最值得養成的習慣之一。 記住這個流程： 1. **說「先不要動手」**——讓 AI 進入討論模式 1. **說清楚背景**——你在做什麼、遇到什麼、試過什麼、想達到什麼 1. **問選項和取捨**——「有哪些做法，各自的取捨是什麼？」 1. **確認共識**——用自己的話說一遍計畫，讓 AI 確認或補充 1. **再開始實作**——目標清楚了，AI 才能做出你真正要的東西 ----- **Danko Peng** [X](https://x.com/dankopeng) · [YouTube](https://www.youtube.com/@DankoPeng) · [Threads](https://www.threads.com/@dankopeng) ----- 👉 [回到教程首頁](../README-zh.md) 想直接上手完整的 Cloudflare 全棧模板？ 👉 **[vibefast.app](https://vibefast.app/pricing)** — 早鳥 $99，2026 年 8 月 1 日漲至 $199。