一個人工作，最缺的是第二雙眼睛，有了 AI 之後還是缺
一個人工作最常碰到的狀況是，事情想到一半沒有人可以問「你覺得呢」。以前在公司，一個提案寫完會有同事看一眼，一個決定下了會有人問你為什麼，現在這些位子都是空的。
有了 AI 之後好一點，至少隨時有人接話。但用久了我開始擔心，只有一個 AI 跟我聊，兩方都有的盲點，誰來提點？它順著我的思路一路想下去，我看它講得很有道理，其實我們兩個是同一條路走到黑。於是我開始在想，如果還有第三方幫我把關、一同激盪，該有多好。
今年五、六月開始，看到很多人推 Codex，我本來的主力是 Claude Code，想說這兩個都很厲害，能不能讓它們互相協作，而不是二選一。剛好那陣子看到一個分享 AI Coding 的 YT 影片，他講的痛點就是我的痛點，一個人寫程式，沒有人幫你 review，所以他讓 Claude 跟 Codex 自動互審。我看完就開始把他的做法改成適合我自己的版本。
現在我有小一跟小二，三種固定玩法
我把 Claude Code 叫小一，Codex 叫小二。它們共用同一份規則檔跟同一套工作方法，所以它們是同一個特助，只是 AI 模型不同。名字分開是為了我喊得出來，「你去找小二討論」這句話才有辦法下。
討論議題或做完分析，下一句「找小二討論」就多一雙眼睛
平常跟小一討論一個題目，或做完一份分析，想要有第三方意見時，我就下 debate 指令，叫另一個加入。像一號星球網站要用 Next.js 還是手寫單頁，我先拿兩個網站挑戰小一，再叫小二進來；退貨中心的資料夾要開工前整理還是做完再整理，我說「你找小二討論，給我原因」；連前幾天 Google 授權每週過期，我受不了了也是一句「你跟小二討論，一定都要我每週去授權嗎」。
整個過程我不用離開原本的對話視窗，不用把內容複製到另一個 App，拿到回覆再貼回來，可以在同一個視窗裡叫小二進來，兩方討論完直接給我結論，主持的那個先講自己的看法，把對方拉進來挑戰，最後整合成一份結論給我，哪裡有共識、哪裡還吵不完、最後建議方案為何。
終於我告別來回複製貼上的麻煩！
用量快到上限，寫一份專案交接文件，換另一個接著做
第二種是當使用的 AI 平台用量快到上限，以前只能等額度回來，或換一個 AI 平台從頭把背景講一遍。現在我會說「你把我們討論過程做個結論，放進交接資料夾」，然後開另一個 AI 平台，直接叫它讀交接文件後繼續工作，因為 skill 跟專案規則兩邊都是同一份，設定不會跑掉，交接文件只要把進度跟已經定案的事寫清楚，另一個接起來就很順，工作不會因為額度用完就斷在那裡。
像銷售分析跟退貨分析的營收口徑要統一，我叫小一把結論寫份交接紀錄，再交給小二討論；LINE 綁定登入的流程判斷，我先跟小二談完，它存一份「交小一」的交接檔，我再回來跟小一定案。
有時候來不及寫交接，直接換過去也還行，它看 memory 多少抓得到上下文，我在外面用手機接小二的時候就這樣，「我之前都跟小一討論，現在換你，跟得上嗎」，它就接了。
專案規則直接寫進工作流，spec 跟 code 一定要另一方 review
第三種是把協作規則直接寫進專案的工作流，讓它自動 run，不靠我每次記得喊。現在做自動化平台系統，spec 寫完它會自己去找另一方複審，code 寫完也會自己去找另一方看過才回報完成。一開始我還要盯「你有找小二 review 過嗎」，規則綁進去之後我不用再提醒，只看「你們討論幾輪了、改幾輪了」，改的內容是它們的事。
兩個 AI 都懂我，指令跟資料夾設好，剩下的就不太會出問題
這三種玩法能跑起來，前提只有一個，兩個 AI 都要懂我。所以全域規則跟相關的 skill，我讓兩邊共用，我的工作方法、做事遵循的原則，兩個都要知道，大家都在同一個水平上，溝通才不會有斷層，尤其交接時另一方才能無痛接軌。這一套設好，剩下的就是把額外的指令跟資料夾也規劃好。
設好一個指令，讓另一方隨叫隨到
找另一方討論這件事，其實只要設定好指令就可以了。我在共用的 skill 資料夾裡放了兩份 SOP，小一叫小二一份，小二叫小一一份，我說「你去問小一」或「請小二加入討論」就會觸發。SOP 裡寫死了幾件事：主持的那個先把問題、專案路徑、已經確認的限制跟自己的初步判斷整理成一份簡報再叫人，被叫進來的只分析、不能改檔案也不能再去叫別的 AI，最後由主持的那個整合結論給我。
被叫進來的那一個是乾淨的分身，只知道簡報裡講的事，所以簡報寫得好不好決定意見有沒有用。同一題要追問的話就接續同一段對話，但接的是那次回傳的確切 ID，不接「最近一次」，第二輪還要驗證 ID 跟第一輪一樣。之前用「接最近一次」的方式，我同時開著好幾個視窗，它會接到別條線去而且不報錯，這是踩過才改的。
專案規則寫好，交接文件的資料夾兩邊都知道
交接要順，專案規則得先寫好，而且要讓兩邊都知道交接文件放在哪個資料夾。我的交接文件格式很固定：一句話現況、已定案不需重新討論的事項、接手的人下一步做什麼，這樣接手的那個不會把已經吵完的事再吵一遍。
memory 兩邊各自管，不做同步，因為對話裡的暫時判斷互相灌進去只會越來越亂。確認後的共同原則放規則檔，可重複的方法放 skill，專案決策放專案文件跟交接檔，這三層分清楚，換哪個 AI 平台接手都找得到該讀的東西。來不及寫交接的時候靠 memory 撐，但正式的專案決策我還是會逼它寫進交接檔，memory 是它自己整理的快照，不是我拍板的東西。
專案協作規則：看了一支影片之後，改成自己的版本
第三種玩法的骨架是從 Gary 那支〈AI 寫的 code 一堆 bug？讓 Claude 跟 Codex 自動互審〉來的，我看了影片，也訂閱了他的文章，然後把流程改成適合自己的版本。
我的版本是這樣跑的：
- 先寫 spec，再寫 code。 只要任何會影響流程、金額、資料或部署的東西，都先有一份 spec，不直接開工。spec 寫的時候先把內容分成已驗證的事實、合理的推論、只有我能拍板的決策，決策問完我才讓它寫檔。
- spec 一寫完，另一方來反方審查。 審的那個只准挑毛病，不准改檔，專門找矛盾、缺漏跟沒查證就寫成事實的地方。回饋改完不能只改被點名的段落，還要掃一次其他段落有沒有被連動改壞。
- 最多兩輪。 第一輪找大洞，修完第二輪驗收，看大洞補好了沒、有沒有新的大洞，然後就停。第二輪如果還是發現很高的風險，我們才討論要不要再多開一輪，因為我不想變成為了 review 而 review。
- 要不要再改，看會不會擋上線。 review 這件事永遠挑得出新東西，你叫它找問題它一定找得到，所以停的條件不是兩邊沒意見了，是剩下的問題會不會讓金額算錯，會不會把資料寫壞，會不會讓流程卡住，會不會在正式站炸掉，會不會是我每天都踩到的東西。五題都不會就不擋，進驗收。
- 開工前宣告依據哪一版 spec，code 寫完照同一套再來一次。 開工前先講清楚這次是照哪個版本的 spec 做，做完另一方 review code，一樣最多兩輪、一樣五題判斷，過了才進測試站驗收。
這整套規則寫在專案的工作流裡，所以它們自己會跑，我看到的只有「第幾輪、改了什麼、還有沒有擋上線的問題」。
我不確定它們能幫我突破多少盲點，但每次多一個人進來，就多一些新觀點
小一跟小二背後是不同公司的模型，但規則跟 skill 都是我給的同一套，它們讀的是同一份工作方法，講起話來也都像我。所以我其實不知道，這樣子到底可以突破多少盲點，也許有些盲點是我自己帶進規則裡的，換幾個入口都看不到。
但至少實際這樣 run 下來，每次請另外一方加入交流，都會有新的觀點跟想法出來，這對現在的我確實有幫助。一個人工作，我沒辦法變出一個同事，但我可以在想問「你覺得呢」的時候，真的有人接話。