AI 裝備升級指南：AIOPC
這是一份公開草稿。內容還在迭代，歡迎一起把它變得更好。
AUTO-FARM ON — Agent 原生網站部署：睡著也在幫你打怪獲客 伺服器狀態：ONLINE ● 獲客砲台自動運作中。預計首次產出：72 小時內 _
這一章是 IDAW 的 BUILD 實戰章
IDAW 的等式是：
I Dream（你）+ AI Works.（AI）= IDAW
I Dream，你負責夢想和方向。
AI Works.——這一章，就是讓 AI Works. 真正跑起來的實戰手冊。
CH06 你學了 OPC 三大基建的設計藍圖。這一章，就是把它真正建起來的實戰手冊。它有一個完整的名字：Agent OPC Operation System。
AI Works. = Agent OPC Operation System
Agent OPC Operation System
= Agent 原生獲客變現網站
+ Agent 員工
+ Agent 工作流
這三個不是三個工具，是同一台機器的三個部件：
Agent 原生獲客變現網站
→ 你的 OPC 基地
→ 24/7 自動獲客、自動變現
→ 你的品牌、內容、課程的家
Agent 員工
→ 執行工作的 AI 主力
→ Claude Code：通用 Agent，建造、設計、執行、修復、創建專精 Agent
→ Codex：接力執行、批量處理、背景任務、平行工作流
Agent 工作流
→ Claude Code / Codex 透過 API / MCP
串連專精 AI 工具 + 外部工具 + 最佳實務 Skills
→ 組成可自動化完成特定任務的完整管線
→ 例如：AI UGC 自動化工作流、SEO Blog 工作流、課程發布工作流
Agent OPC Operation System 建好之後，你的 OPC 就具備了自動運轉的能力。
這就是 AI Works. 的真正意思——
不是你在拚命工作，是你建好的系統在幫你工作。
這一章給你五個關卡：
7-1：免費——Agent 原生網站的建站與運營成本
7-2：新裝備圖鑑——AIOPC 三位一體是什麼
7-3：第一步——建立 IDOL Wiki
7-4：四大模組實戰——內容獲客／課程變現／會員管理／金流系統
7-5：實戰案例——IDOL Wiki × aicoding.tw SEO Blog 自動化
AI BOSS 與 Agent 員工：你真正在指揮的是什麼
很多人以為「Agent 員工」就是一堆 AI 工具。
不是。
一個好的 AI BOSS，要先掌握一個強大的通用 Agent。
這個通用 Agent，就是 Claude Code（或 Codex）。
Claude Code 不只是一個 Coding 工具。
Claude Code 是你的通用 Agent——
它能設計、建造、執行、修復， 能讀懂你的整個專案上下文， 能根據你的指令自主完成複雜的多步驟任務。
更重要的是：Claude Code 可以為你建立專精特定任務的 Agent 和 Agent 工作流。
你（AI BOSS）的指揮鏈：
你（10%：方向 + 判斷 + 主張）
↓ 指揮
Claude Code / Codex（通用 Agent）
↓ 建立
專精 Agent A（例如：SEO Blog 寫作 Agent）
專精 Agent B（例如：課程發布 Agent）
專精 Agent C（例如：短影音腳本 Agent）
+
Agent 工作流（把這些 Agent 串成自動化管線）
↓
Agent OPC Operation System 自動運轉
這是 AI BOSS 真正的工作方式。
你不是直接指揮每一個專精 Agent。
你指揮 Claude Code。
Claude Code 幫你建立、訓練、部署那些專精 Agent。
這是一個很重要的認知：
Claude Code 是生產 Agent 的 Agent。
它是你的 OPC 工廠廠長，負責把你的需求，轉化成一套會自動運轉的 Agent 團隊。
錯誤的認知：
AI BOSS → 直接操作每一個 AI 工具 → 逐一完成任務
正確的認知：
AI BOSS → 指揮 Claude Code（通用 Agent）
→ Claude Code 建立專精 Agent + 工作流
→ 專精 Agent 自動執行任務
→ AI BOSS 只負責方向和 Harness
這就是為什麼 CH05 說的「AI Boss 思維」和普通的「AI 工具使用者」完全不同。
工具使用者：叫 AI 做一件事，等結果，再叫下一件。
AI BOSS：設計 Agent 指揮鏈，讓系統自己跑，自己只負責最重要的 10%。
Agent 工作流：串連一切的自動化管線
Agent 工作流，是 Agent OPC Operation System 的第三個核心部件。
但很多人對它的理解是錯的。
Agent 工作流不只是「讓幾個步驟自動跑」。
它的真正定義是：
Agent 工作流
= Claude Code / Codex（通用 Agent，負責指揮和串接）
+ API / MCP（連接外部工具和服務的通道）
+ 專精 AI 工具（負責特定內容生產任務）
+ 外部工具（負責發布、管理、分析）
+ 最佳實務 Skills（讓每個節點用最好的方式執行）
= 可自動化完成特定任務的完整管線
API / MCP：讓 Claude Code 長出手腳
Claude Code 本身是大腦。
API 和 MCP（Model Context Protocol）是它的手腳——
讓它可以直接操作、呼叫、串接外部的工具和服務。
透過 API / MCP，Claude Code 可以指揮：
專精 AI 工具：
→ AI 圖像：Nano Banana Pro / ChatGPT Images 2.0 / Midjourney
→ AI 影片：Seedance 2.0 / Gemini Omni
→ AI 音樂：Suno / Udio
外部工具：
→ 搜尋與分析：Google Search / Google Analytics
→ 設計平台：Figma / Canva
→ 發布平台：社群媒體 API / 電子報工具
→ 內容管理：Payload CMS / Notion
→ 電商通路：課程平台 / 金流系統
Skills：讓每個節點用最佳實務執行
Skills 是 Claude Code 的專精指令包。
每個 Skill 封裝了一個任務的最佳執行方式——
呼叫它，Claude Code 就知道這個任務要怎麼做得最好。
Skills 是 Agent 工作流品質的保障。
有了 Skills，工作流不只是「自動跑」，而是「用最好的方式自動跑」。
完整示範：AI UGC 自動化工作流
你定義影片主題和品牌調性（10%）
↓
Claude Code 透過 MCP 呼叫搜尋工具
→ 研究平台爆款影片結構
↓
Claude Code 分析爆款，生成影片腳本（用 IDOL Wiki 語氣）
↓
Claude Code 透過 API 呼叫 Seedance 2.0 / Gemini Omni
→ 生成影片素材
↓
Claude Code 透過 API 呼叫 Nano Banana Pro / ChatGPT Images 2.0
→ 生成配套圖像素材
↓
Claude Code 整合素材，加上字幕、標題、hashtag（Skills 執行）
↓
Claude Code 透過 API 發布到社群平台
↓
影片上線，觸達陌生人，建立信任，導向個人網站
你的工作：定義主題和確認方向。
其他所有步驟：Agent 工作流自動執行。
這就是 Claude Code + API / MCP + 專精工具 + Skills 組成的 Agent 工作流。
當前 Agent 工具全景（2026）
工具在快速進化。
這份清單是目前的最強配置——六個月後可能會更新。
但有一件事不會變：
選工具的邏輯永遠是——哪個工具讓你最快建立 Agent 指揮鏈，就用哪個。
通用 Agent：你的 OPC 工廠廠長
這一層是最核心的選擇。
通用 Agent 決定了你能建立什麼、建得多快、建得多好。
Claude Code（Anthropic）
→ 目前最強的通用 Coding Agent
→ 能讀懂整個專案、自主完成複雜多步驟任務
→ 建站、建工作流、建專精 Agent——全部都能做
→ 費用較高，適合認真建系統的 AI BOSS
Codex（OpenAI）
→ 好用、反應快
→ 適合快速執行單一任務和批量處理
→ 和 Claude Code 互補，適合接力執行
Antigravity 2.0（Google，2026 年 5 月發布）
→ Google 在 I/O 2026 推出的 Agentic 開發平台
→ 桌面 App + CLI + SDK + Managed Agents 四合一
→ 可在 Gemini API 內啟動自主推理、工具使用、代碼執行的 Agent
→ 建立在 Gemini 3.5 Flash 之上，支援背景自動排程任務
→ Gemini CLI 使用者需在 2026 年 6 月 18 日前切換至 Antigravity CLI
專精 AI 工具（正在加速導入 Agent 能力）
通用 Agent 管指揮和建造。
這一層負責執行特定內容生產任務——圖像、影片、音樂。
它們本來是工具，現在越來越多開始內建 Agent 能力，可以被通用 Agent 直接指揮和串接。
AI 圖像生成
ChatGPT Images 2.0（OpenAI，2026 年 4 月）
→ 目前 AI 圖像生成新標竿，一上線即登頂 Image Arena 排行榜
→ 具備「thinking」能力：可搜尋、生成多版本、自我審核
→ 文字渲染強，多語言支援，適合品牌視覺和課程封面
Nano Banana Pro / Nano Banana 2（Google）
→ Nano Banana Pro = Gemini 3 Pro Image 模型（Google DeepMind）
→ Nano Banana 2 = Gemini 3.1 Flash Image，速度快、整合 Gemini App/Search/Ads
→ 支援 5 個角色一致性、14 個物件精準呈現，適合品牌敘事素材
→ 深度整合 Gemini 生態，Antigravity 可直接指揮
Midjourney V8.1（2026 年 4 月）
→ 速度提升 4–5 倍，支援 2K 高解析輸出
→ 文字渲染大幅改善，美感仍是業界最強
→ 新增 Conversational Mode，可用對話方式迭代圖像
→ 創作者和品牌視覺首選
AI 影片生成
Seedance 2.0（ByteDance，2026 年 2 月）
→ 多模態輸入：文字 + 圖像 + 音頻 + 影片全支援
→ 單次生成即包含原生同步音頻（對話、音效、環境音、音樂）
→ 支援 2K 解析度，4–15 秒影片
→ 雙分支 Diffusion Transformer 架構，影片和音頻同步生成
→ 2026 春節晚會使用，市場關注度爆發（搜尋量一週暴增 850%）
Gemini Omni（Google，I/O 2026 年 5 月，整合 Agent）
→ Google 最新多模態影片生成模型，取代 Veo 系列
→ 接受任何輸入：文字 / 圖像 / 音頻 / 現有影片片段
→ 深度理解物理規律（重力、動能、流體），解決前代模型弱點
→ 已整合 Agent 能力——可自主規劃影片製作流程
→ 同步上線至 Gemini App、Google Flow、YouTube Shorts
這份清單最重要的訊號，不是哪個工具最強。
而是：
所有工具都在往 Agent 方向演進。
Gemini Omni 已內建 Agent。Antigravity 2.0 本身就是 Agentic 平台。
今天你還在逐一操作的工具，明天可能已經可以被通用 Agent 直接指揮和串接。
這就是為什麼你要建立 Agent 指揮鏈，而不是只學操作工具。
工具會換。
AI BOSS 的指揮能力，永遠有效。
7-1｜免費：Agent 原生網站
先說一件事
你在 CH05 學會了 AI Boss 思維。
你在 CH06 召喚了 Agent 軍團。
現在，你的 Agent 員工需要一個工作基地。
你的 IDOL 內容需要一個落腳的地方。
你的訪客需要一個找到你、了解你、成為你學員的地方。
這個地方，就是你的 Agent 原生網站。
建站之前，先讓你知道兩件事。
這兩件事，是這本書裡最強的兩個作弊碼之一。
第一件：你可以用 Claude Code 建造一個傳統報價 20 萬以上的 Agent 原生網站。
第二件：建好之後，每個月 0 元讓它 24/7 運轉。
不是試用期。不是限時優惠。
是真的 0 元，永久運營。
免費一：免費建站
先說清楚「免費」的意思。
免費，不是「便宜的網站」。
免費，是：同樣的功能，你用 Claude Code 建，傳統方式要花 20 萬請工程師做。
傳統報價是多少？
你去找一家網頁公司，開出這份需求單：
✦ 客製化品牌網站（非模板，從設計到開發）
✦ 後台 CMS 內容管理系統（文章 / 課程 / 產品自行更新）
✦ AI 客服整合（24/7 回應訪客問題）
✦ 課程 / 服務展示與銷售系統
✦ Landing Page 轉換頁系統
✦ SEO 結構優化（讓 Google 找得到你）
✦ GEO 優化（讓 AI 搜尋引擎找得到你）
✦ Email 訂閱入口 + 自動化漏斗接線
✦ 數據分析追蹤整合
對方會回給你一個報價：
基本企業官網（客製化設計） 5–8 萬
CMS 內容管理系統 2–3 萬
AI 客服整合 3–5 萬
課程 / 產品銷售系統 3–5 萬
Landing Page 轉換系統 2–3 萬
SEO + GEO 結構優化 2–4 萬
Email 訂閱 + 自動化接線 2–3 萬
數據分析整合 1–2 萬
────────────────────────────────────────
合計 20–33 萬
交期：6–12 週
後續維護：另計
這是市場行情。不誇張，不灌水。
你用 Claude Code 建，成本是什麼？
Next.js App Router 開源，免費
Payload CMS 開源，免費
GitHub 免費
所有上面列出的功能 全部可以用 Claude Code 建
你唯一的成本：
Claude Code 訂閱 約 600 元 / 月
就這樣。
600 元一個月。
你建造的，是傳統報價 20–33 萬的 Agent 原生網站。
這不是因為你用了「免費的劣質版本」。
這是因為 Claude Code 把工程師的工作接管了。
以前，建這個網站需要一個前端工程師 + 一個後端工程師 + 一個設計師 + 6 週時間。
現在，你需要 Claude Code + 你自己 + 幾天。
這就是 AI 時代最大的槓桿：技術門檻消失了。
建站這件事，不再是「有錢請工程師」的人才能做到的事。
免費二：0 元上線運營
建好網站之後，每個月的運營成本是多少？
Vercel 免費方案
→ 部署費： 0 元
→ HTTPS 憑證： 0 元
→ 全球 CDN 加速： 0 元
→ 自動化部署： 0 元
（每次 git push，網站自動更新）
GitHub
→ 版本控制： 0 元
→ 觸發 Vercel 部署：0 元
Payload CMS
→ 開源授權： 0 元
──────────────────────
每月運營成本： 0 元
Vercel 免費方案不是試用期。
它是 Vercel 給開發者的永久免費方案，適用於個人 OPC 規模的網站流量。
你的 Agent 原生網站建好上線之後，
不需要付任何一毛錢的主機費、不需要管伺服器、不需要設定 SSL 憑證。
全部由 Vercel 自動處理。
唯一可能的額外費用：
自訂網域（非必須）
→ 例如 yourname.com
→ 費用：約 300 元 / 年（25 元 / 月）
→ 沒有自訂網域，Vercel 也會給你一個免費網址可以用
所以：
有自訂網域版：625 元 / 月（Claude Code 600 + 網域 25）
純免費版： 600 元 / 月（只有 Claude Code 訂閱）
完全不算網域：0 元 / 月的運營成本
兩個免費加在一起
╔══════════════════════════════════════════╗
║ ║
║ CHEAT CODE：Agent 原生網站 ║
║ ║
║ 傳統報價：20–33 萬 ║
║ 建站成本：Claude Code 訂閱（600/月） ║
║ 運營成本：0 元 ║
║ ║
║ 你建了一個傳統 20 萬的網站， ║
║ 然後用 0 元讓它每個月 24/7 運轉。 ║
║ ║
╚══════════════════════════════════════════╝
這不是省錢。
這是進入了一個以前只有公司才能玩的遊戲——
用一個人的成本，建造公司等級的數位基建。
這就是 Claude Code 給 OPC 最強的裝備。
你建的不只是網站
最後，要說清楚一件事。
你建的不是「一個有 AI 功能的網站」。
你建的，是讓你的整個 AIOPC 能夠運轉的核心基地。
CH06 你召喚的 Agent 員工——
SEO Blog Agent 寫的文章，在這裡發布。
Agent 客服，在這裡回應訪客。
Landing Page Agent，在這裡讓訪客成為學員。
CH06 你設計的 Agent 工作流——
內容自動發布工作流，把文章推上這個網站。
Email 培育序列，從這裡的訂閱入口開始跑。
數據報告工作流，從這裡抓取流量和轉換數據。
沒有這個基地，
Agent 員工沒有地方工作，
工作流沒有地方落腳，
訪客找不到你，
AIOPC 無法運轉。
Agent 原生網站，是讓你的 Agent 軍團真正能夠上陣打怪的地方。
CHEAT CODE LOADED 傳統建站報價：20–33 萬 你的建站成本：Claude Code 訂閱（600 元 / 月） 月運營成本：0 元 武器：Claude Code 狀態：準備建造你的 Agent 原生網站
7-2｜新裝備圖鑑：Agent 原生 OPC 運營系統
新裝備解鎖
你在 CH05 學會了 AI Boss 思維。
你在 CH06 召喚了 Agent 軍團——
十一個 Agent 員工，七條自動化工作流。
但你還缺少一件事。
CH06 結束的時候，你的狀態是這樣的：
✓ AI Boss 思維：已掌握
✓ Agent 員工：已召喚（11 個）
✓ Agent 工作流：已設計（7 條）
✗ 缺少：讓這一切能夠運轉的完整系統
Agent 員工需要一個工作基地。
工作流需要一個可以落腳、執行、輸出的地方。
訪客需要一個找到你、認識你、成為你學員的入口。
這個「讓一切能夠運轉的完整系統」——
就是 AIOPC。
什麼是 AIOPC
AIOPC = Agent 原生 OPC
一整套讓 AI 一人公司 24/7 自動運轉的完整運營系統。
AIOPC 不是一個工具。
AIOPC 不是一個網站。
AIOPC 是一套完整的 Agent 一人公司作業系統。
它由三個部分組成，缺一不可：
╔═══════════════════════════════════════════════╗
║ ║
║ A I O P C ║
║ Agent 原生 OPC 運營系統 ║
║ ║
║ ┌─────────────────────────────────────────┐ ║
║ │ Agent 原生網站 │ ║
║ │ OPC 的數位基地 │ ║
║ │ 訪客在這裡找到你、信任你、成為學員 │ ║
║ └─────────────────────────────────────────┘ ║
║ ┌──────────────────┐ ┌────────────────────┐ ║
║ │ Agent 員工 │ │ Agent 工作流 │ ║
║ │ 你的 AI 軍團 │ │ 你的自動化引擎 │ ║
║ │ 11 個 Agent │ │ 7 條工作流 │ ║
║ └──────────────────┘ └────────────────────┘ ║
║ ║
╚═══════════════════════════════════════════════╝
三位一體，才是完整的 AIOPC。
三位一體圖鑑
第一位：Agent 原生網站
OPC 的數位基地
Agent 原生網站是讓 Agent 員工有地方工作、讓訪客有地方找到你的數位基地。
它不是傳統意義上的「官網」——
不是一張說明你是誰的靜態頁面。
它是一個 24/7 都有 Agent 在上面工作、隨時有能力回應訪客的活的系統。
Agent 原生網站做的三件事：
獲客
→ SEO 文章讓 Google 找到你
→ GEO 優化讓 AI 搜尋引擎（Perplexity / ChatGPT）找到你
→ IDOL 內容持續帶來流量
信任建立
→ 你的故事、主張、作品，從 IDOL Wiki 自動同步
→ Agent 客服用你的聲音即時回應訪客
→ OPC Blog 持續輸出，訪客越來越了解你
成交
→ 課程 / 服務展示，清楚讓訪客知道能得到什麼
→ Landing Page 深度轉換
→ Email 訂閱入口接住每一個訪客，進入培育漏斗
CH07 要建的，就是這一塊。
第二位：Agent 員工
你的 AI 工作軍團（CH06 已建立）
Agent 員工是讓 AIOPC 持續產出的人力。
不是人類，是 AI。
不是偶爾用一下，是每天都在工作。
獲客組（4 個 Agent）
→ SEO Blog Agent：持續寫 SEO 文章，發布到 Agent 原生網站
→ GEO Wiki Agent：維護 GEO 知識庫，讓 AI 搜尋引擎找到你
→ 短影音腳本 Agent：產出社群短影音素材
→ 社群 IDOL 內容 Agent：輸出符合你語氣的社群貼文
變現組（4 個 Agent）
→ Landing Page Agent：自動生成高轉換率的課程銷售頁
→ Lead Magnet Agent：製作吸引訂閱的免費資源
→ Email 行銷 Agent：撰寫培育序列和促銷信件
→ 促銷活動 Agent：設計限時活動文案
運營組（3 個 Agent）
→ 客服 Agent：在 Agent 原生網站 24/7 回應訪客
→ 數據報告 Agent：每週回報流量、轉換、收入數據
→ IDOL Wiki 維護 Agent：持續更新你的 AI 分身知識庫
第三位：Agent 工作流
你的自動化引擎（CH06 已設計）
Agent 工作流是讓多個 Agent 員工協作、自動完成複雜任務的管線。
你觸發一次，它自動跑完所有步驟。
持續性工作流（每天 / 每週自動跑）
→ 內容獲客工作流：關鍵字 → SEO 文章 → 自動發布到網站
→ 短影音生產工作流：主題 → 腳本 → 平台描述 → 排程
→ Email 培育序列工作流：新訂閱者 → 自動收到 7 封培育信
事件性工作流（需要時觸發）
→ Landing Page 生成工作流：課程資訊 → 銷售頁 → 自動部署
→ 促銷活動工作流：活動主題 → 全管道文案 → 排程發送
回報性工作流（定期自動執行）
→ 每週數據報告工作流：自動抓取數據 → 分析 → 發送給你
→ 客服回覆工作流：訪客訊息 → 分類 → Agent 回應 → 記錄
Agent 原生的意思是什麼
很多人的 OPC 也有網站、也有一些 AI 工具、也會寫 Email。
但那不是 AIOPC。
AIOPC 和「有在用 AI 工具的 OPC」，差別在一個詞：原生。
傳統 OPC + AI 工具
→ 工具是獨立的，沒有整合
→ 你用 AI 做事，然後手動搬運成果
→ 你不在，系統停下來
→ 每個任務都需要你啟動
Agent 原生 OPC（AIOPC）
→ 整套系統從一開始就為 Agent 設計
→ Agent 員工直接在系統裡工作，不需要你搬運
→ 你不在，系統繼續運轉
→ 大多數任務由 Agent 自動啟動和完成
「原生」的意思是：不是把 AI 插進原有系統，而是整套系統從設計之初就是為 Agent 準備的。
你的網站是為 Agent 員工設計的工作場所。
你的工作流是為 Agent 的協作設計的管線。
你的 IDOL Wiki 是為 Agent 的學習設計的知識庫。
這三件事整合在一起，才叫 Agent 原生。
AIOPC 運轉起來，長什麼樣子
一個完整的 AIOPC 在 24 小時裡，是這樣工作的：
凌晨 2 點
內容獲客工作流自動觸發：
→ SEO Blog Agent 從關鍵字庫選出本週主題
→ 讀取 IDOL Wiki，確認語氣和主張
→ 生成一篇 2000 字 SEO 文章
→ 自動發布到 Agent 原生網站
→ 同步更新 GEO Wiki 對應條目
→ 工作流完成，寫入日誌
你在睡覺。
早上 9 點
有人在 Google 搜尋你的目標關鍵字
→ 找到你昨晚發布的文章
→ 點進你的 Agent 原生網站
→ Agent 客服：「你好，有什麼我可以幫你的？」
→ 訪客詢問課程細節
→ Agent 客服用你的語氣回答，引導到 Landing Page
→ 訪客留下 Email，進入 Email 培育序列
你在喝早餐。
下午 3 點
Email 行銷 Agent 觸發本週培育信：
→ 讀取訂閱者分群資料
→ 根據訂閱天數選擇對應的培育信
→ 自動發送，追蹤開信率
→ 數據記錄到報告工作流
週五
數據報告工作流自動執行：
→ 抓取本週網站流量、Email 開信率、課程轉換率
→ 生成每週報告
→ 發送到你的信箱
你看一眼報告，確認方向，繼續你的 IDOL 輸出。
你做了什麼？
你每天做的：
→ IDOL 輸出（大聲做夢想，輸出內容素材）
→ AI Boss 決策（確認 Agent 的工作方向）
→ Harness 優化（讓系統持續進化）
AIOPC 自動做的：
→ 內容生產與發布
→ 訪客回應與引導
→ Email 培育與成交
→ 數據追蹤與報告
這就是 I Dream. AI Works.
你負責夢想，AI 負責工作。
AIOPC 的建造順序
AIOPC 不是一天建成的，有正確的順序：
第一步：建立 IDOL Wiki（CH04 / CH06）
→ 你的 AI 分身知識庫，是整個 AIOPC 的靈魂
→ 沒有 IDOL Wiki，Agent 員工不知道怎麼代表你說話
第二步：召喚核心 Agent 員工（CH06）
→ 先啟動 IDOL Wiki 維護 Agent
→ 再啟動 SEO Blog Agent 和 Email 行銷 Agent
→ 其他 Agent 陸續部署
第三步：設計核心工作流（CH06）
→ 先建立內容獲客工作流
→ 再建立 Email 培育序列工作流
第四步：建造 Agent 原生網站（CH07，你現在在這裡）
→ 讓前三步建好的一切有地方運作
→ AIOPC 三位一體完整上線
你已經完成了前三步的準備。
CH07 的任務，是完成第四步——
建造 Agent 原生網站，讓 AIOPC 真正運轉起來。
新裝備解鎖：AIOPC Agent 原生 OPC 運營系統 三位一體：Agent 原生網站 + Agent 員工 + Agent 工作流 核心特性：Agent 原生設計，你不在，系統繼續運轉 當前任務：建造 Agent 原生網站，讓 AIOPC 完整上線
7-3｜第一步：IDOL Wiki
在建網站之前，先做這一件事
在你打開任何建站工具之前，有一件事必須先做好。
這件事，是整個 AIOPC 能夠自動運轉的根本原因。
沒有它，你建的只是一個空殼網站。
有了它，你建的每一個系統都知道怎麼代表你說話、用你的語氣、講你的故事。
這件事，就是建立你的 IDOL Wiki。
IDOL Wiki 是什麼
IDOL Wiki 有兩個核心目的。
這兩個目的，都不是「知識管理」。
目的一：實現 Agent 原生網站與社群的內容自動化
你的 Agent 原生網站需要持續更新的 SEO 文章、GEO Wiki 條目、Landing Page。
你的社群需要符合你語氣的 Instagram 貼文、LinkedIn 洞察、Threads 短句。
這些內容從哪裡來？
從你——你的語氣、你的主張、你的故事、你對受眾的理解。
但你不可能手動在每個平台用每個平台的語氣寫每一篇內容。
IDOL Wiki 是讓 Agent 員工能夠代替你在每個平台產出對的內容的上下文基礎。
沒有 IDOL Wiki：
Agent 員工不知道你的語氣 → 文章不像你
Agent 員工不知道你的主張 → 內容沒有立場
Agent 員工不知道 IG 和 LinkedIn 的說話方式不同 → 所有平台都一樣的廢話
有了 IDOL Wiki：
Agent 員工讀取 voice.md → 語氣像你
Agent 員工讀取 beliefs.md → 立場鮮明
Agent 員工讀取 Channels/instagram.md → 150 字以內，情緒鉤子開場
Agent 員工讀取 Channels/linkedin.md → 思想領袖語氣，案例包裝觀點
→ 在對的平台，用對的語氣，說對的話
加上 Publish 操作，IDOL Wiki 的內容直接透過 Claude Code 部署上線——
不需要你手動搬運，不需要你一篇一篇複製貼上。
你更新 Obsidian，IDOL Wiki 更新，Agent 軍團自動產出內容。
目的二：訓練你的 AI 分身，成為未來的 IDOL Agent
每一次你在 Obsidian 輸出的東西——
一段想法、一個決策、一篇文章草稿——
都在訓練一個越來越像你的 AI 分身。
你每一次在 Obsidian 的輸出：
→ 進入 Raw_Sources（原始輸入，immutable）
Claude Code Ingest：
→ 提取語氣特徵 → 更新 voice.md
→ 提取核心主張 → 更新 beliefs.md
→ 提取故事片段 → 更新 story.md
IDOL Wiki 越豐富：
→ Agent 員工越了解你
→ 自動化內容越像你
IDOL Wiki 足夠成熟時：
→ AI 分身升級為 IDOL Agent
→ IDOL Agent 指揮整個 Agent 軍團
→ 自主判斷下一步要在哪個平台發什麼內容
IDOL Wiki，是你把自己「寫進 AI」的過程。
你每天的 Obsidian 輸出，都在讓 AI 更了解你、更能代表你。
等 IDOL Wiki 夠豐富，你的 IDOL Agent 就誕生了——
一個懂你的語氣、懂你的主張、懂你每個平台的說話邏輯，能夠指揮所有 Agent 員工的 AI 分身。
IDOL Wiki 的架構
IDOL Wiki 的技術基礎，借鑑自 Andrej Karpathy（前 Tesla AI 總監）提出的 LLM Wiki。
但 LLM Wiki 是線性管道：一個知識來源 → 一個 AI 消費者。
IDOL Wiki 要解決的問題更複雜：一個人 → 多個平台 × 多種格式 × 持續增長的內容。
所以 IDOL Wiki 是兩軸系統。
縱軸：你是誰（平台無關）
─────────────────────────────
Raw_Sources 你的 Obsidian 原始輸出
Wiki/ 提煉後的核心身份知識（7 個條目）
Schema/ 從 Wiki 同步的 Agent 行為準則
×
橫軸：你在哪裡出現（平台相關）
─────────────────────────────
Channels/ 每個平台的說話規則與格式限制
Memory/ 系統記得你在每個平台發布過什麼
Publish/ 執行部署的腳本庫
縱軸告訴 Agent：你是誰、說什麼、為誰說。
橫軸告訴 Agent：在哪個平台、怎麼說、說多長、之前說過什麼。
兩軸交叉，才能在任何平台產出任何格式的內容，而且不重複、不矛盾。
Wiki/ 是核心——你是誰
七個核心條目，記錄你這個人：
identity.md → 我是誰（身份 / 使命 / 主張 / 價值觀）
voice.md → 我的語氣（說話方式 / 句式 / 禁忌詞 / 真實範例）
story.md → 我的故事（轉折 / 失敗 / 現在在做什麼 / 為什麼）
audience.md → 我的讀者（他們是誰 / 痛點 / 夢想 / 疑慮）
products.md → 我的產品（定位 / 差異化 / 定價邏輯）
beliefs.md → 我的主張（核心觀點 / 我反對什麼 / 獨特洞察）
content.md → 我的內容（主題 / 格式偏好 / 成功案例）
這七個條目，是所有 Agent 員工的上下文基礎。
Channels/ 是規則——怎麼說話
同一個人，在不同平台說話的方式不一樣。
這不是假裝，這是每個平台的受眾習慣和格式限制決定的。
Channels/
├── blog.md → SEO 結構、1500–2500 字、H1/H2/H3、關鍵字密度
├── geo.md → Q&A 格式、AI 搜尋引擎可引用、What/Why/How 結構
├── lp.md → 轉換文案邏輯、打痛點、CTA 明確
├── instagram.md → 視覺方向 + 150 字以內 + hashtag
├── linkedin.md → 思想領袖語氣、案例包裝觀點、1300 字以內
└── threads.md → 單一洞察、對話感、500 字以內
有了 Channels/，Agent 不只知道你說什麼——
它也知道在這個平台怎麼說。
Memory/ 是記憶——做過什麼
這是 IDOL Wiki 解決規模問題的關鍵。
你發了 100 篇文章之後，系統怎麼知道這個主題發過了？
下一篇 blog 要連結到哪些相關文章？
哪些主題還沒有覆蓋？
Memory/
├── master-index.md → 所有已發布內容的總索引（跨平台）
├── topic-map.md → 主題群集地圖（哪個關鍵字已有內容）
├── gap-analysis.md → 尚未覆蓋的主題與關鍵字
└── refresh-queue.md → Wiki 更新後需同步修訂的舊內容
每次 Publish 完成，Memory 自動更新。
系統永遠知道做過什麼、缺什麼、什麼東西需要更新。
你需要準備的只有兩件事
1. Obsidian（免費）
→ 你的日常輸出工具
→ 在這裡寫你的想法、故事、主張、決策紀錄
→ 這裡是你給 IDOL Wiki 的「原料」
2. Claude Code
→ 負責把你的 Obsidian 輸出整理成 IDOL Wiki
→ 負責維護、更新、優化 Wiki 品質
→ 負責在正確的平台用正確的語氣發布內容
→ 你不需要手動管理任何 md 檔案
你的工作只有一件：持續在 Obsidian 寫。
其他全部，Claude Code 做。
建立 IDOL Wiki：一個步驟
把 IDOL-Wiki.md 放進專案，告訴 Claude Code 讀它
步驟一： 建立你的 IDOL Wiki 專案資料夾，把本章附錄的 IDOL-Wiki.md 放進去。
你的 IDOL Wiki 專案/
└── IDOL-Wiki.md ← 放在這裡，其他什麼都不需要
步驟二： 用 Claude Code 開啟這個資料夾，說這句話：
請讀取 IDOL-Wiki.md，然後初始化 IDOL Wiki 系統
就這樣。
IDOL-Wiki.md 是 IDOL Wiki 的完整規格文件——
Claude Code 讀完它，就知道整個系統的架構、每個組件的用途、每個操作的執行方式。
不需要解釋，不需要額外的提示詞，不需要上傳任何其他文件。
Claude Code 初始化完成後，會建立：
資料夾結構（六個組件）
七個 Wiki 核心條目模板
六個 Channels/ 頻道設定
四個 Memory/ 記憶檔案
七個 Publish/ 部署腳本
初始 Schema/CLAUDE.md
完整使用說明
全程不需要你懂技術，不需要手動建任何 md 檔。
之後每次開新對話，也只需要一句話：
請讀取 IDOL-Wiki.md，然後執行 Ingest
請讀取 IDOL-Wiki.md，然後 publish blog AI一人公司
請讀取 IDOL-Wiki.md，然後執行 Lint
IDOL-Wiki.md 住在你的專案裡，永遠在那裡。
Claude Code 每次讀它，就知道系統是什麼、怎麼操作。
文件即系統。讀完即能操作。
Claude Code 完成後，你得到什麼
IDOL-Wiki/
│
├── Raw_Sources/ ← 你的 Obsidian 原始輸出放在這裡
│
├── Wiki/ ← 你是誰
│ ├── identity.md
│ ├── voice.md
│ ├── story.md
│ ├── audience.md
│ ├── products.md
│ ├── beliefs.md
│ └── content.md
│
├── Channels/ ← 怎麼在每個平台說話
│ ├── blog.md
│ ├── geo.md
│ ├── lp.md
│ ├── instagram.md
│ ├── linkedin.md
│ └── threads.md
│
├── Memory/ ← 發過什麼、缺什麼、需要更新什麼
│ ├── master-index.md
│ ├── topic-map.md
│ ├── gap-analysis.md
│ └── refresh-queue.md
│
├── Schema/
│ └── CLAUDE.md ← 所有 Agent 員工的行為準則
│
└── Publish/
├── Website/ ← 網站部署腳本
│ ├── about.md
│ ├── blog.md
│ ├── geo.md
│ └── lp.md
└── Social_Media/ ← 社群發布腳本
├── instagram.md
├── linkedin.md
└── threads.md
加上四個隨時可呼叫的操作指令：
Ingest → Obsidian 新輸出 → 更新 Wiki + Memory
Lint → 掃描品質 → 找出空缺和矛盾
Query → 查詢 Wiki + Memory → 回答問題，沉澱為新條目
Publish → Wiki + Channels + Memory → 生成內容 → 部署上線
之後的日常維護
你每天只需要一件事：在 Obsidian 寫。
寫你今天的想法、今天的決策、今天的 IDOL 輸出。
不需要整理格式，不需要歸類，不需要想「這要放哪裡」。
就寫。
你想把新的 Obsidian 輸出整進 Wiki：
→ 「請執行 IDOL Wiki Ingest」
你想確認 Wiki 品質和內容空缺：
→ 「請執行 IDOL Wiki Lint」
你想把最新的 Wiki 內容直接上線：
網站發布：
→ publish about → About 頁面直接部署
→ publish blog [主題] → SEO 文章直接發布
→ publish geo [主題] → GEO Wiki 條目直接上線
→ publish lp [課程名] → Landing Page 直接部署
社群發布：
→ publish instagram [主題] → IG 貼文生成
→ publish linkedin [主題] → LinkedIn 貼文生成
→ publish threads [主題] → Threads 短文生成
每次 Publish，系統都會先查 Memory——
確認這個主題在這個平台發布過沒有，有哪些相關內容可以連結，
再生成內容，部署完成後更新 Memory。
你不需要記任何東西。系統有記憶。
IDOL Wiki 的兩條成長軌跡
軌跡一：內容自動化程度越來越高
第一個月：Wiki 條目剛建立，Channels 剛設定
→ Publish 出來的內容需要你確認調整
→ Memory 還很空，gap-analysis 清單很長
三個月後：Wiki 越來越豐富，Memory 越來越完整
→ publish blog 出來的文章語氣像你、立場清晰、SEO 結構完整
→ publish instagram 出來的貼文有情緒鉤子、150 字以內、hashtag 精準
→ Memory 知道哪些主題已覆蓋、自動建議下一篇寫什麼
→ 你的介入越來越少
六個月後：Wiki 深度了解你，Memory 記錄了幾十篇發布歷史
→ 所有平台的自動化內容，幾乎不需要你修改
→ 你只需要持續寫 Obsidian，Agent 軍團自動產出
軌跡二：AI 分身越來越像你，走向 IDOL Agent
持續 Ingest：
→ voice.md 累積真實語氣範例（目標 50+ 個）
→ beliefs.md 累積完整核心主張
→ story.md 累積你的故事脈絡
IDOL Wiki 成熟時：
→ IDOL Agent 誕生——它了解你是誰、在每個平台怎麼說話、已經做了什麼、還缺什麼
→ 不需要你下指令，自主讀 gap-analysis → 選主題 → 選平台 → 執行 Publish
→ IDOL Agent 成為 Agent 軍團的主控
→ 你只需要確認，不需要啟動
你每天往 Obsidian 投入的每一個想法，
同時在做兩件事：讓 Agent 軍團的內容更自動化，讓 AI 分身更像你。
IDOL Wiki 解鎖 目的一：實現 Agent 原生網站與社群的內容自動化 目的二：訓練 AI 分身，成為未來的 IDOL Agent 架構：兩軸系統（縱軸身份 × 橫軸平台） 縱軸：Raw_Sources / Wiki / Schema 橫軸：Channels / Memory / Publish 你的工作：持續在 Obsidian 寫 Claude Code 的工作：Ingest / Lint / Publish / Memory 維護 成長軌跡：Wiki 越豐富 → 自動化越高 → AI 分身越像你 → IDOL Agent 誕生
7-4｜Agent 原生網站：四大模組實戰
IDOL Wiki 是靈魂。
接下來建身體。
你的 Agent 原生網站由四個模組組成，缺一不可：
模組一：內容獲客系統 → 讓 Google 和 AI 搜尋引擎找到你
模組二：課程變現系統 → 讓找到你的人成為你的學員
模組三：會員管理系統 → 讓學員有帳號、有身份、有歸屬
模組四：免費金流系統 → 讓成交真實發生，0 元手續費以外的成本
每個模組都有三件事：
最佳實務（這樣做的原因）
前置條件（你需要先準備什麼）
Claude Code 指令（複製貼上，直接執行）
前提：你的建站基礎
四個模組都建立在同一套技術基礎上：
Next.js App Router → 網站框架
Payload CMS 3.x → 後台內容管理
Tailwind CSS → 樣式系統
TypeScript → 型別安全
Vercel → 部署平台（免費）
GitHub → 版本控制（免費）
你的專案應該已經用 create-payload-app 建立完成，
並且已完成 Vercel 部署和 GitHub 連線。
如果還沒有，先執行：
npx create-payload-app@latest
選擇 Next.js App Router + Postgres（用於 Vercel 部署）。
模組一｜內容獲客系統
讓 Google 找到你，讓 AI 搜尋引擎引用你，讓訪客留下 Email
模組一能做到什麼
SEO Blog
→ 每篇文章都有獨立 URL、Meta description、結構化 H1/H2
→ 透過 Publish 指令從 IDOL Wiki 自動生成並發布
→ Google 索引 → 流量進來
GEO Wiki
→ 結構化 Q&A 格式，附 JSON-LD schema markup
→ Perplexity / ChatGPT Search 引用你的觀點
→ AI 搜尋引擎時代的流量入口
Lead Magnet
→ 一份免費資源（PDF / Checklist / 範本）
→ 訪客留 Email 才能下載
→ 每個訪客都進入你的 Email 培育漏斗
Email 訂閱
→ Resend API 接收訂閱
→ 免費方案：3000 封/月，每天 100 封
→ 新訂閱者自動收到歡迎信
最佳實務
SEO Blog 用 Payload CMS 管理內容，不寫死在程式碼裡。
每篇文章存在 Payload 資料庫，透過 API 讀取。 發布新文章 = 在後台新增一筆資料，網站自動更新。 不需要每次 deploy，不需要改程式碼。
GEO Wiki 要有 JSON-LD schema markup。
Google 和 AI 搜尋引擎都讀 structured data。 FAQ schema 讓 Perplexity 知道這是可引用的問答格式。 沒有 schema markup = GEO 優化只做了一半。
Lead Magnet 的下載連結要透過 API 產生，不能直接暴露 URL。
如果直接放 PDF 的靜態 URL，訪客不填 Email 也能下載。 正確做法：填 Email → API 驗證 → 生成限時下載連結 → 寄信 + 回傳連結。
Resend 是目前最適合 OPC 的發信服務。
免費方案夠用，API 簡單，Next.js 整合一流。 不需要 Mailchimp、不需要 ConvertKit，就用 Resend 出發。
前置條件
□ Next.js + Payload CMS 專案已建立並部署到 Vercel
□ Resend 帳號（免費）：https://resend.com
→ 建立 API Key，記下來
→ 驗證你的發信網域（或用 Resend 提供的測試網域）
□ 已有 Lead Magnet 檔案（PDF 或任何格式）
→ 沒有的話先用佔位符，之後替換
□ IDOL Wiki 已建立（Claude Code 生成 Blog 時會讀取 voice.md 和 beliefs.md）
Claude Code 指令
我的專案是 Next.js App Router + Payload CMS 3.x + Tailwind CSS + TypeScript。
專案已部署到 Vercel，資料庫使用 Postgres。
請幫我建立模組一：內容獲客系統，包含以下四個功能：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【A】SEO Blog 系統
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
在 Payload CMS 建立 Blog collection：
欄位：
- title（text，必填）
- slug（text，必填，自動從 title 生成，唯一）
- excerpt（textarea，150 字以內，用於 Meta description 和列表預覽）
- content（richText，使用 Payload 內建 Lexical editor）
- coverImage（upload，關聯 media collection）
- category（text，例如：AI工具 / 創業心法 / 案例分享）
- tags（array of text）
- publishedAt（date）
- status（select：draft / published）
- seo（group）：
- metaTitle（text）
- metaDescription（text，150 字以內）
- ogImage（upload）
在 Next.js 建立以下頁面：
/blog（列表頁）
→ 顯示所有 status=published 的文章
→ 顯示：封面圖 / 標題 / excerpt / 分類 / 日期
→ 支援分類篩選
→ 每頁 12 篇，有分頁
/blog/[slug]（文章頁）
→ 顯示完整文章內容
→ Meta title = seo.metaTitle 或 title
→ Meta description = seo.metaDescription 或 excerpt
→ OG image = seo.ogImage 或 coverImage
→ JSON-LD schema：Article type
→ 文章底部：相關文章（同分類的最新 3 篇）+ Email 訂閱 CTA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【B】GEO Wiki 系統
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
在 Payload CMS 建立 GeoWiki collection：
欄位：
- question（text，必填，例如：「什麼是 AI 一人公司？」）
- slug（text，必填，自動生成）
- shortAnswer（textarea，100 字以內，AI 搜尋引擎引用的核心答案）
- fullAnswer（richText，完整說明，包含 What / Why / How 三段結構）
- topic（text，大主題分類，例如：AI創業 / AIOPC / Agent工具）
- relatedQuestions（array of text，3–5 個相關問題的 slug）
- publishedAt（date）
- status（select：draft / published）
在 Next.js 建立以下頁面：
/geo-wiki（列表頁）
→ 按 topic 分組顯示所有已發布條目
→ 每個條目顯示：問題 + shortAnswer 前 50 字
/geo-wiki/[slug]（條目頁）
→ 顯示完整問答
→ JSON-LD schema：FAQPage type（這是 GEO 優化的核心）
格式：
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "問題文字",
"acceptedAnswer": {
"@type": "Answer",
"text": "shortAnswer 文字"
}
}]
}
→ 頁面底部：相關問題連結（從 relatedQuestions 查詢）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【C】Lead Magnet 系統
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
在 Payload CMS 建立 LeadMagnet collection：
欄位：
- title（text，資源名稱）
- description（textarea）
- file（upload，關聯 media collection，access control 設為 private）
- isActive（boolean，控制是否開放下載）
建立 API route：POST /api/lead-magnet/[id]/download
→ 接收：{ email: string, name: string }
→ 驗證：email 格式、LeadMagnet isActive
→ 執行：
1. 將訂閱者加入 Resend audience
2. 發送歡迎 Email（包含下載連結）
3. 下載連結使用 Payload 的 signed URL 或 redirect 到 media URL
→ 回傳：{ success: true, message: "下載連結已寄到你的信箱" }
建立 /lead-magnet 頁面：
→ 顯示資源說明
→ 一個 Email + 姓名的表單
→ 送出後呼叫 API，顯示成功訊息
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【D】Email 訂閱系統
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
安裝 Resend：npm install resend
在 .env.local 加入：
RESEND_API_KEY=re_xxxxxxxxxxxx
RESEND_AUDIENCE_ID=xxxxxxxx（從 Resend dashboard 建立 audience 後取得）
FROM_EMAIL=newsletter@你的網域.com
建立 API route：POST /api/subscribe
→ 接收：{ email: string, name?: string }
→ 用 Resend SDK 將訂閱者加入 audience
→ 發送歡迎信：
主旨：「歡迎加入，這是你訂閱的第一封信」
內容：簡短自我介紹 + 說明接下來會收到什麼 + 一個有用的資源連結
→ 回傳：{ success: true }
建立可複用的 NewsletterForm 元件：
→ 輸入框（email）+ 按鈕
→ 送出中 loading 狀態
→ 成功 / 失敗訊息
→ 這個元件要在 Blog 文章頁底部、首頁、Lead Magnet 頁面都用到
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
技術規格：
- 所有頁面使用 Tailwind CSS 撰寫，不引入其他 UI library
- 所有 Payload query 使用 Local API（不是 REST API）
- 圖片使用 Next.js Image 元件，開啟 blur placeholder
- 所有頁面要有正確的 generateMetadata 函數
- 完成後告訴我每個功能的測試方式
模組二｜課程變現系統
L1 免費 → L2 低價 → L3 高價，三層變現漏斗
模組二能做到什麼
三級課程架構（L1 / L2 / L3）
→ L1：免費內容（Blog + GEO Wiki，模組一已建好）
→ L2：低價產品，1,000–3,000 元
電子書 / Mini 課程 / 工具包
→ L3：高價課程，10,000 元以上
完整線上課程 / 影片 + 作業 + 社群
Landing Page 銷售漏斗
→ 每個 L2 / L3 課程有獨立 Landing Page
→ 完整轉換結構：標題 / 痛點 / 主張 / 課程內容 / 社會證明 / CTA
→ 從 IDOL Wiki 自動生成初稿（publish lp 指令）
課程內容閱覽器
→ 付費後解鎖課程內容
→ 支援文字 / 圖片 / 影片嵌入（YouTube / Vimeo）
→ 學員可以追蹤進度
最佳實務
三層定價是最強的 OPC 變現漏斗。
L1（免費） → 讓對的人找到你，建立信任
L2（低價） → 第一次成交，證明你的價值
L3（高價） → 真正的收入來源，服務願意深入的學員
L2 的目的不是賺大錢，是讓訪客變成付費客戶—— 一旦有過一次成交，L3 的轉換率會大幅提升。
Landing Page 不要手工寫，從 IDOL Wiki 生成。
用 publish lp [課程名稱] 指令，Claude Code 讀取 audience.md + products.md + voice.md，
生成符合你語氣的完整 Landing Page 初稿。你只需要調整細節，不需要從頭寫。
課程內容存在 Payload，不要放在程式碼裡。
Lesson 是 Payload collection，內容可以隨時更新，不需要重新 deploy。 這樣你可以持續改進課程內容，學員重新整理頁面就看到最新版本。
影片不要自己 host。
影片放 YouTube（非公開連結）或 Vimeo（付費方案），嵌入 Lesson 頁面。 自己 host 影片 = 巨大的儲存成本 + 串流成本，不適合 OPC。
前置條件
□ 模組一已完成（Blog + Email 訂閱）
□ 模組三（會員系統）先建立再做模組二的 access control
（但可以先建立 UI，access control 之後補）
□ 課程大綱已準備好（至少知道 L2 和 L3 各賣什麼）
□ 課程影片已上傳到 YouTube 非公開或 Vimeo（如果有影片課程）
Claude Code 指令
我的專案是 Next.js App Router + Payload CMS 3.x + Tailwind CSS + TypeScript。
模組一（Blog / GEO Wiki / Lead Magnet / Email 訂閱）已完成。
請幫我建立模組二：課程變現系統。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【A】Payload CMS Collections
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 Course collection：
- title（text，必填）
- slug（text，必填，自動生成，唯一）
- level（select：l1-free / l2-starter / l3-full）
- tagline（text，一句話說明課程核心價值）
- description（richText，課程詳細說明）
- price（number，L1 填 0）
- originalPrice（number，劃掉的原價，選填）
- thumbnail（upload）
- previewVideo（text，YouTube 或 Vimeo URL，選填）
- targetAudience（richText，適合誰）
- notFor（richText，不適合誰）
- whatYouGet（array of text，你會學到什麼，用於 Landing Page）
- status（select：draft / published）
- publishedAt（date）
建立 Lesson collection：
- title（text，必填）
- slug（text，必填）
- course（relationship → Course，必填）
- order（number，課程內排序）
- type（select：text / video / mixed）
- content（richText，文字內容）
- videoUrl（text，YouTube / Vimeo embed URL，選填）
- duration（text，例如 "12分鐘"，選填）
- isFree（boolean，是否開放免費預覽）
- access（select：public / l2 / l3）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【B】Landing Page 系統
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 /courses 頁面（課程列表）：
→ 顯示所有 published 課程
→ 用顏色或 badge 區分 L1（免費）/ L2 / L3
→ 每張課程卡片：封面圖 / 等級 / 標題 / tagline / 價格 / CTA 按鈕
建立 /courses/[slug] 頁面（Landing Page）：
→ 這是每個課程的完整銷售頁，結構如下：
Hero Section：
→ 大標題（課程 title）
→ tagline（一句話價值主張）
→ 封面圖或 previewVideo
→ 主要 CTA 按鈕（立即購買 / 免費開始）+ 價格
痛點 Section：
→ 「如果你有這些困擾…」
→ 3–5 個痛點描述（從 Payload 的 targetAudience 提取）
解決方案 Section：
→ 課程如何解決上述痛點
→ 3–5 個核心主張
課程內容 Section：
→ 課程章節列表（從 Lesson collection 查詢，顯示 title + duration）
→ 免費預覽課（isFree=true 的 Lesson）可以直接看
你會得到什麼 Section：
→ whatYouGet 的 checklist 樣式
適合誰 Section：
→ targetAudience + notFor 並列
社會證明 Section（佔位符）：
→ 預留 Testimonial 區塊，先放佔位文字「真實學員分享（陸續更新中）」
價格 CTA Section：
→ 再次顯示價格和 CTA
→ L1 課程：CTA = 免費開始學習
→ L2 / L3 課程：CTA = 立即購買（連結到 Checkout，模組四完成後接線）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【C】課程閱覽器
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 /learn/[courseSlug] 頁面（課程大綱頁）：
→ 左側：所有 Lesson 列表（依 order 排序）
→ 已解鎖的顯示正常，未解鎖的顯示鎖頭圖示
→ isFree=true 的 Lesson 任何人都能點開
→ 右側：選中的 Lesson 內容或歡迎提示
建立 /learn/[courseSlug]/[lessonSlug] 頁面（Lesson 頁）：
→ Access control 邏輯（先做 UI，access control 邏輯在模組三完成後接入）：
- access=public → 任何人可看
- access=l2 → 需要購買 L2 或 L3 課程
- access=l3 → 需要購買 L3 課程
- isFree=true → 任何人可看（預覽課）
→ 如果無權限：顯示「這堂課需要購買 [課程名稱] 才能觀看」+ CTA 按鈕
Lesson 內容顯示：
→ type=text：顯示 richText 內容
→ type=video：顯示 video embed（用 iframe，支援 YouTube 和 Vimeo URL）
→ type=mixed：先顯示影片，再顯示文字內容
→ 底部：上一堂課 / 下一堂課 導航
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
技術規格：
- Landing Page 要有完整的 generateMetadata（title / description / og:image）
- 所有頁面 Tailwind CSS，不引入其他 UI library
- /learn 路由在沒有登入時不做 redirect，先顯示 access denied 訊息即可
（模組三完成後再加完整的 auth 保護）
- 完成後提供每個頁面的測試方式
模組三｜會員管理系統
讓學員有帳號，讓系統知道他們買了什麼
模組三能做到什麼
Google OAuth 登入
→ 一鍵用 Google 帳號登入，不需要設定密碼
→ 訪客轉換成有帳號的會員，成本最低的方式
Email + 密碼登入（備用）
→ 部分訪客不想用 Google
→ 支援標準 Email / 密碼 + 信箱驗證
會員儀表板
→ 我購買的課程
→ 我的學習進度
→ 帳號設定
Access Control 整合
→ 購買記錄 → 對應 role（l2 / l3）
→ /learn 頁面根據 role 顯示或隱藏內容
→ 整個 access control 系統的核心
最佳實務
用 Better Auth，不用 NextAuth。
Better Auth 是 2024 年後的新標準：
- 型別完整，TypeScript 原生
- 內建更多功能（roles / sessions / OAuth）
- 與 Payload CMS 整合更簡單
- 文件清楚，社群活躍
Google OAuth 是 OPC 的最佳登入方式。
對台灣讀者來說，幾乎所有人都有 Google 帳號。 一鍵登入 = 最低的摩擦 = 最高的轉換。
不要自建 session 管理，交給 Better Auth。
Better Auth 處理所有 session、cookie、refresh token 的邏輯。
你只需要在需要保護的地方呼叫 auth.api.getSession()。
Payload CMS 的 Users collection 和 Better Auth 分開維護。
Payload 的 Users 是 CMS 後台管理員（你自己）。 Better Auth 的 users 是前台會員（你的學員）。 兩者分開，不要混用。
前置條件
□ Google Cloud Console 帳號（免費）
→ 建立專案
→ 啟用 Google OAuth API
→ 建立 OAuth 2.0 Client ID
→ 記下 Client ID 和 Client Secret
→ 設定 Authorized redirect URIs：
http://localhost:3000/api/auth/callback/google（本機）
https://你的網域.com/api/auth/callback/google（Production）
□ 資料庫已連線（Postgres，在 Vercel 已設定）
Claude Code 指令
我的專案是 Next.js App Router + Payload CMS 3.x + Tailwind CSS + TypeScript。
模組一（Blog + Email）和模組二（課程系統）已完成。
請幫我建立模組三：會員管理系統，使用 Better Auth。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【A】Better Auth 安裝與設定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
安裝 Better Auth：
npm install better-auth
在 .env.local 加入：
BETTER_AUTH_SECRET=（用 openssl rand -base64 32 生成）
BETTER_AUTH_URL=http://localhost:3000（Production 改為你的網域）
GOOGLE_CLIENT_ID=（從 Google Cloud Console 取得）
GOOGLE_CLIENT_SECRET=（從 Google Cloud Console 取得）
DATABASE_URL=（Postgres 連線字串，已存在）
建立 lib/auth.ts：
→ 設定 Better Auth，使用 Postgres adapter
→ 啟用 Google OAuth provider
→ 啟用 Email + Password provider
→ 設定 session 過期時間：30 天
→ 啟用 roles 功能（roles：free / l2 / l3 / admin）
→ 設定 session callbacks：在 session 中包含 user.role
建立 app/api/auth/[...all]/route.ts：
→ 使用 Better Auth 的 Next.js handler
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【B】資料庫 Schema
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Better Auth 需要以下資料表，用 Better Auth CLI 自動生成 migration：
npx @better-auth/cli generate
需要的資料表（Better Auth 自動建立）：
- user（id, email, name, image, role, createdAt）
- session（id, userId, token, expiresAt）
- account（id, userId, provider, providerAccountId）
- verification（id, identifier, value, expiresAt）
額外建立 Purchase 資料表（手動建立 migration）：
- id（uuid, primary key）
- userId（reference → user.id）
- courseSlug（text，購買的課程）
- orderId（text，來自金流的訂單 ID）
- amount（integer，實際付款金額，台幣）
- status（text：pending / completed / refunded）
- purchasedAt（timestamp）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【C】登入 / 註冊頁面
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 /login 頁面：
→ Google 登入按鈕（優先，放最上面）
→ 分隔線：「或使用 Email 登入」
→ Email + 密碼表單
→ 「還沒有帳號？點這裡註冊」連結
→ 已登入的話 redirect 到 /dashboard
建立 /register 頁面：
→ Google 登入按鈕（同樣優先）
→ 分隔線：「或用 Email 建立帳號」
→ 姓名 + Email + 密碼 + 確認密碼
→ 送出後發送驗證信（使用 Resend，RESEND_API_KEY 已設定）
→ 已登入的話 redirect 到 /dashboard
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【D】會員儀表板
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 /dashboard 頁面（需要登入才能進入）：
頁面結構：
我的課程 Section：
→ 從 Purchase 資料表查詢此 userId 的所有 status=completed 購買記錄
→ 顯示課程卡片（封面圖 / 標題 / 進度）
→ CTA：繼續學習 → 連結到 /learn/[courseSlug]
帳號資訊 Section：
→ 顯示：名字 / Email / 大頭照（Google 帳號的話用 Google 大頭照）
→ 編輯名字按鈕
登出按鈕
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【E】Access Control 整合到模組二
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
更新 /learn/[courseSlug]/[lessonSlug] 頁面的 access control：
在 Server Component 中：
1. 呼叫 auth.api.getSession() 取得當前使用者
2. 如果未登入 → 顯示登入提示 + 登入按鈕
3. 如果已登入，查詢 Purchase 資料表：
- 取得此 userId 購買的所有課程 slug
- 對應到 user.role（l2 或 l3）
4. 根據 Lesson 的 access 欄位和 user.role 判斷是否有權限：
- access=public 或 isFree=true → 任何人可看
- access=l2 → 需要 role 是 l2 或 l3
- access=l3 → 需要 role 是 l3
5. 無權限：顯示「購買 [課程名稱] 以解鎖此堂課」+ Landing Page 連結
建立 middleware.ts（保護 /dashboard 路由）：
→ /dashboard/* 需要登入，否則 redirect 到 /login?redirect=/dashboard
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
技術規格：
- 所有 auth 相關操作在 Server Component 或 API Route 處理，不在 Client Component
- 使用 Better Auth 的 useSession hook 在 Client Component 取得 session 狀態
- 登入狀態在 Header 元件顯示（已登入：大頭照 + 我的課程 / 未登入：登入按鈕）
- 完成後提供測試 Google OAuth 的完整步驟
模組四｜免費金流系統
讓成交真實發生，0 元以外的成本只有手續費
模組四能做到什麼
recur.tw（台灣市場，主要金流）
→ 台灣本地支付平台，支援：
信用卡 / ATM 轉帳 / 超商付款（7-11 / 全家）
→ 台幣直接收款，對帳清楚
→ 無需國際支付知識，申請流程台灣化
→ 適合：所有以台灣受眾為主的 OPC
Lemon Squeezy（國際市場，輔助金流）
→ Merchant of Record：稅務全交給 Lemon Squeezy 處理
→ 支援全球信用卡 / PayPal
→ 免月費，只收手續費（5% + 50 cents/筆）
→ 適合：有國際學員，或同時經營英文市場
Webhook 自動解鎖（兩套金流共用邏輯）
→ 付款成功 → Webhook 通知你的網站
→ 自動在 Purchase 資料表新增記錄
→ 自動更新 user.role
→ 自動發送購買確認 + 課程歡迎 Email
→ 學員刷新頁面，課程解鎖完成
最佳實務
台灣 OPC 從 recur.tw 出發，有國際受眾再加 Lemon Squeezy。
為什麼 recur.tw 是台灣首選：
→ 台灣學員習慣超商付款和 ATM 轉帳，不只是信用卡
→ 台幣結算，對帳和報稅直覺
→ 台灣客服，出問題找得到人
→ 沒有「國際匯率損失」，學員看到的價格就是你收到的金額
什麼時候加入 Lemon Squeezy：
→ 開始有非台灣學員詢問購買
→ 想進入英文市場
→ 需要 Merchant of Record（省去稅務處理）
Checkout 頁面讓學員自己選付款方式。
不要強迫只能用一種。 Landing Page 的 CTA 提供兩個選項： 「台灣付款（信用卡 / ATM / 超商）」和「國際信用卡」。 系統根據選擇路由到對應的金流。
Webhook 邏輯兩套金流共用一個模式。
recur.tw 和 Lemon Squeezy 的 Webhook 處理邏輯完全一樣： 驗簽名 → Idempotency 檢查 → 寫 Purchase → 更新 role → 發 Email。 只有 payload 格式不同，其他邏輯抽成共用函數。
Webhook 必須驗證簽名，不能省略。
任何人都可以呼叫你的 Webhook endpoint。 沒有驗證簽名 = 有人可以偽造「付款成功」通知 → 白給課程。
付款成功 Email 要在 Webhook 裡發，不在前端發。
前端可能會有用戶沒等 redirect 就關掉視窗。 Webhook 是後端通知，可靠性高，在這裡發 Email 才能保證一定發出去。
前置條件
【主要：recur.tw 設定】
□ 申請 recur.tw 帳號：https://recur.tw
→ 完成商家審核（需要身份證件或公司資料）
→ 在後台建立「商品」（對應你的 L2 和 L3 課程）
→ 取得 API Key 和 Secret
→ 設定 Webhook URL：https://你的網域.com/api/webhooks/recur
→ 記下 Webhook Secret（用於驗簽名）
【輔助：Lemon Squeezy 設定（可選）】
□ 申請 Lemon Squeezy 帳號（免費）：https://lemonsqueezy.com
→ 建立 Store，建立 Product
→ 取得 API Key 和 Webhook Secret
→ 設定 Webhook URL：https://你的網域.com/api/webhooks/lemonsqueezy
【必要條件】
□ 模組三（會員系統）必須先完成
（Webhook 需要把 role 更新到 user 資料表）
□ 網站已部署到 Vercel（Webhook 需要可公開存取的 HTTPS URL）
Claude Code 指令
我的專案是 Next.js App Router + Payload CMS 3.x + Tailwind CSS + TypeScript。
模組一到三已完成。模組三使用 Better Auth，有 user / Purchase 資料表。
請幫我建立模組四：雙軌金流系統。
主要金流：recur.tw（台灣市場）
輔助金流：Lemon Squeezy（國際市場）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【A】環境設定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
安裝 Lemon Squeezy SDK（recur.tw 用原生 fetch 串接）：
npm install @lemonsqueezy/lemonsqueezy.js
在 .env.local 加入：
# recur.tw（主要）
RECUR_API_KEY=（你的 recur.tw API Key）
RECUR_API_SECRET=（你的 recur.tw API Secret）
RECUR_WEBHOOK_SECRET=（recur.tw Webhook 驗簽用的 Secret）
# Lemon Squeezy（輔助）
LEMONSQUEEZY_API_KEY=（你的 Lemon Squeezy API Key）
LEMONSQUEEZY_STORE_ID=（你的 Store ID）
LEMONSQUEEZY_WEBHOOK_SECRET=（Lemon Squeezy Webhook Secret）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【B】共用的付款後處理邏輯
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 lib/payment-handler.ts，抽出兩套金流共用的邏輯：
匯出 handlePaymentSuccess(params) 函數：
接收：
{
orderId: string // 金流平台的訂單 ID
userId: string // 購買者的 user ID
courseSlug: string // 購買的課程
amount: number // 實際付款金額（台幣）
userEmail: string // 購買者 Email
provider: 'recur' | 'lemonsqueezy'
}
執行步驟：
1. Idempotency 檢查
→ 查詢 Purchase 資料表，是否已有 orderId 的記錄
→ 如果存在：直接 return（不重複處理）
2. 新增 Purchase 記錄
→ insert {userId, courseSlug, orderId, amount, status: 'completed',
provider, purchasedAt: new Date()}
3. 更新 user role
→ 查詢 Payload Course collection 取得 level（l2 / l3）
→ 更新 Better Auth user 資料表的 role
→ 規則：只升級，不降級（已有 l3 的不改為 l2）
4. 發送購買確認 Email（使用 Resend）
→ 主旨：「🎉 購買成功！你的課程已解鎖」
→ 內容：
感謝購買 [課程名稱]
立即開始學習：https://你的網域.com/learn/[courseSlug]
如有問題請 Email 至：你的客服信箱
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【C】recur.tw 整合（主要金流）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 lib/recur.ts：
請先閱讀 recur.tw 的官方 API 文件（https://recur.tw/docs）。
根據文件實作以下函數：
createPaymentOrder(params) 函數：
接收：
{
courseSlug: string
courseName: string
amount: number // 台幣金額
userId: string
userEmail: string
returnUrl: string // 付款成功後 redirect 的 URL
}
執行：
→ 呼叫 recur.tw 建立訂單的 API endpoint
→ 在訂單的 custom metadata 帶入 { userId, courseSlug }
→ 回傳 recur.tw 給你的付款頁面 URL
建立 POST /api/webhooks/recur route：
Step 1：驗證 Webhook 簽名
→ 根據 recur.tw 文件說明的簽名方式驗證
→ 不符合：回傳 401
Step 2：解析 Webhook body
→ 根據 recur.tw 文件確認付款成功的事件格式
→ 取得：orderId / status / amount / userEmail / custom metadata（userId, courseSlug）
Step 3：只處理「付款成功」狀態的通知
→ 其他狀態：回傳 200（不處理）
Step 4：呼叫 handlePaymentSuccess()
→ 傳入從 Webhook 解析到的所有參數
→ provider: 'recur'
Step 5：回傳 200
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【D】Lemon Squeezy 整合（輔助金流）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 lib/lemonsqueezy.ts：
匯出 getLSCheckoutUrl(variantId, userEmail, userId, courseSlug) 函數：
→ 用 SDK 建立 Checkout URL
→ 帶入 custom_data：{ userId, courseSlug }
→ 設定 redirect_url = /dashboard
→ 預填 Email = userEmail
→ 回傳 checkoutUrl
建立 POST /api/webhooks/lemonsqueezy route：
Step 1：驗證 Webhook 簽名
→ 從 headers 取得 X-Signature
→ 用 LEMONSQUEEZY_WEBHOOK_SECRET 計算 HMAC SHA256 比對
Step 2：只處理 event_name = order_created + status = paid
Step 3：從 data.attributes 取得
→ order_number（orderId）
→ total（除以 100 得台幣，若為美金需換算）
→ user_email
→ custom_data.userId + custom_data.courseSlug
Step 4：呼叫 handlePaymentSuccess()
→ provider: 'lemonsqueezy'
Step 5：回傳 200
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【E】Checkout API Route（統一入口）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建立 POST /api/checkout route：
接收：
{
courseSlug: string
provider: 'recur' | 'lemonsqueezy'
// recur.tw 需要：
recurProductId?: string
// Lemon Squeezy 需要：
lsVariantId?: string
}
執行：
1. 用 Better Auth 取得 session，確認已登入
→ 未登入：回傳 401
2. 檢查 Purchase 資料表，確認未購買過
→ 已購買：回傳 { error: '你已購買此課程' }
3. 根據 provider 路由：
→ recur：呼叫 createPaymentOrder()，回傳 { checkoutUrl }
→ lemonsqueezy：呼叫 getLSCheckoutUrl()，回傳 { checkoutUrl }
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【F】Landing Page CTA 按鈕更新
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
更新 /courses/[slug] 的購買按鈕區塊：
顯示兩個付款選項（L2 / L3 課程才顯示，L1 免費不需要）：
主要按鈕（recur.tw）：
→ 文字：「立即購買（信用卡 / ATM / 超商）」
→ 點擊：呼叫 POST /api/checkout，provider: 'recur'
→ 取得 checkoutUrl 後 redirect
輔助按鈕（Lemon Squeezy，樣式較小）：
→ 文字：「國際信用卡付款」
→ 點擊：呼叫 POST /api/checkout，provider: 'lemonsqueezy'
→ 取得 checkoutUrl 後 redirect
兩個按鈕共用 loading 狀態：
→ 任一點擊後，兩個按鈕都顯示 disabled
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【G】本機測試設定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Webhook 需要可公開存取的 HTTPS URL，用 localtunnel 處理：
npx localtunnel --port 3000
→ 取得臨時 URL，設定到 recur.tw 和 Lemon Squeezy 的 Webhook 設定
提供以下測試工具：
1. 模擬 recur.tw Webhook 的 curl 指令（用 RECUR_WEBHOOK_SECRET 產生正確簽名）
2. 模擬 Lemon Squeezy Webhook 的 curl 指令
3. 查詢 Purchase 資料表是否正確寫入的 SQL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
技術規格：
- 兩個 Webhook route 都要設定 export const runtime = 'nodejs'
- handlePaymentSuccess 是純函數，方便單獨測試
- 所有金流相關操作保留 console.log（方便 debug）
- recur.tw API 整合部分：如果文件有不清楚的地方，
先留下 TODO 註解標明需要確認的欄位，不要猜測 API 格式
- 完成後提供完整測試清單：
1. recur.tw 沙盒測試付款流程
2. Lemon Squeezy Test mode 測試付款流程
3. 確認 Purchase 記錄寫入
4. 確認 user.role 更新
5. 確認購買確認 Email 發出
6. 確認課程頁面正確解鎖
四個模組的接線順序
建議的執行順序：
第一步 模組一（內容獲客）
→ Blog + GEO Wiki + Lead Magnet + Email 訂閱
→ 完成後：你的網站已經有內容，可以開始 SEO
第二步 模組二（課程變現）
→ 課程系統 + Landing Page + 課程閱覽器
→ 完成後：課程頁面已存在，但購買和 access control 還沒接好
第三步 模組三（會員管理）
→ Better Auth + Google OAuth + 會員儀表板
→ 完成後：用戶可以登入，access control 接線完成
第四步 模組四（金流系統）
→ recur.tw（主）+ Lemon Squeezy（輔）+ Webhook 自動解鎖
→ 完成後：整條變現漏斗通了
全部完成後，把你的網站 URL 發布在社群——
你的 AIOPC 正式上線。
四大模組解鎖 模組一：內容獲客系統（SEO Blog + GEO Wiki + Lead Magnet + Email） 模組二：課程變現系統（L1 / L2 / L3 三層架構 + Landing Page） 模組三：會員管理系統（Better Auth + Google OAuth + Access Control） 模組四：免費金流系統（recur.tw 主 + Lemon Squeezy 輔 + Webhook 自動解鎖） 工具：Claude Code 技術棧：Next.js + Payload CMS + Tailwind + Vercel（0 元運營） 狀態：AIOPC 完整上線
7-5｜實戰案例：IDOL Wiki × aicoding.tw SEO Blog 自動化
從零建立 IDOL Wiki，到第一篇 SEO Blog 上架的完整流程記錄
這是一份真實的實戰記錄。
不是範本，不是空白的模板——是一個真實的 OPC 網站（aicoding.tw）的 IDOL Wiki， 從頭建立、填入真實內容、然後用 Publish 操作把第一篇 SEO Blog 推上線的完整過程。
起點：把 IDOL-Wiki.md 放進專案
在 aicoding.tw 的同層目錄，建立一個新資料夾 IDOL-Wiki，
把 IDOL-Wiki.md 規格文件放進去。
對 Claude Code 說：
請讀取 IDOL-Wiki.md，然後初始化 IDOL Wiki 系統
Claude Code 讀完規格文件，建立完整的資料夾結構—— Raw_Sources / Wiki / Channels / Memory / Schema / Publish。
所有條目都是空白模板，等待填入真實內容。
第一步：Ingest 品牌資料
aicoding.tw 已經有完整的品牌文件：CLAUDE.md、AGENTS.md、site.config.json。
這些文件放進 Raw_Sources/，然後對 Claude Code 說：
請讀取 IDOL-Wiki.md，然後執行 Ingest
Claude Code 讀取品牌文件，提取關鍵資訊，填入七個 Wiki 條目：
Wiki/identity.md（填入後）
名字：AI-MAN
網站：aicoding.tw
身份定義：繁體中文 AI Coding 學習網站的主理人
自己就是第一個用 Claude Code 從零做出產品的學員
使命：讓沒有工程背景的人，用 Claude Code / Codex 做出第一個真的可以用的作品
核心主張：AI 時代，門檻消失了。你出方向，Claude Code 把想法做成真的
Wiki/voice.md（填入後）
核心語氣：
像一個已經踏出第一步的朋友在說話，不是老師在講課
✓ 我會說：「先做這個，做完這步你就有了 XX」
✓ 我會說：「不需要懂程式，Claude Code 會幫你寫」
✓ 我會說：「卡住了很正常，貼這句話給 Claude Code，它會幫你修」
✗ 我不說：工程黑話（API、repo、版控）
✗ 我不說：「誠摯地」「懇請」「非常感謝您的閱讀」
✗ 我不說：「令人振奮的是」「值得注意的是」（AI 寫作特徵）
Wiki/audience.md（填入後）
主要讀者：第一次想用 AI 工具做出東西的人
→ 有想法，但不知道從哪裡開始
→ 沒有工程背景，或學過一點程式但沒有持續
核心痛點：
「我想學 AI Coding 但不知道從哪裡開始」
「看了很多教學，但沒有做出任何東西」
「Claude Code 打開了不知道要說什麼」
Wiki/beliefs.md（填入後）
核心觀點：
1. 做出來比學完更重要
2. AI Coding 不是寫程式，是溝通
3. 新手最大的錯誤是從複雜的東西開始
4. 失敗不是壞事，Claude Code 重來很快
我反對：
✗「先把程式基礎學好再用 AI」
✗ 教工具而不教成果
✗ 讓讀者一個人摸索
第二步：設定 Channels/blog.md
Blog 頻道的說話規則：
受眾：透過 Google 搜尋主動找答案的新手
語氣規則：
- 開頭直接說這篇能幫讀者做什麼
- 步驟有編號，讓讀者知道自己在哪裡
- 結尾不說「希望對你有幫助」
格式規格：
- 字數：1500–2500 繁體中文字
- 結構：H1 + Meta description + 開頭段 + H2 步驟 + 結尾 CTA
- categorySlug: start / build / sell / one-person-company
發布方式：
npm run publish-post -- content/posts/[slug].md
第三步：查 Memory，確認選題沒有重複
執行第一次 Lint：
請讀取 IDOL-Wiki.md，然後執行 Lint
Lint 產出 Memory/gap-analysis.md：
高優先空缺（有搜尋量，尚未發布）：
→ Claude Code 新手做第一個網頁（關鍵字：claude code 入門 新手）
→ Codex 入門第一步
→ Claude Code 做聊天機器人
→ 第一個付費客戶怎麼找
選擇第一個：「不會寫程式，用 Claude Code 30 分鐘做出第一個網頁」
第四步：執行 Publish
publish blog Claude Code 30分鐘做出第一個網頁
Claude Code 執行三讀：
- 讀 Wiki/：AI-MAN / 新手友善 / 口語短句 / 做出成果導向
- 讀 Channels/blog.md：1500–2500 字 / 步驟有編號 / 結尾 CTA
- 查 Memory/master-index.md：確認此主題尚未發布過 ✓
生成文章，寫入 content/posts/claude-code-first-webpage.md：
---
title: 不會寫程式，用 Claude Code 30 分鐘做出第一個網頁
slug: claude-code-first-webpage
excerpt: 沒有工程背景也能做到。這篇帶你從零開始，用 Claude Code
做出一個真的可以給別人看的網頁。
contentType: blog
accessLevel: free
categorySlug: start
---
你下載了 Claude Code，打開來，看著空白的畫面，不知道要說什麼。
這很正常。大多數人第一次打開都是這個感覺。
[... 1916 字的完整文章 ...]
第五步：部署上線
cd /Users/ai-man/Sites/aicodingtw
npm run publish-post -- content/posts/claude-code-first-webpage.md
終端機輸出：
📝 準備上架：不會寫程式，用 Claude Code 30 分鐘做出第一個網頁
slug: claude-code-first-webpage
字數: 1916 字元
類型: blog / free
分類: start
動作: 新建
目標: https://aicoding.tw/blog/claude-code-first-webpage
✅ 文章已上架！
🔗 https://aicoding.tw/blog/claude-code-first-webpage
第六步：Memory 自動更新
文章上架後，Claude Code 更新 Memory/master-index.md：
| 標題 | 平台 | 日期 | slug | 主題標籤 |
|----------------------------------------|------|------------|----------------------------|----------------------|
| 不會寫程式，用 Claude Code 30 分鐘做出... | blog | 2026-06-04 | claude-code-first-webpage | claude-code, 入門, 開始 |
並在 Wiki/log.md 寫入：
[2026-06-04 15:00] Publish | 平台：blog | 標題：不會寫程式，用 Claude Code 30 分鐘做出第一個網頁 | slug：claude-code-first-webpage | 狀態：已部署
完整的資料夾結構（建立完成後）
IDOL-Wiki/
│
├── IDOL-Wiki.md ← 規格文件，讀它即能操作系統
│
├── Raw_Sources/
│ ├── aicodingtw-CLAUDE.md ← Ingest 來源
│ ├── aicodingtw-AGENTS.md ← Ingest 來源
│ └── aicodingtw-site-config.json
│
├── Wiki/
│ ├── index.md ← 條目目錄，last_updated: 2026-06-04
│ ├── log.md ← 操作日誌
│ ├── identity.md ✓ 已填入
│ ├── voice.md ✓ 已填入
│ ├── story.md ✓ 已填入
│ ├── audience.md ✓ 已填入
│ ├── products.md ✓ 已填入
│ ├── beliefs.md ✓ 已填入
│ └── content.md ✓ 已填入
│
├── Channels/
│ ├── blog.md ✓ 已設定
│ ├── geo.md （待設定）
│ ├── lp.md （待設定）
│ ├── instagram.md （待設定）
│ ├── linkedin.md （待設定）
│ └── threads.md （待設定）
│
├── Memory/
│ ├── master-index.md ✓ 1 篇發布記錄
│ ├── topic-map.md （待更新）
│ ├── gap-analysis.md ✓ 6 個高優先空缺
│ └── refresh-queue.md （空）
│
├── Schema/
│ └── CLAUDE.md ✓ 初始版本已生成
│
└── Publish/
├── Website/
│ ├── blog.md ✓ 部署流程：npm run publish-post
│ ├── geo.md
│ ├── lp.md
│ └── about.md
└── Social_Media/
├── instagram.md
├── linkedin.md
└── threads.md
這個流程說明了什麼
整個過程，你做了幾件事：
1. 把 IDOL-Wiki.md 放進資料夾 ← 1 分鐘
2. 對 Claude Code 說「初始化」 ← 等待 3 分鐘
3. 把品牌文件放進 Raw_Sources，說「Ingest」 ← 等待 5 分鐘
4. 對 Claude Code 說「Lint」 ← 看 gap-analysis
5. 對 Claude Code 說「publish blog XX」 ← 等待 5 分鐘
6. 執行 npm run publish-post ← 1 行指令
Claude Code 做了什麼：
→ 讀品牌文件，填入七個 Wiki 條目
→ 設定 Blog Channel 規則
→ 分析關鍵字空缺，生成 gap-analysis
→ 讀 Wiki + Channels + Memory，生成 1916 字的 SEO Blog
→ 確認主題未重複，符合語氣規則，符合平台格式
→ 部署到 aicoding.tw，更新 Memory
你沒有做什麼：
✗ 沒有手寫任何一段文章
✗ 沒有查過關鍵字工具
✗ 沒有想過文章結構
✗ 沒有擔心語氣對不對
這就是 IDOL Wiki 的意義。
不是讓 AI 隨便生成內容——是讓 AI 基於你真實的身份、語氣、立場和規則，產出真的像你的內容。
已發布文章： https://aicoding.tw/blog/claude-code-first-webpage
IDOL Wiki 狀態： 七個條目已填入 / Blog Channel 已設定 / Memory 初始化完成 距離「自動化發布就緒」里程碑：還需要設定 2 個 Channels（geo / lp）
CHAPTER COMPLETE Agent 原生網站：已建造 AIOPC 三位一體：已上線 IDOL Wiki：已建立 四大模組：已部署 下一關：CH.08 尋找盟友，越級打怪 _