如何為 AI 應用程式生成器撰寫提示（附前後對照例子）

為 AI 應用程式生成器撰寫的好提示，描述的是產品，而不是程式碼：誰使用它、他們一步一步做什麼、它保存什麼數據，以及誰獲准查看哪些內容。第一版完成之後，每條訊息只要求一項具體的改動、說明什麼必須保持不變，並以「我做了 X，預期 Y，結果是 Z」的方式描述問題。這三個習慣能解決大部分令人失望的結果。

本指南餘下的部分會詳細展示這些寫法，並附上可以按需要改編的前後對照例子。

為何向應用程式生成器下提示，與和 AI 閒聊不同

向聊天助手提問時，含糊的提示只會得到含糊的答案，你大可以就此作罷。但向 AI 應用程式生成器下提示，得到的是一個可以運行的程式。你描述中的每一處空白，都會被猜測填滿，而這些猜測會變成程式碼、資料庫資料表和畫面，之後你必須接受或撤銷。

所以，提示的目標不是聽起來很聰明，而是盡量減少把重要決定交由機會決定的情況。要做到這點不需要技術術語，只需要具體地說明那些只有你才知道的事：你的用戶、你的工作流程，以及你的規則。

第一個提示應包含什麼

在動筆之前，先回答以下問題。每一項都是填補 AI 否則只會猜測的空白。

最後一行最容易被忽略。說明你不要什麼，可以防止 AI 加入你從未要求的網誌、定價頁面和電子報訂閱。

前後對照：第一個提示

修改前：

幫我做一個健身室用的應用程式。

生成器必須猜測一切：會員還是員工？團體課還是私人教練？有沒有付款？最後你得到的，是一個看起來像健身室網站、卻做不到你需要的功能的東西。

修改後：

為一間小型瑜伽室建造課堂預約應用程式。會員可以查看本週的課堂（名稱、導師、時間、剩餘名額）、預約名額，並可在開課前兩小時取消。會員以電郵和密碼註冊。瑜伽室負責人可以登入，新增課堂、查看哪些人已預約，並標記出席情況。將課堂、會員和預約保存在資料庫中。外觀簡潔明亮，在手機上運作良好。暫時不設付款功能。

第二個版本仍然不長，它只是逐一回答了上表的問題。

描述行為，而非實作方式

與其說明應該怎樣建造，不如描述應該發生什麼，這往往會得到更好的結果。

修改前：

加入一個 useEffect 來取得預約資料，並加入一個用於編輯的彈出視窗元件。

修改後：

當負責人點擊某個預約時，打開一個面板，讓他們可以更改時間或取消預約。更改後應立即在列表中反映。

第一個提示會把 AI 鎖定在某種特定的技術，而這種技術未必配合應用程式現有的建造方式。第二個提示則告訴它預期的結果，讓它為已寫好的程式碼選擇合適的做法。如果你是開發人員，而且確實有強烈的偏好，可以說明，但也要同時說明預期的結果。

把規則說得具體

業務規則是 AI 建造的應用程式最常出錯的地方，因為對你來說顯而易見，對 AI 來說卻是看不見的。請把規則說清楚。

• 限制：「每位會員最多只能有三個未來的預約。」
• 時限：「取消截止時間為開課前兩小時。」
• 邊緣情況：「如果課堂已滿，顯示候補按鈕，而不是預約按鈕。」
• 權限：「導師可以查看自己課堂的出席紀錄，但不能查看其他導師的。」

以上每一項都只需一句話。遺漏任何一項，應用程式要麼不會執行該規則，要麼會自行發明一個版本。

第一版之後：每條訊息只改一項

當應用程式已經在預覽中運行，就應由描述整個產品，轉為要求小型、可以逐項核實的改動。

修改前：

設計不對，預約功能也不正常，我還想要日曆檢視和電郵通知。

修改後（分四條獨立訊息發送）：

1. 當我預約某課堂的最後一個名額時，該課堂仍顯示「剩餘 1 個名額」。應改為顯示「已滿」，並隱藏預約按鈕。
2. 在時間表頁面加入週檢視日曆，每日一欄。保留現有的列表檢視作為選項。
3. 在手機上讓課堂卡片更緊湊：減少內距，導師姓名與時間放在同一行。
4. 會員預約時，發送確認電郵給他們。

這樣做有效的原因：

• 每項改動都足夠小，AI 能一次做對。
• 你可以在進入下一步之前逐項測試。
• 如果其中一項出錯，你可以只回復那一步，而不影響其他改動。

說明要保留什麼

當你要求修改一項已經運作正常的功能時，請告訴 AI 什麼絕對不能改。這是防止退步（即以前能用的功能因編輯而壞掉）的最簡單方法。

重新設計首頁的主標題區，加大標題，並在右邊加入一張相片。導覽列、顏色，以及主標題區以下的所有內容請保持完全不變。

數據方面也適用同樣道理：「為會員加入電話號碼欄位。不要刪除或重新命名任何現有欄位。」

使用截圖和確切文字

「頂部那個東西」之類的字眼含糊不清。大部分 AI 應用程式生成器都接受圖片，而附上截圖加上一句簡短說明，比用一段文字描述更快。

• 附上截圖，並說明「紅色圈出的按鈕在手機上與選單重疊」。
• 貼上任何錯誤訊息的原文，不要改述。
• 準確引用畫面上的標籤：「設定頁面上的儲存變更按鈕」。

對於錯誤問題，可以採用以下格式：

在預約頁面，我點擊了明天那個預約的取消。我預期它會從列表中消失，但結果什麼都沒發生，重新整理後預約仍然存在。請修正，並確認取消功能運作正常。

我們關於如何除錯 AI 建造的應用程式的指南，會更深入地探討這方面的內容。

大型改動要先制定計劃

對於會影響應用程式多個部分的改動，例如為原本沒有用戶帳戶的應用程式加入用戶帳戶、加入付款功能，或更改數據的結構，請在任何程式碼改動之前，先要求提供計劃。

在改動任何內容之前，請說明你會如何加入團隊帳戶：會新增哪些資料表、哪些頁面會改變，以及現有用戶會有什麼變化。暫時不要編輯程式碼。

細閱計劃。如果它誤解了某些內容，修正一段文字的成本，遠低於修正一項已完成的功能。許多生成器都設有專用的模式；在 Mythex 中，這就是計劃模式，與建造和詢問模式並列。

應避免的做法

關於 API 金鑰：如果你需要付款或電郵服務，請把它的金鑰放在專案的機密設定中，而不是寫在提示內。如果你對此還不熟悉，請參閱什麼是環境變數和機密資料。

可重複使用的提示範本

以下範本可替換方括號中的部分後使用。

新應用程式：

為[誰]建造一個[應用程式類型]。他們會[主要流程，逐步說明]。[第二類用戶]登入後，可以[他們做什麼]。將[數據]保存在資料庫中。[外觀與感覺]。暫時不包含[留待以後的功能]。

新功能：

在[頁面]加入[功能]。當[用戶]執行[行動]時，[應該發生什麼]。只有[誰]可以[做什麼]。保持[現有內容]不變。

設計改動：

在[頁面]，把[具體元素]改為[具體改動]。保持[需要保留的內容]不變。請檢查它在手機寬度的螢幕上是否顯示正確。

錯誤問題：

在[頁面]，我[步驟]。我預期[預期結果]。實際結果是[實際情況，加上確切的錯誤文字]。請修正並確認流程運作正常。

只提問、不改動：

請不要更改任何程式碼。解釋[應用程式的某部分]如何運作，以及[數據]儲存在哪裡。

撰寫較長的規格

對於較大型的專案，可以先寫一份單頁的簡介，然後把它貼上作為開場提示：包括用戶、核心流程、數據、規則，以及不屬於範圍的內容。你甚至可以請 AI 協助草擬，我們關於用 AI 撰寫產品需求文件的指南會說明方法。首次建造的要求只需涵蓋核心流程，其餘的內容則逐步加入。

在 Mythex 中撰寫提示

以上所有方法在 Mythex 中都適用。以下幾點特別有幫助：

• **建造、計劃和詢問模式。**進行大型或風險較高的改動時使用計劃模式；當你只想要解釋而不想編輯時，使用詢問模式。
• 檢查點。每次成功改動後，Mythex 都會儲存一個檢查點，在回覆上使用回復至此點，即可把專案回復到該狀態。你也可以編輯較早的訊息並重新發送，從該點嘗試另一個提示。
• **機密資料卡。**當代理需要 API 金鑰時，它會透過聊天中的卡片詢問，讓數值以專案機密資料的形式儲存，而不會寫入你的訊息中。
• **圖片。**附上截圖或設計稿，代理便會查看它們。

文件中有一頁簡短介紹有效的提示，另一頁介紹不重建而逐步修改。如果你從零開始，如何用 AI 建造應用程式會逐步介紹一個完整的專案，而如何用 AI 設計外觀出色的應用程式則涵蓋視覺潤飾的提示。

常見問題