Day 30｜完賽

哇是最後一天了，30天過得比我想像中的快很多，最後一天就來分享一下鐵人賽的參賽心得，順便紀錄自己的完賽心情ＸＤ

兩個 AI 平行開發同一專案

這次的分享主題是vibe coding，想當然在這30天我是瘋狂借助了AI的力量，而且因為有寫作與開發兩項能力的需求，我特地開了兩個對話，讓他們分別擔任本計劃的「編輯」與「工程師」，也因為某些因素，不小心讓編輯與工程師開在不同電腦上。

分開來做，效果比原本想的好很多。「編輯」這邊雖然沒辦法直接知道程式碼跟規劃上的異動，但特別要求「工程師」要在文件、程式碼裡註記開發需求跟過程——透過這些輸出的文件紀錄，加上直接讀程式碼，一樣能建立起對整個開發過程完整的認知，也還能反過來協助設計文章章節。幫不同對話設定好各自的角色，是一個蠻好用的分工技巧。

回頭看這 30 天

分享文章的這 30 天，為了把概念寫清楚，自己也多花力氣把技術跟文字內容研讀清楚，避免留下錯誤的訊息足跡——這個過程反而讓自己對分享的這幾項技術更有概念、更有基礎，開發的時候也更清楚自己在做什麼。整個系列走下來，等於完整經歷了一次從 0 到有的 vibe coding 過程。

在寫作方面是透過先闡述架構、理念，再由claude替我先產出文章草稿，但claude的說教方式真的太像說教男了，自己看了也受不了，所以會盡量修飾字詞、口吻，讓文章整個讀起來想是分享而不是課程，但有些地方還是有偷懶直接使用claude的內容啦。

四層全貌回顧

最後一天把整個系列攤開來看，其實是一個學習 LLM 的漸進過程：

• Prompt Engineering：怎麼把話講清楚，讓單次呼叫的回應更可靠
• Context Engineering：怎麼管理模型看得到的資訊，讓對話不會因為越拉越長而失控
• Harness Engineering：不只是這一次呼叫，而是從系統設計的層次，讓某一類錯誤變得結構上不可能發生
• 個人版 LLM Router：統一管理多家 provider 的 API Key，處理流量控管與容錯備援，把分散在各處的用量跟花費，收進同一個看得到全貌的地方

前三層處理的是「怎麼把 LLM 用好」，最後則是分享了「如何系統性管理 LLM 的連線」，以上就是本系列想分享的內容。

這是我第一次參加鐵人賽。在 AI 浪潮的席捲下，技術迭代的速度快得不可置信，每天都有新的名詞與概念出現，往往剛理解一個新概念，下一波分享又已隨之而來；在追趕新知的同時，少了一段讓自己好好沉澱與內化基礎的時間。

對我而言，鐵人賽是一個絕佳的契機——用持續輸出的壓力，逼自己放慢腳步梳理這一年來的技術累積與成長盲點。這次梳理不僅是對過往技能的複盤，也替未來的學習打下更穩固的基石。未來若有機會，還會想再參加！

謝謝看到這裡的每一位讀者，30 天連續發文到此結束。