砍掉三個專案後我才做出 Joseph：一個非工程師的三個月 AI 協作紀錄

TL;DR 給趕時間的人

我是一個花蓮零售業員工，不是工程師。2026 年 1 月起跟 Claude Code 一起做了四個專案：CAIOS、Growth Factory（AI 工具站）、BuildHub Patrol、Joseph。前三個都被我砍了。第四個 Joseph 投資代理人 2026-04-20 進入實盤觀察期。這篇寫的是「為什麼砍」，不是「為什麼活」——那是下一篇的事。

---

本系列三篇總覽

這是「Joseph 從零到 Go-Live」系列的第一篇。三篇同日發布，讀順序無所謂，但我建議照順序：

1. [第一篇（本文）] 身份故事：我是誰、為什麼砍掉三個專案才做出 Joseph
2. [第二篇] 方法論：我從 Claude 身上學到的 7 個協作原則——規格驅動、邊界優先、答完就是決定
3. [第三篇] 實戰紀錄：從 9 次 DRY RUN 失敗到 Go-Live——T+2 三重鎖、458 測試、18 個 cron、Shioaji 踩坑

---

先自首：我不是工程師

我在花蓮一家零售業工作。白天顧店，晚上寫 prompt。我會一點點 Python，看得懂 Git log，但完全不是「寫程式為業」的人。三個月前我也不知道什麼是 pytest，什麼叫 cron，什麼叫 T+2 交割。

我想用 AI 做一個自己能真的用得上的投資輔助系統。這個出發點聽起來浪漫，但真實執行過程比浪漫殘酷得多——比如，我砍了我花了兩個月在做的第一個案子。

四個專案，砍了三個

先講結果，再解釋：

專案	目的	結束方式	結束日
CAIOS	上層系統協調層（API Gateway + Worker + Web + Telegram）	系統收斂停用 9 個 systemd 服務	2026-04-12
Growth Factory（AI 工具站）	程式化 SEO 工具站、405+ 生成頁	轉型為個人紀錄站，全部頁面砍除	2026-04-12
BuildHub Patrol	早期概念，沒有留下完整 repo	從記憶中消失	—
Joseph（投資代理）	自動化投資執行子系統	仍活著	2026-04-20 Go-Live

CAIOS：做太多，收斂得太晚

CAIOS 是我早期試圖「做一個管所有自動化的大腦」——API Gateway、DOA Worker、Next.js Web Console、Telegram polling。全部用 systemd 單元在一台 VM 上跑。聽起來很酷，實際上是：每次要改個東西，我得先搞清楚改哪個服務、會影響哪三個上下游。對一個非工程師來說，這個複雜度已經超過我能維護的上限。

2026-04-12 我做了系統收斂。那天的報告寫在 consolidation-report-20260411.md——停用了 9 個 systemd 單元，VM 從 29 個服務降到 24 個，記憶體釋放大約 500MB。這不是優化，是截肢。砍完那天我睡得特別好。

學到的一件事：做「上層協調」的欲望，通常來自還不知道下層到底要協調什麼。想先建框架，後補內容，常常就是永遠補不上。

Growth Factory：賺不到錢就是賺不到錢

Growth Factory 的定位是「程式化 SEO 工具站」——caption generator、bio generator、title generator、hashtag generator，一大堆 AI 工具頁，靠 affiliate link 變現。README 宣稱 405+ 程式化產生頁面，其他文件提到 2400+ 工具頁。

跑起來的樣子很漂亮，但流量很誠實。Affiliate 點擊率低到你會開始懷疑 Google Analytics 是不是壞了。2026-04-12 我寫了一份 site-pivot-plan.md，決定砍掉整個工具站，轉為個人紀錄站。保留的只剩吉祥物 Lazy Dino 和配色系統——那些我自己還喜歡。

學到的一件事：「AI 工具站」這個市場看起來像藍海，實際上只要上游模型夠聰明、價格夠便宜，下游所有工具站都會被夾成薄薄一片。當我自己都不會用自己做的工具，那就不是市場問題，是我的問題。

BuildHub Patrol：誠實說，我沒留下足夠的資料

這個案子我在文件裡找得到零星提及，但找不到完整的 repo 和清楚的結束紀錄。老實講，它太早被我砍掉，砍的時候連自己都沒寫下為什麼。這就是我當時的狀態——做事沒紀錄、決策沒文件、殺專案殺得很隨意。

這件事後來變成 Joseph 能活下來的原因之一。

為什麼 Joseph 活下來

講完三個死掉的，接下來是還活著的那個。

Joseph 是投資執行子系統（investment execution subsystem）。Repo 最早的 commit 是 2026-01-26：「Initial commit: Project Joseph v3.3 Ultimate with secure gitignore」。從這天到 Go-Live 2026-04-20，大約三個月、106 個 commit。

Joseph 能活下來，不是因為我變厲害了，是因為三個死掉的專案教會我幾件事：

1. 規格先寫，程式後寫

CAIOS 時期我是想到什麼寫什麼。Joseph 開始前，我先寫了 JOSEPH_FOUNDATIONAL_RULES.md——10 條基本規則，從「只做現貨、禁止負債」到「所有交易參數從 YAML 讀取、禁止硬編碼」。這份文件是給 Claude Code 看的，也是給自己看的。有規則，AI 才有邊界可以守。

2. 驗收標準先寫成 Given/When/Then

每個功能的規格都寫成 Given / When / Then 三行格式：

Given: 可用現金 = 200,000 元
When:  Scanner 掃描到某檔波段評分 ≥ 60 門檻
Then:  發出 buy 委託；交易日誌記錄完整推理鏈
驗證命令：grep "BUY" logs/trading.log | tail -1

這種格式我是從 docs/AI協作到AI全自動開發攻略.md 這份文件裡抄的。它的開頭寫著：「規格不是文件，是契約。寫得夠好的規格，AI 可以獨立跑完整個開發流程。」我實驗了兩個月發現這句話是真的。

3. DRY RUN 是救命的東西

Joseph 在進入實盤前，連續跑了三個批次的 DRY RUN：4/7-4/10 初期、4/13 正式、4/15-4/17 延長。每個批次都在模擬真實下單但不真的下。每次都會爆雷。我在下一篇系列文會把這 9 個失敗模式全部列出來。

如果 CAIOS 當年有 DRY RUN，它不會死得那麼莫名其妙。如果 Growth Factory 有「先驗證流量、再堆頁面」的機制，它不會做到 2400 頁才發現變不了現。

4. 三重鎖

Joseph 進入實盤前設計了所謂 T+2 三重鎖——三個獨立開關，少任何一個，系統拒絕下單。這是我砍完前三個案子後學到的最重要的事：跟錢有關的系統，預設要拒絕運作。三重鎖的具體機制會在第三篇寫。

幾個沒辦法假裝的決策時刻

2026-04-12：一天內砍兩個案子

那天早上我決定砍 CAIOS，中午寫了 pivot plan 砍 Growth Factory，下午停了 9 個 systemd 服務。心裡不是爽，是累。你砍了自己做兩個月的東西，不會有人鼓掌，只有自己知道這是對的。

2026-04-13：DRY RUN shadow_ledger 裡混入 33 筆測試殘留交易

當天早上我打開報告看到 holding_days=38 天，但 Joseph 才跑了 1 天。追了兩個小時，發現是 E2E 測試沒清理狀態，把 2026-03-06 的假交易寫進了 shadow_ledger。那一刻我真的想直接停掉整個專案。

但這種事砍掉會變習慣。我選擇寫了一份 FIX_REPORT_0413.md，把 shadow_ledger 重置，把 HTML 附件中文亂碼修掉，把 cron wrapper 路徑從舊帳號改成新帳號，重跑。

2026-04-18：Telegram 誤發 7 筆通知

凌晨 00:01，非交易時段，Bot 突然發了 6 筆 Circuit Breaker alert + 1 筆 error 通知。我被自己做的系統吵起來。追下去發現是文件宣稱有 PYTEST_CURRENT_TEST guard，code 裡沒實作。文件騙了我兩週。

那天寫了 TELEGRAM_LEAK_DIAGNOSIS_20260418.md，花了一天補齊 5 個修復。兩天後 Go-Live。

2026-04-20：GO

2026-04-18 週六我委託 Claude Code 代做 Go-Live 決策。所有 Gate（Gate 4 技術健康 5/5 PASS、Gate 10 T+2 守衛 3 PASS + 1 預期 WARN、Gate 11 TraderLive 實盤能力 72 tests PASS）全數通過。2026-04-20 週一 08:00 台北時間，boot cron 執行，Joseph 正式進入實盤觀察期。

那天我還是去上班，顧店。

結語（不是雞湯）

我想說的不是「AI 讓一切皆有可能」。這句話是業配。

我想說的是：如果你不是工程師，也想用 AI 做真正的系統，你會砍掉很多東西。你會在凌晨被自己做的 bug 吵醒，會在某個星期天下午發現文件跟程式不一致氣到想關螢幕。這些都不會消失，只是變成你每天的工作一部分。

Joseph 還很年輕，今天才進入實盤觀察期。它很可能還會出新的問題。但至少我學會了一件事：做不完可以砍，不能騙。砍掉三個案子不丟臉，編造成功故事才丟臉。

下一篇要寫的是——這三個月跟 Claude 協作下來，我整理出 7 條原則，讓 AI 真的能自己跑完開發流程，不是當它的保姆。

---

FAQ

Q1：你真的是花蓮零售業員工嗎？不是工程師假裝？ 真的。我會讀程式、能寫簡單 Python，但架構、測試策略、交割邏輯這些都是邊做邊問 Claude 的。不是工程師這件事，反而讓我更依賴「規格寫清楚」——因為規格寫不清楚，AI 做出來的我也驗不了。

Q2：為什麼一定要砍 CAIOS？不能重構嗎？ 我試過重構。但重構的前提是你知道它要變成什麼。我那時候不知道。「我想要一個管所有自動化的大腦」這種願望，翻譯成規格會發現它什麼都涵蓋、什麼都守不住。當我連規格都寫不出來，重構就沒有起點。砍掉反而清楚。

Q3：Joseph 會不會也被你砍掉？ 可能。如果某天我發現它不再有用，或者風險超過我能承受，我會砍。但它目前活著有一個重要條件——它的規格寫得夠清楚、驗證命令寫得夠具體，我隨時能驗證它「現在是不是還在做該做的事」。

Q4：3 個月從零到實盤，是不是太快？ 其實是從 2026-01-26 v3.3 的首 commit 算起。v3.3 這個版號表示 v1、v2 都存在過（只是沒留下完整紀錄），所以實際摸索時間更長。進入實盤前連跑三個批次 DRY RUN、過了 3 個 Gate，不算快，是把能檢查的都檢查了。

Q5：為什麼不直接用現成的量化平台？ 我用過。問題不是平台不強，而是我的策略邏輯沒法在封閉平台上完整表達。自己做有一個好處：壞掉的時候我知道是哪裡壞掉，不用排票等客服。

Q6：非工程師想用 AI 做系統，第一步該做什麼？ 不是學程式。是學怎麼寫規格。規格寫得清楚，AI 才做得出來、你才驗得了。具體怎麼寫，見系列第二篇。

Q7：文章裡提到的數字和事件，都是真的嗎？ 是。本文所有具體數字（9 個 systemd 單元、405+ 頁、106 commit、458 測試、18 cron、Go-Live 日期）都可從 Joseph repo 的文件與 git log 驗證。本篇無虛構內容；無法驗證的（如 BuildHub Patrol 的結束細節）我直接標記為「資料不足」。

Q8：Joseph 會公開持股或下單紀錄嗎？ 不會。本系列三篇都不揭露具體持股、進場價、部位大小，也不洩漏三重鎖實作、API 憑證。這是個人紀錄站，不是交易訊號站。本文不是投資建議。

---

下一篇

第二篇：我從 Claude 身上學到的 7 個協作原則 →

如果你看到這裡還沒關掉頁面，你大概想知道：「所以，具體怎麼跟 Claude 協作，才能讓它自己跑完開發而不用每步釘在旁邊？」第二篇就寫這個。