一個人用 AI 做產品，技術不是最大的瓶頸，時間與取捨才是。我訪談的 AI Resume Advisor 創辦人，過去有 11 年產品經理（PM）經驗，離職後用 Claude Code 一個人完成「先診斷、後優化」的履歷健檢系統。他在開發中遇到的最大困難是上下文限制，營運上最大的困難則是時間被切碎，他說一人公司真正要練習的是取捨：不是所有需求都接，要過濾雜訊，再有節奏地釋出新版本。
這位創辦人做了什麼產品？
AI Resume Advisor 是先診斷、後優化的履歷健檢系統，比對履歷與職缺並提出修改建議；創辦人是 11 年 PM，用 Claude Code 開發。
創辦人原本是理工背景，早期做過軟體與系統整合，後來擔任 11 年的 PM。開始做這個系統時，他已經十幾年沒有真正寫過程式。一開始他用 no-code 工具做原型，很快發現工具可以做出「看起來像產品」的東西，卻很難做到真正可擴充、可控制、可成長。於是他改用 Vibe Coding，讓 AI 成為他的開發團隊。產品網站是 airesumeadvisor.com。
他主要用 VS Code 搭配 Claude Code，把當年做 PM 的方法拿來與 AI 協作：先想清楚需求與產品流程，再讓 AI 提方案，透過追問收斂成可落地的規格，最後交付、測試、部署。
上圖是產品的評估紀錄頁：每次評估會顯示履歷與職缺、關鍵字與吻合度在修改前後的變化，並提供評估報告與客製化後的履歷。畫面是受訪者提供的截圖，數字只反映這一筆評估，不代表產品的一般成效。
對話越長，AI 越容易「鬼打牆」，怎麼處理？
AI 一次能處理的內容有上限，這個範圍稱為上下文視窗（context window）；專案規範、歷史與工具設定載入後，可用空間變少，對話變長，回答品質就會下降。
這是創辦人在開發中遇到的最大困境。當專案規範、歷史紀錄與工具設定都載入之後，AI 可用於推理的空間已被占去一大段；單一對話的歷史變長，AI 的回答品質就下降、開始鬼打牆。
上下文視窗變長後品質下降的現象，有官方的說明。Anthropic 工程團隊指出，隨著上下文視窗內的 token 數增加，模型準確回想內容的能力會下降，並稱之為 context rot（Anthropic，2025 年 9 月）；Claude Code 官方文件也把「上下文視窗很快就會填滿，填滿後表現下降」列為多數最佳實踐背後的限制（Anthropic，Claude Code Best practices）。
他的對策，是把 SOP 拆成獨立的「任務塊」：
- 整個專案的全域規範，放在 CLAUDE.md。
- 針對特定需求的 SOP，另外寫成較長的規範文件，需要時才啟動。
- 每個任務塊結束後，請 AI 給一份簡短的總結，再進入下一個任務塊。
他啟動任務塊的提示詞大致是：「現在啟動 Skill_SEO_Research.md 裡的任務塊。請讀取該檔案中的 SOP，並針對我提供的這個主題［主題名稱］產出清單。完成後請給我一個簡短的總結，以便我進入下一個任務塊。」
任務塊的做法與 Claude Code 官方的 Skills 機制相近：官方說明 Skill 的內容用到時才載入，平時成本很低，適合已經變成流程的步驟；CLAUDE.md 則每次對話都會載入，應保持精簡（Anthropic，Claude Code Skills 與 Best practices 文件）。創辦人的任務塊，可以視為手動版的同樣概念。
他另外用到 Claude Code 的 Agent teams 功能，開出一個「主管」加多個「隊友」，讓隊友在各自的工作階段裡獨立做事、互相傳訊、分工收斂。例如指定一個負責使用者體驗與前端規格，一個負責後端可行性與風險，讓他們討論後產出可落地的規格與風險評估。要注意，Anthropic 官方文件把 Agent teams 標示為實驗性功能、預設停用（Anthropic，Claude Code Best practices），使用前要確認自己的版本與設定。
規格、測試與部署紀錄怎麼做到「產品級」？
他讓每個需求先寫成規格才交給 AI 實作，重要功能有對應測試，上線前由 AI 做完整驗證，每次修改有紀錄、每次部署有檢查點。
他把開發節奏拉到產品團隊的等級，目的有兩個：確保快速迭代時品質穩定、不變混亂；讓後續 AI 產出的程式碼越來越穩定。規格清楚、測試完整、紀錄透明時，AI 每次修改都有明確的邊界與驗收標準，不需要「憑感覺改東西」。
上圖是他的測試結構：由下而上是單元測試、整合測試與端對端測試，圖中標示約 20 個 API 端點、200 個以上的測試案例。依書稿圖說，每次送交程式碼，都會由 AI 自動執行所有測試，確保部署穩定。
這與官方的建議一致。Anthropic 指出，要給 AI 一個它能自己執行的檢查，例如測試或建置結果；沒有它能執行的檢查，AI 只會在「看起來完成」時停下，使用者就成了唯一的驗證迴圈（Anthropic，Claude Code Best practices）。
他怎麼讓 AI 協助查看營運狀況？
他在產品中記錄註冊、首次使用、升級轉換與失敗原因等行為，整理成 AI 讀得懂的結構，出問題時請 Claude 搭配 Azure CLI 查雲端紀錄。
他不只做營運看板。他在產品裡埋下關鍵的使用者行為紀錄，並整理成結構化格式，讓紀錄不只是儲存下來，還能被 AI 分析。出問題時，他可以下指令讓 AI 直接去查雲端系統的 log。
| 他問 AI 的問題 | 想知道什麼 |
|---|---|
| 為什麼今天轉換率下降？ | 轉換流程在哪個環節出問題 |
| 哪個 API 最近錯誤率升高？ | 後端哪個服務出現異常 |
| 使用者卡在哪一個流程？ | 使用者行為的斷點 |
| 最近三天有沒有異常？ | 近期的異常趨勢 |
他說 AI 不只回傳原始資料，還會整理可能原因與建議方向。在一人公司裡，這等於把營運分析與技術問題排查都交給 AI，他只負責下指令與做決策。
讓 AI 查營運紀錄的概念，與 Claude Code 官方文件的建議一致：官方說明用命令列工具與外部服務互動，是最節省上下文的方式，並建議明確請 Claude Code 使用 gh、aws、gcloud、sentry-cli 這類工具，也可以把紀錄檔直接以管線傳給它分析（Anthropic，Claude Code Best practices）。書稿沒有說明他使用的具體指令、事件名稱或實際的查詢結果，本文的問題清單是他的範例，不是完整紀錄。
給 AI 查營運紀錄時，有三件事要先想：
- 資料範圍： 紀錄裡是否含使用者個資，要不要先去識別化再交給 AI。
- 權限： 交給 AI 的帳號權限，建議限於唯讀。
- 查證： AI 整理的「可能原因」是推測，要回到原始紀錄確認，再做決定。
這三點是我的整理建議，不是受訪者的做法。
一人公司最大的瓶頸，為什麼是取捨？
一人公司的創辦人同時是開發者、PM、營運分析、行銷與社群經營者，時間被切碎；他認為要練習的是取捨，不接所有需求，過濾雜訊，再有節奏地釋出版本。
他坦白說，最大的困難不是技術，而是時間不夠用。今天寫功能，明天要發文推廣，後天要回應使用者回饋，角色頻繁切換，產出容易被打斷，效率也隨之下降。他說：「一人公司真正要練習的，是取捨的能力。」
他給了一個過來人的建議：
- 過去：先花幾個月把產品做完，再推廣。
- 現在：先做出產品頁與功能介紹，到社群推廣並蒐集有興趣的使用者名單，確認產品與市場需求一致，再做最小可行產品（MVP），邊做邊取得回饋。
這樣產品真正上線時，就已經有第一批潛在的付費客戶。這是他的個人經驗，沒有數據證明這個順序一定比較好；它適合的是可以在產品完成前就向目標客群說明價值的產品。
哪些條件可以借鏡？
可借鏡的是用規格思維帶 AI、拆任務控制上下文、用測試限制修改範圍；但他有 11 年 PM 經驗，不是每個人的起點都相同。
| 他做的事 | 可借鏡的原則 | 要留意 |
|---|---|---|
| 先寫規格再讓 AI 實作 | 給 AI 明確的邊界與驗收標準 | 規格要有人寫得清楚，這是他 PM 經驗的優勢 |
| 全域規範放 CLAUDE.md，特定 SOP 做成任務塊 | 控制上下文的使用 | 任務塊內容要實際測試是否有效 |
| 每次送交程式碼自動跑測試 | 把驗證交給可重複執行的檢查 | 測試本身也要有人維護 |
| 讓 AI 查紀錄、分析營運 | 縮短排查時間 | 先處理個資與權限，結論要回頭查證 |
| 先推廣再做 MVP | 在投入開發前驗證需求 | 是個人經驗，不是通則 |
常見問題
一個人可以用 AI 做出完整的產品嗎？
以這個案例來說可以，但他有 11 年 PM 經驗，擅長把需求寫成規格，並有測試、部署紀錄與營運分析的完整流程。他也表示，一個人最大的挑戰是時間被切碎與取捨，而不是技術。
AI 對話越長越不準，要怎麼辦？
Anthropic 的文件說明，上下文填滿後表現會下降。創辦人的做法是把全域規範放在 CLAUDE.md，特定 SOP 拆成獨立文件、用到時才啟動，並在每個任務塊結束時請 AI 給簡短總結。
怎麼讓 AI 協助查看產品的錯誤與使用者流程？
先在產品裡記錄關鍵的使用者行為與失敗原因，整理成結構化格式，再讓 AI 搭配命令列工具查詢雲端紀錄。要先處理個資、限制權限，並回頭查證 AI 的推測。
什麼時候該用 no-code 工具，什麼時候該用 Vibe Coding？
依創辦人的經驗，no-code 工具適合做出看起來像產品的原型，但要做到可擴充、可控制、可成長的產品很困難，所以他改用 Vibe Coding。這是他的個人判斷，取決於產品需求。
一人公司應該先做產品還是先推廣？
他的建議是先做產品頁與功能介紹，到社群蒐集有興趣的使用者名單，確認需求後再做 MVP。這是他的經驗，不是通則，也沒有數據證明優劣。
資料來源與說明
本文整理自我在撰寫書稿期間，對 AI Resume Advisor 創辦人的訪談，內容為受訪者自述。產品畫面的數字只反映單筆評估。書稿沒有提供他實際的任務塊檔案、事件命名或查詢結果，因此本文只呈現他描述的做法。與官方文件的對照，引自下列頁面。
參考資料
- Anthropic，〈Effective context engineering for AI agents〉，Anthropic Engineering，2025 年 9 月 29 日，存取日期：2026 年 10 月 19 日。
- Anthropic，〈Best practices for Claude Code〉，現行文件，存取日期：2026 年 10 月 19 日。
- Anthropic，〈Skills〉，Claude Code 文件，現行文件，存取日期：2026 年 10 月 19 日。
延伸閱讀
- 不熟 Swift 也能做出雙平台 App？mojo 創辦人 Hana 如何把 AI 開發做成工作制度：另一位用 Claude Code 做產品的創辦人，如何把回顧變成規則與 Skill。
- 老闆先用 AI 驗證想法，核心工程師再整合：蒲公英創意商業研究所（MAXO）的開發分工轉型：新創如何決定誰做原型、誰負責上線。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19