從房東代管業者，到用 5 個 AI 搭出一套工作系統
我不是工程師，也沒有 AI 技術背景。
我的本業其實很傳統：
我是做租屋代管的，一人公司，平常處理的是房東、房客、租約、修繕、糾紛、判決資料這些事情。
我是做租屋代管的，一人公司，平常處理的是房東、房客、租約、修繕、糾紛、判決資料這些事情。
但我有一個毛病：
做事做到一半，就會想把它變成流程。
流程跑久了，就會想把它變成系統。
做事做到一半，就會想把它變成流程。
流程跑久了，就會想把它變成系統。
所以我一開始只是請 AI 幫我寫文章。
後來請 AI 幫我整理租賃資料。
再後來，我開始讓 AI 協助我處理判決資料、合約條款、內容產製、資料跑批。
後來請 AI 幫我整理租賃資料。
再後來，我開始讓 AI 協助我處理判決資料、合約條款、內容產製、資料跑批。
一路土炮下來，我才發現一件事：
AI 不是越多越強。
沒有分工，越多只是越亂。
沒有分工，越多只是越亂。
這不是什麼高深技術分享。
這只是我土炮了大半年，踩了一堆坑之後，慢慢摸出來的一套多 AI 協作方式。
這只是我土炮了大半年，踩了一堆坑之後，慢慢摸出來的一套多 AI 協作方式。
我現在怎麼分工？
目前我的工作流，大概是這樣：
我自己
負責提出方向、判斷取捨、最後拍板。
負責提出方向、判斷取捨、最後拍板。
ChatGPT
比較像策略顧問，幫我看大方向、挑盲點、拆風險。
比較像策略顧問，幫我看大方向、挑盲點、拆風險。
Claude Chat
負責長文推理、法律邏輯、內容深度分析。
負責長文推理、法律邏輯、內容深度分析。
Codex
負責把想法制度化，整理成 SOP、工單、schema、驗收標準。
負責把想法制度化，整理成 SOP、工單、schema、驗收標準。
Claude Code
負責真正執行，包含工具操作、程式修改、跑批、commit。
負責真正執行，包含工具操作、程式修改、跑批、commit。
這裡有一個我覺得很重要的原則：
顧問只給建議，不直接動資料。
執行者才進 repo，不讓每個 AI 都下場改檔案。
執行者才進 repo，不讓每個 AI 都下場改檔案。
不然每個 AI 都覺得自己可以幫你「順手改一下」，最後就是災難。
我的完整流程
現在我的流程大概是：
我提出方向
↓
ChatGPT / Claude Chat 給建議
↓
我拍板決策
↓
Codex 整理成 SOP、工單、schema、驗收規則
↓
Claude Code 依工單執行、跑批、commit
↓
Codex 檢查結果，修正規則，建立下一輪工單
↓
重要結論回寫 Notion
↓
長期知識沉澱進 Obsidian / 判決庫 / wiki
↓
ChatGPT / Claude Chat 給建議
↓
我拍板決策
↓
Codex 整理成 SOP、工單、schema、驗收規則
↓
Claude Code 依工單執行、跑批、commit
↓
Codex 檢查結果，修正規則，建立下一輪工單
↓
重要結論回寫 Notion
↓
長期知識沉澱進 Obsidian / 判決庫 / wiki
這樣做之後，我最大的改變不是「AI 變聰明」。
而是我不用每次都重新解釋整個專案。
每個 AI 知道自己該做什麼、不該做什麼，工作就會穩很多。
我踩過最大的坑：兩個 AI 同時改同一個檔案
這個坑我真的踩過。
Codex 在調整腳本邏輯，Claude Code 也在改同一個資料夾。
最後變成：
誰改了什麼？
哪個版本才是對的？
為什麼剛剛修好的東西又壞了？
哪個版本才是對的？
為什麼剛剛修好的東西又壞了？
一開始我以為是 AI 不夠聰明。
後來才發現，問題不是 AI。
問題是我沒有設計「協作規則」。
問題是我沒有設計「協作規則」。
所以我後來做了一個很土炮，但很有用的方法：
在 repo 裡設兩個 inbox。
inbox-claude-code/ ← Codex 寫，Claude Code 讀inbox-codex/ ← Claude Code 寫，Codex 讀Codex 不直接叫 Claude Code。
Claude Code 也不直接叫 Codex。
Claude Code 也不直接叫 Codex。
它們透過 inbox 留任務、交接結果、回報問題。
任何一方要動共用檔案前，先留一行鎖定聲明：
[LOCK] 我要修改 xxx.py — Claude Code 09:30另一方看到就不要碰。
這規則很笨，但很有效。
因為 AI 最可怕的不是不會做，
而是它很熱心地「默默幫你做掉」，然後你完全不知道它動了哪裡。
而是它很熱心地「默默幫你做掉」，然後你完全不知道它動了哪裡。
另一個心得：不是所有專案都適合多 AI 平行做
我後來才發現，多 AI 協作不能一招打天下。
像資料工程、判決資料整理、批次處理這種專案，
就很適合雙軌並行。
就很適合雙軌並行。
因為可以切地盤：
一個 AI 負責規則。
一個 AI 負責工具。
一個 AI 負責驗收。
一個 AI 負責工具。
一個 AI 負責驗收。
但 App 開發就不一樣。
像 Flutter、前端畫面、路由、狀態管理這種東西，
如果兩個 AI 同時各改一半，很容易整個壞掉。
如果兩個 AI 同時各改一半，很容易整個壞掉。
這類專案必須有一個主腦。
其他 AI 可以提建議、抓 bug、寫測試，
但不能大家一起衝進去改。
但不能大家一起衝進去改。
我現在的理解是：
資料工程可以多 AI 分工。
產品開發要單主腦統整。
產品開發要單主腦統整。
這點對我來說很關鍵。
Session 紀律也很重要
AI 最大的問題之一，就是每次新對話都像重開機。
你昨天講過的事，今天它不一定知道。
你前一輪定好的規則，下一輪可能又要重講一次。
你前一輪定好的規則，下一輪可能又要重講一次。
所以我後來訂了一個規則：
Claude Code 每次開工，先讀自己的 inbox。
Claude Code 每次收尾，必須把結果寫回 Codex 的 inbox。
遇到需要我判斷的事情，就標：
Claude Code 每次收尾，必須把結果寫回 Codex 的 inbox。
遇到需要我判斷的事情，就標：
needs_dege_decision這樣 AI 不會自己亂拍板。
我也不用每次都重新交代一整包背景。
很多時候我只要說一句：
「先讀你的 inbox。」
它就知道接下來要做什麼。
最後的體會
這半年我最大的感覺是：
多 AI 協作，不是叫更多 AI 來做事。
而是先設計清楚誰負責什麼、誰不能做什麼。
而是先設計清楚誰負責什麼、誰不能做什麼。
沒有邊界，五個 AI 只是把混亂放大五倍。
有了邊界，AI 才會真的變成一個工作系統。
我現在也還在調整這套流程，還稱不上成熟。
但至少已經從「一直重講、一直救火」變成「可以接力、可以驗收、可以累積」。
但至少已經從「一直重講、一直救火」變成「可以接力、可以驗收、可以累積」。
如果你也在摸索多 AI 工作流，歡迎交流。
我也很想知道大家怎麼避免 AI 之間互相踩腳。
不要叫我開課! 租賃管理我可以！
但談ＡＩ運用～我沒那麼本事!
有機會多交流，交個朋友就好!
我也很想知道大家怎麼避免 AI 之間互相踩腳。
不要叫我開課! 租賃管理我可以！
但談ＡＩ運用～我沒那麼本事!
有機會多交流，交個朋友就好!
