《AI 慣老闆日記》發刊文：從 Vibe Coding 到軟體工程，我為什麼要參加 IT 鐵人幫

人人心中都有一個渴望成為 AI 慣老闆的心願

最近我開始瘋狂 Vibe programming，一整天沉浸在 Replit、Cline 和各種 LLM prompt 中，像回到當年剛開始寫 code 的熱血時光。重新變回一個 builder 的感覺，說不出的開心。但愈寫愈深，卻愈覺得心裡發毛：我好像又在踩坑，而且是踩回那些我以為「AI 會幫我自動跳過」的老問題。

這些心得我決定要整理成一系列日記，正式參加 IT 鐵人幫比賽，也算是對自己的紀錄與反思。希望能讓你少走幾條冤枉路，或至少，在燒錢時知道自己在燒什麼。

Vibe Coding 心路歷程

突然理解 Joe Justice 提過的「Tesla 一天一個 sprint」不是神話，是真的 doable。我一天就能幹完以前兩週的事。靠的是什麼？是 prompt、是 LLM、是 Replit 的 preview & deploy 按鈕，還有我那張信用卡。

一開始，我完全是「靠感覺寫程式」派，不追原理、不補底層，純 trail & error 式的丟 prompt、丟檔案、叫 AI 幫我改樣板。結果還真的有模有樣，像請了一個不抱怨的工讀生。

直到 codebase 長到三個 service、五個套件、十幾個共用模組時，一切崩潰。Cline 的即時監控像心電圖狂跳，token 在飛、quota 在縮、錢在燒，我終於意識到：「好 vibes」其實是刷卡刷出來的。

從亂塞到會餵，才是真 Vibe DevOps

當我開始寫《AI 慣老闆日記》，不是想耍廢，而是提醒自己：AI 工具的效率與金錢，緊密連結。你不優化，你就虧錢。

過去那幾天，每開一個新對話我就貼整包檔案樹、設計 guideline、naming convention、workflow、DoD 通通餵下去。LLM 有耐心讀完，但 quota 沒耐心等你。然後我才懂：不是 LLM 不夠聰明，是我餵得太亂太多太沒秩序。

我開始學習「寫給模型看的說明文件」，在 repo 頂層加一行一句的 project overview，模組功能、資料流向、坑點、設計緣由，全部濃縮進 TL;DR。然後 diff 為主，context 為輔，一次只給必要訊息。像從吃到飽變成 omakase，剛開始不習慣，但看到 token 用量穩下來的那一刻，一切都值了。

這些小改變，讓模型「讀懂我」，也讓我「更懂專案」

設計結束寫設計摘要、新模組補一句說明、PR 前自動產生變更摘要，這些動作其實都是在「訓練自己」：如何讓資訊同時給人與 AI 都好吸收。也更接近我腦中那個 AI 輔助開發的理想場景。

幾個踩雷提醒，也分享給跟我一樣正在 Vibe 上搖擺的你：

1. 打開 IDE 的花費面板，成本可見化是改進第一步。
2. 給模型看的文件短而穩定，固定檔名放 repo 根目錄，讓工具一眼就找得到。
3. 先送 diff，再補全文；減少 AI 的資訊負擔。
4. 分 topic 開 session，任務分線處理；不要讓模型背前情上工。
5. 設計結論要寫下來——模型跟未來的你都會感謝現在的你。

從 builder 到慣老闆再回頭，底層功才是真的 AI 的 accelerator

Claude code、Gemini CLI、Code Interpreter 這些工具不斷變強，但只有一件事是我們能掌控的：如何讓知識被整理好、被壓縮、被摘要得可被處理。

這也是我為什麼要參加鐵人賽：不是炫技，而是透過紀錄與反思，重新梳理「做事的基本功」，讓 AI 不是變成錢坑，而是讓我們的開發體驗升級的跳板。

希望這一連串的《AI 慣老闆日記》，能讓你帶走一些：Vibe 不只是爽感，還需要 discipline；AI 不只是幫手，更是老師；而慣老闆，要先學會怎麼交接、怎麼節流、怎麼寫得清楚再叫別人幫你幹活。

祝各位都有好 vibes，跟更小的帳單。