先記住：競品分析分開證據、推論與未知。
需要深入時：再做 ADR 與驗證實驗。

「這個網站很快，應該是用了某個框架吧？」

假設我們觀察一個購物網站，頁面切換流暢，就想請 AI 分析它的前端架構。
搭啦～
我們很容易得到一份完整答案：微前端、邊緣快取、某套狀態工具，聽起來都很合理。

不過從畫面體驗，不能直接推論內部用了什麼。
公開腳本或網路請求能提供線索，仍不等於知道所有服務與部署方式。
競品分析最需要的是證據紀律。

把筆記分成三欄

觀察：切換分類後 URL 改變，重新整理仍保留篩選。
推論：篩選狀態可能與路由同步。
未知：它用了哪個狀態函式庫、資料是否經過服務端聚合。

第一欄能用錄影、截圖或公開文件支持；
第二欄需要標明推論；
第三欄不能讓 AI 自動補答案。

這樣做的好處是，就算猜錯框架，我們仍然能學到有價值的產品行為：篩選可分享、返回有保留、錯誤可恢復。

選型回到自己的限制

假設團隊正在評估維持單一前端，還是導入微前端。

嘗試先列痛點：有沒有多團隊獨立發布需求？目前衝突是程式邊界不清，還是部署真的互相阻擋？
再比較學習成本、測試、發布、效能與回退能力。
不要先給每個工具五顆星，再假裝總分最高就是答案。
評分權重如果沒有來源，也只是把工具偏好變成數字。

若關鍵未知是共享依賴會增加多少下載量，就做一個限時 prototype，在相同頁面與條件下測量。
沒有實測就寫「待驗證」，不要編造提升百分比。

做一份小型 ADR

ADR 是架構決策紀錄。
我比較懶一點。剛開始先只寫一頁：
背景、選項、採用理由、代價與重新檢討條件。

例如教學決策：三人團隊先維持單體，強化功能模組與版本管理；
等有獨立發布且頻繁互相阻擋的證據，再評估拆分。
這不是單體永遠最好，而是當下開發的成本比較合理。

AI 可以幫忙整理比較項目、搜尋官方限制與設計試驗；最終選擇仍需要團隊承擔後續維運。

可以交給 AI 的 Prompt

請分析我提供的競品觀察紀錄，每項分成直接證據、合理推論與未知。沒有公開證據，不要判定框架或後端架構。接著針對三人前端團隊的購物網站，比較維持模組化單體與拆分微前端的代價。請列決策條件與最小驗證實驗，不提供虛構效能數字。

這段用 SA 管理證據，再用 SD 比較取捨。
若需要當前版本資訊，應查官方資料並記錄日期，而不沿用記憶中的工具功能。

今日練習與筆記

找一個喜歡的網站，只記錄三個使用者可觀察的行為。
每個行為寫一個你可以借鏡的設計問題，然後不去猜測框架。
明天把這週的做法收束成 PRD 與 User Story 工作流。
個人認為這是一個蠻好的切入點，抓了很多網站拿來分析。