AI 音樂生成失敗？重新提交前，先恢復現有任務
不盲目重提 AI 音樂任務：檢查製作卡、已接受任務、下載和積分記錄，並儲存支援團隊調查所需的證據。
如果 AI 音樂生成看起來失敗，先確認服務是否已接受付費任務。頁面卡住、下載按鈕缺失或連線中斷，都不能證明生成停止。保留任務標識，建立另一個付費請求前，先檢查現有任務。
安全順序是：識別階段、記錄證據、恢復已接受的任務（如有）、驗證交付檔案，再單獨調查費用。只有確認此前請求不再活躍，或服務為該任務提供明確、受支援的重試操作時，才重試。
本指南依據 Recapo 公開描述的音樂流程解釋這一順序，不復現付費失敗，也不聲稱某個賬戶已收到退款。示例是構造的排障場景，不是事故報告。
製作卡不是付費音樂任務
Recapo 的 AI 音樂生成器描述了分階段流程：提供創意輸入、審閱製作卡，再在付費提交前確認模型和積分費用。卡片組織擬議音樂，不證明成品歌曲已經生成。
這一區別改變了首個排障問題。如果只完成卡片，沒有音訊下載可能是正常情況。如果已經確認提交併看到任務被接受，問題就屬於後續階段。
公開頁面還描述了可恢復佇列、每位使用者一個活躍音樂任務，以及冪等提交。這些是服務預期行為的說明，不是反覆點選的指令。新的製作請求仍可能代表另一個任務。不要假設在另一標籤頁重複提示詞，總會被視為同一次提交。
調整創作設定前，寫下最後看到的狀態：輸入表單、已完成卡片、確認、已接受任務、佇列進度、完成結果，還是下載失敗。如果無法識別階段，在賬戶任務檢視或支援團隊確認前，應把狀態視為未知。
用可觀察證據定位問題
概念示意圖，並非產品介面截圖。
| 最後可靠觀察 | 它支援什麼 | 最安全的下一步 |
|---|---|---|
| 已輸入內容，未返回製作卡 | 規劃步驟可能尚未完成 | 保留需求；檢查頁面的校驗或連線提示 |
| 卡片已顯示，未確認付費提交 | 計劃存在；生成任務尚未確認 | 審閱卡片及當前確認狀態 |
| 已點選確認，但響應丟失 | 是否接受未知 | 重提前讀取現有任務／賬戶狀態 |
| 出現任務標識或已接受狀態 | 服務已識別一個任務 | 跟進該任務，不建立替代任務 |
| 任務仍在排隊或處理中 | 它可能仍活躍 | 通過受支援介面重新檢視狀態 |
| 狀態完成，但檔案連結失敗 | 生成與交付可能有不同結果 | 恢復已儲存結果，或報告交付失敗 |
| 明確的失敗終止狀態 | 任務報告失敗 | 保留錯誤，新嘗試前檢查積分處理 |
瀏覽器轉圈的證據弱於任務記錄。反過來，舊成功截圖也弱於當前任務狀態。將每項觀察對應到同一個任務、賬戶和日期。
如果多人負責專案，應指定一位恢復操作員。否則，一人可能啟動替代任務，另一人仍在檢查原任務。相關風險是重複工作和潛在重複費用，不只是標籤頁雜亂。
先保留難以重建的內容
在專案說明中儲存創意需求、製作卡文字和歌詞。記錄可見時的所選模型、請求時長、確認積分金額、帶時區的大致提交時間，以及已提供的任務標識。
保留錯誤原文，不要概括成「壞了」。校驗提示、提交被拒、提供方失敗和檔案未找到，指向不同階段。如果截圖，向他人傳送前應裁掉無關賬戶資訊。
不要為支援報告收集密碼、瀏覽器 Cookie、API 金鑰或會話令牌。這些不適合作為排障附件。任務標識及相關錯誤資訊，應足以開始調查。
頁面過載為空白表單時，保留需求尤其有用。表單與付費任務可能有不同生命週期。輸入欄位丟失，不證明後端丟失已接受任務。
即使後來簡化請求，也應保留原始說明。否則無法判斷第二次成功究竟修復了問題，還是隻是把任務改成另一種請求。
如果提交結果未知
這是最容易意外重複的時刻：你點選付費確認，隨後連線斷開，沒有可靠成功或失敗提示。
停止點選。在同一賬戶重新開啟受支援的任務或結果檢視，尋找時間和需求相符的任務。可能時比較標識；標題可能重複。檢查是否有另一個活躍任務阻止新提交。
有三種有用結果：
存在匹配的活躍任務。 繼續跟進該任務。不要僅因原頁面丟失進度顯示就建立替代任務。
存在匹配的已完成任務。 開啟現有結果並驗證交付。瀏覽器中斷可能隱藏了成功生成。
無法確認存在任務。 檢查可見的提交或積分記錄；不確定性仍在時，請支援團隊確認是否接受。一個暫時未更新的列表沒有顯示任務，不足以證明任務不存在。
避免通過改一個詞再提交來「測試」是否接受。那會產生新請求，其表現不能告訴你第一次是否接受，也可能讓賬戶歷史更難核對。
對於緊迫截止專案，在調查狀態期間，可使用已獨立獲授權的備用音樂繼續工作。無需把不確定性變成另一次付費生成才能繼續剪輯。
如果任務排隊或看似卡住
即使進度並非持續變化，佇列也可能活躍。Recapo 公開音樂頁面描述了每位使用者單個活躍任務限制，因此第二次請求未必是恢復第一次任務的適當方式。
檢查最新可見狀態和服務提示。介面提供最後更新時間時應保留；沒有時，記錄自己觀察狀態的時間，不要虛構後端更新時間戳。
沒有一個通用等待時長能證明音樂任務失敗。模型、服務負載、請求複雜度和交付階段都可能不同。使用服務當前提供的指引；超出其說明預期或明顯阻礙工作時，聯絡支援。
有效升級說明應是：「該任務自以下幾次觀察以來，一直處於相同可見狀態」，並附時間和截圖。除非服務確實規定，否則不要聲稱進度百分比必須每分鐘增長。
如果介面提供取消，應先閱讀效果和積分處理說明。不要假設取消可用、立即生效或可退款。取消請求本身也可能結果未知；替換任務前，應驗證終止狀態。
任務完成卻沒有可用下載，是交付問題
生成、儲存和下載相關，但各不相同。Recapo 公開音樂頁面描述了從提供方臨時 URL 儲存成功的 MP3、WAV 和歌詞檔案。因此，舊連結損壞可能需要恢復已儲存交付，而不是重新作曲。
返回現有結果頁面，使用當前受支援的下載操作。避免反覆開啟舊訊息中的過期臨時 URL。不要修改簽名 URL 引數或猜測儲存路徑。
檔案下載後，不只檢查檔名：
- 時長是否合理，能否從頭播放到尾？
- 是否對應請求的人聲或器樂結果？
- 結尾是否完整，而非突然截斷？
- 預期歌詞是否提供，且與可聽版本一致？
- 關閉瀏覽器後，檔案是否仍能重新開啟？
- 預期編輯器是否能無報錯匯入？
副檔名本身不證明檔案是有效音訊。錯誤頁面偶爾可能以誤導名稱儲存。如果本地播放器無法識別，應保留失敗檔案和下載錯誤供支援調查，不要不斷改名直到它看似能用。
只有一種格式缺失時，應準確說明缺失素材。恢復 WAV 匯出，與重新生成作曲，是不同請求。調查缺失檔案時，保留任何有效交付檔案。
區分賬戶積分恢復與現金退款
概念示意圖，並非產品介面截圖。
音樂工具公開說明表示，任務被接受時收取已確認積分費用；符合條件、非使用者原因的失敗會退還積分。這不代表每個創作結果被拒、取消任務或不喜歡的歌曲，都符合條件。
也不應把任務積分撤銷等同於退還最初購買套餐或積分的錢。Recapo 的使用條款包含獨立的付款與退款規定，受適用法律及購買條件約束。應檢查與你的情況有關的政策和賬戶記錄。
記錄確認的任務費用，以及與任務相關的可見扣除或返還。同時發生其他任務、購買或積分變動時，總賬戶餘額可能誤導。介面提供時，優先檢視關聯任務的記錄。
如果失敗任務沒有可見返還，請支援團隊核實資格和處理情況。不要僅因餘額尚未變化就斷言積分永久丟失。同樣，不要僅因產品頁面描述退款機制，就標記退款已收到。
關閉事故所需證據應具體：相關積分調整已可見，或支援團隊已解釋該任務的結果。將此結果與是否已取得可用替代音樂分開記錄。
三個恢復示例
以下場景均為虛構，展示決策，不是觀察到的服務表現。
確認後瀏覽器關閉
創作者為旁白產品影片確認音樂請求。尚未看到響應，瀏覽器就關閉了。重新開啟賬戶後，創作者發現一個匹配任務，有標識且處於排隊狀態。
正確下一步是保留該任務，從記錄繼續。無需重建卡片或再次付費。如果任務之後完成，原中斷應寫入事故說明，但不使生成成為失敗。
如果沒有出現匹配任務，決定仍待確認。創作者應檢查賬戶記錄並請求確認是否接受，而不是把空白表單理解成允許重提。
任務完成，但舊連結返回錯誤
剪輯師在結果交付期間儲存了提供方連結，後來連結失敗，任務本身仍顯示完成。
剪輯師返回已儲存的現有結果，嘗試當前提供的下載。如果也失敗，支援請求應指出已完成任務的交付檔案不可用，而不是要求「重新開始音樂」，因為新輸出可能具有不同時間、旋律或歌詞。
在恢復有效檔案之前，專案仍因交付受阻。任務列表中的完成是有用證據，但不等於經過驗證的本地素材。
檔案已下載，但創作結果不對
團隊請求器樂背景音樂，卻收到包含不需要的類人聲素材的檔案。任務完成，檔案能播放。
這是創作驗收問題，不自動是基礎設施失敗或符合退款條件。團隊記錄不匹配，檢查是否有受支援的糾正方式，並決定另行確認的修訂是否值得費用。
這一區別避免恢復流程變成「每個不滿意藝術結果都能退款」的承諾，也鼓勵下一次有意嘗試使用更清晰的製作卡。
傳送能被調查的支援報告
簡潔報告可以採用以下結構：
主題：音樂任務恢復——任務已接受，交付不可用
賬戶標識：通過服務認可的支援渠道提供
任務標識：可見標識
提交時間：日期、時間、時區
最後可靠狀態：已完成
問題：當前結果下載失敗，附錯誤原文
受影響檔案：WAV；MP3 可用且能播放
積分問題：無，或需要檢查的具體扣除／返還
已嘗試步驟：重新開啟現有結果；嘗試其當前下載
請求操作：恢復已儲存 WAV，或解釋受支援的恢復路線
每個欄位都應替換成真實證據。不要把這個虛構示例當作自己的賬戶情況傳送。如果沒有返回標識，應明確說明，並提供大致時間及足夠需求細節，幫助支援定位請求。
僅描述相關嘗試。冗長的猜測性刷新歷史，可能掩蓋唯一關鍵觀察。除非確有必要且渠道適當，否則應隱去私密歌詞或客戶資訊。
使用線上工具前的更廣泛準備，可參考線上影片工具檢查清單，其中涵蓋相鄰的可靠性與交接考慮。本文事故報告聚焦音樂任務身份與狀態。
何時重試合理
在確認原請求不再活躍，並充分理解失敗原因，使另一次嘗試有價值之後，新生成才可能合理。
重試前回答四個問題：
- 前一任務是否已終止，或已確認從未被接受？
- 同一任務是否有受支援的恢復操作？
- 將改變什麼（如有），來處理報告的問題？
- 新提交顯示什麼費用與條件？
如果服務報告具體無效輸入，就糾正該輸入。如果報告模型不可用，可在合適時使用當前支援的選項。如果沒有可執行原因，一連串相同付費盲試不是好的診斷方法。
將新任務儲存為獨立記錄，並與事故關聯。不要覆蓋舊標識。如果第一任務後來重新顯示完成，你需要區分交付結果，準確核對賬戶。
用素材與記錄結束事故
從操作上看，恢復任務只有在結果已知、相關檔案有效且安全保留，以及積分問題已解決或明確交由後續跟進時，才算結束。
保留未經修改的交付音訊、製作卡和任務記錄。淡化、時間調整或混音應使用編輯副本。恢復檔案在釋出前，仍須通過正常創作、音訊品質和權利審查。
核心習慣很簡單：按身份恢復，不靠重複。未知提交就當作未知，排隊任務就當作可能活躍，下載缺失在證據表明其他原因前就當作交付問題，積分退款就當作必須驗證的賬戶事件。這樣既保留工作成果，也清楚解釋發生了什麼。
