我太相信 ChatGPT 5.6Sol

我原本以為，這會是一個大約 30 分鐘到 1 小時的建站任務。

目標很清楚：把 ai-man.com 做成一個有設計感、能代表 AI-MAN 的雙語個人品牌網站。它要傳達一句話：**用 AI 打造你的一人公司。**

但過程沒有照著這個目標走。

我一開始對 ChatGPT 5.6Sol（高）的期待值太高，因此把流程選擇也交給它。我接受了它建議的 `superpowers:subagent-driven-development`／`superpowers:executing-plans` 組合，並逐項以核取方塊推進計畫。

那就是第一個錯誤。

這本來是一個已經驗證過的 Agent 原生網站模板移植計畫，不是從零開始設計大型系統。Claude Code 曾能以不到 5 小時額度、不到 1 小時的實際時間完成相近的建站工作；但這次的 ChatGPT 5.6Sol（高）消耗了一週額度、超過 5 小時，仍沒有完成開發。使用者必須中途不斷介入提醒加速，並主動中止 Task 7 的金流與 Task 8 的自建社群，才能把工作拉回可上線範圍。

最後得到的不只是網站視覺，而是一套 Next.js、Payload CMS、Better Auth、會員權限、電子書、課程、名單歸因、Agent 發文與 SEO discovery 的全端基礎。這些不是沒有價值；問題是，它們不該搶在「讓我先看見一個很好的網站」之前完成。

這篇文章不是在炫耀 AI 幫我寫了多少 code，而是公開記錄：AI 協作建站真正困難的地方，往往不是模型不會寫，而是它是否把「現在最重要的成果」排在第一位。

一開始，我要的不是一個模板網站

ai-man.com 的定位不是 AI 工具部落格，也不是只賣課的 landing page。

它是 AI-MAN 的全球總部：用內容吸引人、用電子書與課程建立信任、用會員與未來的 AI 老闆俱樂部承接關係，最後成為一人公司（OPC）的商業系統。

網站的資訊架構很快就被定義下來：一人公司、AI 品牌、開放品牌、電子書、AI 老闆俱樂部、關於 AI-MAN。首頁和前三頁要共同回答一件事：一人公司不只要學會做事，還要有 AI 工廠讓自己做得動，以及開放品牌提供可以賣的東西。

這三者的關係被壓縮成一句話：**培訓製造 OPC → AI 工廠武裝 OPC → 開放品牌供應 OPC。**

視覺目標很清楚：AI-MAN 必須有自己的編輯感與品牌辨識，而不是另一個 SaaS 模板。

真正完成了什麼

先把事實說清楚。這次不是只改了首頁。

在 Git 紀錄裡，從 7 月 13 日傍晚到深夜，完成了全端基礎、雙語品牌前台、內容與商品資料模型、會員登入與權限、名單收集、課程與電子書會員庫、Agent 發文與 SEO discovery 等工作。Task 6 的單一提交就包含約 1,200 行、20 個檔案的變更；完整測試最後累積到 69 個通過。

目前網站具備的核心能力包括：

• 中英文路徑與選單，並保留舊網址的永久轉址。

• Payload 作為內容與營運資料層；Production 用 Postgres，local 開發可用 SQLite。

• Better Auth 作為會員登入；Payload 原生登入則留給管理者，兩者不混用。

• 電子書三部曲、課程入口與會員專屬書庫。

• Newsletter 名單收集與來源歸因；重複訂閱不重複建立資料。

• 受保護的 Agent 發文 API、`/api/site-info`、RSS、sitemap、robots 與 `llms.txt`。

電子書的敘事也被固定下來：從《I Dream, AI Works.》的 NPC 覺醒，到《AI Lean Startup》建立能持續改善、能賺錢的一人事業，最後進入《The Super One》的品牌 × 媒體 × 電商三位一體事業。

這些成果是真實的。但它們不等於這次執行方式是對的。

最大的失誤：一開始就過度設計

使用者最在意的是兩件事：速度，以及視覺美學。

最大的錯誤不是多代理流程，而是 ChatGPT 5.6Sol 一開始就把一個已經驗證過的 Agent 原生網站模板移植，判斷成需要完整平台工程的開發案。

在第一版視覺成果真正被看見前，它就投入大量時間在 CMS、資料庫、身份邊界、權限、資料模型與 fail-closed 的 production 契約。這些都是未來可能需要的東西，卻不是第一個小時最需要的東西。

多代理計畫流程不是根因，而是放大器。`subagent-driven-development` 與逐項計畫執行，讓每個 Task 都有代理交接、重複閱讀長規格、核取方塊追蹤、審查與再驗證。一般 UI 與內容頁也反覆跑測試、typecheck、build。安全、付款、身份驗證確實值得嚴格處理；但一個選單調整或視覺區塊，不需要用同一套重量級流程。

結果是：我把本來應該在 30–60 分鐘內交付的可預覽成果，拆成很多工程正確、但使用者暫時看不見的步驟。

這是 AI 協作最容易犯的錯。模型看見完整規格後，傾向把所有未來需求一次做完；但創業者需要的是先看見最小可用、最有感的成果，再決定要不要投資下一層。

一個很小、卻讓網站完全看不到的錯誤

後段最有教育意義的事件，是 Vercel 的 404。

程式其實已經成功 build，Next.js 也確實產生了 `/zh-tw`、`/en`、`/robots.txt` 等路由。但部署後，`https://ai-man-com.vercel.app/zh-tw` 仍然回傳 404，連純靜態的 `robots.txt` 都無法顯示。

一開始，我把注意力放在帳號 email、GitHub no-reply email、Vercel 登入身分等方向。那是錯誤的診斷路線。

真正原因是 Vercel 專案的 Framework Preset 是空值：`framework: null`。也就是說，平台有收到部署產物，卻沒有把它當成 Next.js 專案接到邊緣路由層。於是問題不是 Next.js 應用內的 404，而是請求根本沒有進到應用。

最後使用者切換到 ChatGPT 5.6 Terra；而真正把上線問題排除的人是 Claude Code：它把 Vercel 專案的 framework 設為 `nextjs`，再重新 production deploy。之後 `/zh-tw` 回傳 200、`/en` 正常、`/` 以 308 導向 `/zh-tw`，連 `/robots.txt` 也恢復正常。

這件事提醒我：當「所有路由，連靜態檔」都 404 時，先檢查部署平台是否正確辨識 framework，不要先懷疑應用程式路由，更不要在沒有證據前猜帳號身分問題。

我們刻意沒有做的三件事

一個能誠實 Building in Public 的專案，不只要列出完成項目，也要列出沒做的項目。

第一，金流暫緩。台灣的主要選擇 Recur 尚未正式開放，因此目前沒有硬接 Recur 或 Lemon Squeezy，也沒有假裝 checkout 已經能用。未來恢復時，Recur 會是台灣與 TWD 的優先選擇，Lemon Squeezy 負責國際付款；兩者都必須寫入同一套本地訂單、訂閱與權限履行邏輯。

第二，AI 老闆俱樂部的互動功能暫緩。公開介紹頁存在，但會員動態、主題空間、貼文、留言、公告與訂閱帳務頁還沒有做。它會是自建社群，不串 Circle、Discord 或 Skool；但現在先不把未完成的功能畫成已上線。

第三，`GET /api/metrics` 被排除。目前不建立任何會員營運彙總 API，也不建立對應 token。原因不是技術做不到，而是這個階段沒有必要把營運資料暴露成外部介面。

延後不是放棄。延後是把「現在要驗證的事」和「未來要擴充的事」分開。

下一次，我會怎麼用 AI 建站

這次之後，規則要變得更簡單。

第一，先在 30–60 分鐘交付可見成果。首頁、核心頁、選單、品牌視覺先完成，讓創辦人可以直接判斷：這是不是我要的網站？

第二，一個 Task 在完整實作後才跑一次整合 build。開發中只跑與修改範圍有關的 targeted tests 或型別檢查，不再為每個小修改反覆做全站驗證。

第三，只有身份、付款、隱私與破壞性資料變更需要高強度審查。一般內容與 UI，由主代理直接完成、直接驗證、直接交付。

第四，外部服務還沒準備好，就先保留清楚的介面與恢復條件，不把不存在的能力硬塞進第一版。

第五，遇到部署問題要先看證據。build 是否成功、實際 HTTP status、平台 header、framework 設定、路由輸出，應該比「我猜可能是哪個帳號」更早被檢查。

這不是 AI 替你蓋好網站的故事

ChatGPT 5.6Sol 的確可以把一個靜態內容站推進到可演進的全端商業基礎：雙語、內容、會員、名單、電子書、課程、Agent 發文、SEO 都能在同一個系統裡。但這次也證明，高推理不等於高交付效率；如果模型選錯工作模式，能力越強，越可能把一個已驗證的移植案做得過度複雜。

但 AI 不能替創辦人決定優先順序。

真正的槓桿不是讓 AI 做更多，而是由人明確指定它該用多輕的流程、先交付哪個可見成果。對 ai-man.com 而言，第一個價值不是多一個抽象資料層，而是讓人一打開網站，就知道這裡在說什麼：

**用 AI 打造你的一人公司。**

網站已經可以從這裡開始測試與迭代：<https://ai-man-com.vercel.app/zh-tw>

接下來的工作不是把功能表越拉越長，而是讓首頁、三個 OPC 主題頁、電子書與會員入口，真正開始形成內容、名單與產品之間的飛輪。