2026 DEVOPSDAYS TAIPEI ｜ 內部分享
我們看到的，
是 AI 強大？還是使我們強大？
我去了兩天的 DevOpsDays，聽了九場。今天不是要幫他們做摘要——摘要網路上都有。
我想講的是我帶回來的兩件事：一個結論，和一個我到現在還沒有答案的問題。
我們看到的，
是 AI 強大？
還是使我們強大？
先把今天的題目放在這裡。這一題我不會現在回答，但等一下每一段都在往這個答案上疊。最後一頁我會給我的版本。
今天的規則
今天會停下來問你們 4 次
順帶說一下形式。這種提問驅動的講法，是 Ruddy 老師那場的風格——我今天算是用他的形式，來分享他們的內容。
我會停下來問四次，你們舉手就好，不用發言。
01
我們正在欠
一種看不見的債
第一件事，是兩位講者從完全不同的角度講到同一件事。
S03 ｜ 柯仁傑 David Ko（敏捷三叔公）
「認知負債 ＝ 沒搞懂，
但卻立刻就有成品，這中間的落差。」
現在省下理解的力氣，將來在維護、修 bug、處理危機時加倍償還。
柯仁傑講的是「認知負債」。定義很簡單：你沒搞懂，但你立刻就有成品了。
那個落差就是債。債不會消失，只會延後——延到維護、修 bug、出事的時候一起還。
認知，是一整條鏈
點一杯熱拿鐵
聞到咖啡香感知
→
冰的還熱的？注意
→
上次喝冰的拉肚子記憶
→
今天冷，熱的好推理
→
我要熱拿鐵決策
→
「一杯熱拿鐵」語言
有了 AI 之後
聞不到
→
不知道自己要什麼
→
不記得發生過什麼
→
推理不動
→
AI 幫你決定
→
你只是按 Yes剩下這個
他用一個很生活的例子解釋「認知」是什麼——從接收訊息到做出反應，中間這一整條。
有了 AI 之後，這條鏈中間整段被跳過了。你最後只做一個動作：按 Yes。
證據一 ｜ 短期・功能
"Your Brain on ChatGPT"
Kosmyna et al., MIT Media Lab ｜ arXiv 2506.08872
EEG Electroencephalography，腦電圖 ＝ 在頭皮貼電極量腦波
它量的不是你聰不聰明，是大腦不同區域之間，有沒有在互相搭話。
第四輪：把工具對調
→ 先自己想過的人，
之後用 AI 會用得更好。
"Cognitive activity scaled down in relation to external tool use."
★ "LLM users struggled to accurately quote their own work."
有一個實際的實驗，是 MIT Media Lab 做的。他們找了 54 個人來寫作文，分成三組：
一組完全靠自己、一組可以用搜尋引擎、一組用 ChatGPT。寫的時候每個人頭上都戴著腦波儀。
腦波儀全名叫 Electroencephalography，中文是腦電圖，簡單講就是在頭皮上貼電極量腦波。
它量的不是你聰不聰明，是你大腦不同區域之間，有沒有在互相搭話。
結果是：完全靠自己那組，腦區之間的連結最強、範圍最廣；用搜尋引擎的中等；用 ChatGPT 的最弱。
論文的原話是「認知活動隨著外部工具的使用而遞減」。
但我覺得最有殺傷力的不是這個，是這一句——用 AI 寫的人，連自己剛寫完的文章都引用不出來。
還有一個第四輪，他們把工具對調。原本用 AI 的改成完全靠自己，連結掉下來、呈現「參與不足」；
原本靠自己的改成用 AI，記憶回想反而更好、前額葉那些區域是活化的。
換句話說——先自己想過的人，之後用 AI 會用得更好。
這句對我們很重要，因為它不是叫你別用 AI，是說順序不能反。
查證紅線：只能講這一版。不要講「大腦物理性地停止工作」「省電模式」（柯仁傑的戲劇化轉述，論文沒有）。
不要講「5 所大學」「SAT 式作文」（論文摘要沒有）。被抓包代價最高。
第四輪只有 18 人完成（前三輪 54 人）。被追問樣本時要主動講，別假裝是同一個 n。
證據二 ｜ 長期・結構
倫敦計程車司機的海馬迴
倫敦的計程車執照叫 "The Knowledge" — 要把整座城市背進腦子裡，
約兩萬多條街道，一般要考三到四年。 ｜ 海馬迴 ＝ 負責空間記憶與記憶形成的腦區
Maguire et al., PNAS 2000
計程車司機的「後側海馬迴」顯著較大
★ 而且年資越久，差異越大
劑量反應 — 若只是「本來海馬迴就大的人才去開」，
就不會有這個關係
Maguire, Woollett & Spiers, Hippocampus 2006
對照組：公車司機
一樣天天在倫敦開車 ・ 一樣的交通壓力 ・ 一樣的職業型態
唯一差別：公車跑固定路線
→ 差異消失。長出海馬迴的不是「開車」，
是「不斷更新腦中的地圖」這件事本身
你外包出去的那些事，
就是會讓你大腦進步的那些事情。
第二個實驗更狠，因為它量的不是連結強弱，是大腦結構真的有沒有長出來。
倫敦的計程車執照很特別，它叫 The Knowledge——你要把整座倫敦背進腦子裡，
兩萬多條街道，一般人要考三到四年才過。
研究發現，這些司機負責空間記憶的那個腦區、叫海馬迴，後側的部分明顯比一般人大。
而且關鍵在這裡：開越久的，差越多。這叫劑量反應——
如果只是「海馬迴本來就大的人才會去開計程車」，就不會有這個關係。
六年後他們又做了一次，這次拿公車司機當對照組。
一樣天天在倫敦開車、一樣塞車、一樣的職業型態，唯一的差別是公車跑固定路線。
結果差異就沒了。所以長出海馬迴的不是「開車」這件事，是「不斷更新腦中的地圖」這件事。
對我們的意思是——你外包出去的那些事，就是會讓你大腦進步的那些事情。
The Knowledge 的數字（兩萬多條街、考三到四年）是背景通用知識，不是這兩篇論文的數據。
被追問就說「大約」，不要講得像論文寫的。兩篇論文的結論本身（後側海馬迴較大、年資正相關、公車司機對照）都已查證。
證據三 ｜ 文明・隱喻
兩萬多艘飛船降臨，走下來二十億個衰老的「上帝」
—— 他們是在地球播下生命的那個文明
他們為什麼衰老？「機器搖籃時代」
機器完全獨立於創造者運作
能自我維修、自我更新、自我擴展
提供一切物質與精神所需
→ 遺忘了技術與科學，失去創新與動力
只會用，不會懂。
★ 而他們留給人類的報酬是——
一部記載了他們文明全部知識的典籍。
人類看不懂。
看得懂的那些，也做不出來
（需要的材料在幾光年外）
知識交到你手上，
不等於你有能力。
AI 的進步，不等於你的進步。
★ 先講出處，這句別省——它是全場最有說服力的一個瞬間。
「這篇小說我沒讀過。我是聽一個 YouTuber 講的，腦動烏托邦的小烏。
所以我對它的理解，本身就是二手的。你看，我自己就欠著理解債。」
第三個不是實驗，是一篇小說。劉慈欣的《贍養上帝》。
故事是：兩萬多艘飛船降臨地球，走下來二十億個非常衰老的老人。
他們自稱上帝——而且是真的，他們就是在地球上播下生命的那個文明。
現在他們老了，要人類家庭把他們接回去養。
那他們為什麼會衰老？小說裡有個說法叫「機器搖籃時代」——
他們的機器完全獨立於創造者運作，能自我維修、自我更新、自我擴展，
物質跟精神所需的一切都由機器提供。一代一代過去，他們就遺忘了技術跟科學，
變得懶惰、空虛，失去創新的動力。會用，但不懂。
★ 而最狠的是這裡：他們為了報答人類的贍養，留下一部記載了整個文明全部知識的典籍。
結果人類看不懂。看得懂的那部分，也做不出來——因為需要的材料在幾光年外。
知識交到你手上，不等於你有能力。
我覺得這篇小說講的，就是我們前面講的理解債——只是尺度從一個團隊，放大到一整個文明。
而這就是我想說的——AI 的進步，不等於你的進步。
情節已於 2026-07-19 查證（維基 Taking Care of God／百度百科／百科知識），
但來源是二手百科與評論，不是小說原文 → 所以上面那句「我沒讀過，是聽來的」要保留，不要省。
這是文學借喻不是實證。
連自己剛寫完的東西
都記不住——
這就是認知負債的長相。
（停一下，讓它沉一下）如果你剛剛心裡有「欸我好像有過」，那不是錯覺，是有數據的。
S01 ｜ 李智樺 Ruddy
理解債 Understanding Debt
＝ 當系統的生產速度，超過人類形成理解的速度
Context Recovery 過慢
回到一段程式碼，要花很久才想起來它在幹嘛
過度依賴特定人或 AI
少了某個人（或某個工具）就動不了
Review 形式化
看過、approve、但其實沒真的看懂
Ruddy 老師給了一個名字叫「理解債」，定義是：系統的生產速度超過人形成理解的速度。
他列了五個症狀，我覺得這是今天可以拿來檢視自己的狀態——現在花三十秒，自己數你們中幾條。
★ 這裡真的停三十秒，可以點名問一兩個人數幾條。
中三條以上，這不是你個人的問題，是團隊已經在欠債了。
什麼才算「理解」？
被誤認為理解（其實只是熟悉）
測試有過 ／ 能跑起來 ／ PR merge
看過 code ／ 文件存在
AI 解釋過 ／ ChatGPT 說沒問題
真正的理解
能預測、能解釋、能推論
能驗證、能辨識異常、能知道限制
「如果你無法預測系統在變化下的反應，你其實沒有真正理解它。」
但先講清楚：這不是叫你別用 AI。
Brynjolfsson, Li & Raymond, Quarterly Journal of Economics 2025：5,172 位客服人員，每小時解決案件數 平均 +15%，經驗越少的人速度與品質都提升。
AI 真的有用。問題從來不是「用不用」，是「放大了什麼」。
Ruddy 還分了一件事：什麼叫「以為自己懂」，什麼叫真的懂。
測試過了、能跑、PR merge 了——這些都只是熟悉。真正的理解是你能預測它會怎麼壞。
★ 特別記一下「能辨識異常」，等一下最後一段我會回來拿它。
然後我要先講清楚立場：我今天不是要唱衰 AI。這篇《經濟學季刊》的研究，五千多個客服，這個數字是「每小時解決的客服案件數」——平均多 15%，而且經驗越少的人提升越多，速度跟品質都變好；資深組幾乎沒差。AI 是真的有用，它把新手拉到接近老手。
所以問題不是用不用，是它放大了什麼。
查證紅線：Brynjolfsson 那篇對象是「客服人員」，不是工程師。講成「一般勞動力的普遍發現」可以，不要說成工程師實證。數值以 QJE 2025 正式版為準：樣本 5,172 人、平均 +15%（issues resolved per hour）。+14% 與新手 +34% 是 2023 NBER w31161 working paper 的舊數字，不要用。（伏筆：「能辨識異常」在 P40 回收。）
那到底哪些交給 AI？
你知道
你不知道
講得出來
（可寫下）
已知的已知
能寫進 prompt／測試／spec
例：API 回傳 JSON
→ AI 加速，你能驗證
已知的未知
知道有問題、還沒答案
例：goroutine leak 在哪
→ AI 幫最多：探索、列假設、寫壓測
講不出來
（沒寫下）
隱性知識 ★
團隊都知道，但沒人寫下來
例：業主 API 潛規則
→ AI 最容易踩雷：「語法對、業務錯」
完全沒意識到的未知
AI 的雙面刃
幻覺會製造新的未知
→ 但對抗性審查能把它拉回右上格
講完認知負債後，下一個自然的問題是：那到底哪些事能交給 AI？這張圖是我拿來當今天的地圖用的。
兩個軸：你知不知道，以及你講不講得出來。
右上這格——已知的未知：你知道有問題、但還沒有答案。這是 AI 最能幫上忙的地方，因為你講得出要它去查什麼。
左下這格最容易騙過你：團隊都知道但沒人寫下來的東西，AI 在這裡最容易寫出「語法對、業務錯」的東西。
右下這格是完全沒意識到的未知，AI 的幻覺會在這裡製造新的坑。但它也是雙面刃——關鍵在「對抗性審查」：你反過來叫 AI 挑自己的毛病，「這個方案會怎麼壞？你假設了哪些前提？」，逼它把你沒想到的失敗模式攤出來。這一步就是把右下那格「你沒意識到的未知」，拉回右上那格「你講得出、也驗證得了的問題」。
接下來每一段，
我會回來點亮這張圖的一格。
這張圖等一下會出現四次。每講完一段，我會回來標一格。
02
兩個講者，
兩個瓶頸
同一場研討會，兩個人給了完全不同的答案。
S03 柯仁傑 ｜ 瓶頸在「驗證」
講題：當 AI 帶來思考外包 x 認知負債，要如何不讓 AI 奴役你
+91%
PR review 時間增加（即使 merge 數變多）
來源：75% — Pichai, Cloud Next 2026/04｜+91% — Faros AI 2025（10,000+ 開發者遙測）｜−19% — METR RCT（n=16，熟悉的 codebase） 另：吞吐量與不穩定性同時上升 — DORA 2025 報告（2026/03）
問題已經從「寫」轉移到「驗證」。
而且，多請 reviewer 解決不了。
【這場】S03 柯仁傑「當 AI 帶來思考外包 x 認知負債」——主軸是 MIT EEG 實驗＋認知外包，triage 分級（可外包 AI／要人 review／要人 write）。就是第一章那場。
柯仁傑的答案是：瓶頸在驗證。他給的數字很兇——Google 新程式碼 75% 是 AI 生成的，
PR review 時間增加 91%，而開發者「感覺」變快，客觀上卻慢了 19%。
這三個數字來自三個不同的地方：75% 是 Google CEO 講的，91% 是 Faros AI 的遙測，
19% 是 METR 的對照試驗——只有十六個人，而且是在他們自己熟的 codebase 上。
他最後那句我覺得最關鍵：多請幾個 reviewer 是解決不了的，因為這不是人力問題。
2026-07-24 已查證：三個數字分屬三個來源，不是同一份 DORA 報告。
DORA 那份的正式名稱是《2025 State of AI-assisted Software Development》（2026/03 發布），
它只支持「吞吐量與不穩定性同時上升」，並未提供 review 時間或開發者變慢的數值。
被追問 −19% 時務必主動說出 n=16 與「熟悉的 codebase」這兩個限制。
S04 Charles ｜ 瓶頸在「協作與權限」
講題：以 kagent × A2A 構築自主協作的 Agentic K8s
單一 Super Agent 是死路
→ 拆成專業 Agent：專業分工、減少幻覺、最小權限
卡住的地方不在「寫」也不在「驗證」，
在怎麼分工、怎麼切權限。
【這場】S04 Charles（蕭兆洋，MaiCoin SRE）「以 kagent × A2A 構築自主協作的 Agentic K8s」——多 Agent 專業分工＋最小權限，Demo 讓 AI 自動把 Istio 流量降到 0% 止血。
但同一場研討會，Charles 反而認為瓶頸在協作跟權限。
他的論證是：單一一個什麼都管的 Super Agent 一定會死——會幻覺、會健忘、權限還大到嚇人。
所以要拆成一群專家 Agent。對他來說，瓶頸不在寫也不在驗證，在怎麼分工、怎麼切權限。
現場提問 ／ 01
你們的瓶頸在哪？
兩個講者、兩個答案。所以我想知道我們自己是哪一種。
覺得瓶頸在驗證的舉手……好。覺得在協作跟權限的舉手。
【票數分散】看，連這一個房間都喬不攏——先記住這件事，下一頁我告訴你為什麼。
【票數集中】這房間有共識。那我要追問一句：你們量過嗎？你們的 lead time 到底卡在 review，還是卡在等別組、等權限？還是這其實只是體感？就像柯仁傑那三個數字——瓶頸是可以量的，不是用猜的。
【沒人舉手】沒人舉手其實就是答案——沒關係，我們後面娓娓道來，大家再慢慢體會。（直接轉場下一章）
他們沒有誰對誰錯
瓶頸的位置取決於組織成熟度。
先問自己是哪一種，再決定 AI 投哪裡。
而知道自己缺什麼——那也是「你已經有的東西」的一部分。
我的解讀是：他們沒有誰對誰錯，他們站在不同的成熟度上。（承接剛剛的投票）如果票投得很散，那不是壞事——它正好證明瓶頸長在組織裡，不長在技術裡；如果是技術問題，答案應該只有一個。需求跟驗證都清楚的組織，瓶頸才會浮到協作。
所以 AI 該投哪，答案在你自己身上——而知道自己缺什麼，也是「你已經有的東西」的一部分。
（回到地圖）這一段點亮的是這兩格：你知道要問什麼的地方，AI 幫得上最多。
03
你要 AI 有手，
還是只要 AI 有眼睛？
這一章是今天的重點。兩種完全相反的做法，而且來自同一家公司。
S05 翁傳翔 ｜ 只給眼睛
講題：當 AI Agent 接管你的 On-Call
為什麼這套維運 AI 敢上 production
1
給 AI 一張地圖 — 輸入正確
system_architecture.yaml：每台主機／IP／SSH／K8s context／Prometheus label
沒地圖：AI 猜 cluster 名稱 → 查無資料重來 ｜ 有地圖：一次命中
↓
2
安全長在工具裡 — 動作受限
SQL 只准 SELECT／SHOW（自動加 LIMIT）｜ kubectl 只准 get／describe／logs
修改型操作一律封鎖｜政策用 YAML 宣告
↓
3
診斷不是終點，是協作的起點 — 人機協作
AI 初判 → 人質疑、補證據 → 對話中 AI 即時再下工具 → 修正
（不是按「核准／拒絕」，是可以多輪追問）
先看第一種答案。翁傳翔那場「當 AI Agent 接管你的 On-Call」，他在台泥儲能，他的 AI 會做 on-call 診斷，但不碰 production。
他敢上線的原因有三層。第一，給 AI 一張地圖——把每台主機、每個 label 寫成 yaml 餵進去，他有一句話我很喜歡：「如何消除 AI 幻覺？因為它有地圖。」
第二，安全不是用 prompt 拜託 AI 乖乖聽話，而是長在工具裡：SQL 只准 SELECT，kubectl 只准 get。
第三，他的 human-in-the-loop 不是按核准鍵，是可以跟 AI 吵架、補證據、要它換角度再查。
S05 翁傳翔 ｜ 他踩過的坑
某案場網路不穩，告警一下斷一下上 → AI 一直排查 → 當月成本爆掉
「讓 AI 省著用，是工程問題。」
① 規則先擋，AI 後上
每日巡檢純規則、零 LLM；惡化或跨門檻才升級 AI
② 回合上限
協調者／子代理各設 15–20 回合封頂
④ 集中管控用量
走 LiteLLM Proxy，key 與花費可監看
那麼，他也是有踩到坑的。有個案場網路不穩，告警一直閃，AI 就一直排查，當月帳單直接爆掉。
（這個坑我想我們自己 SRE 那邊好像也遇過類似的，主管的信用卡差點刷爆。所以這個痛，他懂。）
那講者他的結論是什麼？是「讓 AI 省著用，是工程問題」——第一條我覺得對我們最實用：規則先擋，AI 後上。
每日巡檢用純規則、零 LLM，惡化了才升級叫 AI。
排練超時的話，這頁可以砍。
S04 Charles ｜ 給手
講題：以 kagent × A2A 構築自主協作的 Agentic K8s
kagent × A2A — 從「看監控」到「動手改流量」
Demo 流程
根因定位 → 快速止血 → 驗證修復 → 開 Fix PR → 寫 RCA
止血動作 ＝ 把 Istio canary 流量降到 0%
91.3%
Multi-Agent 準確度
（單一 Agent 39.8%）
「Instead of writing scripts and runbooks,
define INTENT.」
第二種答案完全相反。Charles 那場「以 kagent × A2A 構築自主協作的 Agentic K8s」，他的 kagent 會直接動手。
Demo 裡 AI 自己定位根因、自己把 Istio 流量降到 0% 止血、驗證完還幫你開 PR、寫 RCA。
他的哲學是：不要再寫 runbook（維運的「標準作業程序書」）了，直接定義意圖。
S04 Charles ｜ 灰色故障 Gray Failure
「告警沒叫，不代表沒事。」
Demo：payment error rate 0% → 3%
沒破 5% 閾值，但已經在流血
他還講了一個概念我想先埋在這裡，等一下最後會用到——灰色故障。
錯誤率從 0% 爬到 3%，閾值設 5%，所以告警不會響。但它已經在流血了。
「告警沒叫，不代表沒事。」先記住這句。
★ 這是伏筆②，最後一章（P39–P40）會回收。
同一家公司（MaiCoin）・同一場研討會
蕭兆洋 Charles
SRE
AI 自動改 production 流量止血
蔡宗城 smalltown
Infra Director（他的主管）
AI-in-control ＝ Uncontrolled Risk
「把 AI 放進流程，
不代表把流程與權限交給 AI」
誰對？
然後我看到一件很有意思的事。這兩場是同一家公司的人講的，而且是主管跟 Member。
Member 在台上 Demo AI 自動改 production 流量；他的主管在另一場說，AI-in-control 等於不受控的風險。
我覺得這不是誰對誰錯，這是「工程師想要的」跟「要負責的人能接受的」之間，永恆的張力。
★ 而我要老實說——我站在 smalltown 的位置。但我的團隊裡有 Charles。
現場提問 ／ 02
你要 AI 有手，
還是只要 AI 有眼睛？
所以我想問問你們，「你要 AI 有手，還是只要 AI 有眼睛？」
【「有手」多】工程師的直覺都是這樣。那我問一句：手伸下去出事的時候，誰去收拾？
【「有眼睛」多】保守派。那我反問一句：眼睛不夠快，跟沒有眼睛，差在哪？
【沒人舉手】不好選對吧？因為這題的答案不取決於你信不信 AI，取決於你出錯的時候，誰要負責收拾。
機率部門 - 自動化風險評估工作流 ／ 新遊戲研發
Low
隔離/無狀態
Medium
High
影響廣/有狀態
High易復原
STEP 1數值模型打底與 AI 生成高度自動化
STEP 2RTP 驗證與分析報告跑模擬器，純分析無變更
無適用步驟
無適用步驟
Medium部分可逆
無適用步驟
STEP 4建立 AI Agent 與核心框架純人工嚴格開發
STEP 5LUT 重構牽動底層運作
Low難以復原
無適用步驟
無適用步驟
Blast Radius ／ Statefulness（影響範圍・狀態性）
這張不是從研討會抄回來的。
是機率 Leader 自己畫的。
看一個規律：
■ 綠色（高度自動化）
＝ 生報告、跑模擬、產草稿
■ 紅色（純人工）
＝ 碰體感微調、碰底層架構、碰上線
機率組給 AI 的是
眼睛，不是手。
講到這裡我要放一張不是從研討會帶回來的東西。這是機率組自己畫的，把 smalltown 那張矩陣套到他們的工作流程上。這一張是新遊戲研發。
我們來看一下，是不是有發現一個規律？綠色的、高度自動化的，全部都是生報告、跑模擬、產草稿；
碰到體感微調、碰到底層架構、碰到上線，就是紅色純人工。
這裡有一個細節我覺得很值得看：綠色那格裡面就有 RTP——RTP 驗證與分析報告，因為它純分析、不改任何東西。所以不是碰到 RTP 就紅，是改不改得回來。
那麼，套用前面幾張投影片提到的眼睛跟手就是——機率組給 AI 的是眼睛，不是手。 那麼，我覺得這題，大家回去後，團隊內可以聊一下各自的想法，並且先有一個共識，屬於團隊內的默契。
所以「有手還是有眼睛」其實不是技術選擇，是你願意把「出事誰收拾」這件事交給誰。
（回到地圖）這一段點亮右下格：自動止血本身，也可能製造新的未知。
04
AI 放大不了
你沒有的東西
前面那題的答案，其實都指向同一件事——AI 放大不了你本來就沒有的東西。
S06 ｜ 鍾筑安 Judy
講題：從 Vibe Coding 到 SDD：AI 時代的小團隊開發流程實驗
「在歪的地基上蓋樓，蓋越快，倒越快。」
01
Vibe 是起點，不是終點
需求模糊的時候用 Vibe 產出畫面、對齊方向——但確認後要接 SDD，讓它活下去。
02
AI 把實作變快了，真正的瓶頸是需求
實作不是瓶頸，需求才是。需求歪了，做越快歪越快。
03
模式可以複製，但不一定成功
先搞清楚你的團隊組成及適合的路徑，再動手。
她整場其實就收斂成三件事。
這位講者一開始先提到了 Vibe 跟 SDD 之間的關係，強調：Vibe 不是消失，而是 AI 開發的起始點。它放大了 PM 的實作能力——做出一個 prototype 可以把需求轉換成實際給工程師的畫面。工程師再透過 prototype + 規格轉換成 SDD，把實際功能完成。
接著她談到因為開發變快了，且挑選的團隊人員也有關聯，導致需求與規格失焦，因此帶入到第二個重點：實作不是瓶頸，需求才是。需求歪了，做越快歪越快。
最後，她也提醒我們，先搞清楚各自的團隊樣貌，再開始動手，這也提到第三個重點：先搞清楚各自團隊的工作流，再開始規劃要怎麼在團隊運用 AI。
S09 ｜ 吳明倫 Allen Wu（玉山銀行）
講題：CI/CD 也需要自己的 Observability：Centralized Pipeline 的觀察與實踐
Raw data
雜亂的 log、時間戳、狀態碼
AI 一臉困惑
Evidence ／ Outcome ／ Rule ／ Feedback
收成一箱 Review Material
AI 看懂了
「成熟的 Decision System，才有機會被 AI 放大。」
Judy 從地基講——AI 放大不了你沒有的東西，在第二天「CI/CD 也需要自己的 Observability」那場的講者有把這件事講得更完整。
丟一坨 raw log 給 AI，它一臉困惑。那如果你把它整理成證據、結果、規則、回饋，它就看懂了。
地基跟決策系統，講的是同一件事。
他從 CI/CD 的可觀測性切入，然後結尾點出「成熟的 Decision System，才有機會被 AI 放大。」
現場提問 ／ 03
他的 Review Boundary，是靠團隊共識拉出來的。
我們的規模下，誰是那個「團隊」？
如果最後是我一個人拍板，
那是共識還是命令？
隱性知識顯性化 ＝ 最高槓桿的工作
S01 ADR 才是產物 ・ S04 Doc2Vec 儲思盆 ・ S06 規格即資產
S07 餵得進去 vs 餵不進去 ・ S09 把工作流講清楚
→ 五場證據，全部落在同一格。
他那套介入門檻是團隊共識拉出來的。所以我想問一個我自己也在想的問題——
我們的規模下，誰是那個「團隊」？如果最後是我一個人拍板，那是共識還是命令？
【有人回應】命令會被陽奉陰違，所以門檻必須是大家一起訂的。
【沒人回應】沒人想回答老闆這題也很合理。那我換個問法——你們現在遇到不合理的門檻，會直接說嗎？
（回到地圖）今天提到的五場，最後全部落在同一格：左下這格，是團隊都知道、但沒人寫下來的東西——隱性知識。
AI 只放大得了你餵得進去的東西，而隱性知識正是餵不進去的那塊，所以把它寫下來，是槓桿最高的工作。
這五場，剛好是五種寫下來的方法：S01 用 ADR 寫下決策的為什麼、S04 用儲思盆把踩坑史變成可檢索資產、S06 把需求寫成規格、S07 他那場我抓的重點是提醒你餵不進去的要想辦法餵進去、S09 把工作流整理成 AI 看得懂的規則。同一件事，五個切入點。
05
那，你該做什麼？
我們前面提到了很多別人的做法，都很值得深思；那回到我們自身，就職涯規劃或角色定位，在下一頁，我們一起檢視一次。
請對號入座：你是哪一階？
初階學習者心態
別交給 AI：核心演算法理解、系統 debug 的「學習」
益處 coding／debug 加速 ｜ 風險 過度依賴、技能形成受損
別讓 AI 搶走
你學 debug 的機會
中階驗證者心態
別交給 AI：架構決策、安全邊界判斷
益處 整合 AI 產出、提升品質 ｜ 風險 驗證負擔、整合複雜度
整合與判斷，
是你的價值
主管／架構師治理者
別交給 AI：人才評估、技術方向、責任邊界
益處 架構決策輔助、知識延伸 ｜ 風險 治理複雜性、責任歸屬
方向與責任
我把它分三階，大家可以先想一下，現在的你會在哪一階？
★ 停一下。
然後我們把目光拉到每一階的最後一句。
初階，AI 對你幫助最大，但風險也最大——別讓 AI 搶走你學 debug 的機會。
那個學習的過程很痛，但我想，其實就跟當年我們用 Stack Overflow 以及看各種大神的部落格是同樣的道理！我們有了這個過程，就會長出屬於我們自己的能力（真正屬於我們自己的）——就像前面提到的倫敦計程車司機，痛的那段才是海馬迴變大的那段。
中階，你的價值從「寫得出來」變成「看得出對不對」。
舉一個很常見的例子：實作的人用 AI 生了一堆東西出來，結果跟單子上要的根本不是同一件事。AI 不知道這張單子背後那些沒被寫進去的前提，但中階的人知道——因為他做過。那個「他做過」，就是我前面講的隱性知識，也就是餵不進去的那一塊。
主管跟架構師，你們清單上的第一項是人才評估——而我要老實說，這一項我自己正在重學。
以前我看 code review 大概就知道一個人的水準，那個手感我現在已經不敢信了，因為產出被 AI 拉平了。我後來改成問三件事：這裡為什麼這樣設計、好處是什麼？出事的時候你會怎麼查？還有，這個系統長什麼樣子，你講不講得出來？
因為 AI 可以幫他把東西寫出來，但答不出為什麼的人，那個能力不是他的。
至於方向跟責任，那是你們最後不能外包的——這兩件事外包出去，出事沒有人接得住。
而這三階不是切開的，是疊上去的：你要先痛過，才驗證得了；驗證過，才治理得了。AI 讓你可以跳過第一階，但跳過的人，第二階是站不住的。
機率組已經寫下他們的清單了
「凡是碰體感微調、底層架構大改、新遊戲上線
—— 純人工。」
那你們的「別交給 AI」清單，
是什麼？為什麼？
剛剛那三階，我每一階都給了一行「別交給 AI」。
在之前跟機率組聊解決產能瓶頸時，他們自己也有提到——
★ 回到 P27 那張矩陣。
黃色、紅色的格子「凡是碰遊戲體感、微調、底層架構大改、新遊戲上線，純人工」，那這就是他們的「別交給 AI」清單。
所以我想問的是：你們的「別交給 AI」清單是什麼？為什麼？
這一題不用現在回答，但我希望你走出這個空間的時候，心裡要有答案，如果沒有也沒關係，各組可以在每一週自己的組內會議，聊聊看這個議題。
① 台大 2025 碩論《生成式AI導入下軟體開發專案管理與工程師職能重塑：某軟體公司個案研究》
質性研究、單一公司、n=8（初階 ×2、資深 ×2、技術領導 ×2、研發總監／副總各 1）
→ 個案研究。它分四層，我併成三層。
② Brynjolfsson, Li & Raymond, Quarterly Journal of Economics 2025
5,172 位客服（每小時解決案件數）：平均 +15%；新手速度與品質都提升，最資深者速度小增、品質「小降」
→ 對象是客服，當「一般勞動力的普遍發現」引用
③ Lee et al., CHI 2025（Microsoft Research + CMU）
319 位知識工作者、936 個真實使用情境。對 AI 信心越高 → 批判思考越少；對自己能力信心越高 → 越多。
轉移是三組平行的：蒐集資訊→查證、解問題→整合 AI 產出、動手做→監督
→ 按認知活動分，不是按職階
這三份研究是我朋友分享給我的，裡面提到的一些素材，我跟他聊完之後，歸納成三種不同定位的角色各自需要思考的事情。
再說一次：
AI 真的有用。
今天整場講的是「它放大了什麼」，
不是「要不要用」。
那，AI 再變強呢？
我想需要再強調一次，免得被誤會成討厭 AI 的人。
AI 是真的有用，數據跟各位大神們的分享就擺在各大社群媒體上。
我今天從頭到尾都是想表達一件事就是——它放大的是什麼。
還有一件事我也提一下，我想有部分的人也會有疑問：AI 還在變強，如果說，此時此刻，還需要精雕細琢的那些事、還需要人工審核的那些事，明年還能適用嗎？
這題我沒有標準答案。我建議各位包括我自己，都需要每隔一段時間就回頭問自己一次。
但話題拉回來，模型再強，只要今天工作的還是人類，那麼出事的時候要出來面對的還是我們。
這條線不會因為模型變強而移動。
（或許等到哪一天 AI 已經強大到，讓我們不需要工作了，那就可以不用再問了吧！但我相信到時候就會在討論另一種話題了，哈哈）
最後，一個我自己還沒想清楚的問題：
我們說某件事「可以復原」，
是不是預設了 —— 我們會知道它壞了？
（這不是結論）
最後我想丟一個我自己還沒想清楚的問題。這不是結論，是我還在想的東西。
我們很習慣說某件事「可以復原」、「改回去就好」。但這句話其實藏了一個前提——我們會知道它壞了。
那如果，我們不知道呢？
回到機率組那張表
Low
Medium
High
High易復原
—
—
Medium部分可逆
—
Low難以復原
—
—
這張表的縱軸是「可逆性」——
而它被當成一個靜態屬性：
某件事天生易復原，或天生難復原。
smalltown 敢這樣用，是因為他的 rollback 是
kubectl rollout undo
—— 單方面就做得完。
不用問任何人，不會被拒絕，不會失敗。
我們回到機率組那張表。我覺得畫得很好，但它的縱軸讓我卡住。
縱軸是「可逆性」，而可逆性在這裡被當成一個靜態的屬性——某件事天生好復原，或天生難復原。
smalltown 敢這樣用是有原因的：他的 rollback 是 kubectl rollout undo，
他一個人、一個指令就做完了，不用問任何人，不會被拒絕。
對他來說，可逆性確實可以是一個屬性，因為復原這件事完全握在他手上。
機率除錯與客訴處理
現場提問 ／ 04
剛剛那張表上標成「易復原」的格子，如果我們是等客訴才知道出事 ——
它們還算不算易復原？
在機率跟我交流的文件裡，有提到「機率除錯與客訴處理」，Step 1 是收到案件才跑 RTP 分析。
也就是說——至少在這份文件裡，偵測是從客訴開始的。
那我就有個問題了：剛剛那張表上標成「易復原」的格子，如果我們是等客訴才知道出事，它們還算不算易復原？
【有人補充別的偵測管道】太好了，那這一題你們已經有答案了——那就把它寫進表裡。我要的就是這個。
【沒人補充】不追問，直接下一頁。
請各組自己想一想
請各組多想一個問題：
出事的話，我們怎麼發現？多久會發現？
我猜這一題不好想。
如果想不出來，那就是今天最重要的收穫 ——
因為前面兩題的答案，其實都建立在這一題上面。
今天都提到機率組的。那後端、SRE、game-client、前端呢？
想請你們現在花三十秒，在心裡想一下你們那一組的版本。
而且比機率組多想一個：出事的話，我們怎麼發現？多久會發現？
★ 這裡真的停三十秒。
我猜這一題不好想。但如果想不出來，那反而是今天最重要的收穫——
因為「可不可逆」這件事，本來就預設了你來得及回頭。
你不知道多久會發現，就等於不知道來不來得及；那前面兩題你填的答案，其實都預設了同一件事：出事的時候你會及時知道。
而為什麼我們這一行特別要問這一題？因為我們的派彩是一次性入袋，要撤銷得發 rollback 給業主——那是一個「請求」，不是一個「指令」，而且它會衰減。
30 秒發現，大概率收得回；30 分鐘後發現，錢可能已經下了十局，或者提走了。
Ruddy 說真正的理解是「能辨識異常」——理解債欠越多，異常越沒人一眼看得出來，發現就越慢。
認知負債在別的行業，利息是維護成本；在我們這一行，利息可能是那筆收不回來的錢。
Charles 說「告警沒叫不代表沒事」——灰色故障在我們這裡，也不只是優雅的問題。
所以我懷疑我們該問的不是「這個變更可不可逆」，而是「出錯的話我多快會知道」。
但我手上沒有數字。我們現在多久發現？我到今天還答不出來。這就是我今天想留給大家的問題。
★ 上面這兩段分別回收 Ruddy「能辨識異常」與 Charles「告警沒叫不代表沒事」兩個伏筆。
措辭紅線：不要說「回去畫一張給我」「兩週內」「一起把它量出來」——
已定案不回收，這是現場思考練習，不是交辦。
我們看到的，是 AI 強大？還是使我們強大？
AI 只會放大你已經有的東西；
它給不了你理解，
也擔不起你的責任。
回到最開始那一題。我的答案是這樣——
AI 只會放大你已經有的東西；它給不了你理解，也擔不起你的責任。
「成熟的 Decision System 才有機會被 AI 放大」，而你沒有的東西，它放大不了。
「理解」，就是理解債；「責任」，就是三職階的最後一階。
謝謝大家。
參考資源（1／2） DevOpsDays Taipei 2026
官網 devopsdays.tw/2026 ｜ 議程表 devopsdays.tw/2026/agenda
S01 從多模型視角談與 AI 共智 — 李智樺 Ruddy
共筆 hackmd.io/@DevOpsDay/B1GcC7FZfg
書單：模型思維／共智時代／共同知識／心流／鳳凰專案
S02 devops 交給 skill + ai agent 一條龍（Workshop）— awoo
共筆 hackmd.io/@DevOpsDay/r1ELQFPzGx
ithome-devopsday-2026.pages.dev
github.com/qwedsazxc78/devops-ai-skill
S03 當 AI 帶來思考外包 x 認知負債 — 柯仁傑 David Ko
共筆 hackmd.io/@DevOpsDay/BJ49A7FWfx
簡報 slideshare.net/slideshow/ai-x-ai-cognitive-debt-in-genai-era/288242857
S04 以 kagent × A2A 構築 Agentic K8s — 蕭兆洋 Charles
charles-hsiao.com/talks/202606-devopsdays-taipei-2026-kagent-a2a
github.com/charles-hsiao/kagent-doc2vec-demo ｜ a2a-protocol.org
S05 當 AI Agent 接管你的 On-Call — 翁傳翔 Herb
簡報：本機 PDF（32p，無公開連結）
工具：pgvector／bge-base-zh-v1.5／LiteLLM Proxy
S06 從 Vibe Coding 到 SDD — 鍾筑安 Judy
簡報：本機 PDF（25p）
Threads @judych.builds
S07 不用擔心被 AI 裁員 — 蔡宗城 smalltown
共筆 hackmd.io/@DevOpsDay/HyncRXYbzl
簡報：本機 PDF（39p）
S08 告別 RCA 撰寫地獄 — 宋岡諺 Johnny Sung
共筆 hackmd.io/@DevOpsDay/rJ-jC7Kbfe
github.com/j796160836/devopsdays-fortune-telling-demo
S09 CI/CD 也需要自己的 Observability — 吳明倫 Allen Wu
共筆 hackmd.io/@DevOpsDay/HyvjCmYbGe
簡報：本機 PDF（47p）｜ OpenTelemetry CI/CD Semantic Convention
全部九場都列，包含今天沒有引用的 S08。
參考資源（2／2） 本場引用的研究
認知負債 ／ 理解債
Kosmyna et al., Your Brain on ChatGPT, MIT Media Lab — arXiv 2506.08872
Maguire et al., PNAS 2000 — DOI 10.1073/pnas.070039597
Maguire, Woollett & Spiers, Hippocampus 2006 — DOI 10.1002/hipo.20233
劉慈欣《贍養上帝》（文學借喻，非實證）
三職階 takeaway 的三角佐證
台大 2025 碩論《生成式AI導入下軟體開發專案管理與工程師職能重塑：某軟體公司個案研究》— doi:10.6342/NTU202501096（個案研究 n=8）
Brynjolfsson, Li & Raymond, Generative AI at Work — Quarterly Journal of Economics 2025 / NBER w31161 / arXiv 2304.11771（對象為客服 agent）
Lee et al., The Impact of Generative AI on Critical Thinking, CHI 2025 — DOI 10.1145/3706598.3713778
其他
75% AI code — Pichai, Cloud Next 2026/04｜+91% review — Faros AI 2025｜慢 19% — METR RCT（n=16）｜吞吐／不穩定同升 — DORA 2025 報告
DevEx — ACM Queue 2023 ｜ SPACE framework ｜ Team Topologies ｜ 內部素材：機率部門自動化風險評估工作流（機率 Leader 產出）
最後一頁。DORA 那三個數字記得標查證狀態。