(圖說：AWS re:Invent 2025 Special Closing Keynote with Dr. Werner Vogels。圖片來源：AWS。)
AWS 副總裁兼技術長 Dr. Werner Vogels 自 2012 年以來連續 14 年發表 re:Invent 主題演講，這是他最後一場。（唉，我人在現場台下邊聽邊難過。）Werner 不同於傳統的服務發布，而是提出了「文藝復興開發者（The Renaissance Developer）」框架，包含五大特質，定義開發者在 AI 時代應該如何演化。特別嘉賓 Clare Liguori 展示了 Kiro IDE 的規格驅動開發（spec-driven development），Werner 也分享了他在非洲和拉丁美洲旅行的故事，說明開發者如何解決真實世界的問題。
✳️ tl;dr 重點摘要
一個主題「文藝復興開發者（The Renaissance Developer）」貫穿全場，包含五大特質：
- 保持好奇（Be Curious）：實驗與願意失敗的精神、Yerkes-Dodson 定律（壓力與表現的曲線）、社會學習與接觸現實、全球旅行故事（AJE、Ocean Cleanup、Rwanda Health Intelligence、KOKO Networks）、AWS Heroes（265 位遍布 58 個國家） (揮手)。
- 以系統思維思考（Think in Systems）：Donella Meadows 的系統思維、Yellowstone 的狼與營養級聯效應（trophic cascades）、增強迴路與平衡迴路的回饋迴路、「Leverage Points: Places to Intervene in the System」論文。
- 溝通（Communicate）：規格驅動開發降低模糊性、歷史案例（Dijkstra 的結構化程式設計、Apollo 導航系統）、Clare Liguori 與 Kiro IDE（從 vibe coding 到規格驅動開發、功能驅動規格、通知系統以一半時間交付）、快速原型製作（Engelbart 的滑鼠類比）。
- 成為擁有者（Be an Owner）：驗證債（verification debt，AI 生成程式碼的速度超過你理解的速度）、幻覺（hallucination）挑戰、機制 vs 善意（Jeff Bezos / Amazon Andon Cord）、S3 耐久性審查、AI 時代的程式碼審查比以往更重要。
- 成為博學者（Become a Polymath）：I 型開發者 vs T 型開發者、Jim Gray（Turing 獎、交易的發明者、Sloan Digital Sky Survey）、深度領域專業結合廣泛知識。
內容大綱
✳️ Structure 演講結構
Dr. Werner Vogels 這場 75 分鐘的特別閉幕主題演講圍繞著一個主題和五大特質來組織。不同於傳統充滿服務發布的 AWS 主題演講，這場演講是一份給在 AI 時代中導航的開發者的哲學與實踐指南。
一個主題「文藝復興開發者（The Renaissance Developer）」貫穿全場，包含五大特質：
- 保持好奇（Be Curious）
- 以系統思維思考（Think in Systems）
- 溝通（Communicate）
- 成為擁有者（Be an Owner）
- 成為博學者（Become a Polymath）
主題演講以一段預錄的戲劇影片開場，展示開發者經歷數十年的演化（從打孔卡片到 COBOL 到雲端到 AI），接著 Werner 宣布這是他最後一場 re:Invent 主題演講。他將歷史上的文藝復興與當前的科技時刻做了類比，認為正如好奇心、工具和印刷機改變了社會，AI 正在改變今天的開發。
邏輯脈絡從個人心態到更廣泛的影響。「保持好奇」從個人成長開始；「以系統思維思考」擴展到理解複雜互動；「溝通」橋接人與機器之間的鴻溝；「成為擁有者」在 AI 時代建立責任；「成為博學者」將所有特質整合成完整的開發者身份。這個遞進建構了一個框架，每個特質都強化其他特質，共同塑造文藝復興開發者。
✳️ Highlights 精華摘要
文藝復興開發者
- 文藝復興開發者框架
- Werner 將歷史上的文藝復興與當今的科技時刻做類比
- 多個黃金時代同時匯聚：太空旅行、人工智慧、機器人技術
- 一個領域的進步加速其他領域的進步，就像文藝復興一樣
- 五大特質定義文藝復興開發者：保持好奇、以系統思維思考、溝通、成為擁有者、成為博學者
特質 1：保持好奇
- 實驗與願意失敗
- Da Vinci 造了一架從未飛起來的飛機，但我們現在在飛
- 如果你已經知道結果，那就不算是實驗
- 軟體也是一樣：失敗的建構和破碎的假設教會你系統如何運作
- Yerkes-Dodson 定律
- 壓力與表現之間的鐘形曲線關係
- 壓力太小：心不在焉；壓力太大：不堪負荷
- 甜蜜點在上升斜坡上，好奇心與挑戰相遇的地方
- 你坐在舒適的地方是到不了那個點的
- 社會學習與接觸現實
- 學習不僅僅是認知的，它是社交的
- 走出你平常的環境：使用者社群、研討會、和朋友喝杯咖啡
- 保持敏銳的最好方式之一就是和其他也在建構東西的人在一起
- 旅行故事
- AJE：飲料公司支持亞馬遜河沿岸社區，給年輕人經濟前景，讓他們不必離開村莊
- The Ocean Cleanup：海洋中 80% 的塑膠來自全世界 300 萬條河流中僅千分之一的河流；AI 攝影機和 GPS 追蹤的假塑膠建立預測塑膠流向的計算模型
- Rwanda Health Intelligence Center：來自四個層級醫療機構的近即時資料，利用資料在距離醫療提供者超過 30 分鐘步行路程的地區戰略性設置新的產婦健康設施
- KOKO Networks（奈洛比）：乙醇 ATM 機器，人們可以買五分錢的瓦斯來烹飪食物，取代較貧困社區的碳燃燒
- AWS Heroes 與 Now Go Build
- 265 位 AWS Heroes 遍布 58 個國家
- Now Go Build 獎項頒給 Raphael Quisumbing，自 2013 年起共同帶領菲律賓 AWS 使用者社群
- 體現文藝復興開發者精神：建構社群、指導他人、寫程式
特質 2：以系統思維思考
- Donella Meadows 與系統思維
- 在 70 年代，生態學家 Donella Meadows 開始研究複雜系統如何運作
- 「一個系統是一組事物，以一種方式相互連接，使它們隨著時間產生自己的行為模式」
- 系統有自己的生命；我們的軟體系統也不例外
- Yellowstone 的狼與營養級聯效應
- 20 世紀初，狼從 Yellowstone 國家公園被移除
- 預期結果：較少的捕食者意味著更多的麋鹿、更多的生命
- 實際結果：山谷被過度放牧，樹木消失，河流開始侵蝕
- 狼被重新引入後，植被回來了，海狸回來了，河流改變了路線
- 狼沒有移動河流；他們改變了整個系統的行為
- 回饋迴路
- 每個動態系統都由回饋迴路所塑造
- 增強迴路（reinforcing loops，正向迴路）放大改變
- 平衡迴路（balancing loops，負向迴路）抵消改變並將系統推回平衡
- 每個服務、API 和佇列都是更大系統的一部分；你不能孤立地改變一個部分
- 槓桿點
- Donella Meadows 的論文「Leverage Points: Places to Intervene in the System」
- 一旦你看到模式，你就開始能看到微小且精準的改變可能在哪裡轉移整個系統的行為
- 要建構有韌性的系統，你需要理解更大的圖景
特質 3：溝通
- 規格降低模糊性
- 自然語言是模糊的；程式語言是精確的
- 在 AI 時代，我們越來越多地用自然語言與機器溝通
- 需要降低模糊性的機制，讓機器能建立邏輯
- 歷史案例
- Dijkstra 的結構化程式設計：形式化規格在實作之前就證明了程式的正確性
- Apollo 導航系統：精心的規格引導 145,000 行程式碼將人類送上月球
- Clare Liguori 與 Kiro IDE
- 從 vibe coding 到規格驅動開發（spec-driven development）
- 問題：越來越長且詳細的提示來描述軟體應該做什麼，本質上是在建立規格
- 功能驅動規格（feature-driven specs）分為三份文件：需求、設計和任務
- 通知系統案例：規格流程幫助意識到專案比預期更大，在規格上迭代，以大約 vibe coding 一半的時間交付
- Kiro IDE 是用 Kiro IDE 自己建構的
- 快速原型製作
- Engelbart 的滑鼠（1964）：一個木殼加上輪子和一個按鈕，比任何畫作或描述都更好地傳達概念
- AI 從根本上實現了軟體的快速原型製作
- 過去需要數月手動寫程式的東西，現在可以在幾分鐘內產出真正可運作的原型
特質 4：成為擁有者
- 驗證債（verification debt）
- AI 可以比你理解程式碼的速度更快地生成程式碼
- 程式碼瞬間到達，但理解不會
- 這個差距允許軟體在任何人真正驗證它做了什麼之前就朝生產環境前進
- 幻覺（hallucination）
- 模型產生看起來有信心但完全不適合架構的設計
- API 會改變，LLMs 會發明不存在的屬性
- 有時提出過度工程化或忽略系統限制的解決方案
- 機制 vs 善意
- Jeff Bezos 的故事：客服人員知道 70% 的桌子因包裝不當被退回
- 每個人都有善意，但沒有機制，什麼都不會改變
- Amazon 的 Andon Cord：使產品不可銷售的按鈕，觸發負責團隊的警報
- 靈感來自 Toyota 的 Andon Cord：任何汽車都不應帶著已知缺陷離開生產線
- S3 耐久性審查
- 當工程師提出可能影響耐久性的改動時，他們暫停並建模風險
- 寫下改動，列出每個可想像的威脅，規劃防護措施
- 將耐久性從程式碼的屬性變成組織的習慣
- AI 時代的程式碼審查
- 程式碼審查是意圖與實作相遇的機制
- 在 AI 驅動的世界中，它們比以往更重要
- 審查成為恢復平衡、將人類判斷帶回迴路的控制點
- 資深工程師帶來模式識別；資淺工程師帶來新鮮的視角
- 這門手藝仍然是人對人學習的
- 「工作是你的，不是工具的」
- Vibe coding 沒問題，但前提是你密切關注正在被建構的東西
- 如果 AI 建立了違反法規要求的程式碼，你不能怪 AI
- 責任仍然在開發者身上
特質 5：成為博學者
- I 型 vs T 型開發者
- I 型開發者（I-shaped developer）：在一個領域非常深入且高度專精
- T 型開發者（T-shaped developer）：在一個領域很深，但對多個學科有廣泛的理解
- 偉大的開發者結合深度與廣度
- Jim Gray
- Turing 獎得主，交易（transactions）的發明者
- 參與 Sloan Digital Sky Survey，最早的大規模資料集之一
- 能透過聽碟片的嘎嘎聲診斷資料庫布局問題（太多隨機存取）
- 他的好奇心遠超資料庫：理解人、商業和廣泛的技術
- 廣度成就更好的深度
- 一位理解效能和成本感知架構的資料庫開發者能做出更好的架構選擇
- 知識的廣度給你視角來改進你建構的東西，因為你理解權衡
- 兩者都建構：在你的領域發展深度，培養連接多個學科和想法的廣度
✳️ Watch the Video 觀看影片
內容來自 AWS re:Invent 2025。完整場次：AWS re:Invent 2025 - Keynote with Dr. Werner Vogels。
✳️ Knowledge Graph 知識圖譜
(更多關於知識圖譜…)
Overview 總覽
Renaissance Developer Lifecycle 文藝復興開發者生命週期
✳️ Transcripts 逐字稿
Opening Drama & Farewell 開場戲劇與告別
- （沉思的音樂）（電腦嗶嗶聲）（電話鈴響）（報紙沙沙聲）- 嗯。
- 開發者的終結。
- 我以前聽過這個說法。
- （輕柔空靈的音樂）（腳步聲）（輕柔懸疑的音樂）（門咔嗒聲和吱吱聲）（輕柔懸疑的音樂）（電流噼啪聲）（車門嘶嘶聲和咔嗒聲）（太陽眼鏡咔嗒聲）（監視器嗶嗶聲）（棕櫚樹沙沙聲）（按鈕嗶嗶聲）（引擎嗡嗡聲）（汽車引擎轟鳴聲）（電流噼啪聲）（Werner 大喊）（懸疑音樂）（汽車引擎嗡嗡聲）（沉思的音樂）（辦公室員工聊天聲）（卡片沙沙聲）（按鈕咔嗒聲）（卡片碰撞聲）（Lorraine 嘆氣）（椅子碰撞聲）
- 嗨，Lorraine。
- 妳在做什麼？
- 噢，你知道的，整理昨天掉落的程式卡片。
- 搞清楚為什麼機器一直在第 4042 張卡片停下來。
- 在記錄 bogo 編譯器裡一個很奇怪的 bug，還有跟你聊天。
- 總部有什麼新消息嗎？
- 我一直在讀關於這個叫 COBOL 的東西。
- 對，那是新的高階語言。
- 太厲害了。
- 現在任何人都可以寫程式了。
- （報紙沙沙聲）- 我不確定是不是任何人都行。
- 寫軟體是很複雜的。
- 軟什麼？
- 軟體。
- 在哪裡？
- （懸疑音樂）（按鈕嗶嗶聲）（機器嗡嗡聲）（Werner 大喊）（懸疑音樂）（輕快音樂）嘿，Marty，你在讀什麼？
開場戲劇：開發者的演化
- 就在學一些 VP。
- 視覺化程式設計（Visual Programming）啊？
- （嗤笑聲）寫程式已經是歷史了，Marty。
- 拖放就是未來。
- 拖放仍然是程式碼。
- 它仍然有 bug，仍然需要工程師。
- （監視器嗡嗡聲）（輕柔鈴聲音樂）- 所有東西隨時都會故障。
- （鈴聲叮咚）（懸疑音樂）（電流噼啪聲）（Marty 嘆氣）- 這是真的嗎？
- 雲端是否意味著工程師會減少？
- [Werner] 工程師減少。
- （輕笑）是時候來個空投了。
- （書本呼嘯聲）（書本碰撞聲）- 什麼？
- 幾分鐘內就有伺服器。
- 按需擴展。
- 用多少付多少。
開場戲劇：過渡到主題演講
- 哇。
- （輕聲笑）你每天都能學到新東西。
- （電流噼啪聲和嗡嗡聲）（激動人心的音樂）- 你建構它。
- 你營運它。
- 媽。
- 嗨，親愛的，別忘了打電話給媽。
- 嗨，Marty，這個蟲洞不錯吧？
- 介意我加入嗎？
- 喂，你可以跳過這個蟲洞。
- 這是我們所知的開發的終結嗎？
Werner 的告別宣告
- 還是只是另一個新的開始？
- （凱旋音樂）（汽車引擎轟鳴聲）（監視器嗶嗶聲）- [播報員] 請歡迎 Amazon.com 副總裁兼技術長 Dr. Werner Vogels。
- （輕快音樂）（觀眾鼓掌）（觀眾歡呼）- [觀眾] Werner、Werner、Werner、Werner、Werner。
- Werner、Werner、Werner、Werner、Werner。
- （Werner 輕笑）- 謝謝，好的。
- [觀眾] Werner、Werner。
- 首先，我在你們身上尋找並發現了對我們來說每天都是新的東西。不，是每天都有新事物，一顆對不同觀點開放的心，其他一切都不重要。
- 早安。
- 噢不，不是早安。
- 大家好。
- 所以，影片向你們展示了每一代開發者都面臨新的變革浪潮，對吧？
- 工具在演化，架構在演化，期望在演化，我們也是。
- 但在我們談論這些之前，（Werner 清喉嚨）讓我們先談談房間裡的大象吧。
- 對吧？
- 我從 2012 年開始就在做這場主題演講，而且我每一場都做了。
- 順帶一提，那可是很多件 T 恤。
- 對。
- 但今天，這個連續記錄要結束了。
- 這是我最後一場 re:Invent 主題演講。
- （觀眾驚呼）我還有事情要做。
- 我不會離開 Amazon 或任何類似的事。
- 但我認為在 14 屆 re:Invent 之後，你們值得年輕、新鮮、新的聲音。
- Amazon 有太多優秀的工程師有精彩的故事要講，要教導你們，要幫助你們，要教育你們。
- 我認為是時候讓 AWS 那些更年輕、不同的聲音站在你們面前了。
- 順便說一下，沒有人強迫我這樣做。
- 我不會離開 Amazon 或任何類似的事。
- 這是我的決定，為了確保你們能聽到不同的聲音，而不僅僅是我的。
- 現在，讓我們來談談房間裡的其他大象。
- 我走訪了世界各地的 AWS 客戶，有一個問題在每個國家、每個城市都不斷被提起。
Evolution of Development and The Renaissance Analogy 開發的演化與文藝復興的類比
- AI 會取代我的工作嗎？
- 也許。
- （觀眾笑聲）或者說，它會轉變。
- 有些任務會被自動化，有些技能會變得過時。
- 細微差異會浮現。
- 所以，也許我們應該重新措辭和重新框架這個問題。
- AI 會讓我變得過時嗎？
- 絕對不會。
- 如果你進化的話。
- 如果我看看過去幾年在 Amazon，我們一直在使用所有這些新工具，我們已經看到你如何能隨著時間演化，用手中新的工具組仍然成為一位出色的工程師。
- 因為我們作為開發者在演化。
- 我們的工具也必須如此。
- 所以，變化是恆常的。
- 這一直都是如此，沒有什麼新鮮的。
- 讓我們回顧一下過去。
- 隨便說說，當我上學時，我被教導了 68000 組合語言、COBOL 和 Pascal。
- 這些語言都不再被使用了。
- 在 60 年代，我們有了編譯器，你不再需要關心那些編譯器產出什麼樣的組合語言。
- 然而，透過學習組合語言，我知道了、我學會了 Pascal 中的迴圈實際上如何轉換成機器碼。
- 所以那對我很重要。
- 隨著時間推移，編譯器成為大多數開發者所需的最高抽象層次。
- 在 70 年代，結構化程式設計突然變得流行。
- 我們朝著這個方向前進，有了編譯器，Bell Labs 和 Berkeley 支持了這個轉變。
- 他們給了開發者更清晰的控制流程，幫助他們擺脫非結構化程式碼的混亂。
- 然後，幾年後在 Bjarne Stroustrup 的背後，他開始探索如何將現實世界的概念直接模型化為程式碼的物件和類別。
- 那就成了 C++，並幫助塑造了物件導向程式設計。
- 在 90 年代末期，Amazon 仍然是以單體式架構運行。
- 在 98 年，這是一個著名的時刻，成長加速到了一個程度，團隊開始從這個單體中拆分出服務。
- 每個服務擁有自己的伺服器、自己的介面，他們完全改變了開發者的工作方式。
- 他們行動更快，他們變得獨立於其他團隊，他們端到端地擁有自己的系統。
- 隨著時間推移，整個產業開始採用這些實踐作為建構和營運大規模分散式系統的實用模型。
- 實際上，那個時代的工具呢？
- 在 2000 年代，大多數開發者仍然在地端建構和部署東西。
- 寫程式意味著要與硬體搏鬥、容量規劃、漫長的採購週期。
- 當雲端服務出現時，它們再次改變了世界的期望。
- 開發者突然擁有了大量的基礎設施、實驗的自由。
- 我們不再等待硬體。
- 這需要新的技能。
- 各地的開發者適應了一個雲端基礎設施就是建構和營運軟體的正常方式的世界。
- 我的第一個 IDE。
- 有人猜嗎？
- Vi。
- 不，我不是 Emacs 的人。
- （觀眾歡呼和鼓掌）只是說一下。
- IDE 實際上也和我們一起演化。
工具的演化與黃金時代
- 在某個時候我們有了 Microsoft，你可以在螢幕上畫方塊，你有了第一個真正的 IDE。
- 後來我們有了 Visual Studio。
- 然後 Visual Studio Code 成為了預設選擇，因為所有那些驚人的外掛程式。
- 而今天的環境，是 Cursor 和其他工具，那就是新的工作流程。
- 明年會有新的工作流程嗎？
- 五年後呢？
- 十年後呢？
- 當然會有。
- 不過我認為我們今天的工具是非常卓越的。
- 在 Matt 的主題演講中，我們已經看到開發者透過 AI 輔助工作流程變得戲劇性地更有生產力的例子。
- 但這些都不能取代只有你才能做的工作。
- 記住，工作是你的，不是工具的。
- 是你的工作才重要。
- 在我的職業生涯中，我們的工具已經改變了很多次，而且會繼續改變。
- 我們仍然是建構者，我們仍然很重要。
- 什麼都沒變。
- 作為一名開發者，從來沒有比現在更令人興奮的時刻了。
- Bezos 不久前在一次訪談中談到，我們正生活在多個同步黃金時代匯聚的中心。
- 太空旅行、人工智慧、機器人技術。
- 每個領域都在以令人難以置信的速度前進。
- 但讓這個時刻不同的是這些突破實際上如何相互強化。
- 一個領域的進步加速了其他領域的進步。
- 這實際上讓我回想起歷史上一個類似的時期。
- 文藝復興（Renaissance），重生（rebirth），來自一段黑暗之後。
- 黑暗時代（Dark Ages）。
- 中世紀（Middle Ages）。
- 黑死病（plague）。
- 任何認識 Monty Python 的人都知道那看起來是什麼樣子。
- 但文藝復興是一個一切都改變了的時期，因為人們變得好奇。
- 好奇心完全爆發了。
- 其結果是驚人的科學家和哲學家。
- 如果你看看這個，de Medici 可能是第一個版本的風險投資家或慈善家，或者你想怎麼稱呼他。
- Galileo 和 Copernicus 是驚人的科學家。
- Petrarch，最早的哲學家之一。
- Da Vinci，我們稍後會回到他。
- 但同時也演化的是他們的工具。
- 不僅僅是因為好奇心才有了他們。
- 鉛筆被發明了，今天看來這似乎不算什麼發明，但它是一件大事。
- 他們開始思考一個叫做消失點（vanishing point）的概念。
- 當然，如果你比較文藝復興前後的繪畫和素描，之前的都是平面的。
文藝復興的類比
- 在文藝復興時期，繪畫和素描中突然出現了深度和不同的光影。
- 然後，這些工具像是顯微鏡和望遠鏡，當然是由荷蘭人發明的。
- 對。
- （觀眾輕笑）沒什麼好說的。
- 然後，印刷機，當然，我們都將其視為文藝復興中發明的巔峰。
- 但那不僅僅是一項發明。
- Gutenberg 實際上用了一台葡萄酒壓榨機作為他的第一個底版，但那不是他唯一需要發明的東西。
- 他需要發明活字印刷。
- 基本上就是你有可以組合在一起的字元。
- 他必須發明一種可以塗在那些字元上的墨水。
- 然後，紙張和印刷術。
- 在那個時代幾乎是不可想像的。
- 那是一個藝術和科學是同一場對話的一部分的時代。
- 創意和科技一起演化。
- 我花了一些時間思考是什麼讓那個世界中的人們如此有效率。
- 他們很好奇。
- 他們質疑假設。
- 他們廣泛學習並深入應用所學。
- 他們不認為領域之間有界限。
- 他們在領域之間建立了橋梁。
- 他們也是大膽的實驗者，他們素描、他們測量、他們失敗、他們再試一次。
- 他們透過實踐來學習。
- 所以，如果我把所有這些綜合起來，我認為將它們結合在一起，我認為我們再次處於文藝復興的時代。
- 而你就是新的文藝復興開發者（Renaissance Developer）。
- 那些文藝復興時期科學家的特質在今天同樣適用。
- 所以，我把它們整合成一個我稱之為文藝復興開發者（Renaissance Developer）的框架。
- 我今天想向你們展示這個框架，希望能幫助你們在這個新時代中演化並取得成功。
- 在所有這些當中，什麼是至關重要的？
- 你需要培養的第一個特質是，你需要保持好奇。
- 好奇心至關重要。
- 作為開發者，你一直都必須持續學習，因為一切都在不斷變化。
- 我遇到的每一位開發者都有這種本能，要把東西拆開來看看它是怎麼運作的。
- 這也是驅動我們來到這裡的原因。
- 理解、改進、建構的渴望，你必須保護這個本能。
- 保持好奇，因為好奇心引領學習和發明。
- 對學習同樣重要的是兩件事。
- 對於所有新發明，你需要實驗，而要好好實驗，你需要願意失敗。
- 畢竟，Da Vinci 造了一架從未飛起來的飛機，但我們現在在飛。
- 順帶一提，如果你已經知道結果，那就不算是實驗。
- 這驅動實驗，驅動學習。
Quality 1: Be Curious 保持好奇
實驗、失敗與社會學習
- 而這種願意失敗的精神至關重要。
- 當我學一門新語言時，無論是荷蘭語、英語、葡萄牙語還是德語，我發現同樣的原則適用。
- 學習的最佳方式是失敗並被溫和地糾正。
- 你可以盡情研究文法，但真正的學習始於你踉蹌地闖入一段對話，而這些踉蹌幫助你把事情做對。
- 軟體也是一樣的方式運作。
- 你可以無止盡地閱讀文件，但真正教會你系統如何運作的，是那些失敗的建構和破碎的假設。
- 最近使用過 Rust 編譯器的人都知道你能得到多少回饋。
- 有些事情你只能透過實際去做才能學到。
- 閱讀、觀看、聆聽只能帶你走到這麼遠。
- 但真正的學習發生在你投入、有一些壓力、結果很重要的時候。
- 壓力和表現之間有一種關係，叫做 Yerkes-Dodson 定律。
- 圖像是一條鐘形曲線，壓力太小你就心不在焉，壓力太大你就不堪負荷。
- 甜蜜點在那個上升斜坡的某處，好奇心與挑戰相遇的地方。
- 那就是你的大腦完全警覺、專注、準備好成長的時候。
- 你坐在舒適的地方是到不了那個點的。
- 你必須把自己放在考驗你的位置。
- 現在，這背後有一整個故事。
- 今天你們在座位上找到的那份報紙 The Kernel，裡面有一篇 Andy Warfield 寫的文章。
- 我強烈建議你們都去讀那篇文章，如果你們真的想更深入了解這些的話。
- 現在說到學習，還有另一面。
- 學習是社交性的。
- 我們不是來這裡只為了坐在房間裡聽一個人告訴你該做什麼。
- 你真正學到東西是透過彼此交談。
- 學習不僅僅是認知的，它是社交的。
- 你偶爾得去接觸現實。
- 我的意思是，你必須走出你平常的環境。
- 去參加使用者社群、參加像 re:Invent 這樣的研討會。
- 和朋友喝杯咖啡，聊聊系統。
- 保持敏銳的最好方式之一就是和其他也在建構東西的人在一起。
- 對我來說，這通常發生在我出差的時候。
- 我因為工作經常出差。
- 那些旅程讓我持續連結人們實際上如何使用科技，而不僅僅是我們想像他們可能會怎麼用。
- 今年，非常幸運的是，我進行了兩趟為期一個月的旅行。
- 一趟到撒哈拉以南非洲，另一趟到拉丁美洲。
- 在這兩個地區，我做了一些演講，但主要是和客戶見面。
- 而真正的事情是我從那些客戶身上學到的東西。
- 這裡有幾個例子。
- 這是 AJE。
- 順便說一句，我花了 21 年才終於踏上亞馬遜河。
- AJE 是一家飲料公司。
- 他們支持亞馬遜河沿岸的社區，給年輕人一個經濟前景，讓他們不必離開村莊去大城市。
- 這是一段精彩的經歷，也是一個做善事的同時也能獲利的絕佳範例。
- 亞馬遜河很美。
- 我看到了粉紅海豚。
- 但它也提醒了我學到的另一件事，並非所有事情都如此美好。
- 今年年初，我在 The Frugal podcast 的一集中與 The Ocean Cleanup 計畫的 Boyan Slat 對談。
- 他告訴我，海洋中 80% 的塑膠來自全世界 300 萬條河流中僅僅千分之一的河流。
- 面對海洋中的塑膠，他們不僅需要清理已經在那裡的東西，還需要阻止新的塑膠透過這些河流進入海洋。
- 他們就是這樣做的。
- 他們建立了一個河流移動裝置，使用無人機、AI 攝影機分析，甚至在我們去的亞馬遜河 Manaus 附近，他們將 GPS 追蹤的假塑膠放入河中，看看它們最終流向何處。
- 結果發現亞馬遜河根本不是一條主要的污染者。
- 但他們建構的這個計算模型，這些在橋上、在船尾的 AI 攝影機。
- 它們建立了一個預測塑膠如何和在哪裡流動的計算模型，幫助他們定位清理系統以獲得最大影響。
- 現在，這趟旅行中另一件完全讓我驚嘆的事情是在盧安達。
- 在盧安達，這是衛生部的總部。
- 這是健康情報中心。
- 在營運中心，巨大的螢幕顯示來自全國四個不同層級醫療機構的近即時資料。
- 他們建構了一個令人印象深刻的系統，攝取和處理大量的醫療資料，將從疾病爆發到產婦健康結果的所有資料視覺化。
- 他們用它來制定新的政策。
- 他們建立了一個模型，顯示國內哪些地區距離醫療提供者超過 30 分鐘步行路程。
旅行故事與 AWS Heroes
- 他們利用這些資料來戰略性地在服務不足的地區設置新的產婦健康設施。
- 他們用資料來驅動政策，並實際落實該政策。
- 另一次拜訪同樣讓我大為震撼，尤其是年輕公司如何正在攻克世界上最困難的問題。
- 在這個案例中，我們在奈洛比。
- 我了解到在那裡的許多地方，人們早上會借一兩美元，買一些商品，然後去市場或街上賣。
- 到了晚上，他們會把這些錢還回去，希望能賺到 40 或 50 美分，那就是他們那天賺的。
- 那足以去買一些食物。
- 很好。
- 但那還不夠去買煮食物的瓦斯。
- 所以，在那些較貧困的地區，都是用碳燃燒來烹飪，造成大量污染。
- 所以有一家年輕的公司叫 KOKO Networks。
- 他們想出了一個完全不同的解決方案。
- 他們基本上建造了這種裝有乙醇的 ATM 機器，還有一個人們擁有的小罐子。
- 人們基本上可以走到機器前，插上他們的罐子，買五分錢的瓦斯，這就足以煮他們當晚的食物了。
- 這就是當開發者將他們的技能應用到真實的人類挑戰時會發生的事。
- 開發者一直在推動進步。
- 你們建構了數位世界的基礎，今天，你們就是那些將 AI 從可能性轉變為有用、安全、可擴展的人。
- 像你們這樣的開發者在過去是不可或缺的。
- 他們在今天是不可或缺的，你們在未來也將是不可或缺的。
- 聯合國預計到 2050 年，這個星球上會多出 20 億人。
- 我們要如何養活他們？
- 我們要如何確保我們有經濟前景？
- 我們要如何確保我們有醫療照護？
- 那是我們作為技術人員有能力去做的，開發技術來幫助解決世界上最大的問題。
- 如果我看看你們當中有些人花了這麼多時間，不只是在房間角落裡建構東西，還實際幫助他人。
- AWS Heroes。
- 我們現在有 200 位。
- （觀眾鼓掌）對，他們值得掌聲。
- 他們就在那裡。
- 所以，我遇到了社群建構者、AWS Heroes，這些人在自己世界的角落解決核心問題。
- 現在有 265 位 Heroes 遍布 58 個國家。
- 但讓我持續驚嘆的是我們能從他們身上學到多少。
- 順帶一提，今年的 Now Go Build 獎項頒給了 Raphael Quisumbing。
- 站起來，Raphael。
- [觀眾] Raffy、Raffy、Raffy、Raffy、Raffy、Raffy。
- Raffy 完全體現了文藝復興開發者的精神。
- 他不只是寫程式，他建構社群，他指導他人，他從 2013 年起就共同帶領菲律賓的 AWS 使用者社群。
- 來，Raffy，再為他鼓掌一次。
- 所以，我認為文藝復興開發者需要的第一個特質是保持好奇。
- 我喜歡 Walt Whitman 的這句話：「我們不是我們所知道的，而是我們願意學習的。」
Quality 2: Think in Systems 以系統思維思考
- 我認為文藝復興開發者的另一個特質是以系統思維思考。
- 請跟我走一下。
- 如果你不太理解，我在這裡說的不是電腦系統，而是更大的系統。
- 在 70 年代，一位名叫 Donella Meadows 的生態學家開始研究複雜系統如何運作。
- 她甚至不是一位電腦科學家，但她的洞見完美地描述了我們的軟體世界。
- 她寫道：「一個系統是一組事物，人、細胞或其他什麼，以一種方式相互連接，使它們隨著時間產生自己的行為模式。」
- 這是一個非凡的定義，因為它捕捉了每個工程師最終都會學到的東西，那就是我們的系統有自己的生命。
- 讓我給你一個例子。
- 順帶一提，這與電腦無關。
- 系統中最引人注目的例子之一來自生態學。
- 在 20 世紀初，狼從 Yellowstone 國家公園被移除了。
- 這看似合理。
- 較少的捕食者意味著更多的麋鹿，意味著更多的生命。
- （狼嚎叫聲）但相反的事情發生了。
- 山谷被過度放牧，樹木消失了，河流開始侵蝕。
- 這種現象被稱為營養級聯效應（trophic cascades）。
- 當我們在 2010 年重新引入狼回到公園時，公園慢慢開始恢復。
- 植被回來了，海狸回來了。
- 甚至河流改變了路線。
- 狼沒有移動河流，他們改變了整個系統的行為。
- 那個單一的回饋迴路，捕食者與獵物，重塑了整個系統的平衡。
- 然後，結構改變，行為改變。
- 當回饋改變，結果就改變。
- 這就是所謂的系統思維。
- 所以，當以系統思維思考時，我們思考的是完整的系統，不只是孤立的部分。
- 每個服務、每個 API、每個佇列都是更大系統的一部分。
- 你不能孤立地改變一個部分，改動或重寫政策你就影響了負載。
- 你加一個快取，你就改變了流量負載，你改變了流量走向，你轉移了團隊所有權，你改變了交付的節奏。
- 每個改變都建立新的模式，有些穩定，有些不穩定。
- 每個動態系統都由回饋迴路所塑造。
回饋迴路與槓桿點
- 增強迴路（reinforcing loops），有時也稱為正向迴路，會放大改變。
- 平衡迴路（balancing loops），或負向迴路，會抵消改變並將系統推回平衡狀態。
- Meadows 認為，一旦你看到這樣的模式，你就開始能看到微小且精準的改變可能在哪裡轉移整個系統的行為。
- Donella 寫了一篇論文，一篇經典的論文，叫做「Leverage Points: Places to Intervene in the System」（槓桿點：介入系統的位置），她在其中把所有這些東西整合在一起。
- 有些詞我們在日常的電腦科學中都知道，正向和負向回饋迴路。
- 但你真的應該讀這篇論文。
- 把這當作作業。
- 拍下 QR 碼的照片，那就是你接下來一週的作業。
- 文藝復興開發者以系統思維思考。
- 要建構有韌性的系統，你需要理解更大的圖景。
Quality 3: Communicate 溝通
- 如果我想到文藝復興開發者的第三個特質，那就是溝通。
- 如果你踏入這個更廣闘的視野，你會意識到清楚表達你的思考的能力和思考本身一樣關鍵。
- 這就是為什麼我相信工程師或技術領導者能為其職業生涯做的最重要的事情之一，就是練習、發展強大的溝通技能。
- 讓我們回到兩年前我們做 The Frugal Architect 的時候。
- 不知道你是否記得這張圖片，這是 Amazon 首頁。
- 我向你解釋了我們如何將首頁或整個 Amazon 系統分成三個不同的層級。
- 第一層是讓系統運作絕對必要的東西。
- 搜尋、瀏覽、購物車、結帳和評論。
- 沒有這五樣東西，網站就無法運作。
- 第一層。
- 第二層是對客戶重要的東西，個人化、推薦等等。
- 第三層可能是可有可無的部分。
- 要能做到這一點，不僅對我們工程師很重要，也是與業務溝通的工具。
- 你去和業務的人坐在一起，談論第一層需要多少個 9 的可用性？
- 噢，四個 9。
- 那會花你那麼多錢，對吧？
- 或者第二層，也許三個 9。
- 第三層，也許你根本不在意，兩個 9。
- 我們想，好吧，如果資料中心離線我們就手動切換。
- 但這是你需要有的溝通，你需要能夠清楚描述你的系統、能力和機會給業務方。
- 溝通至關重要。
- 現在，人類語言，有點挑戰，不是嗎？
- 因為自然語言是模糊的。
- 但我們有這麼多不同的感官，可以同時將這種自然語言轉變為不那麼模糊的東西。
- 我們是把奶奶放在烤架上，還是今晚吃晚餐？
- 即使沒有逗號，你可能已經理解了這句話。
- 現在，我們一直透過程式語言與機器溝通，因為它們是精確的。
- 我們可以精確地指示機器我們想要它做什麼。
- 但在當今 AI 輔助程式設計的世界中，我們越來越多地用自然語言與機器溝通，而自然語言是模糊的。
- 所以，我們需要幫助開發降低語言模糊性的機制。
- 降低人類的模糊性，讓機器能建立邏輯。
- 規格（specifications）降低模糊性。
- 我們的歷史充滿了規格驅動開發的故事。
- Dijkstra 的結構化程式設計環境，在此之前是基於形式化規格，在你實作之前就證明了程式的正確性。
- Apollo 導航系統依賴於精心的規格，引導其 145,000 行程式碼，一份如此精確的藍圖，幫助人類登上了月球。
- 為了跟你們更多地談論規格，我想邀請 Kiro 團隊的資深首席開發者 Clare Liguori。
- Clare，交給妳了。
- （觀眾鼓掌和歡呼）- 謝謝你，Werner。
- 去年某個時候，我開始注意到隨著我越來越多地 vibe coding，我遇到了一個溝通問題。
- 我花越來越多時間試圖向 AI 描述我想要什麼。
- AI 生成的程式碼是好的，但最終的軟體並沒有做我想要它做的事。
- 我經常試圖用新的提示重新開始。
- 我注意到隨著時間推移，我寫了越來越長、越來越詳細的提示，試圖定義軟體應該做什麼。
- 我會在 Obsidian 中用 Markdown 寫這些長而詳細的提示，然後複製貼到我的程式設計助手中。
- 我本質上是在建立一份規格，以更好地與 AI 溝通我想要什麼。
- 軟體規格可以清楚地溝通系統應該如何運作、應該做什麼和不應該做什麼。
- 就像 Werner 說的，歷史上許多系統都是基於規格的，例如 Apollo 任務。
- 我覺得規格正是我與程式設計助手互動中所缺少的。
- 但接著我想，我們怎麼能將規格作為提示這個想法來使用呢？
- 規格驅動開發（spec-driven development）會是什麼樣子？
- 這個想法的火花引導我們開始了 Kiro IDE 的開發。
- 不過有了這個想法，我們現在有了一個新的溝通挑戰，我們如何與潛在使用者溝通和驗證這個想法？
- 我們不知道它會是什麼樣子，也不知道使用者想要什麼。
- 要描述規格驅動開發是什麼也有點困難。
- 他們沒見過它，我們也還沒建構它。
- 傳達你的想法的最好方式之一是快速建構一個原型，讓使用者可以看到和觸摸的東西。
- 快速原型製作當然不是一個新想法。
- 讓我們回到 60 年代打孔卡片的時代。
- 1964 年，SRI 的 Doug Engelbart 有一個粗略的想法，一個底部有輪子的裝置，你在桌面上滑動它來指向電腦螢幕上的東西。
- 我們大概都能在腦海中想像這個裝置。
Clare Liguori 與 Kiro IDE
- 但你能想像回到 60 年代，試圖向這個人描述什麼是滑鼠嗎？
- Engelbart 的團隊用一塊木頭快速建造了一個原型。
- 那是一個木殼，底部有輪子，頂部有一個按鈕。
- 這個粗糙的原型比任何畫作或描述都更好地傳達了什麼是滑鼠。
- 它讓人們把手放上去，立刻理解了這個概念。
- 它有很好的人體工學，握在手中感覺很好。
- 就像滑鼠一樣，快速原型製作對 Kiro 至關重要。
- 我們知道規格驅動開發的人體工學很重要，它握在開發者手中的感覺。
- 我們快速建造了我們認為規格驅動開發可以如何運作的原型。
- 我們把那些原型放在一些內部使用者手中，要求他們每天使用 Kiro。
- 那將是我們理解什麼感覺好、什麼感覺不好的最佳方式。
- 這是 AI 現在能為我們做的一個很好的例子。
- AI 從根本上實現了軟體的快速原型製作。
- 我相信在過去，我們都花了好幾個月手動為一個想法寫程式。
- 現在，我們可以在幾分鐘內給使用者真正可運作的原型，以獲得關於什麼感覺對的回饋。
- 快速原型製作 Kiro 甚至讓我們用 Kiro 來建構 Kiro。
- 我們最初的 Kiro IDE 原型只能做 vibe coding。
- 但從那一刻起，我們就能用 Kiro IDE 來生成 Kiro IDE 的程式碼。
- 透過使用 Kiro IDE 來建構產品，我們能夠迭代許多規格驅動開發可以如何運作的想法。
- 一個想法是測試驅動開發（test-driven development）規格，從 TDD 技術中獲取靈感。
- 你描述你想要的改變，Kiro 會生成測試來驗證你描述的行為。
- Kiro 接著會生成應用程式碼，確保它通過那些測試。
- 但我們發現開發者不能總是僅用測試來捕捉他們想要軟體做什麼或看起來像什麼的細微差異。
- 我們嘗試了類似 Werner 描述的 Apollo 導航系統那樣的傳統技術規格。
- 它們描述了系統整體及每個元件的細節。
- 你會在整體規格中新增一個功能，Kiro 會根據你描述的改變啟動程式設計任務。
- 這些規格對 AI 來說是很好的上下文，甚至對不太熟悉這個程式碼庫的開發者也是。
- 但對於真實世界的專案，它們有時會變得極其冗長。
- 所以很難弄清楚在這份長長的規格中，你應該把新功能的改變放在哪裡。
- 我們退一步，看看我們作為團隊已經是怎麼工作的。
- 當我們有一個新功能想法時，我們會描述它。
- 我們會處理產品需求、審查設計文件、建立 sprint 任務。
- 我們想也許規格可以遵循同樣的模式，那就成了功能驅動規格（feature-driven specs）。
- 我們把流程分成三份文件：需求（requirements）、設計（designs）和任務（tasks）。
- 我們發現這給了開發者更多對 AI 的控制，讓他們更好地溝通他們想要什麼。
- 所有這些快速原型給了我們關鍵的使用者回饋，帶來了今天在 Kiro IDE 中的規格驅動開發工作流程。
- 有了規格工作流程在 Kiro 中就位，我們可以更有效地使用它來持續建構產品。
- 因為現在我們可以更精確地與 AI 溝通我們想要什麼。
- 在 vibe coding 中，我經常發現我們給 AI 非常模糊的任務。
- 我們可能會說：「幫我建構一個網頁問答遊戲。」
- 從這個很短的提示中，可能有一百萬種不同的最終結果，但可能只有一種是你腦海中想的。
- 用 vibe coding，AI 會盡力猜測你的意思，它會生成程式碼，但這讓你不得不與 AI 在程式碼上迭代，而不是在你原本想要的東西上迭代。
- 用規格驅動開發，你有機會透過規格更精確地細化你的意思。
- 你可以給 Kiro IDE 同樣模糊的任務，但它不會馬上跳進程式碼，而是先生成需求、設計、任務。
- 如果這些不符合你腦海中的想法，你有機會要求 Kiro 改變和細化。
- 讓我們走過一個我們在 Kiro IDE 中用規格驅動開發建構的生產功能的真實例子：系統通知。
- 我們從一個我們自己在早期版本 Kiro IDE 中經歷的小煩惱開始。
- Agents 可能需要一段時間來完成程式設計工作，同時我們會切換到不同的應用程式，但 agent 需要使用者輸入或完成工作時，我們完全不知道它在那裡閒置，而我們在做其他工作。
- 所以我們著手建構一個功能，在 agent 需要注意時通知使用者。
- 我們先讓 Kiro 生成規格，生成的需求實際上幫我們思考了一些細節，比如哪些 agent 動作應該觸發通知給使用者。
- 當我們到了設計階段，我們預期這會是一個相當簡單的整合到 Kiro agent 程式碼中。
- 但 Kiro 生成了一個非常複雜的設計，要直接在我們的 agent 程式碼中建構一個全新的通知系統。
- 現在，如果我們 vibe coded 這個，我們會得到一大堆我們實際上不想要的程式碼。
- 但相反，規格流程幫我們快速意識到這是一個比我們原先想像的更大的專案。
- 我們在規格上迭代，首先專注於在 agent 程式碼之外、直接在底層 IDE 程式碼中建構通知系統。
- 這需要建構在 Electron 的原生通知 API 之上。
- Kiro IDE 基於 Code OSS，這是一個跨越 10 年開發和 200 萬行程式碼的程式碼庫。
- 對任何開發者來說，弄清楚在這個程式碼庫中需要在哪裡做改動都是很困難的。
- 但 Kiro 的規格工作流程實際上幫助我們探索和理解需要在哪裡做出這些改動。
- 一旦這些改動就位，我們又能再次使用規格驅動開發將其整合到我們的 agent 程式碼中。
- 在整個過程中，我們能快速在規格上迭代，直到我們從 AI 那裡得到了我們想要的東西。
- 用規格驅動開發，我們以大約 vibe coding 一半的時間交付了這個 agent。
- 在我們建構 Kiro 的經驗中，我們意識到 AI 改變了我們如何溝通以及我們能多快迭代。
- 我們可以透過規格與 AI 溝通來迭代軟體設計，我們可以透過快速將真正可運作的應用程式交到使用者手中來迭代軟體的功能並獲取回饋。
- AI 和規格驅動開發幫助我們建構了更好的 Kiro IDE，這在很大程度上得益於透過快速原型與使用者的更精確溝通，以及透過規格與 AI 的溝通。
- 自然語言不一定意味著高度模糊。
- 就我個人而言，這就是我認為 Kiro IDE 如此特別的原因。
- Kiro IDE 為自然語言帶來了精確性。
- 說完這些，我把時間交還給 Werner。
- （觀眾鼓掌）（輕快音樂）- 謝謝妳，Clare。
- 溝通是如此重要，Clare 展示了它如何帶來更少錯誤的系統。
- 實際上，讓我再告訴你們一個故事，算是來自我自己年輕時候的。
- 當我上電腦科學學校時，有一門課叫訪談技巧，我想：「什麼，訪談？」
- 因為你會想到記者之類的。
- 不，它是學習如何與客戶對話，真正試圖理解他或她實際上真正想要什麼。
- 因為他們可能已經帶著一個技術解決方案來找你，而對技術一無所知。
- 這些日子我遇到客戶說「我應該用 GenAI 做什麼？」不會是第一次了。
- 然後，因為你真的受過訓練去深入了解，你說我非常抱歉要用一個問題回答你的問題，但你為什麼問我這個？
- 大部分是害怕錯過（FOMO）。
- 所以，真正深入與客戶一起理解他們想解決什麼問題、他們看到什麼機會？
- 所有這些都是我們作為工程師應該具備的溝通能力。
Quality 4: Be an Owner 成為擁有者
- 現在，讓我們進入第四個，我稱之為文藝復興開發者的第四個特質。
- 開發者是一個擁有者，擁有權。
- 我之前已經談過了，但今天我想專注在其中一個部分。
- 擁有你軟體的品質。
- AI 會讓我們建構東西、更大的系統、探索更多想法、比以往更快地前進。
- 這些工具，正如現代哲學家 Daft Punk 所說：「幫助我們建構得更用力、更好、更快、更強。」
- 如果我們正確使用這些工具，它們可以幫助我們產出高品質的軟體。
- 但有些開發者開始使用這些工具的方式存在風險。
- Vibe coding 沒問題，但前提是你密切關注正在被建構的東西。
- 我們不能只是拉一下 IDE 的把手然後希望好東西會跑出來。
- 那不是軟體工程，那是賭博，你得去別的地方做那個。
- 記住我一開始說的，工作是你的，不是工具的。
- 如果你受到法規要求的約束，比如說醫療照護、金融服務等等，如果 AI 建立了一些確實違反法規要求的程式碼，你不能去對監管機構說：「噢，那是 AI 做的。」
- 不，那仍然是你的責任，工作是你的，不是工具的。
- 現在，世界正在改變。
- 你會寫更少的程式碼，因為生成速度太快了；你會審查更多的程式碼，因為理解需要時間。
- 當你自己寫程式碼時，理解伴隨著創造的行為而來。
- 當機器寫程式碼時，你必須在審查過程中重建那個理解。
- 這就是所謂的驗證債（verification debt）。
機制與善意
- 這是我與開發者談論這種新工作方式時聽到的兩個主要挑戰之一。
- AI 可以比你理解程式碼的速度更快地生成程式碼。
- 程式碼瞬間到達，但理解不會。
- 這個差距允許軟體在任何人真正驗證它做了什麼之前就朝著生產環境前進。
- 第二個挑戰當然是幻覺（hallucination）。
- Clare 之前展示了一個完美的例子。
- 模型產生了一個看起來很有信心但完全不適合這個架構的設計。
- 有些 API 會改變，LLMs 會發明不存在的屬性。
- 有時候它們提出的解決方案完全不恰當或過度工程化，或者忽略你系統本身的限制。
- 這些輸出看起來合理，但並不基於現實。
- 我認為我們正在取得進展。
- 我們正在開發像規格驅動開發這樣的實踐，Clare 展示了它如何能大幅提升品質。
- Byron 的主題演講展示了像 Kiro 這樣的工具如何能實際使用自動推理（automatic reasoning）搭配你的規格來建立經過驗證的程式碼。
- 我們展示了我們也能使用自動推理來確保針對 AWS API 生成的程式碼是正確的。
- 我也看到許多開發者在審視他們的 CICD 管線，然後建構越來越多的自動化測試。
- 這些都是機制的類型。
- 在這裡，我要做一個轉換。
- 我要你們真正理解這兩件事。
- 有機制（mechanisms），也有善意（good intentions）。
- 它們不是一回事。
- 讓我透過回到過去一點，告訴你們一個關於 Jeff Bezos 的故事來說明。
- 在 Amazon 的早期，我們作為主管每年都被要求花兩天時間在客戶服務部門接聽客戶電話，這樣我們才能真正理解客戶正在經歷什麼。
- 不只是高階主管，Jeff 本人也是。
- 所以，Jeff 坐在一位客戶服務人員旁邊。
- 電話響了，自動系統已經叫出了這位客戶的訂單歷史。
- 在客戶說任何話之前，客服人員對 Jeff 說：「她要退那張桌子」，果然客戶要退桌子，因為桌子損壞了。
- 電話結束後，Jeff 看著這位客服人員說：「你怎麼知道的？」
- 她說：「嗯，那些桌子有 70% 會被退回，因為有某個代發貨商（drop shipper）不太會包裝。」
- 當然，Jeff 把所有人召集到房間裡開始思考。大家都有善意。
- 不，當然我們不想讓這種事發生。
- 但沒有機制，什麼都不會改變，因為每個人早就有善意了。
- 所以，他引入了一個新的機制，Amazon 版本的 Toyota 著名的 Andon Cord。
- Toyota 的 Andon Cord 原則是：任何汽車都不應該帶著已知缺陷離開生產線。
- 在生產線上工作的任何工程師都可以拉這條繩子，使整條生產線停下來，直到缺陷被修復。
- 客服人員得到的 Andon Cord 是一個使產品不可銷售的按鈕。
- 那會觸發負責該產品的人員的警報，讓他們去修復問題。
- 但在這之前，每個人已經有了善意，直到我們引入了機制，什麼都沒有改變。
- 現在，讓我們回到我們的技術世界。
- 機制有很多形式。
- 每個團隊建構適合其規模和工作性質的機制。
- 例如，S3 團隊使用一種他們稱為耐久性審查（durability reviews）的東西。
- 當一位工程師提出一個可能影響耐久性的改動時，他們會暫停並建模風險。
- 他們寫下改動，列出每一個可以想像的威脅，規劃出保護資料安全的防護措施，這是一個具有非常強大效果的機制。
- 它將耐久性從程式碼的一個屬性變成組織的一個習慣。
- 它讓工程師以失敗模式思考，而不是只想順利的路徑。
- 這就是為什麼機制很重要。
- 它們將善意轉化為一致的結果。
- 現在，如果你想想看，程式碼審查也是一種機制。
- 我知道，我們都討厭程式碼審查。
- 就像 12 歲站在全班面前一樣，對吧？
- 但它們是非常重要的機制，因為它們建立了一個意圖與實作相遇的時刻。
- 另一位工程師可以在那裡質疑假設，捕捉你的編輯器不再看到的東西。
- 在 AI 驅動的世界中，它們比以往任何時候都更重要。
- 在 AI 驅動的世界中，它們至關重要。
- 模型可以比我們理解程式碼的速度更快地生成程式碼。
- 所以，審查成為恢復平衡的控制點。
- 這是我們將人類判斷帶回迴路中的地方，確保軟體確實做了我們期望它做的事。
- 我鼓勵你們所有人繼續並增加你們的人對人程式碼審查。
- 當資深和資淺工程師一起審查程式碼時，它成為我們擁有的最有效的學習機制之一。
- 資深工程師帶來模式識別和來之不易的判斷力。
- 資淺工程師帶來新鮮的視角，經常發現細節。
- 看，這就是我們如何傳遞知識、如何培養下一代建構者。
- AI 會改變很多東西，但這門手藝仍然是人對人學習的。
- 所以，在我看來文藝復興開發者的第四個特質是擁有者。
- 你建構它，你擁有它。
- 我想跟你們談的最後一個特質是，我認為你們這些未來的文藝復興開發者需要成為博學者。
Quality 5: Become a Polymath 成為博學者
- 現在，順帶一提，這跟數學無關。
- 不是 mathematics 或 maths，或者你想怎麼稱呼它。
- polymath 這個詞跟數學無關。
- 它實際上意味著「多」，因為 math 來自希臘文 manthanein，意思是「學習」。
- 它是關於擁有深厚的領域經驗，但同時也有跨越多個不同學科的知識。
- Da Vinci 可能是博學者最好的例子，因為他跨越了這麼多不同的學科工作。
- 他是畫家、工程師、經濟學家和發明家。
- 現在，我不指望你們都成為 Da Vinci。
- 但你應該將你的知識擴展到深度領域專業之外。
- 這就是我所說的 I 型開發者。
- I 型開發者（I-shaped developer）是在一個領域非常深入且高度專精的人。
- 讓我再講一個來自我自己經歷的有趣故事。
- 這是我的老導師和朋友，Jim Gray。
- Jim 獲得了 Turing 獎，因為你們都應該知道 Jim Gray，他是交易（transactions）的發明者。
- 今天你做的每一筆交易，我們都要感謝 Jim。
- 但他也有偉大的頭腦，他對遠不止資料庫的更多事情感興趣。
- 這是他著名的挑戰之一。
- 給我 20 個問題，20 個你想問你的資料的重要問題，我會為你設計系統。
- 他最早工作的其中一個是 Sloan Digital Sky Survey。
- 這是最早的大規模資料集之一。
- 那是開發 SkyServer 的開創性工作。
- Jim 作為資料庫專家的深入知識對天文資料的計算是變革性的。
- 實際上有一個很有趣的故事。
- 某個時候，Jim 去了費城的 Baltimore，那個團隊在的地方，他走進伺服器房。
- 30 秒後，他走出來告訴他們資料庫布局是錯的，（機器嘎嘎作響）每個人看著他說：「你怎麼知道的？」
- 只是透過聽碟片的嘎嘎聲，他就知道有太多隨機存取了。
- 這種由數十年經驗建立的直覺，給了他一種關於系統應該如何運作的第六感。
- 他幫他們重新設計架構，效能顯著改善。
- 現在，Jim 完全不是我所說的 I 型開發者。
- 他的好奇心遠遠超越了資料庫。
- 他理解人、理解商業、理解廣泛的技術。
- 我會把我出色的技術人員描述為 T 型（T-shaped）。
- 在一個領域很深，但帶有廣泛的理解。
- 你在工作中取得成功所需的技能是個人技能、功能深度、產業知識的獨特組合。
- 一位理解效能或成本感知架構的資料庫開發者可以做出更好的架構選擇，因為他們看到自己的工作如何塑造整體系統。
- 那種知識的廣度給你視角來改進你建構的東西，因為你理解權衡。
- T 型開發者結合了深度與廣度。
- 他們可以深入研究特定問題，但也理解它如何適配更大的系統。
- 這是我給你們所有人的建議：兩者都建構。
- 在你的領域發展深度，但培養、培養連接多個學科和想法的廣度。
- 所以，文藝復興開發者的最後一個收穫是成為博學者。
- 嗯，我不指望你們都成為那樣的人，但你應該拓寬你的 T。偉大的開發者是 T 型的。
- 他們是各自領域的專家，理解自己的工作如何適配更大的系統。
- 你必須拓寬你的 T。
Closing & Call to Action 結語與行動呼籲
- 現在，如果我們看看整場演講中的文藝復興開發者，我用不同的方式稱呼了他們。
- 我認為你需要保持好奇並持續學習。
- 以系統思維思考，精確溝通，成為擁有者。
- 你建構它，你就擁有它。
- 最後，成為博學者，拓展你的知識。
- 接下來一週你會有充足的時間開始實踐這一切。
- 今晚之前，在 Las Vegas Festival Grounds 加入我。
- 會有很棒的食物、一些瘋狂的遊戲，當然還有 Beck 和 Kaskade 的現場音樂演出。
- 這是一個和你的團隊一起慶祝、在一週嚴肅的學習和建構之後放鬆的機會。
- 現在，還有一件事。
- 我想留給你們的是這個。
- 當你建構一個應用程式之類的東西時，客戶會不會想過底下所有的工作？
- 一個 Amazon 客戶會點一個按鈕然後包裹就到了。
- 他會想到維護目錄、做供應鏈的人嗎？
- 所有那些工作，沒有人看到，對吧？
- 你的客戶永遠不會告訴你，你的資料庫工程師做了很棒的工作，他們喜歡他們所做的。
- 只有你理解那些投入的工作。
- 我相信對我們所有人來說，在我們的工作中擁有自豪感是很重要的，在那些徹夜運行的看不見的系統中，在乾淨的部署中，在沒有人注意到的回滾中。
- 我們建構的大部分東西，沒有人會看到。
- 我們把這些做好的唯一原因是我們自己對卓越營運的專業自豪感。
- 這就是定義最優秀建構者的東西。
- 他們在沒有人看的時候也把事情做好。
- 當我看到你們每天交付的工作，我到處都看到那份承諾。
- 所以為此，我為你們感到無比驕傲。
- 感謝你們所做的一切。
- 再兩個。
- 噢。
- 再兩個字。
- Werner out。
- （遙控器掉落聲）（明亮的音樂）（明亮的音樂持續）
✳️ Reference 參考資料
- AWS re:Invent 2025 - Keynote with Dr. Werner Vogels - 完整主題演講影片
- Amazon Kiro - 規格驅動開發的 agentic IDE
- The Frugal Architect - Werner Vogels 在 re:Invent 2023 提出的成本感知架構框架
- Leverage Points: Places to Intervene in a System - Donella Meadows 1999 年關於系統思維的經典論文
- The Ocean Cleanup - 開發技術從海洋和河流中清除塑膠的非營利組織
- KOKO Networks - 為非洲和印度城市提供清潔烹飪燃料和技術解決方案
- AWS Heroes - 表彰全球技術領袖的社群計畫
- Jim Gray (computer scientist) - Turing 獎得主，交易處理和資料庫系統的先驅