不會寫程式也能創業？Anthropic 白皮書告訴你可以，但有條件

Anthropic 在 5 月 14 日發布的《The Founder's Playbook》裡，有一句話值得所有想創業但不會寫程式的人記住：AI 原生新創正在根本性地改變「創辦人」這個詞的定義。一個沒有工程背景的人，現在可以建造出讓想法落地的生產級軟體；而一個技術能力很強但不懂商業的創辦人，也能輕鬆產出市場進入策略、財務模型和精緻的投資簡報。

這不是空泛的願景宣言。白皮書引用了具體案例：透過 Anything 平台（基於 Claude 和 Agent SDK 建造），已經有 150 萬名使用者把想法變成了可運作的軟體產品，其中包括一位非技術背景的創辦人，用它打造了一個完整的招募平台，而且已經在賣了。另一個例子是 Kindora，由一位非營利組織的高階主管用 Claude Sonnet 打造，專門解決慈善機構與捐贈者媒合的難題。白皮書認為這是 AI 帶來的最大變革：當創業的門檻不再限定為「會寫程式的人」，來自完全不同生活經驗的人開始進入新創生態圈，他們會去解決傳統科技創辦人從未注意到、甚至從未遇過的問題。

同一個 AI，三種工作面

白皮書花了不少篇幅解釋一件很實際的事：同樣是 Claude，不同的產品介面適合不同類型的工作。對非技術創辦人來說，搞清楚什麼時候該用哪個介面，是避免浪費時間的第一步。

Chat 是最輕量的選項，適合不需要離開當前工作流的快速任務。從一份冗長的投資備忘錄裡抓出一句話重點、在董事會前確認一個說法是否站得住腳、消化團隊 Slack 裡一長串的討論。不需要任何設定，打開就能用，像隨時在旁邊的顧問。在 Idea 階段，Chat 最常被用來磨利你的問題假設：把一個模糊的觀察（「大家覺得報帳很煩」）逼成一個可驗證的假設（「中型企業的財務經理每週花四小時以上對帳，因為現有工具無法跟會計軟體整合」）。你也可以讓 Chat 扮演魔鬼代言人，用最強的論證攻擊你的創業點子，找出你可能忽略的致命缺陷。

Cowork 是做「需要花時間的知識工作」的地方。它能存取你的檔案和資料夾，連結你使用的工具（專案管理、通訊平台、資料來源），還能設定定期自動執行的任務。白皮書舉了幾個具體場景：把一整個資料夾的客戶訪談紀錄彙整成主題式的發現報告、從十幾家供應商的網站上建構競爭態勢分析、每週一早上自動從連結的工具裡拉出 KPI 簡報。對一個還沒有團隊的獨立創辦人來說，Cowork 就是那個你請不起但很需要的營運助理。白皮書特別提到，Cowork 可以透過 MCP（Model Context Protocol）整合你公司使用的各種系統，不需要有人特地去建立和維護這些串接。在一人公司裡，那個「有人」通常就是創辦人自己，所以這省下的時間是實實在在的。

Code 是給工程師用的環境，直接存取程式碼庫、執行命令、處理 Git 版本控制。但白皮書指出，即使是非技術創辦人，在 Idea 階段結束時也會需要用 Code 來建造輕量原型。關鍵是，你不是在「學寫程式」，而是用自然語言描述你想要什麼，讓 AI 處理技術實作。你的工作是說清楚「建造什麼」和「為什麼」，Code 負責「怎麼建造」。但這也是白皮書開始發出警告的地方：正因為你看不懂 AI 寫出來的程式碼，某些風險對你來說是隱形的。

非技術創辦人的三個特殊風險

白皮書沒有天真地認為 AI 消除了技術門檻就萬事大吉。它明確點出了三個非技術創辦人比技術創辦人更容易踩到的坑。

第一個是安全盲區。白皮書的說法很直白：AI 程式撰寫工具產生的是「能用的程式碼」，不是「安全的程式碼」。功能正不正常很容易看出來，東西能動就知道成功了，但安全漏洞是隱形的，沒有任何天然的回饋機制會告訴你出了問題。技術創辦人至少知道要去檢查認證處理、API 回應中的資料暴露、輸入驗證和注入風險這些基本項目。非技術創辦人可能根本不知道這些項目的存在。白皮書的底線很明確：在任何真實使用者碰觸你的產品之前，至少跑一次安全審查。可以先用 AI 做初步掃描（白皮書提到了 Claude Code Security 功能，但誠實標註它在出版時仍是限量測試版），但這不能替代專業的安全工具或有經驗的人工審查。

第二個是 AI 技術債的隱形累積。如果你不把架構決策記錄下來，每一次新的 AI 工作階段都會從頭推導基礎設計，而且每次的結果略有不同。你最後得到的程式碼庫表面上能跑，但底層邏輯自相矛盾。技術創辦人在過程中通常會察覺到程式碼風格或結構的不一致，非技術創辦人可能完全看不出來，直到產品在使用者暴增時崩潰。白皮書建議的解法是從第一天就建立 CLAUDE.md 檔案，一種專案層級的記憶文件，把所有架構決策、技術選擇和設計原則寫在裡面，讓 AI 每次開工時都先讀取這份文件。每次工作結束花五分鐘更新它。白皮書還建議建立一個簡單的工作階段模板：先讀架構文件、執行本次任務、結束時記錄做了什麼決定和引入了什麼假設。五分鐘的記錄，是防止架構漂移最便宜的保險。

第三個是對 AI 輸出的過度信任。當你不理解程式碼在做什麼的時候，你傾向於相信它是對的。白皮書的態度很嚴肅：創辦人的責任是知道自己的程式碼庫裡有什麼，理解潛在的曝險面，不把明顯的漏洞推給信任你的使用者。這不是要你學會讀程式碼（雖然基礎理解確實有幫助），而是要你建立驗證的習慣。讓 AI 解釋它做了什麼、為什麼這樣做、有哪些已知的風險。把「問 AI 為什麼」變成跟「問 AI 去做」同樣頻繁的動作。

你的護城河不在技術，在領域知識

白皮書對非技術創辦人說了一件很重要的事：你的優勢，恰恰是技術創辦人沒有的東西。

很多非技術創辦人之所以想創業，是因為在自己的專業領域裡親身遇到了問題。你可能是律師，受夠了合約審查的低效率；是醫療從業者，知道病歷摘要的流程有多荒謬；或者是非營利組織的主管，對媒合捐贈者和受助機構的困難感同身受。這些第一手的領域知識，白皮書稱為「創辦人知識」（founder knowledge），是 AI 無法自動產生的。一個工程師可以用 AI 在一個週末做出一個合約審查工具，但如果他不知道跨部門利害關係人溝通的眉角、不同公司風險容忍度的差異、或是哪些合約條款在實務上永遠是談判焦點，那個工具就只是一個好看的殼。

白皮書建議把這些知識系統性地輸入 AI 系統。行業術語、法規陷阱、邊界案例、為什麼顯而易見的做法行不通的原因，都可以透過跟 AI 的對話、專案設定和記憶功能，轉化成結構化的、可搜尋的知識基底。時間越長，這個基底越厚，你的產品就越能處理通才 AI 做不到的專業場景。白皮書舉了一個很具體的例子：一個通用的醫療帳務 AI 工具可能在處理 340B 藥品計畫的請款時出錯，但如果你的產品有針對這個邊界案例的專門邏輯，因為你這個前醫療從業者知道它的存在，那就是競爭對手抄不走的優勢。每多處理一個這樣的邊界案例，你的護城河就多深一層。

這個思路翻轉了傳統的創業敘事。過去，「我不會寫程式」是劣勢。現在，「我在某個領域有二十年經驗」可能比工程學位更有價值。AI 補齊了技術的缺口，而你的領域專業成為產品持續累積深度的引擎。白皮書裡提到的案例都印證了這個邏輯：GC AI 的創辦人用法律領域的專業知識打造了一個符合法務團隊真實工作流的平台，Wordsmith 的創辦人本身就是律師轉技術長，Zingage 則是把居家照護機構的營運知識轉化成了 24 小時運作的 AI 代理人。這些產品的差異化都不是來自技術，而是來自創辦人帶進來的領域理解。

門檻消失了，但判斷不能外包

Anthropic 這份白皮書畫了一幅很吸引人的圖景：在 2026 年，一個有想法的人不需要技術共同創辦人、不需要外包開發團隊、不需要先募一輪資來招工程師，就可以開始把想法變成產品。但白皮書也很誠實地指出，門檻的消失不等於成功的保證。

AI 讓建造變容易了，但驗證問題是否真實、使用者是否真的需要你的解決方案、產品是否安全可靠，這些判斷沒有工具可以代勞。對非技術創辦人來說，最務實的做法可能是這樣的：先用 Chat 和 Cowork 把 Idea 階段的功課做足，做到你真的能回答「誰有這個問題、多嚴重、目前怎麼處理」。然後才打開 Code 建造最小的原型，拿去跟五個目標使用者面對面測試。五場對話的價值，遠超過你花一個週末用 AI 多做出來的十個功能。

白皮書最後寫到，2026 年的創辦人的工作本質沒有變：找到真實的問題、建造真正能解決它的東西、然後把它變成一家有意義的公司。改變的是路徑。AI 壓縮了從想法到產品的距離，但壓縮不了從產品到成功所需要的判斷力和紀律。對非技術創辦人來說，這大概是最公平的時代：你的劣勢被 AI 補齊了，但你的優勢，也就是那些年累積的領域直覺和對問題的深刻理解，反而比以前更有價值了。