請工程師花三年做不出來的產品，他用 Claude Code 十小時自己蓋出來了

本文整理自 Techmeme Ride Home Podcast 2026 年 5 月播出的「How I AI」首集。

---

投了幾百萬在 AI 基金，自己卻不碰 AI

Brian McCullough 大概是矽谷最了解科技趨勢、卻最晚開始用 AI 的人。他是美國最受歡迎的科技 Podcast 之一 Techmeme Ride Home（現為 Tech Brew Ride Home）的主持人，每天下午五點更新，是不少矽谷人通勤時的標配。他同時經營 Ride Home Fund，2024 年三月，好友、hashtag（#）發明者 Chris Messina 向他提出一個投資論述：不要押注在通用人工智慧上，要押注在「垂直 AI」上，因為每個產業的專業知識太深太碎，只有深耕領域的人才能把 AI 用對。Brian 被說服了，兩人一起募了一檔 1,500 萬美金的 AI 基金。

但投資歸投資，Brian 自己的生活裡幾乎不碰 AI。Chris 在節目中直接點破這個矛盾，語氣帶著不可思議：你把錢砸進 AI 基金，自己連 ChatGPT 都沒在認真用？Brian 坦承確實如此。他知道 AI 很重要，每天在節目裡講 AI 新聞，但一直沒有真正把它用在自己的工作和生意裡。轉折發生在 2026 年一月的 CES。他開始用 LM Studio 下載本地模型、用 ComfyUI 做實驗，純粹想知道「這東西現在到底能幹嘛」。結果一玩就停不下來。

幾週的實驗下來，他學到了第一個重要教訓。他原本以為好的提示詞就是要寫得又長又詳細，把所有要求鉅細靡遺地描述出來。錯了。真正的關鍵是理解 AI 記憶的運作方式，用 Markdown 檔案當作專案的持久參考文件，讓 AI 隨時可以回頭查。他稱這些檔案為「專案的藍圖」。他的第一個實際成果很小但很有感：自動產生每集節目的 show notes 連結。這件事他以前每天花五到十分鐘手動做，在錄完一整集節目後腦力耗盡的狀態下，這五分鐘格外痛苦。現在他打開 Claude，說一句「show notes」，Claude 就去讀他 Google Drive 裡的當日腳本，自動產出所有連結。

26 年、90 位寫手、20 萬求職者

但 Brian 真正想用 AI 解的問題比 show notes 大得多。他 19 歲還在佛羅里達大學念書時就創辦了 ResumeWriters.com，靠的是一個簡單的洞察：大部分人不會寫履歷。公司的模式是媒合。客戶填寫表格，系統配對合適的專業履歷寫手，一對一量身打造。巔峰時期他有 90 位約聘認證寫手遍布全球，26 年來服務超過 20 萬名求職者，客戶裡甚至有不少矽谷知名 CEO。Brian 在創業初期自己寫了超過一千份履歷，他非常清楚什麼格式能通過 ATS（應聘者追蹤系統）的自動篩選，什麼措辭能讓招聘主管多看兩眼。

他一直有個夢想沒實現：讓每個求職者對每一份工作都能有一份量身訂製的履歷，不是一份投到底。傳統的人工代寫模式做不到這件事，因為成本太高、速度太慢。一個求職者可能同時投二十份工作，你不可能為每一份都配一位寫手。

他從 AI 出現的第一天就知道，這個技術會直接衝擊他的生意。一個能自動幫你改履歷的 AI，就是他 90 位寫手的直接競爭者。但前兩年他試過了，AI 的產出品質根本不到他的標準。於是他走了另一條路：花了三年，請了好幾組軟體開發者，累計花費數萬美金，想打造一個「根據職缺描述自動調整履歷」的產品。結果全部失敗。工程師的能力沒問題，問題在別的地方：Brian 的品質標準存在他腦子裡，壓縮不進一份規格文件。他每次給開發者的回饋都很模糊，「這看起來不對」「語氣太硬」「重點擺錯了」。工程師收到這種回饋根本無法有效迭代。專業知識和程式碼之間，永遠隔著一層翻譯。

一個星期四早上 7:30，他打開了終端機

在 CES 之後幾個月的 AI 實驗裡，Brian 花了好幾週反覆調整他的履歷生成提示詞，把 26 年的品質判斷一條一條編碼進去：什麼情況下該用動作動詞、什麼時候要量化成就、遇到轉職的人該怎麼重新框定經歷。直到 Claude 的輸出終於達到他自己的標準。有了這個提示詞基礎，他決定做一件他一直以為自己做不到的事：自己把它變成一個產品。

那是一個星期四的早上七點半。他坐下來，打開終端機裡的 Claude Code，告訴 Claude 他有一個域名 resumewriting.com，請 Claude 幫他規劃整個產品架構。Claude 推薦了 Vercel 做部署、Supabase 做後端資料庫，然後開始跟他對話。不是那種「你丟需求、AI 吐程式碼」的單向流程，而是 Claude 反過來面試他：你的使用者是誰？他們最常遇到什麼問題？你希望產品流程怎麼走？有趣的是，Anthropic 的團隊後來在「Code with Claude」開發者活動上給了完全一樣的建議：讓 Claude 來面試你，別自己一口氣把所有需求倒出來。Brian 在不知情的情況下走上了同一條路。

兩個半小時後，Claude 產出了一份大約三十到四十頁的完整產品規格書。Brian 看完之後就知道這可以做。接下來大約十小時的實際編碼工作，分散在好幾天凌晨三點起床的晨間衝刺裡，一個功能完整的 MVP 慢慢成形了。

開發過程一點都不優雅。Brian 不懂 Vercel 的介面該按哪裡，不懂 Supabase 的設定頁面在說什麼。他的解法是截圖，大量的截圖。一個工作階段裡他可能截三百張螢幕截圖，全部丟給 Claude，問：「你叫我做的事情我找不到在哪裡，你看一下這個畫面，告訴我該按哪裡。」Chris Messina 在節目中毫不客氣地說，這是「最笨、最慢的電腦操作方式」。但它有用。而且任何不會寫程式的人，只要願意截圖和問問題，都能用同樣的方法前進。

不是聊天機器人，是旋鈕和儀表板

Brian 做出來的產品長得不像你想像的那種「AI 聊天機器人幫你改履歷」。它更像是一套有步驟、有控制項、有品質把關的工作流程介面。

使用者上傳現有履歷，貼上目標職缺的描述，AI 就開始工作。但在產出最終結果之前，系統會先做幾件事。一個驗證步驟會檢查你提供的資訊是否充足，如果缺少關鍵資料，系統會擋住你，不讓你繼續走。接著一個叫「情境解讀」（situation read）的區塊會顯示 AI 對你的職涯判斷：它認為你想從這份工作裡得到什麼、你的核心優勢是什麼。如果 AI 判斷錯了，你可以馬上修正方向。然後是八個 Yes/No 的澄清問題，像是「你願意搬家嗎？」「你願意接受遠端工作？」這些答案會被快取進下一輪的提示詞裡，讓 AI 在迭代時記住你的偏好，不用每次重來。

系統還會顯示一個 ATS 關鍵字匹配分數。在展示中，分數是 62/100，告訴使用者這份履歷有多少機率通過自動篩選。Brian 坦承他還在猶豫要不要在正式上線時保留這個功能，擔心太低的分數會嚇跑使用者。最後，使用者可以直接在線上預覽調整後的履歷，支援 PDF 和 Word 格式輸出，有十種設計模板。定價是每月 24.95 美金，含 50 個額度，一份履歷用掉一個額度，換算下來大約每份 50 美分。

Brian 刻意不做成開放式的聊天介面。他的邏輯很清楚：大多數人不懂提示工程。你丟給他們一個空白聊天框說「跟 AI 聊天改履歷」，他們不知道該問什麼、該怎麼引導 AI，最後得到的結果就是泛泛的通用輸出。所以他把自己 26 年的專業判斷編碼成產品的流程和介面，用結構化的旋鈕和儀表板取代開放式對話。使用者不需要知道怎麼寫提示詞，只需要回答問題、確認 AI 的判斷、按按鈕。Chris Messina 在節目中替他做了一句精準的總結：Brian 把他的專業知識透過介面產品化了。

Claude 逼他學會的東西

這段 vibe coding 旅程有個意料之外的副產品：Brian 終於學會了真正的軟體工程實務。

Brian 跟軟體開發者合作了 25 年，他知道 Git、repo、環境變數這些詞彙，但從來沒有自己操作過。Claude Code 逼他親手做這些事。他學會了 commit 和 push 的差別（以前他一直以為是同一件事），學會了環境變數的用途、為什麼不能把 API key 寫死在程式碼裡。他開始用 sprint 的方式工作，每個衝刺結束時留一個有意義的檢查點。他甚至在新產品裡加了 Sentry 做錯誤監控，每天早上收到一份報告，告訴他前一天有多少使用者在哪些環節遇到了問題。經營了 26 年的 ResumeWriters.com 從來沒有過這種東西。

最痛的一課跟效能優化有關。履歷生成的等待時間大約 90 秒，Brian 覺得這對消費者產品來說太慢了，於是花了大約十小時反覆調整，試圖把時間壓下來。結果改著改著，系統完全壞掉了。他問 Claude：「最後一個能正常運作的版本是什麼時候？」Claude 給了答案，但同時反對他回退（revert），理由是已經投入了這麼多心力，放棄太可惜。Brian 聽完直接否決：一個完全不能用的東西，談什麼沉沒成本？他強制回退到上一個穩定版本。Chris 聽完後給了一個更激進的建議：不要 refactor，直接把整個程式碼燒掉，讓 Claude 根據你這段時間學到的東西，從頭寫一份全新的規格書再重建。在 vibe coding 的時代，程式碼是便宜的，你的理解才值錢。舊的程式碼可以當零件拆著用，但不要被它綁住。

Brian 也發展出自己的品質控制方法。他會讓 Claude Code 在終端機裡跑出程式碼或方案，然後把輸出貼到另一個瀏覽器視窗裡的 Claude 對話中，問第二個 Claude：「你覺得它說得對嗎？」兩個 Claude 有時候會給出不同的判斷，Brian 就在中間挑有道理的那一個。他自嘲說：「我就像那個在中間的小孩，讓爸媽互鬥，然後從中間撈到我要的東西。」Chris 的做法更進一步：他用 OpenAI 的 Codex 來批評 Claude Code 產出的計畫檔案，跨模型交叉檢驗，當作一套簡易的評估系統。

我的觀察：真正的突破不是「非工程師能寫程式」

坊間談 vibe coding，最常見的框架是「現在不會寫程式的人也能做 app 了」。但 Brian 的故事指向一個更核心的命題：AI 消除的不是技術門檻本身，而是領域專家到產品之間那層有損的翻譯。

Brian 請了三年的工程師，那些工程師並非能力不足。問題是結構性的。Brian 腦子裡有 26 年、一千多份履歷累積起來的品質判斷力。那種判斷力是內隱的，靠直覺，靠模式辨認，壓縮不進一份產品規格書。當他告訴開發者「這份履歷感覺不對」，開發者根本沒有足夠的背景去解碼「感覺不對」到底是什麼意思。每一次溝通都是一次有損壓縮，專業知識在傳遞過程中不斷流失。三年做不出來，不是因為缺技術，是因為翻譯損耗太大。

用 Claude Code 自己做，這層翻譯就不見了。Brian 的專業知識直接進入提示詞和介面設計。當輸出不符合標準，他自己微調提示詞、調整流程、加一個驗證步驟，不需要把腦子裡的直覺翻譯成文字，再等另一個不懂這個領域的人去猜他的意思。他終於可以不靠中間人，直接把自己的判斷力寫進產品裡。

這對我們很多人都有意義。你不需要是創業家才會碰到「專業知識無法轉化為產品」的問題。任何在某個領域深耕超過十年的人，腦子裡都有一堆「感覺不對」的直覺。那些直覺是 AI 無法自己產出的東西，它們是你花了幾千個小時累積的模式辨認能力。在過去，這些直覺只能停留在你腦子裡，或者透過有損的翻譯勉強傳遞給別人。vibe coding 給了你一條更直接的路：跳過翻譯，直接把你知道的東西變成可以用的產品。這才是 Brian 的故事真正在說的事。