← → 翻頁 · ESC 索引
Vibe Coding 方法論 v2.0
Codex · Skills · TDD · Tauri 2
不是讓 AI 隨便寫代碼 · 而是把想法穩定落地

Vibe Coding
方法論 v2.0

Project Docs→ Phase Plan→ TDD Spec→ Test Files→ Code→ Checklist→ Verify→ Iterate

適用於沒有編程經驗、但想用 AI 輔助開發產品、MVP、網站、App、內部工具的人。核心目標：照著文檔走，可測、可驗收、可迭代。

Codex·Superpowers Skill·UI UX PRO MAX·Tauri 2·TDD
Vibe Coding Methodology · v2.0 · 2026
30 slides · 6 acts
正確定義 · Definition
Act I · 02 / 30
先糾正一個常見的錯誤認知

Vibe Coding 不是 vs 應該是

BAD · Vibe Coding 不是

隨口說「幫我做個 App」

不看代碼、不跑測試、只看 AI 截圖

一次讓 AI 寫完所有功能

出錯後繼續堆 Prompt，直到項目不可維護

把 AI 當成魔法按鈕，自己不做任何判斷

GOOD · Vibe Coding 應該是

你負責產品判斷、驗收標準、取捨

Codex 負責代碼探索、實作、測試、修復

Skills 負責把工作流標準化

TDD 負責防止「看起來完成，實際不可用」

UI/UX Skill 負責確保產品品質，不只是 demo

Page 02 · 正確定義
你仍然是產品與品質的負責人
核心流程 · Core Flow
Act I · 03 / 30
把這條流水線刻進肌肉記憶
Project Docs → Phase Plan → UI/UX Plan → TDD Spec → Test Files
→ Code → Checklist → Skill Review → Verification → Next Iter.

每一個節點都要落到文件或測試結果裡。這個流程不是抽象口號，而是新手可直接照抄的產品開發路線。

Plan first·Test first·Small steps·Always check
Page 03 · 核心流程
— · —
第二幕 · 工具棧
Act II · 04 / 30
Act II

工具棧

Codex、Superpowers Skill、UI UX PRO MAX、Tauri 2——每個工具有明確的分工，不可替換，也不能省略。

第二幕 · Tool Stack
— · —
主力工程代理 · Codex
Act II · 05 / 30
你最重要的工程夥伴

Codex：做什麼 + 怎麼問

Codex 適合做
讀 Repo
讀取整個 codebase，理解現有架構與數據流，再開始動代碼
多文件修改
跨越多個文件的功能實作、重構、類型修復
跑測試
執行測試、修 lint、修 type error，輸出測試結果摘要
生成 PR
根據 diff 生成 pull request 摘要，包含影響範圍和風險說明
任務提示的 4 個必填欄位
Goal 我要完成什麼？
Context 相關文件、錯誤、設計、接口在哪？
Constraints 技術棧、風格、安全、性能限制
Done when 什麼條件全部滿足才算完成？

缺少任何一個欄位，Codex 就會填空——你不想要的功能就這樣出現了。Done when 是最常被省略、也是最重要的。

Page 05 · Codex
Goal · Context · Constraints · Done when
流程保險絲 · Superpowers Skill
Act II · 06 / 30
不是多一個插件，而是讓 AI 開發有紀律

Superpowers Skill：在哪 5 個節點必用

Superpowers 的價值是流程約束，不是功能增強。這 5 個節點省掉任何一個，都會積累技術債。

節點 01 · 開始前
任務開始
檢查是否需要 brainstorming / planning / TDD / debugging / code review。確定策略後再開始
節點 02 · 寫代碼前
強制先 Plan
不讓 Codex 直接寫。先輸出 plan 和 TDD 測試清單，確認後才進入實作
節點 03 · 實作中
RED → GREEN → REFACTOR
按 TDD 三步走。每完成一個小任務：改了什麼、測試結果、下一步
節點 04 · 完成後
Skill Check
不能省。確認流程、測試、代碼質量、設計一致性、跨平台風險
節點 05 · 合併前
Branch Review
Code review + finishing branch 檢查。commit message + PR 摘要要清楚
什麼時候一定要觸發：開始新功能、拆解複雜任務、debug、code review、任務跨多文件或多模塊。
Page 06 · Superpowers Skill
流程保險絲 · 5 個必用節點
界面品質閘門 · UI UX PRO MAX
Act II · 07 / 30
不是「最後美化一下」，是產品品質的一部分

UI UX PRO MAX：早期介入

在產品早期就引入 UI UX PRO MAX——不要等功能寫完再想設計。先有 design system，再寫頁面。

先讓 AI 輸出一份 design system，再讓它寫頁面——順序反了，每個頁面風格就會不同，像拼湊 demo。
反模式警告
Design System 包含 →
色彩系統 字體系統 Spacing / Radius Shadow 動效規範 響應式規範 反模式清單
每個頁面的 UI 驗收標準
首屏信息層級清楚，主要 CTA 明確且可點擊區域足夠大
有 loading / empty / error 狀態——缺一個都算未完成
移動端不溢出、不擠壓、不遮擋，觸控交互可用
顏色、字體、間距符合 design system，無硬編碼魔法數字
表單錯誤提示具體可修復，不只是「填寫錯誤」
可訪問性：鍵盤可用、對比度合理、aria label 完整
Page 07 · UI UX PRO MAX
先 Design System · 再寫頁面
跨平台打包層 · Tauri 2
Act II · 08 / 30
一套代碼，覆蓋五個平台

Tauri 2：推薦技術棧與限制

推薦技術棧
Tauri 2 + 跨平台殼
Next.js / React + Vite 靜態前端
three.js / @react-three/fiber 3D 場景
Rust commands / Tauri plugins 本地能力
Playwright / Vitest 測試
適合場景：3D 展示、本地工具、離線 App、需要原生殼但不想維護多套代碼
macOSWindowsLinuxiOSAndroid
重要限制
UI 層
運行在系統 WebView（WKWebView / WebView2 / WebKitGTK）——不是原生渲染
three.js
跑 WebGL，不是 Metal / Vulkan 原生渲染，移動端需設清晰性能預算
Next.js
必須按 static export 或純 client-side 設計，不能有 server runtime
原生能力
深度 iOS/Android 原生能力仍可能涉及 Swift / Kotlin 插件
Page 08 · Tauri 2
5 平台覆蓋 · 了解 WebView 限制
第三幕 · 核心方法論
Act III · 09 / 30
Act III

Plan → TDD
→ Code → Check

四步走完整方法論——每一步都有對應的提示詞模板和驗收標準。

第三幕 · 核心方法論
— · —
Step 1 · Plan First
Act III · 10 / 30
不要直接讓 Codex 開始寫代碼

Step 1：先建立分階段 Plan 文檔

用這段提示詞強制 Codex 先規劃再動手。沒有 plan，AI 會根據自己的猜測實作你不需要的功能；有 plan，新手也能逐條驗收。

Plan 的核心價值：把項目文檔拆成可執行階段。每一階段都要包含 UI/UX 設計、要改的文件、測試策略和 Done when。
Plan 驗收清單
任務範圍足夠小？能在 1 個 PR 完成？
明確列出不做什麼？
是否寫成 docs/plans/phase-01.md 這類文件？
是否包含 UI/UX 草圖、狀態、響應式要求？
是否列出測試文件、驗收 checklist、驗證命令？
Phase Plan 文檔包含 6 個區塊
來源文檔
PRD、需求筆記、設計草稿、現有 bug 描述，全部列出文件路徑
階段目標
本階段只做什麼、不做什麼，控制在 1 個小 PR 內
UI/UX 設計
頁面結構、狀態、交互、響應式要求；必要時附 ASCII mockup
文件清單
要新增/修改的代碼文件、測試文件、checklist 文件
TDD 計劃
先寫哪些測試文件；每個測試對應哪條驗收標準
Checklist
完成前逐項勾選：功能、測試、UI、性能、安全、交付
Page 10 · Step 1 · Phase Plan
文檔先行 · 改 plan 比改代碼便宜
Step 2 · TDD Spec
Act III · 11 / 30
Plan 不是終點，要把它變成測試

Step 2：TDD Spec + test 文件

TDD Spec 要落到文件
Happy Path
Given / When / Then 格式。用戶正常操作時系統應產生什麼結果
Edge Cases
空輸入、錯誤格式、API 失敗、慢網絡、權限不足、移動端小屏
Regression
之前出過的 bug 是否不再出現？原有功能是否不被破壞？
UI/UX 驗收
交互是否清楚？loading / error / empty state 是否存在？手機端可用？
Test Files
把以上條目寫進 *.test.ts、*.spec.ts 或 tests/*.md
RED → GREEN → REFACTOR
RED

先讓測試跑起來並確認失敗。測試是契約，失敗說明實作還不存在

GREEN

只寫讓當前測試通過的最小代碼。不要在這步優化或加功能

REFACTOR

測試通過後做必要重構。重構前後測試結果必須一致

Page 11 · Step 2 · TDD Spec
Spec 必須變成 test files
Step 3 · Implementation
Act III · 12 / 30
先跑測試，再寫最小代碼

Step 3：Test → Code → Checklist

實作提示詞的 5 條規則
01
先新增或更新 test 文件，再運行測試，確認失敗——進入 RED
02
只寫讓當前測試通過的最小代碼——進入 GREEN
03
測試通過後更新 checklist，做必要重構——進入 REFACTOR
04
不要順手新增 plan 之外的功能
05
每完成一個小任務輸出：改了什麼 · 測試結果 · checklist 狀態 · 下一步
分層推進的順序
Phase Plan
TDD Spec
Test Files
Code
Checklist
Verification → Iterate
不要在同一個 prompt 內同時要求：改 schema、寫 API、做 UI、加動畫、修性能。新手只要守住「一個小任務一輪驗證」。
Page 12 · Step 3 · Implementation
Test files · Code · Checklist
Step 4 · Skill Check
Act III · 13 / 30
這一步不能省

Step 4：Superpowers Skill Check

任務「看起來完成」不等於「完成」。Skill Check 是最後一道防線。

Process
流程驗證
是否從項目文檔 → phase plan → TDD → test files → code → checklist？是否每步有記錄？
Code
代碼質量
是否只改必要文件？有無無關重構？有無新增未說明依賴？有無錯誤處理？
Tests
測試覆蓋
測試文件是否落地？單元 / 集成 / UI 測試是否通過？是否覆蓋失敗場景和 edge cases？
Product
產品符合度
是否符合原始需求和 Done when？是否有超範圍功能需要確認？
UI/UX
界面檢查
是否需要 UI UX PRO MAX 再過一遍界面？設計一致性、響應式、可訪問性
Delivery
可交付
可以 commit 嗎？PR 摘要清楚嗎？風險和後續事項列出來了嗎？
Page 13 · Step 4 · Skill Check
Process · Code · Tests · Product · UI · Delivery
第四幕 · Codex 使用技巧
Act IV · 14 / 30
Act IV

Codex
使用技巧

這些技巧的本質都是同一件事：限制 AI 的自由度，減少它亂發揮的機會。

第四幕 · Codex Tips
— · —
技巧 · Small Steps
Act IV · 15 / 30
一次只做一件事

小步快跑：差的任務 vs 好的任務

BAD · 差的任務

「幫我做一個完整 SaaS，包括登錄、支付、dashboard、AI、管理後台。」

問題：AI 偏離、漏測、引入隱性 bug。拆不開、改不了、無法驗收。

GOOD · 好的任務

「先完成 dashboard 的空狀態頁面：使用現有 layout、顯示 3 個 onboarding step、CTA 跳轉 /setup、加入單元測試和響應式測試、完成後做 UI UX PRO MAX 檢查。」

理想任務大小：30–90 分鐘內可完成、有清晰 Done when、能在 1 個 PR 合併。

技巧 01
先讀代碼再改代碼
讓 Codex 先掃描相關文件，輸出架構理解、相關文件列表、最小修改方案和潛在風險。不要修改任何文件
技巧 02
每次只改一個抽象層
數據模型 → API → 狀態 → UI → 整合 → 測試 → 優化。不要在同一個 prompt 跨多層
技巧 03
禁止「順手重構」
明確告訴 Codex：不要做無關重構、不要改格式化風格、不要重命名公開 API。必要重構先列原因等確認
技巧 04
明確說不要什麼
不要引入新依賴（除非先說明原因）、不要改無關文件、不要做 plan 之外的功能。負面清單和正面需求一樣重要
Page 15 · Codex 使用技巧
小步 · 先讀後改 · 禁止亂重構
任務模板 · Task Template
Act IV · 16 / 30
每次開任務都用這個格式

標準任務提示模板

任務開始模板（5 個欄位）
任務
一句話描述：要做什麼
上下文
項目文檔、phase plan、設計說明、相關 issue / bug、當前問題描述
限制
不要改動無關文件 · 不要引入新依賴 · 必須先 phase plan → TDD → test files → code
輸出順序
① Phase Plan → ② TDD Spec → ③ Test Files → ④ Code → ⑤ Checklist → ⑥ Verification
Done when
驗收條件 1 · 驗收條件 2 · 驗收條件 3
一個完整任務示例

EXAMPLE · Settings 頁面

任務：新增 settings 頁，允許用戶修改暱稱和頭像

Phase Plan：docs/plans/settings-profile.md
TDD Spec：顯示當前暱稱 · 修改後保存成功 · 空暱稱報錯 · API 失敗顯示錯誤 · 手機端不溢出
Test Files：settings-profile.test.ts + settings-profile.spec.ts

Done when：所有測試通過 · checklist 全部勾選 · UI 通過 PRO MAX review · lint 和 typecheck 無報錯

Codex · 實際任務示例
最小落地鏈路：項目文檔 → phase plan → TDD spec → test files → code → checklist → verification → 下一輪迭代
Page 16 · 標準任務模板
5 欄位 · 固定輸出順序
第五幕 · Tauri 2 跨平台
Act V · 17 / 30
Act V

Tauri 2
跨平台工作流

架構規範、項目結構、跨平台驗收清單——確保一套代碼在五個平台都能穩定跑起來。

第五幕 · Tauri 2 Workflow
— · —
架構規範 · Architecture
Act V · 18 / 30
項目結構與關鍵規範

Tauri 2 + Next.js + three.js 架構規範

項目目錄結構
app/ src/
React / Next.js UI · three.js 場景和 renderer · platform-safe hooks
src-tauri/
Rust commands · Tauri config · permissions/capabilities · plugins · platform setup
tests/
unit / integration / Playwright smoke tests · platform build scripts
平台差異必須集中封裝，不要在 UI 組件內到處散落 if platform
5 個關鍵規範
three.js
場景封裝為可測/可卸載/可釋放資源的模塊。unmount 時必須 dispose renderer、texture、geometry、material
移動端預算
明確設定：模型大小、貼圖尺寸、draw calls 上限、首屏載入時間
Rust commands
做 schema 驗證和錯誤處理，不把任意文件路徑或 shell 能力直接暴露給前端
Next.js
優先 static export 或純 client-side，禁止依賴 API routes、SSR runtime、server actions
WebGL 降級
WebGL context loss 需有降級或恢復策略，不能直接崩潰
Page 18 · Tauri 2 架構規範
結構清晰 · 平台差異集中封裝
跨平台驗收 · Cross-platform Acceptance
Act V · 19 / 30
全部通過才算完成

Tauri 2 跨平台驗收清單

Build
構建驗證
typecheck / lint / test 通過
cargo test + cargo clippy 無阻塞
tauri build 在主要桌面平台通過
iOS/Android smoke test 完成
Runtime
五平台運行
macOS / Windows / Linux 主流程可用
iOS / Android 主流程可用
深色模式、視窗尺寸、safe area 可用
觸控交互在移動端可用
three.js
3D 場景
場景 init / resize / pause / destroy 正常
WebGL context loss 有降級策略
移動端幀率/記憶體/貼圖可接受
模型和貼圖路徑在打包後可讀取
Security
安全邊界
Tauri permissions 最小化
Rust commands 有輸入驗證和錯誤返回
沒有 API key / secret 寫進客戶端
完成 Superpowers + UI UX PRO MAX check
Page 19 · Tauri 2 驗收清單
Build · Runtime · three.js · Security
第六幕 · 工程習慣
Act VI · 20 / 30
Act VI

工程習慣

Debug 方法論、Commit/PR 規範、文檔落地閉環、反模式清單——讓 Vibe Coding 長期可持續。

第六幕 · Engineering Discipline
— · —
Debug 方法論 · Systematic Debugging
Act VI · 21 / 30
當 AI 寫壞了，不要說「修一下」

系統化 Debug：6 步定位

隨意說「修一下」只會讓 Codex 猜測性修復，製造更多問題。要讓它系統化定位。

01
描述現象
錯誤日誌 + 復現步驟 + 預期行為 vs 實際行為。越精確越好
02
列出 3 個原因
讓 Codex 輸出最可能的 3 個原因，不讓它直接猜一個然後改
03
驗證每個原因
每個原因對應一個驗證方法，先驗證再改代碼，不跳步
04
最小檢查先行
從成本最低的檢查開始。加一行 log 比重寫函數便宜
05
確認原因再修
確認是這個原因導致問題後，才讓 Codex 修代碼
06
加 Regression Test
修復後新增 regression test，確保這個 bug 不再出現
核心原則：先定位，再修復。「隨便改改看」的代價是不知道為什麼好了，下次出現相似問題更難追。
Page 21 · Debug 方法論
定位 · 驗證 · 修復 · Regression
Commit/PR 規範 · Delivery
Act VI · 22 / 30
合併前的最後防線

Commit 前 6 項檢查 + PR 結構

Commit 前必做 6 項
git diff 只包含本任務相關變更
測試全部通過（unit + integration + e2e）
lint / typecheck 無報錯
無 console.log / debug code / secret
文檔或註釋已更新（如有必要）
已完成 Superpowers Skill Check
PR 摘要必須包含
Summary
完成了什麼 · 為什麼這樣實作 · 影響範圍
Tests
unit / integration / e2e / lint / typecheck 結果
UI Notes
桌面、移動端、loading / empty / error state 截圖或說明
Risks
已知風險 + 後續需要觀察的點
Skill Check
Superpowers：通過/阻塞 · UI UX PRO MAX：通過/阻塞
Page 22 · Commit/PR 規範
6 項檢查 · PR 結構完整
落地閉環 · Delivery Loop
Act VI · 23 / 30
新手只照這條鏈路走

文檔 → Plan → TDD → Test → Code → Verify

不要按日期切任務。按文件與驗證切任務：每一步都有產物，每一步都能 review。

開工前先落三份文檔
Doc 01
Project Docs
寫清楚產品目標、用戶、核心流程、已有設計、限制。新手先把需求說人話
Doc 02
Phase Plan
把項目拆成階段。每階段有目標、非目標、UI/UX、文件清單、風險、Done when
Doc 03
TDD Spec
把 Done when 變成測試清單：happy path、edge case、regression、UI/UX 驗收
Doc 04
Review with Skills
在開工前用 planning / TDD / UI UX skill review 一遍，先修文檔再寫代碼
實作時只跑一個閉環
Loop 01
Create Test Files
先新增或更新測試文件，跑一次確認失敗。沒有測試文件，不准開始寫功能
Loop 02
Minimal Code
只寫讓測試通過的最小代碼；禁止順手加功能、順手重構、順手換依賴
Loop 03
Checklist
逐項勾選功能、測試、UI、錯誤狀態、響應式、安全、交付；缺一項就回去修
Loop 04
Verification → Iterate
跑驗證命令，讓 skill 再 review；通過才 commit，未通過就更新 plan 進下一輪
Page 23 · 文檔落地閉環
Project Docs · Phase Plan · TDD · Test Files · Checklist
反模式 · Anti-patterns
Act VI · 24 / 30
識別並避免這 5 個高頻錯誤

6 個常見反模式

Anti-pattern 01
一次做太大
問題：AI 容易偏離、漏測、引入隱性 bug
解法：拆成 30–90 分鐘內可完成的小任務
Anti-pattern 02
沒有Done When
問題：Codex 不知道何時停止，會一直加功能
解法：每個任務都寫明通過哪些測試才算完成
Anti-pattern 03
只看UI 截圖
問題：demo 能看，實際流程壞掉
解法：每個功能至少有 happy path + edge case + regression test
Anti-pattern 04
AI 定產品範圍
問題：AI 會加不必要的功能
解法：明確寫「非目標」和「不要做什麼」——負面清單和正面需求同樣重要
Anti-pattern 05
沒有設計系統
問題：每個頁面風格不同，像拼湊 demo
解法：先用 UI UX PRO MAX 生成 design system，再寫任何頁面
Anti-pattern 06
順手重構
問題：改壞已有功能，diff 變大難以 review
解法：明確禁止無關重構，必要時先列原因、等確認、再重構
Page 24 · 反模式
識別 · 記住解法 · 避免重蹈
核心原則 · Core Principle
25 / 30
4 條最終原則

「先想清楚，再讓 AI 寫。」

「先寫測試，再寫代碼。」

「先小步完成，再擴大範圍。」

「每個任務都要有 Done When。」

Codex 是工程代理，不是魔法按鈕。你仍然是產品和質量的負責人。

Page 25 · 4 大核心原則
— · —
完整工作流 · Full Workflow
26 / 30
從項目文檔到 Commit，7 步走完

最小可用工作流：完整一遍

把所有方法論串起來，這就是每個任務的標準流水線。

Step 1
Project Docs
產品目標、用戶、流程、限制、已有設計。先讓 Codex 讀文檔，不先寫代碼
Step 2
Phase Plan
分階段 plan：目標/非目標、UI/UX、文件清單、風險、Done when、測試策略
Step 3
TDD Spec → Test Files
Happy path + edge cases + regression + UI 驗收，落到測試文件或測試清單
Step 4
RED → GREEN → REFACTOR
先確認測試失敗，再寫最小代碼讓測試通過，最後做必要重構
Step 5
Checklist
功能、測試、UI、錯誤狀態、響應式、安全、交付逐項勾選
Step 6
Skill Review
用 Superpowers + UI/UX skill 多次 review：開工前、測試後、交付前都要過
Step 7
Commit / PR
6 項 commit 前檢查，PR 包含 Summary + Tests + UI Notes + Risks + Skill Check
Page 26 · 完整工作流
7 步 · 從任務到 PR
工具分工 · Tool Responsibility
27 / 30
每個工具做它最擅長的

工具分工總覽

你
產品判斷 · 驗收標準 · 功能取捨 · 優先級排序 · 最終決策
Codex
代碼實作 · 多文件修改 · 測試執行 · Bug 修復 · PR 摘要
Superpowers Skill
流程標準化 · 強制 Plan → TDD · Skill Check · 防止跳步
UI UX PRO MAX
Design System · 交互規則 · 響應式 · 反模式檢查 · 可訪問性
Tauri 2
跨平台打包 · 原生殼 · Rust 本地能力 · 5 平台覆蓋
TDD
防止「看起來完成，實際不可用」· 定義 Done when · 回歸保護
六個角色缺一不可。省掉任何一個，都會在不同地方留下隱患——功能缺陷、視覺不一致、跨平台崩潰、無法驗收。
核心數字
目標任務大小
30– 90 min
每個任務控制在這個範圍內，可測試、可驗收、可單 PR 合併
TDD 測試維度
4個維度
Happy Path · Edge Cases · Regression · UI/UX 驗收
Page 27 · 工具分工
六個角色 · 缺一不可
快速參考 · Quick Reference
28 / 30
新手可直接複製的核心結構

4 個必備落地模板

任務開始
使用 Codex 處理這個任務。
任務：{一句話}
上下文：{項目文檔 · phase plan · 設計稿 · issue}
限制：先 phase plan → TDD → test files → code
Done when：{驗收條件清單}
Plan 提示
你是我的產品工程搭檔。先不要寫代碼。
任務：{描述}
輸出：來源文檔 · 階段目標 · UI/UX · 文件清單 · TDD 計劃 · checklist
限制：優先 MVP · 不要自行擴大範圍
TDD + Test Files
基於 phase plan，拆成 TDD 測試清單。
每個功能：1 個 happy path + 1 個 edge case
涉及 UI：加交互和響應式驗收
涉及 API：加失敗/超時/空數據測試
輸出需包含：要新增/更新的 test 文件路徑
使用 RED / GREEN / REFACTOR 排序
Checklist + Skill
任務已完成。請先按 checklist 驗證，再做 Superpowers Skill Check。
輸出：通過項 · 阻塞項 · 建議修復項 · 下一步
檢查：流程 · test files · 測試結果 · UI/UX · 可交付性
Page 28 · 快速參考
Project Docs · Plan · Test Files · Checklist
參考資料 · References
29 / 30
延伸閱讀與官方文檔

核心參考資料

Codex
developers.openai.com/codex/learn/best-practices
Best practices + Skills for Codex
Tauri 2 Docs
v2.tauri.app
Official docs · Prerequisites · Mobile development · Plugin development
Superpowers Skill
github.com/obra/superpowers
using-superpowers SKILL.md + workflow overview
UI UX PRO MAX
github.com/nextlevelbuilder/ui-ux-pro-max-skill
Next.js Static
nextjs.org/docs/app/guides/static-exports
Tauri + Next.js 靜態部署指南
Superpowers 文章
blog.fsck.com/2025/10/09/superpowers/
Vibe Coding workflow 詳細寫法
Plugin Hub
claudepluginhub.com/plugins/obra-superpowers-2
Superpowers workflow 概覽
Tauri Mobile
v2.tauri.app/develop/plugins/develop-mobile/
iOS / Android 插件開發指南
Page 29 · 參考資料
— · —
最終原則 · Final Principles
30 / 30
把這 3 句話貼在顯示器上
"UI 不是最後美化， 而是產品質量的一部分。"
"每次完成都做 Skill Check。"
"Codex 是代理，你是負責人。"
Codex·Superpowers·UI UX PRO MAX·Tauri 2·TDD
Vibe Coding 方法論 v2.0 · 完
Plan → TDD → Code → Check