從撰寫者到主管：代理如何改變開發者的工作

代理大幅降低了撰寫程式碼的成本，卻沒有降低理解該做什麼，以及檢查成果的成本。因此，與代理協作最值得關注的，往往是寫程式碼之前和之後的事：誰來定義任務、誰來判斷成果是否合格，以及該交給代理多少工作。

接下來會整理近兩年研究與報告中的描述：與代理協作的四種方式、如何依任務選擇方式，以及所謂的"意圖與品質門檻"。後半段會談談，為什麼開發者的職責不再只是寫程式碼。資料截至 2026 年 9 月。數字會放在獨立區塊，並附上來源連結；轉述作者觀點時會標明出處，自己的推論也會清楚註記。

與代理協作的四種方式

Microsoft 的 Jared Spataro 在 2026 年 5 月提出了目前最清楚的一套架構，描述人與 AI 分工的四種方式。這套架構很直觀，開發者也能從中看見自己使用工具一路走來的歷程。

層級越高，您親自撰寫的程式碼越少，事前規劃和事後檢查就越重要。撰寫者在寫程式時掌握品質；指揮者看不到程式碼如何產生，因此所有重要要求都得在開始前說明，完成後再確認。這裡只先介紹協調者這個名稱：它是另一個有自己一套工具的大主題，等前三種方式都熟悉後再深入即可。

依任務選擇方式，而非逐級晉升

這套架構很容易被理解成一條階梯：先當撰寫者，再一路晉升為協調者，位置越高越好。但 Spataro 明確指出，事實正好相反。目標不是把每項任務都升級到第四種方式，而是為每一種工作流程挑選合適的方式。

實際選擇時，可以先想想這四個問題：

• 目標有多明確。如果您自己還不清楚成果應該長什麼樣，就還不適合把整項任務交出去；
• 成果能否自動驗證。完善的測試能讓您放手讓代理多做一些，因為錯誤會由檢查程序抓出來，而不是靠您盯著看；
• 出錯的代價有多高。提示文字打錯很容易修正，金額算錯卻可能代價高昂；
• 任務是否會重複。只做一次的任務不值得另建流程，每週都要做的任務就很值得。

以下是套用到具體任務的例子：

我認為值得記住這些數字。多數人保持謹慎，不代表落後；大家依照錯誤的代價選擇方式，這是合理的。如果任務出錯代價很高，您採用編輯者的方式並不代表"沒有充分利用"代理。

在 Claude Code 中，這個選擇可以直接設定。規劃模式（Plan mode）和權限規則就像由您親自調整的控制旋鈕。錯誤代價高的任務，可以要求代理修改前先提出計畫，並在執行高風險操作前先取得您的確認；例行任務則可以放手讓代理多處理一些。

意圖與品質門檻

交給代理的工作越多，開始之前說清楚要求就越重要。Microsoft 的研究指出，最能善用 AI 的人，不會只追求做得更多、更快，而是會把自身價值建立在只有人類能做到的事上：明確表達意圖，也就是描述預期成果與品質門檻，並思考人與 AI 該如何分工。

在軟體開發中，這些概念早有常見名稱。意圖就是規格：要做什麼，以及為什麼要做。品質門檻則是驗收條件，也就是 Scrum 所說的 Definition of Done：一份列出工作何時算完成的條件清單。下文簡稱為完成標準。

Microsoft 的 Daniel Epstein 正以 Agile 方法建置代理。他在 Agentic-Agile 系列首篇文章（2026 年 5 月 19 日）中，用一句話概括："Every capability is an issue. Every issue has acceptance criteria." 每項功能都是一個 issue，而每個 issue 都有驗收條件。

撰寫任務時，可以同時考慮兩種讀者。對人說明任務的目的和使用對象；對代理則說清楚要做什麼、如何驗證，以及哪些地方不能動。以下是同一項請求修改前後的教學範例。第二個版本的第一段是寫給人看的，其餘內容則是給代理的指示。

修改前：

請新增支出 CSV 匯出功能，做得好用一點。

修改後：

目的：會計人員每個月都要手動把團隊支出抄到自己的試算表，每次要花一小時，金額還常出錯。

任務：在每月支出頁面新增"匯出 CSV"按鈕。

完成條件：
- 在試算表軟體中按兩下即可開啟檔案，中文名稱不必手動調整編碼就能正常顯示；
- 每筆支出各占一列，第一列是欄位名稱；
- 金額可直接用公式加總，不必修改儲存格。

不要修改：支出的儲存格式，以及現有的清單畫面。
請先提出計畫，並說明每項條件要如何驗證。

第二個版本幾乎不需要代理自行猜測。更重要的是，您有明確標準可以比較成果：三項條件花幾分鐘就能手動確認。第一個版本的"好用一點"無從驗證，只能選擇相信。

代理不知道什麼才算好

接下來主要是我根據資料得出的看法，不是資料本身。先說明這點，免得把觀點說成研究結果。

代理能做很多事：閱讀陌生專案、找出錯誤原因、撰寫實作、執行測試，並解釋自己做了什麼。但有一件事它辦不到：自行判斷對這些使用者和這項業務來說，怎樣才算"做好"。沒有明確標準時，它會挑一個看似合理、中規中矩的方案，然後自信地回報已經完成。程式碼或許很整潔，解決方案卻仍然不是對方要的。

"好不好"並不寫在程式碼裡，而是取決於誰會使用成果、對那個人來說什麼最重要，以及哪些錯誤無法接受。以匯出功能為例，代理完全可能產生技術上正確的 CSV，會計人員打開後卻只看到亂碼。就程式碼而言，沒有錯；就任務而言，卻不合格。

結論很簡單：訂出標準，再依標準檢查成果，這部分工作無法委派。代理可以協助擬定標準、提出澄清問題或建議檢查方式，但標準是否恰當，仍由您來判斷。

先了解工作流程

標準從何而來？幾乎不會來自程式碼，而是來自業務流程：誰會開啟檔案、接下來要如何使用，以及資料列遺失或金額四捨五入錯誤時會發生什麼事。

"不用手動調整，就能正確顯示中文名稱"這項要求，並不是因為 CSV 就該這樣寫，而是有人問了會計人員如何開啟檔案，才發現對方直接按兩下，根本不會使用匯入精靈。了解流程的開發者會一開始就寫下這項標準；不了解的人，則要等一個月後收到抱怨才知道。

有些公司已經注意到這點，並開始重新調整職務分工。

這件事也有相反的觀點，值得了解。例如，顧問公司 Converteo 在自己的部落格中，將產品經理、設計師和 AI product builder 描述為互補而非競爭的角色：產品經理負責回答"為什麼"，設計師關注使用者，AI product builder 則迅速把想法做成可運作的原型。Converteo 自己也提供這方面的顧問服務。我不會押注其中任何一種說法。對您而言，實際結論都一樣：了解客戶流程的開發者，比只等著收到完美 ticket 的人更有價值。

對話也是工作工具

過去常把 soft skills 當成技術之外的加分項。代理出現後，情況變了。品質標準存在於人的想法中，不在儲存庫裡，只能透過對話問出來。

實際上，以下這些都已經成為工作的一部分：

• 先詢問。不要只問"要做什麼"，而要問"您會如何使用成果"，這個問題大家通常答得更準確；
• 再確認。趁邊界情況還沒變成 bug，先追問清楚：沒有分類的支出該怎麼處理？
• 留下紀錄。只留在對話中的共識，代理讀不到，同事也會忘記；
• 確認範圍。說清楚任務包含什麼、不包含什麼；有人要求"順便改一下"時，也要指出"那是另一項任務"；
• 說明取捨。"一天內完成，但不能選期間；或花三天完成，並支援選期間" - 最後由客戶決定，選項則由您提出。

這些能力都和寫程式碼無關，卻都會直接影響代理的工作成果。換句話說，您與人溝通的品質，會轉化成任務交代給代理時的品質。

人人都像個 CEO

把這些事情放在一起看，會發現一幅熟悉的圖像：設定目標、訂出標準、分配工作、檢查成果並為成果負責，這些都是主管的工作。開發者每天與代理協作時，也會做這些事，只是規模小得多。

CEO 這個比喻有一個優點：它清楚指出責任所在。CEO 幾乎可以委派所有工作，唯獨不能卸下對成果負責的責任。代理也是如此。如果代理做出的匯出功能讓會計人員的試算表出錯，負責的不是代理。

也得說清楚，這個比喻不代表什麼。它不是升職，也不表示啟動三個代理就成了主管。比較可能的情況是，主管需要的能力會比過去更早派上用場，甚至在第一份工作就用得到。還有一個風險：開發者過去長期靠親手寫程式碼累積經驗，這條路正在改變。但理解您從代理那裡接手的程式碼，仍然不可或缺。否則檢查成果就只剩下"好像能跑"。

如何解讀這些資料

以上數字都來自銷售 AI 或相關產品的公司。這不代表數字是假的，但仍值得納入考量。簡要整理如下：

這裡所有百分比都是人們在單一時間點的自我評估，反映的是他們的想法和預期，而非實際發生的事。Work Trend Index 2026 的作者也明確指出，分析中的關聯是統計上的關聯，不代表因果關係。

看到任何關於 AI 與工作的數字，都可以先問三個問題：誰出資進行研究？研究衡量的是什麼：看法、預期，還是實際成果？研究詢問了哪些人，他們和您相似嗎？如果答案讓您信服，就可以參考這個數字；如果不然，它或許仍有參考價值，只是份量較輕。

這一切的實際意義

上面這些聽起來像報告用語，但在 Claude Code 的工作中，都能轉化成具體習慣：

• 修改前先看計畫 - 這就是意圖。請代理先說明預計修改哪些內容、如何修改，再確認是否符合您的期待；
• 在請求中列出驗收條件 - 這是您的完成標準。用兩、三項可驗證的條件，取代"做得好用一點"；
• 工作模式與權限規則 - 決定採用哪種方式。錯誤代價越高，就越應該讓代理經常停下來詢問；
• 檢視 diff 並確實驗證 - 依照您的標準評估成果，而不是只看代理的報告；
• 簡短總結：完成了什麼、如何驗證、哪些尚未驗證 - 對成果負責，這件事不能轉交給代理。

資料截至 2026 年 9 月。這個領域的研究不斷推出，數字過時的速度比結論更快。