先記住：AI 需要事實、限制與未知，不是更多形容詞。
需要深入時：再整理來源優先順序。

它寫得很完整，卻沒有一條 API 是真的

你輸入「幫我做會員優惠券功能」，AI 生出 service、store 和元件，連錯誤提示都附上了。
乍看很完整，仔細看才發現端點不存在，回傳欄位也跟專案不同。

我會先把這件事理解成資訊不足下的補全。
模型會根據脈絡產生看似合理的內容，但「合理」和「符合系統」是兩件事。
Garbage in, Garbage out 是提醒，不是保證：輸入品質好，仍不代表輸出一定正確。

脈絡過長、資料過期、任務含糊與模型能力限制，都可能影響結果。

問題有時是矛盾輸入

假設你同時貼了舊 Wiki、新 API 範例和上週聊天紀錄。
三份資料對折扣欄位說法不同，卻沒交代哪份為準。
AI 可能把它們拼成一份不存在的契約。

因此「多貼一點」不一定比較好。

真正需要的是來源、版本與優先順序。
先指出目前正式契約，再把舊資料標成背景或待核對，避免混用。

程式碼片段也要有位置與周邊行為。
只貼一個函式，模型不知道它是純計算、網路邊界，還是會在每次 render 執行。

試著把輸入整理成三層

第一層是事實：目前用什麼框架、已存在的函式、契約與測試。
第二層是限制：不能變更公開介面、不能新增端點、失敗要保留草稿。
第三層是未知：優惠券是否消耗次數、錯誤碼是否穩定。

這樣整理後，AI 可以把未知列出來，而不是替我們選答案。
提出新欄位不是不行，但建議需要標示為提案，不能直接接進正式流程。

用小步驟辨認它是否理解

不要第一輪就要求完整功能。
先請它複述需求與衝突，第二輪列出變更位置和驗收案例，確認無誤再動手。

例如它說「失敗時清空購物車」，我們就在分析階段發現偏差，不用等到五個檔案改完才追回來。

這個回饋迴圈通常比事後要求「全部重寫好一點」容易控制。
審查時也要留意過度自信的句子。
「測試應該通過」不是執行結果；「後端會回傳」必須有來源。

然後這邊也小建議當 AI 跑的時候可以觀察 AI 都做了什麼。
適時就要插手，別白花了一大堆 Token才發現有問題。

可以交給 AI 的 Prompt

請先閱讀我提供的現行契約與程式片段，輸出已確認事實、來源衝突、未知事項和你對任務的理解。缺少的端點與欄位不得補造。若只能提出假設，請標明假設及可能影響。先不要修改程式，也不要宣稱已執行測試。

這裡用的是資訊來源管理和驗證分離。
讓它知道什麼可以引用、什麼只能推測。

今日練習與筆記

找一段你曾覺得 AI 寫錯的結果，反推是缺來源、來源衝突、需求不明，還是已有足夠資訊仍犯錯。不同原因需要不同修正，不能全部歸因於 Prompt 不夠長。

接著明天把這些材料組成一份可重複使用的任務 Prompt。