Vibe Coding

航海日誌：AI 寫作的三層甲板，從提示、脈絡到載具工程

多數人以為「會跟 AI 講話」就等於「會用 AI」。其實從一句提示到交付一整套軟體，隔著三層甲板：提示工程、脈絡工程、載具工程。這篇用一個統計教學網站的真實開發，帶你看最深的那一層怎麼運作。

前面幾篇航海日誌，我帶各位船員看了不少用 AI 協助寫作、整理筆記、打造統計教具的實戰案例。我們一路用 Vibe Coding 把教科書變成可以互動的甲板，也讓 AI 副官替我們生成練習題、寫程式、做視覺化。

但這趟航程走到這裡，我想先停下槳，把一件事講清楚：和 AI 一起工作，其實有三層甲板。

很多人以為「會跟 AI 講話」就等於「會用 AI」。事實上，從你丟出第一句提示，到你能讓 AI 穩定地交付一整套統計教學軟體，中間隔著三道一道比一道深的水域。我把它們叫做：

Prompt Engineering（提示工程）——你怎麼喊話給舵手。
Context Engineering（脈絡工程）——你怎麼管理海圖與航海日誌。
Harness Engineering（載具工程）——你怎麼打造整艘船與一套航行制度。

這一篇，我們先把這三層甲板逐一走過；接著，我會用一個比過去稍微大型的開發案例——一個叫 vibe statistics 的統計教學網站——實際示範什麼叫 Harness Engineering，而且我會儘量講得讓第一次聽到這些名詞的船員也能跟上。文中提到的每一份原始文件，我都已經整理上傳，連結放在文末附錄，你可以邊讀邊對照。

第一層：Prompt Engineering，喊話給舵手

最表層的甲板，是提示工程。你把任務濃縮成一句（或一段）話，盡量把指令、受眾、格式、限制講清楚，讓模型一次就給出好結果。這是最多人停留的地方，也最容易撞上暗礁。

Q：我請 AI 解釋「p 值」，它給的定義時對時錯，到底哪裡出問題？

A：因為單一提示沒有約束，模型會直覺地給出「最常見」的講法——而 p 值最常見的口語定義，偏偏就是錯的（把它說成「虛無假設為真的機率」）。在提示工程這一層，解法是把要求寫死：指定受眾（大一學生）、要求嚴謹定義、並明確叫它「避開常見誤解」。同一個模型，換一句提示，答案的品質就天差地遠。

Q：我要 AI 出一題 t 檢定練習題，數字卻老是湊不出漂亮的結果。

A：這也是提示層的典型問題。你心裡有一堆沒講出口的約束——樣本數要適中、結果最好落在某個顯著水準附近、數字最好是整數。模型讀不到你的心。把這些限制全部寫進提示，命中率立刻上升。

這一層的天花板：每換一個話題，你就得把背景重講一次；對話一長，它就忘了你最早的要求；而且它看不到你的專案——你沒辦法只靠一句提示，叫它去改一個跨好幾個檔案的統計軟體。當你撞上這面牆，就該往下潛一層。

第二層：Context Engineering，管理海圖與航海日誌

第二層甲板，關心的不再是「你說了哪一句話」，而是「模型此刻看得到什麼」。它的視野只有一個有限的上下文視窗（context window）；你放進去什麼、怎麼排、何時清掉，決定了它的表現。

Q：我把整本統計講義貼給 AI，它反而開始答非所問、抓錯重點？

A：這是脈絡工程裡最經典的暗礁——上下文太長造成的「漂移」（drift），以及「迷失在中間」（lost in the middle）：模型對開頭和結尾印象深刻，中間的關鍵反而被稀釋掉。解法不是塞更多，而是塞得更準：先檢索出真正相關的章節、做分段摘要，只把當下需要的那張海圖攤在桌上。

Q：開發統計軟體時，AI 改了 A 檔案，就忘了 B 檔案的命名約定。

A：因為 B 檔案根本不在它的視野裡。這一層的功夫，是維護一份「常駐脈絡」——專案結構、命名規範、共用的型別與函式定義——讓這些約定持續待在上下文裡，而不是每次重講。

Q：對話拉長之後，AI 開始自相矛盾。

A：上下文被雜訊塞滿了。適時請它摘要、壓縮、甚至重置脈絡，把長對話收斂成幾條乾淨的結論再繼續。這個「主動摘要以對抗漂移」的動作，正是我們待會兒示範時的關鍵手法。

這一層的核心：你管理的不是一句話，而是一整片資訊的潮汐。但就算海圖管得再好，你會發現——一個人盯著對話框，仍然撐不起一艘大船。

第三層：Harness Engineering，打造整艘船與航行制度

最深的一層，是載具工程。到了這裡，模型只是引擎；你真正在設計的，是承載這具引擎的整艘船：它能用的工具、它讀的規範文件、它跑的測試、它自我校正的循環、以及把這一切串起來的工作流程。

Q：脈絡都管好了，AI 寫的統計模組還是會壞，怎麼讓它自己抓錯？

A：靠一個會回饋的載具。給它一組可執行的測試，讓它寫完就跑、跑完看輸出、錯了自己修——把「生成 → 驗證 → 修正」變成一個閉環，而不是你一行行替它除錯。

Q：一個大型統計教學網站有十幾個模組，怎麼讓 AI 不要每次都從零開始？

A：用規範文件（spec）、目錄結構、工作流程當作它的軌道。每一次開發都在同一套規範上推進，模型換了、對話斷了，軌道還在。

Q：我希望整個開發過程可以被重現、被別人接手。

A：那就別把知識留在某一次對話裡——把它文件化。需求文件、架構文件、風格指南……讓「船」承載知識，而不是靠艦長的記憶。對話會散，文件不會。

這一層的核心：你設計的，是一套讓 AI 能穩定、可重複、可交接地工作的環境。提示與脈絡，都成了這套載具裡的零件。

從概念到甲板：vibe statistics 的造船全紀錄

講完三層，接下來這趟航程，我要帶各位實際下水。前面幾篇的案例都還算輕巧，這次我們挑一個稍微大型一點的軟體——把我過去四個各自獨立的統計小工具（描述統計、機率模擬、Z 檢定練習、Excel 檢定工具箱），整合成一個零安裝、打開瀏覽器就能用的繁體中文教學網站，取名 vibe statistics。

關鍵在於：我從頭到尾沒有自己寫半行 spec，也沒有自己畫設計稿。 我做的，是先打造一套「讓 AI 能穩定產出這些東西的載具」。整個流程分成三步——廣泛激盪、落成規範、長出設計。我們一步一步看。

第一步：先聊開——用「選擇題訪談」廣泛談需求

我一開始就把四個既有的小工具丟給 Claude，請它先看、先分析，別急著動手。它很快抓出一條我自己都沒明講的主線：描述統計 → 機率直覺 → 推論檢定 → 上機練習 → 用自己的資料分析——這正好是一條完整的教學路徑，可以直接當網站骨架。

但這裡我馬上踩了一個許多人會犯的錯，也順手示範了該怎麼修正。Claude 一度以為我要牠「現在就在對話裡把網站做出來」，開始搭骨架。我喊停，把真正的意圖講清楚：

我不是要你在聊天過程中做這個專案，而是我們先廣泛地談需求；等談完、你完全理解之後，我會上傳一份開發文件規範，請你依規範寫出規範文件。之後我再拿去 Claude Design 做視覺、Claude Code 寫程式。

這一澄清，等於把 AI 的角色從「施工的工人」切換成「需求訪談者」。而為了讓訪談不發散、不漂移，我做了一個關鍵動作——我請牠「一題一題用選擇題問我」。

別小看這個動作，它其實就是第二層脈絡工程的精髓。一次只問一題、每題給我選項，好處是：每一輪對話都很短、不堆積雜訊；每個決定都被明確記下來；我也不必一次面面俱到地空想。於是訪談像剝洋蔥一樣一層層定案：

給誰用？→ 公開自學網站。在什麼裝置？→ 電腦為主。
第一版範圍？→ 就把四塊整合好，不擴充（邊界清楚，直接擋掉日後的功能蔓延）。
導覽結構？→ 入口頁 + 各單元各一頁。
要不要記錄使用者資料？→ 完全不記，關頁清空（除了 API 金鑰）。
公式怎麼呈現？→ 要漂亮的數學排版。圖表？→ 統一套件。語言？→ 只做繁體中文。

訪談中最精彩的，是 AI 主動幫我擋下的幾顆暗礁

好的訪談者不會只記錄你的答案，還會在你要踩坑前拉住你。這場對話裡，Claude 至少擋下四顆暗礁，每一顆都值得初學的船員記下來：

它去查證、不憑記憶。 聊到 AI 評分要用 Gemini 時，我隨口問「是不是還有模型版本的問題？」牠沒有亂猜，而是當場上網搜尋，查出舊版 Gemini（1.0／1.5）已經停用、呼叫會直接回 404，2.0 系列也將在 2026 年 6 月關閉。於是牠建議：模型名稱絕對不能寫死成一個字串，要做成可切換的下拉清單，哪天某版本失效，使用者自己換一個就好，不必我重新發布網站。
它抓出我自己沒發現的矛盾。 我先選了「入口頁＋各單元各一頁」的多頁架構，後面又選了「單頁式應用（SPA）」。牠立刻指出這兩者表面打架，並說明怎麼共存：用前端路由在「邏輯上的多頁、技術上的單頁」之間切換。更重要的是，牠預先點出 GitHub Pages 部署 SPA 的經典 404 陷阱，直接定下用 HashRouter（網址帶 #） 來閃避。
它替每個技術選擇附上理由。 公式選 KaTeX 而非 MathJax（快、輕、適合純前端）；圖表用 Chart.js 為主、少數客製互動用輕量 SVG（不硬塞 D3 把整站搞複雜）；統計運算改用現成的 jStat，但加一道「標準答案驗證」——每種檢定都要拿 Excel／R 算出的答案來對，誤差超過萬分之一就不准上線。教學網站最不能出錯的就是數字，這道關卡是牠主動加的。
它連配色都不要我空想。 談到主色時，牠直接在對話裡視覺化三個候選的綠讓我挑，我選了 B 草綠（#639922）。牠當下補了一個統計專屬的體貼提醒：輔助色珊瑚橙代表「達顯著／拒絕虛無假設」，但絕不能用紅色——因為「拒絕虛無假設」在統計上常是好結果，用紅色會嚇到學生；而且珊瑚橙和綠對紅綠色盲不友善，所以狀態一律「顏色＋文字標籤」雙重標示。

收尾前，請 AI 做完整盤點——這就是「摘要對抗漂移」

訪談談了十幾輪，上下文已經很長。在請牠動筆寫文件之前，我請牠把所有定案完整盤點一次。牠分成「產品層面 / 技術層面 / AI 評分 / Design System」四大塊，把每一條決定重述清楚，讓我逐條確認無誤。

這個動作，正是第二層那片「漂移」暗礁的解藥：在進入下一個大階段之前，主動把長對話收斂成一份乾淨的摘要。 後面 AI 寫的八份文件，幾乎就是照著這份盤點長出來的——盤點準了，文件才不會走鐘。

這整場需求訪談的逐句紀錄，我放在附錄的 vibe-statistics-dialogue.md，想看 AI 怎麼一步步把需求問出來的船員，可以直接翻。

第二步：上傳「Harness 規範」，把共識長成一整套文件

盤點確認後，重頭戲來了。我上傳了一份文件——它的本名就叫 Harness Engineering 規範（03-harness-spec-compact-v2.md）。你可以把它想成「一份規定文件該長什麼樣的文件」，一張造船廠的標準藍圖。我請 Claude 依這份規範，把剛才盤點好的共識，寫成一整套軟體開發文件。

注意這個巧合——或者說，這根本不是巧合：我們這篇文章談的第三層「載具工程（Harness Engineering）」，正是我實際拿來造這艘船的那份規範的名字。這一步，就是 Harness Engineering 本人。

這套文件，就是這艘船的龍骨。規範要求七份，我再請牠獨立多寫一份給設計用的，總共八份，每一份各司其職。我用航海的方式幫初學者解釋它們是什麼：

文件	白話來說，它是船上的什麼	作用
`spec.md`	船的憲法	產品與功能的「最高仲裁依據」。任何方案和它衝突，以它為準。寫明做什麼、明確不做什麼（擋功能蔓延）、驗收標準、絕對禁止的工程行為。
`design.md`	技術海圖	技術設計的單一真相來源：每個技術選擇「為什麼選它」、系統怎麼分模組、怎麼部署、出事怎麼回滾、那道標準答案驗證的細節。
`design-system.md`	船的塗裝規範	視覺設計原則：主色、字形、圓角、語意配色，交給設計 AI 用。
`ai-rules.md`（即 `CLAUDE.md`）	船員守則	AI 的權限邊界：哪些事可以自己做、哪些要先問人類、哪些是絕對紅線（例如：絕不把 API 金鑰寫進程式碼）。每次開工必讀。
`roadmap.md`	駕駛艙儀表板	進度的單一真相來源：用樹狀的工作分解列出每個里程碑、現在做到哪、卡在哪。
`log.md`	航海日誌（只進不出）	決策與踩雷紀錄，只能新增、不能竄改。事後要追究「當初為什麼這樣決定」，全看它。
`journal.md`	對外的見聞素材庫	專門攢「可以拿去寫部落格、發社群」的料，還會標記每條「可講／不可講」——我現在寫的這篇，原料就是從這裡來的。
`README.md`	碼頭的迎賓牌	給第一次接觸專案的人看：這是什麼、怎麼安裝、有哪些功能。

這八份文件擺在一起，威力就出來了。它們之間有明確的位階（憲法 spec.md 最大），有分工（技術歸 design.md、外觀歸 design-system.md、進度歸 roadmap.md），還有記憶（log.md 把踩過的雷沉澱成「硬性教訓清單」，下次開工自動避開）。

連 AI 寫這八份文件的順序都不是隨便的——這也是載具思維的一部分。牠先寫 spec.md，因為其他文件都要引用它定義的功能編號（F-CORE、F-DESC、F-TOOL…）；接著把 log.md 用五筆「決策紀錄」開檔，好讓 design.md 裡「為什麼選 React／HashRouter／jStat」的引用不會指向空檔；而 roadmap.md 最前面三個里程碑，被規範強制排成「先把空殼部署上線 → 打通整條鏈路 → 再做最小可行產品」，功能單元一律排在後面。先讓水管通水，再裝水龍頭。

這就是 Harness Engineering 的精髓：知識不是綁在某一次對話裡，而是攤進這一整套會互相支撐的文件。換了一個新的 AI、開了一個新對話、甚至換個人來接手，只要讀這套文件，就能站回同一條航線上。對話會散，這艘船不會。

第三步：依規範文件，讓設計 AI 長出設計系統與網站雛形

龍骨架好，接著就能讓專業分工上場。我把上面那套文件交給 Claude Design（一個專門做介面設計的 AI），請它依 design-system.md 的塗裝規範和 spec.md 的功能清單，產出兩樣東西：

其一，一套真正能用的「設計系統」。 它不只是一張色票，而是把所有設計決定變成程式可直接套用的變數——例如把主色草綠 #639922、輔助色珊瑚橙 #D85A30、圓角、間距、陰影，全部定義成 54 個 CSS 變數，還附上一頁頁的元件樣本（按鈕、卡片、輸入框長什麼樣）。

這裡有個很值得初學者學的細節：規範裡白紙黑字寫著「珊瑚橙代表『達顯著／拒絕虛無假設』，但絕不能用紅色」。為什麼？因為在統計裡「拒絕虛無假設」常常正是研究者想要的好結果，用紅色會誤導學生以為自己錯了。紅色只留給「真正的錯誤」（檔案讀不懂、API 失敗）。這就是把教學上的體貼，寫進了設計規範——這種細膩，正是先有規範文件才守得住的。

其二，一份「設計交接包」（design handoff）。 裡頭是一個高擬真的網站雛形：入口頁、四大單元、AI 設定視窗都做出來了，連骰寶遊戲的搖骰動畫、餘額折線圖都能互動，而且用的是真實的統計運算，不是假數字。

但這份雛形聰明的地方在於——它在交接文件裡誠實標明「我是設計參考，不是正式上線的程式碼」，並附上一張對照表，告訴下一棒的工程 AI：哪些是雛形階段的暫代做法、正式版該換成什麼。例如：

雛形的暫代做法	正式版要換成
公式用排版文字示意	改用 KaTeX 正式渲染數學式
自己手寫的近似函式算 p 值	改用 jStat，並通過標準答案驗證
工具箱用假資料	改用 SheetJS 解析使用者上傳的 Excel
AI 評分回傳罐頭文字	接上 Gemini 真實呼叫

於是這艘船的接力棒就清楚了：人類用選擇題訪談聊出方向 → Claude 依 Harness 規範寫成八份文件 → Claude Design 依文件長出設計系統與雛形 → 下一棒的 Claude Code 依交接表把雛形變成正式程式碼。每一棒交接的，都不是「記憶」，而是「文件」。這，就是載具在做的事。