理論與工具在真實問題前才能見真章。這篇記錄一個真實場景的全流程：從 PM 丟過來的一句話，走過 Intent Extraction → Problem Framing → Spec → Plan → Tasks，看看每個環節把問題的形狀改變了多少。
起點：一句模糊的需求
PM：「用戶對登入體驗不滿意，能不能改一下？」
這是一個「症狀陳述」，不是問題定義。它沒有告訴我們：哪個用戶？哪種不滿意？現在的數字是什麼？改到什麼程度算「改好了」？
如果此刻直接開工，你會在「猜測什麼是對的解法」上花大部分精力。
第一步：Intent Extraction（Interview Me）
目標：確認對方真正想要的是什麼，而不是他描述問題的方式。
Q：你說「用戶不滿意」——你指的是哪些用戶？在哪裡看到這個信號？
猜測：大概是客服票或 App Store 評論，抱怨密碼登入太麻煩？
PM：主要是 App Store 一顆星評論，最近三個月暴增，很多人說
「每次都要重新登入，很煩」。
Q：「每次都要重新登入」——你知道是 session 過期太短，
還是另有原因（比如強制重登或 token 更新有 bug）？
猜測：大概是 session TTL 設得太短，7 天就到期了。
PM：我不確定，但 iOS 更新之後就開始變多這類評論了。
確認後的意圖聲明：
Outcome：讓已驗證用戶不需要頻繁重新登入
User：現有 iOS 用戶（特別是每週使用一次以上的回頭客）
Why now：iOS 更新後一顆星評論量三個月內增加，懷疑 session 持久化行為改變
Success：每週活躍用戶的強制重登次數降至 ≤1 次/月
Constraint：不能降低帳戶安全性，不能破壞現有 Android 行為
Out of scope：新用戶首次登入流程、社交登入功能
第二步：Problem Framing
意圖聲明告訴我們「什麼方向」，Problem Framing 告訴我們「為什麼這裡有個洞」。
5 Whys：
症狀：iOS 用戶每週需要重新登入 Why 1：為什麼需要重新登入？→ Session/token 過期了 Why 2：為什麼 token 過期？→ Refresh token 沒有被正確儲存進 iOS Keychain（iOS 更新後行為改變） Why 3：為什麼 Keychain 儲存邏輯沒有跟上 iOS 更新？→ 沒有針對 iOS major version 的回歸測試 Why 4：為什麼沒有這個測試？→ 當初的測試策略沒有覆蓋「OS 升級後的持久化行為」 Why 5：為什麼測試策略沒有覆蓋這個？→ 我們假設 Keychain API 是穩定的，不需要測
根因：「Keychain API 行為在 iOS 版本之間的穩定性假設從未被驗證過，也沒有自動測試覆蓋它。」
HMW 重構：
- 我們要怎樣才能讓已驗證的 iOS 用戶在跨版本升級後仍保持登入狀態？
- 我們要怎樣才能在 iOS major update 之後，自動偵測 auth 持久化回歸？
問題陳述句：
已驗證 iOS 用戶在 iOS major version 升級後，
因 Keychain refresh token 持久化行為改變而被強制重登，
導致每月約 12% 的週活用戶流失一次完整登入 session，
App Store 一顆星評論量三個月增加 47%。
這個陳述比「登入體驗不好」具體 10 倍，而且可以被測試：修完之後，同樣的 iOS 升級場景，強制重登應該不再發生。
第三步：Specify
## Objective
讓已驗證 iOS 用戶在 iOS major version 升級後維持登入狀態。
**驗收標準：**
- 模擬 iOS 17 → 18 升級後，refresh token 從 Keychain 正確讀取，
用戶無需重新輸入密碼
- 週活用戶強制重登次數 ≤1 次/月（以 Session invalidation log 量測）
- Android 行為不受影響（現有 Android E2E test suite 全過）
## 假設
1. Refresh token 目前儲存在 Keychain，不是 UserDefaults
2. 問題在 iOS 17 → 18 升級的 Keychain migration policy 改變（待確認）
3. 後端 token 驗證邏輯不需要改動
→ 假設 2 需要在 iOS 測試機上先驗證，未確認前不進入 Plan
## Boundaries
- Always：改動前後跑完 iOS E2E auth flow test
- Ask first：任何改動 token 儲存格式的決策（影響所有已登入用戶）
- Never：直接在 production 測試 token migration logic第四步：Plan → Tasks
計畫（Plan）：
- 在 iOS 17 / 18 測試機上複現問題，確認根因（Keychain migration policy）
- 修正 Keychain 存取邏輯，支援新的
kSecAttrAccessibleAfterFirstUnlock政策 - 加入 iOS 版本升級的回歸測試（XCTest + 模擬器 snapshot）
- Staged rollout：先 10% 用戶，觀察 Session invalidation 指標
任務（Tasks，垂直切片）：
Task 1：複現問題
驗收：在 iOS 17 → 18 升級後，refresh token 讀取失敗，可重現
驗證：手動測試 + 截圖記錄
預估：S（1 人 × 2 小時）
Task 2：修正 Keychain 存取邏輯
驗收：iOS 17 → 18 升級後，token 讀取成功，無重登
驗證：iOS E2E auth test pass；Android E2E test pass
預估：M（1 人 × 4 小時）
Task 3：加入回歸測試
驗收：CI 包含一個測試案例，模擬 Keychain migration，
在邏輯被改壞時會失敗
驗證：故意引入 regression，確認測試失敗
預估：M（1 人 × 3 小時）
Task 4：Staged rollout 計畫
驗收：rollout plan 文件，含回滾條件和監控指標
驗證：PM + 工程 lead review
預估：S（0.5 小時）
結果：問題的形狀改變了多少
| 環節後 | 問題的描述 |
|---|---|
| 初始需求 | 「登入體驗不好，改一下」（無邊界、無指標、無根因） |
| Intent Extraction 後 | 「iOS 用戶週活中有重複強制重登，iOS 更新後惡化」（有用戶、有信號、有範圍） |
| Problem Framing 後 | 「iOS major version 升級改變 Keychain 存取政策，導致 refresh token 讀取失敗」（有根因、可測試） |
| Spec 後 | 可量測的驗收標準 + 明確假設清單 + 邊界定義 |
| Tasks 後 | 4 個有驗收標準的具體任務，總估時 9.5 小時 |
如果跳過前三步直接開工，很可能花在「優化密碼輸入 UI」或「加入 Social Login」上，解掉一個不存在的問題。
延伸
- Problem Framing 工具詳解 → Problem Framing：定義正確問題
- Spec-Driven 工作流程詳解 → Spec-Driven Development：規格先行
- 閉環全景 → Framing → Spec → 實作 → 驗證：閉環全景
- 回到全景 → Problem Framing ＋ Spec-Driven Development 專欄首頁