獨自賺取 160 萬美元：全球頂尖創作者使用的進階 Claude Code 工作流程

不只把 AI 當作寫程式的工具，而是把它當作 24 小時全年無休的一人公司員工

當人們聽到「用 AI 賺錢」時，多數人想像的都是同樣的事情：

• 用 ChatGPT 寫部落格文章
• 用 AI 大量生產圖片
• 把 AI 生成的影片上傳到 TikTok
• 用 AI 寫程式來大量生產應用程式

然而，單靠這些方法要賺到可觀的收入，案例並不多。

這是因為你只是用 AI 來增加「工作量」。

即使文章從 10 篇增加到 100 篇，如果沒有讀者，收入也不會增加。即使應用程式從 1 個增加到 10 個，如果沒有解決客戶的問題，也不會有人付費。

AI 時代真正厲害的人，不是把 AI 當作內容製造機。

他們是用 AI 來讓公司本身變得更小。

他們不雇用開發者。

他們不增加客服。

他們不開會。

他們不讓人在規格之間傳遞。

他們不經過從本機到正式環境的多階段程式碼交接。

當客戶的要求進來時，AI 會讀取程式碼、修復它、測試它，並在幾分鐘內準備好讓使用者可以操作。

一個極端的例子是獨立開發者 Pieter Levels。

他使用 Claude Code 的方式可以用一句話總結：

不是把 Claude Code 當作「方便的寫程式助手」，而是當作「住在伺服器裡的員工」。

在這篇文章中，我們將拆解 Pieter 的做法，並轉換成日本獨立開發者和小型企業主可以複製的形式。

Pieter Levels 是誰？

Pieter Levels 是一位獨立開發者，推出過多個網路服務，例如 Nomad List、Remote OK、Photo AI 和 Interior AI。

他廣為人知的原因之一，是他「在 12 個月內打造 12 家新創公司」的專案。他不是募大筆資金來建立組織，而是遵循快速釋出服務，只培育那些有反應的服務的風格。

他目前的主力服務之一是 Photo AI，這是一個 AI 照片生成服務。

使用者上傳自己的照片，服務會建立該人物的 AI 模型，以生成攝影棚風格的照片、大頭照、時尚照、旅遊照、影片等。Photo AI 官方網站表示，至今已生成超過 3000 萬張照片。

2024 年 3 月，Pieter 公開了 Photo AI 的以下數據：

更令人驚訝的是，他透露該服務的核心是一個約 40,870 行的單一巨大 PHP 檔案。

典型的工程師聽到這個可能會皺眉頭。

「這麼大的檔案無法維護。」

「應該拆成微服務。」

「應該用更現代的框架。」

但收入並不是因為程式碼漂亮而支付的。

如果你正在交付使用者想要的結果，並維持那個狀態，那麼技術配置不需要遵循教科書。

Pieter 的強項不是比任何人都了解更尖端的技術。

而是他徹底捨棄那些與收入無關的複雜性。

嚴格來說，他不是「只靠 AI」賺錢

不要誤解這部分。

Pieter 不是某天突然開始碰觸 Claude Code，然後就靠 AI 一年賺 160 萬美元。

他擁有多年開發經驗。他擁有網路名氣和追隨者，可以向他們行銷產品。他擁有判斷市場的判斷力、定價能力，以及解讀使用者反應的經驗。

AI 不是從零創造一切。

AI 放大了他原本就擁有的開發能力、判斷力和行銷能力。

這個差異很大。

使用 AI 並不會讓經驗變得不需要。相反地，隨著 AI 提升實作速度，判斷「該做什麼」、「賣給誰」、「不做什麼」的價值變得更高。

因此，這篇文章的真正主題不是「在 Claude Code 裡輸入什麼神奇提示詞就能賺數百萬」。

而是 如何建立一個讓一個人能像一家公司一樣移動的系統，使用 Claude Code。

方法 1

讓 Claude Code 住在 VPS 上，而不是筆電上

Pieter 操作中最獨特的特點是，他在服務運行的 VPS 上執行 Claude Code，而不是在本機筆電上。

根據他的說法，大約一年來，他幾乎所有程式碼都是在 VPS 上用 Claude Code 完成的。即使關上筆電，他也能繼續處理；不耗電；而且可以從另一個終端機或智慧型手機接手工作。因為新服務可以從已經在伺服器上的狀態啟動，所以可以直接推向公開釋出。

典型的開發流程是這樣的：

1. 規劃
2. 在本機環境寫程式碼
3. 在本機測試
4. 推送到 GitHub
5. CI 執行
6. 反映到測試環境
7. 確認後部署到正式環境

在大型組織中，這個流程是必要的。因為數十位工程師操作同一個系統，所以需要防止意外的界線。

但當你把大公司的流程帶進一個人經營的小型服務時，會發生什麼事？

修復本身只需 3 分鐘，但上線卻要花 20 分鐘。

小麻煩累積起來，就會增加「這個修改可以晚點再做」的判斷。即使客戶的要求進來了，修復也被推到明天或下週。

Pieter 把這個等待時間變得極短。

以前，在本機測試並透過 GitHub 自動部署大約需要 1 分鐘。改成直接推送到伺服器後，大約需要 3 秒，現在他正朝著讓 Claude Code 直接在伺服器上修改程式碼的方向前進。雖然他提到網站 12 個月內只當機了約兩次，每次約 10 秒，但他也明確表示大公司會使用測試環境。

這裡要模仿的不是「每個人都應該直接編輯正式環境」。

應該模仿的是 把 AI 放在它可以持續工作的地方。

只要你在自己的電腦上執行 Claude Code，關上筆電工作就停了。如果連線中斷，也停了。如果換到另一個終端機，你必須從頭解釋情境。

透過在 VPS 上維持持久 session，AI 可以一直待在專案旁邊。

這不只是環境設定的差異。

這是 把 AI 可以工作的時間與人類的作業時間脫鉤 的想法，而不只是增加「使用 AI 的時間」。

方法 2

為每個產品建立專屬的持久 session

Pieter 使用 Termius 連接到 VPS，並為每個服務準備連線設定檔。

連線後，他移動到該服務的目錄並進入對應的 tmux session。在每個 session 中，Claude Code 保持開啟，讓他可以從筆電或智慧型手機回到相同的工作。他甚至讓 Claude Code 建立了 shell 函數，讓連線和回到 tmux 變得更簡單。

這個系統的重點不是終端機操作看起來很酷。

而是 每個產品都有自己的專屬工作間。

• Photo AI 的工作間有 Photo AI 程式碼和 Claude Code。
• Nomad List 的工作間有 Nomad List 程式碼和 Claude Code。
• Remote OK 的工作間有 Remote OK 程式碼和 Claude Code。

當人類切換產品時，只需要進入那個工作間。

一般的聊天型 AI，每次開始對話都需要解釋事情。

「這是這類服務。」

「上次我做到這裡。」

「請不要更改這個檔案。」

「用這個指令執行測試。」

這些解釋成本會剝奪 AI 使用的速度。

另一方面，如果你在專案目錄中保持 Claude Code 執行，AI 可以直接存取程式碼、設定檔、測試和歷史記錄。即使人類不從零解釋，它也可以調查「這個產品的當前狀態是什麼」。

Anthropic 的官方文件也說明，Claude Code 不只是回傳程式碼建議的工具，而是一個進階工具，可以進行讀取檔案、執行指令、修改程式碼、調查、規劃和實作。

換句話說，要發揮 Claude Code 的優勢，你需要讓它在可以存取整個產品的地方工作，而不是每次在聊天框中貼上程式碼片段。

方法 3

傳遞「完成狀態」，而不是「撰寫程式碼」

即使使用 Claude Code 也得不到結果的人，不是指令太詳細就是太模糊。

例如，像這樣的請求：

請改善登入畫面。

這樣一來，不清楚什麼樣的改善才算完成。

• 改變設計？
• 改變錯誤顯示？
• 提高登入速度？
• 新增 Google 登入？
• 想要降低跳出率？

相反地，逐行指示程式碼也很沒效率。

在檔案的第 35 行新增一個函數，然後改變這個變數名稱...

在這種情況下，你只是把 Claude Code 當作一個比你自己打字更快的鍵盤。

你應該傳遞的不是工作步驟，而是 完成條件。

實務上，像這樣的格式很容易使用：

目標：

減少因登入錯誤而流失的使用者。

當前狀態：

無論是密碼錯誤還是連線錯誤，都顯示相同的「登入失敗」。

變更範圍：

登入畫面、認證 API、相關測試。

完成條件：

• 輸入錯誤和連線失敗顯示不同的訊息。
• 不向外洩漏電子郵件地址的存在。
• 不破壞現有的 Google 登入。
• 在智慧型手機顯示上不破壞版面。
• 所有相關測試通過。

禁止事項：

• 不改變資料庫結構。
• 不新增新的認證函式庫。

完成後：

• 總結變更過的檔案。
• 顯示執行的測試。
• 報告剩餘風險。

以這種格式，Claude Code 可以調查程式碼庫，自己找到要變更的位置，並思考實作方法。

人類的角色從「如何撰寫」轉變為「什麼狀態能提供價值」。

在這裡，管理和開發結合在一起。

要寫出好的完成條件，你必須了解客戶在困擾什麼。一個人如果觀察客戶行為、付費原因和流失原因，就能給 Claude Code 比只關注技術的人更有價值的工作。

在 AI 時代，重要的不是提示詞的詞彙。

而是定義完成狀態的能力。

方法 4

把 CLAUDE.md 變成「一人公司營運手冊」

Claude Code 有一種機制，可以將專案特定的指令保存在 CLAUDE.md 中。

官方文件說明，CLAUDE.md 在對話開始時被讀取，讓你可以列出建置和測試指令、程式碼慣例和工作規則。但建議保持簡短具體，而不是長篇手冊，也不要寫那些可以透過閱讀程式碼理解的內容。

大多數人只會在這裡寫縮排寬度或變數命名規則。

但在一人公司中，真正重要的不是程式碼風格，而是 業務優先順序。

例如，你可以這樣寫：

產品目標

• 這個服務是為了讓個體經營者在 10 分鐘內建立產品照片。
• 優先考慮首次生成的速度，而不是功能數量。
• 對於會增加免費使用者使用量的變更，務必檢查對成本價格的影響。

架構

• 使用 PHP、JavaScript、PostgreSQL。
• 未經明確許可，不得新增框架。
• 如果可以用現有機制解決，就不要增加依賴。

工作流程

• 在變更前，先讀取相關程式碼和測試。
• 對於大型變更，在實作前提出計畫。
• 變更後，執行測試、靜態分析，並檢查主要畫面。
• 不要因為測試失敗就刪除它來解決問題。

安全

• 不要刪除正式資料。
• 資料庫變更要附上復原程序。
• 不要將 API 金鑰或個人資訊輸出到日誌。
• 處理帳單、認證和刪除功能時要極度謹慎。

完成定義

• 能夠從使用者的角度解釋變更。
• 報告測試結果。
• 列出變更過的檔案。
• 清楚說明已知風險和未處理的事項。

只要有這個，就不需要每次重複相同的注意事項。

更重要的是，當 Claude Code 犯錯時要如何處理。

不要只是生氣「它又犯了同樣的錯誤」，而是將防止再發的規則加入到 CLAUDE.md 中。

如果它更改了正式設定檔，就寫「未經明確許可，不得更改設定檔」。

如果它為了通過測試而刪除了重要的驗證，就寫「禁止刪除失敗的測試」。

如果它格式化不相關的檔案導致 diff 變很大，就寫「不要執行與請求無關的重構」。

Anthropic 也指出，反覆發生的錯誤或多次解釋的事情，是應該加入永久指令的訊號。

換句話說，CLAUDE.md 不只是 AI 的設定檔。

它是一人公司中累積的失敗和判斷的資料庫。

在雇用員工的公司中，知識會累積在培訓教材或內部 Wiki 中。

在一人公司中，你讓 Claude Code 來讀取它。

方法 5

減少核准工作，增加防護措施

Pieter 使用一種大幅省略 Claude Code 權限檢查的模式，在伺服器上高速工作。

他聲稱自從改用這種操作方式後，開發速度飛快，他的任務清單首次變空，並且達到了平常約 10 倍的產出。他在短時間內完成了跨越多個產品的變更，包括認證和安全性改善、圖片功能、影片/音訊功能、3D 檢視器、電子報、聊天機器人和電子書生成。

然而，完全複製這部分是很危險的。

Claude Code 的官方文件明確指出，等同於 bypassPermissions 的操作只應在有外部安全邊界時使用，例如隔離的容器或虛擬機器。因為一旦省略確認，最後一道防線就只有執行環境的隔離。

如果日本獨立開發者要採用這個方法，與其完全複製 Pieter 的操作，不如將其轉換如下：

調查階段使用計畫模式

首先，讓它調查相關檔案、影響範圍、實作政策和風險，但不讓它改變程式碼。

特別是對於帳單、認證、資料刪除和電子郵件傳送這些事故影響大的部分，不要讓它立即實作。

在測試環境中自動化實作

準備一個與正式環境配置相似的測試環境，讓 Claude Code 在那裡進行變更和測試。

不是每次都核准每個指令，而是預先區分允許的操作和拒絕的操作。

官方文件提供了多種權限模式，例如 acceptEdits 允許變更、auto 自動判斷安全性、plan 只建立計畫。你也可以針對每個指令設定 allow、ask 和 deny。

只留下一個人類閘門來反映到正式環境

• 測試通過。
• 畫面確認完成。
• diff 在預期範圍內。
• 有復原方法。

一旦達到這個狀態，人類才允許反映到正式環境。

重要的不是人類撰寫每一行程式碼。

而是建立一個在出錯時可以還原的結構，讓人類只處理最終不可逆的判斷。

方法 6

優先考慮測試和復原，而不是程式碼審查

當 AI 開始產生大量程式碼時，人類逐行檢查所有程式碼的方法會達到極限。

即使程式碼生成速度加快 10 倍，如果審查需要 10 倍的時間，生產力也不會提高。

因此，變得必要的是改變信任的對象。

不要相信「Claude 一定寫了正確的程式碼」。

要信任這個系統：

• 「如果錯了，測試會失敗。」
• 「主要使用者操作可以自動確認。」
• 「如果有問題，可以立即還原到先前的狀態。」

Pieter 自己優先考慮的是準備測試和在正式環境中快速確認的回饋迴圈，而不是詳細檢查所有內容。他也說明伺服器有多個備份，結合了本地和遠端。

在安全的 Claude Code 操作中，至少先建立以下四項：

1. 主要功能的自動化測試。
2. 反映到正式環境前的操作確認。
3. 監控以偵測錯誤和收入異常。
4. 可以在幾分鐘內還原到先前狀態的復原機制。

使用 Claude Code 的 Hooks，你也可以自動化流程，例如在檔案變更後執行測試或格式化程式，或在特定操作前插入檢查。Hooks 是一項官方功能，可以在 Claude Code 的特定生命週期執行 shell 指令、HTTP 處理、LLM 判斷等。

例如，在變更後自動執行以下流程：

程式碼變更

↓

自動化測試

↓

靜態分析

↓

主要頁面的操作確認

↓

diff 總結

↓

如果發現問題，停止反映到正式環境

透過這個，人類的工作從「檢查所有內容」變成「只檢查異常」。

能獨自賺大錢的人，不只是工作速度快。

他們是減少需要確認的工作本身。

方法 7

把客戶請求直接變成 Claude Code 的工作佇列

在 Pieter 公開的一人公司配置中，他結合了收集使用者請求的回饋專案、客戶的 Stripe 帳單管理畫面、使用者可以自行操作的退款功能，以及使用 ChatGPT API 的自動化處理。

他所展示的理想型態是「1 位創辦人，0 位人類」，一個由他處理行銷、開發和設計，並盡可能自動化其他所有事物的模型。

在這裡，Claude Code 不只是用來建立新功能。

它變成一個將客戶聲音轉化為改善，並帶來收入的裝置。

例如，像這樣的流程：

使用者發布請求

↓

分類相似請求

↓

檢查對流失率和帳單率的影響

↓

選擇一個高價值項目

↓

Claude Code 調查影響範圍

↓

實作和測試

↓

通知使用者改善

當你建立這個系統時，任務管理的意義就改變了。

在許多公司中，收到請求後，他們會開會、寫規格、決定負責人、放入 sprint，然後幾週後才上線。

在一人公司中，有可能當天就釋出。

小型公司能贏過大型公司的，不是功能數量。

而是客戶聲音反映到產品中的時間。

如果你已經導入 Claude Code，但人類仍然在詳細拆解任務、複製貼上程式碼，並逐一指定變更位置，那麼你並沒有充分利用 AI 的速度。

傳遞客戶問題和完成條件，讓 Claude Code 自己去調查程式碼庫。

這就是把它當作聊天機器人和把它當作員工之間的差異。

方法 8

大膽避免使技術配置複雜化

Photo AI 的核心是一個超過 40,000 行的單一 PHP 檔案，這並不代表所有開發者都應該建立巨大的檔案。

相反地，模仿表面形式是危險的。

對 Pieter 來說，重要的不是它是 PHP 或巨大檔案。

重要的是被認為是 將系統維持在他和 Claude Code 可以掌握整體的範圍內。

這是基於公開資訊的推測，但如果你將產品拆分為太多小型服務，每次變更都會跨越 multiple 儲存庫、API、認證方法和部署程序。

對人類來說複雜的系統，對 AI 來說也是複雜的。

• 需要載入到上下文中的檔案更多。
• 調查變更位置需要時間。
• 只更新一側會導致不一致。
• 測試範圍擴大。
• 故障時識別原因變得困難。

即使有 Claude Code，你也不能管理無限複雜的技術配置。

AI 降低了複雜性的成本，但並沒有讓它變成零。

因此，當你引入新的函式庫、新服務、新資料庫或新框架時，要這樣思考：

這項技術是否增加了客戶獲得的價值？ 還是只是為了開發者的技術滿足感？

一個創造出年營業額 2 億日元產品的人，不一定選擇了最新的配置。

這對許多獨立開發者來說是一個重要的事實。

方法 9

讓 Claude Code 建立「公司自動化」，而不只是「開發」

許多使用 AI 程式碼工具的人只考慮實作產品功能。

然而，要獨自賺大錢，不僅僅是做出產品。

• 回應詢問。
• 偵測詐欺使用。
• 更改帳單資訊。
• 退款。
• 取消。
• 內容審查。
• 故障通知。
• 定期報告。
• 收入彙總。
• 引導客戶。

隨著業務成長，這些營運工作會增加。

如果收入翻倍，詢問也會翻倍，如果需要兩倍的人力，一人公司就無法維持。

在 Pieter 公開的配置中，他透過 Stripe 客戶功能、自助管理畫面、自動退款和使用 AI API 的工作腳本，減少了人類介入的點。

你應該讓 Claude Code 做的，不只是新的華麗功能。

而是消除「你每週花 30 分鐘做的工作」的程式碼。

例如，如果你每天早上檢查收入並寫到 Slack，就建立自動化報告。

如果有很多相同問題的詢問，就改善管理畫面或幫助頁面。

如果每次有退款請求時你都要操作管理畫面，就建立有條件的自助退款。

如果你正在用視覺檢查詐欺使用，就偵測異常值並只傳送需要人類判斷的案例。

每一個都是小小的自動化，但它們加起來會改變公司的固定成本。

建立能消除你自己工作的功能，就像建立能增加收入的功能一樣。

這就是為了留下利潤的 Claude Code 使用方法。

方法 10

讓 Claude Code 成為背景工作者

Claude Code 不只是在使用互動畫面時使用。

官方提供了非互動式執行（使用 claude -p）、使用有限允許工具的執行、結構化輸出和 session 延續等功能。它也被設計為從 CI 或腳本呼叫，並整合到背景處理中。

利用這個，你可以在沒有人類開始對話的情況下生成工作。

例如，每晚執行以下流程：

1. 檢查過去 24 小時的錯誤日誌。
2. 將被認為有相同原因的錯誤分類。
3. 調查重現方法。
4. 建立修復建議。
5. 在測試環境中修復。
6. 執行測試。
7. 隔天早上，向人類報告 diff 和風險。

或者，讓它分析從使用者收到的詢問：

1. 按主題分類查詢。
2. 彙總計數與營收影響。
3. 提取可透過產品原因解決的項目。
4. 按優先級排列改善候選項目。
5. 為最高優先項目制定實施計劃。

到了這個階段，Claude Code 不再是「只有在人類與它對話時才會回應的 AI」。

它變成了一位員工，能夠在夜間完成調查，並在早上準備好判斷資料。

然而，越是讓它在背景執行，安全設計就變得越重要。

將刪除、轉帳、計費、大量發送給客戶以及變更生產資料等不可逆的操作，排除在自動化範圍之外。

你必須將賦予 AI 的自由度與故障時的損害範圍視為一組來考量。

最大的祕密

即使你用 Claude Code 提升了開發速度，客戶也不會增加

在 Pieter 的文章中，最重要的並非技術層面的討論。

他指出，有許多獨立開發者沉迷於打造複雜的 AI Agent 環境或「AI 開發工廠」，卻沒有任何營收或流量。他說這些人滿足於建立開發環境，而把行銷放在次要位置。

此外，他提到，隨著任何人都能用 AI 製作應用程式，真正的挑戰變成了分發——也就是觸及客戶的能力。

• 你已經能透過資訊觸及很多人了嗎？
• 你能負擔廣告成本嗎？
• 你能產生 UGC（用戶生成內容）嗎？
• 你有辦法免費製造話題嗎？

隨著開發變得更容易，這些分發能力的差異會變得更大。

這就是 AI 時代殘酷的現實。

當你導入 Claude Code，功能可以快速打造出來。

然而，即使開發速度提升 10 倍，如果流量是零，營收就是零。

更危險的是，由於你能快速建構，你可能會大量生產沒有需求的東西。

每次新增功能，程式碼量、測試、失敗風險和查詢回應都會增加。

即使客戶沒有增加，維護項目卻增加了。

因此，從 Claude Code 中節省下來的時間，有一半必須用在開發以外的事情上。

• 傾聽客戶。
• 閱讀競爭對手的產品評論。
• 調查為什麼產品賣不出去。
• 測試價格。
• 改寫銷售頁面。
• 發布案例研究。
• 在社群媒體上分享生產過程。
• 建立讓用戶想要介紹給他人的機制。

Claude Code 的真正價值並非縮短寫程式碼的時間。

而是讓人類有時間去思考客戶與市場。

日本獨立開發者可以複製的 30 天計畫

即使你沒有 Pieter 那樣的經驗、名氣或粉絲，你也可以採用他的經營哲學。

但你不能一開始就建立多項服務。

首先，專注於一個產品、一個客戶、一個問題。

第一週：在寫程式碼之前，先找到願意付費的人

第一週要做的不是一個完成的服務。

決定你要解決誰的問題、如何解決、以及收費多少。

不要擴大目標範圍。

不要做「給所有公司的 AI 工具」，而是縮小範圍，例如「讓房地產公司在 10 分鐘內建立物業描述的專用工具」。

與潛在客戶交談，確認他們目前使用什麼方法、花費多少分鐘、以及困擾程度有多高。

然後建立一個簡單的銷售頁面。

不要只放免費註冊按鈕，如果可以的話，顯示價格。加入能讓用戶真正採取行動的機制，例如預先註冊、預約、或小額預購。

如果在這個階段沒有反應，即使讓 Claude Code 大量生產功能，情況也不會改變。

第二週：只提供一個價值

接下來這週，只製作核心功能，也就是用戶會付費的那個功能。

將登入、管理後台、詳細個人資料設定、大量模板、團隊功能等，延後到它們變得必要時再處理。

先讓 Claude Code 調查現有配置並建立實施計畫。

計畫確認後，讓它在測試環境中進行實作與測試。

這個階段必須包含的東西有：流量分析、計費、錯誤監控和客服窗口。

無法確認營收的產品不是商業。無法確認錯誤的產品無法自行運作。

第三週：建立一個 Claude Code 不會迷失的環境

第三週，與其增加新功能，不如先打好營運基礎。

在 CLAUDE.md 中寫下產品的目的、技術配置、禁止事項、測試方法和完成條件。

每個產品準備一台 VPS 或安全的開發環境，以及一個持續運作的對話 session。

確保當 Claude Code 做出變更時，測試、靜態分析和主要畫面的操作確認會自動執行。

同時也要確認備份和還原機制。

這裡的目標不是「完全信任 AI」。

而是確保即使 AI 犯了錯，業務也不會遭受致命打擊。

第四週：花在銷售上的時間要與開發時間相同

最後一週，每天發布一個改善。

但不要憑自己的喜好決定改善內容。

要根據用戶的反應來決定，例如查詢、流失點、付款前的行為、以及取消原因。

• 早上，選擇一個對營收影響最大的問題。
• 要求 Claude Code 調查並實作。
• 測試後發布。
• 下午，通知客戶這項改善。

如果你分享你改善了某件事，這本身就是一種行銷。

與其說「我正在開發」，不如展示「我昨天收到的請求，今天已經實作完成」，這能傳達產品的速度與可靠性。

經營一人公司的日常循環

導入 Claude Code 之後，不要註冊一大堆任務，而是每天執行以下循環：

早上：查看數據

查看營收、註冊數、付費轉換率、取消數、錯誤和查詢。

從業務的狀態開始一天，而不是從程式碼開始。

上午晚些時候：選擇一個價值最高的問題

與其做十個小任務，不如選一個。

判斷標準不是「這個有趣嗎？」，而是對營收、留存率和使用成功率的影響。

中午：將完成條件交給 Claude Code

讓它調查相關程式碼並確認計畫。

之後，讓它進行實作、測試和 diff 摘要。

人類不需要詳細指示工作步驟，而是要傳達客戶的「正確答案」。

下午：發布並觸及客戶

發布改善後還不算結束。

通知發送相關請求的用戶。在社群媒體上分享生產過程。反映在銷售頁面上。做成案例研究。

永遠將開發出來的東西與分發連結起來。

晚上：將當天的失敗轉化為規則

確認 Claude Code 在哪裡迷失了方向、在哪裡做了不必要的變更、以及人類多次解釋了什麼。

如果必要的話，在 CLAUDE.md 中加入簡短的規則。

每一天，AI 都會一點一滴地為你的公司最佳化。

絕對不能模仿的事

Pieter 的案例很刺激，但只模仿表面是會失敗的。

突然讓它在生產環境中自由運作

在處理生產資料、計費、認證和客戶通知的環境中，跳過所有權限檢查是很危險的。

首先，在隔離的開發或測試環境中運作，並限制允許的操作。官方文件也指出，省略權限檢查的模式需要容器或 VM 等隔離措施。

只模仿巨大的 PHP 檔案

一個 40,000 行的檔案並不會產生營收。

這是 Pieter 選擇一種他自己能理解且能快速變更的配置的結果。

技術配置應該根據你的產品、經驗、用戶數量和失敗風險來決定。

在未確認需求的情況下，用 AI 大量開發

當開發成本降低時，判斷要不要做的標準會變得鬆散。

不要「因為能快速做出來就做」，而要「因為是付費客戶的問題才做」。

在向 Claude Code 提出請求之前，先決定這個變更會改善哪個數字。

混淆營收、利潤和個人收入

每月營收 105,000 美元和每月利潤 80,000 美元是不同的數字。

此外，業務利潤和個人實際收入也不一樣。它會因稅務、結算費用、基礎設施成本、AI API 成本、退款等處理方式而改變。

當看到大數字時，你需要確認它是「營收」、「毛利」、「營業利潤」，還是「個人收入」。

假設 AI 會修正商業判斷

Claude Code 可以調查程式碼庫、建立實施計畫並執行測試。

然而，那個功能是否真的必要、要定價多少、以及要鎖定哪些客戶，單靠讀取程式碼是無法理解的。

當你把市場判斷交給 AI 的那一刻，你的產品就會變得和其他 AI 用戶一樣平庸。

創造百萬收入的不是什麼祕密提示詞

認為「只要用同樣的提示詞，我就能賺到錢」是錯誤的。

祕密不在提示詞裡。

• 將 Claude Code 放在 VPS 上。
• 為每個產品提供一個持續的 session。
• 傳遞完成條件。
• 在 CLAUDE.md 中累積判斷標準。
• 透過測試和備份為失敗做好準備。
• 立即將客戶的請求反映在產品中。
• 自動化你重複執行的營運任務。
• 將省下來的時間用於行銷。

真正的力量在於將這些組合成一個單一系統。

Claude Code 的價值不在於能快速寫程式碼。

而是在於能讓以下循環變得極短：

客戶遇到困難 ↓ 了解原因 ↓ 修復 ↓ 發布 ↓ 衡量結果

一個正常公司需要數週的循環，你一個人可以在一天內完成，有時甚至只需幾小時。

如果這種速度持續數月，產品之間的差異將變得巨大。

然而，AI 創造的是供給，而不是需求。

• 你解決的是誰的問題？
• 他們為什麼付費？
• 你要如何讓你的存在被知道？
• 為什麼選擇你的產品而不是競爭對手的？

人類必須找出這些問題的答案。

在 AI 時代，「只有海外天才在做的事」並非撰寫困難的提示詞。

而是利用 AI 在 AI 搶走他們的工作之前，將「工作」本身從公司中消除。

而且，他們將消除工作所節省下來的時間，不是用來寫更多程式碼，而是用來理解客戶和銷售產品。

這就是為什麼即使只有一個人，也能經營年營收 2 億日圓、年利潤率 1.6 億日圓的業務。

Claude Code 不是一個讓你賺進百萬的神奇工具。

然而，對於那些擁有正確客戶、正確產品和正確銷售能力的人來說，它會變成 將一個人的判斷力放大到公司規模的裝置。