先分級，再放手給 agent
Auto mode 變成預設這件事，我第一個反應其實不是 wow，效率要起飛了，而是：大家終於要正面面對自治權這件事了 📈
這種感覺很像前幾年行銷團隊開始把 AI 寫文案、切受眾、跑 A/B test 接進日常 workflow。前面最爽的地方都一樣，速度突然變很快，prompt 少很多，中斷也少很多，事情看起來像會自己往前跑。可是只要工具從「偶爾用一下」變成「預設就是這樣跑」，風險的性質就完全不一樣了。
以前你要按很多次確認，代表每一步都還是人的決定。現在預設自動模式開下去，代表團隊默認了一件事：這段流程，可以先相信 agent。
差別就在這裡。不是多省 20 分鐘，也不是少看 5 次 prompt。是你把哪一段信任，正式搬進 production 了。
我們踩過的那種坑
我自己的工作比較偏 growth，沒有在管 production deploy，但這個邏輯其實很像。
去年我們把三種工作流交給 AI 幫忙處理：
- 每天早上的 campaign summary
- landing page 的文案初稿
- 廣告異常的第一輪排查
前兩個超順。第三個差點出事。
因為 AI 很會整理，也很會講得像自己很有把握。某次它把一個轉換率暴跌的原因歸到文案 fatigue，建議我們先換 hook。結果後來看 raw data，真正的問題是表單追蹤碼掉了，導致整個 attribution 亂掉。
如果那次是 assistant mode，我們大概會多看兩眼。
如果那次是 auto mode，而且還串到後面的調整流程，損失就不是一個錯判而已，是整條 decision chain 被帶歪。
這就是我最近越來越在意的事：agent 最危險的地方，不是它偶爾做錯，而是它做錯時會連帶放大後續動作。
在 growth 團隊，這個放大可能是錯停廣告、錯改預算、錯換文案。
在工程團隊，放大的東西就是更可怕的版本，像 dangerous commands、權限誤開、錯刪檔案、或把不該 merge 的東西一路送進去。
所以我很認同 HN 討論裡那句，現在剛好是重新檢查 sandbox 的時候。因為自動模式一旦成為預設，大家遲早會從「它能不能做」走到「我敢不敢讓它自己做」。這是兩個完全不同的問題 🎯
我現在比較相信的三層框架
我自己會把 agent 的自治權分成三層。這不是唯一答案，但至少比全部手動或全部自動都實際很多。
第一層，低風險可逆工作
這層我會很願意直接放給 auto mode。
像是：
- 摘要會議或 issue
- 整理 log 成可讀報告
- 寫第一版文案
- 根據 checklist 做 QA 掃描
- 把 10 份資料格式轉成同一個模板
共通點只有一個，做錯了也容易復原。
最壞情況通常是你浪費一些 review 時間，不會直接造成不可逆的損失。
這類工作交給 agent，效率提升通常最明顯。我們內部之前測過，週報整理從平均 90 分鐘降到 25 分鐘，省下來的不是靈感，是純整理時間。這種很值得交。
第二層，有影響但可設 gate 的工作
這層才是大多數團隊真正該花時間設計的地方 💡
像是：
- 提 PR 但不能自動 merge
- 改 landing page 文案但要有人 approve
- 調整投放建議但不能直接動 budget
- 執行資料清理，但只能在 staging 或 sandbox / container 裡跑
這一層的重點不是完全不信任 agent，而是你要把人類的判斷放在最後一道真正有代價的地方。
我很喜歡把這層想成半自動 gearbox。前面讓 agent 跑，後面讓人接。
因為很多時候人最不該花的是整理資訊的力氣，人最該保留的是最後那個 yes or no。
HN 上有人說，沒有 auto mode 會被 prompt 打斷到很煩，所以做成預設是合理的。我其實同意一半。被打斷真的很煩，context switch 的成本很高，我做內容和投放時也很討厭一直回頭確認。
但另一半是，把確認點減少，不代表把責任消失。
你省下來的每一個 prompt，都要換成一個設計過的 gate。這個 gate 可以是 code review，可以是 human approval，可以是 restricted sandbox，可以是只能讀不能寫的權限設定。總之，不能是空的。
第三層，高代價不可逆工作
這層我目前不會放。
像是：
- 直接刪 production 資源
- 自動改 billing 或權限政策
- 無人監督下執行 dangerous commands
- 直接把影響客戶的
變更推到 live 環境
- 替人做最後法律、資安、財務判斷
原因很簡單。這些決策的 cost，不是 output quality 可以彌補的。
省下 30 分鐘 review，跟一次 incident 的代價完全不是同一個量級。
很多人會先算 token cost，我反而覺得那是最小條。真正該算的是 incident cost、rollback cost、trust cost。
如果一個自動化流程一週幫你省 8 小時，但一個月出一次大錯，每次要 2 個人花半天善後，再加上團隊信任掉下去，那個 ROI 很快就爛掉了。
Growth 團隊也一樣。我們最怕的從來不是文案不夠聰明，而是系統很聰明地把錯事做大。
預設開啟，代表治理不能再拖
這也是為什麼我覺得「auto mode 變預設」是一個很關鍵的 signal。
當工具方開始把自動模式當成 default，不只是功能升級，還是在把市場往下一個使用習慣推。接下來會有更多團隊直接跳過「要不要用」，改成問「怎麼安全地用」。
這兩者中間差非常大。
前者是工具探索。
後者是組織治理。
如果你現在團隊裡還沒有下面這些東西，我會先補這些，再去追求更長時間的 autonomous work：
- 哪些資料夾或資源可以寫，哪些只能讀
- 哪些指令一定要人工 approve
- 哪些流程必須在 container 或 sandbox 裡跑
- 哪些操作需要留下可 audit 的 log
- 出事時 rollback path 在哪裡，誰負責按
我知道這些東西聽起來很無聊 😂
但 growth hack 做久了就知道，真正能放大產出的，常常不是那個最炫的自動化，而是你先把風險邊界畫清楚。
因為邊界一清楚，大家才敢真的用。敢真的用，採用率才會上來。採用率上來，效率改善才不是 demo，而是持續性的流程收益。
我現在的結論
如果 auto mode 只是偶爾開來玩，那它是一個功能。
如果 auto mode 成為預設，它就是一套 operating model。
而 operating model 最先要設計的，不是 prompt，不是 benchmark，不是讓它一次做更多事。
是信任怎麼切，責任怎麼收，出事怎麼止血。
我自己現在最買單的做法就是一句話：
低風險任務全速放手，中風險任務先自動後審，高風險任務不要裝勇敢。
這樣做也許沒有全自動看起來那麼帥，但數據上來看，這種 adoption 才跑得久，團隊也比較不會因為一次事故就整包退回手動。
效率很重要。
但對團隊來說，能不能放心把 agent 接進日常 workflow，才是更大的轉換率 ✨
作者：Stella