此为历史版本和 IPFS 入口查阅区，回到作品页
Ryan Vale
IPFS 指纹 这是什么

修正標題與清單排版

作品指纹

AI agent 不是幫你寫完程式的人，而是一個需要收工規則的工作區

Ryan Vale
·
·
AI agent 開始像一個會留下狀態的工作區，小團隊需要任務名、負責人、驗證證據與收工決策，才能讓每次 run 被接手、被驗收，也能被回退。

以前我們很容易把 coding agent 想成更聰明的 autocomplete。

它幫你補一段函式，解釋一段錯誤訊息，或把一個小 bug 修掉。這種用法裡，AI 比較像助手。你問，它答。你看一眼，覺得可以就用，不可以就丟掉。

但最近的方向已經不太一樣了。

Agent 開始有自己的 session、歷史紀錄、遠端執行、背景任務、工具呼叫、review surface，甚至可以在你關掉筆電之後繼續工作。它不只是回答問題，而是會把一段工作放進某個地方，讓它等待、重跑、同步、分支、留下檔案和結果。

這就不是助手而已了。這更像一個工作區。

而工作區最麻煩的地方，不是它會不會做事。是它做完之後，誰來收。

助手回答問題，工作區留下狀態

把「助手」和「工作區」分開看，很多問題會清楚一點。

助手回答問題時，輸出大多是一次性的。你問一段 code 怎麼寫，它給你一個版本。你可以複製，可以不用，也可以再問一次。錯了當然浪費時間，但通常不會在專案裡留下太多痕跡。

工作區不一樣。

工作區會有任務名稱，會改檔案，會跑測試，會保存歷史，會留下半成品，會等下一個人接手。它可能同時有好幾個 session 在跑。某個 session 修 UI，另一個 session 改資料層，還有一個在嘗試整理文件。表面上很有效率，實際上也更容易亂。

因為每一個還沒收掉的 session，都在專案裡留下某種未完成的承諾。

它也許真的改好了。也許只做了一半。也許測試有跑，但不是關鍵那一組。也許遇到阻礙後自己繞路，改出一個看起來能動、但團隊根本不想維護的方案。

如果沒有人明確收尾，這些狀態不會自己消失。

背景執行省時間，也會製造「差一點完成」

遠端 session 和背景執行很吸引人，尤其對小團隊。

你可以把一個重複性任務丟出去，去做別的事。你可以讓 agent 先改一版，稍後再看結果。你可以讓它在 sandbox 裡嘗試，失敗了再重跑。這些能力都很實用。

但它們也會製造一種新的堆積：差一點完成的工作。

這種工作最難處理。它不是完全失敗，所以你不會立刻刪掉。它也不是完全成功，所以你不敢 merge。它放在那裡，好像還有價值，但下一次要接手時，又要重新理解它到底做了什麼。

幾次之後，團隊會開始有一堆「晚點再看」的 agent run。

這其實和人類工作很像。差別是，人類同事通常會被要求開 ticket、寫 PR、留下測試結果、說清楚還缺什麼。Agent 如果也開始承擔類似的工作，就不能只靠一句「已完成」交差。

「已完成」不是一個狀態。它要有證據。

每一次 agent run 都該有收工清單

我覺得小團隊不需要一開始就做很重的 AI governance。

先做一張很短的收工清單就夠了。每一次 agent run 要結束前，至少回答這幾件事：

  • 這次任務叫什麼

  • 誰是負責人

  • 改了哪些檔案或資料

  • 驗證證據在哪裡

  • 哪些東西可以被 review

  • 這次結果要 merge、封存、重跑，還是刪掉

  • 如果結果有問題，怎麼 rollback

這張清單看起來很普通，普通到不像 AI 功能。但它會決定 agent 能不能真的進入工作流程。

沒有任務名稱，session 很快就會變成一串看不懂的歷史。沒有負責人，出問題時沒有人知道該問誰。沒有驗證證據，reviewer 只能重新跑一遍心智負擔。沒有 merge 或封存決策，半成品就會一直留著。

最糟的是沒有 rollback。

Agent 的價值在於它能快速試錯，但快速試錯的前提，是你能把錯的東西收回來。如果一個 run 會改很多地方，卻沒有清楚的回退方式，那它不是自動化，是把風險包成效率。

session history 的價值不是紀念，而是交接

很多工具開始強調 session history、multiple sessions side-by-side、auto-review、背景命令提示、sandbox retry。這些功能本身都很好，但我不會把它們只看成「方便回顧 AI 做了什麼」。

更重要的是交接。

下一個人打開這個 session 時，應該能很快判斷三件事：

第一，這個工作現在在哪裡。

第二，它已經產生了哪些可以檢查的結果。

第三，它接下來需要人的哪一個決策。

如果 session history 只是很多對話和工具輸出，那它其實沒有幫太多忙。人還是要從頭推理，猜 agent 的意圖，猜哪些步驟重要，猜最後狀態能不能相信。

好的歷史紀錄應該像一份交班筆記，而不是完整錄影。

它不用很長。它只要把任務、範圍、已做事項、驗證結果、待決策項目講清楚。這樣另一個人才能接手，也才能決定這個 run 應該繼續、收掉，還是整個丟掉。

工具呼叫越多，結案語言越重要

Agent 變成工作區之後，工具呼叫會越來越多。

它可能讀 issue、改檔案、跑測試、查文件、產生頁面、整理資料、建立內部工具、幫你把結果交給 reviewer。這些事情單獨看都合理，合在一起就會變成一條需要管理的工作流。

這時候 prompt 寫得再漂亮，也不能取代結案語言。

所謂結案語言，就是團隊對一段 agent work 的最終判斷要足夠明確。不要停在「看起來差不多」、「應該可以」、「之後再確認」。一個 run 最後應該落在幾種很清楚的狀態裡：

  • 已合併

  • 已拒絕

  • 已封存

  • 已交接

  • 已刪除

  • 等待某個具體驗證

這些字很無聊，但很有用。

因為自動化越多，模糊狀態越貴。以前一個人手動做事，腦中還記得自己卡在哪裡。Agent 跑完之後，如果沒有把狀態寫清楚，下一個人只會看到一包輸出，卻不知道它該不該被信任。

小團隊先從三條規則開始

如果你現在已經開始用 coding agent 跑比較長的任務，我會先加三條規則。

第一，沒有 owner 的 session 不要長期存在。

任何 agent run 都要有一個人負責收尾。這個人不一定要親自寫每一行 code，但要決定結果怎麼處理。沒有 owner 的 session 最容易變成團隊共同的心理負債。

第二，沒有驗證證據的 run 不能叫完成。

證據可以是測試結果、截圖、diff、build log、手動驗收紀錄，或很明確的「未驗證原因」。重點不是形式漂亮，而是 reviewer 不需要猜。

第三，沒有輸出位置就不要開新任務。

如果你不知道結果應該落在哪裡，就先不要讓 agent 跑。是開 PR？改某個 branch？寫一份 markdown？產生一個 demo？還是只要調查報告？輸出位置不清楚，工作很容易變成散落在 session 裡的半成品。

這三條規則不會讓 agent 變聰明，但會讓它比較能被管理。

對小團隊來說，這比多學十個 prompt 技巧更實際。

真正省時間的是把工作收得回來

我不覺得 agent 工作區是壞方向。相反，它很可能會變成很多產品團隊和獨立開發者的日常工具。

能把任務交出去，能讓背景 session 先跑，能保留歷史，能讓多人 review，這些都會改變工作節奏。尤其在資源少的小團隊，這種能力很有吸引力。

但越是這樣，越不能把 agent 當成一個神祕黑箱。

好的 agent workflow，不是讓人完全不用管它。好的 workflow 是讓人一眼看懂它現在在哪裡、做完了什麼、還缺什麼、接下來誰要判斷。

真正省時間的，不是把工作丟出去。

是每一次丟出去的工作，都收得回來。

Source notes

CC BY-NC-ND 4.0 授权