如何在不弄壞 AI 建構 App 的情況下持續迭代

要在不弄壞 AI 建構 App 的情況下持續迭代，請每則提示只改一件事，在預覽中確認，然後再儲存檢查點，接著才進行下一步。描述你看到的情況，而不是你猜測程式碼會做什麼；大改動要先規劃再建構；當某個改動出錯時，回退到最後一個正常的版本，而不是要求 AI 修正它自己的修正。

App 的第一個版本通常幾分鐘就能完成。真正困難的是第五十個改動，因為每則新提示都可能弄壞原本正常運作的功能。本指南介紹的是能避免這種情況的循環做法。

迭代循環

1. 選定一個改動。 一個功能、一個錯誤或一個頁面。
2. 描述它，以用戶看到與做到的事情來表達。
3. 大改動先規劃。 要求提出計畫，閱讀後再建構。
4. 在預覽中檢查結果：改動本身，以及附近的流程。
5. 儲存檢查點或提交（commit）。
6. 重複。

每個步驟都是為了讓改動保持小而且可以復原。

第一步：保留一份簡短清單

在下提示之前，先依重要性寫下你想改的事項。這樣你就不會在一則訊息中丟出十個願望，也能在中途冒出的想法上說「先不要」。

如果改動很大，請拆開來做。「新增團隊帳號」可以拆成：建立團隊、邀請成員、在團隊之間切換、把資料限制在目前的團隊內。每一項都是獨立的提示。撰寫使用者故事是很好的拆分方式。

第二步：描述你看到的內容

除非你告訴 AI，否則它看不到你的畫面。請指出具體的地方，並說明應該發生什麼：

在手機上查看定價頁面時，Pro 方案卡片的按鈕在右側邊緣被截掉了。桌面版的版面保持不變；在 640px 以下的螢幕上，請把卡片改為垂直堆疊，並讓按鈕全寬。

和「定價頁面在手機上看起來很糟」相比，前者可以一次完成並檢查；後者則會引來你沒有要求的重新設計。

截圖很有幫助。如果你的建構工具支援圖片，請附上一張，並圈出問題所在。

第三步：大改動前先規劃

凡是會影響 App 多個部分的改動，例如新的資料模型、付款或用戶角色，都要在任何程式碼變更之前先要求提出計畫：

先不要改程式碼。我希望用戶屬於團隊，且只能看到自己團隊的專案。請規劃這項改動：哪些資料表、頁面與 API 路由會改變，現有用戶的資料會怎樣處理，以及你打算以什麼順序建構。

閱讀計畫。如果計畫有誤，修正計畫的成本遠低於撤銷已完成的建構。

第四步：說明什麼絕對不能改

AI 工具有時會「順手整理」你沒有要求的部分。請保護已經正常運作的內容：

在訂單表格中加入日期篩選。不要改變表格的欄位、樣式或匯出按鈕。

對於適用於所有地方的規則，例如品牌顏色、語氣風格、「未經確認絕不刪除資料」，請把它們寫進 AI 每次都會讀取的專案筆記檔或知識設定中，而不是每次重複提醒。

第五步：檢查的不只是改動本身

每則提示之後，請測試：

• 改動本身。 它是否做了你要求的事，在桌面與手機上都正確？
• 相鄰的部分。 同一頁上的其他內容，以及使用相同資料的流程。
• 關鍵路徑。 註冊、登入、主要操作、付款。每次大改動後花三十秒走一遍，大多數壞掉的情況都能及早發現。

如果發現問題，請精確地回報，參閱如何撰寫好的錯誤回報。

第六步：回退，而不是疊加

當某個改動弄壞了某些功能，而第一次的修正沒有用時，請停下來。每一次額外的「修正」都建立在已經壞掉的狀態上，問題會不斷累積。

應該這樣做：

1. 回退到最後一個正常運作的版本（檢查點或 Git 提交）。
2. 找出提示中哪裡不夠清楚。
3. 用更小或更清楚的要求重新嘗試。

這個改動弄壞了草稿儲存功能。我已經回退。這次只做：在標題列以文字顯示自動儲存指示。不要改變草稿的儲存方式。

第七步：知道何時該重建

從頭重建會丟棄許多已經正常運作的細節。只有在以下情況才值得這麼做：

• 產品構想已經完全改變。
• 底層結構無法支撐你現在需要的功能，例如原本是靜態網站，現在需要帳號與資料庫。
• 專案仍然接近空白。

真的要重建時，請列出要保留的內容：名稱、顏色、文案，以及用戶喜歡的部分。

範例提示

在我們繼續之前，請摘要說明目前 App 的運作方式：有哪些頁面、儲存了哪些資料，以及你認為哪些部分比較脆弱。

我想新增定期預約。能發揮作用的最小版本是什麼？請建議三個獨立的改動，讓我們一次做一個。

檢查最近三次改動，看看有沒有可能弄壞結帳流程的地方。先不要編輯。

常見錯誤

• 一則提示裡提出十個要求。 有些完成了，有些只做一半，而你無法分辨哪些是哪些。
• 模糊的回饋。「壞掉了」或「做得更好一點」只會得到猜測。
• 從不檢查相鄰的部分。 改動一個共用元件，可能會弄壞另外三個頁面。
• 修正修正。 針對同一個錯誤已經連續下了四則提示，就該回退了。
• 每次都重複背景資訊，而不是把長期規則保存在專案筆記中。
• 卡住就重建。 大多數「從頭開始」的時刻，其實只需要回退兩步。

檢查清單

• 每則提示只有一個目標。
• 我描述我看到的內容，以及應該發生什麼。
• 大改動在寫程式碼之前先有計畫。
• 我說明了什麼絕對不能改。
• 每次改動後，我測試改動本身、相鄰部分與關鍵路徑。
• 每次成功的改動後，我都會儲存檢查點或提交。
• 修正失敗時，我會回退，而不是疊加修正。
• 長期規則保存在 AI 每次都會讀取的專案筆記中。

在 Mythex 中迭代

Mythex 就是圍繞這個循環設計的：

• Plan、Build 與 Ask 模式。 Plan 在編輯前先討論做法；Ask 只回答問題而不改程式碼；Build 則進行改動。參閱聊天。
• 檢查點。 每次成功的回合之後，Mythex 都會儲存一個 git 檢查點；Revert to this point 可以回退。你也可以編輯較早的訊息並使用 Discard & resend，從該點改用不同的提示重新開始。參閱不重建也能迭代。
• Knowledge（知識）。 專案設定 → Knowledge 會保存 Agent 在每則訊息中都會遵循的長期筆記。
• /test 會在大改動後，讓 Agent 像用戶一樣在預覽中點擊操作。

較小的要求也會消耗較少的點數。關於如何撰寫提示本身，請參閱如何為 AI App 建構工具撰寫提示；當真的出問題時，請參閱如何除錯 AI 建構的 App。

常見問題