CareerWise 規劃審查模式 — 讓 AI 先提出分析規劃再執行

CareerWise 是一個以 LLM 為核心的職涯諮詢網站，提供履歷健檢、職涯建議與預約諮詢。目前的 career chain（medium tier 的處理路徑，用提示鏈拆成三步驟依序執行：Step 1 背景分析輸出 JSON、Step 2 知識庫比對輸出 JSON、Step 3 個人化建議產出報告）拿到問題就直接跑固定流程，使用者看不到 CareerWise 打算怎麼分析，只能被動接收結果。

這在大部分時候沒問題——使用者丟一個問題，CareerWise 回一份有根據的答案。但如果 CareerWise 打算分析的方向跟使用者預期的不一樣呢？舉例來說，使用者問「該不該轉職去新創」，心裡想的是薪資和工時，但 CareerWise 的分析面向是技能成長與職涯發展。使用者拿到報告才發現方向不對，已經浪費了一次完整的分析流程。如果能讓使用者在分析開始前先看到 CareerWise 打算從哪些角度切入、確認方向對了再執行，就不會發生這種錯位。

這就是規劃審查模式要解決的問題。

直覺的反應是「啊不然呢？AI 回答問題本來就是這樣啊。」但 AI 代理的規劃能力，關鍵差異其實在於從 How 轉變為 What：

過去程式（How）：
  使用者投幣 → 按下 A1 → 掉出可樂
  如果抹茶賣完了 → 當機

AI 代理規劃（What）：
  使用者說「頭痛、需要提神」
  → 代理檢查庫存（抹茶賣完了）
  → 自主決策：氣泡水 + 薑汁 + 濃縮咖啡
  → 特調一杯醒腦飲料

過去程式把每一步都寫死，輸入 A1 就掉出可樂，遇到意外就當機。AI 代理則是自己拆解目標、動態調整、遇到障礙重新規劃路徑。但這也帶來一個新的問題：使用者怎麼知道 AI 打算怎麼做？Google Deep Research 的作法是：先擬規劃、再送審查，批准後才開始投入資源執行。這個「規劃審查模式」正好補上 CareerWise 目前 missing 的那一塊。

從三階分流到四階

原本 career 路徑有三個 tier：

career → simple (SSE) → medium (chain) → complex (平行代理)

• simple：短問句、單一主題，走 SSE streaming，送出後 200ms 首字出現。例如「面試要怎麼準備」
• medium：長問句但主題集中，走 3-step 提示鏈（背景分析 → 知識庫比對 → 產出報告），無法串流，約 3–5 秒一次輸出。例如「我想轉職前端但沒有相關經驗」
• complex：跨領域、含決策詞，走平行化架構，三個 Agent 同時分析後合併報告。例如「該不該離職」

規劃審查不是取代其中任何一層，而是在 medium 和 complex 之間新增一個 planned tier：

career → simple → medium → planned → complex

只對需要規劃的問題啟用審查，簡單問題照樣秒回，不影響既有體驗。

什麼問題會觸發 planned？

classifyTier 新增了 "planned" 的判斷邏輯，觸發條件很直觀：

• 問題包含「規劃」「評估」「分析」「比較」「該不該」「建議」「趨勢」這類規劃關鍵字
• 長度在 6–45 字之間（極短走 simple，過長走 complex）
• 原本會進 complex 的問題，只要長度符合，優先進入 planned

實際跑起來長這樣：

規劃審查怎麼運作

整個流程分為兩個階段：

Phase 1 — 產生規劃

LLM 收到問題後，不是直接回答，而是先產生 3–5 個分析面向：

📋 分析規劃
├── ① 市場分析
├── ② 技能評估
├── ③ 風險評估
└── ④ 文化適應

規劃以 plan 事件回傳給前端，前端顯示一張規劃卡片 + 操作按鈕。

Phase 2a — 批准

使用者按下 [批准執行]，系統依序執行每個分析步驟：每個步驟呼叫一次 LLM 加上知識庫搜尋，結果逐步累積。執行期間卡片會顯示進度：

📋 執行中...
  1. 市場分析    🔄
  2. 技能評估    ⏳
  3. 風險評估    ⏳

四個步驟都跑完後，合併產出最終報告。

Phase 2b — 修改

使用者按下 [修改] 或直接打字「再加薪資分析」，系統把「原規劃 + 使用者修改意見」一起餵給 LLM，LLM 在原規劃的基礎上做局部調整——插入新項目、刪除某個面向、或調整順序。

關鍵是不重新產生完整規劃。如果整份打掉重來，LLM 可能連使用者原本同意的項目也一併改了，變成無窮迴圈——使用者批准 A/B/C，加了 D 之後回來變成 A/E/F，使用者又要改，永遠送不了審。

動態調整做完後回到 Phase 1 的狀態，再次送審讓使用者確認。使用者可以一直改到滿意為止。

Phase 2c — 取消

使用者按下 [跳過規劃，直接回答]，清除規劃回到對話——不走 career chain，LLM 直接用自身知識回答。

為什麼這樣設計

分析面向列表就夠了

規劃只需要列出分析面向（「市場分析」「技能評估」這類），不需要額外說明「為什麼選這個面向」或「預計用什麼方法」。使用者只需要確認方向對不對，塞太多資訊反而是視覺雜訊。

按鈕為主，文字為輔

[批准] [修改] [取消] 三個按鈕處理標準操作。修改時也可以直接打字說「再加薪資分析」——按鈕處理 80% 的場景，文字處理剩下的彈性需求。

動態加入，不重新產生

使用者說「再加薪資分析」時，系統在原規劃裡插入新項目，不會整份打掉重來。如果重新產生，可能連原本使用者同意的項目也一起被改了；如果直接加入不送審，那審查就失去意義了。

對 UI/UX 的影響

規劃審查模式最直接的改變是：使用者從「被動接收結果」變成「主動參與規劃」。

多了一次往返，但換來方向控制權。 原本使用者丟問題、等答案，現在多了審查步驟。壞處是回應時間變長（多一次 LLM 呼叫產生規劃），好處是不會發生「分析方向跟我想的不一樣」的浪費。如果使用者覺得多此一舉，跳過規劃按鈕可以回到傳統模式。

規劃卡片的設計選擇。 規劃只列出分析面向的名稱（市場分析、技能評估），沒有額外說明「為什麼選這個」。原因是使用者只需要確認方向對不對，塞太多資訊反而是視覺雜訊。三個按鈕（批准、修改、取消）處理 80% 的操作，剩下的彈性需求靠打字解決。

執行階段的進度感。 四個步驟依序執行時，卡片會顯示每個步驟的狀態（進行中、已完成、等待中），避免使用者看著空白畫面不知道系統是否還在運作。這對無法串流的 chain 路徑尤其重要——使用者需要知道系統有在動。

修改機制的使用體驗。 使用者可以直接打字說「再加薪資分析」，系統在原規劃中插入新項目，不會整份打掉重來。如果重新產生，使用者可能發現原本同意過的項目被改了，又要再修改，變成無窮迴圈。動態插入 + 再次送審，確保使用者的每次修改都被尊重。

解法

規劃審查模式碰到的 UI/UX 問題，解法核心是降低審查的摩擦成本：

• 跳過按鈕。不是每個問題都需要審查。使用者如果覺得多此一舉，跳過規劃按鈕可以直接回到傳統模式，不用強迫走流程。
• 規劃內容只留必要資訊。分析面向的名稱就夠了，不需要說明「為什麼選這個面向」，降低使用者的閱讀負擔。
• 按鈕為主、文字為輔。批准、修改、取消三個按鈕處理 80% 的操作，剩下的打字解決——不強迫使用者打字，也不用擔心找不到功能在哪。
• 動態修改不重排。使用者說「再加薪資分析」，在原規劃內插入該項目就好，整份打掉重來只會讓使用者困惑「為什麼原本同意的 A 項目不見了」。

改了哪些東西

測試結果

實際跑過一輪完整的規劃審查流程：

輸入: 「該不該轉職去新創」

Phase 1 — classifyTier 判定為 planned ✅
Phase 2 — 產生規劃：市場分析、技能評估、風險評估、文化適應
Phase 3 — 批准執行 → 依序完成 4 步驟 → 產出報告 ✅

最終報告涵蓋四個面向的分析，不是單一觀點的建議。路由分類測試也全數通過——該進 planned 的進 planned，該走 simple 的走 simple，沒有誤判。

總結

規劃審查模式讓 CareerWise 從「AI 直接回答」變成「AI 先說打算怎麼分析 → 你確認方向 → 再開始執行」。多了一次往返，但換來使用者的知情權與方向控制權。

下一步是觀察使用者的實際行為：修改率多少？會不會有人覺得多此一舉直接跳過？這些數據會決定規劃審查是成為常態流程，還是只服務特定類型的使用者。

CareerWise