01 / OUTCOME
商業目標與決策邊界
先釐清這次要做的決策、不可犧牲的營運條件，以及哪些議題不在本次範圍。
- 市場與通路優先序
- 成功指標與限制
- 已知假設與不可變條件
這份藍圖是
一份讓決策可被審查的共同底稿
- 架構選項、假設、取捨與拒絕理由
- 資料、SEO、整合及切換的驗收證據
- 決策門、RACI 與接手團隊可執行的待辦清單
這份藍圖不是
一張先有答案、再補理由的技術清單
- 不預設 Shopify、Headless 或全面重建一定適合
- 不以一張系統圖取代資料與營運驗證
- 不把未決事項藏在報價、排程或模糊的「待確認」中
01 / 必要輸入
沒有輸入證據，架構只會是偏好。
不要求一開始就文件齊全；但每個缺口都必須成為有負責人、取得方式與阻擋影響的明確事項。
02 / SYSTEM
現況系統與責任人
盤點商務平台、CMS、搜尋、支付、會員、行銷與內部系統，連同實際維運者一起確認。
- 系統清單與版本
- 資料讀寫方向
- 業務與技術責任人
03 / DATA
資料模型與品質
檢視商品、庫存、顧客、訂單、折扣與訂閱等關鍵資料的來源、轉換及例外。
- 來源資料樣本
- 數量與欄位基準
- 歷史資料保留規則
04 / DISCOVERY
內容、SEO 與衡量基準
在改造前留下網址、內容、結構化資料、分析事件與自然搜尋表現的可比較基準。
- 可索引網址清單
- 內容類型與擁有者
- 分析事件與同意模式
05 / INTEGRATION
整合契約與失敗路徑
除了列出 API，也要確認權威來源、同步頻率、重試、冪等、告警與人工補救。
- 介面與驗證方式
- 錯誤處理流程
- 服務窗口與升級路徑
06 / DELIVERY
組織與發布限制
把採購、安全、法務、內容凍結、旺季與內部發布流程納入架構決策。
- 審核與簽核角色
- 發布與回復能力
- 依賴團隊的可用性
02 / 挑戰規劃
先從你正在承擔的風險開始。
選擇目前的挑戰，查看應被納入討論的交付物。三項核心交付物固定保留：決策紀錄、系統圖與實作交接。
匿名規劃工具
先選問題，再看應該留下哪些交付物。
可複選。這裡不要求輸入機密資料，也不會送出或保存你的選擇。 結果是對話起點，不是自動產生的架構答案。
建議交付物組合
已選 0 個挑戰；目前啟用 3 份交付物。
A01core
架構選項與決策紀錄
候選方案 · 評估準則 · 取捨與決策狀態
A02core
現況與目標系統圖
系統與通路 · 資料流向 · 擁有者與邊界
A03standby
資料遷移與對帳計畫
欄位映射 · 數量與樣本對帳 · 例外與回復
A04standby
整合契約與韌性清單
讀寫契約 · 失敗與重試 · 告警與升級
A05standby
SEO 與內容保存計畫
網址與轉址對照 · 索引控制 · 上線前後爬取
A06standby
體驗與非功能需求
關鍵使用流程 · 效能與韌性預算 · 營運操作需求
A07standby
驗證、切換與回復矩陣
驗證順序 · 放行／不放行條件 · 回復觸發與步驟
A08core
實作交接包
分階段待辦清單 · 依賴與責任人 · 驗收與決策連結
Core 為任何診斷都保留的基礎交付物；Mapped 會隨挑戰加入。正式範圍仍需依證據與決策邊界確認。
03 / 交付物資料庫
系統圖要連回可追溯的證據。
每份交付物都要回答「包含什麼」與「完成時拿什麼證明」，避免架構只剩簡報語言。
A01
架構選項與決策紀錄
比較可行方案、取捨與拒絕理由，讓後續團隊知道決策成立的條件。
- 候選方案
- 評估準則
- 取捨與決策狀態
完成證據：完成時應有可簽核的選項比較，以及仍待驗證的假設清單。
A02
現況與目標系統圖
標記系統邊界、資料方向、來源真相、同步方式與營運責任。
- 系統與通路
- 資料流向
- 擁有者與邊界
完成證據：完成時每條關鍵資料流都能指向來源、目的地與責任人。
A03
資料遷移與對帳計畫
定義資料範圍、欄位映射、轉換、清理、試遷移、差異處理與回復方式。
- 欄位映射
- 數量與樣本對帳
- 例外與回復
完成證據：完成時每個資料集都有驗收規則與差異處理負責人。
A04
整合契約與韌性清單
逐一記錄介面、認證、速率限制、逾時、重試、冪等、監控與人工補救。
- 讀寫契約
- 失敗與重試
- 告警與升級
完成證據：完成時主要失敗情境都有偵測方式、處理路徑與擁有者。
A05
SEO 與內容保存計畫
把網址、重新導向、canonical、結構化資料、robots、內容模型與追蹤納入切換。
- 網址與轉址對照
- 索引控制
- 上線前後爬取
完成證據：完成時舊有可索引頁面都有保留、合併或退場決策。
A06
體驗與非功能需求
將效能、可用性、權限、安全、可觀測性與內容操作需求寫成可驗收條件。
- 關鍵使用流程
- 效能與韌性預算
- 營運操作需求
完成證據：完成時每項需求都有衡量方式、適用範圍與驗收角色。
A07
驗證、切換與回復矩陣
把試跑、凍結、資料增量、冒煙測試、監看、放行、不放行與復原串成一張表。
- 驗證順序
- 放行／不放行條件
- 回復觸發與步驟
完成證據：完成時每個切換動作都有執行人、核准人、證據與失敗處置。
A08
實作交接包
把已核准決策轉為可估算、可排序、可驗收且有明確依賴的實作工作。
- 分階段待辦清單
- 依賴與責任人
- 驗收與決策連結
完成證據：完成時接手團隊能追溯每項工作為何存在、誰核准、如何驗收。
04 / Decision gates
每前進一步，都要知道誰能說「可以」。
Gate 要寫清楚待回答的問題、通過證據與核准責任。若未通過，就回頭補齊缺口，不依預設流程繼續。
- G1
證據是否足夠
現況、限制與未知項是否已被看見？
通過證據輸入清單、缺口、假設與取得方式均有紀錄。
核准負責人商務負責人核准問題邊界。
- G2
方案是否適配
選定架構是否優於其他可行選項？
通過證據依共同準則完成選項比較、風險與拒絕理由。
核准負責人商務與技術決策者共同核准。
- G3
遷移是否可驗證
資料、SEO 與整合能否用證據判定成功？
通過證據對帳、爬取、契約測試與例外處理均有門檻。
核准負責人各資料與通路擁有者接受驗收規則。
- G4
切換是否可控制
上線、監看與回復是否有一致指揮？
通過證據放行／不放行、責任、時間點、監測與回復皆明確。
核准負責人發布負責人持有最終切換權。
- G5
交接是否可執行
接手團隊能否估算、排序、實作與驗收？
通過證據backlog 連回決策，依賴、負責人、完成條件與證據齊備。
核准負責人實作負責人確認接收並列出未決事項。
05 / 責任分工
架構是跨團隊承諾，不是架構師的獨白。
R 執行 ResponsibleA 核准 AccountableC 協作 ConsultedI 知會 Informed
| 工作流 | 商務負責人 | 內部產品／技術 | 資料／營運負責人 | Tenten | 實作負責人 |
|---|---|---|---|---|---|
| 定義商業成果與範圍 | A / R | C | C | R | I |
| 提供現況系統與限制證據 | A | R | R | C | I |
| 建立選項、取捨與目標架構 | A | C | C | R | C |
| 核准資料、SEO 與整合驗收規則 | A | C | R | R | C |
| 拆分待辦清單與實作依賴 | A | C | C | R | R |
| 接受交接與管理後續變更 | A | C | I | C | R |
這是建議起點；實際 RACI 需依組織、供應商與決策權限確認。A 應盡量保持單一且明確。
06 / 驗證
三條不能等到上線後才驗證的路徑。
資料、SEO 與整合各有不同的失敗方式，因此也需要不同的基準、測試與結束證據。
資料完整性
搬過去，不等於搬對了。
- 01每個資料集先固定來源筆數、欄位與樣本基準
- 02轉換規則可追溯，敏感資料與刪除規則明確
- 03全量、增量與例外都能對帳，差異有負責人
完成證據對帳報告、差異清單、例外處置與簽核紀錄。
可發現性保存
新頁面上線，不代表搜尋資產被保留。
- 01上線前盤點可索引網址、canonical、結構化資料與內鏈
- 02每個舊網址有保留、合併、301 或退場決策
- 03上線前後執行爬取，檢查 robots、sitemap 與回應碼
完成證據網址對照、轉址測試、爬取差異與追蹤計畫。
整合韌性
正常流程通過，不代表例外可以營運。
- 01每個介面有來源真相、讀寫方向、認證與限制
- 02逾時、重試、冪等、佇列與人工補救有明確規則
- 03告警能到達當班負責人，並有升級與復原紀錄
完成證據契約測試、失敗演練、告警證據與責任窗口。
07／實作交接
交接要把決策能力一起移交。
接手團隊應能看懂工作為何存在、依賴誰、如何驗收，以及新資訊出現時要回到哪個決策點。
- 01
決策 → 工作
每個大型工作項目與任務都連回已核准的架構決策或風險。
- 02
負責人 → 相依項目
每項依賴有提供者、需要日期、接受者與升級路徑。
- 03
完成條件 → 證據
完成條件說明如何測、由誰驗收、證據放在哪裡。
- 04
變更 → 決策紀錄
需求變更回到決策紀錄，重新評估影響而不是口頭覆蓋。
常見問題
開始之前，先對齊幾件事。
如果你的問題涉及既有系統、資料責任或多方供應商，可以在第一次對話時直接帶入。
不會。診斷先定義目標、限制與評估準則，再比較可行架構。若證據不支持 Headless、全面遷移或特定平台，決策紀錄應清楚說明原因。
報價通常回答投入範圍，技術規格回答如何建置；藍圖先回答為何選這個方向、需要哪些證據、風險如何驗證、誰有決策與驗收責任。之後才把核准內容轉為可估算的待辦清單。
可以先從可取得的系統清單、資料樣本、網址與關鍵流程開始，但缺口必須被列為假設或待辦，並標示取得方式、負責人及它會阻擋哪一道決策門。
可以，而且在多系統環境通常很重要。RACI 會區分商務核准、內部技術、資料與營運擁有者、架構協作及未來實作責任，避免把所有問題推給單一團隊。
藍圖會定義可驗收的方法與證據：資料以基準、對照、樣本及數量對帳；SEO 以網址對照與上線前後爬取；整合以契約、失敗路徑、告警與負責人驗證。實際測試深度仍依核准範圍與可用環境決定。
不一定。交接包的目的就是讓指定的實作團隊能追溯決策、估算工作並驗收成果；接手者可以是內部團隊、既有合作夥伴或後續選定的服務團隊。
不會。這個規劃器只在目前瀏覽器頁面中即時計算，沒有文字輸入、帳號、儲存或網路送出。它用來整理初步對話，不能取代正式的證據盤點與架構判斷。
帶著待決定的問題來，不必先選好解法
把「要不要重做」改成一組能被回答的問題。
帶上目前的系統、資料與決策限制。我們先確認問題邊界、需要的證據，以及 Blueprint 是否適合這次決策。
討論架構題目