軟體工程師的角色消亡與重生：當代碼不再是主要產出
> 一個正在發生、但我們還沒完全理解的轉變
核心問題
「你不再是一個人，也不再只是一個人。」
看到這句話的時候，我愣了一下。
它像一個謎語，又像一句預言。這句話正在發生，但我們還沒完全理解它的意思。
你還記得最後一次在履歷上寫「Frontend Developer」是什麼時候嗎？那時候，角色是清楚的、邊界是明確的。你負責前端，別人負責後端，大家各司其職，像一支樂團裡的固定位置。
但現在呢？
打開專案，你發現自己不只在寫程式碼。你在定義協作流程、在配置 AI agents、在思考如何讓「人+AI」組合產生最大效益。你像是同時扮演著 Team Lead、Product Owner，甚至有點像 HR 在配置資源。
這不是工作量變多了。這是角色本身變模糊了。
也許你會問：「軟體開發的工作內容，到底變成什麼了？」
我也還在找答案。但我知道的是，這個轉變不是你一個人在經歷。所有寫程式碼的人，都站在同一個岔路口上。
這篇文章想探討的核心問題是：
> 當軟體成為副產品，工程師的價值還剩下什麼？
我不會給你標準答案，因為沒有人知道。但我想分享我的思考過程、我觀察到的變化、以及我還不確定的部分。
多角度探討
角度 1：角色邊界正在消融
從「職位」到「資源」的思維轉換
以前，我們習慣用職位來定義自己。Frontend Developer、Backend Engineer、DevOps，像是貼在身上的標籤。找工作時看 JD (Job Description)，上面寫著「需要熟悉 React、TypeScript」，你對照自己的技能清單，符合就投。
這個邏輯很簡單，也很安全。就像球隊裡的固定位置，王建民就是投手，只要把球投好就行了。
但 AI 時代，遊戲規則變了。
我們需要的不是「一個會 React 的人」，而是「能夠調度各種資源來完成 Frontend 任務的角色」。這個資源可能是你自己、可能是 AI、可能是「你+AI」的組合。
你要扛的不是工作，是責任感
「你要扛的比以前更多，不是工作，是責任感。」
這句話說得很準。
以前，Frontend 工程師的責任邊界是清楚的：把 UI 做好、API 串好、效能調好。其他的事情，有 PM 管產品、有 Team Lead 管流程、有 HR 管人。
但現在，當你可以用 Claude Code 的 Task tool 來調度多個 AI agents 時，你突然發現：你需要理解 Product 的視角（什麼功能該先做？）、需要理解 Management 的視角（如何分配任務？）、甚至需要理解 HR 的視角（這個任務該配置人還是 AI？）。
技術工具變強大了，但決策責任也變重了。
以前你只需要回答「這個功能怎麼實作？」，現在你需要回答「這個功能該由誰（或什麼）來做？怎麼做最有效率？」
三個身份的疊加
我觀察到工程師正在疊加三種身份：
Team Lead：你要設計協作機制。不是「大家一起開會討論」，而是「設計一個讓人和 AI 能無縫協作的 workflow」。
Product Owner：你要定義價值產出。不是「PM 說要做什麼就做什麼」，而是「理解為什麼要做，然後找到最有效的方式實現」。
HR/總經理：你要配置資源與人力。不是「等公司招聘新人」，而是「評估這個任務該用哪種資源組合，成本效益如何，能否即時調整」。
你不再是一個人，因為你要扮演多種角色。
你也不再只是一個人，因為你身後有一整個 AI agents 的團隊。
但這裡有個矛盾：
一方面，角色邊界消融讓我們變得更全能。
另一方面，當每個人都要懂一點 Product、一點 Management、一點 HR，我們還是專業的「工程師」嗎？
我還沒想清楚。
角度 2：能力定義正在改變
專業能力的進化
過去的專業能力：精通單一技術棧
- React + TypeScript
- C# + .NET
- Python + Django
你花三年精通一個框架，再花兩年成為專家。專業能力的證明是：你寫的程式碼品質高、效率快、bug 少。
現在的專業能力：調度 AI Agents
- 設計
.claude/skills/模組 - 配置 agent 職責分工
- 整合人與 AI 的協作
你的專業能力變成：知道什麼任務該讓 AI 做、什麼任務該自己做、怎麼把兩者組合起來產生最大效益。
技術工具：
- Claude Code（開發助手）
- GitHub Copilot（程式碼生成）
- Cursor（編輯器整合）
說穿了，專業能力不再是「你會什麼」，而是「你知道怎麼組合資源來完成任務」。
就像指揮家，不需要會彈所有樂器，但要知道什麼時候該讓小提琴進來。
管理能力的進化
過去的管理能力：溝通技巧、會議效率
- 如何清楚表達需求
- 如何協調不同意見
- 如何追蹤專案進度
管理能力的重點在「人」。你學習如何與人溝通、如何化解衝突、如何激勵團隊。
現在的管理能力：設計協作演算法
- 定義 agent 的 responsibilities
- 規劃 workflow 的協作邏輯
- 設計 message passing 與 task coordination
管理能力的重點變成「機制」。你要設計一個協作系統，讓人和 AI 在裡面能高效運作。
技術事實：Agent Teams 的 message passing 允許 agents 之間互相傳遞訊息，而 task coordination 確保任務不會重複或遺漏。
對比：
傳統 Scrum：
- Daily Standup（每天15分鐘）
- Sprint Planning（計畫會議）
- Retrospective（回顧會議）
AI-augmented workflow：
- 任務自動分配給最適合的 agent
- 進度自動更新在共享 task list
- 問題自動標註並通知相關成員
這不是取代 Scrum，而是讓協作的效率提升到另一個層次。
學習能力的進化
過去的學習能力：學新框架、新語言
- 讀文檔
- 上課程
- 做 side project
學習能力的展現是：你能多快掌握一個新技術。
現在的學習能力：學習「如何讓 AI 學習」
- Prompt engineering
- Agent configuration
- Skill design
學習能力變成：你能多快教會 AI 做你想要它做的事。
技術事實：在 Claude Code 中，你可以透過 .claude/agents/ 定義 agent 的職責，透過 .claude/skills/ 定義可重用的技能模組。這些都是「教 AI」的具體方式。
[此處可加入您學習 AI 工具的心得——第一次成功讓 AI 完成複雜任務時的感受]
這三個進化帶來的困惑
這三本柱的進化，也許讓我們變得更強大，也讓我們更依賴工具。兩者都是真的。
但我知道的是，當工具變強大時，我們的價值就不再是「會操作工具」，而是「知道該用工具做什麼」。
但這裡又有個問題：
如果工程師的價值是「知道該用工具做什麼」，那麼當 AI 也能學會「判斷該用什麼工具」時，我們還剩下什麼？
我還沒想清楚。
角度 3：團隊本質的重新思考
團隊是「人」的組成，還是「職位」的組成？
我們常說「我們是一個團隊」。
但仔細想想，這個「團隊」到底是什麼？
是「五個人」，還是「五個職位」？
靜態職務的困境
以前，組建團隊的方式很直接：
- 寫一份 JD (Job Description)
- 列出需要的技能
- 招聘符合條件的人
- 人到職後開始工作
這個模式有個假設：職位是固定的，需求是穩定的。
「我們需要一個 Senior React Developer」——這個需求在專案的一年內都不會變。所以我們找一個人，讓他從頭做到尾。
但問題來了：職位是固定的，但需求是動態的。
專案初期需要快速建立 prototype，這時候需要的是「會快速驗證想法」的人。專案中期需要穩定架構，需要的是「擅長系統設計」的人。專案後期需要優化效能，需要的又是另一種專長。
同一個「Senior React Developer」，能在所有階段都是最適合的人選嗎？
動態資源配置的新思維
「AI 時代，人是一種 agent，也是你的資源，你的花費變成算力，變成 token，還有時間，你有權抽換，有權調整。」
這句話剛開始聽起來有點冷血。
「人怎麼能說抽換就抽換？」
但換個角度想，這其實是一種解放。
以前，團隊組成是固定的。老闆說「這五個人就是你的團隊」，那就是這五個人。不管任務適不適合他們，你都得想辦法讓他們勝任。
現在，團隊組成可以是彈性的。
技術上，這已經可行了（Claude Code 的 subagent 機制允許動態生成與調度 agents）。
資源的衡量也變了：
- 傳統：月薪、年薪、福利
- 現在：算力（API calls）、token（使用量）、時間（執行時長）
更重要的是，你有權調整組成。
如果發現某個 AI agent 的能力不夠，你可以換一個更強的模型。如果發現某個任務需要人來做，你可以把它從 AI 手上拿回來。
這不是冷血，這是靈活。
從「找人」到「設計角色」
組建團隊的思維，從「找人」變成「設計角色」。
以前：「我需要一個會 React 的人」
現在：「Frontend 角色需要哪些能力模組？」
然後你發現：
- UI 組件開發 → AI 可以做 80%
- 狀態管理設計 → 需要人來思考
- 效能優化 → 人+AI 協作效果最好
- Code Review → AI 先篩一輪，人做最終把關
最後你配置的不是「一個 Frontend Developer」，而是：
- 1 個懂架構的人（負責設計與決策）
- 2 個 AI coding agents（負責實作）
- 1 個 AI review agent（負責品質把關）
這個組合的成本可能只有傳統「招聘兩個 Frontend」的 1/3，但效率可能是 1.5 倍。
也許有一天，當別人問「你的團隊有幾個人？」，你會回答：「2 個人，6 個 AI agents。」
這聽起來很科幻，但其實已經在發生了。
但這裡又有個倫理問題：
當人變成「可配置的資源」，當團隊組成變成「設計」而非「招聘」，人的尊嚴和價值怎麼辦？
我們會不會變成「可抽換的零件」？
我還沒想清楚。
角度 4：價值產出的翻轉
思維的翻轉
「我們以前是團隊的一員，是在創造產品；現在我們是一起在創造團隊的演算法。」
這句話的轉折，藏著一個深刻的洞察。
以前，我們的工作產出是什麼？
是軟體。是 Web Application、API Service、Data Pipeline。我們寫程式碼、做測試、部署上線，然後產品開始產生價值。
軟體是主要產出。團隊是手段。
但現在，這個關係翻轉了。
主產品：團隊設計思維 & 協作演算法
- 角色如何定義？
- 技能如何模組化？
- 協作如何流程化？
- 品質如何機制化？
副產品：軟體工具 & 專案產出
- Web Application
- API Service
- Data Pipeline
軟體變成了副產品。因為當你把團隊設計好了，軟體自然就會被高效地產出。
什麼是「團隊的演算法」？
聽起來很抽象，對吧？
讓我用技術語言解釋：
說白了，團隊設計就是軟體架構設計，只是運算單元從「函式」變成了「人或 AI」。
定義 agents 的 responsibilities
就像寫程式碼時定義函式的職責一樣，你要定義每個 agent 的職責範圍、輸入輸出、與其他 agent 的介面。
技術事實：在 .claude/agents/ 中，每個 agent 的 markdown 檔案就是在定義它的職責。
設計 skills 的可重用模組
就像寫程式碼時抽離共用邏輯一樣，你要把團隊的能力模組化、可重用、可組合。
技術事實：在 .claude/skills/ 中，你可以定義 frontend-expert、backend-expert、process-manager 等技能模組，然後在不同專案中重複使用。
規劃 workflow 的協作邏輯
就像寫程式碼時設計資料流一樣，你要規劃任務如何流動、誰在什麼時候接手、如何驗證完成。
技術事實：Claude Code 的 task coordination 機制允許你定義任務的依賴關係、執行順序、完成條件。
如果團隊是產品
如果團隊是產品，那我們該怎麼「開發」它？
模組化：將團隊能力模組化
- 把「Frontend 開發」拆成：UI 組件、狀態管理、API 串接、效能優化
- 每個模組可以獨立進化、獨立測試
可配置：將協作流程可配置
- 不同專案可以有不同的協作流程
- 透過
.claude/agents/的配置檔案來調整
版本控制：將團隊結構版本控制
- 團隊配置放進 git
- 可以追蹤演進、可以回溯、可以比較不同版本
當團隊可以像軟體一樣被設計、被測試、被迭代時，我們就真的在「創造團隊的演算法」了。
也許有一天，我們會像評估軟體品質一樣評估團隊品質——這個團隊的「可維護性」如何？能不能快速替換某個角色？當需求改變時，這個團隊的「擴展性」如何？
聽起來很瘋狂，但也許這就是未來。
但這裡又有個哲學問題：
如果團隊可以被「設計」、被「版本控制」、被「測試」，那麼團隊還是「人」的集合嗎？
還是變成了「機制」的集合？
我還沒想清楚。
我的個人立場
有時候我會想，如果有一天，寫程式這件事不再是我們的全部價值，那我們還剩下什麼？
我傾向相信的答案
我傾向相信：軟體確實正在成為副產品，團隊設計才是主產品。
不是因為我有完整的證據，而是因為我觀察到的趨勢：
- 工具變強了，但問題沒有變簡單
- Claude Code 可以寫代碼，但誰來決定寫什麼？
- AI 可以優化效能，但誰來定義「好的效能」？
- 技術問題被解決得越來越快，但「該解決什麼問題」變得越來越難
- 個人能力的天花板變低了，但組織能力的天花板變高了
- 一個人能做的事情，AI 很快就能做
- 但一個設計良好的「人+AI」團隊，能做到以前需要 10 倍人力才能做到的事
- 可複製的技能變得不值錢，但不可複製的判斷變得更值錢
- 寫代碼 → 可複製 → AI 能做
- 判斷該寫什麼代碼 → 不可複製 → 還需要人
- 設計團隊協作機制 → 更不可複製 → 更需要人
我還不確定的部分
但我還有很多不確定：
1. 這個轉變的速度有多快？
是 2 年內每個工程師都要學會「團隊設計」？
還是 10 年才會真正普及？
2. 不是每個人都適合當「設計者」
有些人就是喜歡專注在技術細節，不想管協作、流程、資源配置。
當「工程師」這個角色強制要求你成為「設計者」時，那些不想轉型的人該怎麼辦？
3. 人的價值到底在哪裡？
如果 AI 能做代碼，未來也能做判斷，那麼人的不可取代性在哪裡？
「對人的理解、對混亂的包容、對不確定的勇氣」——這些聽起來很美，但真的是不可取代的嗎？
還是只是我們暫時還沒被 AI 取代的安慰？
4. 倫理問題
當人變成「可配置的資源」，當團隊變成「可設計的演算法」，我們會不會失去某些重要的東西？
團隊的溫度？人與人之間的信任？那些無法被量化的連結？
[此處可加入您的個人經歷——在導入 AI 協作時，是否有過這些困惑？你的團隊如何面對這些問題？]
為什麼我還是想試試看
即使有這麼多不確定，我還是想試試看。
不是因為我有答案，而是因為：
1. 這個轉變正在發生，不管我們準備好了沒有
與其被動接受，不如主動探索。
2. 早期探索的人會建立新的專業
就像 10 年前，「DevOps」還不是一個正式的職位。現在，DevOps 工程師是市場上最搶手的角色之一。
也許 5 年後，「Team Architect」（團隊架構師）會成為一個獨立的職位。
3. 這個過程很有趣
設計團隊就像設計軟體一樣，有架構、有模組、有版本控制。
對於喜歡「設計系統」的工程師來說，這是一個全新的遊樂場。
開放結尾
給讀者的問題
我不知道十年後，「工程師」這個職業會變成什麼樣子。
但我知道的是，那些能夠從「團隊的一員」轉變為「團隊的設計者」的人，會在這場轉型中找到自己的位置。
現在，我想把問題拋給你：
1. 你準備好從「團隊的一員」變成「團隊的設計者」了嗎？
如果不準備，為什麼？
如果準備，你缺少什麼？
2. 如果團隊可以版本控制，你會設計什麼樣的 v2.0？
你現在的團隊是 v1.0，有哪些痛點？
如果可以重新設計，你會怎麼改？
3. 當軟體成為副產品，你的主產品是什麼？
除了寫代碼，你還在創造什麼？
那些東西能不能被「版本控制」、「模組化」、「重用」？
4. 人的不可取代性在哪裡？
你相信有些東西 AI 永遠學不會嗎？
如果有，是什麼？
如果沒有，我們該怎麼辦？
我還在想的問題
我也還在想這些問題：
關於速度：這個轉變會比我們想像的快嗎？還是慢？
關於適應：不想轉型的人，還有生存空間嗎？
關於倫理：當團隊變成「可設計的演算法」，我們會失去什麼？
關於未來：5 年後，我們還會用「工程師」這個詞來形容自己嗎？
未來可能的變化
也許，未來會有這些變化：
新的職位：
- Team Architect（團隊架構師）
- Workflow Designer（協作流程設計師）
- Agent Coordinator（AI 協調者）
新的技能：
- 團隊設計模式（就像現在的軟體設計模式）
- Agent 配置與調度
- 人機協作的最佳實踐
新的價值觀：
- 從「個人貢獻」到「系統設計」
- 從「技術深度」到「資源協調」
- 從「寫代碼」到「創造機制」
但這些只是猜測。
真正的未來，要我們一起創造。
如果你想立即開始
不需要等到完全準備好。你現在就可以做三件事：
1. 盤點你的「技能模組」而非「職位標籤」
你不是「Frontend Developer」
你是擁有：
- UI 設計感知
- 狀態管理經驗
- API 串接能力
- 協作溝通技巧
把這些能力列出來，然後問自己：哪些可以交給 AI？哪些必須自己做？
2. 試著設計一個小型 AI 團隊
2 個人 + 3 個 AI agents
定義清楚的職責分工
實際跑一個小專案
看看會遇到什麼問題
3. 將一次協作流程寫成「可重用的 workflow」
記錄下你們是如何協作的
哪些步驟可以自動化？
哪些決策點需要人來判斷？
然後問自己：你的「主產品」是什麼？
最後的邀請
我還在想。但我想試試看。
你呢？
如果你有想法、有經驗、有困惑，歡迎與我討論。
這不是一個人的旅程，而是一整個世代的轉型。
我們一起探索。