ElevenLabs 讓逐字稿依指令編輯：保留原文，才能分清轉錄與改寫
ElevenLabs 新增實驗性逐字稿編輯，回傳原始轉錄與獨立編輯文字。本文解析格式整理、額外費用、時間戳限制，以及訪談與會議資料的儲存方法。
逐字稿常需要整理日期、縮寫與段落，但整理後的文字和原始語音紀錄已經不是完全相同的資料。ElevenLabs 新增 Transcript Editing，讓使用者在語音轉文字請求中附上自然語言指令，轉錄完成後再產生編輯版，並與原文一起返回。
這項功能最值得理解的地方，是它保留兩種表示。原始文字、逐詞時間戳與說話者資訊仍對應原始轉錄，編輯版則是另外返回的純文字。它不是改掉原始音訊，也不能直接把改寫後的每個字套回原有時間戳。對訪談、會議與客服資料，這個區分會影響查證與後續使用。
轉錄與編輯，回答不同需求
轉錄的目的是把說話內容變成文字，編輯則依要求改變文字呈現。把口語日期改成固定格式、展開縮寫或調整段落，都屬於後處理。模型可能讓內容更好讀，但編輯結果不能取代原始紀錄。
例如一個人說下週再確認，整理版可能改成一條待辦。如果編輯擅自加上確切日期，就可能增加原音中沒有的資訊。團隊應根據用途決定允許的改動，並核對是否仍保留原意。
對需要忠實引用的內容，原始轉錄與音訊仍應保留。對需要快速閱讀的內部摘要，則可以使用編輯版。兩種用途可以並存，關鍵是讓使用者知道自己正在看哪一種資料。
官方功能屬於實驗性後處理
官方檔案將逐字稿編輯標為實驗功能，額外費用為基礎轉錄成本的百分之三十，每個請求至少按十秒音訊計費。指令最多兩千字元，編輯發生在轉錄之後，也會增加等待時間。
這些條件說明它是轉錄管線中的額外步驟。若只需要某些常見調整，官方建議優先使用更專門的引數，例如術語提示、移除填充詞或數字格式。專門引數可能更便宜，也更可預測。
實際費用仍應依目前服務價格與音訊時長確認。短音訊特別要注意最低計費，不把幾秒鐘的內容直接按實際秒數估算。企業試用應同時記錄編輯成功、延遲與費用，才容易判斷是否值得整合。
原始欄位與編輯欄位，應分別儲存
官方回傳中的 text 與 words 描述原始轉錄，編輯內容在 edited_transcript 中。後者會說明成功返回文字，或發生編輯錯誤。若編輯失敗，原始轉錄仍可能已經成功返回。
應用程式應分別處理這兩種狀態。不能只因為編輯失敗，就把整次轉錄標成失敗。也不能因為原文存在，就假設編輯版已經完成。狀態清楚，後續重試與人工接手才容易安排。
資料儲存可以保留原始轉錄、編輯要求、編輯結果與模型版本。這樣有人質疑文字變化時，團隊能夠回到來源，判斷是辨識錯誤還是後處理改變。沒有這層區分，往往只能重新聽全部音訊。
Transcript Edit 官方發布與示範影片。此為官方展示，並非本文實測結果。 影片來源：ElevenLabs Developers 官方發布素材。
時間戳仍對應原文，不能直接套到改寫文字
逐詞時間戳標記原始轉錄中的詞何時出現。編輯版可能刪詞、改詞或重新組織句子，因此原有時間位置未必能直接套用。官方明確說明時間戳、說話者標籤與其他格式仍描述原始內容。
如果要製作字幕，應先確認需要忠實字幕還是整理字幕。忠實字幕可以使用原始轉錄與對應時間。整理字幕則可能需要重新安排或對齊。不能只把編輯後的文字替換進去，就假設所有時間仍正確。
說話者也有類似問題。編輯版是純文字，若重組多個段落，應用程式應確認沒有把不同人的陳述合成同一人觀點。對訪談引用，這類變化尤其需要核對。
指令應描述具體改動
「修好這份稿」很難定義正確結果。比較清楚的要求是統一日期格式、保留原文內容、只展開展示過的縮寫，或把每句話分成獨立專案。指令越具體，結果越容易驗收。
官方說明指令會在整個轉錄中對所有符合條件的內容生效，不只修改第一次出現的位置。因此，要求替換某個詞時，應考慮它在不同上下文中的意義，避免造成不適當的全篇變化。
一項指令可以包含多種編輯，但首次試用最好先從單一目的開始。日期格式與語氣改寫同時發生，失敗時很難判斷原因。把修改分清楚，也能讓團隊決定哪些變化可以自動接受。
用訪談資料試用，先鎖定保留要求
以下是測試設計示例。選擇一小段訪談，保留原始音訊與人工核對的逐字稿，只要求整理段落與統一日期。姓名、數字、否定詞與不確定說法都應保持，避免編輯把保留語氣改成確定結論。
審查時可以比較原文與編輯版差異，特別檢查「可能」「還沒」「不確定」等影響意思的詞。文字更流暢，不代表事實更準確。若這些詞被刪掉，引用可能改變受訪者原本表達。
透過後再加入其他格式要求，並繼續保留差異核對。對需要忠實記錄的工作，自動化可以減少整理負擔，但不能替代來源檢查。編輯範圍應由使用者的用途決定。
會議待辦，不能憑整理自行增加承諾
會議中有人提出建議，不一定已經形成決定。編輯版如果把建議整理成待辦，可能讓讀者誤以為已經確定負責人或期限。任務應明確要求區分提議、決定與尚未確認事項。
可以讓結果保留原句或來源位置，幫助會議參與者核對。若資料沒有負責人或日期，應說明缺少，而不是自行補齊。完整的待辦看起來更好用，卻可能增加會議中不存在的承諾。
實際流程可以先用編輯版供閱讀，再由負責人員確認正式行動清單。這樣模型負責整理，人負責確認決策，職責比較清楚，也能減少誤解。
遮蔽文字，不等於原始資料已經刪除
編輯指令可以要求替換或遮蔽部分文字，但原始轉錄仍然返回。若應用程式儲存原文，敏感內容可能仍在資料庫裡。不能只看到編輯版沒有出現，就宣告全部資料已經移除。
系統需要依儲存用途安排原文與編輯版的存取。對外展示可能只用整理版，內部核對可能保留原文，兩者應有清楚邊界。刪除要求也需要檢查實際儲存位置，而不只是改變顯示文字。
官方還說明逐字稿編輯不能與指定的實體偵測、實體遮蔽與多通道引數同時使用。整合前應檢查引數組合，避免請求被拒絕。文字編輯與專門遮蔽功能有不同條件，不應混為同一能力。
音訊內容應當資料，不能改變編輯要求
官方檔案說明，只執行使用者提供的編輯指令，音訊中說出的內容被視為資料。這個區分很重要：錄音裡有人說「忽略前面的要求」，不應改變目前的處理方式。
應用程式也可以延續這種原則，把編輯要求與轉錄內容分開傳遞與儲存。資料中的命令句可能只是訪談或會議的一部分，不等於使用者目前授權。清楚區分資料與操作，有助於減少不相關變化。
審查時可以準備一段含有命令式語句的測試資料，確認結果仍按原先格式處理。這是功能驗收的情境設計，並非本文實測。它能幫助團隊檢查後處理是否遵守預定範圍。
編輯失敗，重試應針對正確階段
若原始轉錄成功、編輯失敗，系統可以保留原文並標記編輯待處理。不要為了重做後處理，就無條件把整段音訊重複轉錄，增加費用與版本差異。具體重試方式應依可用介面與系統設計確認。
也要記錄失敗原因與指令。過長要求、引數衝突與服務錯誤需要不同處理。只有一個失敗標記，會讓維運人員很難決定下一步，也可能讓使用者誤以為原始資料已經丟失。
使用者介面可以清楚顯示原文可用、編輯未完成，讓人選擇繼續閱讀或安排處理。透明狀態比隱藏失敗後自動展示某個舊版本更容易建立信任。
即時與批次，使用情境不同
官方說明批次請求與非同步回傳支援編輯內容，即時 Scribe v2 也支援對已提交的轉錄片段使用指令。即時資料可能分段出現，整篇格式與跨段落整理則需要另外規劃。
如果編輯要求依賴完整上下文，短片段可能不足以判斷。團隊應確認哪些變化適合即時處理，哪些要等完整內容後再整理。不要把批次效果直接假設成每個即時片段都有相同結果。
延遲也應依用途評估。會議後整理可以容許較長等待，即時字幕則更敏感。功能支援與體驗適合是不同問題，需要在實際流程裡測試。
成本與品質，要以最終用途比較
額外百分之三十費用可能換來較少的後處理工作，但團隊仍需要計算審查與修正。若原本只需簡單格式轉換，使用確定性程式處理可能更合適。若需求涉及複雜語氣與結構，模型編輯則值得試用。
可以比較手動整理、獨立後處理與整合編輯三種方式，記錄費用、時間與錯誤。選擇依據不是哪個步驟最自動化，而是哪個方式能可靠完成用途，並保留必要來源。
對訪談與會議，保留原文通常是最重要的基礎。編輯能力讓資料更容易閱讀，原始依據則讓人能夠查證。兩者一起管理，才能把效率改善轉成可持續使用的工作流程。
這項功能最值得帶走的原則
ElevenLabs 逐字稿編輯把轉錄與後處理接在同一次請求中，減少流程銜接，但也讓資料版本更需要區分。原文、編輯要求、編輯結果與狀態，應成為系統明確儲存的內容。
使用者先定義允許改變的範圍，再核對關鍵事實與時間關係，就能判斷功能是否適合。流暢的文字可以幫助閱讀，忠實的來源則支援信任。把這兩種價值同時保留，才是逐字稿工具進入真實工作時最重要的條件。
顯示名稱，應讓讀者知道版本性質
如果系統同時提供原文與編輯版，可以在畫面標明來源性質與編輯目的。例如原始轉錄供核對，格式整理版供閱讀，而摘要另有自己的標示。這些名稱能避免同事把改寫內容直接當成受訪者逐字發言。
匯出檔案也應保留同樣區分。只有一份叫做逐字稿的檔案，可能讓後續使用者不知道內容經過哪些修改。附上簡短的編輯說明與原始資料識別，就能讓接手者決定是否需要回聽或引用原文。
當有人要求修正一個詞，先確認它是辨識錯誤還是編輯變化，再修改對應版本。這樣能保留清楚的修正原因，也避免把來源與後處理混在一起。資料版本越清楚，工具越容易進入需要查證的工作。
