PM 說了一句「讓使用者用 Google 登入」，你覺得很簡單對吧？
先講結論
一個功能從「PM 腦中的念頭」到「使用者能按的按鈕」，要經過七個階段。小功能每階段五分鐘，大功能每階段一週——但流程是一樣的，思考不能省。
這篇是三篇系列的第一篇，涵蓋前三個階段：需求釐清、技術設計、開發準備。後續請看 開發到 Code Review 和 部署到上線後營運。
Phase 1：需求釐清——你到底要我做什麼
PM 說「Google 登入」，你的第一反應如果是打開 IDE，那你還太嫩。
先問問題。不是刁難，是幫團隊省重工：
- 只支援 Google？還是以後要加 Apple、GitHub？（影響你要不要先做抽象層）
- 已有帳號的人用 Google 登入，要自動綁定嗎？（帳號合併是個巨坑）
- Google 登入失敗時使用者看到什麼？（UX 不定義清楚，你就等著被退回）
- 有沒有時程壓力？（決定先做 MVP 還是一次到位）
問完之後交付一份 PRD，不用長篇大論，但至少要有：
## PRD: Google 帳號登入
### 背景
40% 使用者在註冊流程放棄，主因是「不想再記帳密」。
### User Story
- 新使用者：Google 一鍵註冊 + 登入
- 舊使用者：綁定 Google，下次直接用
- 管理員：後台看到誰用 Google 登入
### 範圍
- In: Google OAuth 2.0、email 自動綁定、解除綁定
- Out: Apple / GitHub（Phase 2）
### Acceptance Criteria
1. 點「Sign in with Google」→ 授權 → 自動登入
2. 同 email 帳號自動綁定
3. 可在設定頁解除綁定
4. Google API 掛了顯示友善錯誤，不影響其他登入
5. 登入流程 < 3 秒（不含 Google 授權頁）PRD 的價值不是文件本身，是強迫所有人對「做什麼」和「不做什麼」達成共識。更多請看 好產品的定義。
Phase 2：技術設計——怎麼做
需求確認了，你的主場。
核心是 OAuth 2.0 Authorization Code Flow。幾個關鍵決策：
- Token 格式：JWT（Access + Refresh），stateless 適合分散式
- Token 存放：HttpOnly Cookie，防 XSS
放 localStorage 的人請自首 - OAuth Library：後端用 Google 官方 SDK，不要自己造輪子
- 帳號綁定：email match 自動綁定，PRD 說的
API 端點：
POST /api/auth/google # authorization code 換 JWT
POST /api/auth/google/link # 已登入使用者綁定 Google
DELETE /api/auth/google/link # 解除綁定
GET /api/auth/me # 當前使用者（含綁定狀態）
API Spec 寫進 OpenAPI 文件，前後端依此對齊——這不是可選的。前後端能平行開發的前提，就是有一份雙方都同意的合約。
架構設計的完整方法論請參考 系統規劃方法論、API 設計與認證機制。
Phase 3：開發準備——磨刀不誤砍柴工
開 feature branch：
git checkout develop
git pull origin develop
git checkout -b feature/google-oauth分支名叫 feature/google-oauth，不要叫 feat-1234——只有你自己看得懂的名字就是在跟未來的自己過不去。
環境變數加到 .env.example：
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GOOGLE_REDIRECT_URI=http://localhost:3000/auth/google/callback.env.example 只放 key 不放 value。Secret 透過 Vault 或雲端 Secret Manager 分發，絕對不進 Git。
如果是全新專案，從 Proto clone 出來，不從零開始（見 Proto 規劃）。Proto 幫你處理好 ESLint、Docker、CI/CD 骨架、測試框架。
分支策略細節見 Git Flow。
下一篇：開發、測試到 Code Review——寫 code 的部分才是最容易失控的。