概念地圖・技術成熟度九級
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
技術成熟度九級：這項技術，離上場多遠
「我們的技術已經很成熟了」——這句話在提案簡報裡出現的頻率極高，實際意思卻可以從「實驗室裡跑得出數據」到「客戶已經用了三年」都算。技術成熟度等級把這條路切成九格，每一格都綁定一個可查證的事實：在什麼環境下、驗證了什麼、由誰看見。從第一級的基本原理被觀察，到第九級的系統在真實運行中證明有效，中間跨過三道環境門檻——實驗室、相關環境、真實環境。
九個級別，各自要交出什麼證據
這套分級由 NASA 在 1970 年代發展、1990 年代定型為九級，後來被歐盟研究計畫、各國國防與科技部門廣泛採用，台灣的補助計畫與法人技轉評估也常見它的身影。每一級真正的定義，都寫在「在哪裡驗證、驗證到什麼程度」這件事上。
| 級別 | 這一級的意思 | 要拿得出的證據 | 常在哪裡發生 |
|---|---|---|---|
| 1～2 | 原理被觀察，概念成形 | 論文、專利、技術構想書 | 學界與研究單位 |
| 3 | 概念驗證 | 實驗室裡跑得出關鍵數據 | 研究計畫的結案標準 |
| 4 | 實驗室環境的元件驗證 | 元件組起來能運作 | 谷底的起點 |
| 5～6 | 相關環境下的元件與原型 | 模擬真實條件的測試報告 | 最缺錢的一段 |
| 7 | 真實環境的系統原型 | 裝在客戶現場跑過 | 試量產、示範場域 |
| 8～9 | 系統完成、實際運行中證明 | 驗收文件、運轉紀錄 | 量產與商轉 |
宣告級別之前，先過四個自問
這是一把很容易被自己拉高的尺。四個問題可以把水分擠掉大半。
一、你說的「環境」，到底多接近真實。第五級與第七級的差別，全在環境兩個字：相關環境是實驗室裡刻意模擬出的溫濕度、震動與負載；真實環境是客戶那條產線、那台車、那個屋頂。多數的級別灌水都發生在這裡——把恆溫實驗室的資料，說成相關環境的驗證。自問：這次測試的條件，跟客戶現場最惡劣的那一天差多少？
二、你講的是整套系統，還是其中一顆元件。整體級別取決於最弱的那一環——既非平均值，也非你最有把握的那一項。一個感測器到了第七級、但供電模組還在第四級的系統，整體就是第四級。自問：把所有子系統各自標一個級別，最低的那個是誰？
三、除了技術，製造與市場的成熟度在哪一級。技術到第九級，代表它能運作，並不代表做得出量、賣得掉、有人願意換掉現有做法。國際上因此發展出製造成熟度與商業成熟度等平行的尺，用來補這一塊。自問：如果明天要交一千套，我卡在哪一個環節？
四、這個級別是誰認定的。自評永遠偏高，尤其在計畫結案、募資、投標這些有壓力的場合。比較站得住的做法是替每一級預先寫下「通過的條件」，並且由不參與開發的人來檢核。自問：如果由客戶的工程師來評，他會給幾級？
一個實驗室團隊的第四級卡關
台灣有大量從大學實驗室或法人單位長出來的硬體團隊，卡點幾乎一致。以下是一個示意情境。
- 起點：三年計畫做出感測模組，實驗室數據漂亮。第四級
- 對外的說法：簡報寫「技術已成熟，可商品化」。跳過五到八級
- 投資人的問題：有沒有裝在真實現場跑過一整季。沒有
- 補助的邊界：既有計畫只補到概念與雛型階段。谷底沒人出錢
- 改變做法：找一家願意提供場地的中小廠，做一個免費的示範點。換到真實環境
- 三個月後：粉塵與電壓不穩讓模組當機，改設計後升到第六級。證據換來了
這個團隊最大的轉折，是把「找錢」改成「找場域」。他們原本的邏輯是先募到資金、再把技術做到能上場；但投資人要的正是上場過的證據，於是兩邊互相等待。改成免費借一個真實現場之後，他們拿到的不只是級別的提升——那三個月暴露出來的粉塵與電壓問題，在實驗室裡永遠不會出現，卻是這個產品後來最關鍵的設計修改。值得記下的還有一個副作用：那家願意借場地的工廠，後來成了第一個付費客戶，因為在示範期間，他們自己看見了問題被解決的樣子。以上為說明結構用的示意情境，僅供理解框架之用。
這把尺，有三個地方會騙你
它把模糊的「成熟」變成可討論的數字，代價是這個數字也很容易被操作。
- 它只量技術，完全不量需求。九個級別從頭到尾問的都是「這東西做不做得出來、跑不跑得動」，沒有任何一級要求你證明有人願意買。於是會出現一種很典型的失敗：技術一路推到第八、第九級，客戶數字停在零。這也是為什麼近年許多評估架構會要求 TRL 與市場、製造的成熟度並列呈現——單獨看技術成熟度，等於只看了一半的儀表板。
- 真實開發不是一路往上的階梯。圖畫成樓梯，是為了溝通方便。實際的開發會回頭：第六級的原型在真實環境炸掉，得退回第四級改設計；換一個應用場域，原本第七級的東西可能瞬間變回第五級，因為「真實環境」的定義變了。把它當成路線圖，會低估反覆的次數與時間；當成當下狀態的快照，才用得對。
- 定義有伸縮空間，而所有壓力都指向往上報。相關環境到底多相關、驗證要做幾次、失敗算不算通過——這些邊界在實務上都有解釋餘地。而計畫結案、募資、評鑑、投標，每一種場合的誘因都是把數字報高一點。結果是同一個「第六級」，在不同團隊嘴裡可能差兩級以上。看別人的級別時，別看數字，看他描述的那個測試環境。
技術爬到第八級，需求還在第一級
這張階梯圖最誠實的一件事，是它從來沒有假裝自己在回答市場的問題。它處理的是「做得出來嗎」，而且處理得非常好——每一級都綁著一份可查證的證據，這正是多數創業說法最缺的東西。問題出在使用它的人身上：很多團隊把技術的級別當成整個專案的進度，於是九分之八的路走完了，要付錢的那個人從頭到尾沒被問過。
真正該做的，是替需求也畫一把一樣嚴格的梯子。第一級是「我覺得有人會需要」，第三級是「五個人願意花半小時談這件事」，第五級是「有人願意先付一筆訂金」，第七級是「有人已經付過三次錢」，第九級是「他們會主動介紹別人來」。兩把梯子並排放，你會立刻看見自己真正落後的是哪一邊。技術成熟度與需求成熟度，落差越大，燒掉的錢越多。P.A.I.N. 之尺量的正是右邊那把梯子。今晚可以做的一件小事：在一張紙上畫兩條垂直的線，左邊標你的技術現在第幾級，右邊標「有多少人真的付過錢」。兩個高度差多少，就是你接下來三個月該補的那一段。
關於技術成熟度等級，常被問到的幾件事
技術成熟度等級是誰提出的？
起源於 NASA：1970 年代為了評估太空任務中各項技術的風險而發展，最初是七級，1990 年代擴充並定型為九級。之後被美國國防部、歐盟研究與創新架構計畫廣泛採用，也發展出對應的國際標準。台灣的科研補助、法人技轉與產學合作評估也常引用這套分級，因此在寫計畫書時會反覆遇到。
九個級別大致怎麼分？
前三級屬於研究：原理被觀察、概念成形、在實驗室完成概念驗證。第四到第六級屬於開發：元件在實驗室組起來運作、在模擬真實條件的相關環境中通過測試、做出系統原型。第七到第九級屬於落地：原型裝進真實運行環境、系統完成並通過驗收、在實際運行中證明有效。記憶的關鍵在三段環境的分界，編號本身反倒次要。
為什麼說死亡之谷在中間那幾級？
因為出錢的人分布在兩端。前三級有研究補助與學術資源，第七級之後有創投、銀行與客戶預付款，因為風險已經看得見底。中間那段既不夠新到能拿研究經費，又不夠確定到能說服投資人，而它偏偏是最花錢的一段——要做原型、要跑測試、要進場域。多數技術新創倒下的地方，就是這段沒有資金來源的路。
TRL 跟製造成熟度、商業成熟度有什麼關係？
它們是互補的三把尺。技術成熟度回答「跑不跑得動」，製造成熟度回答「量產穩不穩、良率與成本撐不撐得住」，商業成熟度回答「有沒有人買、通路與商業模式通不通」。實務上最常見的災難是三者嚴重不同步：技術第八級、製造第三級、商業第一級。同時列出三個數字，比把技術那一格推高有用得多。
寫補助計畫時，級別該怎麼填？
誠實填現況，把力氣花在「這個計畫要從第幾級推到第幾級」的說明上。審查者看得多，往上灌水的說法通常一問測試環境就破。比較有說服力的寫法是三段式：現在在第幾級（附上已完成的驗證與資料）、計畫結束時要到第幾級、以及那一級的通過條件怎麼定義、由誰認定。把驗收條件寫清楚，比宣稱自己已經很成熟更容易拿到資源。
技術的期待與實際落差怎麼走，技術炒作週期畫的是另一條線；把每一階段設成一道關卡逐步放行，階段關卡流程是配套的管理方法。至於技術很強卻找不到題目時該怎麼進場，這篇拆書給了一個很不一樣的順序。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。