Step by Step 工作流程

先別急著寫 code！讓 AI 扮演挑剔的 YC 導師，問你 6 個刁鑽問題：這個需求是真實痛點嗎？最小有效範疇是什麼？競品有哪些？

以 CEO 角度審視整個計畫：找出隱藏在你需求裡的「更好產品」、分析競爭格局、確認功能範圍是否過大或過小。

確認技術選型、資料庫設計、API 邊界、MVP 範圍 vs 後期功能切割。輸出具體實作方案、架構圖與工作量估算。

前三步確認方向後，開始實作。因為範圍已定、架構已清，每次對話不用再重新解釋背景，Claude 能更精準地協助你。

動手寫 UI 之前先執行這個 Skill：強制你確立一個大膽的美感方向（復古未來、極簡、暴力排版…），再生成有個性的 Production-grade 前端程式碼，避免千篇一律的 AI 風格。

獨立審查整個 diff，找出 SQL injection、邊界條件、型別錯誤、效能隱患等問題——就像 PR 被資深工程師仔細審過一遍。

系統化測試整個網站：遍歷所有頁面、模擬使用者操作、找到 bug 並自動修復，最後截圖確認每個流程正常運作。

自動完成：同步主分支、執行測試、更新 CHANGELOG、產生版本號、建立 PR。把「發布」從繁瑣手動操作變成一行指令。

快速過一遍核心假設：誰會用？憑什麼用？最小版本長什麼樣？這步 30 分鐘能省你 3 天的無效開發。

強制聚焦：把「想做的功能」清單交給 CEO 模式，它會幫你砍到只剩最核心的一件事。MVP 的 M 是 Minimum，不是 More。

按照砍完的清單，只做最核心的使用者旅程。其他功能全部先 TODO，先讓核心流程跑通。

只測試主要使用者旅程。快速找出阻礙試用的致命 bug，其他小問題先記錄不修。

發布出去，讓真實用戶使用。收集反饋比繼續打磨功能更重要。

四階段系統化排查：調查現象 → 分析代碼 → 建立假設 → 驗證修復。鐵律：沒找到根因前不動手修，避免「修了這個壞那個」。

修完之後，讓 review Skill 審查 diff，確認修復邏輯正確，沒有帶入新的邊界條件問題或型別錯誤。

測試修復是否有效，同時驗證其他原本正常的功能還是好的——修 bug 最怕修好一個、壞掉另一個。

執行完整的程式碼品質儀表板：型別檢查、Lint、測試、死碼偵測，輸出 0-10 分的綜合評分，告訴你問題優先順序。

把健檢結果交給工程審查，產出安全的重構路徑：哪些先改、哪些不動、改動範圍、預估風險。

依照計畫，小批次、有測試地逐步重構。每個批次都是獨立的 commit，出問題可以輕易 revert。

每個重構批次完成後執行一次 review，確保重構只改了結構，沒有偷偷改變行為。

所有批次完成後，跑一次完整 QA，確認重構前後的外部行為完全一致。