點樣修改 AI 建構嘅 App 而唔搞壞佢

要修改 AI 建構嘅 App 而唔搞壞佢，每個提示只改一樣嘢，喺預覽入面檢查，然後先儲存檢查點再繼續。描述你見到嘅問題，而唔係你以為程式碼點運作；大改動要先計劃再建構；如果改動搞砸咗，就還原到最後一個正常版本，唔好叫 AI 修補它自己嘅修補。

App 嘅第一個版本通常幾分鐘就完成。困難嘅係第五十個改動，每個新提示都有可能搞壞一些本來已經運作嘅嘢。本指南就係防止呢種情況嘅循環。

修改循環

1. 揀一個改動。 一個功能、一個錯誤、一個頁面。
2. 用用戶見到同做到嘅嘢去描述。
3. 大改動要先計劃。 要求一個計劃，睇過先至建構。
4. 喺預覽檢查結果。 檢查改動本身，同埋附近嘅流程。
5. 儲存一個檢查點或者 commit。
6. 重複。

每一步都係為咗保持改動細小同可以還原。

第 1 步：寫一張短清單

喺下提示之前，先寫低你想改咩，並按重要性排序。咁樣可以避免一次過傳送一段十樣願望嘅長訊息，而且當中途冒出新點子時，你可以話「遲啲先做」。

如果改動好大，就拆細佢。「加入團隊帳戶」可以拆成：建立團隊、邀請成員、喺團隊之間切換、將資料限制喺當前團隊。每個都係一個獨立嘅提示。撰寫用戶故事係拆細嘅好方法。

第 2 步：描述你見到嘅嘢

AI 睇唔到你嘅螢幕，除非你講俾佢聽。指出具體嘅嘢，並且講明應該發生乜：

喺手機上嘅價錢頁面，Pro 卡片嘅按鈕喺右邊被切咗一截。桌面版面保持不變；喺 640px 以下嘅螢幕，將卡片堆疊，並且令按鈕闊度全滿。

對比「價錢頁喺手機上睇落好差」。第一個可以一次過做完同檢查；第二個就好似邀請人去重新設計你冇要求嘅嘢。

截圖會有幫助。如果你嘅 builder 接受圖片，就附上一張，並且圈出問題。

第 3 步：大改動之前先計劃

對於會影響 App 多個部分嘅改動（新嘅資料模型、付款、用戶角色），要求喺任何程式碼改變之前先出一個計劃：

唔好改程式碼。我想用戶屬於團隊，並且只可以睇到自己團隊嘅專案。幫我計劃呢個改動：會改變邊啲資料表、頁面同 API 路由，現有用戶嘅資料會點樣處理，以及你會以咩次序去建構。

睇清楚個計劃。如果計劃錯咗，改正計劃遠比還原一次建構便宜。

第 4 步：講明咩嘢唔可以改

AI 工具有時會「順手整理」你冇提及嘅嘢。要保護好已經運作嘅部分：

喺訂單表格加入日期篩選。唔好改表格嘅欄位、樣式或者匯出按鈕。

至於適用於所有地方嘅規則（品牌顏色、語氣、「未經確認絕對唔好刪除資料」），就放入一個 AI 每次都會讀取嘅專案筆記或者知識設定入面，唔好每次重複講。

第 5 步：除咗改動本身，仲要檢查其他嘢

每次下提示之後，要測試：

• 改動本身。 佢係咪做到你要求嘅嘢，喺桌面同手機都得？
• 鄰近嘅嘢。 同一頁面嘅其他嘢，以及用同一份資料嘅流程。
• 關鍵路徑。 註冊、登入、主要操作、付款。每次大改動之後快快地走一遍（大約三十秒），就可以及早捉到大部分壞咗嘅嘢。

如果有嘢唔啱，要準確咁報告，參閱點樣寫好錯誤報告。

第 6 步：還原，唔好繼續疊加

當一個改動搞壞咗某啲嘢，而第一次修補又唔work，就要停手。每一次額外嘅「修補」都係建基於一個已經壞咗嘅狀態上面，問題會越滾越大。

咁做：

1. 還原到最後一個運作正常嘅版本（檢查點或者 Git commit）。
2. 諗清楚提示邊度唔清晰。
3. 用一個更細或者更清楚嘅要求再試一次。

嗰個改動搞壞咗儲存草稿嘅功能。我已經還原咗。呢次只做：喺標題列以文字顯示自動儲存指示器。唔好改草稿嘅儲存方式。

第 7 步：知道幾時應該重建

由零開始重建，會丟棄好多已經運作嘅細節。只有以下情況先至值得重建：

• 產品概念完全改變。
• 底層結構承受唔到你而家需要嘅嘢，例如原本係靜態網站，而家需要帳戶同資料庫。
• 專案仲接近空白。

重建嗰時，要列出要保留嘅嘢：名稱、顏色、文案、用戶鍾意嘅部分。

例子提示

喺我哋繼續之前，請概括而家個 App 點運作：頁面、佢儲存嘅資料，以及你覺得脆弱嘅地方。

我想加入定期預約。最細嘅可用版本係咩？請建議三個獨立改動，我哋可以逐個做。

檢查最近三次改動，睇吓有冇嘢可能搞壞咗結帳流程。暫時唔好改。

常見錯誤

• 一個提示入面有十個要求。 有啲做咗，有啲做咗一半，你分唔清邊啲係邊啲。
• 含糊嘅意見。 「壞咗」或者「改好啲」只會令 AI 亂估。
• 從來唔檢查鄰近嘅嘢。 改動一個共用元件，可能弄壞三個其他頁面。
• 修補修補。 一個錯誤修咗四個提示仲未搞掂，就應該還原。
• 每次都重複背景，而唔係將長期規則放喺專案筆記。
• 卡住就重建。 大部分「重新開始」嘅時刻，其實只係「還原兩步」。

檢查清單

• 每個提示一個目標。
• 我描述我見到嘅嘢，同應該發生嘅嘢。
• 大改動要先有計劃，之後先寫程式碼。
• 我講明咩嘢唔可以改。
• 每次改動之後，我測試改動本身、鄰近嘅嘢，同關鍵路徑。
• 每個運作正常嘅改動之後，我儲存檢查點或者 commit。
• 修補失敗時，我還原，而唔係繼續疊加。
• 長期規則放喺 AI 每次都會讀嘅專案筆記入面。

喺 Mythex 修改

Mythex 就係圍繞呢個循環而設計：

• 計劃、建構同詢問模式。 計劃模式會喺編輯之前討論做法；詢問模式只回答，唔改程式碼；建構模式就會執行改動。參閱聊天。
• 檢查點。 每次成功嘅回合之後，Mythex 都會儲存一個 git 檢查點；還原到呢個點就可以回到嗰度。你亦可以編輯較早嘅訊息，然後用捨棄並重新傳送，從嗰一點試另一個提示。參閱唔重建都可以修改。
• 知識。 專案設定 → 知識，儲存 Agent 每則訊息都會跟從嘅長期筆記。
• /test 可以喺大改動之後，叫 Agent 喺預覽入面似用戶咁撳一輪。

細啲嘅要求亦都耗費較少點數。撰寫提示本身，可以睇點樣為 AI App builder 寫提示；如果真係出錯，就睇點樣除錯 AI 建構嘅 App。

常見問題