Journal
AI 協作系列｜第 1 篇：我在協作裡扮演什麼角色
承接 第 0 篇的脈絡。那天讓我重新想清楚的第一件事，是我在整個協作流程裡，到底在哪裡。
我的工作流程，說出口的版本
把我一般的開發流程說清楚大概是這樣的：
收到任務。了解需求，想清楚系統要怎麼跑。列出規格和驗收條件，交給 Agent 確認方向。Agent 開始實作，我在旁邊等——有時候盯著看，有時候同時處理別的事。跑完之後，我把結果跑起來，看有沒有符合預期。有問題就回去讓 Agent 修。
這個流程其實沒什麼問題，大方向是對的。Explore → Spec → Implement → Verify，這是現在主流的 agentic 開發方式，不是我亂發明的。
問題是細節。
但有幾件事我沒說清楚
我「了解需求」的時候，Agent 在哪裡？
大部分時候，我先想一輪再交給 Agent。但「想一輪」的深度不一樣——熟悉的領域，我自己有方向，跟 Agent 確認一下就走；不熟悉的領域，我把需求丟給 Agent，讓它 survey 做法，然後透過來回討論把方向收斂。
後者其實是 Agent 在幫我想，我在選它給我的方案。
我「驗收結果」的時候，看的是什麼？
大多數是跑起來試，看功能有沒有對。偶爾讀一下 Agent 的說明。讀程式碼的頻率其實不高——因為要花很大的時間，如果功能跑起來是對的，我會告訴自己「有問題再說」。
我認為這個想法沒有什麼問題，但它讓我把很多判斷交給了「跑起來沒壞」或是「看起來蠻正常」的這種「感覺」做標準。
「Agent 怎麼做，我就怎麼接受」的情況，有多常？
比我意識到的要多。
說出口才發現的問題
把上面這些說完，我才意識到：這件事取決於我對那個領域的熟悉程度。
熟悉的地方，我確實有判斷。我做過類似的事，知道哪裡容易出問題，所以 Agent 提方案的時候，我能評估對不對。比如資料模型的設計——如果東西跑起來感覺彆扭，我能說出「公費池不應該是一個人，它的語意不對」，這是真正的判斷，不是接收。
不熟悉的地方就不一樣了。我對那個領域沒有足夠的背景，Agent 提了三個方案，我選了其中一個——但我不確定我選的是否真的對，還是我只是選了聽起來最合理的那個。這種情況下，「我在選」更像是一個形式，背後是 Agent 在決定。
問題不是「我從來不做判斷」，而是：我不熟悉的領域和需求，比我意識到的要多。而那些地方，我傾向直接依賴 Agent 給的方向，而不是自己建立判斷。
我以為自己是在「指揮 AI 做工程」，但在很多我沒有紮實背景的地方，更像是在接收 AI 的工程成果，然後用「跑得起來」當作驗收標準。
開槓桿沒有錯，但要知道槓桿的代價
我沒有覺得這種工作方式完全錯誤。用 AI 協作讓我可以接下超出自己能力範圍的工作，這是真實的生產力，不是假的。
但開槓桿有代價，而且這個代價沒有那麼顯眼。
第一個代價：codebase 的掌握感在下降。 我越來越沒辦法清楚系統的某個部分是如何運作的，因為我沒有寫它，我只是接收了它。這件事好不好？我沒有一個確定的答案。讀程式碼要花時間，如果東西能跑，那個時間投資在哪裡比較划算？當我站在一個不太熟悉的系統上面的時候，那個「不清不楚」的感覺很真實，很不舒服（活該?）。
第二個代價：我學不深。 我觀察 Agent 怎麼做，從旁邊看一點，但如果很久沒遇到同樣的情境，就忘了。我記住的是「這個情況可以這樣解決」，而不是「為什麼這樣解決」。後者才是能在新情境裡被用到的知識。
第三個代價，也是最讓我在意的：我不熟悉的領域，判斷力很難累積。 熟悉的地方，我做決策、觀察後果、下次知道了——這個迴路是有效的。但不熟悉的地方，我選了 Agent 給的方案，不確定選的對不對，結果跑起來能用，但我也不知道為什麼能用。那個判斷力的迴路是斷的。這個問題我沒有好答案，但我不想假裝它不存在。
用 AI 擴大產出，和用 AI 讓自己變強，是兩件不一樣的事。兩件都可以是目標，但不會自動同時發生。
Human-in-the-loop，但在哪裡
研究 agentic 開發的最新討論時，有一個詞反覆出現：Human-in-the-loop。
它的對立面叫 Human-on-the-loop。差別是：in-the-loop 是每個環節都需要人確認才繼續；on-the-loop 是人設定參數和邊界，Agent 自主跑，人在關鍵點介入。
我現在的模式比較接近 on-the-loop，這方向沒問題。現在的模型夠強，不需要每一步都等我確認，那樣只會讓整個流程變慢、讓 Agent 沒辦法發揮。
問題是「關鍵點」是哪些。
如果我的「關鍵點」只有「跑起來沒壞」，那我等於是在 on-the-loop，但 loop 的邊界太外面了。很多真正重要的判斷——這個 service 要不要拆、這個 API 設計合不合理、這個 pattern 適不適合這個規模——都在 loop 裡面，由 Agent 自己做了。
我想要的是：loop 的邊界往內移一點，讓架構選型、技術取捨這類判斷進到我的範圍。不是每個步驟都要我點頭，而是這類型的決策要停下來讓我表態。
決策點才是學習的地方
這個想法背後有一個我越來越確定的觀察：
真正能累積成能力的，是做了決策之後知道結果怎樣。 不是「觀察 Agent 選了什麼」，而是「我選了 A，後來發現 A 有這個問題，下次我知道了」。
如果 Agent 選 A，我接收了結果，那個「A 有這個問題」的知識沒有附著在我的判斷上，它只是一個觀察到的事實。
所以把判斷拉回來，不只是「我想有更多掌控感」，而是讓那些決策點真正成為我在這個領域累積判斷的機會。我不需要自己手刻程式碼，但我需要選 A 或 B，而不是等 Agent 選完之後看結果。
這件事被寫進規則了嗎？
答案是，現在被寫進去了。
原本的規則系統裡，有很多「Agent 要怎麼做事」的規範，但沒有明確說「在架構選擇點，Agent 要停下來讓使用者決定」。
現在加了這一條：多個可行方案的時候，在計畫階段列出來讓使用者選，而不是自己決定再執行。
這條規則能不能真正改變行為，還需要實際經過幾次使用才知道。但至少方向是清楚了。
本文是系列的第 1 篇。系列共五篇，從 第 0 篇 開始閱讀。