刀匠的意圖
最近社群上看到不少人在轉貼 Anthropic 五月初發布的《The Founder’s Playbook: Building an AI-Native Startup》（AI 原生新創實戰手冊），甚至已經有人做出中文翻譯版本了。大部分討論都集中在「這份文件教了什麼」——每個創業階段該用什麼工具、怎麼寫 CLAUDE.md、怎麼做安全性審查之類的。
不過我比較好奇的，是另一件事：它沒說出口的部分。
這就像你拿到一把造型講究的名刀，賣刀的人跟你說「這把適合切肉、那把適合片魚」，大多數人聽完就照著用了，也不會多想什麼。但如果你碰巧跟鍛刀的師傅聊過，知道他為什麼這裡要收窄、那裡要加厚、刀背為什麼留了這個角度——回來再看同一把刀，感覺完全不一樣。
你會發現它能做的事其實比行銷文案告訴你的多得多，但同時也有些你以為理所當然的用法，其實正在違反它的結構硬切。繼續這樣搞下去，遲早崩口。
Anthropic 就是那個鍛刀的師傅。而這份 Playbook，與其說是使用手冊，不如說是一份半遮半掩的鍛造筆記。
所以今天我們不聊創業，我們來聊：從這份鍛造筆記裡，能讀出什麼製造者的設計意圖？
同一塊鋼，三把刀
整份文件裡面藏了一句看起來不起眼的話，但其實是理解整個 Claude 產品線的鑰匙：
“The three share the same Claude underneath; what changes is the workspace around it.”
（三者底下跑的是同一個 Claude；差別在於圍繞它的工作空間不同。）
簡單來說：Chat、Claude Cowork、Claude Code，底下的引擎是同一顆。
差別不在引擎，在車殼。
咦！？等等——這意思是說，我們在三個產品上感受到的能力差異，不是因為模型不同，而是 Anthropic 刻意在同一個模型外面，包了三套不同的邊界設計？
對，就是這樣。
那問題就有趣了：這三套邊界，各自的設計意圖到底是什麼？
我們一個一個來拆。
Chat：被設計成「不動手」的思考夥伴
Playbook 裡有一張產品對照表，把 Chat 的定位寫得很清楚：
| 如果任務是… | 用這個 | 原因 |
|---|---|---|
| 一個問題、一次改寫、一場快速腦力激盪 | Chat | 快速、對話式、不需要設定 |
「不需要設定」這四個字，就是關鍵。
Chat 不能碰你的檔案系統、不能連你的 Google Drive、不能排程、不能執行程式。這些「不能」，並不是「功能還沒做」或「之後版本會加」——這是刻意的設計選擇。
從鍛造者的角度想想看：對話場景的信任成本是最低的。你問一個問題，AI 回答，你看完覺得有道理就採用、覺得不對就忽略。整個過程裡，AI 的「行動半徑」接近零——它只能輸出文字給你看，不能替你做任何事情。
也因此出錯的後果同樣接近零。它給你一個爛建議？你不採用就好了。它不會在你不知情的情況下跑去改你的程式碼、發你的 email、或是動你的檔案。
所以 Chat 的設計哲學是：最大限度的思考自由，最小限度的行動權限。
你回頭看 Playbook 裡建議用 Chat 來做的事——假設壓力測試、devil’s advocate（魔鬼代言人）、solution concept（解決方案概念）設計——全部都是「想」的工作，不是「做」的工作。Anthropic 顯然認為，在純粹思考的場景裡，AI 不需要碰任何外部系統。
（想想也是，你找朋友喝咖啡聊創業點子，你不會順便把公司信用卡交給他保管吧… XD）
Cowork：有圍牆的自主權
到了 Cowork，畫風突然一變。Playbook 裡的描述是：
| 如果任務是… | 用這個 | 原因 |
|---|---|---|
| 研究、分析、或從你的檔案和系統產出成品文件 | Claude Cowork | 資料夾存取、連接器、技能、排程執行 |
欸等等，關鍵詞一下子多了好幾個：資料夾存取、連接器（MCP）、排程執行。
剛才 Chat 連你的 Google Drive 都不能碰，Cowork 不但能碰，還能接 Gmail、Google Calendar，甚至能設定排程讓它自己定時跑！同一個模型，行動半徑直接從「零」跳到「能碰你的數位生活」。
這差距也太大了吧（驚!!!）
但是——注意 Playbook 怎麼描述 Cowork 的實際使用場景。它舉的例子包括：
- 把一整個資料夾的客戶訪談逐字稿轉成主題分析文件
- 從十幾個供應商網站建立競爭格局分析
- 每週一早上自動從你連接的工具拉數據，丟出一份 KPI 週報
每一個例子都有一個共同特徵：Cowork 能做什麼事，取決於你事先授權它連接哪些系統。
它不是什麼都能碰，而是你打開哪扇門，它才能進哪個房間。你沒開門的地方？門鎖得死死的。
這就是一種「有限代理權」的設計——你劃定邊界，它在邊界內自主運作。
用 RPG 來比喻的話，Chat 是那個只能在城鎮裡跟你聊天的 NPC，Cowork 是你派出去跑腿的隊友——但他只能去你事先解鎖的副本區域，沒解鎖的地圖他進不去。
Cowork 的設計哲學是：用連接器框定信任範圍，在範圍內給予行動自主權。
這跟 Chat 是完全不同的信任模型。Chat 說「我只提供想法，你自己決定要不要聽」。Cowork 說「你先告訴我你信任我碰什麼，然後我在那個範圍內把事情幫你做完」。
Code：最大自由度，但規矩你自己寫
然後是 Claude Code。Playbook 的描述：
| 如果任務是… | 用這個 | 原因 |
|---|---|---|
| 撰寫、測試或交付軟體 | Claude Code | 程式碼庫存取、差異比對、git、開發環境 |
直接存取 codebase、可以跑 git 操作、能在本地或雲端開發環境裡直接動手。
三個產品裡面行動半徑最大的——它能讀你的程式碼、改你的程式碼、跑你的測試、幫你 commit。技術能力這一塊，Claude Code 基本上是全開的。
但 Playbook 在講 Code 的時候，花了大量篇幅反覆強調一件事情。不是某個厲害的功能，而是一個檔案：
CLAUDE.md。
我把散落在各章節裡的相關敘述整理出來，大家感受一下這個份量：
“Save this output as CLAUDE.md markdown file(s). This is your architectural context document: the first artifact of your build, and the one every subsequent session depends on.”
（把這份輸出存成 CLAUDE.md。這是你的架構上下文文件：你整個建造過程的第一個產物，也是之後每一個工作階段都依賴的那一個。）
“Without this context, each session starts from scratch and Claude Code is forced to infer its own structural assumptions.”
（沒有這份上下文，每次工作階段都從零開始，Claude Code 只能自己推測結構假設。）
“Five minutes of documentation per session is cheap insurance against architectural drift.”
（每次工作結束花五分鐘寫文件，是防止架構偏移最划算的保險。）
“Letting Claude Code build without guardrails produces a codebase that will be functional but structurally incoherent.”
（讓 Claude Code 在沒有護欄的情況下動工，你會得到一個能跑但結構混亂的程式碼庫。）
看出來了嗎？
Chat 不需要什麼外部約束，因為它本來就被限縮了行動權限——手都被綁住了，也不太需要擔心它亂來。Cowork 用連接器來框定邊界——你開哪扇門它進哪間房。
但 Code 的技術能力幾乎全開，Anthropic 選了一個完全不同的策略——它不限縮模型的能力，而是要求你這個使用者自己提供約束。
CLAUDE.md 的本質，不是什麼配置檔或設定檔，而是人類對 AI 的行為契約。你在裡面寫下：這個專案的架構原則是什麼、哪些 pattern 要遵守、哪些依賴要避免、當初為什麼做了這些取捨。Claude Code 每次啟動都會讀這份文件，然後在你定義的框架裡面工作。
為什麼非得這樣設計不可？因為模型本身沒有跨 session 的記憶。Playbook 直接告訴你了：沒有 CLAUDE.md，每次 session 都從零開始，模型每次都得自己重新推導一遍「這個專案應該怎麼蓋」，而且——每次推出來的結論可能都不一樣。
累積個幾十次 session 之後，你得到的不是一個架構連貫的 codebase，而是一堆各自合理但彼此打架的決策堆疊物。能跑，但沒人看得懂為什麼長這樣。包括你自己。
Code 的設計哲學是：給你最大的技術自由度，但判斷的一致性必須由你自己來維護。
這讓我想到以前帶新人的經驗——能力越強的新人，你越需要花時間跟他對齊專案的架構方向。不然他會用最漂亮的姿勢，把東西蓋歪… Orz
浮現的設計哲學
好，到這裡我們把三條產品線拆完了。接下來把它們擺在一起看，有幾個 Anthropic 從頭到尾都沒有明說、但一旦你知道要找就非常清楚的設計原則：
第一項：能力與約束成正比
| 產品 | 行動能力 | 約束來源 |
|---|---|---|
| Chat | 最低（只輸出文字） | 系統內建（根本不開放外部連接） |
| Cowork | 中等（可連接授權系統） | 使用者配置（你決定開哪些連接器） |
| Code | 最高（直接操作 codebase） | 使用者提供（你自己寫 CLAUDE.md） |
越強的工具，需要越多來自人的約束。
Anthropic 沒有選「通通鎖死最安全」這條路，而是做了一個更精細的設計：根據場景的風險等級，把約束機制的控制權分配給不同的對象。低風險的讓系統自己管，中風險的讓使用者配置，高風險的直接要求使用者主動提供。
你仔細想想，這其實是很厲害的一手——它讓使用者在不知不覺中，隨著工具能力的提升，逐漸承擔起更多的判斷責任。
第二項：信任是分層的
三個產品其實對應了三種不同的人機信任關係：
- Chat：我信任你的判斷——但不讓你動手
- Cowork：我信任你在特定範圍內的執行——你能碰的東西由我決定
- Code：我信任你的技術能力——但行為框架由我來定義和維護
同一個模型、同一顆引擎，三種信任等級，三套對應的邊界機制。
這套分層信任架構，才是 Claude 產品線真正的設計圖。
從外面看，你以為 Anthropic 賣的是三個不同功能的產品。從裡面看，它賣的其實是三種不同的信任契約。
第三項：記憶的缺失是刻意的，不是做不到
Playbook 花了很大力氣講 persistent context（持久化上下文）——為什麼需要 CLAUDE.md、為什麼每個 session 結束要更新文件、為什麼架構決策一定要外化成文字。
但你有沒有想過一個問題：為什麼 Claude Code 不直接幫你記住上一次 session 的決策就好？多方便啊？
原因是：讓模型自己記住東西，就等於讓模型自己決定該記什麼、該忘什麼。在一個能直接改你程式碼的工具裡面，這太危險了。
記憶外化，其實是一種安全機制——它強迫人類把自己的判斷轉成可檢視、可修改、可版本控制的文字檔。你永遠知道 Claude Code 是讀了什麼指令在工作，因為那些指令是你自己寫的、你自己維護的。
這裡再對比一下 Chat 就更明顯了。Chat 有 memory 功能，可以讓模型跨對話記住你的偏好和背景。但 Chat 的行動半徑接近零——就算它記錯了什麼東西，頂多回答不太對，不會造成什麼實際損害。
Code 呢？它有最大的行動半徑，所以 Anthropic 反而選擇不讓它自己「記」，而是由人來維護那份「記憶」。
能力越大的地方，記憶越不能交給 AI 自己管。
這個原則，Playbook 從頭到尾都在示範，但從來沒有直接說出來。
（嗯…不知道為什麼，突然覺得這個道理放到現實世界的組織管理裡也蠻適用的… XD）
回到鍛造場
好，聊到這裡，我們回頭看整份 Founder’s Playbook，它的價值就不只是「教你怎麼用 Claude 來創業」了。
它真正展示的，是一家 AI 公司怎麼用同一個模型底座，透過不同的邊界設計、信任機制和約束策略，鍛造出適合不同場景的產品。
這套設計邏輯其實不只適用於 Anthropic。任何在做 AI 產品的人，或者想搞懂 AI 產品背後到底在想什麼的人，都可以拿這份文件當一面透視鏡來讀。下次看到 OpenAI、Google 發新的產品文件，你也可以試試用同樣的方式反著讀——從使用建議裡反推設計意圖，往往比正面讀更有收穫。
而對我們這些日常使用者來說，理解鍛造意圖的好處也很實際：你會知道每個工具的「刀鋒」朝哪裡、「刀背」在哪裡。順著結構切，事半功倍；逆著結構硬幹，不是切不動就是崩口。
了解了鍛造意圖，下一步就是回到自己的工作場景，順著這些設計邏輯把工具用對、用好。
這部分，我們下篇來聊～
參考文件：
The Founder’s Playbook: Building an AI-Native Startup（PDF） — Anthropic, 2026.05
