德國 7 天分散式 ship 實驗：why-i-built-atlas 的結果報告
德國 7 天分散式 ship 實驗：why-i-built-atlas 的結果報告
「假設」跟「驗證」之間隔了 13 hr 飛行、7 天、跟 1 顆洲際導彈。
上一篇 我說這趟德國旅程是 Atlas thesis 的壓力測試——「一人公司 + AI 同事，能不能根本不停？」
我落地了。結果出爐。
7 天到底 ship 了什麼
不是抽象意義的「有做事」。是可數的、有 commit hash 的、有 timestamp 的具體輸出：
- Atlas feed 153 條 entries（5/8 到 5/15、平均一天 ~22 條、最薄那天 8 條、最厚那天 37 條）
- OSS PR 在旅程中 merge：3 個（Microsoft Agent Governance Toolkit、TalEliyahu/Awesome-AI-Security、巴士上 commit 的）
- 行程結束後的 Phase 0 essay：8 章、~11,600 字 zh-TW（含 inline 媒體、scrollytelling、3 個彩蛋）
- 新 brand × 1（在 charter bus 上 8 小時 ship 完整個 landing page、之後會獨立發文）
- 新 SaaS spec × 1（落地後 48 hr 內寫完、~12,000 字 spec）
- WebP 圖片優化 -37%（281 張、5,5.5MB → 34.9MB）
加總起來、這 7 天的工作量高於我日常 baseline。
不是不停、是加速。
為什麼比平常快
當初設計 Atlas 的時候我給自己定的約束：
- Public-by-default — 所有人能看到
- Real-time — 不事後剪輯
- Frictionless — 一支手機 + Telegram 就能操作
這 3 個約束在出發前看是「為了透明度」。實際跑完才發現、它們同時是加速器：
Public-by-default 強迫你做完才 commit。沒有「等回來再整理」的逃避路線。 Real-time 把 batching 成本降到 0。一個觀察 → 兩分鐘後 atlas 上、不用週末整理。 Frictionless 讓「想到就做」變成可能。30,000 呎、巴士、Marienbrücke 橋上、Zugspitze 山頂——只要手機在手就能 ship。
換句話說、約束本身產出 throughput。這跟工廠設計 takt time 一樣：限制每個工位的時間、總產出反而升高。
Atlas 不是一個 dashboard、是一條 production line。
我做什麼 / Claude 做什麼 / OpenClaw 做什麼
實際 7 天的工作分配（粗估）：
| 角色 | % | 做的事 |
|---|---|---|
| 我 | ~10% | 看、感受、傳訊息、決定方向、社交、睡覺 |
| Claude（AI 同事） | ~70% | 接 TG 訊息、寫 entry、改 code、寫 essay、push commit、回 PR、debug |
| OpenClaw fleet（4 agents、30 timers） | ~20% | 排程內容、社群互動、每日 fleet report、自動產出 blog 草稿 |
關鍵在於那 10%。
那 10% 不是「我在偷懶」、是「不能委派的部分」：什麼有價值、什麼不重要、什麼是真正的 insight。Claude 跟 OpenClaw 可以執行任何被定義的任務、但**「定義任務本身」**還是我做。
這對「下一代 CEO 是什麼樣貌」的答案有具體意義：不是 AI 取代你、是 AI 接管 90% 的執行、釋放你做那 5-10% 真正不能委派的事。
那 10% 是品味、判斷、跨領域 literacy、人際關係——人能做、AI 還做不好的部分。
Capability stack > 任何單一輸出
最重要的不是這 7 天具體輸出多少。是 7 天累積了 3 樣會 compound 的東西：
- 一個磨好的 magazine-essay engine——8 章遊記用的 5 種 magazine layout primitives（InlinePhoto / FullBleed / PullQuoteBg / SideBySide / Scrolly）、之後任何長文都能複用
- 兩個衍生產品的 seed——一個來自 outlet 巴士那 8 小時的副產物、一個來自整個 Atlas 經驗的 productization。兩個都還沒公開、但 spec 跟 brand 都鎖好了
- 一套可複製的旅程 → narrative 轉換 workflow——下次出差不用從零開始
比起任何單一 commit、這個 capability stack 才是 7 天真正的 payload。
旅程結束 ≠ 工作結束。每個 capability 都是下一個出差會更快、下一個產品會更早 ship 的 multiplier。
跌過的坑：自有 stack 不是免費的
行程尾聲撞上 Vercel 用量警告。Fluid Active CPU 83% / 4h 上限——主要是 ultra-lab project（75.7%）燒掉。
選項：
- A：花 3-4 hr 搬重 API 到 Firebase Functions（免費、但有 cold start + CORS 風險）
- B：升 Vercel Pro $20/月（CPU cap × 25 倍）
- C：自己優化 + 拆專案
我選了 B。
為什麼？因為「時間比 $20 貴」。3-4 hr 的工程 risk 不值得省 $20/月。自有 stack 是有代價的、要算進來、別假裝它是免費的。
這也是 founder 的損失耐受性校準——剛輸 $20 不糾結、快速切回正事。出差 7 天買了張刮刮樂 €20 沒中、立刻丟垃圾桶切回工作。同個技能、不同 scale。
7 天後的答案
上一篇 我問：能不能根本不停？
7 天後的答案：不只能不停、能加速。
但條件是：
- 你要 ship 一套 AI 同事可以接的工作流（不是 prompt engineer、是 ops engineer）
- 你要願意 public-by-default（不然 batching 偷懶會回來）
- 你要承認自有 stack 不免費（不然會被基礎設施 surprise）
這趟旅程的真正 payload 不是 Mercedes Factory 56、不是 Zugspitze 那 50 通電話、不是巴士上 ship 的品牌。是這 3 個條件被一一驗證——Atlas thesis 成立。
過程比結果重要、因為過程是會 compound 的能力、結果只是當下的一次輸出。
如果你想看那 8 章 essay：ultralab.tw/atlas/germany-2026（含 3 個彩蛋）。 如果你想跟著看下一段——下一篇文章可能會公開那兩個衍生產品。