一個看空 AI 的 Neovim 派工程師，怎麼在六個月內讓 agent 寫出跟自己一模一樣的 production code——以及這件事對人、組織與工作流的代價

1. 開場：六個月沒自己寫 code 0:00–1:18

節目開頭剪輯了整集的重點：Cloudflare 五月裁掉 20%（約 1,100 人）並把 AI 列為主因；Dillon 這位死忠 Neovimi 派過去六個月幾乎沒自己寫 code，生產力空前但對工作的喜歡程度下降；最大的不確定是下一代開發者怎麼訓練。主持人丟出核心問題：你怎麼讓 AI 寫出跟你自己寫的一模一樣的 code？Dillon 的回答是「挫折、掙扎、反覆嘗試、絕望的夜晚」。

推理因為節目要先讓觀眾知道這集為什麼值得聽，所以作者（主持人）把整集最刺的幾句話剪成預告：Cloudflare 五月裁 20%、AI 是主因；Dillon 六個月沒寫 code、生產力空前但更不快樂；最大的不確定是下一代怎麼訓練。最後丟出整集的主線問題——怎麼讓 AI 寫出跟你自己會寫的一模一樣的 code——而 Dillon 的回答不是工具名，而是「挫折、掙扎、反覆嘗試、絕望的夜晚」，這等於預告答案是「過程」而不是「捷徑」。

• Rline for line：AI 產出跟自己寫的每一行都相同——比「能動」高很多的標準，後面所有做法都為了它→ 存＋回想

AI 補充這段是剪輯預告，不是線性的對談；所以先把三條線標出來，之後對談會依序展開：(1) 個人層面——一個手工派工程師怎麼變成幾乎不寫 code、以及為什麼更累；(2) 組織層面——Cloudflare 裁員與角色壓縮；(3) 方法層面——具體的工具鏈與工作流。「line for linei」這個說法值得留意：他要的不是「能動的 code」，而是「跟他自己寫的看不出差別的 code」，這個標準比一般 vibe coding 高很多，後面所有做法都是為了達到這個標準。

2. 從看空到 all-in 1:18–6:55

Dillon 交代背景：直到 2025 年 11 月他都公開看空 AI，對 Dario「12 個月內 AI 寫 90–100% 的 code」翻白眼；結果 Opus 4.5 在感恩節後推出，聖誕假期一玩就發現和 Sonnet 3.5/3.7 時代完全不同，從此幾乎不再自己寫 code。他強調這是「whiplashi」：六個月內產出相同、做事方式 100% 不同，而業界對這個「人的面向」討論太少。他推薦前同事 Ethan Niszer 的文章《Don't Hold Back the Ocean》：把這段時期比作電影業從手工剪接換成數位，結論是精靈已出瓶，選擇成為新工具的 craftsmani 並繼續為結果負責。

推理因為上一段預告了「六個月沒寫 code」但沒說怎麼開始，所以 Dillon 先說明自己的基準線：他不是 AI 早期信徒，而是對 Dario「12 個月內 AI 寫 90–100% code」翻白眼的人。這讓他的轉向更有說服力——不是信仰，是實際用了 Opus 4.5 之後發現「跟 Sonnet 3.5/3.7 時代明顯不同」。接著他把重點從模型拉到人：產出一樣、做法 100% 不同，這是「whiplash」，而業界對這個人的面向討論太少。最後借 Ethan Niser 的文章給出他的心態框架：精靈已出瓶，選擇成為新工具的 craftsman、繼續為結果負責。

• EOpus 4.5 之前只讓 Claude Code 寫 5–10% 的 code，一個假期後變成幾乎全部→ 存＋演練
• AEthan Niser 的電影業比喻：手工剪接→數位，難的是以手藝為身份的人怎麼安放自己→ 批判類比

AI 補充這段的關鍵不是「Opus 4.5 很強」，而是 Dillon 把「工具換了」和「身份換了」分開談。Ethan 的電影業比喻（手工剪接 → 數位）點出一件事：技術轉換時真正難的是那些以「手藝」為身份的人怎麼安放自己。這段給的答案是「把手藝從『寫 code』轉移到『駕馭工具並為結果負責』」——注意「still own the outcomes」這句，它是後面所有討論的錨點：不管 code 是誰寫的，責任沒有轉移。另外他說在 Opus 4.5 之前只讓 Claude Code 寫 5–10% 的 code，這個數字可以當對照：從 5–10% 到「幾乎全部」只花了一個假期，這就是他說的 whiplash。

術語:bearishi

3. 工具不定義工作？ 6:55–10:02

主持人提出自己的立場：AI 是工具，工具 15 年來一直在換，他刻意不讓工具定義自己的工作，因為他對公司的價值從來不是寫出的 code。Dillon 同意這個框架，但補充兩點：第一，他不是讓 agent 在 loopi 裡 AFKi 自動 commit 的人，每一行 code 都會讀，仍然把自己的原則與經驗灌進產出，只是「產出怎麼產生」變了；第二，只叫它工具不太公平，因為它不像任何過去的工具——在對的人手上是驚人的生產力放大器。

推理因為上一段 Dillon 用 craftsman 的框架談身份轉換，所以主持人提出一個反向的框架來對照：他 15 年來工具一直在換、自己對公司的價值從來不是寫出的 code，所以刻意不讓工具定義工作——換工具不該動搖身份。Dillon 的回應分兩層：先同意「LLM 仍然是工具」，並劃清界線——他不是讓 agent AFK 在 loop 裡自動 commit 的人，每一行 code 都會讀，原則、經驗、過去的錯誤與成功一樣灌進產出，只是「產出怎麼產生」變了；再補一句「只叫它工具不太公平」，因為在對的人手上它是前所未有的生產力放大器。這兩層合起來的意思是：責任歸屬不變（所以是工具），但影響幅度前所未見（所以不只是工具）。

• R「AFK loop 派」與「讀每一行派」：Dillon 站後者，這決定他對 sub-agent、自動降級、多 agent 平行的態度→ 存＋回想

AI 補充主持人和 Dillon 的分歧其實不在「是不是工具」，而在「滿足感從哪裡來」——主持人的價值錨在「對公司的貢獻」，Dillon 的錨原本在「寫 code 的過程」。這段還藏了一個後面會一直用到的區分：「AFK loop 派」與「讀每一行派」。前者讓 agent 自主循環、直接 commit；後者堅持人是 reviewer 與決策者。Dillon 明確站在後者，這決定了他之後對 sub-agent、對自動降級模型、對「多 agent 平行」的態度。另外他自嘲「預測的 track record 很差」，是呼應上一段的 bearish 翻車，也提醒聽眾：接下來的判斷都是「今天」的判斷。

4. 更不快樂：滿足感的來源變了 10:02–14:16

Dillon 坦白今天對工作的喜歡程度遠不如一年前，滿足感與快樂變少，但看得到隧道盡頭的光。他的原則是：駕駛 LLM 的人就是該負責的人，這和以前一樣，只是「從開始到完成的中間那段」完全不同，要維持同樣品質很費工。主持人用太太從工程師轉 EM 的經驗類比：工程師每解一個小問題就有一個小成就，EM 沒有，得重新調整「什麼讓我快樂」的價值系統；以前以寫 code 為傲的人現在也面臨同樣的轉換。

推理因為上一段確立了「責任沒變、只是中間過程變了」，所以 Dillon 在這段把「更不快樂」定位在那個中間過程：從開始到完成的路徑完全不同，要維持同樣品質很費工，個人滿足感與快樂變少，但他看得到隧道盡頭的光。主持人接著提供一個解釋框架：太太從工程師轉 EM 後不再寫 code，工程師每解一個小問題就有一個小成就、有起有伏，EM 沒有，所以得重新調整「什麼讓我快樂」的價值系統。Dillon 承認這個類比成立——他愛做產品，但「沉浸在寫 code 裡」那種東西不一樣了，而且六個月沒進過 flow statei。

• A生產力更高卻更不快樂，像工程師轉 EM：小成就的頻率消失了→ 批判類比

AI 補充這段是整集情緒線的核心。主持人的 EM 類比把一個模糊的「不快樂」拆成可分析的機制：滿足感來自「小成就的頻率」。工程師的一天有幾十個小成就（解 bug、想到漂亮解法），EM 的一天可能一個都沒有，只有「團隊有沒有產出」這種延遲很長的回饋。Dillon 現在的處境跟 EM 一樣——他管理的不是人而是 agent，但同樣失去了那些小成就。注意他說「I see a light at the end of the tunnel」：他不是在抱怨，而是在描述一段還沒結束的適應期，並且已經開始看到新的滿足感會從哪裡回來（從「怎麼設計系統」而不是「怎麼寫這行」）。

術語:engineering manageri

5. 只剩 macro 難題，沒有 flow 14:16–17:38

Dillon 解釋為什麼更累：以前做一個全端功能，先決定架構、抽象、資料流與型別（macro 難題，決定系統成敗），然後可以「休息」去實作，實作過程裡不斷出現的小難題（這個 class 怎麼寫、用哪個 library、漏掉的錯誤路徑）是一個個小的 dopamine hiti，讓他進入 flow state。現在小難題全被 LLM 接走，工作變成從一個 macro 難題跳到下一個，六個月沒進過 flow state。他再次強調：LLM 的產出永遠要落到一個人身上負責，而且決策的影響範圍更大、時間更短，所以 macro 決定要更謹慎。

推理因為上一段用 EM 類比指出「小成就消失」是不快樂的來源，所以 Dillon 這段用一個全端功能的例子把它講具體：以前做一個從 UI 到 endpoint 到商業邏輯到資料庫索引的功能，先決定架構、抽象、資料流與型別——這是「macro 難題」，決定系統成敗；決定完就能「休息」去實作，而實作過程裡不斷冒出的小難題（這個 class 怎麼寫、用哪個 library、漏掉的錯誤路徑）是一個個小的 dopamine hit，把他帶進 flow state。現在小難題全被 LLM 接走，一天變成從一個 macro 難題直接跳到下一個，所以更累。他順勢再強調一次：LLM 的產出永遠要落到一個人身上負責，而且決策影響範圍更大、時間更短，所以 macro 決定要更謹慎——這又加重了每個 macro 難題的壓力。

• Cmacro hard problem：架構、抽象、資料流、型別；現在全是 macro 所以更累→ 畫地圖
• E全端功能的例子：UI→endpoint→商業邏輯→索引；決定架構後的實作小難題是休息也是心流，現在全被 LLM 接走→ 存＋演練

AI 補充這段給出了「更累」的機制，值得把它畫成兩層：macro 層（架構、抽象、資料流、型別）與 micro 層（class 怎麼寫、選哪個 library、錯誤路徑）。以前一天是「macro → 一串 micro → macro → 一串 micro」，micro 那段既是休息也是心流；現在是「macro → macro → macro」。這解釋了為什麼生產力上升但更累：被拿掉的正是「省力又有回饋」的那一層。作者沒有明說但值得補的一步：這也意味著「macro 能力」變成瓶頸——一個人一天能做多少個好的 macro 決定是有上限的，而且他說決策影響「更遠、更快」，所以錯的 macro 決定會被 LLM 以同樣速度放大。這是他之後花大力氣在 spec 與 review 上的原因。

術語:macro hard problemi

6. 像回到 junior 17:38–19:46

另一個累的來源：像重新變成新人。Dillon 回憶第一份工作時想不出 React → Go → ORMi 的完美資料流抽象、不懂資深同事為什麼那麼輕鬆，那種「得不到想要的結果」的挫折感現在一模一樣。主持人接話：他完全同意 LLM 的 code 要被 review（問責第一、品質第二），但這需要細心與紀律；網路上很多人沒經歷這些痛苦，因為「能動就好」，幾分鐘就從零到能跑。

推理因為上一段解釋了「macro 連發」這種累，所以 Dillon 補上第二種：過去幾週他發現自己的挫折感跟當 junior 時一模一樣——第一份工作時想不出 React → Go → ORM 的完美資料流抽象、看不懂資深同事為什麼那麼輕鬆，那種「知道自己要什麼卻得不到」的感覺現在重演了，只是對象換成 agent。主持人接話把這件事推到方法論層面：他 100% 同意 LLM 的 code 要被 review（問責第一、品質第二），但這需要細心與紀律；網路上很多聲音之所以聽起來輕鬆，是因為他們跳過了這一步——「能動就好」，幾分鐘就從零到能跑，所以沒有這些痛苦、也沒有「像 junior」的感覺。

• R「像回到 junior」不是能力退步，而是工具操作技能歸零：judgement 還在、operation 要重學→ 存＋回想

AI 補充這段其實在解釋一個很多人困惑的現象：為什麼有些人說 AI 寫 code 很輕鬆、有些人說很痛苦？主持人給的答案是「標準不同」。如果標準是「能動」，LLM 幾分鐘就達成，當然輕鬆；如果標準是第 1 段說的 line for line，那你得像 junior 一樣反覆試、反覆被拒絕，直到學會怎麼讓 agent 給你要的東西。Dillon 的「像 junior」不是能力退步，而是「工具的操作技能歸零」——他知道好的抽象長什麼樣（senior 的判斷力還在），但還不知道怎麼讓 agent 產出它（新的操作技能還沒建立）。這個區分後面談「下一代怎麼訓練」時會很關鍵：judgement 和 operation 是兩種不同的技能。

術語:signal to noisei

7. 下一代怎麼訓練 19:46–23:34

主持人：「能動」對多數 production 應用不夠（liability 是大問題），軟體開發不會消失、工程師反而更有價值，但他最怕 junior：以前靠跟難題搏鬥學習，現在丟一顆「止痛藥」（prompt）就有東西。Dillon 說這是他現在最大的不確定，沒有答案，也許會變成學徒制i；他自己靠掙扎、犯錯、弄掛 prod 學會，所以認為 system designi 與架構能力是往後最重要的技能，而那是幾千次反覆看過什麼可行、什麼失敗、什麼只是 hype 累積出來的直覺。他擔心新的學法是「更快地做出爛軟體再重建」。

推理因為上一段確認了「能動不等於夠好、真正的學習來自搏鬥」，所以主持人這段先把立場說清楚：軟體開發這個職業不會消失（他認為 Dario 在這點上胡說），工程師反而更有價值，因為「這是好 code、這是壞 code」的判斷力更被需要；但他最怕 junior——以前靠跟難題搏鬥學習，現在丟一顆 Advil（prompt）就有東西，搏鬥不見了。Dillon 說這正是他現在最大的不確定，沒有答案，只有一些想法（也許會變成學徒制、Cloudflare 有些 junior 有成功案例）。他接著推導出一個結論：因為自己是靠掙扎、犯錯、弄掛 prod 學會的，而這些累積出的「看過幾千種模式、知道什麼可行什麼是 hype」的直覺正是 system design 與架構能力，所以往後最重要的技能是 system design——但他不知道沒有搏鬥要怎麼建立這種直覺，只擔心新的學法是「更快做出爛軟體再重建」。

• Csystem design 直覺過去是 micro 搏鬥的副產品；micro 被 LLM 拿走，副產品消失——下一代怎麼訓練是最大未知→ 畫地圖
• A主持人：以前靠跟難題搏鬥學習，現在丟一顆 Advil（prompt）就有東西→ 批判類比

AI 補充這段把第 5、6 段的兩條線接起來了：第 5 段說工作只剩 macro 難題，第 6 段說 judgement 和 operation 是兩種技能；那麼下一代的問題就是——macro 判斷力（system design 直覺）以前是 micro 搏鬥的副產品，現在 micro 被 LLM 拿走了，副產品也跟著消失。這是為什麼 Dillon 說「沒有答案」：不是他沒想過，而是這個因果鏈斷了、還沒有替代品。作者跳過的一步：主持人說「工程師更有價值」和「junior 很危險」其實是同一件事的兩面——價值集中在有判斷力的人身上，而判斷力的生產線壞了，長期會讓有價值的人越來越稀缺。這也是為什麼「apprenticeship」被提出來：學徒制的本質是讓新人在有判斷力的人旁邊做真實的事，而不是自己搏鬥。

8. Cloudflare 裁 1,100 人 23:34–26:12

主持人先說「AI 裁員」多半是藉口、10x/100x 是行銷，2–3 倍才務實；Dillon 表示在裁員這點上有些不同意見。Cloudflare 五月裁 20%、約 1,100 人，AI 是主因；他承認也有過去幾年過度招聘i的成分，但壓倒性的事實是 AI 驅動：裁完隔天就有幾百個開缺，只是職位完全不同。他歸功 Matthew Prince 與 Dane Knecht 看到「AI 讓人更有能力」的趨勢並全力投入；被砍的是中間那一層——scrum masteri、三層 director、負責忙碌工作的角色。

推理因為上一段主持人主張「AI 裁員多半是藉口、2–3 倍才務實」，所以 Dillon 這段用親身經歷提出反例：Cloudflare 五月裁 20%、約 1,100 人，AI 被列為主因。他先承認也有過去幾年 overhiring 的成分（並說這是脫下 Cloudflare 帽子講的），但接著給出判斷「壓倒性的事實是 AI 驅動」的證據：裁完隔天就開了幾百個職缺，只是職位完全不同——所以不是瘦身，是換人。他歸功 Matthew Prince 與 Dane Knecht 看到的趨勢不是「裁員」而是「AI 讓人更有能力」並全力投入；被砍的是中間那一層：scrum master、三層 director、負責忙碌工作的角色。

• ECloudflare 五月裁 20%（約 1,100 人），隔天開幾百個完全不同的職缺；砍的是 scrum master、三層 director 等中間層→ 存＋演練

AI 補充這段對「AI 裁員是不是藉口」給了一個比二選一更細的答案：關鍵指標不是「裁了多少」而是「裁完之後有沒有補、補什麼」。如果裁完就縮編，那是財務理由掛 AI 招牌；如果裁完馬上開幾百個不同的缺，那是組織結構因為 AI 而重排。Dillon 說被砍的是「中間層」——這跟第 5 段的 macro/micro 結構可以對起來：AI 讓有判斷力的個人能直接產出，那些原本負責「協調產出」的角色（scrum master、多層 director）的價值就下降了。要注意的是，他這裡的說法是一個內部員工的主觀判斷，他自己也先聲明「可能有沒被承認的其他原因」；聽的時候把「AI 驅動」和「overhiring 修正」當成同時成立的兩個因素比較穩。

9. 角色壓縮：QA 30 秒、軟技能更重要 26:12–31:00

主持人問：AI 會讓一個工程師同時是 QA 和 PM 嗎？Dillon：QA 肯定會——他推 PR 後有 agent 自動寫 Playwrighti 測試、錄影交回，以前半天的 QA 現在 30 秒；但這不是說要裁 QA。他認為最好的工程師是 product-minded、對使用者痛點有同理心（除了 2% 極深專業如嵌入式 kernel）。主持人補充最好的工程師是 T 型、能跟法務對話；Dillon 說一年前這是 senior 與 staff/principal 的分界（技術報酬遞減、軟技能推動事情），而 AI 是一股壓縮力量，角色重疊變多，所以跨團隊合作、同理心比以前更重要——例如派 agent 去別團隊的 codebase 探索問題再去溝通。

推理因為上一段確立了「AI 讓個人能直接產出、中間層價值下降」，所以主持人這段追問角色邊界會不會消失，用 QA 與 PM 當具體例子。Dillon 的回答分三步：第一，QA 肯定會——他推 PR 後有 agent 自動寫 Playwright 測試、錄影交回，以前半天的 QA 現在 30 秒，但他刻意說這不是主張裁掉 QA。第二，最好的工程師本來就該是 product-minded、對使用者痛點有同理心，除了 2% 極深專業（嵌入式 kernel）之外。第三，主持人補充 T 型、能跟法務對話的工程師更有價值，Dillon 接著把它升級：一年前這只是 senior 與 staff/principal 的分界（技術報酬遞減、軟技能推動事情），現在 AI 是一股壓縮力量，角色重疊變多，所以跨團隊合作與同理心比以前更重要——例如派 agent 去別團隊的 codebase 探索問題後再去溝通。

• CAI 移除「做」的成本、不移除「協調」的成本，所以角色壓縮後跨團隊同理心與 product-minded 更重要→ 畫地圖
• E推 PR 後 agent 自動寫 Playwright 測試、錄影交回，以前半天的 QA 現在 30 秒——但他還是自己看錄影→ 存＋演練

AI 補充這段有一個容易漏掉的推論：為什麼 AI 讓「軟技能」更重要，而不是更不重要？直覺上 AI 接手了更多工作，人應該更少互動才對。Dillon 的邏輯是：AI 壓縮了角色邊界 → 每個人碰到的「別人領域」變多（你會去動別團隊的 codebase、會做以前 QA 做的事）→ 需要更多跨領域的協調與同理心。換句話說，AI 移除的是「做」的成本，不是「協調」的成本，所以協調的相對重要性上升。另外，「QA 30 秒」這個例子要和第 3 段的立場合起來看：agent 自動跑 Playwright 是把 micro 工作交出去，但 Dillon 還是自己看錄影——這是「人在迴圈裡」的 QA，不是 AFK。

術語:product-minded engineeriT-shapedi

10. PM 與工程師：MVP 取代長 PRD 31:00–34:55

主持人不買單「未來只招 product engineer 包辦一切」：JetBrains 的 PM 有的比他還懂 codebase、有的完全不懂，讓 PM vibe code 一個 PR 當討論起點很好，但他不覺得工程師能寫出設計、QA、行銷都能用的 PRDi——專業分工還在，只是界線變模糊、交接更快。Dillon 同意沒有哪個職位該消失，但 PM 要離開「花兩週寫 4,000 字 PRD 再到處 bikeshed」的流程：用更精簡的 spec 做 MVPi/原型交給工程師打磨，Cloudflare 的 PM 已經這樣做；不過 product engineer 和 PM 技能組合仍不同，好 PM 值千金。

推理因為上一段 Dillon 主張角色壓縮、重疊變多，所以主持人這段提出反例來畫界線：JetBrains 的 PM 有的比他還懂 codebase、有的完全不懂，讓 PM vibe code 一個 PR 當討論起點他很歡迎，但他不覺得自己能寫出設計、QA、行銷都能用的 PRD——專業分工還在，只是界線更模糊、交接更快。Dillon 說他不反對任何一句，並澄清自己沒說任何職位該消失（「我連自己的日常都還不太會做」）；但他對 PM 有具體看法：PM 要離開「花兩週寫 4,000 字 PRD、到處 bikeshed」的流程，改用精簡的 spec 做 MVP/原型交給工程師打磨，Cloudflare 的 PM 已經開始這樣做。最後補一句平衡：product engineer 和 PM 的技能組合仍然不同，好 PM 值千金。

• A角色不消失，交接物改變：PM 從 4,000 字 PRD 變成能跑的 MVP；工程師從 PR 變成 PR＋測試影片→ 批判類比

AI 補充兩人在這段收斂出一個共識，值得整理成一句：**角色不消失，交接物改變**。以前 PM → 工程師的交接物是文件（PRD），現在可以是「能跑的原型」；以前工程師 → QA 的交接物是 PR，現在是「PR + agent 錄的測試影片」。交接物從「描述」變成「實物」，所以交接更快、誤解更少——這是主持人說的「AI 讓 handoff 更 seamless」的具體含義。Dillon 對 PRD 的批評也可以對回第 5 段：4,000 字 PRD 是「用文字描述 macro 決定」，而原型是「用實物呈現 macro 決定」；後者更容易被工程師驗證與反駁。這個「用實物代替描述」的想法，之後會出現在他自己的 spec 寫法裡。

術語:vibe codingibikesheddingi

11. Loops 不適合中位數開發者 34:55–40:00

主持人問：Boris（Claude）、Peter Steinberger（OpenAI）那種多 agent 平行 loop 的工作法，多少是靠 AI lab 的無限 token？是未來還是「科學實驗」？Dillon 自評在正中間：以今天的模型與成本，對中位數開發者i「行不通」，除非你在 lab；他不喜歡 Claude Code 與 Codex 團隊的說法，因為不論訂閱或 API 計費（Cloudflare 與多數企業都走 API），dynamic workflow 這類功能貴到不能日用。他設想若成本不降，可能要用 RFC 決定哪些問題值得花 token。他要看更多「receiptsi」：harnessi 品質一版好一版壞、功能狂出但一致性不足以合理化成本，而越來越多人被價格排除在外。

推理因為上一段把話題從組織轉到工作方式，所以主持人這段先把問題框好：Boris（Claude Code）與 Peter Steinberger（OpenAI）推的多 agent 平行 loop，他很敬佩，但多少是靠 lab 的無限 token？是未來方向還是 David Cramer（Sentry）說的「科學實驗」？Dillon 自評在正中間，然後把「中間」拆開：以今天的模型與限制，對「中位數」開發者來說行不通，除非你在 lab 有無限 token。接著他點名不喜歡 Claude Code 與 Codex 團隊談這件事的方式——不論訂閱或 API 計費（Cloudflare 與多數企業都走 API），dynamic workflow 這類功能貴到不能日用；他甚至設想若成本不降，組織可能得用 RFC 決定哪些問題值得花 token。最後他要看更多「receipts」：harness 品質一版好一版壞、功能狂出但一致性不足以合理化成本，同時越來越多人被價格排除在外，這是一種錯位。

• R多 agent loop 對中位數開發者不實際的三個獨立理由：成本、harness 飄移、缺 receipts→ 存＋回想

AI 補充這段是 Dillon 對 AI lab 敘事最直接的批評，值得把他的論證拆成三個獨立的主張，因為它們各自成立：(1) **成本主張**——loop 消耗的 token 對 API 計費的企業來說太貴，這是經濟問題，不是能力問題；(2) **一致性主張**——harness 每版行為都變，沒有穩定的 baseline，所以無法評估 loop 到底有沒有用；(3) **證據主張**——lab 說有效，但沒有足夠的 receipts（可驗證的成果）。注意他特別用「中位數」而不是「平均」：平均會被少數重度使用者拉高，中位數才代表「一般人」。RFC 決定 token 用途的設想很有意思：它意味著 token 變成一種需要治理的稀缺資源，跟雲端成本、資料庫連線數一樣要被組織層級管理。這也回應了第 3 段他為什麼不是 loop 派——不只是原則，也是他公司的帳單。

術語:API billingi

12. 永遠再六個月：ROI 與預算 40:00–41:50

Dillon 說開源權重模型（如 GLM 5.2）越來越好，哪天夠好時這些能力才合理，但那正是 AI 批評者說的「永遠在六個月後」；他自己實驗能拿到結果，但今天（2026-06-25）不是主流，lab 的說法聽了很煩。主持人補充：若品質不大幅上升、價格不下來，今年公司內部會有激烈的 ROIi 對話——過去 AI 花費像有無窮的金子，Uber 四個月燒光全年 AI 預算後率先設硬上限，其他公司會跟進。Fable 是第一次看到品質戲劇性提升的模型，但也貴一倍、慢一倍。

推理因為上一段結尾自己說出了「等模型夠好」這種話，所以 Dillon 這段先承認這正是 AI 批評者的視角——「永遠在六個月後」——並引 Armin 的文章說他也在跟同樣的矛盾搏鬥：Dillon 自己的實驗有時真的能拿到結果，但今天（2026 年 6 月 25 日）它不是主流；六個月後也許 GPT-6 很強、成本或 token 效率壓下來，也許不會，所以現在聽 lab 那種說法「很煩」。主持人接著把它從個人推到公司：若品質不大幅上升、價格不下來，今年公司內部就會有激烈的 ROI 對話——過去 AI 花費像有無窮的金子，公司用 10x/100x 的希望合理化；Uber 四個月燒光全年 AI 預算後率先設硬上限，其他公司會跟進。他最後點出 Fable 是第一次看到品質戲劇性提升的模型，但也貴一倍、慢一倍——品質上升了，價格卻沒下來。

• R把判斷加上日期（「今天，2026 年 6 月 25 日」）：拒絕用未來的可能性合理化今天的成本→ 存＋回想

AI 補充這段最重要的是那句「今天，2026 年 6 月 25 日」——Dillon 刻意把判斷加上日期，是因為他知道這個領域的判斷保鮮期很短（第 3 段他就說過自己預測的 track record 很差）。這是一種誠實的說法：「我不否認未來可能不同，但我拒絕用未來的可能性來合理化今天的成本」。主持人的 Uber 例子把第 11 段的「token 需要治理」變成了現實：當一家公司四個月燒光全年預算，硬上限就不是假設而是必然。作者沒明說的一步：「品質上升、價格下降」需要同時發生，才能解開 ROI 的僵局；而 Fable 是「品質上升但價格也上升」，所以它不解決問題，反而讓問題更尖銳。

術語:open-weight modeli

13. Fable 為何是 non-starter 41:50–44:05

Dillon 對 Fable 的兩個問題：一、沒有 zero data retentioni（ZDR），會保留並訓練你的 prompt 與 code，其他模型都有 ZDR，所以對 Cloudflare 這種企業第一天就出局；二、它會自作主張降級到 Opus 4.8——他不接受 thinkingi 被拿走（他手動引導 agent、不要更多自主性），而且 200k context 一路吃 cache hiti 後突然換模型，整份 inference 成本要重付。主持人的抱怨則是「不可用」是 Anthropic 自己搞出來的：先喊危險，再抱怨被封鎖。

推理因為上一段主持人只談了 Fable 的價格與速度，所以 Dillon 這段補上企業視角的兩個硬門檻。第一，Fable 不提供 zero data retention——會保留你所有的 prompt 與送進去的 code 並拿來訓練，而其他模型都有 ZDR，所以對 Cloudflare 這種公司第一天就 non-starter。第二，它會自作主張降級到 Opus 4.8，這又有兩個問題：(a) 他不接受 thinking 被拿走——他手動引導 agent、知道自己要什麼，不想要模型在這方面「更有自主性」；(b) 成本——假設 context 已累積 200k token，用 Fable 時一路吃 cache hit 省了錢，一降級到 4.8 就得把整份 inference 成本重付一次。主持人的抱怨則是另一個角度：「Fable 不可用」是 Anthropic 自己搞出來的——先喊很危險，再抱怨被封鎖。

• Rzero data retention：企業採用 AI 的硬門檻，資料治理先於能力→ 存＋回想
• Rprompt cache 綁定特定模型：200k context 在 Fable 上一路 cache hit，自動降級到 Opus 4.8 就得整份重付→ 存＋回想

AI 補充這段看起來是對單一模型的抱怨，但背後是兩條企業採用 AI 的通則。第一條：**資料治理先於能力**——再強的模型，只要會把企業的 code 拿去訓練，法務就會直接否決，跟品質無關。第二條：**可預測性先於自主性**——Dillon 在第 3 段說自己「讀每一行」、在這裡說「不要更多 dynamism」，是同一個原則：他要的是一個可控的工具，不是一個會自己做決定的代理人。自動降級違反這個原則的方式很具體：它讓成本和行為都變得不可預測。作者跳過的一步：為什麼降級會「重付整份 inference」？因為 prompt cache 是綁定在特定模型上的——同一份 200k context 在 Fable 上已經被快取，換到 Opus 4.8 就是一份全新的、未快取的輸入，得從頭計價。這也解釋了為什麼他把「cache hit」當成日常成本結構的一部分。另外要提醒：ZDR 與降級行為都是供應商政策，可能隨版本或合約改變，聽的時候記得這是 2026 年 6 月的狀態。

14. 讓模型照你的方式寫 44:05–46:20

回到核心問題「怎麼讓 AI 寫出跟你一樣的 code」。Dillon：挫折、反覆嘗試、絕望與存在焦慮，花了很長時間，而且現在還是沒以前那麼喜歡日常。但若你認為 agentic engineeringi 是未來、在乎手藝，就該花時間親自建構、找出什麼有用；而且要幾乎完全忽略 Twitter——談 AI 工作流的多是年輕 YC 創辦人，有才華但沒有「production 系統跑很多年還可維護」的經驗，很多人也在賣東西。他學會的方式和以前一樣：失敗、產出爛東西、造成事故，只是壓縮在幾個月裡。

推理因為主持人把第 1 段預告裡的問題正式問出來，所以 Dillon 先重複同樣的答案——挫折、掙扎、反覆嘗試、絕望的夜晚、存在焦慮——並補充：花了很長時間，而且到現在還是沒以前那麼喜歡日常（呼應第 4 段）。接著他給出一個條件式：如果你認為 agentic engineering 是未來、在乎自己的手藝與產出，那就該花時間親自用這些東西建構、反覆試、找出什麼有用。而要做到這件事，幾乎得完全忽略 Twitter——因為談 AI 工作流的多是年輕 YC 創辦人，有才華、做出好產品，但沒有「production 系統跑很多年還可維護」的經驗，而且很多人在賣東西。最後他把方法對回自己的成長路徑：他是靠失敗、產出爛東西、造成事故學會當工程師的，這次一樣，只是壓縮在幾個月裡。

• Cagentic engineering 沒有捷徑：要學的是判斷力，只能從自己的失敗長出來，只是壓縮在幾個月裡→ 畫地圖

AI 補充這段的答案看起來像在迴避（「就是反覆試」），但其實是整集最一致的主張：**沒有捷徑，因為你要學的是判斷力，而判斷力只能從自己的失敗裡長出來**。這和第 7 段談下一代訓練的邏輯完全相同——Dillon 對自己的要求，就是他擔心 junior 得不到的那條路。「忽略 Twitter」的理由也不是傲慢，而是第 6 段訊噪比的延伸：YC 創辦人的標準是「快速做出產品」，Dillon 的標準是「跑很多年還可維護」，兩種標準下的最佳工作流不同，所以對方的經驗對他幾乎沒有參考價值。作者沒說但值得補的一步：「壓縮在幾個月裡」意味著失敗的成本也被壓縮——以前弄掛 prod 一次學一課，現在一天可以失敗十次；這其實是 LLM 給有經驗者的一個真正優勢，前提是你願意讀每一行、看每一次失敗。

術語:YC founderi

15. Herdr 與 Pi：harness 越少越好 46:20–48:16

工具鏈第一層：Ghostty 終端機 + Herdr（建在 libghostty 上的現代 tmux，支援 kitty image protocol、agent 追蹤指示器，CLI 對人和 agent 都友善，用來組織專案與 workspace）。第二層是 Pii 這個 coding agent harness：極簡、可客製但他幾乎不客製。他對 harness 的結論是「做得越少、改得越少越好」——OpenCode 與 Claude Code 每週改 tool 定義與 system prompti，模型行為跟著飄，很難建立 baselinei；小 system prompt、少數 tool、把注入 context 的東西減到最少，是他學會最珍惜的事。

推理因為上一段說「反覆嘗試總得落在具體工具上」，所以 Dillon 這段從最底層開始盤點。第一層：Ghostty 終端機配 Herdr——建在 libghostty 上的現代版 tmux，支援 kitty image protocol、有 agent 追蹤與指示器、CLI 對人和 agent 都友善（控制 dev server、監看狀態），他用它組織專案與 workspace。第二層：Pi 這個 coding agent harness，他喜歡它極簡、可客製（自嘲是 Neovim 魂），但其實沒有重度客製。接著他給出選 harness 的結論：要它做得越少、改得越少越好。理由直接接回第 11 段的抱怨：OpenCode 與 Claude Code 每週出新功能、tool 定義變、system prompt 變，模型行為跟著飄，很難建立 baseline。所以「很小的 system prompt、只有幾個 tool、把注入 context 的東西減到最少」是他學會最珍惜的事。

• Charness 做得越少越好：小 system prompt、幾個 tool、最少注入 context——否則每版飄移，建不了 baseline→ 畫地圖
• RDillon 工具鏈：Ghostty + Herdr（tmux 替代）、Pi（極簡 harness）、Plannotator→ 存＋回想

AI 補充這段把第 11 段的批評（harness 一版好一版壞）變成了選擇標準：既然 harness 的每次改動都會讓模型行為飄移，那最好的 harness 就是「幾乎不存在」的 harness——它只提供最少的 tool 和最短的 system prompt，其餘由人來控制。這背後有一個作者沒明說的假設：Dillon 要建立的是「他自己對模型的直覺」（第 6 段的 operation 技能），而這需要一個穩定的實驗環境——harness 一直變，他就分不清是自己的方法有效還是 harness 剛好改對了。「minimize what gets injected into your context」也是後面所有工具的共同原則：他要親手決定 context 裡有什麼。Herdr 看似只是 tmux 替代品，但「agent 追蹤指示器」與「agent 友善的 CLI」說明它是為多個 agent 同時跑的工作方式設計的——這是他組織多個 agent session 的基礎設施。

術語:terminal multiplexeri

16. Plannotator review 與 stacked PR 48:16–51:13

第三個工具 Plannotatori（plannotator.ai，免費，支援 Pi/OpenCode/Codex/Claude Code）。功能一是本地 code review：年初他看出 review 流程壞了，不想在自己完整 review 前把 AI 改動推給團隊看，`/plannotator review` 開一個像 GitHub PR review 的網頁（建在 Pierre 的 diff 工具上，很快），逐檔加註解後 submit 就注入回 agent session，回饋循環變快。他強調交付方式沒變：小改動、stacked PRi、每個 PR 控制在 300–800 行，這樣能 review 到懂、還能完整理解 codebase。主持人問 stacked PR 是什麼：從還沒 merge 的分支再開分支、PR 指向前一個分支，工具如 Graphite（被 Cursor 收購）、JJ，GitHub/GitLab 也要原生支援。

推理因為上一段確立了「context 由人控制、review 每一行」的原則，所以這段的工具就是讓「人 review」變快。第三個工具 Plannotator（plannotator.ai，免費，支援 Pi/OpenCode/Codex/Claude Code）有兩大功能，先講第一個：本地 code review。年初他就看出 review 流程壞了——他不想在自己完整、整體地 review 之前把 AI 的改動推成 PR 讓團隊看，但當時沒有好的本地工具。`/plannotator review` 會開一個像 GitHub PR review 的網頁（建在 Pierre 的 diff 工具上，很快），逐檔加註解，submit 後註解直接注入回目前的 agent session，讓「做 → review → 修」的回饋循環變快。他接著強調交付方式完全沒變：小改動、stacked PR、每個 PR 控制在 300–800 行——這樣可以 review 到懂、眼睛不會花，還能完整理解自己的 codebase。主持人問 stacked PR 是什麼，Dillon 解釋：從還沒 merge 的分支再開分支，PR 指向前一個分支，工具有 Graphite（被 Cursor 收購）、JJ，GitHub 與 GitLab 也在加原生支援。

• P把 review 移到 PR 之前：本地逐檔註解、注入回 agent、修完才推給團隊→ 練習
• Cstacked PR：從未 merge 的分支再開分支，PR 指向前一個；讓 300–800 行的小 PR 在多步驟功能上仍可行→ 畫地圖

AI 補充這段回答了一個很實際的問題：如果 agent 產出很快，人怎麼跟得上 review？Dillon 的答案是兩件事同時做。第一，**把 review 移到 PR 之前**——本地 review 讓他在推給團隊之前就已經逐行看過、逐行改過，PR 上的 code 是「他認可的」而不是「agent 剛吐的」。這是第 3 段「讀每一行」的工具化。第二，**限制每次產出的大小**——300–800 行不是隨便的數字，它是「一個人能真正讀懂」的上限；agent 可以一次產出三千行，但他刻意不讓它這麼做。stacked PR 是讓「小 PR」在多步驟功能上仍然可行的技術：每一步是一個獨立可審的 PR，但彼此有依賴順序。作者沒明說的一步：這兩個做法合起來，等於把 agent 的速度優勢用在「迭代次數」而不是「單次產量」上——這是他能維持 line for line 品質的結構性原因。

術語:atomici

17. annotate / last：對話堆成 spec 51:13–52:49

Plannotator 另外兩個功能做同一件事：`/plannotator annotate <檔案>` 把檔案打開讓你畫重點、加註解再送回 harness（例如叫 agent 寫一份新 ORM 抽象的 speci 到 markdown，再標註回饋）；`/plannotator last` 把 agent 最後一則訊息載進註解工具編輯。他更常用後者：在一來一回的訊息裡建立對實作計畫的共同理解i，而不是先寫 markdown；累積久了看起來越來越像 spec，等他相信雙方有清楚的共同理解，才叫它寫成 markdown 並實作。

推理因為上一段的 review 功能已經證明「人的註解直接注入 agent session」這條回饋路徑很有效，所以 Dillon 把同一條路徑用在 code 之外。`/plannotator annotate <檔案>` 把檔案打開讓你畫重點、加註解再送回 harness——例如先叫 agent 寫一份「新 ORM 抽象」的 spec 到 markdown，再標註回饋，整個循環很緊。`/plannotator last` 則把 agent 最後一則訊息載進註解工具讓他直接編輯。他說自己更常用後者：在一來一回的訊息裡建立對實作計畫的共同理解，而不是一開始就寫 markdown；累積久了這些訊息看起來越來越像一份 spec，等他「終於相信」雙方對要做什麼有清楚的共同理解，才叫 agent 寫成 markdown 並實作。

• Cshared understanding：spec 不是先寫好再實作，而是對話累積到「終於相信有共識」才固化成 markdown→ 畫地圖
• P/plannotator last：直接編輯 agent 最後一則訊息，把來回對話堆成 spec→ 練習

AI 補充這段藏著一個對「spec-driven development」的重要修正。一般想像是「先寫好 spec → 再叫 agent 實作」，但 Dillon 的順序是「對話 → 對話漸漸長成 spec → 最後才固化成文件」。差別在於 spec 不是他一個人憑空寫的，而是他和 agent 在來回中「協商」出來的——agent 提案、他標註、agent 修、他再標註。這對回第 10 段談 PRD 時的共識：交接物從「描述」變成「實物」；這裡 spec 也不是描述，而是「已經對齊過的理解」的快照。`/plannotator last` 之所以比 annotate 常用，是因為它讓「編輯 agent 的話」變得跟「回訊息」一樣輕——他不是在寫文件，而是在修正 agent 的理解。作者沒明說的一步：「終於相信有共同理解」是一個判斷，而做這個判斷的能力正是第 6、7 段說的 senior 判斷力；junior 可能會太早相信。

18. /tree：先問自己知道答案的問題 52:49–54:50

Pi 的 `/treei`（Pi 刻意沒有 sub-agent）。他開始一項工作（例如在 Artifacts 產品加 endpoint）的方式是問 agent 一些他已經知道答案的問題：Honoi 是什麼、怎麼設定、API 有哪些；agent 去研究，來回幾次直到他放心它的理解正確，然後 `/tree` 跳回對話根部（可選擇摘要、像 compactioni）。他通常讓那則結論留在樹上或寫進 markdown，再從零 context 的根部問下一個主題（Durable Objects 怎麼做 SQLite 儲存）。這樣一個個建立 agent 對技術與模式的理解，得到精簡小結帶回主線，再用 Plannotator 迭代出 tech spec。

推理因為上一段說共同理解要靠來回累積，所以這段講累積的起點。Pi 有 `/tree`，而且刻意沒有 sub-agent。他開始一項工作（例如在 Artifacts 產品加一個 endpoint）的方式是問 agent 一些他已經知道答案的問題——通常是技術棧、library、框架或 codebase 既有抽象：Hono 是什麼、怎麼運作、怎麼設定、API 有哪些。agent 去研究，來回幾次直到他對它的理解放心，然後 `/tree` 跳回對話的根部（可以選擇像 compaction 一樣先摘要）。他通常讓那則結論留在樹上、或把最後一段寫進 markdown，再從零 context 的根部問下一個主題：Durable Objects 怎麼做 SQLite 儲存、API 是什麼。這樣一個個建立 agent 對他要用的技術與模式的理解，每個分支得到一段精簡小結，帶回主線後再用 Plannotator 迭代出 tech spec。

• C/tree：對話當成一棵樹，每個主題在自己的分支研究，只把審過的精簡小結帶回根部——你就是自己的 sub-agent→ 畫地圖
• P開始一項工作：先問 agent 你已經知道答案的問題（技術棧、library、既有抽象）→ 練習

AI 補充「問自己已經知道答案的問題」乍看是浪費 token，其實是整套方法裡最聰明的一步，理由有三。第一，**它是驗證**——他知道正確答案，所以能判斷 agent 的研究對不對，錯了就糾正；這是第 6 段「senior 判斷力還在」的直接應用。第二，**它是 context 的建材**——agent 研究後的結論會留在對話裡，之後實作時模型「已經知道」Hono 怎麼用，不用他每次重講。第三，**它是分區的**——每個主題在自己的分支上研究，`/tree` 跳回根部後主線只留一段小結，不會被研究過程的雜訊塞滿。這正是第 15 段「把注入 context 的東西減到最少」的實作：他不是不給 context，而是只給「經過他驗證的精簡結論」。作者沒明說的一步：為什麼 Pi「刻意沒有 sub-agent」在這裡被特別提出來——因為 `/tree` 做的事在其他 harness 裡通常由 sub-agent 做（派一個 agent 去研究、帶摘要回來），但 sub-agent 的摘要是模型自己決定的，而 tree 的小結是 Dillon 親手審過的。

19. spec 長得像 code 54:50–57:54

他的 tech spec 不像 PRD，而是 TypeScript 型別與 interfacei：邊界在哪、需要哪些 adapteri 與實作；再讓 agent 列出要實作的 call stacki（改既有的還是開新路徑、每一步的輸入輸出型別與可能錯誤）；最後寫出它要寫的測試（red-green-refactor TDDi）。整份約 650–1,000 行。理由：給 agent 一個 function 它多半能正確實作，agent 真正差的是抽象的設計與組合，所以用真正的 code 對齊「形狀」，把它擅長的實作交出去。主持人回應：這解決了他對 spec-driven developmenti 的根本問題（他太探索式，不可能先寫出完美 PRD，「我要看 receipts」），並分享自己用 red-green 先寫紮實的測試再讓 LLM 實作，效果好十倍；反之「幫既有 function 寫測試」全是垃圾。

推理因為上一段研究分支的小結已經讓 agent 懂了技術棧，所以這段的 spec 可以直接用 code 的語言寫。他的 tech spec 有三部分：(1) TypeScript 型別與 interface——邊界在哪、需要哪些 adapter 與各 interface 的實作；(2) 讓 agent 列出它要實作的 call stack——是改既有的還是開全新路徑、每一步的輸入輸出型別與可能的錯誤；(3) 讓 agent 先寫出它將要寫的測試（red-green-refactor 的 TDD）。整份約 650 到 1,000 行。理由是他對 agent 能力的判斷：給它一個 function，它多半能正確實作；agent 真正差的是「抽象的設計與組合」，那是他花最多時間跟它搏鬥的地方。所以用真正的 code 對齊「要建的東西的形狀」，把它擅長的實作交出去——不完美，LLM 還是會做蠢事，但他在慢慢磨掉那些。主持人回應這解決了他對 spec-driven development 的根本問題：他太探索式，不可能先寫出完美的 PRD（Dillon：對任何人都不現實；主持人：有人說成功，但「我要看 receipts」）；他自己的類似經驗是 red-green——先自己寫或讓 LLM 寫很紮實的測試，再讓 LLM 實作，效果好十倍；反過來「幫既有 function 寫測試」全是垃圾。

• Cagent 擅長填空、不擅長設計空格；人設計空格（型別、interface）、agent 填實作——spec 因此長得像 code→ 畫地圖
• Ptech spec 三部分：型別與 interface、call stack、先寫測試；650–1,000 行→ 練習
• E主持人：先寫紮實測試再讓 LLM 實作，效果好十倍；反過來幫既有 function 寫測試全是垃圾→ 存＋演練
• Espec 650–1,000 行，PR 只有 300–800 行：spec 比實作長，思考成本刻意放在動手前→ 存＋演練

AI 補充這段是整集方法論的核心，值得把邏輯鏈拉直：**agent 擅長「填空」、不擅長「設計空格」→ 所以人負責設計空格、agent 負責填 → 而「空格」在 TypeScript 裡就是型別與 interface**。型別是最精確的「形狀描述」：一個 interface 說清楚輸入什麼、輸出什麼、可能丟什麼錯，比任何自然語言 PRD 都不模糊。這也對回第 5 段：macro 難題（架構、抽象、資料流、型別）本來就是人負責的，Dillon 只是把它寫成 agent 能直接消費的格式。三個部分各有作用：型別定「形狀」，call stack 定「路徑」（防止 agent 開一條你不想要的新路），測試定「驗收」（防止它實作出「能過型別檢查但行為不對」的東西）。主持人的 red-green 經驗是同一原理的另一個切面：測試也是「空格」——先定好，agent 填實作。而「幫既有 function 寫測試全是垃圾」的原因是：那時 agent 是在「描述現況」而不是「填空」，它會把 bug 也當成規格。作者沒明說的一步：650–1,000 行的 spec 看起來很長，但對照第 16 段每個 PR 300–800 行，spec 其實比實作長——這代表他把主要的思考成本刻意放在動手前。

20. /tree 細節：三種回法、幾百則訊息 57:54–1:00:12

主持人追問 tree 的分支怎麼「拉回來」。Dillon：`/tree` 跳到對話別處有三個選項——什麼都不做、自動摘要、給 prompt 自己摘要；它不會回滾 git，只影響 context 與對話。他偏好什麼都不做：把分支最後一則訊息整理成「你需要知道的事」，用 `/copyi` 帶到別處，或寫成 markdown 從別的點引用。一個 Pi session 可能幾百則訊息：從前端到資料庫做完、用 Plannotator review、再跳回第零則訊息寫 e2e 測試與測試 harness，各自有分支；可以給位置加標籤讓 agent 引用。他說沒有 tree 沒辦法工作——「你就是自己的 sub-agent」。

推理因為主持人猜想「是不是靠 compaction 把摘要帶回根部」，所以 Dillon 先把 `/tree` 跳轉的三個選項講清楚：什麼都不做、自動摘要、給 prompt 讓它自己摘要——而且它不會回滾 git，只影響 context 與對話。他偏好「什麼都不做」：先把分支的最後一則訊息整理到「這些是你需要知道的事」的程度，再用 `/copy` 帶到對話的另一個位置，或叫它寫成 markdown 從別的點引用。接著描述規模：一個 Pi session 可能有幾百則訊息——從前端到資料庫在一個 session 裡做完、用 Plannotator review 來回幾次，再跳回第零則訊息（零 context）寫 e2e 測試與測試 harness，那又是幾百則訊息、各有自己的分支；可以給位置加標籤，叫 agent 去看某個標籤。他的結論是沒有 tree 沒辦法工作——「你就是自己的 sub-agent，你在做 sub-agent 的工作」。

• P/tree 跳回時選「什麼都不做」：自己手動整理小結再 /copy，不讓模型決定留什麼→ 練習
• A「你就是自己的 sub-agent」：sub-agent 的價值全都要，代價（摘要由模型決定）不接受→ 批判類比

AI 補充「偏好什麼都不做」是這段最值得注意的選擇，因為它跟直覺相反——有自動摘要為什麼不用？理由接回第 18 段：自動摘要由模型決定留什麼，而 Dillon 要親自決定。「先把最後一則訊息整理成『你需要知道的事』」其實是他手動做的 compaction——差別在於這份摘要經過他審核、修改（用 `/plannotator last`）、確認正確，才被帶走。「不回滾 git」這句也很重要：tree 操作的是「模型知道什麼」，不是「檔案長什麼樣」，所以他可以在實作完成後跳回零 context 寫 e2e 測試——這時 code 已經在那裡，但模型不再帶著實作過程的所有雜訊，只看最終結果來寫測試。這其實是主持人在第 19 段說的「先有紮實測試」的另一種實現：測試 agent 沒有被實作 agent 的假設污染。「你就是自己的 sub-agent」總結了整套方法：sub-agent 的價值（隔離 context、分工探索）他全都要，但 sub-agent 的代價（摘要由模型決定）他不接受，所以自己扮演那個角色。

術語:e2e testi

21. 為何不用 sub-agent 1:00:12–1:02:00

Dillon 在接受 tree 前就發文說不愛 sub-agenti：它們擅長探索、很方便，但一切取決於核心 agent 的判斷，帶回的摘要常不是他真正要放進主 context 的東西，還會妨礙自己的思考。他已經對「context 如何影響模型表現」建立相對的直覺（仍然模糊、非確定性i），所以現在必須由他自己決定 context 裡放什麼，因為 agent 還不夠好。主持人同意：sub-agent 唯一有價值的場合是一大塊工作會撐爆 context、用它讓 compaction 優雅一點，但他不這樣工作；「設計師 sub-agent、架構師 sub-agent、review sub-agent」的敘事是垃圾。

推理因為上一段的 tree 用法本質上是「自己做 sub-agent 的工作」，所以這段解釋為什麼不把這件事交給真的 sub-agent。Dillon 在接受 tree 之前就發過推文：sub-agent 擅長探索、很方便，但一切取決於核心 agent 的判斷——它帶回來的摘要或 context 常常不是他真正想放進主 context 的東西，還會妨礙他自己的判斷與思考。他已經對「context 如何影響模型表現」建立了相對的直覺（他自己說仍然很模糊、非確定性），所以現在必須由他來決定 context 裡放什麼，因為 agent 還不夠好。主持人同意：sub-agent 唯一讓他欣賞的場合是「一大塊工作會撐爆 context，用 sub-agent 讓 compaction 優雅一點」，但他本來就不用大塊工作，所以結論一樣——「設計師 sub-agent、架構師 sub-agent、review sub-agent」的敘事是垃圾。

• Csub-agent 的問題不在能力，在誰做「摘要」這個決定——摘要就是決定什麼進主 context，是最重要的 macro 決定→ 畫地圖

AI 補充把整段的邏輯收成一句：**sub-agent 的問題不在能力，在誰做「摘要」這個決定**。摘要就是「決定什麼進主 context」，而這段之前介紹的所有工具（極簡 harness、tree、/copy、Plannotator last）都是為了讓這個決定留在 Dillon 手上。sub-agent 把它交給模型，這在他看來是把最重要的 macro 決定（第 5 段）外包出去。「妨礙判斷與思考」這句也值得展開：當 sub-agent 帶回一份漂亮的摘要，人很容易接受它而不再自己想——這跟第 7 段主持人擔心 junior 吃「止痛藥」是同一種風險，只是發生在 senior 身上。主持人的「唯一例外」很精確：sub-agent 真正解決的是 context window 的容量問題，不是判斷問題；而如果你的工作單位本來就小（300–800 行的 PR），容量問題就不存在。「designer / architect / reviewer sub-agent 是垃圾」的原因也可以推出來：那些角色的價值恰恰是判斷力，而判斷力正是模型還不夠好的部分。

22. 看得見的 queue：把品味放進 skill 1:02:00–1:04:31

收尾回到 loop 的話題與 Armin 的文章。Dillon 承認現在的工作流很累：能同時做兩三個功能或 debug 一個 Sentry 問題，品質接近甚至等於手寫，但很耗神。他能想像一個 queuei：他丟功能需求，agent 在一個 pane 裡開始探索技術、建立 context 的 session，做完先寫一版 tech spec 再迭代，後續 agent 知道「Dillon 喜歡輸入輸出型別、interface、call stack」。review 也一樣：過去幾週他把自己在設計、架構、review 上的品味寫進 skilli，也許做成 Flow agenti（Astro 團隊的 framework）先做第一輪 review；不期待一開始就好，但若能省下五分鐘、不用每次糾正 `is Record`、一路傳 `unknown`、重複驗證這種事，就是勝利。

推理因為前面幾段建立的方法全靠人親手控制 context，所以 Dillon 在收尾時承認代價：這個工作流很累，他能同時做兩三個功能或 debug 一個 Sentry 問題，品質接近甚至等於手寫，但很耗神、很煩。然後他描述能想像的世界：一個 queue，他丟進「我要這個功能」，某個 agent 接走，在一個 pane 裡開始那個「來回探索技術、建立 context」的 session，做完後先寫一版 tech spec，再迭代；後續的 agent 會知道「Dillon 喜歡輸入輸出型別、interface、call stack」。review 也一樣：過去幾週他在把自己在軟體設計、架構、review 上覺得有價值的東西寫進 skill，也許做成 Flow agent（Astro 團隊出的 framework）先做第一輪 review、套用他的品味與原則。他不期待一開始就好，甚至不期待「好」，但如果能省下五分鐘、不用每次都糾正 `is Record`、一路傳 `unknown`、重複驗證這種事，就是勝利。他說自己正往那個方向走，但還有很多工作。

• P把幾百次 review 裡反覆糾正的同一件事寫進 skill，讓 agent 做第一輪 review；省五分鐘就算贏→ 練習

AI 補充這段跟第 11 段的立場放在一起看才完整：他不是反對 loop，而是反對「今天、以今天的成本、由模型決定一切」的 loop。他想像的 queue 有三個跟 lab 敘事不同的特徵。第一，**queue 裡的每一步都是他已經手動走過幾百次的步驟**（研究分支 → spec → 迭代 → review），自動化的是「流程」，不是「判斷」。第二，**品味是被明確寫下來的**——skill 裡寫的是「Dillon 喜歡型別、interface、call stack」「不要 `is Record`」「不要一路傳 `unknown`」，這些是他在幾百次 review 裡反覆糾正的東西，現在變成可執行的規則。第三，**期望值很低**：省五分鐘就算贏。這跟 lab 說的「10x」形成對比——他要的不是替代自己，而是把「每次都要糾正的同一件事」拿掉。整集的弧線到這裡收束：從「六個月沒寫 code、更累」出發，經過「為什麼累」「怎麼維持品質」「哪些工具」，最後到「怎麼把已經穩定的部分交出去」——這正是第 2 段 Ethan 說的「成為新工具的 craftsman」的具體長相。