開發航海日誌 ｜ 船長 Balung　·　副官：Claude Code 這是一篇「邊蓋邊寫」的連載長文——從專案的第一步，一路記到整個網站真實上線。它會隨開發持續長出新章節；你現在讀到哪，就是我們航行到哪。

上一篇〈AI 寫作的三層甲板：提示、脈絡、載具工程〉，我們花了整整一篇，做了一件看起來「都還沒開始」的事：在寫下任何一行程式之前，先把整套開發文件寫出來。

那篇的核心主張濃縮成一句話——「對話會散，文件不會。」 跟 AI 協作，真正要緊的知識不能只活在聊天視窗裡，得沉澱成一套結構化文件：產品的憲法（spec.md）、技術海圖（design.md）、塗裝規範（design-system.md）、船員守則（ai-rules.md）、駕駛艙儀表板（roadmap.md）、航海日誌（log.md）、對外素材庫（journal.md），還有給新人的碼頭迎賓牌（README.md）。換一個新對話、換一個 AI、甚至換個人來接手，只要讀這套文件，就能立刻站回同一條航線上。

那篇的結尾，我留了一句預告：

「下一段航線，我們就把這艘船真正開出港——讓工程 AI 依著這套文件，把雛形一塊一塊變成上線的網站。」

這篇日誌，就是那段航線的全程實錄。目標是把過去各自漂在不同海域的四座小島——描述統計、機率模擬、Z 檢定練習、Excel 檢定工具箱——連成一塊看起來像「同一家人」的大陸：一個零安裝、打開瀏覽器就能動手玩的繁體中文統計教學網站。

先把這趟航行的兩個角色講白，免得後面看得霧煞煞：船長，就是我這個人類——負責定方向、做決策、把關品味、在關鍵時刻拍板。副官，指的就是 Claude Code——一個能讀懂整包專案文件、還能自己動手寫程式、跑測試、開瀏覽器驗證的 AI 程式工具。所以下文凡是寫「副官做了什麼」，意思就是「Claude Code 自己把那段程式寫出來、跑出來」；而我這個船長，多數時候只是在旁邊看著，必要時才出手。

這篇很長，所以先給你一張全程航海圖——這趟從文件到上線怎麼走，一眼看懂；接著我們再從第一章慢慢航行。

圖：全流程三步——①先把 8 份文件與規矩準備好（上一篇做的）；②在 Claude Code 下第一道指令，讓副官先讀文件、複述航線；③邊開發邊過「驗收三關」（算得對／看得見／上得了線），一路把空船開到全站上線。船長定方向與驗收，副官（Claude Code）讀文件、寫程式、自測。

我們從第一章開始。

第一章：先讓空船下水（部署優先）

航行日期：2026-06-10

這一章不會談任何一個統計公式。因為遠征的第一課，不是「蓋什麼」，而是「怎麼確定船真的浮得起來」。

一、先把那套「文件船」搬上來

上一篇那 8 份文件，不是寫完就收進抽屜。我把它們整包放進這次專案資料夾的 02-harness/——harness（載具）正是上一篇講的第三層「載具工程」，這個資料夾就是這艘船的龍骨。同一套東西也整理進了上一篇附錄的 GitHub repo，你想對照原件，照那條動線就翻得到。

換句話說，這篇要做的事不是「從零開始」，而是把一艘已經設計好、文件齊備的船，真正開出港。

二、在 Claude Code 裡打開資料夾，下第一道指令

先講最有「現場感」的一刻。我把整個專案資料夾用 Claude Code 打開，左邊的檔案樹一攤開，那套文件就靜靜躺在 02-harness/ 裡：

vibe-statistics/
├── 02-harness/            ← 上一篇寫的那套「文件船」
│   ├── spec.md            產品憲法（最高仲裁依據）
│   ├── design.md          技術海圖
│   ├── design-system.md   塗裝規範（視覺）
│   ├── ai-rules.md        船員守則（AI 紅線）
│   ├── roadmap.md         駕駛艙儀表板（進度）
│   ├── log.md             航海日誌（決策／踩雷）
│   ├── journal.md         對外素材庫
│   └── README.md          碼頭迎賓牌
├── 03-design-system/      設計系統的實際產出
├── 04-handoff/            舊的四個原型
├── 05-app/                ← 還空著（這趟要長出來的網站）
└── 06-devblog/            ← 你正在讀的這篇日誌

注意看 05-app/——它還是空的。那就是這趟航行要從無到有長出來的網站。

接著是關鍵：我下的第一道指令，不是「幫我做網站」。 我打的是這樣一句話——

請先讀這個專案 02-harness/ 資料夾裡的文件，特別是 ai-rules.md 跟 spec.md，讀完告訴我你打算怎麼進行。先不要動手寫程式。

為什麼要這樣下？因為「先寫文件」的回報，就在這一刻兌現：我要先確認副官讀過海圖、站回同一條航線，再讓它碰程式碼。它讀完之後，回我的不是程式，而是一段複述——這個專案的最高鐵律是「計算正確性優先、數字與解釋缺一不可」、開發順序是「部署 → 測通 → MVP，不可顛倒」、金鑰絕不寫進程式或版控。它理解的航向，跟我海圖上畫的對得起來。

對得上，才開工。這就是 Vibe Coding 真正的樣子——不是對著 AI 喊一句就生出網站，而是先讓 AI 跟你站在同一張海圖前。

三、誰掌舵、誰划槳：哪些它自己跑，哪些停下來等我

開工前，我給副官的開場再加上三條一句話鐵律，釘住整艘船的底線：

副官，記住這艘船的三條鐵律： 一、任何會吐出數字的地方，都要同時給白話解釋，缺一不可；計算的正確性高於美觀與速度。 二、開發順序不可顛倒——先讓空殼能部署上線、把整條鏈路測通，再回頭做功能。 三、能自動化又可逆的事（打包、起伺服器、截圖驗證），你自己用指令做完並驗證，別丟回來給我。

但「分工」不能只靠精神喊話，它白紙黑字寫在 ai-rules.md（船員守則）裡，把界線切成三種：

• 副官自己做、不必問我：讀寫程式碼、跑測試、在本機起伺服器預覽、打包、用瀏覽器自己開來截圖比對、本機存檔（commit）。這些都可逆、可自動，丟回來問我反而是浪費。
• 副官一定要停下來、當場問我：安裝新套件、把程式推上雲端（git push）、部署上線、用我的真實金鑰去呼叫 AI 評分。這些要嘛花錢、要嘛對外、要嘛收不回來，不能讓 AI 自己按。
• 只有我能親手做的（副官根本沒權限碰）：到 GitHub 網站開一個新的儲存庫、進設定把 Pages 的部署來源切成 Actions、把我的 API 金鑰貼進專案的 .env 檔、以及最後——親手按下這篇部落格的 publish。

所以你等一下會看到一個很具體的畫面：這一章後半的「啟航實錄」那三步，是我親手在 GitHub 網站上點的；而打包、寫部署腳本、截圖驗證那些，是副官自己跑完、回報給我的。一隻腳踩在岸上、一隻腳踩在船上，Vibe Coding 的分工，就是這個樣子。

四、選哪一具引擎：JavaScript 還是 TypeScript？

第一個要拍板的關鍵決策，是程式語言。

副官原本傾向用大家熟悉的 JavaScript——因為設計原型本來就是用它寫的，照搬最省力。但我請它再想一層：這是一個教統計的網站，最可怕的事是什麼？

不是當機，不是醜。是安靜地算錯——畫面上吐出一個看起來很合理、其實是錯的數字，沒有任何人察覺。對一個教學網站來說，這是會動搖信任的暗礁。

於是我們選了 TypeScript。它像是在每一具統計引擎的管線接口都加上「規格不符就鎖死」的螺紋——當副官把資料餵進統計函式時，只要參數型別放錯，程式在出海前就會被擋下來，而不是讓錯誤的數字流到使用者眼前。

航海小語：技術選型沒有標準答案，只有「對這艘船」的答案。同樣一個選擇，放在別的專案可能相反。

五、先讓空船下水

決定好引擎，副官很快搭好了船的骨架：一個空殼網站，有一個入口頁、一個佔位的單元頁，點連結能切換頁面。

這裡我要強調一個很多人會搞反的順序——我們沒有先去蓋功能，而是先確認這艘空船能不能開到外海。

一般人的直覺是「先把功能做完，最後再來想上線」。但部署這件事，往往藏著最多暗礁；等到最後一刻才接，常常船蓋好了卻下不了水。所以我們的鐵律是：先讓水管通水，再裝水龍頭。

具體來說，就是先讓這個什麼功能都還沒有的空殼，成功開上 GitHub Pages 的外海，把「程式碼 → 打包 → 部署 → 瀏覽器打開」這整條航線跑通。

圖：還很樸素的入口頁雛形——「統計，沒那麼可怕。」設計與功能都還沒上，但這正是要拿去下水測試的那艘空船。

六、啟航實錄：三步把空船推上外海

程式的空殼一寫好，副官（Claude Code）自己就走到了一道它跨不過去的界線——上線。開 GitHub 儲存庫、設部署來源這些是「對外、要帳號權限」的操作，副官碰不到；於是它停下來，具體地點名請我這個船長出手：

船長，空殼我準備好了，但接下來這幾步我沒有權限，得請你親自到 GitHub 網站上處理：開一個新的儲存庫，命名 vibe-statistics、設為 Public、三個初始化選項都不要勾。進 Settings → Pages，把部署來源（Source）設成 GitHub Actions。 弄好跟我說一聲，我就把程式碼推上去，讓自動部署接手。

這就是前面講的分工落到實處的一刻：該人類動手的，AI 會明確點名請你做，而不是自己亂闖。 所以下面這三步，是我照著它的指示、一步一步親手在 GitHub 上點出來的——我也順手把每一步記下來。

Step 1：在 GitHub 上備好一個空船塢

到 GitHub 開一個新的儲存庫（repository）：

• 擁有者選我的帳號 captain-balung，名字取 vibe-statistics（這個名字很重要，等下網址會用到，得對得上）。
• 設為 Public（公開）。
• 三個「要不要幫你加 README / .gitignore / 授權」的選項，全部都不要勾。

最後一點是新手最容易踩的暗礁：因為我本機已經先把檔案準備好、也記錄好版本了，如果這裡再讓 GitHub 幫忙塞檔案進去，兩邊就會打架。空船塢，就讓它空著。

圖：建立儲存庫的設定——名字 vibe-statistics、Public、三個初始化選項全關。

Step 2：把 Pages 的引擎切到「GitHub Actions」

進到這個儲存庫的 Settings → Pages，在「Source（來源）」的下拉選單裡，有兩個選項：

• GitHub Actions ——適合像我們這種需要先打包再上線的網站。
• Deploy from a branch ——舊式做法，把某個資料夾的內容原封不動丟上去。

我們選 GitHub Actions。因為我們的程式碼不是寫好就能直接看的成品，得先經過一道「打包」工序；而我事先已經寫好一份自動化腳本，會在每次更新時自動完成打包與部署。

圖：Source 設成 GitHub Actions。下面那些 Next.js、Hugo 的建議範本通通不用理會——我們已經有自己的腳本了。

Step 3：推送，然後看著它自己開出港

repo 開好、Pages 也設好之後，我回頭跟副官說了一聲：「好了，推上去。」——把程式碼推上雲端（git push）是「對外、不可逆」的動作，照規矩副官不會自己按，要等我這個船長下令；得到指令，它才把本機準備好的程式碼推送上這個儲存庫。

推送的那一瞬間，事先寫好的自動化腳本就被觸發了——它在 GitHub 的雲端機器上，自動把程式碼打包、再部署到網站上。整個過程不需要我守在旁邊，像是按下啟航鈕後，船自己平穩地開出了港口。

圖：那道自動化腳本在雲端跑完——打包、部署，一個綠勾，33 秒。我什麼都不用做，只是看著它開出港。

幾十秒後，網址活了過來：

https://captain-balung.github.io/vibe-statistics/

圖：空船成功下水。雖然只是個樸素的雛形，但它是真正活在網際網路上、任何人都打得開的網站了。

七、海試：在外海重整，會不會翻船？

下水不等於航行平穩。我特別做了一個壓力測試。

我們這種「單頁網站」有個惡名昭彰的暗礁：使用者如果停在某個內頁，按下「重新整理」，整個網站很容易直接給你一個冷冰冰的 404 找不到頁面。對教學網站來說，這種事一旦發生在學生面前，信任就崩了。

為了徹底避開它，我們從一開始就選用了一種「把頁面路徑藏在網址 # 之後」的路由方式（technically 叫 HashRouter）。它的好處是：不管使用者停在哪一頁、怎麼重整，瀏覽器永遠先拿到同一份門面，再由前端決定要顯示哪一頁，根本不會去問伺服器「這個內頁的檔案在哪」——也就沒有 404 的機會。

於是我直接開到內頁、用力重整：

圖：直接開到「描述統計 · 標準差圖解」這個內頁並重整——畫面穩穩地顯示，沒有翻船。海試通過。

頁面穩穩地停在那裡。海試通過。

本章暫泊：空船已在外海，下一章要裝上靈魂

到這裡，第一章完成了：一艘什麼功能都還沒有、卻已經能穩穩航行在外海的空船。

聽起來好像什麼都還沒做——畢竟畫面上連一個能算東西的工具都沒有。但對我來說，這一章反而是整趟航行裡最關鍵的：因為從現在起，之後每長出一個新功能，都能立刻、安全地開上線給人看，而不是把所有風險都堆到最後一刻。水管通了，接下來才輪到水龍頭。

下一章，我們要往船艙裡裝第一個真正的靈魂——讓「標準差」這個讓無數初學者頭痛的概念，變成一張可以動手玩、會即時跟著資料變化的互動圖。

不再紙上談兵。我們下一章見。

第二章：裝上第一個靈魂（標準差圖解）

航行日期：2026-06-10

空船能航行了，這一章我們往船艙裡裝第一個真正能用的工具。

在裝工具之前，先說一下從這裡開始的航行節奏——它其實最能說明 Vibe Coding 平常長什麼樣子。接下來絕大部分時間，都是副官（Claude Code）自己在划槳：自己讀文件、自己寫程式、自己在本機跑起來、自己開瀏覽器截圖驗證。我這個船長多半沒事做，只在兩個時刻出手——一是幫它做它沒權限的對外動作（開 repo、設部署、把金鑰放進 .env），二是在它寫好一段、自己驗過之後，下令把成果 push 到 GitHub、讓它真正上線。程式是副官划的槳，我只負責在對的時機喊一聲「推」。所以後面的章節你會看到，畫面一個個長出來，而我出現的次數越來越少——這正是「人定方向、AI 划槳」運轉起來的樣子。

一、先把引擎室建好

要做能「動手玩」的統計工具，船上得先有三樣共用設備：

• 公式排版：讓 σ、Σ 這些數學符號漂亮地印出來，而不是一堆看不懂的原始碼。
• 互動圖表：能即時畫出長條圖（之後還有散佈圖、曲線等）。
• 全站導覽列：把四個單元（描述統計、機率模擬、Z 檢定、Excel 工具箱）一字排開，點了就切換、看起來像同一家人。

這部分是副官的純執行工作，我只負責驗收：公式有沒有正確渲染、圖表有沒有出來、導覽切換順不順。引擎室一通電，主角就能上場了。

二、把「標準差」變成看得見的東西

標準差，大概是初學統計最容易「背得出公式、卻不知道在幹嘛」的概念。所以這個工具的目標不是吐出一個數字，而是讓你看見它。

你貼上一組數字，它即時告訴你四件事：平均數、平均離差、變異數、標準差。但真正的主角是下面那張離差圖——

圖：貼上一組數字，平均/離差/變異數/標準差即時算出，下方離差圖把每筆資料離平均多遠畫成棒子。

每一根棒子，是一筆資料離平均有多遠：在平均之上是綠色、朝上；在平均之下是珊瑚色、朝下；棒子越長，離得越遠。標準差，其實就是在描述「這些棒子平均而言有多長」。當你改幾個數字、看著棒子跟著變高變矮，那個抽象的 σ 就突然具體了起來。

而且，每個數字旁邊都有白話解釋。這是這艘船的鐵律：絕不丟一個冷冰冰的數字就走人。

小插曲：我特地用課本經典的那組數字 2, 4, 4, 4, 5, 5, 7, 9 來驗收，因為它的標準差剛好是漂亮的整數 2。畫面算出來的平均 5、變異數 4、標準差 2，跟手算一字不差——對一個教統計的網站來說，「算對」是不能妥協的底線。輸入怪資料（比如混進文字）也會跳紅字提醒、絕不偷偷算出一個錯的數字。

三、一個真實的暗礁：部署成功 ≠ 立刻看得到

把這個工具推上線時，我撞到一個很多人會被搞糊塗的暗礁：GitHub 的部署紀錄明明顯示「成功」，我打開網站卻還是舊的。

原因是 GitHub Pages 前面有一層 CDN 快取——新版其實已經部署好了，但散布在全球的節點要等舊版快取過期才會換上新的。這不是壞掉，是「還在傳播」。部署成功，和你眼睛看到新版，中間有一段時間差。 知道這件事，就不會在那邊瞎緊張、亂改東西——耐心等它換版就好。

本章暫泊：第一個工具上線了

到這裡，這艘船不再只是能航行的空殼——它裝上了第一個真正能用、能算、還會用白話解釋給你聽的工具。最開始畫好的那條航線「部署 → 測通 → MVP」，正式走完一輪。

下一章，我們要把描述統計剩下的夥伴一個個請上船：把 Z 分數和百分比互相換算、用電腦模擬出一整批常態分佈的資料、還有畫散佈圖看兩個變數怎麼一起跑。

繼續航行。下一章見。

第三章：船長上岸，副官獨自航行

航行日期：2026-06-10

這一章有個轉折：我上岸了。

船的骨架穩了、第一個工具也下了水，我把舵交給副官（Claude Code），給了它一道明確的命令——「把整個網站做完、自己測試、全程截圖記錄，能判斷的就別來問我。我回來時要看到一艘完整的船。」然後我就去忙別的事了。

接下來的航程，是副官獨自完成的。我回來時，描述統計剩下的三個夥伴都已上船：Z 分數換算（在常態曲線上看到分數落在哪、左尾面積多大）、常態模擬（一鍵抽出一整批資料、看它堆成鐘形）、相關與回歸（在圖上點一點加資料，即時算出相關係數與回歸線）。

圖：在散佈圖上點一點就新增資料點，Pearson r 與珊瑚色回歸線即時跟著變。旁邊永遠提醒：相關不等於因果。

機率模擬那一櫃更是「玩中學」的重頭戲：鐘形曲線、二項分配、賭場優勢，還有兩個賭博模擬。其中馬丁格爾策略那張圖我特別喜歡——餘額一路小幅爬升，看起來穩賺，然後在某一注突然斷崖式崩盤破產。

圖：「輸了加倍」的策略把「小贏很多次」換成「偶爾大輸一次」。那道斷崖，就是代價。

壓軸是一張仿真的骰寶骰桌：選籌碼、在格子上下注、開骰結算，賠率規則完整。但每一格底下都寫著同一句老實話——長期期望值都是負的，沒有「保證贏」這回事。

第四章：最深的暗礁——「算錯」

航行日期：2026-06-10

如果這趟航行有一道最深的暗礁，那就是**「安靜地算錯」**。一個教統計的網站，畫面上吐出一個看起來合理、其實是錯的數字，比當機還可怕。

所以在做 Z 檢定練習（自動出題、自己作答、立即對答案）和 Excel 工具箱（上傳 .xlsx，跑單樣本 t、Welch t、ANOVA、卡方）這些「會算給你看」的工具時，我給副官立了一條鐵律：每一種檢定上線前，都要先通過「標準答案測試」——拿課本/權威工具算好的已知答案，寫成自動化測試，全部對得上才准上線。

圖：選數值欄與分組欄，立刻得到 F 值、自由度、p 值與判定，旁邊一段白話告訴你它在問什麼。

副官把四種檢定的統計量與自由度用手算精確值核對、p 值對照權威參考值，寫成測試一次跑——五項全綠才把工具接上畫面。這條「計算正確性不能妥協」的底線，是整個網站的信任根基。

至於 AI 評分：你可以自備 Google Gemini 的 key（只存在你自己的瀏覽器、絕不上傳），讓 AI 幫你的作答打分。船長負責定規矩——key 怎麼存、怎麼遮蔽、沒填 key 時要優雅降級（出題、作答、對答案照常，只停用評分按鈕）；這些「品味與安全」的決定是人的，執行交給副官。

第五章：大陸成形

航行日期：2026-06-10

我回到船上時，四座原本各自漂流的小島，已經連成了一塊大陸。

入口頁不再是空殼，而是一張清楚的航海圖：四個單元一字排開，點哪一張卡就駛向哪片海域。

圖：「統計，沒那麼可怕。」四個單元、十幾個互動工具，全部活在同一個零安裝、免註冊的網站裡。

還記得這趟遠征最開始，是為了回答〈從教科書到 Vibe Coding〉結尾那個鉤子嗎——

「有沒有可能，將這些獨立的教學工具，整合成為一個完整的教學網站？」

現在我可以給出最確定的回答：可以，而且它已經上線了。

🔗 https://captain-balung.github.io/vibe-statistics/

這趟航行教我的事，或許比任何一個統計工具都重要：Vibe Coding 不是把方向盤交給 AI 就好。船長要做的，是把價值觀、底線與品味講得夠清楚——「數字與解釋缺一不可」「計算正確性不能妥協」「先讓水管通水」「資料留在使用者的瀏覽器」——剩下的執行，副官能跑得又快又穩，甚至能在我上岸時獨自把船開回港。

人定方向，AI 划槳。這就是我心目中的 Vibe Coding。

下一段航程，換你了——去玩玩看，告訴我哪裡還能更好。