編排與員工框架：調和創辦人手冊與 HBR 的問責證據

資料來源#

兩份來源各自的說法#

Anthropic 的《創辦人手冊》（AI-Native Startup Lifecycle，2026 年 5 月）將三種 Claude 介面定位為可取代人力的工具：

「對話式智慧與研究——隨時待命、涵蓋所有領域的專家」
「代理式程式設計——隨時可用、永遠不會卡住的工程師」
「工作流程自動化——隨需啟用的自動化營運團隊」

其中隱含的運作心智模型是：代理程式是各有專長的同事，創辦人可以把工作委派給他們。「精簡的 10 人獨角獸公司」仰賴這個想法——三個專門代理程式取代三個職能各異的職缺。

HBR 的 Kropp、Bedard、Wiles、Hsu、Krayer 於 2026 年進行的研究（AI Employee Framing，招募 1,261 位人資與財務經理，並以隨機方式分派審查任務）恰好測試了這種框架。在其他條件相同時，只改變文件被描述為由 AI 工具 或 AI 員工（有名字、列在組織圖上）起草：

結果	AI 員工相較於 AI 工具
個人對產出的問責感	−9 個百分點
歸因於 AI 的問責責任	+8 個百分點
要求額外審查（升級處理）	+44%
找出的錯誤	−18%
採用意願	沒有顯著變化

兩份來源都沒有討論對方的證據。 兩者同月由可信機構發表，對於如何描述 AI 部署，隱含結論在結構上卻截然相反。《手冊》沒有引用框架研究；HBR 論文則沒有討論單人創辦人的情境。

為什麼不能輕易用「他們談的是不同事情」帶過#

天真的駁斥會說：「HBR 研究大型組織，員工會把問責責任推給 AI；《手冊》談的是單人創辦人，底下沒有人可把責任推給對方。」 這種說法有三個問題。

HBR 的效果出現在真正接觸過 AI 員工的子群體中（約占受訪者 23%，所在組織已把 AI 列入組織圖或工作表）——這正是《手冊》想吸引加入的族群。《手冊》是鼓勵更多組織把 AI 列入組織圖的行銷手冊。
HBR 指出的機制由認知負荷與語言驅動，而非組織圖上的職位。 同事開始稱代理程式為「Kevin」，開玩笑說「我們正在和 Kevin 合作……他有點無趣」時，錯誤便成了 Kevin 的失誤，而不是 團隊使用軟體產出時的失誤。這種機制不需要使用者底下有層級；它需要的是 名字與委派工作的情境。單人創辦人兩者都會給代理程式。
《手冊》明確採用擬人化說法（「隨時待命的工程師」、「自動化營運團隊」、「AI 就像施工團隊」）。這正是 HBR 實驗所檢驗的語言基礎——無論使用者是管理團隊的執行長，還是只管理自己的創辦人，都一樣。

兩份來源實際上都認同什麼#

表面上彼此緊張，但兩者在五點上相當一致：

AI 能放大勞動力效能。 HBR 沒有否認生產力提升，只質疑用來描述這些提升的框架。《手冊》則以具體的營運方式描述這些增益。
問責責任不能落在 AI 身上。 兩份來源都明確指出這一點。《手冊》寫道：「創辦人保留只有創辦人才能做的決策。」HBR 則說：「AI 是軟體，不能被追究責任。」
採用與否取決於管理者的行為，而非框架。 HBR 顯示，擬人化不會提高採用意願；真正提升採用意願的是 管理者以身作則使用 AI。《手冊》的架構與此一致——它展示創辦人在每個階段都直接使用 AI。《手冊》實踐了 HBR 對促進採用的建議，只是以擬人化語言描述這種做法。
重新設計工作比挑選工具更重要。 《手冊》提倡「設計哪些工作要系統化」以及「讓創辦人能把注意力留給只有創辦人才能做的決策」；這是單人創辦人版本的 HBR 主張：「依照工作流程設計代理式單位，而非依照人類職務設計。」
錯誤風險確實存在。 《手冊》透過 Agentic Technical Debt、Zero-Friction Scope Creep，以及「代理式程式設計產出的是能運作的程式碼，不代表程式碼本質上安全」來提醒。HBR 則以錯誤發現率下降 18% 和腦力耗竭指出這點。用詞不同，觀察相同：人類審查 AI 產出的表現比自己以為的更差。

真正的歧見很有限：描述創辦人如何與 AI 合作時，要怎麼稱呼 AI。

調和之道：採用編排，不採用員工框架#

只要把《手冊》混為一談的兩件事分開，它的建議就經得起 HBR 的批評：

把編排視為工作流程設計。 多個專門代理程式、明確的交接、由創辦人指派任務、界定行動範圍、清楚的成功標準。這是多代理程式系統的軟體架構，本質上仍是工具框架：多種工具上方有一層編排層。
把編排視為「代理程式是共同工作者」的心智模型。 為代理程式取名、把意圖歸給它（「Kevin 有點無趣」）、安排組織圖上的職位，並把其產出視為委派工作，而非工具產出。這是 HBR 實驗所檢驗的框架，也會帶來 −9 個百分點、+44%、−18% 的效果。

《手冊》的生命週期架構——構想、MVP、推出、擴大，每個階段都壓縮過去需要人力才能完成的工作——採用第 (1) 點仍然行得通，並不需要第 (2) 點。「隨時待命的工程師」是有助行銷的比喻；底層的實務模式其實是「創辦人啟動一個 Claude Code 工作階段，並指定清楚的工作範圍。」

謹慎閱讀《手冊》的方式： 每種「AI 是某種[職稱]」的說法，都應視為你正在設計的工作流程，而不是你正在聘用的同事。具體來說：

《手冊》的說法	工作流程轉譯
「隨時待命的工程師」	「我會依據 CLAUDE.md 定義的明確任務範圍執行 Claude Code 工作階段，並審查每個工作階段的差異」
「涵蓋所有領域的隨叫隨到專家」	「我會以研究夥伴模式向 Claude 提問，把產出視為多項輸入之一，並明確要求它扮演唱反調者」
「自動化營運團隊」	「我會為 Cowork 設定範圍明確的 MCP 整合、定義升級處理門檻，並安排每週稽核檢查點」
「打造你事業的施工團隊」	「我會設計多代理程式工作流程，設定交接方式、成功標準和審查關卡」

每一列都保留了《手冊》描繪的生產力效益，同時去除有問題的框架。

HBR 的證據仍要求《手冊》讀者採取的做法#

即使移除員工框架，HBR 的實證結果仍意味著《手冊》沒有明確建議的五項做法。謹慎自律的創辦人應將它們納入：

1. 在每個工作流程設置問責檢查點#

對每個由代理程式執行的工作流程，明確指出創辦人親自審查哪個步驟。代理程式透過 Gmail MCP 執行客戶聯繫流程；創辦人在寄送前審查聯絡人清單，並每天查看回覆串。如果沒有這些檢查，自動模式類型的分類器就是唯一防線，而它們並非為了找出商業邏輯錯誤而設計。

2. 留意「Kevin」式稱呼的偏移#

一旦人們開始用名字稱呼代理程式、拿它的個性開玩笑、替它指派身分，HBR 指出的機制就會啟動。如果你發現自己用這種方式對待 Cowork 執行個體或 Claude Code 工作階段，請稽核：

我發現錯誤的比例是否下降？
我交給代理程式的工作是否多於我審查的工作？
我是否開始把代理程式的產出視為權威定論，而非暫定結果？

第一次不指定範圍就說「讓 Kevin 處理吧」，你就跨入了 HBR 研究所衡量的框架效應範圍。

3. 將腦力耗竭納入監督工作量預算#

AI 腦力耗竭是審查 AI 產出所造成的認知負荷成本。Kropp 等人的前一篇論文測得腦力耗竭會讓錯誤增加 11–39%。對單人創辦人來說，這個問題更嚴重，而非較輕：

經理監督 5 個人 → AI 讓他們能監督 5 個人，加上每天 50 項代理程式產出
單人創辦人一開始監督 0 個人、0 個代理程式 → AI 讓他們每天監督 50 項代理程式產出

認知負荷相近，但創辦人缺少經理擁有的監督基礎設施。實務上的意涵是：「精簡的 10 人獨角獸公司」這項主張，代表創辦人要承受《手冊》沒有納入預算的認知工作量。一位在四個生命週期階段中同時執行 5 個 Claude Code 工作階段的創辦人，比起代理程式數量相同、但有 50 人的組織，更快接近腦力耗竭門檻。

緩解方式：

限制平行工作量（Cat Wu 說「簡單的設定效果更好」；Claude Code Best Practices明確提醒不要把工作流程客製化過頭）
以抽樣方式審查，而非審查每一項產出
集中審查高風險事項（安全性、面向客戶的溝通，以及任何影響營收或信任的事項）

4. 績效指標納入錯誤發現，而非只看產出量#

《手冊》的階段出口標準著重產出（留存率、營收、成長）。HBR 的建議則把監督品質列為績效面向。對創辦人而言，這代表要自我稽核一項指標：送到客戶手上的 AI 產出中，有多少比例是我實際審查過的？ 如果這個比例低於某個門檻（《手冊》沒有給出數字；HBR 的資料顯示它確實重要），那麼生產力的提升就是以未被發現的錯誤為代價。

5. 在整合層設定決策權限關卡#

MCP 與電腦操作構成行動介面。《手冊》建議在四個階段透過 MCP 串接 Gmail、Calendar、Drive、Salesforce 和內部 CRM。每個連線都擴大了代理程式的觸及範圍。HBR 提出的「決策權」子項正是治理這些連線的框架：

代理程式可以透過 MCP 自主執行哪些操作？（讀取收件匣、撰寫草稿、排程）
哪些操作需要明確核准？（寄送電子郵件、將程式碼提交至 main、向客戶收費、更改人資記錄）
哪些操作禁止執行？（跨越客戶資料邊界、聯絡受監管的對象）

若缺少這些關卡，《手冊》中充滿 MCP 整合的工作流程，在隨意部署時就會成為 Agentic Misalignment (AM)的行動介面。Human-AI Accountability Redesign的五支柱框架或許會簡化成一位創辦人，但工作不會因此消失。

《手冊》確實有理之處，以及 HBR 框架不完整之處#

HBR 論文嚴謹地處理了它的狹義主張：在其他條件相同時，光是描述框架就會改變結果。 但研究採用的是刻意簡化的審查任務，而非實際運作中的單人創辦人工作流程。《手冊》提出兩項觀察，對 HBR 建議的普遍適用性有所保留：

已經把 AI 當成隊友的領導者占 31%，不代表他們全都錯了。 HBR 指出框架帶來的影響，卻沒有主張應完全廢除這種框架。一種有用的理解是：擬人化是一種啟發法，能降低多代理程式推理的認知成本，代價則是問責責任逐漸偏移。 對於在不確定情況下迅速做決策的單人創辦人，這套啟發法的淨效益或許為正——前提是他們有自律能力，在高風險決策上推翻它。
《手冊》的框架也具有招募作用，能吸引 HBR 研究沒有抽樣到的族群。 HBR 抽樣的是已在成熟組織中的經理、主管和高階主管。《手冊》則在招募單人創辦人，其中許多人不懂技術，鼓勵他們打造過去無法打造的軟體。這些人的起點並非「能妥善校準 AI 產出的審查者」，而是「原本根本無法推出產品的人」。要讓這群人開始行動，有些生產力突破確實需要仰賴擬人化框架。

合理的解讀是：框架確實有成本（HBR 對影響程度的判斷是正確的），也確實能降低入門門檻（《手冊》對新加入開發行列者的觀察是正確的）。謹慎自律的創辦人可以先用這套框架開始，再隨著工作成熟，升級為以工具模式為基礎的問責紀律。

尚未解決的矛盾#

綜合分析仍無法妥善解決三處矛盾：

Anthropic 同時發布了兩種框架。 同一家公司在自家產品線上發布與 HBR 問責研究相呼應的工作（自動模式分類器、Claude's Constitution / Model Spec對齊工作、Model Spec Midtraining (MSM)），同時又在面向創辦人的行銷中銷售「隨時待命的工程師」框架。Anthropic 沒有處理這個矛盾——《手冊》完全沒有討論相關框架研究，儘管 Anthropic 自己也發布了相近的對齊與行為研究。
2026 年 5 月的「精簡 10 人獨角獸公司」主張無從證偽。 尚無公開資料能比較 AI 原生新創公司與先前世代在達到產品市場契合時的人數。HBR 衡量的效果確實存在；《手冊》的生產力主張則是軼事。證據品質的不對稱，應使判斷偏向採納 HBR 的紀律要求；但實務上，《手冊》會觸及更多創辦人。
單人創辦人的腦力耗竭失敗模式仍是一片未知。 HBR／Kropp 等人的前一篇論文研究的是有經理監督的員工。單人創辦人的版本——在沒有同儕審查下同時執行許多平行代理程式工作階段——可能更嚴重、較不嚴重，或本質上不同。目前沒有相關研究，這是實際存在的資料缺口。

謹慎自律的創辦人實務清單#

從 HBR 的角度閱讀《手冊》，下列做法能保留其生命週期架構，同時去除有問題的框架：

構想階段： 明確要求 AI 扮演唱反調者；把 AI 產出視為多個來源之一，而非唯一來源；記錄假設為何經過 AI 批判後仍站得住腳，而非只記錄它們確實留下來了。
MVP 階段： CLAUDE.md 是給程式碼庫看的，不是用來設定代理程式身分。避免替代理程式取名或客製化人格。在安全性、付款和客戶資料邊界設置明確的審查關卡。把自動模式用作決策權限關卡，而非委派自主權。
推出階段： 把任何營運工作流程委派給 Cowork 前，先將工作流程寫成程式碼（或工作流程設定檔）。撰寫流程能維持工具框架；不寫規格就說「Cowork 會處理 X」，則會滑向員工框架。
擴大階段： Compounding Data Moat確實存在，也與 HBR 的觀點相容（它關乎將創辦人的判斷力編碼進底層系統）。問責責任重新設計不可或缺：企業客戶會稽核你的決策權限模型。從一開始就建置好，比日後再補上更省成本。
所有階段皆適用： 衡量 AI 產出的錯誤發現率。把比率下降視為腦力耗竭或框架偏移的先行指標。將平行工作階段數量限制在你實際能審查的範圍內。

延伸連結#

來源概念文章：
AI-Native Startup Lifecycle — 《手冊》的結構性重構
Founder as Agent Orchestrator — 本綜合分析所探討的角色轉變
Compounding Data Moat — 本綜合分析保留的擴大階段護城河
AI Employee Framing — HBR 的實驗證據
AI Brain Fry — 認知成本機制
Human-AI Accountability Redesign — HBR 的五支柱框架
中介概念：
MCP and Computer Use — 需要決策權治理的整合基礎
Claude Code Auto Mode — 在工具層自動核准安全操作、封鎖風險操作的模式
Engineer PM Convergence — Anthropic 內部類似的角色轉變
Harness Shrinkage as Models Improve — 哪些會縮減、哪些不會（監督仍不可少）
Evals as Product Spec — 將錯誤發現轉化成可執行的成品
衍生配套文章：
Opinions on Using AI Tools & the Future of the Software Engineering Role — 涵蓋樂觀的業界內部人士與治理懷疑論者立場的爭論地圖版本
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》，2026 年 5 月
Research: Why You Shouldn’t Treat AI Agents Like Employees — HBR，Kropp、Bedard、Wiles、Hsu、Krayer，2026 年 5 月（引用的工作論文：emmawiles.github.io/storage/ai_employee.pdf）
How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — 與本綜合分析相關的 Anthropic 內部運作規範（Anthropic 自己在內部實踐工具框架，同時對外行銷員工框架）