工程師如何用 Claude Code 把一週的工作壓縮到一天 | AI 賺錢
你每天有多少時間，不是在解決真正的問題，而是在打樣板碼、查不熟的 API 文件、手動補單元測試？我把這些事情交給 Claude Code 之後，同樣的工作量，原本要五天，現在大概一天半就搞定了。省下的那三天，我拿去接了兩個 自由接案，另一個月開始做自己的 SaaS 產品。這篇文章把我的實際工作流寫出來。
我用 Claude Code 之後，一週的工作長怎樣
先說我的背景：全端工程師，平常接一些 SaaS 外包、同時在跑個人部落格和幾個小產品。不是什麼大公司的人，就是一個在咖啡廳用筆電工作的獨立開發者。
用 Claude Code 之前的一週（5 個工作天）：
- Day 1：理解需求 + 搭環境 + 寫資料模型。大概花了 4 小時在手打 schema 和 migration。
- Day 2-3：寫 CRUD API。大量的 controller、service、repository 樣板，基本上複製貼上改改改。
- Day 4：寫測試。這個最痛苦，因為我不想寫但又不能不寫。
- Day 5：debug + 重構 + 收尾。其實每次都要加班。
用 Claude Code 之後的一週：
- Day 1 上午：理解需求 + 跟 Claude Code 對話把資料模型討論清楚。用
/init讓它掃 codebase，下午開始直接生 API。 - Day 1 下午：主要的 CRUD 全部跑起來。
- Day 2：寫測試（由 Claude Code 起草，我 review + 補邊界案例）。重構。加新功能。
- Day 3：收尾、文件、部署。還有半天空閒。
同樣的功能範圍，壓縮到兩天半。剩下的兩天半，我用來處理另一個案子的需求訪談、以及推進我自己的產品。
這不是在誇大。我沒有把 Claude Code 說成萬能的——我只是把重複的部分外包出去，自己專注在需要判斷的地方。
3 個最有感的用法
① 大量樣板 / CRUD：讓它直接生，你只要定義 schema
以前寫 NestJS 的 CRUD，光是建一個 module（controller + service + repository + DTO + entity + test）就要花 30-40 分鐘。現在我的做法：
- 把現有的一個 module 丟給 Claude Code 當範例（讓它理解你的命名慣例和程式碼風格）。
- 說清楚新 module 的欄位和業務規則。
- 叫它生成，然後跑 test，看哪裡壞掉。
生出來的程式碼不會是完美的，大概需要修 15-20% 的地方。但比從零開始還是快了三倍以上。
關鍵是：不要讓它猜你的慣例，直接給它範例。 這樣輸出的風格一致性會高很多，review 成本也低。
② 讀不熟的 codebase：問它而不是自己翻
接到一個外包，對方的 codebase 有 200+ 個檔案，你要在三天內開始出貨。以前我會花一整天只是在讀 code、畫架構圖、搞清楚資料流。
現在的做法：
- 先用
claude --dangerously-skip-permissions跑一次/init，讓它把整個 codebase 掃一遍（大概 5-10 分鐘）。 - 直接問：「
createOrder這個 function 的完整資料流是什麼？哪些 service 會被呼叫？」 - 問：「如果我要新增一個退款功能，最少需要動哪些檔案？」
這樣大概 1 小時就能對一個陌生 codebase 有足夠的理解，可以開始動手了。節省下來的時間，直接反應在接案報價的 ROI 上。
③ 寫測試與重構：最讓我改觀的地方
說實話，寫測試以前是我最拖的事情——知道要寫但就是會一直延。現在的流程：
- 寫完一個 service 之後，叫 Claude Code：「幫我針對這個 service 寫 unit test，包含 happy path 和常見 edge case。」
- 跑 test，哪個壞掉就丟錯誤訊息回去叫它修。
- 我再補幾個它沒想到的 edge case（這才是需要你真正理解業務的地方）。
測試覆蓋率從以前的 40% 提升到現在穩定的 70-80%，但花在測試上的主動時間反而減少了。
重構也是：把一段有 code smell 的程式碼丟給它，說「這段邏輯很亂，請幫我重構，保持相同行為」，它通常能給出一個不錯的起點，你再根據業務知識微調。
省下的時間，拿去做什麼
這才是這篇文章真正要聊的核心。
提升開發效率，不是讓你「做更多外包案子把自己再次榨乾」。時間才是你真正的資本，省下來的時間要用在能複利的事情上。
我自己分兩個方向用：
方向一：接更高價值的案子，而不是接更多案子
以前一個 CRUD 重型的案子我要花兩週，現在可以壓到一週內。這不代表我去接兩個案子——我用多出來的那一週，重新定位我的接案報價，從「按小時計費」轉成「按功能交付計費」。
因為我的交付速度變快了，但我報的價沒有跟著降。客戶不在乎你用了幾小時，他們在乎你能不能準時交付。效率提升 = 實際時薪翻倍，但客戶感覺沒有差。
方向二：把省下的時間投入自己的產品
這是我覺得更重要的方向。接案的本質還是「花時間換錢」，有時間上限的。但如果你在接案之外，把每週省下來的 10-15 小時投入自己的產品——SaaS、工具、課程、電子報——這些是能持續帶來回報的資產。
這類把重複開發工作交給 AI、把省下的時間系統性地轉換成收入的流程，我整理成了一份可以直接照做的入門包，放在這裡：AI 賺錢入門包。
如果你也在想怎麼把開發效率的提升，轉化成實際的額外收入，可以去看看。
延伸閱讀：
一個提醒：AI 提效不是取代你的判斷
用了 Claude Code 幾個月之後，我覺得有一件事要說清楚，因為我看到很多人在理解上有偏差。
Claude Code 是個非常稱職的「執行者」，但它是個很差的「決策者」。
它可以：
- 按照你定義的規格生成準確的程式碼
- 找出某個函數的 bug
- 解釋你看不懂的某段邏輯
- 按照某個模式做大量的重複性工作
它不擅長：
- 判斷這個功能到底值不值得做
- 在架構層面做取捨（因為它不知道你三個月後的 roadmap）
- 理解你的客戶為什麼需要這個東西
- 在業務邏輯有矛盾時，判斷哪個優先
我看過幾個工程師，讓 Claude Code 做完整個功能，自己幾乎沒有 review，直接推上 production。結果出現了一些「程式碼完全正確、但根本不是客戶要的東西」的問題。
你的判斷力，才是 AI 時代真正的護城河。 Claude Code 讓你把 80% 的重複勞動外包出去，但那剩下的 20% 需要你真正懂業務、懂架構、懂客戶——這個東西 AI 沒辦法取代你。
所以正確的使用心態是：讓 Claude Code 跑得更快，但你負責決定跑的方向。
總結
用 Claude Code 做 開發提效 這件事，我現在的體感大概是：
- 大量樣板 / CRUD 類的工作：速度提升 3-5 倍
- 讀陌生 codebase：上手時間縮短 60-70%
- 測試撰寫：主動投入時間減少一半，覆蓋率反而提高
但這些數字只有在你真的懂得把省下的時間用在對的地方時，才有意義。
如果你只是用 Claude Code 讓自己能接更多外包，加速把時間賣掉，那你其實只是在跑步機上跑得更快——位置沒有動。
真正有意思的地方，是把每週省下的那幾個小時，系統性地投入到能帶來複利的事情上。無論是更高品質的接案定位，還是你自己的產品。
開始的方式很簡單：下次遇到要打樣板碼的時候，先試試 Claude Code，然後把省下的那一個小時，拿去想你的產品 idea。