新開發範式：
Vibe Coding 到 Spec-Driven
上一課看完模型怎麼「思考」，這一課換人類上場：用 AI 寫程式的四種姿勢。 需求都一樣——「做一個報帳單審核小工具」——但你交給 AI 的東西完全不同。 點四個分頁比比看（示範文本，用來對照範式的差異）：
右邊的實驗場是真的 Python（在你的瀏覽器裡跑，不用安裝任何東西）。 首次載入約需 30–60 秒，正好夠你讀完第 1 節。這一課右邊只有兩個實驗， 但其中一個的 token 帳是真的用 tiktoken 量出來的——改壞了重新整理就復原。
Vibe Coding：講人話，讓 AI 寫
這個詞是 Andrej Karpathy 在 2025 年初丟出來的：與其逐行寫码，不如 「完全順著感覺走」——描述、生成、跑跑看、再描述。工具就是你身邊那些： Claude Code、Cursor、GitHub Copilot。一個典型的 vibe 迴圈長這樣：
注意這個迴圈裡人做了什麼：沒讀一行程式碼，但每一輪都動手驗證結果。 這就是 vibe coding 的安全邊界——改壞的代價小（自用、可重來）、 對錯一眼可辨的東西，vibe 是最快的路。反過來，會碰錢、碰資料、 別人要接手維護的東西，「能動」跟「能上線」中間差的就是接下來三站。
Agentic Engineering：從「下指令」到「帶團隊」
當 AI 從「補全下一行」進化成「自己開檔案、跑測試、改到過」的 agent （上上課的主角），工程師的工作跟著變形： 像帶新同事一樣帶它——任務拆到可驗收、規範寫到可查閱、進度有檢查點。
最具體的動作是把「每次都要重講的事」寫成專案脈絡檔。 Claude Code 讀 CLAUDE.md、Cursor 讀 rules 檔，格式就是普通 Markdown：
然後把「做完」定義成可驗證的條件（測試通過、lint 全綠、行為對照清單打勾）， 讓 agent 對著驗收條件自我修正，而不是對著你的耐心修正。 到右邊 1️⃣ 挑幾個專案情境，看你該站在光譜的哪一格。
Context Engineering：餵對資訊，比餵多資訊重要
第 1 課說過：上下文窗再大，「塞越多」都不等於「答越好」， 而且每個 token 都要錢。Context engineering 就是把「該給什麼」當工程問題管理： 檢索出相關的知識段落（而不是整份文件）、把冗長歷史摘要（而不是全文重播）、 規範放在固定位置（而不是每次口頭重講）。
右邊 2️⃣ 的帳是真的：同一個客服問題，「全塞」757 個 token， 「檢索相關段＋歷史摘要」236 個——省 69%（tiktoken o200k_base 實測，2026-08）。 每輪對話都付一次，乘上流量就是月底帳單的差距； 而且無關內容變少，模型被雜訊帶偏的機率也跟著降。
| 實務動作 | 取代的壞習慣 |
|---|---|
| 檢索後只塞相關段（下一課 RAG 的本行） | 整份文件複製貼上 |
| 歷史摘要＋保留最近幾輪原文 | 對話全文無限重播 |
| 規範進 CLAUDE.md / system prompt 固定位置 | 每次對話重新交代一遍 |
| 工具與參考資料按需載入（要用才給說明書） | 把所有工具說明全掛上去 |
Spec-Driven：規格是唯一真相源
Vibe 的極限在「你講的話就是規格」——講漏了，AI 只能猜。 Spec-driven 把這件事翻過來：行為先寫成結構化規格， 需求變更先改 spec、再讓 AI 依 spec 改實作，審查時看的是「diff 是否符合 spec」。 OpenSpec 的規格長這樣（Requirement ＋ 可驗證的 Scenario）：
GitHub 的 Spec Kit 把整條流程做成指令（在 Claude Code、Copilot 等代理裡用）：
BMAD 則是把這條流程角色化的多 agent 框架（分析師、PM、架構師、開發各司其職）。 工具會換，骨架不變：規格在前、實作在後、驗收對規格。 什麼時候值得付這個「先寫規格」的成本？右邊 1️⃣ 的光譜圖給你判斷基準—— 多人維護、合規要求越重，越該往這一站走。
本課名詞速查卡
發講義用的濃縮版——一個名詞一句話：
| Vibe Coding | 自然語言描述需求、AI 生成程式，人只做測試判斷——低風險小工具的最快路徑。 |
| Agentic Engineering | Vibe 的專業版：重心在編排與監督 Agent——拆任務、設驗收條件、寫 CLAUDE.md 留脈絡。 |
| Context Engineering | 按需組裝最小正確資訊取代無限上下文迷信——實測同一問題省 69% token，還降低被雜訊帶偏。 |
| Spec-Driven Development | 規格是唯一真相源，AI 對規格實作與驗收——工具如 Spec Kit／OpenSpec／BMAD。 |
換你動手
在右邊 2️⃣ 把兩個開關全關，token 掉到多少、省幾成？再各只關一個——知識和歷史，哪個開關省得多？
在實驗區把 knowledge 改成 3000、history 改成 1200（模擬塞大文件＋長對話），算一天一萬輪的量。什麼規模下 context engineering 從「可有可無」變成「非做不可」？
「歷史摘要」有代價：想出三個「摘要會把事情弄壞」的具體情境，以及你會怎麼驗證摘要沒摘壞。（提示：想想被摘掉的訂單編號。）
卡住了？三題在 notebook 最後一格都有折疊解答——先自己做，再打開對照。
情境測驗
離開前試試看：下面的情境都真的會遇到。每題選一個你認為的最佳做法，選了馬上看得到解釋。
Q1 情境題
你週末 vibe 出一個報帳小工具自己用，很順手。主管看到說「很棒，下個月全部門 40 人都用它報帳」。上線前最該補的是？
從「自用」到「40 人碰錢的工具」，改壞的代價變了，開發姿勢就要跟著換站——這正是光譜圖的用法。該補的不是「重寫」而是「可驗證性」：測試蓋住金額與權限這些會出事的路徑、行為寫成規格，之後不管人改還是 AI 改，都有東西可對。A 低估了場景變化（vibe 的品質保證只有「你驗過的那幾條路」）；B 把 AI 的產能優勢整個丟掉，而且逐行重寫不等於有測試；D 搞錯了問題——缺的是驗收機制，不是生成品質。
Q2 情境題
你用 AI 代理改公司後端，發現每次新對話都要重講一遍「金額要用 Decimal」「改 API 要同步改測試」，偶爾忘了講它就犯。最好的解法是？
「每次都要重講」是 context engineering 最典型的病徵，藥方是把規則放進固定位置：CLAUDE.md 這類專案脈絡檔每次對話自動載入，規則從「口頭交代」變成「基礎設施」。A 方向對但劑量錯——三萬字全塞是「無限上下文迷信」，又貴又稀釋重點，硬規則只需要幾行；C 誤解了機制——新對話是全新的上下文，窗再大也不會自動繼承上一場對話；D 放棄得太早，這問題有標準工程解。
Q3 情境題
你的團隊接了一個金融客戶的案子，對方稽核要求「每個系統行為都要能對應到書面需求」。團隊平常用 vibe + agent 開發，速度很快。你該怎麼調整？
稽核要的是「行為 → 需求」的對應鏈，這正是 spec-driven 的本行：規格先行，每個行為都能回答「規格哪一條允許」，變更有提案紀錄。關鍵是 C 沒有放棄 AI——Spec Kit／OpenSpec 這類工具就是設計來讓 AI 在規格框架裡高速實作的。A 是事後補文件：反向整理出來的「需求」只是實作的鏡子，說明不了「為什麼該這樣」，稽核一問就穿幫；B 把工具和流程混為一談，手工開發沒有 spec 一樣不可追溯；D 不是工程對策。