Tenex 如何打造 AI 原生工程團隊——Alex Lieberman 與 CJ Hess 對談

Alex Lieberman 是應用 AI 顧問公司 Tenex 的共同創辦人。他主張，企業 AI 最難的問題不在於模型本身的智慧，而在於把 AI 擴散到大型組織裡的「最後一哩路」；而在這樣的世界裡，按產出而非工時付薪水給工程師，才是對的模式。本集主要談這套營運模式，以及 Tenex 在企業客戶內部看到的實況：一套以故事點（story point）計酬的制度，最高與最低收入者之間差距約 4 倍；一套「元框架（meta harness）」，把計畫與決策紀錄都簽入版本庫，讓代理（agent）能執行長時間任務；模型與 Token 支出的成本結構；以及企業 AI 採用的四階段地圖——走到最後，只有約 5% 的大型企業在生產環境中跑著非工程用途的代理。標題裡的「AI 原生工程團隊」是貫穿全場的主線，但節目有相當大的比重花在市場觀點上——對垂直 AI 新創的看空、對重建中階 SaaS 的辯論、以及人力重新配置——最後還討論了紐約與舊金山作為 AI 樞紐的差異。

與 Lieberman 對談的是 CJ Hess，Tenex 的工程總監，他自稱「特別專案負責人」，是公司第一位員工，負責內部的工程框架與平臺工作。Tenex 位於紐約，共 75 人，約 90% 是工程師或「AI 策略師」（技術顧問），客戶約一半是《財星》2000 大企業，一半是營收 1 億至 5 億美元的中階市場公司。讀者讀完應該能掌握：按產出計酬制度的運作機制與其極限、Tenex 從客戶對話中歸納出的具體採用統計，以及與談人彼此有爭議的市場判斷——那些是他們的觀點，不是既定事實。

按故事點付薪，差距是 4 倍，不是 10 倍

Tenex 的創立論點是：AI 是「對人的智力與工作倫理的槓桿押注」，所以賺錢能力應該比以往差距更大。成立 18 個月後，這套模式在方向上證明是對的，但離散程度比創辦人當初提議的小。Lieberman 說，Tenex 最高薪與最低薪工程師的差距「大概在 4 倍左右」，不是他先前上節目時談過的 10 倍。Hess 是第一位員工，他先前自己經營工程顧問公司，當時發現匯入 AI 工具後產出上升，但按小時計費卻壓住了他的收入；Lieberman 公開主張按產出而非工時給酬，吸引了他。

Lieberman 說，外界對按產出計酬的兩個經典質疑——故事點很主觀，以及工程師會刻意低報估計或交出未經檢查的程式碼——都沒有發生，因為 AI 策略師的獎勵綁在客戶留存與成長上，與工程師的利益「正好相反」。真正的摩擦在於沒有計酬的非寫程式時間：架構設計、客戶會議之類的工作。模式需要在這裡細緻化，但整體仍然「主要由產出驅動」。

Hess 補充，當模型只要給對上下文就能做到解決方案的約 90%，價值就轉移到：坐下來陪客戶、把腦中的東西完整挖出來、再餵給模型。他預期 Tenex 會走向評估產出的真實形狀，而不是傳統的故事點單位，但仍以故事點作為衡量基準。

簽入版本庫的「元框架」讓儲存庫成為代理的記憶

Tenex 把工程流程標準化成一套結構化檔案，放進每個儲存庫，再加上一個 CLI 讓模型用來推動工作——建立計畫、視覺化、客戶報告——於是寫程式周邊的流程會自動發生，且全團隊一致。Hess 描述一份有共通結構的標準計畫檔案，不過隨著模型進步，強製程度已經放寬。代理會記錄自己的決策與動作，所有東西都簽入 Git，而且越來越常是 HTML 的「繪本」而非 Markdown。

設計原則是：上下文絕不該只存在某人腦中或某段 Slack 對話裡。程式碼是一個真相來源；決策紀錄是另一個，記錄某個選擇為何做出、以及背後的上下文。Hess 承認有爭論認為既然程式碼本身就能當作程式庫的記憶，檔案是否還需要；他的結論很明確：需要。目標是持續把上下文推進同一個耐久的位置，讓更多工作由代理驅動，而不是什麼都得事先備齊。

Tenex 用「每位工程師每月平均故事點」來衡量這套框架是否有效。Hess 估計 2026 年產出大約翻了一倍，並把轉折點定在 12 月的一次模型發布，他稱之為「Opus 4.5 時刻」——模型開始能承接長時間執行的任務——一路到他現在所稱的 Opus 5.5。故事點的價值大約每季重新校準，Lieberman 主張理論上隨著模型進步應該有通縮——在獎勵產出與捕捉所創造的價值之間取得平衡。

Opus 5.5 讓多模型堆疊收斂成單一預設

Tenex 讓工程師自選工具，但辦公室已經收斂了。Hess 說「現在的主流就是 Opus 5.5」——快、便宜，而且涵蓋過去得依成本與能力拆成兩、三個模型的全方位任務。他大致上已經不用 Fable。Codex 仍用於電腦操作類的工作，更關鍵的是當審查者：以 Opus 當駕駛、Codex 當審查，兩者在同一臺機器上來回跑，「仍然能產出最好的結果」。

Hess 是 AMP 使用者，並指出 AMP 最近能掛接 Claude Code 訂閱是一大省錢關鍵，支出砍了約 80%。他看重 AMP 的雲端「orb」機制，因為能把工作從本機卸下，並支援跨模型流程——Opus 寫、另一個 orb 審。他試過雲端版 Claude Code 與 Claude Tag，發現它們適合團隊協作處理非技術任務，但無法複製他的本機配置。

| 工具 | 在 Tenex 的角色 | Hess 的評價 |
|---|---|---|
| Opus 5.5 | 預設駕駛模型 | 快、便宜、涵蓋全方位任務；取代了 2 至 3 個模型的堆疊 |
| Codex（Sol 6.1） | 審查者、電腦操作任務 | 與 Opus 在同一臺機器上配對時效果最好 |
| AMP | 主要介面、雲端 orb | 跨模型流程、離機執行，透過掛接訂閱省下約 80% 成本 |
| 雲端版 Claude Code／Claude Tag | 評估過 | 適合非技術協作，但比不上本機配置 |
| Fable | 大致棄用 | 「現在很多人就是預設不用它了」 |

Token 支出約為薪資的 1 至 2 倍，成本恐慌已經過去

被問到 Token 支出相對於人事支出的比例，Hess 估計 Tenex 的原始 Token 支出大約是 1:1 到 2:1——以主持人的框架來說算高，因為多數公司是每位員工 10 至 200 美元，AI 原生新創大約 1 倍，最積極的則在 5 至 10 倍。他沒有精確數字。在團隊一度倚賴 Astra 與 Fable（因為效果最好，儘管很貴）之後，成本隨著 Opus 5.5 大幅下降。

Lieberman 說，公司隨著人數成長確實曾經擔心成本，但他主張市場已經過了危險點。單一任務的成本在下降，今天個人要跑出傷本的支出，比六到八個月前難得多。他把這連到一個更大的問題：像 Micro One、Mercor、Handshake 這類資料授權公司，營收九成以上來自各家實驗室；如果企業成為核心的資料買家，他們就得微調自己的模型，而這只有在品質（不斷移動的前沿）或價格（Token 成本下降）上說得通時才成立。Hess 承認未來若有「Astra 6.5」或「Fable 5.5」又貴又是同級最佳，支出可能再被拉高，但他指出便宜的前沿競爭者——他舉 Muse Wonder 的發布為例——並主張許多有經濟價值的任務並不值得用聰明 10 倍的模型：「一個聰明 10 倍的模型，真的值得為了在試算表裡搬幾個儲存格付這個錢嗎？大概不值得。」

只有約 5% 的大型企業在生產環境跑非工程用途的代理

Lieberman 把企業 AI 採用描述成一場逐個里程碑的競賽，並說 AI Engineer 大會的聽眾聽到這些數字之低都很驚訝。在 Tenex 目前接觸的約 100 家企業中，約 90% 已向員工推行通用型 LLM（Claude 或 Codex）。訓練與賦能——他說這一塊始終沒得到應有的重視——約 60%。推行到工程組織的編碼代理「接近 50%」，遠低於多數人猜的 70–80%；許多企業要不是還沒部署，就是用的東西「與其說有編碼代理，不如說沒有」。

掉得最陡的是最後一階段：非工程工作的代理進入生產環境，只剩約 5%。員工超過 1,000 人的企業，多數在生產環境中沒有任何代理在做建軟體以外的工作。Lieberman 把這個落差歸因於：一小群人真正懂什麼是可能的，一大群人則是被 FOMO 推著走；這創造了動能，卻也讓買方緊抓著當下最流行的東西——所以年年都是「代理元年」，也所以最常見的需求就是替某個後勤任務做一個代理。

flowchart TD
    A["通用型 LLM 推行至員工 — 約 90%"] --> B["訓練與賦能 — 約 60%"]
    B --> C["工程組織內的編碼代理 — 約 50%"]
    C --> D["非工程工作的代理進入生產環境 — 約 5%"]

第二常見的需求是許可權管理與 RBAC。當每位員工都有 Claude 或 Codex，又需要存取特定資料，CIO 與 CISO 就面臨一場沒有好閘道的惡夢——「幾乎可以說是一個資料許可權的控制面板」。Tenex 起初替客戶打造客製閘道，後來把自己的閘道方案產品化。

Hess 補了一個流程上的警告：「你沒辦法自動化一個不存在的流程。」當 40 個人用略有不同的方式做大致相同的職能，要做一個主動式的背景代理就難得多。Tenex 常告訴客戶，先把流程標準化，再交給代理——沒有標準化，就無從建立評估，也無從知道代理有沒有做對。回報出現在代理把工作整理出來給人審閱、再送回去的時候，也就是大家都在談的「代理管理者」角色。

Tenex 看空垂直 AI 新創，但不看空專業化軟體

Lieberman 與 Hess 說，他們整體看空垂直特定領域的 AI 方案——給律師用的 Harvey、給醫生用的 Open Evidence——因為企業的細微差異、慣性與系統整合讓「一家一家量身打造」很難交付，也因為買方現在期待量身打造的軟體，這正是為什麼每家軟體公司都在組建前線部署工程團隊。Lieberman 的疑慮是：當每個客戶都要客製體驗，垂直業者還能不能賺到軟體毛利？以及前沿模型為什麼不會乾脆把他們吸收掉？

主持人反駁：這些公司有專屬的資料存取、為特定用途打造的介面與操作方式（他舉 Harvey 的 Tabular Review 與 Legora 為例），還有專注。他把他們比作 Bloomberg——同樣的市場資料別處也拿得到，但交易員一年付約 5 萬美元，因為大家都在用、資訊整合在一起、而且已經接進他們的工作流程。Lieberman 部分讓步，指出 Bloomberg 的社交屬（它的私訊功能）是真正的吸引力，並說面對職務專屬工具這麼大的需求，很難對其中任何一家看空。他把這個動態比作 Superhuman：給整天活在 email 裡的人用的高階客戶端，市場真實但有限。Hess 則劃下界線：如果一個垂直領域裡代理「就是」產品本身，又沒有策略性的資料或法遵護城河，他就不看好；圍繞著被改變的流程、上面再加一層代理的應用與工具，仍然可以成功。

重建中階 SaaS 在大型企業門檻以下才划算

主持人描述一個「Kill My SaaS」實驗：一套一年 4 萬美元的中階工具，用約 1,000 美元就替換掉，而且即將上線。Lieberman 的看法是，越往大型企業走，這個命題越難成立：他不認為 Salesforce 或 SAP 真的岌岌可危，因為一次失敗的全面替換所牽涉的金額——可能是數億甚至數十億美元——讓大公司極度風險趨避。對中階工具而言，問題在於獎賞夠不夠大，大到值得長期背負維護核心業務以外東西的認知負擔；軟體的價值，也包含你因為不擁有它而省下的所有麻煩。

他同意主持人的情況不同，因為那不只是防守成本，還是進攻：既有產品長期平庸，而客戶現在能在幾分鐘內、而非幾個月內，迭代出好 10 倍的版本。Tenex 自己就做過——從零打造自家的 CRM 與內部作業系統。Lieberman 懷疑企業會常態性地長出好 10 倍的 SaaS 版本，因為「我不覺得企業是那樣運作的」。

取代是真的，但 Tenex 賣的是重新配置

Hess 說他相信 AI 整體會帶來正面效益、強化工作，但也承認確實有取代——他引用 a16z 一篇談客服中心式微、AI 接手更多這類工作的文章，並說對那些職涯技能正被自動化的人而言，這是毀滅性的。Tenex 與客戶對話時，把代理部署框在重新配置上：哪些可以取代、接下來最大的問題是什麼。他主張大公司實質上有無限的需求、永遠有下一個問題，所以領域專家可以被拉離試算表，去跨團隊協作、處理更大的問題。

Lieberman 反對把取代講成「發生在」人身上的事，因為那剝奪了人的能動性。他主張重新技能化既是僱主的責任（為了推動成長），也是員工自己的責任；而「AI 會取代所有大家不喜歡的工作」某種程度上是自我安慰——很多人工作是為了賺錢，不是因為喜歡。人應該評估自己職務的可取代性，然後行動。

紐約是比較小的 AI 泡泡，坐在比較大的商業池塘上

Lieberman 形容舊金山無所不包——每個人「整天都在談代理」，辯論本能、Grok 或 Muse——而紐約的 AI 泡泡比較小，不過 Tenex 是舊金山的縮影，因為會自我選擇來這裡工作的人、以及合作的公司型別。他估計 AI Engineer 社群大約只佔紐約的 1%，並說目標是讓紐約成為 AI 樞紐，因為太多商業活動在這裡發生，這裡才是擴散能推動 GDP 的地方。他的說法是：「我在紐約做 AI 的原因，就是把舊金山的人帶來這裡見他們的客戶，順便面對現實」——在舊金山那種活在未來的文化與紐約的商業規模之間套利。他指出，這座城市的 AI 廣告看板現在已經毫不反諷，在那之前曾有一段塗鴉反彈期，他認為那有一部分是刻意引戰。

Tenex 正透過 tenex.co 招募前線部署工程師與 AI 策略師，公司位於紐約、共 75 人。Hess 的「特別專案」職務涵蓋客戶工作以外的一切：打造內部的元框架以探索模型能力的最前沿，以及把背景代理推進企業、解決前面談到的那些棘手 IT 問題的平臺。

值得持續追蹤的主線，是 Tenex 兩個押注之間的張力。它的計酬模式假設產出可以被衡量與獎勵，但它自己的主管也承認這個衡量需要每季重新校準，而且最有價值的工作——收集客戶上下文、架構設計、流程標準化——根本抗拒故事點。與此同時，採用階段圖顯示 Tenex 所服務的企業市場仍卡在編碼代理階段，真正能支撐「AI 轉型即服務」這個說法的非工程代理部署，只觸及約 5% 的大型企業。如果這個數字動起來，Lieberman 所描述的服務與軟體匯流就會成為成長故事；如果停滯，那些由 FOMO 驅動的後勤代理需求，可能就只是一次次專案，而不是可長可久的平臺生意。