不要先叫 AI 寫 code：
先讓它把系統 讀懂

先講結論：AI agent 的第一個任務應該是 comprehension

這支 talk 的重點不是「AI 不能寫程式」。Priscila 的意思更精準：在一個有 15 年歷史、每天約 100 個 PR merge、被 100,000 個組織依賴的 codebase 裡，直接叫 AI 改 code 很容易跳過最重要的步驟，也就是理解現有架構、慣例、測試方式與歷史原因。

她分析自己 116 次 Claude sessions 後發現，67% 的使用其實是 comprehension，只有 2% 是直接 code generation。這組數字把常見敘事反過來：AI 工具不是只讓工程師更快打字，而是可以先幫工程師把陌生系統變成可判斷、可修改、可驗證的工作空間。

真正的解鎖不是「讓 AI 先寫」，而是「讓 AI 先把它找到的系統脈絡講清楚，讓人類驗證 mental model」。— 本頁依 YouTube metadata、影片描述與公開活動摘要整理

為什麼 vibe coding 在大型系統裡會失真

vibe coding 對 prototype、side project、一次性 demo 很有價值，因為錯誤成本低、上下文小、設計歷史短。但企業級產品不是這樣運作。舊 code 的命名、抽象、測試、feature flag、資料遷移與 backward compatibility，通常比單次修改本身更重要。

如果 agent 沒有先理解這些脈絡，它產生的 patch 可能看起來可編譯，卻破壞團隊慣例、繞過既有 abstraction，或在錯誤層級修問題。這就是影片描述裡提到的 slop 來源：不是模型完全不會寫 code，而是它拿著錯的 mental model 開始寫。

catch me up skill：把理解變成可重複工作流

Priscila 建了一個個人 skill 叫做 catch me up。它不是要求 agent 直接改檔，而是先用六種探索模式幫她理解系統：architecture、conventions、feature traces、syntax、testing、history。這些模式對應工程師平常接手任務時會問的問題，只是把它們明文化成 agent 可執行的流程。

這個設計的價值在於降低「亂問 AI」的隨機性。與其每次都臨場寫 prompt，不如把 code comprehension 拆成固定入口：這個 feature 從哪裡進來？團隊慣例是什麼？測試怎麼寫？過去為什麼這樣設計？agent 先回答這些問題，人再決定下一步是否值得讓它 plan 或 implement。

六種探索模式各自解決什麼問題

architecture 幫你建立系統邊界與模組關係；conventions 找出團隊在命名、檔案結構、錯誤處理與 UI pattern 上的慣例；feature traces 從使用者行為一路追到資料與副作用；syntax 釐清語言或框架細節；testing 找到該怎麼驗證；history 則回頭看 PR、commit 或文件，理解現在這個形狀的原因。

這六類問題合起來，剛好對抗 agent 最容易犯的錯：只看局部檔案、用通用答案覆蓋團隊脈絡、忽略測試策略、把歷史約束當成壞設計。它也讓人類 reviewer 更容易介入，因為你可以先審 mental model，再審 patch。

實務啟發：把 agent workflow 改成「先讀懂，再動手」

來源與限制

來源包含 YouTube 原影片、watch metadata、影片描述，以及公開活動摘要。YouTube metadata 顯示有英文自動字幕 track，但本輪 timedtext 端點回傳空內容，且本機沒有 yt-dlp；因此本頁以可得 metadata / description / public abstract 做重點整理，時間碼為依 17:05 影片長度與內容線索整理的 approximate content map，非官方章節。