小編精選 - 技術文章翻譯 · 08月23日

思考最近熱門的「AI時代的開發者五種原型」

AI時代的 5 種開發者原型是什麼？

最近，我聽到這樣一個說法：

工程師的分類，未來可能不再是後端、前端這種區分，而是可以用包含原型開發者在內的 5 種原型來理解。

我查了一下，原來是由負責 Claude Code 開發的 Boris Cherny 提出的觀點，內容是關於工程師的 5 種原型。

原型職責1. 原型開發者大量嘗試新的想法。大多不會正式發布2. 建造者把想法與原型推進到可上線品質3. 整理者整理 UI、程式碼與系統，進行刪除、簡化、加速4. 成長推進者反覆改善已做出的產品，提高 PMF（Product-Market Fit：產品與市場契合度）5. 維運者維持成熟系統的安全性、可靠性、效能與效率本文整理了這個分類的概要，以及對它的批判性討論。

思考背景

Anthropic 分析了約 40 萬筆 Claude Code 工作階段後，觀察到如下分工：

人類：約 70% 負責「要做什麼」的規劃與方針判斷
Claude：約 80% 負責「怎麼實作」的實作判斷

另外，同一份調查也顯示，對該任務具備越高專業性的人，工作階段成功率也越高（這裡的專業性並不是單純的職務或一般寫程式能力，而是是否理解這個任務應該達成什麼這種任務特定的專業性）。

也就是說，在 AI 時代，具備該領域知識，能定義「要做什麼」與「做到什麼程度才算完成」，並能驗證 AI 成果的能力，似乎正變得更加重要。

與其問「你能做什麼？」，不如說，發現問題、決定方向、判斷品質、培養產品、承擔責任這些角色差異，未來會變得更重要。

原始貼文

Cherny 把這 5 種原型當成「未來可能會這樣發展」的假說來提出。

以下是 Anthropic 的 Boris Cherny 在 X 上發表的內容。

本文的調查方法與 AI 使用方式

這篇文章是筆者把「5 種原型到底是什麼？」這個疑問交給 GPT-5.6 調查後，得到一份比想像中更清楚的資料，再整理成適合文章使用的內容。

雖然也許任何人都可以用 AI 做出這樣的資料，但我認為作為讓人接觸這種思考方式的契機，仍然值得留下來，因此才刊出。

各原型的評價與批判

我整理了各個原型的概要，以及對它們的批判性意見。

特別是批判性意見中，有不少一針見血地點出 5 分類的本質，很值得參考。

① 原型開發者

概要

這是最容易受惠於 AI 的角色之一，因為它能快速做出大量原型。

像 Claude Code 這類 AI Agent，大幅降低了每次試驗的成本，因此可以大量跑這種循環：

點子 → 原型 → 回饋 → 丟棄

Anthropic 內部也有報告指出，會讓多個 Claude 並行運作，同時探索不同方法。

批判

矛盾的是，原型開發者本身的稀缺價值可能會下降。

2026 年 7 月針對這個分類的一則評論指出，因為 Claude Code 之類的工具降低了原型製作的進入門檻，所以這很可能會成為 5 種角色中競爭最激烈的一種。

也就是說，變得稀缺的，不只是「會做」而已，而是：

應該試什麼
應該丟掉什麼
哪個結果值得相信

這種辨別價值的敏銳度與判斷力。

試作成本下降，反而更容易陷入「一直做原型，卻沒有任何一個真正成熟」的狀態。

因此，重要能力的核心，可能不只是實作很多點子，而是能嗅出客戶需求的直覺，以及能從多個試作中篩選出有價值假說的選擇眼光。

② 建造者

概要

AI Agent 最擅長的是建造者的「動手部分」。

Anthropic 約 40 萬筆工作階段的分析顯示，人類掌握規劃與方針判斷，AI 負責實作判斷，這個結構相當清楚。

而且，人類對目標領域的專業越高，對 Claude 的指示就越精準，也越能可靠地完成更多工作。

因此，優秀的建造者，可能會從：

自己寫大量程式碼

轉變為：

規格／驗收條件 → 架構／限制 → 測試／驗證標準 → 委託 AI Agent 實作 → 審查

這樣的開發迴圈設計與監督者。

當然，也可以讓 AI 協助撰寫架構與測試。重點不是人類把所有事情都手動做完，而是對於要做什麼，以及滿足哪些條件才算正確，保有最終判斷權。

批判

最大的問題是：

「能運作的軟體」與「production-grade 的軟體」之間，距離仍然很大。

Anthropic 自家員工調查也提到，有些人表示理解 Claude 寫出的程式碼所需的認知負擔增加了，後續除錯與整理的時間也可能變多。

此外，對於複雜且高風險的工作，許多員工仍然會積極驗證 AI 的成果。

在 ExperiencedDevs 等社群中，也能看到多起個別回報，指出 AI 產生的程式碼增加後，審查端的負擔變高了。

這些都只是社群上的個別案例，但 AI 提升實作速度後，設計、審查與治理端反而成為新瓶頸，這個方向也與 Anthropic 內部調查相符。

也就是說，未來建造者所需要的能力，可能會從：

「快速寫程式的能力」

轉向：

「運用 AI 打造不容易壞的系統的能力」

③ 整理者

這是 5 種分類中，在 AI 時代可能更重要的角色。

AI 讓「新增」變得非常低成本，但：

這個功能不需要
這個抽象層不需要
這個畫面可以拿掉

這種「做減法」則需要理解目的、使用者體驗與未來規劃後才能判斷。

Anthropic 內部也有 8.6% 的 Claude Code 任務，是用在重構等「減少日常小摩擦的改善（papercut fixes）」上。

批判

有人批評把整理者當成獨立的「後段作業」本身就不恰當。

UI 的精緻化與系統的簡化，並不是建造者把東西做完之後才來收尾的工作，而是應該從設計與實作階段就一併納入。

另外也有評論指出，整理者不是屬於某個特定產品階段，而是從原型到成熟產品都一直需要的角色。

這麼看來，整理者與其說是「做清理的人」，不如說是判斷該保留什麼、刪除什麼，以及要簡化到什麼程度的能力。這個任務本身就直接連結到產品策略，因此需要高度的產品、需求與行銷理解。

④ 成長推進者

成長推進者是負責擴大既有產品的人。

隨著 AI 讓實作成本大幅下降，真正的瓶頸就會轉向「要改善什麼」，因此其相對重要性反而會提高。

有一位實務工作者把這 5 分類套用到自己的個人開發後指出，原型開發者、建造者、整理者、維運者都可以相當程度地 AI 化，但只有成長推進者因為需要真實使用者這個「外部世界」，所以最難自動化。

批判

反過來說，這個分類中邊界最模糊的也是成長推進者。

依情境不同會有些差異，但若把成長推進者的工作對應到既有職種，會涵蓋：

客戶研究
市場選擇
定位
產品策略
銷售與獲客渠道
定價設計
業務

因此也可以說，「成長推進者」這個詞塞進了太多能力。

另外，如果只是不斷改善局部 KPI，還可能錯過真正需要的產品策略調整。

⑤ 維運者

在 AI 時代，這不但不會消失，反而可能因為產品數量與產生的程式碼量增加，而讓工作總量上升的角色。

重點包括資安、可靠性、可觀測性、事件應變、成本最佳化、移轉作業等。

對於例行性的監控、測試、資安檢查，AI Agent 較容易接手，但事故發生時的最終責任仍然在於人類。

Anthropic 也說明，當 AI Agent 被賦予越大的權限，潛在損害範圍就會越大，因此在提升 AI Agent 能力的同時，也在加強封鎖與監督。

批判

最大的問題是不容易被評價。

「做了 10 個新功能」很容易看見，但：

「沒有發生故障」
「沒有引入不必要的複雜性」
「避免了事件發生」

這些成果卻很難被看見。

最近針對這個分類的評論也指出，維運者是「最不光鮮、最不容易被評價但又不可或缺」的角色，而且如果把角色固定化，可能會出現「維運者是職涯死胡同」這種階層化認知。

對 5 種原型分類本身的主要批判

批判 1：把人本身分成 5 類的危險性

前 Meta／Microsoft 的 Kun Chen 針對 Cherny 的 X 貼文批評說，一旦選擇了某種原型，人就可能停止反問自己。

Cherny 也同意這點，回應說「角色會隨時間與專案而改變」。

這非常重要。

把分類：

A 是建造者
B 是維運者

這樣當成貼在人身上的固定標籤是很危險的。

更好的用法應該是：

這個專案現在建造者太多，缺少整理者與成長推進者

也就是把它當成診斷當下團隊缺少哪種工作能力的框架，會更有用。

批判 2：偏向矽谷型產品組織

LinkedIn 上，Vivek Bharadwaj 批評這 5 分類太偏向矽谷型產品公司。

他有趣的主張不只是指出「5 分類少了什麼角色」。

他認為，在很多組織裡，原型開發者、建造者、整理者、維運者，並不是由不同的人分工，而常常是一個建造者在擅長與不擅長之間擺盪，負責整個產品生命週期。

因此 Bharadwaj 建議把這 4 個合併成廣義的「建造者」，保留成長推進者作為獨立角色，並再加入以下兩種：

Handler：實際推動複雜組織運作的人。常出現在 Chief of Staff、業務／事業營運、CX 策略等角色
Grown Ups：為加速中的組織踩煞車的人。負責法務、財務、風險管理等

從這個批評可以看出，Cherny 的 5 分類雖然很能解釋產品的製作、改善與維持，但對於實際推動公司運作的組織管理，以及法務、財務、風險管理等治理工作，涵蓋得還不夠。

確實，原本的 5 分類幾乎沒有提到組織運作、法務、財務、風險管理、招募、客戶合約、團隊管理等主題。

因此，與其把這個分類當成整家公司職種模型，不如把它視為產品開發中的 5 種原型會更自然。

總結

與其說是 5 種「職種」，不如說是 5 種「任務憲章」更有用

綜合目前資訊來看，最恰當的理解應該是這樣：

產品狀態重視的原型PMF 之前原型開發者 + 建造者 + 整理者尋找 PMF 並成長中建造者 + 整理者 + 成長推進者 + 一部分維運者已建立強 PMF整理者 + 成長推進者 + 維運者 + 一部分建造者因此，把人類端特別重要的問題，依原型整理如下：

原型人類端要回答的問題原型開發者應該試什麼？建造者應該把什麼、以什麼品質交付到正式環境？整理者應該保留什麼、刪除什麼、如何簡化？成長推進者應該改善什麼，才能讓使用者的 PMF 更高？維運者應該保護什麼、接受哪些風險，以及如何偵測與復原異常？---

最終評價

觀點評價「工程師這個職種會消失」現在還言之過早職種邊界變得模糊有相當強的跡象一個人同時負責多個領域Anthropic 內部也已觀察到比起實作，判斷力更重要非常有說服力直接把 5 分類當成職種不太建議作為團隊／產品分析框架非常有用這場討論最有價值的地方，其實不是「未來工程師會不會變成原型開發者或建造者」這件事。

真正重要的是，隨著 AI 降低實作本身的成本，人類端的問題定義、判斷、驗證與責任這些能力，其價值正在相對上升

若再往前一步，

與其問：

「你屬於哪一種原型？」

不如問：

「現在這個專案缺少哪一種原型？」

這樣的用法更合理。

如果把它當成固定職種，可能會導致角色僵化與不必要的階層化。

但若把它當成診斷團隊能力組合的 5 個軸線，那麼它很可能會成為思考 AI 原生開發組織時，非常實用的框架。