影片 13:18 ／ 56:39 · 本段共 2 張截圖 · ▶ 從這裡開始看
規範寫得越長，被遵守的機率越低。
「我早期的 prompt 是：這是 TDD 的做法、這是 Clean Code 的做法……最後變成一份五到十頁的文件。我甚至想過把整本書都餵給它。」
「但 agents 看待這些規則的方式，很像《神鬼奇航》裡的說法：比較像指引。就是「可能」會遵守。」
- 這是架構問題，不是 prompt 技巧問題。人類團隊靠 review 和 CI 讓規則生效，不是靠把規範貼在牆上 —— agent 同理，把 guideline 變成 gate。
- 「五到十頁的規範」本身就是壞味道。同樣的內容拆成「進場三條鐵律」＋「動作發生時才注入的局部規則」，命中率高得多。
影片 13:55 ／ 56:39 · ▶ 從這裡開始看
位置是稀缺資源：頭尾是精華地段，中間是垃圾掩埋場。
「有個現象叫做 lost in the middle。context window 越堆越長，最開頭和最後面的內容會比中間更受重視。」
「你一開始說得太長，前面的話就會被擠到中間。開頭那三句可能還有優先權，但第 50 句和第 80 句就沒了。」
- 最重要的三條放最前、驗收條件放最後 —— 今天就能改的排版策略。
- 這解釋了為什麼分層 skill 會贏過一份巨大的 system prompt：不是模型變聰明，是規則在對的時機才出現。
影片 15:16 ／ 56:39 · ▶ 從這裡開始看
該追求的不是更大的 context window，是更小的進場 prompt。
「我把 context window 分成智慧區和笨區（Dex Hardy 的說法）。前段、像前 15 萬 token 還滿聰明的，越往後 attention 就越吃力，被稀釋得很嚴重。」
「就像每個 token 都在越來越擁擠的房間裡大喊。雜訊太多，根本聽不見訊號。」
- Bob 的結論很直接：「agent 的關鍵，就是把最初的 prompt 縮到最精簡。」
- 推論：context 不是均質的容量，是有貧富差距的地段。塞好塞滿＝把自己的重點搬去笨區。
影片 20:37 ／ 56:39 · ▶ 從這裡開始看
agent 之間要交接，就得有一份可執行的規格當契約。
「我會先跑一個 specifier，把人寫的文件轉成 Gherkin 和 QA 流程。」
「Gherkin 就是 Given、When、Then 那套，是高階驗收測試；QA 流程是系統測試，從使用者角度透過 UI 操作整個系統，證明系統能正常運作。」
- Given/When/Then 是老技術，但在 agent 流水線上變成剛需：它同時是需求、是測試、是驗收。
- 驗收要站在使用者那一側，不是站在實作那一側 —— 否則 agent 只會證明它自己寫的東西符合它自己的假設。
影片 21:45 ／ 56:39 · ▶ 從這裡開始看
不要用一個萬能 agent。把寫、清、逼、驗拆成有明確交接物的角色。
「程式設計師寫單元測試和實作 → 交給清理者跑 crap analysis 和 code review，清掉爛攤子（做到那時肯定已經亂成一團）→ 交給強化者。」
「強化者負責跑突變測試，而且絕不留情。做到 100% 覆蓋率，每個等號、每個小於號都會測。最後交給 QA agent，把 QA 文件轉成可執行腳本。」
- 每個角色的職責都非常窄 —— 呼應前面的「短 prompt」：角色越窄，規則越少，遵守率越高。
- 「清理者假設前面一定留了爛攤子」是很成熟的預設值。流程要假設上游會出錯，而不是期待它不出錯。
影片 29:57 ／ 56:39 · ▶ 從這裡開始看
好架構的回報變高了 —— 介面窄，agent 讀得懂，也不需要讀太多。
「（Ousterhout 的）淺層模組：介面很大、裡面藏的東西不多。深層模組：介面很小、裡面藏了大量資訊。這對模型很有利，因為它們只要看介面，不用理解實作細節。」
「模型會看結構，這讓它們不必讀底下的程式碼 —— 這既是風險也是優勢。它們也會看測試，透過測試了解系統在做什麼。」
- 「既是風險也是優勢」：介面漂亮但實作騙人時，模型會被騙得比人還徹底。命名的誠實度變成安全議題。
- 測試已經是寫給 AI 看的文件 —— 這一點會改變我們寫測試的動機和格式。
影片 34:03 ／ 56:39 · ▶ 從這裡開始看
Clean Code 之父說：我的招牌紀律，不要套在 agent 上。
「我很支持測試驅動開發。但那是因為人類天生需要這種紀律。要 agent 一行測試、一行正式碼、再一行測試，我覺得毫無意義。但對人類有意義，至少對我來說。」
「我讓 agent 更像 Ousterhout 那樣：先寫一個函式，再替它寫測試。就算我要求嚴格 TDD，它們最後也總是回到那種做法。」
- 先問理由，不要抄形式。TDD 的價值來自人類短期記憶有限（Matt：「你的短期記憶只夠寫測試，然後只夠讓測試通過」）—— agent 沒有這個限制。
- 跟模型的天性對抗，通常是你輸。與其反覆糾正它的工作順序，不如把力氣花在驗收條件上。
影片 35:04 ／ 56:39 · ▶ 從這裡開始看
規範結果，不要規範動作。
「把人類的紀律強加給 agent，可能是個錯誤。但把人類價值觀加諸 agent，並不是錯誤。只是有些門檻可能得調整。至於那些行為本身，我覺得不該強加給它們。」
- 價值觀（要堅持）：程式碼要乾淨、介面要窄、要被測試覆蓋、要能被人審。
- 紀律（可放手）：先寫 test 再寫 code、一次只改一個函式、commit 的節奏。
- 回頭審自己的規範：團隊的 CLAUDE.md／開發準則裡，有多少條其實只是人類的儀式？
影片 36:00 ／ 56:39 · ▶ 從這裡開始看
執行成本降低後，做錯方向反而變成主要成本。
Matt：「在進入這個 gauntlet 迴圈前，你會做多少規劃？畢竟把錯的工作丟進 gauntlet 非常浪費。」
- 這是全場的樞紐：前半在講「怎麼做得更好」，這裡開始講「不要把做得快誤認成規劃得準」。
- 流水線越自動化，越需要有人在入口把關 —— 自動化放大的是方向，不是正確性。
影片 36:10 ／ 56:39 · ▶ 從這裡開始看
AI 沒有讓瀑布變可行，只是讓它重演得更快。
「人很容易想先把規格寫好，寫了又寫、寫了又寫，再交給 agent。這是很老的誘惑，我們 70 年代就經歷過，這導致了瀑布式流程。」
「敏捷革命就是對此的回應：『前期規劃搞得這麼重，只會把一切弄得一團糟，因為最後產出的東西根本不像原本的計畫 —— 而且從來都是如此。』」
- Bob 補了一句很誠實的話：「不過敏捷革命做得好不好，我也不確定。」
- 老問題換了新工具，不會自動變成新問題。先確認你踩的是不是同一個坑。
影片 37:42 ／ 56:39 · ▶ 從這裡開始看
大計畫 × 高速執行 = 大規模返工。切小、交付、看、再切。
「我試過先規劃再交給 agent，這週還在試。結果總是災難，而且每次都一樣。」
「『好，等一下，現在來試試敏捷方法。』先讓它們做一兩個 story，最後再看架構。或許我得親自介入處理幾件事，然後再做幾個 story。」
「我們可能永遠都無法省掉最後手動整理的步驟。」
- 「最後手動整理」是流程的一部分，不是失敗。定義誰做、什麼標準，比幻想下一版模型就不用了實際。
- 瓶頸移位了：實作變快，需求釐清和 review 沒變快，於是它們成為新瓶頸（Matt：「真正困難的事花的時間還是一樣」）。
影片 40:59 ／ 56:39 · ▶ 從這裡開始看
規劃之所以值錢，是因為改動很貴。改動變便宜了，規劃的相對價值就跌了。
（用蓋房子比喻）「先做一點。廚房放這邊、客廳放那邊，這才 2 美元。不行？那就調整一下，讓小孩走過去看看 —— 喔，動線很爛，就把樓梯移走。」
「變更成本已經暴跌到我覺得幾乎是最低點了。既然低到這種程度，何必一開始就先規劃？那很花錢。為什麼不直接一直調、一直調，直到看起來對了？」
- 這是「敏捷 vs 大計畫」的經濟學解釋 —— 不是態度問題，是成本結構變了。
- 注意 Bob 說的是「變更成本」，不是「做錯的成本」。做錯方向的成本沒有變便宜（見前一頁）。
影片 41:45 ／ 56:39 · ▶ 從這裡開始看
判斷是不是 SDD，不看你寫得多詳細，看你事後會不會回去看。
「我對『規格驅動開發』這標籤有個很大的問題。規格驅動開發到底是什麼？可以有十種不同解讀。以前你會跟同事說『你去修一下 header 的載入問題』—— 這算規格驅動開發嗎？」
「我覺得差別在於：你有沒有把規格保存下來？你會不會回頭參考那些規格？」
- 這條檢查很好用：如果那份文件寫完就沒人再打開，它不是規格，是拋棄式 prompt。
- 名詞之爭常常掩蓋真正的差異。與其爭要不要 SDD，不如問「這份東西的保存期限多長」。
影片 42:38 ／ 56:39 · ▶ 從這裡開始看
規格是耗材，不是資產。
Matt：「那你怎麼看規格？會把所有規格列在 repo 裡嗎？」
Bob：「不會。規格是暫時的，之後會消失，也常常改。我會一直調整，然後它就沒了。」
- 跟 lost in the middle 呼應：留下來的東西越少，剩下的越有效。
- 真正該進 repo 的是能自動執行的東西（測試、檢查器、harness），不是描述性的文字。
影片 42:49 ／ 56:39 · 本段共 2 張截圖 · ▶ 從這裡開始看
規格的位置從事前的文字，移到事後的成果 + 驗收工具。
「它不像原始碼有對應的東西。以前是人寫原始碼，所以原始碼就是最終規格。但現在不是了。現在還是有原始碼，但不是人類在寫。」
「我最近在做的是：不再寫規格來定義我想要什麼，我會看最終成果，然後說：這就是規格。」
- 這是全場最激進的一句 —— 它把「需求 → 實作」的方向反過來：先長出來，再定義它是什麼。
- 配套是他的工具箱（crap tool、mutation tester、agent harness）。沒有這些確定性檢查，這招就是失控。他還說：「別下載那些，那是我為自己寫的。你該做的是讓你的 agent 去看它們，再替你做一套。」
影片 44:05 ／ 56:39 · ▶ 從這裡開始看
AI 會讀完你寫的每個字；你不會讀完它寫的每個字。
「agent 最奇怪的一點就是，你丟東西給它，它會讀。這跟人類差很多 —— 你丟一大份規格給人，能有 20% 的命中率就不錯了，20% 可能還太樂觀，5% 吧。」
「但你把規格交給 agent，它們大概真的會讀。反過來，agent 寫的東西，人類根本不看。」Matt：「它們以為我們會讀完它們寫的每個字，但我們就是不會。」
- 「寫給 AI 看的文件」投報率很高，「AI 寫給人看的文件」投報率極低。產出格式要照這個不對等重新設計。
- review 的瓶頸不在工具，在人的注意力。要求 agent 產出更短、更可掃描的交件，比要求它產出更完整的報告有用。
影片 45:46 ／ 56:39 · ▶ 從這裡開始看
AI 吃掉的，正是過去用來練功的那一層。
「戰術型就像地面的士官，負責打仗的人；策略型則是像指揮戰局的將軍。agents 很擅長戰術，戰略卻很差。」
Matt：「那剛入門的人該怎麼辦？現在 AI 已經吃掉所有戰術工作，他們要怎麼學戰略程式設計？」
- 這是全場最尖銳的問題，而 Bob 的回答很誠實：「我沒有完美答案，因為我真的不知道。」
- 對團隊的意涵：資淺工程師的成長路徑要重新設計，不能再靠「做久了自然會」。
影片 47:41 ／ 56:39 · ▶ 從這裡開始看
學不到策略，就先把戰術做到底 —— 而且用跟 agent 一樣的規則做。
「剛受訓完的年輕人，應該被當成 agent 對待。帶領的人可能是資深工程師，或其他帶著一堆 agents、負責策略的人。」
「他們應該把你當成 Agent，交給你跟 Agent 一樣的任務，也讓你用同樣的確定性工具。」Matt 接：「你當 agent 的 sub-agent。」
- 這不是羞辱，是把「感受過那種掙扎」當成必修課 —— Bob 後面說：「我看得出 agent 在掙扎，因為我也經歷過。新手進來時認不出那種掙扎。」
- 先寫程式寫一年（Bob 的原話），才知道 agents 在處理什麼。
影片 47:49 ／ 56:39 · 本段共 2 張截圖 · ▶ 從這裡開始看
養成期本來就該是低效率的。
「你得維持這種狀態好幾個月，效率慘不忍睹，卻學到一大堆。等你熬過這段考驗，也許就能信任你自己操作 Agent。」
「我是吃過苦才學到的。挫折中學習。」
- 把新人的產出效率當 KPI，等於斷了他的學習路。這條跟公司的短期績效制度直接衝突，是實務上最難執行的一段。
- 反過來說，這也給了主管一個明確的判斷：這段時間你該看的是他的判斷力有沒有長，不是他交了幾張票。
影片 48:02 ／ 56:39 · ▶ 從這裡開始看
抽象層之上的人，仍然要下去看過一次底層。
「你不能完全丟掉程式碼。我以前常跟人說，十年前也這樣說：如果你沒寫過組合語言，就該花個週末寫寫看，才知道底層到底在幹嘛。」
「因為如果你整天只寫 Java，你就活在幻想世界裡。還有很多你不懂的魔法。」
- 「花個週末」不是要你精通，是要你知道下面沒有魔法。
- 同理搬到今天：不用每行都自己寫，但agent 交出一坨爛東西時，你得看得出它爛在哪 —— 看不出來，你已經失去對系統的控制權。
影片 48:17 ／ 56:39 · ▶ 從這裡開始看
操作 agent 是最後一階，不是第一階。
「你得從最基礎的二進位開始，一路學到組合語言、C 這類基礎程式，再到 Python 之類的高階程式，然後處理 Agent 相關工作，以及確定性工具，最後才能在監督下、有策略地操作 Agent。」
- 現實是很多人直接從最後一階開始。梯子沒有斷，只是他們踩空了自己不知道。
- 這也是一份可以直接拿來用的培訓大綱 —— 差別只在每一階要花多久。
影片 50:17 ／ 56:39 · ▶ 從這裡開始看
整場唯一對新人有利的結構性改變：爛設計的報應來得更快了。
Matt：「策略性程式設計的回饋週期很長。做了六個月就離職的人可能永遠學不會，因為他們犯的錯要九個月後才會出現，根本看不到自己的錯。」
「但有了 agents，我想就可以了 —— 因為速度快了很多，你可以更早得到更多犯錯的回饋。」
- 前提是你真的去看那個報應。速度變快只是把回饋端上桌，不會逼你吃。
- 呼應 Bob：「我認得那種掙扎，因為我也經歷過。」加速的回饋，只有在你認得出訊號時才有價值。
影片 53:06 ／ 56:39 · ▶ 從這裡開始看
基本功 = 把複雜性整理成可理解的形式。這件事沒被取代，只是換了讀者。
「軟體是人類至今嘗試過最複雜的東西（我記得是 Dijkstra 說的）。所以基本功，就是把這份複雜性整理成可理解的形式 —— 不只人類能理解，模型也能理解，畢竟模型也是仿照人類打造的。」
「現在有人覺得基本功不重要。他們會學到的，而且會吃盡苦頭。」
- 「模型也是仿照人類打造的」是關鍵推論：對人友善的結構，對模型也友善。「為了 AI 而寫」跟「為了人而寫」收斂成同一件事。
- 「我看過它們撞上那道牆，所以我知道那道牆確實存在，我不想再撞一次。」—— 他不是在講信仰，是在講他看過的失敗。
影片 54:36 ／ 56:39 · ▶ 從這裡開始看
把 AI 放回歷史的位置 —— 它是第四階，不是第一次。
「現在我們已經到了編譯器之上的層級。以前，我們的抽象層是編譯器；在那之前是組合語言；在那之前是二進位。現在則到了模型這個層級。」
- 這個框架讓討論從「AI 會不會取代工程師」變成「這一階的新規則是什麼」，是更有生產力的問法。
- 每一階都不是取代下一層，是讓下一層變成「通常不用管」—— 出事的時候你還是得下去。
影片 55:07 ／ 56:39 · ▶ 從這裡開始看
恐慌會重演，原則會回來。
「底下一層的人抱怨說：『喔，這會毀了一切。我們連工作都沒了。事情變得太簡單，連五歲小孩都會寫程式。』你知道嗎，當時他們講的還是二進位。」
「不會。規則還是一樣。所有基本原則依然存在，理由也一樣。你丟掉的規則，一年後又會從地上撿回來，拍拍灰，想起為什麼需要它們。」
- 「拍拍灰撿回來」是可驗證的預言。現在團隊正在丟掉的通常是：測試、命名、邊界、review。
- 與其等它回來，現在就標記「哪些是我們決定暫時不做的」 —— 讓它是決策，不是遺忘。
影片 55:52 ／ 56:39 · ▶ 從這裡開始看
每次恐慌都對事實判斷正確，對價值判斷錯誤。
Matt：「我記得有句很棒的話，好像是柏拉圖說的：文字會讓人變笨，對吧？從希臘時代起，大家就在爭論同樣的抽象化問題。很荒謬。」
- （考據）出自柏拉圖《斐德羅篇》，藉蘇格拉底之口反對文字：人會依賴外在符號而不再記憶。他說對了 —— 我們確實不再背誦史詩。但人類換到了更高的位置。
- 收束：基本功不是懷舊，是槓桿。抽象層越高，一個判斷失誤被複製到整個 codebase 的速度就越快。