最有收穫的部分大概就是封面圖了。
AI 時代工程師的角色翻轉：
| 舊時代 | AI 時代 | |
|---|---|---|
| 工作 | 工程師寫 code | 工程師設計 + AI 生成 |
| 成果 | code 是成果 | 理解是成果 |
| 日常 | debug code | 驗證行為 |
| 知識資產 | 程式碼 | 理解 |
理解是工程師在 AI 時代唯一真正的知識資產。 投影片上特別強調：判斷能力 » 撰寫能力。 進一步的演進路徑分四個階段：Coder → Prompt Designer → System Designer → Reality Engineer（定義、預測、驗證，處理不確定性管理與複雜系統思考）。
Ruddy 老師說，在不久的將來，高端的工程師都會變成在做 QA 的事情，我們不寫 code，我們設計、理解與驗證程式的行為。
There is no code better than “No Code” – Kevlin Henney
我們看情境，以及行為的「產出」，輸入不同數據得到不同結果。
code 不再是產出，「理解」才是工程師的「產出」
開場 Ruddy 老師就說了一句讓我印象很深的話 ——
把王宏仁的投影片餵給 AI，請他用王宏仁的語調重新講一遍。
💡 Brilliant 💡
好有趣，這年頭大家都是這樣學東西的，突然覺得我快被淘汰了。 原本的我大概率就是回去看筆記+把投影片再看一遍，應該不會問 AI 請 AI 整理。
沒關係，至少現在我學會了。
令人啟發的演講內容
AI 時代下 DX 的重要性大幅提升
可觀察性：由 UX 推演到 DX 工程可觀察性 : DX
我們可以用 AI 埋 code，埋在我們想看到這個系統行為是否如我們預期的地方。觀察他的數據意圖是否是我們所要的。
Source code 你不用看，你看的是系統在做什麼。
Vibe coding to Vibe story 意圖 -> 數據 -> 整合 -> 特徵
你的意圖透過 AI 變成 code，code 跑起來產生數據，數據組成故事，故事形成你對系統的理解，理解最後變成可觀察性的基準——這就是 AI 時代工程師的工作流程。
很抽象對吧XDDD
簡而言之就是
用觀察性看程式運行情境
同一個 prompt，AI 每次都可能給你不同答案
同一個 Prompt， 為何產生不同答案？
今天才看到 Claude 出了 prompt master，讓不會寫 prompt 的我彷彿得到了救贖。
我們正在從 Prompt Engineer 變成 Harness Engineer
Prompt Engineer 知道怎麼「問 AI」；Harness Engineer 知道怎麼「控制 AI 行為」 harness engineer
如果能控制 AI，就能「完全不動手」
我們可以做到「完全不動手」，但要先克服三個障礙
AI 時代你可以不用親手寫 code，但需要三種能力來支撐「行動力」：
克服「完全不動手」的三個障礙
A. 模組化思維（Computational Thinking）
不能叫 AI「幫我寫一個電商網站」。這種大型任務交給 AI，spaghetti code 的機率極高。 正確做法是把需求原子化——先寫「身份驗證模組」，再寫「庫存扣除邏輯」。 我們真正要做的不是寫程式，而是畫邏輯流程圖。
B. 從「撰寫者」轉向「評論家」（Observability/Code Reviewer）
我們不產出 code，但我們負責驗收。要能一眼看出 AI 寫的有沒有 SQL Injection 風險、效能問題。工具是讓 AI 替自己的 code 做 TDD，自己寫單元測試。
C. 建立自動化管線（AI Pipelines）
讓一個 AI 寫 code、另一個找 Bug、第三個部署。我們管理的是工作的 flow 而不是程式行數。
不是缺乏能力，而是缺乏可行動的結構。
如果沒有分層觀察，我們根本不知道 AI 在幹嘛
這裡 Ruddy 老師借用了 Judea Pearl 的因果推理概念，把觀察分成三層：
- Seeing（關聯）：我看到了什麼現象、模式、變化？
- Doing（干預）：我做了這個改變，帶來了什麼後果？
- Imagining（反事實）：如果我當初沒這樣做，現在會怎樣？還有沒有更好的選擇？
停在 Seeing 層，你只是在看 dashboard。 真正的工程判斷力要走到 Imagining 層，也就是反事實推理。 擅用 AI 的反事實推理，可以讓我們更全面地理解。
老師說了一句很直白的話：判斷能力 » 撰寫能力。
進一步的演進路徑是四個階段：
Coder → Prompt Designer → System Designer → Reality Engineer
（定義現實、預測行為、驗證結果，處理不確定性與複雜系統）。
AI 時代的 Debug：假設驅動開發（HDD）
AI 的產出，其實是一種假設，不是答案。
Debug 的流程變成這樣：
問題/需求
→ AI 生成（LLM/Agent）
→ Debug Layer：假設 → 觀察 → 驗證 → 迭代
→ 可觀察性層：Evidence/Metrics/Logs → 決策 → 知識資產化
→ 回饋到 Prompt/系統
這個循環有兩個守備區：
不確定性層：AI 的地盤，產出假設
可觀察性層：人類守備區，負責判斷——Human In The Loop
老師說，面對 AI 生成的 code，Senior 工程師會抱持懷疑的態度，用假設做驗證，利用這個間隙去設計實驗、觀察數據。Junior 工程師則是想快速確定能不能跑。 我聽到這段想說，確實，code 產出來就是先跑跑看能不能動啊XD
為什麼你的 prompt 沒用？通常是少了這三個東西
去歧義性（De-ambiguation）：消除自然語言中的灰色地帶
可預測性（Predictability）：即使運行多次，結果的邏輯架構保持一致
可驗證性（Verifiability）：輸出必須包含足以讓你「判斷」的證據或邏輯鏈
結構化 Prompt 對應的是 BDD 的 Given/When/Then 語法——Given 是你的觀察與可觀察性設計、When 是系統行為、Then 是你的判斷力展現。
面對不確定性，「驗證 AI 給的對不對」成為開發的核心行為
可觀察性是治理 AI 不確定性的唯一解藥 「驗證 AI 給的對不對」成為開發的核心行為
看不到完整信號 → 以為自己看懂了（Illusion of Visibility）
基於錯誤假設做決定 → False Confidence
問題發生才慢慢意識到 → 進入 trial & error 的無底洞
公式就是：Low Observability → False Confidence → Poor Decisions
S.H.I.P 迷霧法則：面對不確定性的態度
不確定性不是要被消滅的敵人，是宇宙運行的基本法則。
Stillness：暫停衝動反應，不要被資訊洪水牽著走 Humility：承認知識有限，為學習與修正保留空間 Inquiry：以好奇心主動探詢未知，而非被動等待答案 Productive Struggle：將掙扎視為成長的必要張力，而非失敗
老師引了一句話讓我很有感：
我們要害怕的不應該是不確定性，而應該是我們越來越不情願去辨別細微的差別、尋找深度和視角——以及這種能力可能變得越來越弱。
如果你想跟 AI 好好合作，這四個原則很關鍵（Ethan Mollick，《Co-Intelligence》）
Co-Intelligence
- Always invite AI to the table：不管你覺得它行不行，先讓它參與每一件事。而且要 multi-model 交叉驗證，不能只問一次。你才會知道他哪些強、哪些弱、哪些可以信任、哪些不能。
- Human in the loop：人類的專業判斷、價值觀、責任感仍然是最後一道關卡。Code reviewer 的重心不是看語法，而是觀察行為、得到情境。
- Treat AI like a person, but tell it what kind of person it is：給它角色、個性、專業背景，效果會好非常多。
- Assume this is the worst AI you will ever use：把現在的 AI 當成你用過最爛的，因為明天的 AI 一定更好。AI 不會自我反思，所以你要保持批判眼光。
當 AI 進入團隊，問題不再是技術，而是協作
Stand up meeting 的時候可以讓團隊溝通是怎麼用 AI 的。創造共識，減少溝通時間。 Flow
不確定性下的決策閉環：空、雨、傘
這個框架來自麥肯錫，Ruddy 老師把它套用在 AI 可觀察性上，我覺得非常順：
空（Fact）：客觀不帶解釋的事實。「上個月營收下滑 15%」 雨（Hypothesis）：最可能的假設推論。「可能是新功能上線導致轉換率下降」 傘（Action）：具體可執行的行動。「建議優化 onboarding 流程並跑 A/B test」
對應到 AI 可觀察性的決策公式就是：
Hypothesis → Evidence → Judgment → Learning Loop
Prompt Refinement 本質上就是敏捷 突然想到小時候上科學講的：「大膽假設、小心求證」 只是現在的小心求證變成了快速驗證。 AI 時代的敏捷精神不再只存在於 Scrum 流程，而是藏在每一次 Prompt Refinement 裡：
第一個 Prompt = MVP 觀察輸出、找出不足 = Sprint Review 給出針對性調整指令 = Inspect & Adapt 持續迭代直到接近理想結果 = Progressive Refinement
每一次與 AI 的互動，都是一次完整的敏捷循環。 看板方法與可觀察性的對比 兩者都是對抗「不可見」的工具，只是對象不同： 看板（工作流可見性）可觀察性（系統行為）現在有哪些工作、卡在哪裡系統現在是否健康哪些步驟過載哪裡變慢、哪個服務出錯從開始到完成花了多久為什麼會發生這件事 看板讓知識工作變得可見（事情怎麼做的），可觀察性讓你看見系統內部狀態（事情做的結果）。
Reference
- 讓 Observability 與不確定性共舞 — Ruddy 老師講座
- Ethan Mollick《Co-Intelligence》
- Judea Pearl 因果推理三層次（Seeing / Doing / Imagining）