Suno Speech Podcast 開場：腳本與驗收工作表

在生成 Podcast 開場白之前，先備好三樣東西：要朗讀的文字、一段簡短的人聲與配樂方向說明，以及一份會讓你否決生成結果的理由清單。本教程為一個虛構節目**《小修小補》（Small Repairs）**提供這三樣內容。最終成果是一份可用於你自己試做的工作表，而不是宣稱本文示例已經通過音訊測試。

Suno 於 2026 年 10 月 1 日發布的 Speech 公告說明了「提供文字並描述人聲與配樂」的基本工作流程。帳號介面的細節和匯出權限不在本工作表範圍內。請開啟你自己 Suno 帳號中可用的 Speech 功能，在生成前先檢視它目前的控制選項。本文不假定任何具體的選單路徑、長度限制或付費方案權益。

1. 寫一段只完成一個任務的開場白

《小修小補》是一個虛構節目，講的是日常修理，以及人們一直留著的物件。它的開場白應該交代這個主題，並把聽眾引入一集節目。它不需要贊助口播、社交帳號清單，也不需要對整季內容的概括。

請使用這段原創英文練習腳本（保留英文原文，以便你與 Suno 的輸入保持一致的參照）：

A loose chair leg. A radio that only works when you hold the dial.
Small Repairs is a show about the things we keep, and the people who help us keep them.
Today, we start with one kitchen drawer.

前兩個物件提供了可辨識的畫面。中間一句點明節目名稱。最後一句轉入本期內容。如果你的開場白沒有明確的去向，加音樂並不能解決這個編輯層面的問題。

輸入之前，先自己把文字朗讀一遍。標出你會接不上氣、或讀丟句意的地方，優先刪短這些段落。如果長度很重要，可以給自己的朗讀計時，但要把它標註為規劃估算：生成的錄音可能採用不同的語速。

如果要製作其他語言的版本，請圍繞同樣的任務寫一段自然的當地語言腳本。不要用英文試做來推斷該語言的發音品質或長度。這裡保留英文示例，是為了讓你能一致地對比自己的輸入。

2. 把內容與方向說明分開

把旁白文字和製作方向分別記錄，然後按照你實際介面中的欄位分別填入。這樣可以防止「留一個停頓」這類指令混進你本想讓人聲朗讀的正文裡。

以下是第一版的擬定方向說明（作為提交給 Suno 的提示內容，同樣保留英文原文）：

Conversational spoken delivery, close and unhurried.
Sparse muted guitar beneath the narration.
Leave room after the two opening objects.
No sung hook; let the last sentence finish clearly.

這些是自然語言請求，並非有文件記載的長度控制指令。模型的理解可能與你的預期不同。在你還不清楚更簡單的請求會有什麼表現之前，不要追加一長串樂器清單或相互矛盾的形容詞。

試做之前，把腳本和方向說明存為版本 A。記錄日期，以及你實際選擇的各項設定。不要照搬別人截圖或舊教程裡的設定來填寫。如果找不到某個預期中的控制項，如實記下這個差異，而不是自己編造一個等效項。

立即開始創作

3. 先查文字，再聽氛圍

對照腳本逐句聽。記下遺漏、多出來的詞、重複的短語和聽不清的名稱。就本例而言，節目名稱和「廚房抽屜」這個過渡必須保住。音樂鋪底再悅耳，也彌補不了唸錯節目名的問題。

接下來，不看腳本純聽一遍。只聽音訊，你能跟上這段開場白嗎？列印出來的腳本會讓一個含糊的詞顯得比實際更清晰。用平常的音量聽；把音量開大，可能會掩蓋你的聽眾真正會遇到的問題。

最後，檢查開頭和結尾。第一個詞不應有被切斷的感覺，最後一個句子應該在你計劃做的任何剪輯之前完整收住。記下實際長度。規劃表裡的目標長度，並不能證明輸出達到了它。

4. 每次只改一個因素，並留下記錄

如果音樂與人聲爭奪注意力，用同樣的腳本和人聲方向做一個版本 B，只把伴奏改得更簡單。一個可行的實驗是用稀疏、低強度的打擊樂替換悶音吉他。這只是一個提議中的對比方案；我們並沒有生成過其中任何一個版本，也沒有得出哪個更優的結論。

如果問題出在文字本身，那就修改腳本，並給它一個新的版本標識。不要拿新腳本配上不同的音樂，然後把這個差異稱為一次獨立的音樂測試。一份小而清晰的版本歷史，比一個裝滿未命名嘗試的資料夾更好用。

記錄項	試做後填寫的內容
版本與日期	與已儲存的輸入和輸出相對應的標識
腳本	實際提交的原文
方向說明	實際提交的人聲與配樂請求
實際長度	實測長度，而非目標值
文字錯誤	具體的遺漏、新增或含糊詞句
音樂干擾	受影響的句子或時間點
結論	保留、修改或更換製作方式，並註明理由

在聽過之前，讓結果欄保持空白。這張表是工作表，不是一組已經成功的測試結果。

5. 針對每種失敗給出具體對策

朗讀變得像唱歌。 重新審視口播方式的請求，刪掉與任務衝突的音樂方向描述。在認定該請求能穩定產出你想要的朗讀方式之前，先再測一次。

某個名稱聽不清。 在筆記中把這句話單獨摘出來。試試簡化上下文措辭；只有當介面支援時，才使用發音輔助手段。真實人名的發音如果沒把握，不要靠猜測就發布。

停頓破壞了句意。 調整標點，或拆分句子。每次只改其中一個因素。Suno 已把停頓行為列為 beta 階段的限制，因此不要投入無限次的重試，試圖強行得到一個固定模式。

音樂蓋過人聲。 在請求中讓伴奏更簡單、更稀疏，或計劃把旁白和音樂分開製作。如果需要後者，可以從背景配樂指南入手。

錄音太長。 刪掉對開場白沒有貢獻的字句。再次檢查修改後錄音的長度。給最終檔案加速是另一項剪輯決策，而且可能影響聽辨清晰度。

6. 發布前先定好交付標準

只有當關鍵文字準確、語音可以聽懂、首尾字詞完整、長度符合實際用途時，才保留某個版本。如果耳機和手機外放都代表你的聽眾，就在你常用的耳機和手機喇叭上各聽一遍。失敗就是失敗，如實記錄；不要因為另一臺裝置聽起來還行，就把它平均成及格。

然後核實目前的匯出選項，以及與你的預期用途相關的權限。在允許的範圍內儲存確認採用的檔案，並連同它的腳本、方向說明和審聽記錄放在一起。分享一個可用連結，不等於交付了一份確認採用的音訊檔案。

本工作流程針對的是 Suno 官方的 Speech 功能。該功能在 MidassAI 中的可用情況尚未核實。關於「聯合生成還是分開製作」這一更大的取捨，請閱讀什麼時候適合在專案中使用 Speech。完成後的工作表應該讓這個決策清晰可見——即使最好的結果是改用其他製作方式。