如何為 AI 應用程式建置工具撰寫提示詞（附前後對照範例）
為 AI 應用程式建置工具撰寫好的提示詞，要描述的是產品，而不是程式碼：誰會使用它、他們一步一步做什麼、它保存哪些資料，以及誰被允許看到什麼。第一版出來之後，每則訊息只要求一項具體的變更，說明哪些必須保持不變，並以「我做了 X，預期 Y，實際得到 Z」的方式描述問題。這三個習慣就能解決大多數令人失望的結果。
本指南其餘部分會以前後對照範例，詳細說明這些模式，你可以依此調整。
為什麼提示 AI 應用程式建置工具和與 AI 聊天不同
當你向聊天助手提出問題時，模糊的提示詞只會得到模糊的回答，然後你就繼續前進。但當你提示 AI 應用程式建置工具時，得到的答案是一個正在執行的程式。你描述中的每個缺口，都會被猜測填補，而這些猜測會變成你之後必須接受或撤銷的程式碼、資料表與畫面。
因此，提示詞的目標不是聽起來聰明，而是讓重要的決策較少交給運氣。你不需要專業術語來做到這點。你需要的是，針對只有你知道的事情說得具體：你的使用者、你的工作流程，以及你的規則。
第一則提示詞應該包含什麼
在寫任何東西之前，先回答這些問題。每一題都在填補 AI 否則就會猜測的缺口。
| 應包含 | 為什麼重要 | 範例 |
|---|---|---|
| 用一句話描述產品 | 為之後的每個決策設定框架 | 「一間只有兩張理髮椅的理髮店的預約網站」 |
| 誰會使用 | 決定畫面與語氣 | 「在手機上的現場顧客，以及用筆電的店主」 |
| 主要流程，一步一步 | 必須先能運作的核心 | 「選擇服務、選擇時間、輸入姓名與電話，取得確認」 |
| 它保存的資料 | 會成為資料庫設計 | 「服務、預約、顧客」 |
| 誰能查看或更改什麼 | 決定登入與權限 | 「只有店主能看到所有預約」 |
| 外觀與感覺，簡要說明 | 避免出現千篇一律的預設風格 | 「深色、簡潔、按鈕要大」 |
| 暫時不做什麼 | 讓第一版保持精簡 | 「目前不做付款或評價」 |
最後一列常被低估。說明你不要什麼，能避免 AI 新增你從未要求的部落格、定價頁面或電子報訂閱表單。
前後對照：第一則提示詞
之前：
幫我的健身房做一個應用程式。
建置工具必須猜測一切：是給會員還是員工用？團體課還是私人教練？有沒有付款？你會得到一個看起來像健身房網站、卻做不了你需要之事的東西。
之後：
為一間小型瑜伽工作室打造課程預約應用程式。會員可以查看本週的課程（課名、老師、時間、剩餘名額）、預約名額，並在上課前兩小時取消。會員以電子郵件與密碼註冊。工作室老闆登入後可以新增課程、查看誰已預約，並標記出席狀況。課程、會員與預約資料都存入資料庫。外觀清爽、柔和，並在手機上運作良好。目前不做付款。
第二個版本依然簡短，它只是回答了上表中的問題。
描述行為，而不是實作方式
如果你描述的是應該發生什麼，而不是該如何建置，通常能得到更好的結果。
之前：
加一個 useEffect 來抓取預約資料，再加一個用於編輯的 modal 元件。
之後：
當老闆點擊某筆預約時，開啟一個面板，讓他可以更改時間或取消。變更應立即反映在列表中。
第一個提示詞把 AI 鎖定在某種特定技術上，而那種技術可能不符合應用程式既有的架構。第二個提示詞告訴它結果是什麼，讓它為已經寫好的程式碼選擇正確的做法。如果你是開發者，而且確實有強烈偏好，請直接說明，但要搭配預期的結果。
把規則說清楚
AI 製作的應用程式最常出錯的地方就是商業規則。這些規則在你眼中再明顯不過，對 AI 來說卻看不見。請把它們寫明白。
- 限制：「會員最多只能持有三筆未來的預約。」
- 時限：「課程開始前兩小時截止取消。」
- 邊緣情況：「若課程已滿，顯示候補按鈕，而不是預約按鈕。」
- 權限：「老師只能看到自己課程的出席紀錄，看不到其他老師的。」
每一條都只是一句話。漏掉任何一條，應用程式就會不執行這項規則，或自行發明一個版本。
第一版之後：每則訊息只做一項變更
一旦某個東西已經在預覽中運作，就從描述整個產品，改為要求小而可檢查的變更。
之前：
設計不太對，預約也不太正常，我還要一個日曆檢視和電子郵件。
之後（拆成四則獨立訊息）：
- 當我預訂課程的最後一個名額時，課程仍然顯示「剩餘 1 位」。應該改為顯示「已額滿」，並隱藏預約按鈕。
- 在課表頁面加入週檢視日曆，每一天一欄。保留目前的列表檢視作為選項。
- 讓課程卡片在手機上更緊湊：縮小內距，並把老師姓名與時間放在同一行。
- 會員預訂時，寄送確認電子郵件給他。
這樣做的原因：
- 每項變更都夠小，AI 通常一次就能做對。
- 你可以在進入下一步之前逐一測試。
- 如果其中一項出錯，你可以只回退那一步，而不會失去其他變更。
說明要保留什麼
當你要求修改某個已經能運作的東西時，請告訴 AI 什麼絕對不能改。這是避免退化（也就是原本能用的東西，在編輯後壞掉）最簡單的方法。
重新設計首頁的主視覺，標題放大，右側加上一張照片。導覽列、配色，以及主視覺以下的所有內容都保持原樣。
資料也一樣：「為會員新增電話欄位。不要刪除或重新命名任何現有欄位。」
使用截圖與確切文字
「最上面那個東西」這類說法很含糊。大多數 AI 應用程式建置工具都接受圖片，一張截圖加上簡短說明，會比一大段文字描述更快。
- 附上截圖，並說明「紅色圈起來的按鈕在手機上會蓋住選單」。
- 錯誤訊息請貼上原文，不要轉述。
- 畫面上的標籤要照原文引述：「設定頁面上的儲存變更按鈕」。
針對錯誤，使用這種格式：
在預約頁面，我點了明天那筆預約的取消。我預期它會從列表中消失。結果什麼都沒發生，重新整理後預約仍然在。請修正，並確認取消功能可以正常運作。
我們的指南如何除錯 AI 製作的應用程式會更深入說明這一點。
大型變更前先規劃
對於會牽動應用程式多個部分的變更，例如為原本沒有帳號的應用程式加入使用者帳號、加入付款，或是改變資料的結構，請在任何程式碼變動之前先要求一個計畫。
在改動任何東西之前，先說明你會如何加入團隊帳號：需要新增哪些資料表、哪些頁面會改變，以及現有使用者會發生什麼事。目前先不要編輯程式碼。
仔細閱讀計畫。如果它誤解了什麼，修正一段文字的成本遠低於修正一個已完成的功能。許多建置工具都有專門的模式來處理這件事；在 Mythex 中，它就是 Plan 模式，另外還有 Build 與 Ask 模式。
應避免的事
| 應避免 | 原因 | 改為 |
|---|---|---|
| 「讓它更好」／「讓它更醒目」 | 沒有明確目標，AI 會隨機改動 | 指明變更：「區塊之間留更多空白，標題放大」 |
| 一則巨大的提示詞，包含十個功能 | 錯誤會累積，也難以測試 | 每則訊息只處理一個功能 |
| 把 API 金鑰貼到聊天中 | 金鑰會留在聊天紀錄裡 | 使用建置工具的密鑰或環境設定 |
| 與損壞的結果爭辯 | 每次修正都疊加在錯誤之上 | 回退，然後換個說法 |
| 指定你看不懂的程式碼 | 會鎖死一個不合適的做法 | 描述你想要的行為 |
| 要求「企業級安全」 | 這句話沒有具體意義 | 列出實際規則：誰能看到什麼 |
關於 API 金鑰：如果你需要付款或電子郵件服務，請把它的金鑰放進專案的密鑰中，而不是寫在提示詞裡。如果這個概念對你還陌生，請參見什麼是環境變數與密鑰。
可重複使用的提示詞範本
把方括號中的部分替換掉，就能調整使用。
新應用程式：
為[誰]打造一個[應用程式類型]。他們[主要流程，一步一步]。[第二種使用者]登入後[他們做什麼]。把[資料]存入資料庫。[外觀與感覺]。暫時不做[之後的事項]。
新功能：
在[頁面]新增[功能]。當[使用者]執行[動作]時，[應該發生什麼]。只有[誰]可以[做這件事]。保持[既有內容]不變。
設計變更：
在[頁面]中，把[特定元素]改為[具體變更]。保持[要保留的內容]不變。確認它在手機寬度的螢幕上看起來正常。
錯誤：
在[頁面]，我[步驟]。我預期[預期結果]。實際上[實際結果，並附上確切的錯誤文字]。請修正，並驗證流程可以正常運作。
只問問題、不做變更：
不要更改任何程式碼。說明[應用程式的某部分]如何運作，以及[資料]存放在哪裡。
撰寫較長的規格
對於較大的專案，可以先寫一份一頁的簡要說明，並把它貼上作為開場提示詞：使用者、核心流程、資料、規則，以及排除的範圍。你甚至可以請 AI 協助起草它。我們關於如何用 AI 撰寫產品需求文件的指南說明了做法。只需把第一則建置要求限定在核心流程，其餘的再一步一步加入。
在 Mythex 中撰寫提示詞
以上所有方法在 Mythex 中都適用。以下是幾個有助益的具體做法：
- **Build、Plan 與 Ask 模式。**對於大型或有風險的變更，使用 Plan；若只想要解釋而不做編輯，則使用 Ask。
- 檢查點。每次成功的變更後，Mythex 都會儲存一個檢查點，對某則回覆按下還原到此處，就能把專案回退。你也可以編輯較早的訊息並重新送出，從該點嘗試不同的提示詞。
- **密鑰卡片。**當代理需要 API 金鑰時，它會透過聊天中的卡片提出請求，讓這個值被儲存為專案密鑰，而不是寫進你的訊息裡。
- **圖片。**附上截圖或設計稿，代理就會查看它們。
文件中有一頁簡短的有效提示詞，以及一頁關於不必重建即可迭代。如果你是從零開始，如何用 AI 打造應用程式會逐步說明一個完整的專案，而如何用 AI 設計外觀出色的應用程式則涵蓋了視覺精修的提示詞。
常見問題
為 AI 應用程式建置工具撰寫的提示詞應該多長？
第一版通常四到八句話的一段文字就足夠：誰會使用這個應用程式、主要流程、它保存哪些資料，以及誰能看到或更改什麼。之後，每次只要求一項變更的簡短提示詞，比冗長的提示詞效果更好。
我應該告訴 AI 要使用哪個框架或程式語言嗎？
只有在你有理由時才需要，例如之後會接手程式碼的開發者，或是只能搭配特定技術堆疊運作的服務。否則，就描述你的產品，讓建置工具自行選擇合理的預設值。
為什麼 AI 總是改動我沒有要求它改的東西？
通常是因為提示詞太籠統（例如「讓它更好」），或是沒有說明哪些要保留。請指明要改的確切項目、說明哪些必須維持不變，並且每則訊息只要求一項變更。
遇到不理想的結果，應該用更多提示詞修正，還是重新開始？
如果上一次的變更讓情況變得更糟，就回退到它之前的版本，並換個說法重新提出，而不是在錯誤上一層層地疊加修正。只有當構想本身已經改變時，才需要開一個新專案。