技術需求清單 vs 場館技術資料包：各自應包含什麼內容

TL;DR — 演出方的技術需求清單說明「這場演出需要什麼、巡演團隊自備什麼」；場館技術資料包則說明「這個場地有哪些條件、可提供什麼、有哪些限制」。兩者互不取代。前置協調（advance）時，製作團隊會比對兩份文件、排除缺口與替代方案、分配供應責任，並記錄最後確認的場次專屬計畫。請保留有日期的原始文件與清楚的決策紀錄，避免工作團隊把「需求」誤以為「承諾」。

定義這兩份文件

演出方技術需求清單是巡演製作對一場演出的需求說明。內容通常包含舞台配置圖、輸入列表、監聽需求、PA 與控台需求、樂器後線設備、電力、燈光、影像、吊掛、通訊、工作人力、時程假設，以及自帶設備等。

場館技術資料包——也可稱為場館技術規格、場地規格，或技術資訊包——則是描述場館本身以及可提供資源的文件。內容可能涵蓋舞台與空間尺寸、已安裝的音響／燈光／影像系統、吊掛資料、電力、裝卸貨動線、後台區域、在地庫存、限制事項、聯絡窗口與場館作業流程。

技術需求清單回答的是：「這場演出需要什麼？」 場館技術資料包回答的是：「這個場地有什麼、允許什麼、能支援什麼？」 前置協調的工作，就是把這兩個視角整合成一份確認後的計畫。

比較所有權與用途

文件名稱會因單位而異。有些場館把自己的文件稱為「technical rider」，有些製作團隊則把自己的包稱為「tech specs」。在解讀標題前，先確認擁有者與用途。

演出方技術需求清單應包含什麼

技術需求清單應描述真實的演出需求，而不是理想化的製作規模。實用章節可包括：

• 製作聯絡人與決策權責；
• 舞台配置圖，標示表演者、樂器、升高平台、監聽、電力與出入口；
• 編號的輸入列表，列出訊源、麥克風或 DI 盒需求、麥架／立架與備註；
• 監聽目的地、楔形監聽喇叭或 IEM 需求，以及 talkback；
• PA、前場（FOH）與監聽控台、舞台介面與處理需求；
• 藝人自帶設備，以及由場館或供應商提供的設備；
• 樂器後線設備的型號、數量、狀況、配件，以及可接受的替代方案；
• 如適用，燈光、影像、播放、timecode、intercom 或錄音需求；
• 舞台、吊掛、電力、網路、人力、時程與安全要求；
• 必要項目、偏好項目、可協商項目，以及需核准項目。

技術需求清單範本 提供了結構化的起點。請讓 舞台配置圖 與 輸入列表 和書面需求保持一致。

場館技術資料包應包含什麼

一份有用的技術資料包，應讓來訪團隊在不猜測的情況下完成規劃。

場館與進出動線

• 技術與製作聯絡人姓名；
• 地址、廳名、觀眾配置與容量（如適用）；
• 裝卸路線、門與走廊尺寸、電梯限制、碼頭或街道管制；
• 停車、巴士或卡車進出、宵禁、噪音限制與工作時段；
• 舞台進出、樓梯、坡道、後台動線，以及相關無障礙資訊。

舞台、吊掛與電力

• 舞台尺寸、高度、側翼、障礙物、地板承重與可用升高平台；
• 現行吊掛計畫、核准吊點、承重資料、場館規範與必要供應商；
• 電力服務位置、接頭、電壓、相位、容量，以及具資格的管理單位；
• 影響 haze、火焰、紙屑、雷射、天候曝露或其他演出元素的限制。

吊掛與電力數據必須來自最新的場館文件與具資格人員。一般文章或過期的活動檔案不等於核准。

音響、燈光、影像與通訊

• 實際安裝與可搬運庫存的精確清單，包含型號、數量、位置與狀況（如相關）；
• PA 的覆蓋設計、補聲、延遲、低頻喇叭、擴大機、處理與控制邊界；
• 控台、舞台箱、分線、網路、I/O、韌體或軟體限制，以及場館檔案；
• 楔形監聽喇叭、IEM 支援、麥克風、DI 盒、麥架／立架、線材與備品；
• 燈光位置、燈具、控台、控制協定、場館 patch 與電力；
• 投影機、顯示器、切換器、訊號格式、解析度、線路走向與內容交接；
• 製作通聯系統、cueing、show relay、輔助聆聽、錄音與串流設備；
• 包含的場館工作人力、最低 call 人數、專業人員需求，以及與供應商的合作關係。

維護場館原始文件時，請使用 場館技術資料包檢查清單。

逐項比對兩份文件

不要先讀技術需求清單，就把場館包當成一般簡介。應建立一份缺口表。

請用「已確認」、「供應商處理」、「藝人處理」、「場館處理」、「待確認」與「不適用」等狀態標示，而不要只靠沒有圖例的顏色標記。

把可用性和承諾分開

庫存清單只能表示某個物品存在；它不一定代表該物品包含在這場活動中、專屬於這場活動、相容、已維護，或由具資格工作人員操作。同樣地，技術需求清單中的某項要求也不會因為沒人對 PDF 提出異議，就自動變成已確認。

針對每一項關鍵內容，都要確認：

1. 確切設備，或明確核准的替代品；
2. 數量、配件與目前狀況；
3. 供應方與費用承擔方；
4. 運送、架設、操作與撤場責任；
5. 與系統其他部分的相容性；
6. 決策權責人與確認日期；
7. 若該項目不可用時的備援方案。

如果技術需求清單是合約的一部分，相關方應透過主協議與適當的專業法律意見處理其法律效力。單靠檔名或簽名欄，並不能在所有司法管轄區或交易中產生相同效果。

管理版本，不要丟失原始依據

兩份文件都會過期。場館庫存會變，舞台會重設，巡演人員會更動，演出檔案也會演進。請在每份原始文件上標註修訂日期、擁有者與聯絡方式。

在前置協調期間：

• 保留原始技術需求清單與場館技術資料包作為參照；
• 建立一份場次專用的缺口與決策紀錄；
• 將每個決策連結到受影響的舞台配置圖、輸入列表、時程或供應商訂單；
• 若確認變更會影響巡演計畫，就更新目前使用中的技術需求清單；
• 指明哪一份文件或哪個版本取代舊版本；
• 發出一份最終的演出日包，並註明其擁有者；
• 保留歷程，方便團隊檢視為什麼會做出某個替代或配置變更。

不要反覆寄送重新命名的附件，例如 final-v7-new.pdf。PDF 適合用於固定交付；受控的原始文件則更容易檢視修訂與歷史。

以實務順序完成前置協調

1. 交換最新的演出方技術需求清單與最新的場地專用場館技術資料包。
2. 確認聯絡人、活動範圍、觀眾配置、進出動線、時程與決策期限。
3. 比對舞台、音響、監聽、樂器後線設備、燈光、影像、電力、吊掛、通訊與人力。
4. 標記所有不一致、缺漏資訊、假設與需要核准的事項。
5. 先處理必要項目，再評估偏好項目與可接受替代方案。
6. 分配行動、供應方、費用承擔方、截止日與備援路徑。
7. 更新相關依賴文件，使舞台配置圖、輸入列表、時程與訂單一致。
8. 發出有日期的確認摘要，並在裝台前再次確認關鍵變更。

演出前置協調檢查清單 涵蓋更完整的活動流程。若是巡演套件，請將場地專屬確認與可重複使用的巡演母版分開，避免某一間場地的例外變成每一間場地的要求。

避免常見的文件失誤

• 舊庫存：已停產或已重新分配的設備仍被列為可用。
• 權責模糊：雙方都以為對方會提供控台、升高平台、線材或操作人員。
• 未核准替代：在未檢查所需 I/O、控制、配件或工作流程前，就更換型號。
• 圖面不一致：舞台配置圖與輸入列表顯示不同陣容或不同通道數。
• 缺少場地辨識：多廳場館傳來的是錯誤空間的尺寸或庫存資料。
• 沒有狀態用語：需求、選項與確認看起來一模一樣。
• 默默替換版本：新的附件流通了，卻沒有變更摘要或擁有者。
• 危險推論：把舊演出的吊掛或電力容量直接複製成今天的核准資訊。

FAQ

技術需求清單和場館技術資料包有什麼差別？

演出方技術需求清單描述的是演出的需求與自備設備；場館技術資料包描述的是建築、既有系統、在地庫存、進出動線、政策與限制。前置協調會把兩者比對後，記錄一份確認計畫。

誰負責製作場館技術資料包？

通常由場館的技術經理、製作經理或各部門主管維護。涉及安全的吊掛、結構、電力與系統資料，應由具資格的專業人員負責。

場館技術資料包應該包含哪些內容？

應包含聯絡人、進出動線、空間與舞台尺寸、吊掛與電力資訊、音響、燈光、影像、通訊、在地庫存、人力、限制、時程，以及與該空間相關的修訂資訊。

場館技術資料包可以取代演出方技術需求清單嗎？

不行。技術資料包說明的是場館能支援什麼，並不定義藝人的確切演出需求；技術需求清單說明的是演出需要什麼，也不代表場館一定會提供。

如何比對技術需求清單與場館規格？

使用逐項缺口表。針對每個需求，記錄場館證據、狀態、核准替代方案、供應方、費用承擔方、行動、截止日、備援方案，以及完成確認的人。

把兩份文件整合成一份確認後的演出計畫

在 Techrider.live 建立 舞台配置圖與技術需求清單，邀請藝人與場地方主管一起編輯同一份技術需求清單，並保存每一次確認變更。請把場館包作為場地證據，把技術需求清單作為演出證據，把前置協調紀錄作為雙方實際同意交付內容的證據。