找到支點，難題就撬得動
創新方法與知識工程
「給我一個支點」，難題就撬得動；技術題的支點叫矛盾。TRIZ 從二十萬件專利歸納出：技術矛盾類型有限，解法模式可重複使用，AI 正把門檻降到一般工程團隊搆得著。
靈感之前，先有問題：發明不靠等
靈感從不憑空掉下來，它落在準備好的問題上。發明史上每一聲「想通了」，前面都排著好幾天翻來覆去的提問。真正可複製的，是提問的方法。
蘇聯工程師 Genrich Altshuller 把這件事做成了學問。他從 1946 年起在裏海海軍專利部門工作，開始系統性地分析專利。他研究了 20 萬件專利後歸納出結論：技術矛盾大約只有 1,500 種，而化解這些矛盾的手法可以整理成 40 個發明原則（Altshuller Institute 傳記，Altshuller Institute）。
第一篇學術論文《On the Psychology of Inventive Creation》在 1956 年發表於《Voprosy Psikhologii》期刊（Wikipedia: TRIZ，TRIZ）。體系隨後成形：40 個發明原則、39 個工程參數，以及把兩者接起來的矛盾矩陣。工程師把自己的難題翻譯成參數衝突，查矩陣，就能拿到前人在類似矛盾上用過的原則清單。
Altshuller 對這套方法的價值有一句流傳很廣的說法：「You can wait a hundred years for enlightenment, or you can solve the problem in 15 minutes with these principles.」（你可以等一百年等靈感，也可以用這些原則十五分鐘解掉問題。Altshuller Institute 傳記，Altshuller Institute）話說得滿。方向倒值得舉雙手贊成：把「想創意」變成「查前例、套模式、再驗證」。
支點在哪裡：先認矛盾，再談點子
「給我一個支點和一根夠長的槓桿，就能撬動地球。」這句流傳兩千年的老話，拿來當工程守則正合適：力氣不夠時別硬推，找支點。TRIZ 的支點，叫矛盾。
它把難題分成兩類。工程矛盾是「改善 A 就惡化 B」：機殼做厚，強度上去了，重量也上去了。這類矛盾用 39 個工程參數描述，查矛盾矩陣拿原則建議。物理矛盾更尖銳，同一個參數被要求同時往兩個方向走：天線要長，收訊才好；又要短，才好攜帶。這類靠分離原理處理：在時間上分離、空間上分離、依條件分離，或在系統層級間分離。摺疊天線就是空間分離的答案。
這個框架最實際的好處，是改變了團隊開會的語言。腦力激盪常見的下場是人人丟點子、彼此評點，最後選一個聲量最大的。矛盾分析先逼大家講清楚：我們到底在跟哪兩個參數的衝突打架？問題定義對了，解法空間從無限縮到幾十個原則。幾何證明的老規矩相通：先把命題寫成可證的形式，證明就成了一半。
40 個原則本身給的是提示方向。「分割」「抽取」「非對稱」「借力」這些詞，要落到具體領域才有意義，中間的翻譯工作以前靠 TRIZ 專家，現在有一部分可以交給機器，後面會講。
綁進日常才見效：三星怎麼用 TRIZ
方法臨陣抱不了佛腳，得先綁進日常的開發流程，這在 TRIZ 有公開記錄的產業成績裡看得最清楚。
三星在 2000 年代初把俄籍 TRIZ 工程師聘進首爾實驗室。依 Altshuller Institute 刊出的記述：「In 2003 TRIZ led to 50 new patents for Samsung and in 2004 one project alone, a DVD pick-up innovation, saved Samsung over $100 million.」（2003 年 TRIZ 為三星帶來 50 項新專利；2004 年單一個 DVD 讀取頭專案就省下超過一億美元。Altshuller Institute）
同一篇記述也提到規模：三星內部撰寫韓文 TRIZ 教材的專家，光 2004 年就在集團內訓練了超過 1,000 名工程師（來源同上）。Forbes 在 2013 年回顧三星創新體系時，也把 TRIZ 列為其中一個環節（來源）。
讀這個案例，該盯的是投入方式。三星把專家聘來長駐，把訓練與開發流程綁在一起；辦幾場工作坊發發證書，換不來這種成績。成效跟投入深度綁在一起，這對想導入的公司是提醒：方法有效的前提，是它真的被用在日常專案上。
為什麼學的人多、用起來的人少
教材不缺，缺的是把它用起來的環境。頭一個門檻是抽象度：40 個原則和 39 個參數都是高度概括的語言，把自己的問題翻譯成標準參數需要練習，翻錯了，矩陣給的建議就不對題。學幾何的人裡，會背公設的多，會挑輔助線的少。同一回事。
第二個門檻是陪跑。多數成功案例背後有專家帶著走前幾輪；中小團隊請不起長駐顧問，上完課回去自己查表，卡在翻譯這一步就放掉了。
再來是知識分散。原則、參數、矩陣之外，TRIZ 還有科學效應庫這類跨領域資源，概念是「你的問題在別的領域可能早被解過」。這些知識散在教材、論文、案例集裡，沒有一個可以用自然語言查詢的入口。工程師遇到問題時想不起來要查哪本書的哪一章，方法就停在書架上。知識放著沒人查得到，跟失傳沒有兩樣。
失敗模式因此很一致：導入案子從全員教育訓練開始，課上完、證書發完，半年後沒有任何專案真的跑過一輪矛盾分析。工具的操作成本高過工程師的耐心。這件事在 AI 出現以前，沒有好解。
AI 把查表的功夫接走了
大型語言模型改變的是「翻譯」這一步。2024 年發表的 AutoTRIZ 研究（arXiv:2403.13002）讓 LLM 依 TRIZ 的推理步驟自動運作：使用者用白話描述問題，系統自動識別矛盾、對映參數、推薦原則、產出解法報告，並以教科書案例與電池熱管理系統的實際設計做了驗證。論文對這個取徑的定位是：「By leveraging LLMs' vast pre-trained knowledge and advanced reasoning capabilities, AutoTRIZ offers a novel, generative, and interpretable approach to engineering innovation.」（藉助 LLM 的預訓練知識與推理能力，AutoTRIZ 為工程創新提供一種新的、生成式且可解釋的做法。arXiv）
可解釋，這三個字是重點。直接叫聊天機器人「幫我想十個點子」，拿到的是無法追溯的輸出；讓模型沿著 TRIZ 步驟走，每個建議都掛在某條原則、某個矛盾上，工程師可以逐步檢查推理對不對。好的證明每一步都攤開給人檢驗，就是要讓人挑得了錯。方法論在這裡的角色，是給 AI 上軌道，讓生成過程留下可以審的軌跡。
工程實作上，標準做法是 RAG：把原則、參數、矛盾矩陣、分離原理、效應庫、案例集全部向量化建庫，模型回答前先檢索，再依檢索到的條目推理。我們自己的系統就是這樣建的：40 發明原則、39 工程參數、263 矛盾矩陣建成完整向量庫，涵蓋 4 分離原理、Oxford Effects 與 AutoTRIZ 案例，用 crawl、chunk、embed 三階段管線維護，多角色 AI 從描述問題一路走到生成解法。過去要專家陪跑的翻譯與查表，現在是幾分鐘的自動流程；專家的時間留給驗證解法。
導入建議：從一個卡住的真問題開始
別從全員上課開始。挑一個團隊卡了幾個月的具體工程問題，用矛盾的語言重寫它：改善什麼會惡化什麼？有沒有同一參數被要求往兩邊走？然後跑一輪原則推薦，人查表或用 AI 系統都行，產出三到五個候選方向，評估哪個值得做實驗。
成本是幾天。幾天而已。跑完第一輪你會知道兩件事：這個方法對你們的問題型態有沒有感覺、團隊裡誰對這套語言上手最快。有了一個講得出口的內部案例，再決定要不要擴大，順序別反過來。
驗收標準也講明白：別數上了幾小時課，數多少個實際專案跑過矛盾分析、產出了幾個進入實驗的解法方向。候選方向講得再動聽，有沒有用，最後是實驗量出來的。