Eric Schmidt 的演說 第二篇, 來聊聊我看完全文後, 覺得很有感的第二段:
他提到過去第一次將電力引進工廠時 (原本工廠用的是蒸汽機)，明明是劃時代的改變，但是卻花了 30 年才真正帶來飛躍性的進步這段.. 這完全就是現在 AI 的局面啊..
先交代一下歷史吧:
工廠剛開始電氣化的時候，由於之前的工廠都是由蒸汽機驅動的。蒸汽機需要龐大的鍋爐燒水產生蒸氣來驅動，產生蒸氣需要大量煤炭，鍋爐跟水等等設備，規模龐大，需要集中處理 (就像當年 mainframe)，而產生的動力也不能傳太遠 (要靠曲軸或皮帶傳遞動力，會有物理限制與損耗)，因此，初代的工廠都用類似的設計，設備都圍繞蒸汽機來配置。如果只是把蒸汽機換成電動馬達… ，但是流程跟設計沒變，帶來的效率改善也有限..
過了 30 年，工廠的設計被翻了一輪，電力傳輸沒有距離限制，電動馬達也可以做得可大可小，可以直接做成適合的規模，擺在適合的位置。整體搭配可以以 “生產最有效率的流程” 來進行，因此效率開始翻倍。整座工廠可以由數百個馬達同時驅動多個設備，而不是集中的鍋爐提供蒸氣… 用雲端計算的用語來說，工廠開始從 scale up 進步到可以 Scale out …
這段歷史的結論是: 電力是很有價值的技術，但是直到流程跟設計也跟著改變，組織也轉變成對應的生產組織，整個體系才開始獲得巨大的回報。
–
歷史故事到此為止，回過頭來，看看現在 AI 的應用跟發展。
我之前文章跟演講 ( DevOpsDays Taipei 那場 ) 也提過，目前談的最多的是 “各種 AI 工具，如何幫助我更容易完成現在的任務” ..
這某種程度，不就是把蒸汽機換成馬達嗎?
如果你用 AI 來做你現在在做的事情，這一定有改善，因為工具要解決的 (對我而言是整理資料，還有寫些有點無聊，不得不寫的 code…) 是我目前完成任務的瓶頸，改善工具當然能提升效率。但是問題有兩個:
-
整體效能決定於最大瓶頸 AI 越來越聰明，解決了你現在的瓶頸，就會越快逼出下一個瓶頸。等到瓶頸回到你自己的想像力時，AI 對你的幫助就到此為止了… (這是為什麼我會拿魔法就是想像力當例子)
-
如果你拿著 AI 做跟過去一樣的事情，你速度變快了，但是產出是一樣的，沒有改變品質，或是任務的本質，那就跟工廠設計不變，只是把蒸汽機換掉一樣。你做得更快，但是並沒有產生質變，放大來看，其實沒有產生 “變革”… 對軟體開發而言，改變流程是什麼?
我會對這段有感，就是他跟我那場演講提到 “降維打擊” 講的是同一件事。多了一個維度，跟同一個維度但是刻度放大 10 倍是完全不同的。有了強大的 AI，你還要做以前一樣的事情嗎? 如果不是，那會是什麼?
因此，我嘗試了幾件事:
-
大家在瘋 AI 寫 code 時, 我能不能多跳一步, 讓 AI 自己寫 code (推論) + 自己執行? AI 的推理能力有限 (目前)，因此我需要盡量簡化他的推論，盡量放大這種當下才知道需求，當下就立刻推論並執行的優點。我領悟出來，關鍵就是模組化，抽象化而已。做好這些事，你要執行的步驟就變簡單了。只是以前是讓你寫的 code 變簡單，現在是讓 AI 處理 function calling 的門檻降低到可用的地步。我想通了這過程，所以有了 “安德魯小舖 GPTs” 的 POC.. 也有了 “從 API First 到 AI First” 的體悟。
-
用 UI 設計來改善 UX，用統計來判定滿意度，用機器學習來處理個人化，這些都需要大量且有經驗的前置設計才辦的到，我能否善用 LLM 直接跳過這些作業? LLM 從全世界的資料被訓練出來，他應該都有足夠的能力省掉事前設計才對 (我是天真的這麼想的)。
於是，我開始嘗試直接用對話當作介面，我開始嘗試 Copilot 的架構，我開始嘗試靠 LLM + 個人註記 + 操作歷程 都放入 context window, 讓 AI 幫我評斷過程中的滿意度，也讓 AI 用 function calling 來更新個人註記..，我也試出了靠 AI 也能達到良好 UX 的方式，我多了 AI 這個新的維度的視野，開始可以用不同層次來看問題..
這些，都會改變整個開發流程，也都會改變需要的對應角色。我想的不一定是正確的答案，但是我的卻是在嘗試不同的設計，看到蒸汽機這案例，我就知道我在嘗試 “正確” 的事情了 (但是我的結果還不一定是正確的)。
這是另一個我看完有感的觀點，也是最大的收穫: 當你有了驚人的新技術 (AI)，那麼就會有很多機會重新思考現在的做法跟流程。
其實這段演講，還有很多類似有趣且實際的觀點，留給大家去發掘 :D
