讓 CareerWise 愈用愈懂你：學習與適應

CareerWise 是一個職涯諮詢 AI 服務，使用者在上面詢問面試準備、履歷健檢、轉職規劃等問題，由 AI 代理扮演職涯顧問來回答。目前的記憶機制（profile + memory）讓系統可以記住使用者的事實與偏好，但系統是被動儲存——使用者說了什麼就存什麼，不會主動根據使用者的行為調整自己的回應方式。

這篇文章要紀錄的是學習模式中最適合 CareerWise 的做法：線上學習（Online Learning）——系統在每次互動後，根據使用者的回饋和行為，動態調整後續的回應方式。總共分為四個部分：P1 使用者偏好學習、P2 回饋機制、P3 從修正中學習、P4 版本變更日誌。

P1 — 使用者偏好學習

問題：目前 CareerWise 的 system prompt 是固定的，所有使用者看到同一組回答原則。使用者必須每次重複說「我不喜歡空泛建議」、「太長了」、「可以具體一點嗎」，CareerWise 才會在當次修正，但下次又忘了。

設計決策

1. 學習來源 — 系統從哪裡取得使用者的偏好訊號。也就是說，CareerWise 要怎麼知道使用者喜歡什麼、不喜歡什麼。主要有兩種訊號來源：使用者主動說的（明確回饋）和使用者行為透露的（隱含行為）。

選擇 C — 明確回饋為主 + 隱含行為為輔：

選擇原因：使用者不常主動給回饋，只靠 A 資料稀疏。隱含行為（B）可能誤判（閱讀時間短可能只是分心）。C 讓明確信號（修正 + 回饋）優先，隱含行為（跳過長篇回答的頻率）輔助。

2. 儲存位置與注入方式 — 偏好資料要存在哪裡、怎麼讓 CareerWise 在回答時知道這些偏好

選擇 C — Firestore + 動態注入 system prompt：

選擇原因：偏好需要持久化（跨對話），也需要在每次回答時被 CareerWise 知道。C 整合現有 client context 機制，將 preferences 與 profile/memory 一起載入並 append 到 system prompt 結尾。

// 注入後的 system prompt：
「你是 CareerWise — 一位擁有豐富經驗的前端工程師與職涯顧問。
...
使用者的個人檔案：現職：前端工程師，年資：3 年
使用者的偏好：喜歡簡潔回答、不喜歡條列式」

3. 觸發時機 — 什麼時候分析使用者對話並更新偏好

選擇 A — 每次回答後輕量分析 + 明確修正直接更新：

選擇原因：A 讓學習即時發生——使用者說「太長了」後，下次對話立即生效。成本可控（每次約 100 tokens 的輕量分析）。B 錯過「謝謝很有幫助」這類正面回饋。C 學習延遲，使用者無感。

4. 注入方式 — 偏好資訊以什麼形式送進 LLM 的提示詞

選擇 A — 直接 append 到 system prompt 結尾：

5. 生命週期 — 偏好改變時，舊的資料怎麼處理

選擇 A — 新值覆蓋舊值：

選擇原因：偏好的本質是「當下設定」，不是「歷史經驗」。使用者說「太長了」就是要 CareerWise 現在改，不需要保留「去年喜歡詳細」的記錄，也不需要先問使用者。

Firestore 結構

// users/{uid}/profile/data 擴充
{
  current_role: "前端工程師",
  years: 3,
  skills: ["front-end", "development"],
  goals: ["轉管理職"],
  preferences: {
    style: "concise",           // concise | detailed
    tone: "direct",             // direct | warm
    detail_level: "high",       // high | low
    avoid: ["條列式", "空泛建議"]
  }
}

P2 — 回饋機制（Thumbs Up/Down）

問題：目前 CareerWise 回答後，使用者沒有任何方式表達滿意或不滿意。沒有 👍/👎 按鈕、沒有評分機制、沒有「這有幫助嗎？」的詢問。系統完全不知道哪些回答是好的、哪些需要改進。學習與適應需要明確的回饋信號——沒有回饋，系統就只能盲目猜測使用者的偏好，無法針對性地調整回應方式。

設計決策

1. 按鈕呈現 — 回饋按鈕長什麼樣子

選擇 B — 👍/👎 + 可選原因：

2. 儲存位置 — 回饋資料存在哪裡

選擇 B — 獨立 feedback 集合：

// users/{uid}/feedback/{autoId}
{
  rating: "up" | "down",
  reason: "too_long" | "vague" | "tone" | "generic" | "other" | null,
  messageId: string,
  messageSnippet: string,  // 前 50 字
  createdAt: Timestamp
}

3. 影響後續回答 — 按 👎 後 CareerWise 會做什麼

選擇 A — 即時修正 + 記錄偏好：

4. 重新生成流程 — 新回答怎麼呈現給使用者

選擇 B — 原回答保留，下方追加新回答：

CareerWise: （原本的回答）
              [👍] [👎]
                 ↓ （使用者按 👎 → 選「太長了」）
已根據你的回饋調整，這是更簡潔的版本：
（新回答串流）
              [👍] [👎]

5. 儀表板 — 回饋資料的分析與呈現

選擇 C — 完整儀表板：

選擇原因：回饋資料的價值在於長期趨勢分析，不是只看今天。

P3 — 從修正中學習（Correction Learning）

問題：當使用者說「不對」、「不是這樣」、「我沒說過」時，系統需要判斷這是修正指令，並即時更新記憶和偏好。

設計決策

1. 觸發條件 — 怎麼知道使用者在修正

選擇 C — 關鍵字秒判斷 + LLM 輔助判斷：

2. 回應方式 — 系統更新後怎麼告知使用者

選擇 C — 更新 + 解釋：

選擇原因：C 讓使用者知道修正已生效——「好的，我原本記錄了『想轉管理職』，現在已更新為『加強技術深度』」。使用者看到具體的變更內容，信任感更高。

3. 影響範圍 — 一次修正要同步更新哪些資料

選擇 C — LLM 判斷影響範圍：

選擇原因：使用者說「我沒說過想轉管理職」可能影響 memories（刪除）、goals（移除）、profile（更新）。C 讓 LLM 根據修正內容動態決定影響範圍，不需要預先定義規則。

P4 — 版本變更日誌

問題：CareerWise 持續更新（知識庫新增、功能改善、prompt 優化），但使用者不知道系統改變了什麼。當回答方式改變時，使用者困惑「它什麼時候變的？為什麼變？」。

設計決策

1. 觸發時機 — 更新日誌在什麼時候顯示給使用者

選擇 C — 可關閉橫幅：

2. 儲存位置 — 更新日誌存在哪裡

選擇 A — Firestore 全域集合：

3. 內容格式 — 更新日誌要寫哪些資訊

選擇 B — 標題 + 改善重點：

📢 CareerWise 已更新（2026-07-24）
• 現在會參考你的個人檔案來回答
• 改善了建議的具體性
• 新增了計劃審查功能

Firestore 結構

// updates/{updateId}
{
  date: "2026-07-24",
  title: "CareerWise 已更新",
  items: [
    "現在會參考你的個人檔案來回答",
    "改善了建議的具體性",
    "新增了計劃審查功能"
  ],
  type: "improvement"  // "new_feature" | "improvement" | "knowledge"
}

測試方式

測試 1：偏好學習（P1）

在 chat 輸入「太長了」「不喜歡條列式」
→ 打開 /memories
→ 偏好設定區塊應該出現：風格：簡潔、避免：條列式

測試 2：回饋按鈕（P2）

在 chat 輸入「怎麼談薪水」
→ CareerWise 回答後，下方出現 👍/👎 按鈕
→ 按 👎 → 跳出 5 個原因選項
→ 選「太長了」→ 原始回答保留，下方串流新回答

測試 3：計劃持久化（P4）

輸入「該不該轉職去新創」
→ 看到計劃卡片 → Cmd+R 重新整理
→ 計劃卡片還在（Firestore client-side 儲存）

測試 4：/memories 頁面完整功能

打開 http://localhost:3000/memories
→ 個人檔案：可編輯現職、年資、技能
→ 偏好設定：可編輯風格、語氣、具體程度、避免
→ 歷史記憶：可新增、刪除
→ 表現統計：本週 👍 率、最常被 👎 的原因（需有回饋資料）
→ 更新記錄：CareerWise 更新日誌

測試 5：Terminal Log 確認

[Profile] Merged via client SDK    ← profile/preferences 有寫入
[Profile] Using client context     ← 個人化內容有載入

對 UI/UX 的影響

學習與適應對使用者來說，最直接的感受是CareerWise 愈來愈懂得自己的偏好。

• 即時修正的體驗。 使用者說「太長了」後按 👎 選原因，原回答保留在畫面上，下方立即串流新版本。使用者可以比對前後兩個版本，確認新的真的有改善。這種即時性讓使用者感覺「它真的聽到了」。
• 偏好可視化。 所有學習到的偏好都在 /memories 頁面顯示，使用者可以查看、編輯、刪除。如果 CareerWise 學錯了（例如把「一次不喜歡」誤判為「永遠不喜歡」），使用者可以直接修正。
• 更新告知不強迫。 版本變更以可關閉橫幅呈現，使用者知道有更新但不被打斷。想了解詳情可以展開查看，不想看可以關掉。

解法

• 關鍵字 + LLM 雙層判斷。簡單的修正（「不對」）零成本秒判斷，複雜的修正（「其實我是想說⋯」）由 LLM 輔助判斷，兼顧速度和準確性。
• 保留原回答 + 下方追加。使用者按 👎 重新生成時，保留原回答讓使用者可以比較。新回答從下方串流，不會讓使用者覺得原本的回答消失了。
• 全域更新集合。更新日誌只寫入一次 Firestore，所有使用者共用，不需要為每個使用者複製。

總結

這次升級讓 CareerWise 從「被動儲存」變成「主動學習」。

• P1 偏好學習讓 CareerWise 根據使用者的回饋調整回應風格
• P2 回饋機制給使用者表達滿意或不滿意的管道，並即時修正
• P3 修正學習讓 CareerWise 能理解「不對」「不是這樣」這類修正指令
• P4 版本日誌讓使用者知道 CareerWise 什麼時候變了、為什麼變

線上學習的關鍵在於即時性——使用者給出回饋後，下次對話就該有感，而不是等下次系統更新。這套機制讓 CareerWise 愈用愈懂使用者，而不是每次都從陌生人開始。