編排 vs 員工框架：調和創辦人劇本與 HBR 問責證據

資料來源#

• Research: Why You Shouldn't Treat AI Agents Like Employees
• The Founder's Playbook: Building an AI-Native Startup

兩份來源，用它們自己的話說#

Anthropic 的 Founder's Playbook（AI-Native Startup Lifecycle，2026 年 5 月）將三個 Claude 介面定位為人力替代：

• 「對話式智慧與研究——每個領域的隨傳隨到專家」
• 「Agentic coding——永遠在線、永不阻塞的工程師」
• 「工作流自動化——隨需即用的自動化營運團隊」

隱含的運作心智模型：agents 是具有有限專長的同事，創辦人將工作委派給他們。「精實十人獨角獸」依賴於此——三個專業化 agents 取代三個職能專屬的雇員。

HBR Kropp/Bedard/Wiles/Hsu/Krayer 2026（AI Employee Framing，n=1,261 位 HR/財務經理，隨機化審閱任務）精確測試了這個框架。在其他條件完全相同的情況下，僅改變文件被框架為由 AI 工具 還是 AI 員工（有名字、在組織圖上）所起草：

結果	AI 員工 vs AI 工具
對產出的個人問責感	−9 pp
歸因於 AI 的問責	+8 pp
要求額外審閱（升級）的請求	+44%
發現的錯誤	−18%
採用意願	無顯著變化

兩份來源都未涉及對方的證據。 兩者均於同月由聲譽良好的機構發表，卻在如何框架 AI 部署上得出結構性相反的隱含結論。劇本未引用框架文獻；HBR 論文未處理獨立創辦人的使用情境。

為什麼不能簡單地說「它們在談不同的事」就解決#

天真的駁斥：「HBR 研究的是大型組織環境，員工將問責推卸給 AI；劇本針對的是獨立創辦人，下面沒有人可以推卸。」 這個駁斥因三個原因而失敗。

1. HBR 的效應出現在有真實 AI 員工經驗的子群體中（約 23% 的受訪者，AI 已在組織/工作圖表上的組織）——正是劇本正在招募進入的群體。劇本是讓更多組織將 AI 放上組織圖的行銷手冊。
2. HBR 識別的機制是認知負荷和語言驅動的，而非組織圖位置驅動的。 當同事稱 agent 為「Kevin」並開玩笑說「我們跟 Kevin 一起工作⋯⋯他有點無趣」，錯誤就變成了 Kevin 的錯誤，而非團隊在軟體產出上的錯誤。這個機制不需要使用者下方有層級——它需要的是一個名字和一個委派情境。獨立創辦人兩者都給了他們的 agents。
3. 劇本明確地擬人化（「永遠在線的工程師」、「自動化營運團隊」、「AI 作為施工團隊」）。這正是 HBR 實驗所測試反對的語言基底——無論使用者是管理團隊的 CEO 還是只管理自己的創辦人。

兩份來源實際上同意什麼#

儘管表面上有張力，兩者在五個點上趨同：

1. AI 作為勞動力倍增器是真實的。 HBR 不爭議生產力提升；他們爭議的是捕捉這些提升的框架。劇本以具體的營運術語描述這些提升。
2. 問責不能落在 AI 身上。 兩者都明確表達了這點。劇本：「創辦人保留只有創辦人能做的決策。」HBR：「AI 是軟體；它無法被問責。」
3. 管理行為，而非框架，預測採用。 HBR 顯示擬人化不會提升採用意願；提升採用的是管理者以身作則使用 AI。劇本在結構上與此一致——它展示創辦人在每個階段直接使用 AI。劇本實踐了 HBR 為採用所開出的處方；只是用擬人化語言來描述它。
4. 工作重新設計比工具更重要。 劇本的「設計要系統化什麼」/「釋放創辦人注意力用於只有創辦人能做的決策」是 HBR「為工作流設計 agentic 單元，而非為人類角色設計」的獨立創辦人版本。
5. 錯誤面是真實的。 劇本透過 Agentic Technical Debt、Zero-Friction Scope Creep 和「agentic coding 產出功能性程式碼，但不一定是安全的程式碼」來標記它。HBR 透過 −18% 錯誤發現率和 brain fry 來標記它。不同的詞彙，相同的觀察：人類審閱 AI 產出的表現比他們自認的更差。

實際的分歧很窄：在描述創辦人如何與 AI 協作時，該怎麼稱呼 AI。

調和：有編排而無員工#

如果你將劇本混為一談的兩件事分開，劇本的處方就能經受 HBR 的批判：

1. 編排作為工作流設計。 多個專業化 agents、定義好的交接、創辦人導向的任務分派、有界的行動面、明確的成功標準。這是多 agent 系統的軟體架構。它在結構上是一個工具框架，具有多個工具和一個在其上方的編排層。
2. 編排作為 agents-as-coworkers 的心智模型。 為 agents 命名、歸因意圖（「Kevin 有點無趣」）、指派組織圖位置、將其產出視為委派工作而非工具產出。這是 HBR 實驗所測試反對的框架，也是產生 −9pp / +44% / −18% 效應的框架。

劇本的生命週期結構——Idea / MVP / Launch / Scale，每個階段壓縮過去需要人力的工作——在 (1) 下運作。它不需要 (2)。「永遠在線的工程師」措辭是行銷上有用的隱喻；底層的營運模式是「創辦人針對定義好的範圍執行 Claude Code session」。

對劇本的紀律性閱讀： 將每個「AI 作為 [職稱]」的框架視為你正在設計的工作流，而非你正在雇用的同事。具體來說：

劇本框架	工作流翻譯
「永遠在線的工程師」	「我將針對 CLAUDE.md 中定義的範圍任務執行 Claude Code sessions，審閱每個 session 的 diff」
「每個領域的隨傳隨到專家」	「我將以研究夥伴模式查詢 Claude，將產出視為多個輸入之一，並明確使用魔鬼代言人提示」
「自動化營運團隊」	「我將配置 Cowork 搭配範圍化的 MCP 整合、定義好的升級閾值和每週稽核檢查點」
「建造你事業的施工團隊」	「我將設計具有交接、成功標準和審閱關卡的多 agent 工作流」

每一行都保留了劇本的生產力故事，同時去除了框架病理。

HBR 的證據要求劇本讀者無論如何都要做的事#

即使剝除了員工框架，HBR 的實證發現暗示了五個劇本未明確開出的實踐。紀律型創辦人應該加上它們：

1. 每個工作流的問責檢查點#

對於每個 agent 執行的工作流，指名創辦人親自審閱哪個步驟。Agent 透過 Gmail MCP 執行了客戶外展；創辦人在發送前審閱聯絡名單，每天審閱回覆串。沒有這個，auto-mode 風格的分類器是唯一的防線，而它們並非設計來捕捉商業邏輯錯誤的。

2. 注意「Kevin」命名漂移#

HBR 的機制在人們開始稱 agent 為名字、開玩笑說它的個性、並賦予它身份時啟動。如果你發現自己對 Cowork 實例或 Claude Code session 這樣做，請稽核：

• 我的錯誤發現率是否下降了？
• 我是否發送了比我審閱的更多工作給 agent？
• 我是否開始將 agent 的產出視為權威而非暫定的？

你第一次說「讓 Kevin 處理」而未指定範圍時，你就已經跨入了 HBR 效應所測量的框架。

3. 考慮 brain fry 的監督預算#

AI Brain Fry 是審閱 AI 產出的認知負荷成本。Kropp 等人的先前論文測量了 brain fry 導致 11–39% 的錯誤增加。對獨立創辦人而言，這比對經理人更嚴重，而非更輕：

• 經理人監督 5 個人類 → AI 讓他們監督 5 個人類 + 每天 50 個 agent 產出
• 獨立創辦人起初監督 0 個人類 + 0 個 agents → AI 讓他們監督每天 50 個 agent 產出

認知負荷相當，但創辦人缺乏經理人擁有的監督基礎設施。實際意涵：精實十人獨角獸的主張暗示了劇本未預算的認知工作量。一位跨四個生命週期階段同時執行 5 個平行 Claude Code sessions 的創辦人，比擁有相同 agent 數量的 50 人組織更快接近 brain fry 閾值。

緩解措施：

• 有界的平行度（Cat Wu 的「簡單設置效果更好」；Claude Code Best Practices 明確警告過度客製化的工作流）
• 基於抽樣的審閱而非逐一審閱
• 高風險審閱集中（安全性、面向客戶的通訊、任何影響營收或信任的事物）

4. 包含錯誤捕捉的績效指標，而非僅有吞吐量#

劇本的退出標準是產出導向的（留存、營收、成長）。HBR 的處方將監督品質納入績效維度。對創辦人而言，這轉化為自我稽核指標：觸及客戶的 AI 產出中，我實際審閱了多少比例？ 如果這低於某個閾值（劇本未給出數字；HBR 的數據暗示這很重要），生產力提升正在以未偵測到的錯誤為代價。

5. 整合層的決策權閘控#

MCP and Computer Use 是行動面。劇本開出在所有四個階段透過 MCP 連接 Gmail、Calendar、Drive、Salesforce、內部 CRM 的處方。每個連接都擴展了 agent 的觸及範圍。HBR 的「決策權」子前線就是治理這個的：

• Agent 透過 MCP 自主做什麼？（讀取收件匣、起草、排程）
• 什麼需要明確批准？（發送電子郵件、提交程式碼到 main、向客戶收費、修改 HR 記錄）
• 什麼是禁止的？（跨越客戶資料邊界、聯繫受監管人員）

沒有這個閘控，劇本的 MCP 豐富工作流就是隨意部署中的 Agentic Misalignment (AM) 行動面。Human-AI Accountability Redesign 的五支柱框架縮減為一位創辦人，但工作不會消失。

劇本實際上正確而 HBR 框架不完整之處#

HBR 的論文對其狹窄主張是嚴謹的：在其他條件不變的情況下，僅框架就會改變結果。 但它是在風格化的審閱任務中研究的，而非在生產環境的獨立創辦人工作流中。兩個劇本側的觀察反駁了 HBR 處方的普遍性：

1. 31% 已將 AI 框架為隊友的領導者並非全都錯了。 HBR 識別了效應但未主張應廢除框架。一個有用的解讀：擬人化是一種啟發式方法，以問責漂移為代價降低多 agent 推理的認知成本。 對於在不確定性下快速決策的獨立創辦人，這個啟發式方法可能淨值為正——如果他們有紀律在高風險決策時覆蓋它。
2. 劇本的框架也是針對 HBR 研究未抽樣群體的招募語言。 HBR 抽樣的是已在既有組織中的經理/總監/高管。劇本招募的是獨立創辦人，許多是非技術背景，讓他們建造以前無法建造的軟體。那個群體的基線不是「校準良好的 AI 產出審閱者」；而是「根本無法出貨的人」。部分生產力解鎖需要擬人化框架才能開始。

正確的解讀：框架有真實成本（HBR 對幅度的判斷是正確的）；框架也有准入價值（劇本對誰新成為建造者的判斷是正確的）。紀律型創辦人使用框架來起步，然後隨著工作成熟升級到工具模式的問責紀律。

誠實的未解決張力#

三個地方綜合未能乾淨地解決：

1. Anthropic 同時發表兩種框架。 同一家公司在自己的產品線中發表 HBR 意識的問責工作（auto-mode 分類器、Claude's Constitution / Model Spec 對齊工作、Model Spec Midtraining），同時在面向創辦人的行銷中銷售「永遠在線的工程師」框架。這不是 Anthropic 處理的矛盾——劇本根本未涉及框架文獻，即使 Anthropic 發表了相鄰的對齊和行為研究。
2. 「精實十人獨角獸」主張在 2026 年 5 月是不可證偽的。 沒有已發表的 AI 原生新創 vs 先前世代在 PMF 時的人力數據。HBR 測量的效應是真實的；劇本的生產力主張是軼事性的。證據品質的不對稱應偏向 HBR 的紀律，但實際上劇本會觸及更多創辦人。
3. Brain fry 作為獨立創辦人失敗模式是未知領域。 HBR/Kropp 等人的先前論文測量的是有經理人的員工的 brain fry。獨立創辦人版本——執行多個平行 agent sessions 且無同儕審閱——可能更嚴重、更輕微、或質性上不同。沒有研究存在。這是真實的數據缺口。

紀律型創辦人的操作清單#

透過 HBR 的鏡頭閱讀劇本，以下實踐保留了劇本的生命週期結構，同時去除了框架病理：

• Idea 階段： 明確調用魔鬼代言人提示；將 AI 產出視為來源之一而非唯一來源；記錄假設為何經受住 AI 批判，而非僅記錄它們經受住了。
• MVP 階段： CLAUDE.md 是給程式碼庫的，不是給 agent 的身份的。抵制為 agent 命名或客製化人格。在安全性、支付和客戶資料邊界維持明確的審閱關卡。使用 auto-mode 作為決策權閘控，而非自主權委派。
• Launch 階段： 在將任何營運工作流委派給 Cowork 之前，將工作流寫成程式碼（或工作流配置）。寫下它的行為保留了工具框架；說「Cowork 處理 X」而無規格的行為則滑向員工框架。
• Scale 階段： Compounding Data Moat 是真實的且與 HBR 相容（它關於將創辦人判斷編碼進基底）。問責重新設計是必要的：企業客戶會稽核你的決策權模型。從一開始就建立這個比事後改造便宜。
• 跨所有階段： 測量 AI 產出的錯誤捕捉率。將下降視為 brain fry 或框架漂移的領先指標。將平行 sessions 上限設在你實際能審閱的水準。

相關連結#

• 來源概念文章：
• AI-Native Startup Lifecycle — 劇本的結構性重新框架
• Founder as Agent Orchestrator — 本綜合所治理的角色轉變
• Compounding Data Moat — 本綜合所保留的 Scale 階段護城河
• AI Employee Framing — HBR 的實驗證據
• AI Brain Fry — 認知成本機制
• Human-AI Accountability Redesign — HBR 的五支柱框架
• 中介概念：
• MCP and Computer Use — 需要決策權治理的整合基底
• Claude Code Auto Mode — 工具層級的 auto-approve-safe/block-risky 模式
• Engineer PM Convergence — Anthropic 內部的類似角色轉變
• Harness Shrinkage as Models Improve — 什麼縮減 vs 什麼不縮減（監督留下）
• Evals as Product Spec — 錯誤捕捉轉化為可執行的產物
• 伴隨衍生：
• Opinions on Using AI Tools & the Future of the Software Engineering Role — 涵蓋看多內部人 vs 懷疑治理立場的辯論地圖版本
• Learning to Co-Work with AI: A Software Engineer's Field Guide — 工程師側的規範性伴隨文章

資料來源#

• The Founder's Playbook: Building an AI-Native Startup — Anthropic, The Founder's Playbook: Building an AI-Native Startup, May 2026
• Research: Why You Shouldn't Treat AI Agents Like Employees — HBR, Kropp/Bedard/Wiles/Hsu/Krayer, May 2026 (referenced working paper: emmawiles.github.io/storage/ai_employee.pdf)
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — internal Anthropic operating norms relevant to the synthesis (Anthropic itself practices tool framing internally even while marketing employee framing externally)