建造日誌
日本偶像轉型記：她連一行程式碼都不懂，卻在十天內做出了整套直播系統
7 月 31 日那天，日本偶像宮本佳林在 YouTube 上做了一場十小時的現場直播。
企劃本身就很有意思：跟大家合力，用家裡現有的東西重現 MV。觀眾每買一張新單曲、每發一則指定主題標籤的貼文，畫面上的計量表就往前推一格；推到一定數量，就解鎖一項道具，可能是化妝品、可能是服裝、也可能是某個剪輯 App。最後她要用這些解鎖來的東西，在家裡把 MV 重拍一次，再讓 AI 打分數，看看重現度有多高。
十小時直播順利跑完。真正讓我感到驚喜的，是她在同一天發表的另一篇東西。
她在自己的部落格上，寫了一篇〈HANAKIN 配信系統的技術構成〉。從後端架構、資料結構、API 端點，一路寫到當天的營運流程與失敗備援。那是一篇正經到不行的技術文章。
而她在開頭第一句就寫著：這篇文章裡出現的術語，我並沒有完全理解。
她到底做了什麼
先說這套系統長什麼樣子，你才知道這件事的量級。
即時計量與畫面。 她要在直播畫面上放一條橫幅面板，顯示兩種計數、下一個要解鎖的道具還差幾件、AI 評分、直播計時器，還有每八秒淡入淡出切換一次的跑馬燈文字。這塊由 Cloudflare Workers 加上 KV 撐著，手機或電腦上的管理後臺改數字，畫面每五秒去問一次伺服器，然後更新。
社群貼文計數。 她想抓指定主題標籤的貼文數量。X 的官方 API 對個人來說太貴，她改走第三方服務，選了每月一美元、一千次請求的方案。
AI 評分程式。 這塊最不像一個偶像會做的東西。把原版 MV 與重現版 MV 兩支影片丟進去，用 ffmpeg 從兩邊各自抽出靜態幀，把相同時間碼的兩張畫面配成一對送給視覺模型，請它就構圖、姿勢、服裝、背景、燈光、氛圍六個項目打分，再給總分與評語。
最講究的是呈現方式。她刻意讓評分結果一場一場慢慢跑出來，而不是全部跑完才一次顯示。她的理由是：比起最後咚一聲跳出結果，看著「第一場審查中」「92 分」一件一件疊上去，畫面比較有趣，而且讓觀眾看見 AI 思考的過程，本身就有意義。
這不是由技術決定，這是由導演決定。
那一行沒讀的程式碼
她把實作全部交給了 Claude Code，自己一行程式碼都沒有讀。
那她做了什麼？她自己列了三件事：
一、用日文把需求講清楚。 二、跳出錯誤就把開發者工具的主控臺直接擷圖貼上去。 三、把「跟我想的不一樣」具體地講出來。
還有一件她認為最關鍵的：動工之前，她先寫好了一份規格書。目錄結構、資料結構、API 端點、失敗時的備援方針、實作順序、當天的營運流程，全部寫完，然後才對 AI 說「照這份做」。
她的結論是：一開始在設計階段好好花時間，後半段的速度才快得起來。
我看到這裡笑了。因為這正是我在每一場工作坊裡講到快沒力氣的那件事：很多人以為 Vibe Coding 是不用想清楚就能做東西，其實正好相反，它是把你的力氣從打字轉移到想清楚。
三個判斷，比技術更值錢
她在文章末尾自己回顧，說最有效的其實不是技術上的巧妙，而是三個判斷。這三個判斷，我認為值得大家效法。
第一，每一個自動流程都留一條手動退路。
現場直播是一發定生死，所以她從一開始就假設「這東西可能不會動」來設計。社群貼文數抓不到？可以手動加減、也可以直接覆寫。AI 評分掛掉？分數跟評語可以手打。她寫道：結果就算貼文數抓取不穩，直播一次都沒有停過。
還有一個更聰明的設計。她原本想讓系統管理整串解鎖的階段，後來改成只管「下一個要解鎖的東西」這一項，因為當天的成長速度根本沒人猜得準。少管一點，反而穩。
第二，撞到限制就改設計，不是硬闖。
她原本規劃每十分鐘自動去抓一次貼文數，結果撞上一句話：免費方案不支援排程觸發。
她沒有為了這個功能去升級方案，也沒有想辦法繞過去，而是直接改設計：在管理後臺放一顆手動按鈕，想抓的時候自己按。結果反而更好，因為請求次數變成可以跟著直播的熱度來調配。
她另外還有一句話，我覺得任何做過即時系統的人都會點頭：出錯的時候就沿用上一次的數值，因為在現場直播裡，比起正確，不要出現奇怪的行為更重要。
第三，不要執著於解決，記得看截止日。
開發途中她遇到一個純粹卡關的問題：某家 AI 服務的儲值一直刷不過。她把帳單地址從漢字改成羅馬拼音也一樣，同一張卡拿去付別家卻正常。她判斷這不是信用卡的問題，是對方的風控把她擋掉了。
她寫得很乾脆：靠自己突破是不可能的。算了算剩下的天數，她放棄突破，直接換另一家 AI 服務。
之所以能說換就換，是因為她當初沒有把服務商寫死，換過去只需要改端點跟請求格式。她自己把這件事定位得很準：這與其說是技術問題，不如說是專案管理問題。不執著於解決，從截止日往回推，切換到替代方案。不要把時間溶解在動不了的東西上面。
一個十天前才開始動工的人，做出了這個判斷。反觀我看過不少略有資訊背景的人，在同樣的岔路上硬撐了三天。
這件事為什麼是給你的邀請函
如果你到這裡的反應是「她一定本來就很聰明」，那我們可能錯過了重點。
重點是：她全程沒有讀程式碼，卻對整件事有完整的判斷力。她知道什麼東西放在哪裡、當天會在哪裡卡住、哪些功能可以砍、哪些備援不能省、什麼時候該放棄一條路。
這些沒有一項需要你會寫程式，但每一項都需要你知道自己要什麼。
她的優勢從頭到尾就不是技術。她是那個最清楚這場直播該長什麼樣子的人，她知道評分一場一場跑出來比較好看，她知道當天觀眾的成長速度沒人猜得到，她知道直播中斷比數字不準嚴重一百倍。這些判斷，AI 給不了你，因為 AI 不在現場，也不在乎。
我常說 AI 不會超越你，它只會放大你。這個案例又補上了另外半句：它放大的不是你的技術，是你的判斷。
所以，如果你現在的狀態是「我完全不會寫程式」，我想告訴你的是，這句話在 2026 年已經不是一個拒絕的理由了。你真正需要準備的東西，其實是這三樣：
一、你想做出什麼，具體到能寫成一份規格。 二、東西壞掉的時候，你有沒有能力描述「我期望的是什麼、實際發生的是什麼」。 三、卡住的時候，你捨不捨得換路。
第一樣靠練習，第二樣靠幾次挫折，第三樣靠一點決斷。三樣都跟程式語言沒有關係。
從哪裡開始
宮本佳林用了十天。你的第一個東西不需要那麼複雜，也不必搞什麼十小時直播。
如果你想試試看，我在 builder.tw 開了一門免費的迷你課，主線就是零基礎學 Vibe Coding，內容全部公開，進度自己決定。你不需要先買什麼、不需要先會什麼，甚至不需要先想好要做什麼。先走一段，感覺一下這件事到底是怎麼回事。
她在那篇技術文章的最後寫了一句話，我想把它放在這裡當結尾：
這十天，邊做邊學到的東西還比較多。希望對同樣不會寫程式、卻想做點什麼的人有所幫助。
那句話是寫給你的。