以模型為核心的團隊編制：無傳統工程師的敏捷編制

過去要做出一個能上線的數位產品。團隊的長相幾乎是固定的。你需要一個產品經理。需要幾個前端與後端工程師。需要設計師與測試人員。每一個角色都對應一份薪水與一段招募的時間。這套編制行之有年。大家也習以為常。但這一兩年。有一件事悄悄改變了這個慣例。一顆夠強的大型語言模型。已經能寫出可用的程式、能查資料、能擬草稿、能把零散的需求整理成規格。於是一個尖銳的問題浮上檯面。如果模型能做掉過去工程師大半的活。那一個小團隊。是不是可以在「沒有傳統工程師」的情況下。照樣把產品做出來。這篇文章想拆解的。就是這種以模型為核心的全新編制。它不是要你裁掉所有人。而是要你重新想清楚。當模型坐進團隊的正中央。剩下的人。到底該負責什麼。

一、什麼叫「以模型為核心」，而不是「把模型當工具」

先把概念講清楚。多數團隊現在用 AI 的方式。其實還是「把模型當工具」。意思是。人還是照原本的分工在做事。只是手邊多了一個會寫程式、會查資料的助手。工程師寫累了。叫模型補一段。文案寫不下去。叫模型給靈感。模型在這裡。是掛在每個人旁邊的外掛。組織的骨架沒有變。

以模型為核心的編制。是把這個關係整個翻過來。模型不再是某個人的外掛。而是團隊運作的中樞。需求進來。先由模型生出第一版的程式、文件或方案。人不再是「從零生產」的那一方。而是退到模型的外圈。負責三件模型做不好的事。一是把問題定義清楚。二是驗收模型產出的品質。三是為最後的結果負責。換句話說。生產的主力換成了模型。人的價值。從「會不會做」。挪到了「會不會判斷與收尾」。

這個轉換之所以重要。是因為它改變了招募與編制的邏輯。當生產主力是模型。你需要的就不再是一大批會敲程式碼的人。而是少數幾個。懂得提出對的問題、看得懂模型有沒有亂講、扛得住最後責任的人。團隊因此可以壓得很小。卻不見得做得比較少。這就是「無傳統工程師」這句話真正的意思。不是工程消失了。而是工程的執行被模型接走了。留給人的。是更上游的定義。與更下游的把關。

二、團隊架構圖：模型在中央，三種人在外圈

以模型為核心的小團隊。可以畫成一張很簡單的圖。模型坐在正中央。外圈是三種角色。彼此分工但會互相補位。

              ┌─────────────────────┐
              │   問題定義者          │
              │ 把模糊需求變成清楚規格 │
              └──────────┬──────────┘
                         │ 給指令
                         ▼
        ┌────────────────────────────────┐
        │         核心模型（生產主力）       │
        │   寫程式 / 查資料 / 擬草稿 / 整理   │
        └───────┬────────────────┬───────┘
                │ 交出產出         │ 交出產出
                ▼                ▼
   ┌──────────────────┐  ┌──────────────────┐
   │   品質驗收者        │  │   收尾上線者        │
   │ 看產出對不對、好不好 │  │ 把成品真正推到使用者 │
   └──────────────────┘  └──────────────────┘

這張圖裡最該注意的。是箭頭的方向。過去的編制。是人把活一層一層往下傳。產品經理交給工程師。工程師交給測試。現在不是。三種人都是直接面對中央那顆模型。問題定義者把規格餵進去。品質驗收者把產出抓出來檢查。收尾上線者把通過檢查的東西推出去。模型是所有人共同的工作對象。而不是某一條生產線上的某一站。理解了這個方向。你就會明白。為什麼這種團隊可以這麼小。因為中間那些「人傳給人」的環節。大半被模型吃掉了。

值得提醒的是。這三種角色雖然分工。但在小團隊裡常常需要互相補位。問題定義者在寫規格的當下。其實也在預想驗收的標準。收尾上線者把東西推出去之後。蒐集到的真實反饋。又會回頭變成下一輪問題定義的素材。三個角色不是三條互不相干的線。而是繞著中央模型轉的一個循環。這也是為什麼。這套編制最怕的不是人少。而是「少了某一個角色卻沒人發現」。最常被偷偷省略的。就是品質驗收。因為模型講得太流暢。產出看起來太完整。團隊很容易在沒人認真驗收的情況下。就把東西放出去。等到使用者踩到錯誤。才發現中央那顆模型。早就一本正經地把一個錯誤包裝得很漂亮。所以在排這三個角色時。寧可問題定義與收尾兼任。也千萬別讓驗收這一環掛空。

三、實作案例：一個三人小組做出一套內部工具

舉一個設想情境的例子。一家中型公司的營運部門。長期苦於一件事。每個月要手動整理好幾份報表。流程又雜又容易出錯。過去要解決這件事。得排隊等資訊部門有空。可能要等上好幾個月。這一次。部門主管決定自己組一個三人小組來做。而這三個人。沒有任何一位是傳統意義上的工程師。

第一位是熟悉業務的資深專員。她擔任問題定義者。負責把「報表到底要長什麼樣、哪些數字從哪來、什麼情況算錯」講得清清楚楚。第二位是部門裡細心、邏輯好的同事。他擔任品質驗收者。負責拿模型寫出來的程式與報表。一筆一筆對照真實資料。確認沒有算錯。第三位是主管自己。他擔任收尾上線者。負責處理權限、把工具放到大家都能用的地方、並為這套工具的結果負責。中央那顆模型。則包辦了寫程式、串接資料、產出報表初版的所有粗活。三個人花了大約兩個禮拜。做出了一套堪用的內部工具。把每個月好幾天的手工整理。壓縮成按一個鍵。這個案例裡。沒有人會被叫做工程師。但工程被完成了。

四、Prompt 範本：讓模型扮演團隊裡的工程角色

以模型為核心的團隊。最關鍵的技能。是把需求清楚地交代給模型。下面提供一個可以直接套用的 Prompt 範本。它的精神是。把模型當成一位坐在團隊中央、需要明確指令才能動工的工程角色。

【角色】
你是一位資深的全端工程師，擅長把模糊的業務需求，
轉成可執行的程式與清楚的技術方案。

【背景】
我們是一個沒有傳統工程師的小團隊。我負責定義問題，
另有同事負責驗收品質與收尾上線。你是團隊的生產主力。

【任務】
請根據以下需求，產出第一版的可行方案與程式：
（在這裡填入：要解決的問題、輸入是什麼、預期的輸出是什麼）

【限制】
一、若需求有任何不清楚之處，先列出你的疑問，不要自己假設。
二、產出時請標明：哪些是你有把握的、哪些是你猜測的。
三、用我們團隊看得懂的方式說明，不要堆砌艱深術語。

這個範本的重點。在於它逼著團隊把「問題定義者」這個角色做扎實。你會發現。當你被要求把背景、任務、限制一條條寫清楚。你其實是在替整個團隊釐清思緒。模型產出的好壞。九成取決於這份指令給得夠不夠清楚。這也正好呼應了第一段講的。在這種編制裡。人最大的價值。是把問題問對。而不是親手把答案寫出來。

五、導入 SOP：從一個小痛點開始試這套編制

想試這套以模型為核心的編制。不必一次全公司改組。建議的做法可以拆成五步。從一個小範圍開始。

第一步。挑一個明確、但又不致命的小痛點。最好是那種「大家都嫌麻煩、但出錯也不會出大事」的內部流程。拿它當第一塊試驗田。第二步。指派三個角色。問題定義者、品質驗收者、收尾上線者。這三個位置可以由兼任。但一定要有人明確扛起來。尤其是品質驗收。絕對不能省。第三步。讓問題定義者先把需求寫成清楚的指令。餵給模型。拿到第一版產出。第四步。由品質驗收者拿真實資料。逐項檢查模型的產出對不對。這一步是整套編制的命脈。模型很會講得頭頭是道。但它會出錯。沒有人驗收。等於把錯誤直接放給使用者。第五步。確認品質後。由收尾上線者把成品真正推出去。並持續觀察使用情況。再決定要不要調整。

跑完這一輪。團隊就會對這套編制有實感。也會清楚知道。哪些活模型扛得起。哪些判斷還是只能靠人。把這個小循環跑順了。再考慮把它複製到更大的專案上。

六、ROI 評估：少了工程師，省下的與多出來的

很多人看到「無傳統工程師」。直覺就是「省人事費」。這話只對了一半。要看清這套編制划不划算。該把它真正換掉的、與真正多出來的。一起放上桌面攤平了講。下表把這兩邊對照排出來。表內的數字與比例。皆為設想情境下的示意。請務必依自身團隊的實況重新估算。

把這張表攤開看。你會發現。這套編制省下的。主要是「執行的人力」。但它多出來的。是「判斷與把關的壓力」。過去工程師會幫你擋掉很多技術上的錯。現在那道防線。要由品質驗收者用人眼補回來。所以這套編制適不適合你。要問的不是「我能不能少請幾個工程師」。而是「我手上有沒有那少數幾個。問得出對問題、看得懂模型有沒有亂講、扛得起最後責任的人」。有這種人。這套編制會很省很快。沒有這種人。省下的人事費。遲早會用出錯的代價還回去。

❓ 讀完後，先問自己這幾個問題

如果把模型放進你團隊的正中央，你現在的成員裡，誰能勝任「問題定義」與「品質驗收」這兩個關鍵角色？

• 你手邊正在做的某個專案，有多少比例的工作，其實是模型已經能扛起的「執行」，而不是只有人能做的「判斷」？
• 在你的團隊裡，誰會被指定為某項產出「對不對」的最終把關者？這個責任現在有沒有人明確扛著？
• 如果模型某天一本正經地產出了一個錯誤，而它順利上線了，你的編制裡，哪一道關卡本來應該擋下它？

結語：消失的是職稱，不是工程

以模型為核心的團隊編制。聽起來像是在談「裁掉工程師」。但真正在發生的。其實是工程這件事被重新拆解。寫程式、查資料、擬草稿這些可以被模型接手的執行。漸漸從人的工作清單裡退場。而把問題定義清楚、判斷產出對不對、為結果負起責任這些事。反而被放大成團隊最稀缺的能力。所以消失的不是工程。是「工程師」這個固定職稱。以及它背後那套「一定要會敲程式碼才能參與」的舊假設。對想試這套編制的人來說。下一步不是急著去改組織圖。而是先在一個小專案裡。實際指派出問題定義者、品質驗收者、收尾上線者這三個角色。讓模型坐進中央跑一輪。你會很快感覺到。這套編制真正考驗的。從來不是技術。而是你身邊有沒有那幾個。問得對、看得準、扛得住的人。