Quick Flow（快速工作流程）
Quick Flow 是 Superpowers 中最高效的工作流程，專為緊急任務、簡單功能或快速修復設計。它強調速度和實用性，在保持基本品質的同時快速完成工作。
v6.4.2 之後：
writing-plans對計畫的要求改為「只記錄實作需要的決策」（檔案、介面簽名、測試斷言），不再用時間估算。Quick Flow 與此一致：用範圍與驗收標準控制節奏，而不是用分鐘數。
何時使用 Quick Flow
✅ 最適合的情境：
- 緊急的 bug 修復（hotfix）
- 範圍小而明確的功能開發（能在一次工作階段內完成）
- 明確的程式碼調整
- 配置檔案修改
- 文案或內容更新
- 快速的樣式調整
❌ 不適合的情境：
- 複雜的功能開發
- 需要深入設計的重構
- 涉及多個模組的變更
- 不確定解決方案的情況
Quick Flow 的三個步驟
第 1 步：快速分析
快速理解問題和制定簡單計畫：
問題理解：
- 問題是什麼？
- 期望的行為是什麼？
- 當前的行為是什麼？
解決方案：
- 最簡單的修復方式是什麼？
- 需要修改哪些檔案？
- 有什麼潛在風險？
驗收標準：
- 如何確認問題已解決？
- 需要測試哪些情況？
第 2 步：直接實作
立即開始實作，保持簡單：
Quick Flow 實作原則：
- 最簡單的解決方案
- 最少的檔案修改
- 最快的測試驗證
- 直接的程式碼變更
第 3 步：快速驗證
確認修復有效且沒有破壞其他功能：
驗證步驟：
- 測試修復的功能
- 執行相關測試
- 快速檢查相關功能
- 確認可以提交
實際範例
範例 1：緊急 Bug 修復
情境：生產環境發現按鈕點擊沒有反應
第 1 步：快速分析
問題： 使用者回報「提交按鈕點擊後沒有反應」
快速檢查：
- 檢查 Console：發現
TypeError: Cannot read property 'then' of undefined - 問題原因：API 函數沒有返回 Promise
- 影響範圍：只影響提交功能
解決方案： 在 submitForm 函數中加上 Promise 返回
第 2 步：直接實作
// 修復前
const submitForm = (data: FormData) => {
api.submit(data); // ❌ 沒有返回 Promise
};
// 修復後
const submitForm = (data: FormData) => {
return api.submit(data); // ✅ 返回 Promise
};第 3 步：快速驗證
本地測試：
- 點擊提交按鈕 ✓
- 表單成功提交 ✓
- 顯示成功訊息 ✓
範例 2：簡單功能添加
情境：需要在現有頁面加上「返回」按鈕
第 1 步：快速分析
需求： 在使用者設定頁面加上返回按鈕
實作方式：
- 使用 React Router 的 navigate(-1)
- 按鈕樣式與其他按鈕一致
- 放置在頁面標題旁邊
第 2 步：直接實作
// 在 Settings.tsx 中加上返回按鈕
import { useNavigate } from 'react-router-dom';
function Settings() {
const navigate = useNavigate();
return (
<div>
<div className="flex items-center gap-4">
<button
onClick={() => navigate(-1)}
className="text-gray-600 hover:text-gray-900"
>
← 返回
</button>
<h1>設定</h1>
</div>
{/* 設定內容 */}
</div>
);
}第 3 步：快速驗證
測試：
- 點擊返回按鈕 ✓
- 正確返回上一頁 ✓
- 樣式符合預期 ✓
Quick Flow 的特點
1. 範圍優先
Quick Flow 控制的是範圍，不是鐘錶：
- 分析只做到「知道要改什麼、怎麼確認」就停
- 實作只做最小可行修正
- 驗證只確認核心行為與相關測試
範圍一旦開始膨脹（發現要多改兩三個模組、解法還不確定），就是該換流程的訊號。
2. 簡單直接
Quick Flow 偏好的實作方式：
✅ 好的 Quick Flow 程式碼：
const isValid = email.includes('@'); // 簡單明瞭❌ 過於複雜（不適合 Quick Flow）：
const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
const isValid = emailRegex.test(email);3. 最小變更
Quick Flow 的修改原則：
- 只修改必要的檔案
- 只修改必要的程式碼
- 避免重構或優化
- 保持變更範圍最小
Quick Flow 與其他流程的對比
vs Full Flow
| 特點 | Quick Flow | Full Flow |
|---|---|---|
| 範圍 | 一次工作階段內完成 | 跨多個工作階段 |
| 步驟 | 3 個 | 7+ 個 |
| 文件 | 最小 | 完整 |
| 審查 | 可選 | 必須 |
vs Incremental Flow
Quick Flow：
- 一次性完成
- 不考慮後續擴展
- 快速交付價值
Incremental Flow：
- 分階段完成
- 考慮後續擴展
- 穩健的迭代
Quick Flow 的限制
1. 不適合複雜問題
使用 Quick Flow 的風險：
- 可能引入技術債務
- 可能缺少完整測試
- 可能忽略邊界情況
- 可能需要後續重構
2. 需要後續跟進
Quick Flow 後的跟進工作：
- 如果修復正確，標記為完成
- 如果問題複雜，建立後續任務重構
- 如果影響範圍大，安排完整審查
- 更新相關文件（如需要）
Quick Flow 的最佳實踐
1. 快速但不能草率
Quick Flow 的品質標準：
- ✅ 功能正確實作
- ✅ 沒有明顯的 bug
- ✅ 通過基本測試
- ✅ 程式碼可讀
可接受的簡化：
- ⚠️ 可能不是最佳實踐
- ⚠️ 可能需要後續重構
- ⚠️ 測試覆蓋可能不完整
2. 明確的範圍界限
設定範圍界限：
- 一次只修一個問題
- 只碰必要的檔案
- 如果範圍膨脹：停下來，重新評估是否需要其他流程
3. 快速文件
Quick Flow 的最小文件：
git commit 訊息：
fix: 修正提交按鈕無回應的問題
問題：API 函數沒有返回 Promise
解決：在 submitForm 中返回 Promise
影響：提交功能恢復正常何時避免 Quick Flow
需要使用 Full Flow 的情況
切換到 Full Flow 如果：
- 問題複雜且原因不明
- 需要深入分析和解決方案設計
- 影響範圍大或多個模組
- 沒有明確的解決方案
- 需要考慮長期影響
需要使用 Incremental Flow 的情況
切換到 Incremental Flow 如果：
- 功能可以分階段實作
- 需要逐步驗證方向
- 不確定最終需求
- 需要使用者回饋迭代
Quick Flow 成功的關鍵
1. 明確的問題定義
好的 Quick Flow 開始： ✅ 「按鈕點擊沒有反應，Console 顯示 TypeError」
不好的 Quick Flow 開始： ❌ 「某個功能好像有問題」
2. 限制變更範圍
Quick Flow 的變更範圍建議：
- 檔案數量：1-3 個
- 程式碼行數：< 100 行
- 影響模組：單一模組
- 測試需求：基本驗證
3. 快速驗證循環
Quick Flow 的驗證循環：
實作 → 測試 → 確認 → 完成- 總循環數：1-3 次
Quick Flow 的變體
Ultra-Quick Flow（超快速）
適用：明顯的 typo 或配置錯誤——修正本身無歧義、不需要分析步驟。
步驟：
- 直接修正
- 快速測試
- 提交
Standard Quick Flow（標準快速）
適用：簡單的 bug 修復或小功能——動手前需要先在腦中擬定一兩步做法。
步驟：
- 快速分析
- 直接實作
- 快速驗證
Quick Flow 是 Superpowers 中最實用的工作流程之一，掌握它能讓你在緊急情況下快速回應，同時保持基本的品質標準！