SOCLE 方法 是做什麼的？
五步驟的數位產品創建框架。每個步驟產出具體的可交付成果，並為下一步奠定基礎。
原則
在建造第一個可見功能之前，先完整準備好基礎。每個決定只做一次，按順序進行。技術基礎在一次通過中完成，包括稍後才會構建的內容。開發以短增量進行，每個增量完整且部署後才進入下一個。
五個步驟
S — 結構化選擇
從最重要的決定開始。我們為誰服務、解決什麼問題、使用哪些技術、如何衡量。一次一個，按順序進行，每個決定都為下一個敞開大門。
此步驟的可交付成果：
- 一句話產品願景
- 目標用戶（主要和次要人物誌）
- 解決的問題（具體、可衡量）
- 鎖定的技術棧
- 選擇的視覺方向
- 確定的獲利模式（即使是免費增值或稍後實現）
- 產品名稱
執行方式：
- 提出封閉式框架問題（非開放式腦力激盪）
- 在進入下一個決定前鎖定每個決定
- 整合到一個鎖定決策表中
- 識別競爭對手和差異化因素
參閱 references/structurer-checklist.md 以取得完整的決策清單。
O — 工具化基礎
一次通過準備好所有基礎。資料庫、頁面、驗證、追蹤、慣例。一切就緒，包括稍後才會構建的內容。
此步驟的可交付成果：
- 最終路由結構（URL 將不再變更）
- 完整資料庫結構（所有表格，即使 V0.1 未使用）
- CSS 設計權杖（變數、字體、顏色、間距）
- 動畫變體（Framer Motion 或同等方案）
- 分析標籤計畫（事件、轉換漏斗）
- CI/CD 管線（lint、型別檢查、測試、自動建置）
- CLAUDE.md 檔案（Claude Code 的專案指示）
- CURRENT_INCREMENT.md 檔案（第一個增量的範圍）
- 中介軟體設定（驗證、重定向、安全標頭）
- 已記錄的環境變數
執行方式：
- 生成完整路由結構（行銷、驗證、應用程式、管理、API）
- 編寫完整 SQL 結構，包含枚舉、索引、RLS、觸發器
- 配置設計系統（globals.css + tailwind.config.ts）
- 創建專案背景檔案（CLAUDE.md、ARCHITECTURE.md 等）
- Scaffold 專案、安裝所有依賴項、首次提交、部署
參閱 references/outiller-templates.md 以取得每個檔案的範本。
C — 按區塊建構
以短增量前進。每個增量都交付完整的內容，可以展示、測試、使用。一個真正的產品片段，從頭到尾都能運作。
原則：
- 每個增量都有寫在 CURRENT_INCREMENT.md 中的封閉範圍
- 每個增量都有可測試的完成標準
- 每個增量都有明確的範圍外清單
- 任務按順序排列：每個任務僅依賴於前一個任務
- 每個任務遵循循環：編碼、測試、驗證、提交
增量結構：
# V0.X — [增量名稱]
## 目標
[使用者在此增量結束時可以做的事情]
## 任務（按順序）
[有序任務列表，附詳細說明]
## 完成標準
[具體檢查清單]
## 範圍外
[明確說明此增量中不包含的所有內容]
每個任務後的系統性檢查：
- 型別檢查通過
- 測試通過
- 沒有
any型別 - 屬性已正確型別化
- API 輸入已驗證
- 提交遵循 conventional commits
L — 每個階段交付
每個區塊在上線前都經過真實使用者測試。回饋來得早，調整也來得早。
原則：
- 每個增量完成後立即部署到正式環境（或預覽環境）
- 部署自動化（推送到 main 分支 = Vercel 部署）
- 正式環境錯誤立即偵測（監控、錯誤邊界）
- 分析事件從第一個增量開始啟用
- 只有在當前增量穩定後才開始下一個增量
交付檢查清單：
- CI 建置通過
- 正式環境零主控台錯誤
- 頁面包含元資料（標題、描述）
- 響應式設計正常（檢查行動裝置）
- 分析事件已追蹤
- URL 可訪問且功能正常
E — 無需重構的擴展
產品自然成長。新功能建立在現有基礎上，設計演進，整合連接。結構保持穩定，因為從一開始基礎就準備好了。
原則：
- 新的增量絕不會使先前的增量失效
- 資料庫表格已準備就緒（在步驟 O 中添加）
- CSS 變數允許在不觸及元件的情況下更改樣式
- 路由穩定（URL 不變）
- 程式碼慣例從第一個增量到最後一個增量保持一致
添加增量時：
- 使用新範圍更新 CURRENT_INCREMENT.md
- 檢查基礎（步驟 O）是否涵蓋需求
- 如果缺少表格或路由：透過遷移添加，而非重建
- 遵循與 V0.1 相同的慣例進行編碼、測試、部署
如何將 SOCLE 應用於新專案
完整順序
1. 結構化
│ 框架對話（封閉式問題）
│ 鎖定決策表
│ 願景、目標、技術棧、獲利模式
↓
2. 工具化
│ 生成所有基礎檔案
│ 路由、資料庫、權杖、分析、CI/CD
│ Scaffold、部署、首次空白提交
↓
3. 建構 (V0.1)
│ 第一個增量：最小核心
│ 驗證 + 一個核心功能 + 一個匯出
│ 測試、提交、部署
↓
4. 交付 (V0.1)
│ 正式環境，由真實使用者測試
│ 分析啟用，錯誤監控
│ 穩定後才進入 V0.2
↓
5. 擴展 (V0.2, V0.3, ...)
│ 每個增量遵循 C → L
│ 基礎吸收成長
│ 無需重構
專案檔案（步驟 O 生成）
| 檔案 | 角色 |
|---|---|
CLAUDE.md | Claude Code 指示：慣例、工作流程、檢查 |
CURRENT_INCREMENT.md | 當前增量範圍、有序任務、完成標準 |
ARCHITECTURE.md | 最終路由、檔案結構、資料流 |
DB_SCHEMA.sql | 完整資料庫結構 |
DESIGN_TOKENS.md | CSS 變數、Tailwind 配置、動畫變體 |
AGENT_PROMPTS.md | 如果專案使用 AI 代理的系統提示詞 |
ROADMAP.md | 所有計劃增量的總覽 |
複雜度審計（S 和 O 之間）
在進入步驟 O 之前，盤點專案中所有元件並評估其複雜度。如果高複雜度元件數量超過 5 個，則拆分成更多增量。規則：每個增量最多包含 3 到 5 個新元件。
| 元件 | 複雜度 | 預定增量 |
|---|---|---|
| [名稱] | 低 / 中 / 高 | V0.X |
如果專案看起來像大教堂（超過 20 個元件，超過 6 個高複雜度），重新審視範圍。簡化 V0.1，直到一個人可以在 1 到 2 週內完成。
推薦技術棧
SOCLE 方法適用於任何技術棧。如果使用者沒有偏好，以下是預設的技術棧：
| 層級 | 技術 |
|---|---|
| 框架 | Next.js 14+ (App Router) |
| 語言 | TypeScript 嚴格模式 |
| 樣式 | Tailwind CSS + shadcn/ui |
| 動畫 | Framer Motion |
| 狀態管理 | Zustand |
| 驗證 | Supabase Auth |
| 資料庫 | Supabase (PostgreSQL) |
| 驗證庫 | Zod |
| 測試 | Vitest + Testing Library |
| CI/CD | GitHub Actions |
| 部署 | Vercel |
如果使用者有不同的技術棧，請相應調整步驟 O 的範本。SOCLE 原則適用於任何技術棧。
語氣與姿態
與使用者一起應用 SOCLE 時：
- 專業、成熟、對話式語氣
- 清晰且直接有用的句子
- 對非開發人員解釋時不使用未說明的技術術語
- 不擺出優越姿態
- 不使用修辭結構（「這不是 X，這是 Y」）
- 我們引導、傳遞、共同前進