程式碼現在由代理來寫。開發者這份工作，變成了下面這樣。

只要家裡有個做開發的，飯桌上遲早會冒出這個問題：既然程式碼機器會寫了，那還剩下什麼？

老實說，這個問題問錯了地方。寫程式碼從來就不是這份工作的全部。它只是看得見的那部分，是從工位後面路過的人眼裡唯一像在幹活的那部分。而且在大多數星期裡，它還是佔比最小的那部分。

被自動化掉的那部分，從來就不是工作的全部

任何最終上線的東西，都要走完六個環節：

1. 有人想要點什麼，而且說得很糟。
2. 有人判斷這事值得做，以及什麼時候做。
3. 有人把它變成一段足夠精確、可以直接照著動手的描述。
4. 有人把它做出來。
5. 有人確認它沒有碰壞別的東西。
6. 有人把它發布出去，並回話給最初提要求的人。

代理拿走的是第四環。它拿得很有說服力，而且只會越做越好。幾乎沒人明說的是這件事對另外五環的影響：它們變重了，不是變輕了。

原因是吞吐量。當「把它做出來」要花兩週時，周圍這五環也就有兩週的時間慢慢走。它們慢，是因為中間那一環慢，所以沒人發現它們慢。當「把它做出來」只要一個下午，其餘的一切就在同一時刻變成了瓶頸。

一環塌了下去。它原本擋住的重量，現在壓在另外五環身上。

整件事就是這樣，而這篇文章餘下的部分，講的是這五環每天真正落到手上時，各自長什麼樣。

環節 1：聽見要做什麼，而且別丟掉一半

新的失敗方式很具體，代價也很實在：什麼都做得出來，於是你把錯的東西做得更快了。

需求從四面八方冒出來。客服會話裡的一條訊息。會議結束前的一句話。社交媒體上的一句抱怨。一份其實是功能需求、只是套了個 bug 外殼的報告。以前這沒什麼要緊，反正你兩週也只做得動一件事，而最顯眼的那件通常就是對的。現在你一週能做五件，選對的那五件和選錯的那五件之間的差距，就是你一年裡的絕大部分。

有兩件事必須發生，而它們是兩件不同的事。

第一，對提需求的人來說，提交這個動作本身必須足夠便宜。如果使用者得先註冊帳號、再找到一個表單、再把問題描述兩遍，多數人根本不會去做，而願意做的那些人也不構成一個有代表性的樣本。一塊公開待辦看板，任何人都能在上面提需求、附一張截圖、追蹤它後來怎麼樣了，這層摩擦就沒了。用產品的人自己寫下需求，用他們自己的措辭，上下文一併帶著。

第二，歸攏必須是自動的，因為原始反饋的保質期很短。二十條其實在說同一件事的訊息，在有人把二十條都讀完並發現它們是一件事之前，看上去就是二十個問題。而這恰好是誰都騰不出時間去做的活。Idea Radar 是我們給出的答案：原始訊號原樣落進來，自動聚成主題，重複項在變成兩份工作之前就被對上，每個想法都帶著有多少個不同的人提過它這個數字。原文從不被改寫，因為對方用的那些確切措辭本身就是資料。

這一環產出的不是一份待辦清單，而是一份你讀得下去的語料。

環節 2：決定做什麼，現在最稀缺的就是這個

一塊想法看板不是計劃。把前者變成後者靠的是判斷，而這個判斷以前稀稀拉拉地攤在一個季度裡，現在每週都得做一次。

這裡有兩個動作真正起作用。

晉級是一個刻意的動作。一個想法變成待辦工單，是在有人判斷它值得做的那一刻，而不是在它被提交的那一刻。其餘的想法留在雷達上，帶著提過它的人數，這才是誠實的狀態：聽到了，但沒排期。八成條目永遠不會被做的待辦清單不是計劃，那是一份排版具有欺騙性的檔案。

範圍界定發生在動手之前，不是動手過程中。含糊的反饋先變成一張確認過的效果圖，提需求的人可以直接看著它點頭。五分鐘的確認，勝過一個下午做錯一個頁面，而當這個下午從你的一個下午，變成本可以用在別處的一個下午的代理時間之後，這筆帳變得划算得多。

環節 3：寫任務簡報，取代打字的那門手藝

真正的手藝跑到這裡來了。

代理不會像同事那樣，對一條含糊的指令提出異議。它不會說「等等，你指的是兩條支付流程裡的哪一條」。它會用一個看起來合理的猜測把空缺填上，然後交給你一份自洽而錯誤的東西。含糊的代價以前是一次對話，現在是一份 diff。

拿到好結果的人和一整天都在跟代理較勁的人，差別不在提示詞寫得多巧，而在有沒有可複用的上下文。一共四種，按回報從高到低排。

代理在動手探索之前就會讀的上下文。 提交進儲存庫的約定檔案（CLAUDE.md、AGENTS.md），以及一份專案記憶，裡面裝著架構決策、踩過的坑，還有事情為什麼長成現在這樣的原因。寫一次，之後每台機器上的每個代理都會讀，一直讀下去。這是今天開發者寫下的、槓桿最高的文字，而幾乎沒人給它排時間。

把流程存成流程。 當你第十次講解自己的發布檢查清單時，你不是在寫任務簡報，你是在重打一遍字。一個技能庫能把一段反覆出現的流程變成代理在任務對得上時自動載入的東西，而一個提示詞庫對任務簡報本身做同樣的事。

給它看，而不是描述給它聽。 一段描述某個按鈕沒對齊的文字，比不上一張這個按鈕沒對齊的圖。直接發一塊螢幕區域過去，或者在上面畫兩筆指出你說的是哪個東西。如果是網頁，把即時的 DOM 交給代理，永遠好過向它描述。

說出來，而不是打出來。 一段三句話的口述簡報，比你原本願意打下來的那一句承載的細節多得多。快速下一條指令用語音聽寫，想在不碰鍵盤的情況下來回溝通就用語音模式。這聽起來像個舒適度功能。實際上它是個頻寬功能：人說出來的總比打出來的多，而代理的上限就是你告訴它的那些。

前三種每做一個任務都要重新付一次。第四種只付一次，之後一直在收。

環節 4：把活跑起來，跑在對的機器上

一個代理是工具。多個代理是系統，而系統需要有人來操作。

真正要回答的問題都不體面，而它們就是這份工作本身。哪些活可以並行跑，而不會出現兩個代理同時改同一個模組？哪個任務在執行期間值得你盯著，哪個不值得？你睡覺的時候，應該有什麼在跑？

最後這個問題決定了活在哪裡執行。任何你可能需要中途打斷、糾正或者掰回方向的事情，都留在你面前這台機器上。又長、交代得清楚、沒有模糊地帶的活，應該丟到別處去：另一台你自己的電腦，或者一台透過 SSH 連上的伺服器，這樣一個兩小時的任務就不會把你的筆記本扣為人質。反覆出現的活交給定時任務。決定性的問題從來不是算力，而是你需要介入的機率有多大。

當一件活裡的各個階段確實性質不同時，單個代理就是錯誤的形狀。一件要先做出來、再測試、再審查的工作，是三份需要三套本事的活，而代理團隊讓你把這幾次交接明確畫出來，不必在每一步重新解釋一遍上下文。

而且因為這一切都不要求你坐在那兒，用手機來指揮也就不再是個噱頭。在火車上花二十秒讀完代理的提問並回答它，決定了這個任務是做完了，還是等了你四個小時。

環節 5：審查，責任落在這裡

這一環沒法交給別人，原因不是技術上的。

逐行閱讀這件事，大部分已經被代理接走了。它們接不走的是簽字。責任不會轉移到一個模型身上。當一次遷移在正式環境上刪掉一列資料時，「這是代理寫的」不是一句誰會接受的話，也不該是。

變的是審查的形態，不是它存不存在。每一行都讀這條規矩，在五個代理並行跑起來的那一刻就撐不住了；而一個人在晚上六點快速掃過九百行的 diff，產出的是一個簽名，不是認識。真正站得住的規矩是按影響範圍審查：文案和樣式掃一眼就過，而身份驗證、支付、權限、個人資料和資料庫遷移，每一次都要由一個本來就寫得出這些程式碼的人逐行讀完。

有兩件事讓這套做法真的跑得起來。能夠按代理分別看 diff，而不是面對一堆合併在一起的改動，在三個代理動過同一個儲存庫的時候，它能告訴你誰改了什麼。而把對話附在提交上回答的是半年之後真正費時間的那個問題，那個問題從來不是「改了什麼」，而是「為什麼」。

只要涉及介面，檢查就不能停在 diff 上。一個能操作真實瀏覽器的代理，可以把它剛做出來的流程完整走一遍並彙報它看到了什麼，這能抓住那一類在原始碼裡讀起來毫無問題的 bug。

關於這份注意力該花在哪裡，我們專門寫過一整篇：你還需要審查 AI 代理寫的程式碼嗎。

環節 6：發布，然後把迴圈閉上

發布是這一環裡容易的那一半。被跳過的那一半，是回話給最初提要求的人。

它也是回報最高的那一半。一個報了問題、後來聽說它已經上線的使用者，下一個問題還會來報。一個報完之後只收獲沉默的使用者會停止上報，而你也就失去了餵養第一環的原料。當一張源自公開需求的工單被關閉時，提交它的人應該會收到訊息，而不需要任何人記得去發一封郵件。

在這之前，通常還有個人需要親眼看到它跑起來，而這個人手上沒有你的開發環境：一位客戶、一位設計師、一位在另一個大洲的同事。一個指向你本機的公開 HTTPS 網址，把這件事從一次部署變成了一條連結，而回來的反饋直接進入第一環。

鏈條閉合了。正是這一點讓它成為一份工作，而不是一條排隊的佇列。

真正縮水的和真正膨脹的

老實讀完這張表，焦慮就換了個形狀。縮水的那些部分，恰恰是最容易招到人的部分。膨脹的那些部分，需要一個真正理解系統、理解使用者、理解後果的人。這是一份更難的工作，不是一份更小的工作，而且比整天埋頭打字的那個版本要熱鬧得多。

AgentsRoom 在這裡面處在什麼位置

我們做的是能把整條鏈條兜住的那個工具，因為另一種選擇是六個彼此不認識的工具。

具體地說：需求落進一塊看板，自動歸攏成想法，被晉級成工單，被界定成一份代理不會讀錯的說明，由一個代理或者一支代理團隊在你的機器上或者一台遠端機器上執行，按代理分別審查、對話一併附上，最後在關閉時通知最初提要求的人。一個視窗，一個能反映工作真實狀態的地方。

單塊的零件別處都有。沒人做出來的是它們之間的連線，而工作正是從這些連線處漏掉的。

大家真正會問的問題

AI 會取代軟體開發者嗎？

它取代的是打字，不是這份工作。寫程式碼是一條鏈條上的一環，這條鏈條上還有：聽見使用者需要什麼、判斷什麼值得做、把它寫得足夠精確、盯住執行、驗證、發布。代理把其中一環的成本壓塌了，於是另外五環成了瓶頸。以後為產出程式碼行數而拿錢的人會更少，而為決定哪些程式碼行應該存在、並在它們上線之後為其負責而拿錢的人會更多。

程式碼由代理來寫之後，開發者具體在做什麼？

六件事，而其中只有一件以前會顯示在一屏程式碼上。你收集大家提出的需求，你決定什麼值得做以及按什麼順序做，你把任務簡報寫到代理不可能讀錯的精度，你同時推進好幾件活而不丟線索，你按每個改動可能造成的破壞程度來審查，然後你發布並回話給最初提要求的人。手藝從產出改動，轉移到了把它講清楚併為它負責。

還需要會寫程式碼嗎？

需要，而且在「讀」這件事上比以前更需要。你不再需要背下一門一年只碰兩次的語言的語法，那由代理來寫。但你需要開啟一份 diff，在幾秒鐘之內判斷出一次遷移能不能回滾、一處身份驗證有沒有被挪走、一條查詢在十倍流量下扛不扛得住。看不懂程式碼的人審查不了代理，而審查不了代理的人不是在指揮它，只是在祈禱。

把寫程式碼交給代理之後，最先崩掉的是什麼？

是優先順序排序。當做一件事從兩週變成一個下午，做錯東西的成本就從視野裡消失了，於是它真的被做了出來。團隊最後拿到的是更多已發布的功能，而解決掉的問題一個都沒多。第二個崩掉的是反饋閉環：使用者的需求來得比任何人整理得動的速度都快，於是它們堆在聊天記錄裡被弄丟，同一個需求被做了兩遍，因為沒人發現那是同一個。

在這套新的工作方式裡，最難的本事是什麼？

把任務簡報寫到代理不可能讀錯。代理不會像同事那樣對一條含糊的指令提出異議，它會用一個看起來合理的猜測把空缺補上，然後交給你一份自洽而錯誤的東西。拿到好結果的人靠的不是提示詞寫得多巧，而是他們一直在維護可複用的上下文：提交進儲存庫的約定檔案、每一件反覆出現的任務都存下的一份流程、一份代理在動手探索之前就會讀的專案記憶，以及用截圖或草圖代替整段描述介面的文字。

編碼代理應該跑在本機還是遠端機器上？

兩者都要，按任務來選。任何你想盯著看、想中途打斷或者糾正的活，都放在你面前這台機器上。又長、交代得清楚、沒有模糊地帶的活，放到另一台你自己的電腦或者一台透過 SSH 連上的伺服器上，這樣一個兩小時的任務就不會把你的筆記本扣為人質。做決定的問題不是算力，而是你需要介入的機率有多大。

簡短版本

這份工作沒有消失。它從編輯器裡搬了出來，搬進了圍著編輯器的那條鏈條。

如果這個月你只打算改一件事，那就選第一環。一旦對準的是錯的問題，它下游的一切都是白費力氣；而這也是唯一一個環節，在這裡你一小時的注意力，仍然以一個沒人量得出來的倍數勝過一小時的代理時間。