# 顧問方法論（Methodology）

> 狀態：待建立 ｜ 最後更新：2026-04-11

這個資料夾存放職涯停看聽的核心顧問知識與方法。

## 待建立的文件

- [x] `resume-diagnosis-framework.md` — 履歷診斷流程與評分標準
- [x] `consultation-framework.md` — 諮詢對話框架（開場、探索、建議、結尾）
- [x] `career-problem-patterns.md` — 常見職涯問題類型與對應解法
- [x] `lecture-product-review-guidelines.md` — 講座簡報審查指引（2026-04-13）
- [ ] `client-case-template.md` — 客戶案例結構化記錄格式（去識別化）

## 新增文件規則
1. 文件頂部標記：狀態（草稿/有效/已棄用）+ 最後更新日期
2. 新增後更新 `knowledge/CLAUDE.md` 的文件索引

# 常見職涯問題類型與對應解法

> 狀態：有效 ｜ 最後更新：2026-04-11
> 目標讀者：3-10 年工作經驗、面臨職涯卡關的職場人士

---

## 一、問題分類總覽

職涯卡關通常來自六大根本原因：

| 類型代號 | 問題類型 | 核心癥結 |
|---------|---------|---------|
| P1 | 履歷無效率 | 履歷沒有發揮應有的篩選力 |
| P2 | 方向不清晰 | 不知道自己要什麼、適合什麼 |
| P3 | 面試表現差 | 知道自己要什麼，但說不出來 |
| P4 | 薪資不到位 | 市場定位模糊，談判能力弱 |
| P5 | 職場困境 | 人際、主管、組織問題 |
| P6 | 轉職焦慮 | 想換但不知如何準備 |

---

## 二、P1：履歷無效率

### 症狀識別
- 投了 20+ 封無回音
- 有回音但很少（回應率 <5%）
- 面試後沒有下一輪機會

### 常見根本原因

| 原因 | 占比（估計）| 診斷方式 |
|------|-----------|---------|
| 內容問題（職責描述為主，缺乏成果）| ~40% | 五維診斷 |
| 相關性問題（不夠對齊 JD）| ~30% | 對照 JD 逐條比對 |
| 定位問題（看不出你是誰）| ~20% | 請旁人 6 秒後說出你的定位 |
| 格式問題（ATS 或視覺問題）| ~10% | 工具掃描 + 人眼測試 |

### 解法路徑
1. 五維診斷 → 找出最低分維度
2. 優先修最弱的那一個（不要同時改所有）
3. 修完後重新投 10-15 封 → 觀察回應率變化

---

## 三、P2：方向不清晰

### 症狀識別
- 「我不知道自己想做什麼」
- 「我什麼都願意嘗試」
- 每次被問到職涯目標，感到茫然或焦慮

### 探索工具

**工具 1：職涯三角形**
```
        興趣（我喜歡做什麼）
       /        \
      /          \
能力（我擅長做什麼）── 市場（別人願意付錢的）
```
> 交集點 = 值得探索的職涯方向

**工具 2：成就事件盤點**
- 列出 5 個職涯中有成就感的時刻
- 找出共同模式（什麼類型的工作讓你有能量？）

**工具 3：反向排除法**
- 先問「你絕對不想做的事是什麼？」
- 從排除中找到邊界，縮小範圍

### 解法路徑
1. 進行成就事件盤點（自行或與顧問一起）
2. 畫職涯三角形，找交集
3. 縮小到 2-3 個方向，評估可行性
4. 選一個試探，不需要一次決定終身方向

---

## 四、P3：面試表現差

### 症狀識別
- 進了面試，但沒有 Offer
- 面試後被說「表達不清楚」
- 自己知道有能力，但說不出來

### 常見問題

| 問題 | 表現 | 改善方向 |
|------|------|---------|
| 回答太抽象 | 「我很負責、很積極...」| STAR 法則具體化 |
| 沒有結構 | 講了很長，但對方沒聽懂 | 先說結論，再說過程 |
| 太謙虛 | 「這也不是我一個人的功勞」| 說出你的具體貢獻 |
| 沒準備問題 | 「我沒有問題了」| 準備 3 個有深度的問題 |

### STAR 法則
- **S**ituation：背景是什麼？
- **T**ask：你的任務是什麼？
- **A**ction：你具體做了什麼？
- **R**esult：結果如何？（數字最好）

### 解法路徑
1. 整理 10 個「最有代表性的工作故事」，用 STAR 法則結構化
2. 大聲練習（錄音、照鏡子、找人 mock）
3. 每次面試後覆盤：哪題回答得好？哪題需要改？

---

## 五、P4：薪資不到位

### 症狀識別
- 感覺自己的薪水比同業低
- 每次加薪幅度很小（<5%）
- 不知道如何在新工作談到心目中的數字

### 薪資談判框架

**步驟一：市場定價**
- 查詢管道：104 薪資大調查、Glassdoor、同業詢問
- 目標：了解同職位、同年資的市場區間

**步驟二：定錨策略**
- 先出價者有利（對方問薪資期望，報出你的目標）
- 報「略高於目標」的數字（留談判空間）
- 範例：目標 55K → 報 58-62K

**步驟三：理由堆疊**
- 用「市場行情 + 個人貢獻 + 特殊技能」三層理由
- 避免用「我需要更多錢」這種個人理由

**步驟四：不接受第一個 Offer**
- 幾乎所有 Offer 都有談判空間
- 至少嘗試談一次：「這個機會對我很有吸引力，但薪資的部分可以再討論嗎？」

---

## 六、P5：職場困境

### 常見子類型

| 困境類型 | 核心問題 | 優先探索方向 |
|---------|---------|------------|
| 主管問題 | 溝通/信任/風格衝突 | 是問題可解決，還是文化不合？ |
| 同事問題 | 合作障礙、職場政治 | 是個案還是系統性問題？ |
| 職涯天花板 | 看不到晉升空間 | 內部轉調 vs 外部跳槽 |
| 工作倦怠 | 失去動力、情緒耗盡 | 是工作問題還是生活問題？ |

### 解法原則
- 先釐清「這是可以改變的，還是環境固有的？」
- 可以改變的 → 找具體改善策略
- 不能改變的 → 評估是否值得繼續待，還是要換環境

---

## 七、P6：轉職焦慮

### 症狀識別
- 「我想換，但怕薪水降」
- 「我想換，但不知道自己適合什麼」
- 「我想換，但怕選錯了更慘」

### 焦慮來源分析

| 焦慮類型 | 本質 | 解法 |
|---------|------|------|
| 資訊焦慮 | 不知道目標行業/職位的真實樣貌 | 資訊蒐集（訪談、打聽）|
| 能力焦慮 | 擔心進去之後不夠格 | 技能缺口分析 + 補足計畫 |
| 財務焦慮 | 怕薪水縮水撐不住 | 計算最低財務需求、評估風險期 |
| 決策焦慮 | 怕選錯了後悔 | 分析最壞情況，通常沒那麼糟 |

### 轉職準備三步驟
1. **確認目標**：縮小到 1-2 個方向（用 P2 工具）
2. **評估缺口**：我現在有什麼？目標需要什麼？差距在哪？
3. **制定計畫**：先準備，不要裸辭。邊工作邊準備投遞。

# 諮詢對話框架

> 狀態：有效 ｜ 最後更新：2026-04-11
> 作者：蒲朝棟 Tim（CDA 認證職涯顧問、104 職涯引導師）

---

## 一、諮詢的核心原則

**顧問的角色是引導，不是給答案。**

求職者知道自己的故事，顧問的工作是幫他看到他自己看不到的模式，並協助他找到下一步的行動方向。

**三不原則：**
- 不替客戶做決定（引導他自己看清楚）
- 不批判客戶的選擇（探索動機，不評價對錯）
- 不保證結果（說明機率，不承諾成功）

---

## 二、諮詢四階段流程

### 階段一：開場與關係建立（10-15 分鐘）

**目的：** 建立信任，了解客戶帶著什麼問題來。

**關鍵問題：**
- 「今天你最想解決的一件事是什麼？」
- 「如果我們今天談完，你希望帶走什麼？」

**注意：**
- 讓客戶先說，顧問少說
- 確認諮詢目標，避免談話漫無邊際
- 如果客戶說「我也不知道」→ 用「那你現在最困擾的是什麼？」引導

---

### 階段二：現況探索（20-30 分鐘）

**目的：** 深入了解客戶的工作背景、職涯歷史、核心能力與真實困境。

**探索維度：**

| 維度 | 探索問題 |
|------|---------|
| 工作歷史 | 「你做過最有成就感的一件事是什麼？」|
| 核心能力 | 「別人常找你幫忙的事是什麼？」|
| 價值觀 | 「什麼樣的工作環境讓你最有動力？」|
| 困境根源 | 「你覺得卡住的真正原因是什麼？」|
| 目標清晰度 | 「如果有完全的自由，你想做什麼？」|

**常見模式識別：**
- 「我只是想換工作」→ 通常有更深的動機（待遇、主管、職涯天花板）
- 「我不知道自己想做什麼」→ 通常已有方向，但缺乏信心
- 「我的履歷沒有問題」→ 問題通常不只是履歷

---

### 階段三：建議與行動規劃（20-25 分鐘）

**目的：** 根據探索結果，提供具體的改善方向與行動步驟。

**建議框架：**
1. **反映觀察**：「我注意到一件事...」（先說你看到的，不下判斷）
2. **提出方向**：「有一個可能性是...」（提供選項，不強推一種答案）
3. **具體行動**：「下一步你可以做的第一件事是...」（越具體越好）

**常見諮詢場景與建議方向：**

| 場景 | 建議方向 |
|------|---------|
| 履歷無回音 | 五維診斷 → 找出最弱的一個維度先改 |
| 不知道要轉去哪 | 職涯興趣 × 市場需求 × 可遷移技能的交叉分析 |
| 面試被刷掉 | 還原面試過程，找出具體被刷點 |
| 不知道值多少錢 | 市場薪資查詢 + 談判話術準備 |
| 職場人際問題 | 先釐清是「關係問題」還是「溝通問題」，再對症處理 |

---

### 階段四：結尾與後續（5-10 分鐘）

**目的：** 確認客戶帶走具體的行動承諾，設定下一步。

**結尾三問：**
1. 「今天最有收穫的是什麼？」（讓客戶自己說出）
2. 「你決定接下來要做的第一件事是什麼？」（行動承諾）
3. 「你預計什麼時候完成這件事？」（時間錨點）

**後續追蹤（如適合）：**
- 2 週後詢問進度（LINE 一則）
- 鼓勵客戶回饋成果，有助於轉介紹

---

## 三、不同諮詢類型的重點調整

### RES 履歷健診
- 重點在「診斷 + 修改方向」
- 使用五維診斷框架
- 結束時要有具體的 3-5 個修改建議

### CAR 職涯規劃
- 重點在「探索 + 可能性」
- 時間分配：探索 40% + 規劃 40% + 行動 20%
- 避免給太多選項，最後聚焦到 1-2 個方向

### INT 面試準備
- 重點在「還原 + 練習」
- 讓客戶模擬回答，顧問給具體回饋
- STAR 法則（情境、任務、行動、結果）

### CHG 轉職評估
- 重點在「風險評估 + 決策支持」
- 不替客戶做決定，但要幫他看到決定的影響
- 常見問題：財務缺口、技能缺口、時間規劃

---

## 四、諮詢品質自評表（諮詢後填寫）

| 項目 | 評分（1-5）| 備註 |
|------|-----------|------|
| 是否掌握客戶真實問題？ | | |
| 建議是否具體可執行？ | | |
| 客戶是否帶著行動方向離開？ | | |
| 時間控制是否恰當？ | | |
| 整體諮詢流暢度 | | |

# 講座簡報審查指引

> 適用範圍：職涯停看聽旗下所有講座型產品（就業講座、工作坊、企業內訓）
> 建立日期：2026-04-13（v1.0 審查）；更新：2026-04-14（v1.1 審查補充）
> 來源：就業講座「你的履歷沒問題是語言問題」v1.0 + v1.1 完整審查報告
> 維護人：Tim（內容決策）/ Claude（執行與格式）

---

## 一、審查前準備：七個強制確認點

任何講座簡報**上台前必須逐一確認**，有一項未過就不得使用：

| 項目 | 確認內容 | 常見失誤 |
|------|---------|---------|
| 佔位符清理 | 所有「X%」「＿＿」「待確認」已填入真實數字或說明 | 案例中的數字比例未更新 |
| Emoji 風險 | 所有 Emoji（💬💡❓等）在正式投影設備顯示正常；若無法確認，**改為純文字方案**（【互動】【提示】等） | cp950/LibreOffice 環境 emoji 亂碼或空白 |
| 中文字型嵌入 | 所有文字方塊的字型確認為 CJK 相容字型（微軟正黑體 / Noto Sans TC）；**避免對中文文字使用 Calibri 等純拉丁字型** | Calibri 在 LibreOffice 渲染時中文文字全數消失 |
| 文字框溢出 | 每次新增文字後確認文字框高度足夠，無截斷；特別注意「auto_size=None」的固定高度文字框 | 新增內容溢出底部，後排觀眾看不完整 |
| 連結可用性 | 所有 URL 在手機與桌機均可開啟 | 工具上線後 URL 變更未同步 |
| 定價確認 | 所有諮詢費用為最新版本 | 調漲後投影片未更新 |
| 備用投影片隱藏 | Q&A 備用頁設為隱藏投影片（PowerPoint: 右鍵→隱藏投影片） | 正常播放中意外顯示備用頁 |

---

## 二、內容品質四層審查框架

### 層 1：正確性
- 所有案例數字是否有來源依據？
- 引用的資料、統計、HR 說法是否可驗證？
- 工具/平台名稱是否為最新現用名稱？

### 層 2：時效性
- HR 篩選行為描述是否反映當前市場（不超過 2 年）？
- 求職工具推薦是否仍存在且運作中？
- 薪資數字或產業現狀是否需要更新？

### 層 3：完整性（說服鏈）
每份講座都必須有完整的「問題→原因→解決方案→行動」說服鏈：

```
受眾的痛點（共鳴）
      ↓
問題的真正根因（框架重塑）
      ↓
解決方案（工具/公式/方法）
      ↓
可立即執行的行動（CTA）
```

**常見說服鏈缺口**：
- 只給痛點但未給解法底線（例：說「估算數字」但未給範例句）
- 只給公式但未給「什麼都沒有的人」的最低門檻示範
- 章節彼此獨立，未與講座核心主軸形成連貫敘事

### 層 4：差異化
- 受眾看完後能不能一句話描述「這個講師的獨特角度是什麼」？
- 是否提供市面上少有的具體話術（而非原則描述）？
- 最適合拍照分享的頁面是哪頁？是否已強化它的傳播潛力？

---

## 三、章節主軸一致性原則

> 每個章節必須與講座的核心主張明確掛鉤，不能讓受眾感覺「這章和主題無關」。

**標準做法**：每個章節頁（標題投影片）加一句「這也是語言問題的一部分，因為……」

**就業講座案例**：
- 第一章（為什麼沒回音）→ 主軸本身，不需額外說明
- 第二章（怎麼翻譯經歷）→ 主軸本身，不需額外說明
- 第三章（面試緊張）→ **需要加**：「面試緊張，其實也是一種語言問題。」
- 第四章（第一份工作怎麼選）→ **需要加**：「選工作，也是選一個讓你快速累積職場語言的環境。」

---

## 四、互動設計標準

### 互動密度
- 每章至少 1 個互動點（舉手、寫下來、30 秒練習）
- 互動指令必須在投影片上可見，不依賴講師口頭說明

### 互動品質
| 類型 | 目的 | 注意 |
|------|------|------|
| 舉手問題 | 建立共鳴、掃描場內 | 問題必須讓大多數人都能舉手 |
| 限時書寫（30-60 秒）| 讓受眾主動思考 | 時間要說清楚，倒數計時可見 |
| 分享邀請 | 讓內容進入現實情境 | 備好即時點評的話術 |
| 猜測互動（先問再揭曉）| 建立懸念 | 揭曉前等待 2-3 秒 |

---

## 五、CTA 設計原則

> CTA（行動呼籲）是講座的商業轉換關鍵，設計不良將直接影響後續業績。

### 三項 CTA 黃金標準

1. **即時行動型**（最重要）：受眾現在就可以做的事
   - 好：「現在打開手機掃 QR Code，30 秒診斷你的履歷」
   - 差：「有空可以去看看我們的工具」

2. **價值明確型**：加入/訂閱後受眾會得到什麼
   - 好：「加入 LINE，每週一則求職語言技巧」
   - 差：「加入 LINE，持續更新求職資源」（太模糊）

3. **降低門檻型**：消除加入前的不確定感
   - 說明頻率、說明類型、說明不會騷擾
   - 好：「每週只發一則，絕不群發廣告」

### CTA 層次設計
```
① 免費即時行動（最多人轉換）—— 工具/診斷/名單登記
② 低門檻付費嘗試 —— NT$600 以下、30 分鐘以內
③ 持續關係建立 —— LINE/電子報/社群追蹤
```
---

## 六、備用 Q&A 投影片管理

### 必須涵蓋的六類問題
| 類型 | 範例問題 | 適合台詞開頭 |
|------|---------|------------|
| 科系/背景 | 沒有相關科系可以投嗎？ | 「這是最多人問的問題之一……」|
| 履歷薄弱 | 實習很少，履歷很空怎麼辦？ | 「沒有實習不代表沒有故事……」|
| 公司選擇 | 要不要投小公司？ | 「這取決於你的優先順序……」|
| 薪資談判 | 被問期望薪資怎麼回答？ | 「先說範圍，不說單一數字……」|
| 心態維持 | 一直被拒絕怎麼調整心態？ | 「拒絕不是對你這個人的否定……」|
| 負面問題 | 面試官問弱點/失敗經驗怎麼回答？ | 「這道題有固定結構……」|

### 備用投影片技術規定
- **必須設為隱藏投影片**（PowerPoint：右鍵投影片→「隱藏投影片」）
- 正常播放不出現，需要時按 G 跳頁輸入投影片編號
- 備用投影片視覺設計可簡化（灰色背景+清楚標記「備用」）

---

## 七、話術示範頁設計原則

> 話術示範是最容易形成口碑傳播的頁面——受眾拍照帶走的機率最高。

### 設計要求
1. **填空框架（___）**：讓受眾能直接套用自己的情況
2. **短句優先**：每句話術不超過 40 字，確保說出來自然
3. **情境標示清楚**：幫受眾知道「這句話在什麼情況下用」
4. **視覺強調**：話術框用深色邊框或底色標示，與說明文字有明顯區別

### 範例（三個心理卡點話術，來源：S28 v1.1）
```
❶ 沒有亮眼成就：
「這段經驗規模雖小，但讓我學到了___，
 正好對應這個職位需要___的能力。」

❷ 換過很多工作：
「每次轉換都有明確原因——我在找___，
 這讓我對這個職位更加確定。」

❸ 有空白期：
「那段空白我用來___，
 讓我確認自己真正想要的方向是___。」
```

---

## 八、投影片版本管理規則

| 版本 | 觸發條件 | 更新範圍 |
|------|---------|---------|
| v1.0 | 首次完成，可上台使用 | 全部 |
| v1.x（小版本）| 內容補強、話術新增、CTA 修改 | 局部頁面 |
| v2.0 | 重大架構調整、受眾定位轉換 | 全部 |

**版本文件同步規則**：
- PPTX 檔案重新命名（v1.0 → v1.1）
- `lecture-xxx-slides.md` 更新對應章節內容
- `調整記錄` 表格補充本次修改說明

---

## 九、上台前最後確認清單（15 分鐘）

```
□ 用正式投影設備測試全場播放一次
□ 確認 emoji 顯示正常
□ 確認連結可開啟（手機掃 QR Code 測試）
□ 確認備用投影片不在正常播放流程中
□ 備妥白板筆/計時器（若現場互動需要）
□ 確認講師備忘都看過一遍
□ 確認最後一張投影片（S36）是 CTA 頁，而非意外停在其他頁
```

---

## 十、常見錯誤 → 修正對照表

| 錯誤描述 | 影響 | 修正方向 |
|---------|------|---------|
| 章節與核心主軸連結鬆散 | 受眾覺得講座發散 | 每章標題頁加一句主軸連結語 |
| 「估算數字」只說方法不給範例 | 受眾不知道怎麼用 | 加「0 實習完整示範句」 |
| 話術頁只說原則不給話術 | 受眾覺得聽了沒用 | 改為直接給填空話術框架 |
| LINE CTA 說「持續更新」太模糊 | 掃碼率偏低 | 改為「每週一則＋具體類型」 |
| 備用頁在正常播放中出現 | 打斷講座節奏，降低專業感 | 設為隱藏投影片 |
| 案例中 X% 未換成真實數字 | 降低可信度 | 換真實數字或說明估算邏輯 |
| 案例全是資深職場人士 | 應屆生代入感有限 | 下一版補充大四學生翻譯案例 |
| 文字內容溢出文字框底部 | 後排觀眾看不到完整內容 | 增加文字框高度或縮小字級至 13pt |
| 中文文字套用 Calibri 字型 | LibreOffice 渲染時文字全數亂碼 | 改為微軟正黑體或 Noto Sans TC |
| 無依據數字（80%、快3年等） | 受眾追問時無法回應 | 改為描述性說法（「大多數」「可能快好幾年」）|
| 行業術語首次出現無說明 | 部分受眾（大一/高中生）不理解 | 加括號說明，如 JD（職缺說明） |
| 章節後無落地行動步驟 | 受眾離場後不知道要做什麼 | 加「你這週的行動」頁，具體到今天就能做 |

---

## 附錄：就業講座 v1.0 → v1.1 修改紀錄

| 投影片 | 修改內容 | 修改原因 |
|-------|---------|---------|
| S12 | 底部新增定位 vs 語言問題導覽提示 | 受眾最常見的未解疑問：「我是定位問題還是語言問題？」 |
| S15 | 第一章小結末加導覽句 | 強化定位/語言區分，幫助受眾知道下一步 |
| S19 | 新增「0 實習完整示範句」 | P19 有估算方法但缺乏底線示範，受眾沒有具體範本 |
| S26 | 章節頁加語言問題連結句 | 第三章（面試緊張）與核心主軸連結較鬆散 |
| S28 | 深化三個心理卡點為話術示範 | 原版只有原則未給話術，受眾最容易拍照分享的頁面 |
| S31 | 章節頁加語言問題連結句 | 第四章（第一份工作怎麼選）與核心主軸連結較鬆散 |
| S35 | 新增弱點/失敗備用問題 + 設隱藏 | 面試問弱點是高頻問題，備用庫應涵蓋 |
| S36 | LINE CTA 加入具體說明 | 「持續更新求職資源」太模糊，改為「每週一則求職語言技巧」 |

# 履歷診斷框架

> 狀態：有效 ｜ 最後更新：2026-04-11
> 作者：蒲朝棟 Tim（CDA 認證職涯顧問）

---

## 一、履歷的本質定義

**履歷是翻譯文件，不是自傳。**

求職者的工作經歷是「原文」，履歷是翻譯成「雇主語言」的版本。
最常見的問題不是「做的事情不夠好」，而是「翻譯不到位」。

---

## 二、五維診斷框架

### 維度一：定位清晰度
**核心問題：看完你的履歷，對方知道你是誰嗎？**

| 評分 | 描述 |
|------|------|
| 高 | 一眼看出目標職位、核心能力、個人定位 |
| 中 | 大致看得出方向，但有雜訊干擾 |
| 低 | 看完不知道你想做什麼，或你適合什麼 |

**常見問題：**
- 求職目標太模糊（「對各類職位開放」）
- 放了太多無關經歷試圖「展現多元」
- 標題與內容不一致（自稱行銷，但沒有行銷成果）

---

### 維度二：成果具體性
**核心問題：你說的話，有沒有數字或案例支撐？**

| 評分 | 描述 |
|------|------|
| 高 | 80% 以上的條目有量化數字或具體成果 |
| 中 | 部分有數字，部分仍是職責描述 |
| 低 | 幾乎都是職責描述（「負責 XX」「協助 XX」）|

**黃金公式：**
> 用 [行動動詞] + [方法/工具] + [量化結果]
> 例：「導入 A/B 測試機制，使電子報開封率從 18% 提升至 27%（+50%）」

**常見問題：**
- 「負責」「協助」等被動詞彙過多
- 數字缺失（「提升了業績」但沒有說提升多少）
- 只寫職責，沒寫貢獻

---

### 維度三：相關性匹配度
**核心問題：你的經歷是否對齊目標職位的需求？**

| 評分 | 描述 |
|------|------|
| 高 | 主要條目直接對應 JD 關鍵詞，相關性 >80% |
| 中 | 有相關性，但需要雇主自己連結 |
| 低 | 經歷與目標職位關聯性低，需要大幅調整 |

**診斷方法：**
1. 找到目標 JD，列出前 5 個核心技能需求
2. 比對履歷，每個需求是否有對應的條目？
3. 相關條目是否放在最顯眼的位置？

---

### 維度四：視覺可讀性
**核心問題：人資 6 秒掃描，能抓到關鍵資訊嗎？**

| 評分 | 描述 |
|------|------|
| 高 | 結構清晰、留白充足、關鍵詞一眼可見 |
| 中 | 可讀但稍顯擁擠，或排版有小問題 |
| 低 | 密密麻麻、字級混亂、不知從何看起 |

**常見問題：**
- 每個工作經歷放超過 6 個條目
- 字體大小超過 3 種
- 沒有合理的段落間距

---

### 維度五：敘事一致性
**核心問題：你的職涯故事說得通嗎？**

| 評分 | 描述 |
|------|------|
| 高 | 經歷有明顯的成長脈絡，轉折有說服力 |
| 中 | 大致說得通，但有跳躍或空白需要解釋 |
| 低 | 跨度太大、空白太多、讓人看不懂邏輯 |

**重點：**
- 跨領域轉職者的挑戰最大（需要強調「可遷移技能」）
- 短暫工作（<1 年）需要主動說明，否則被質疑

---

## 三、診斷評分計算

| 維度 | 滿分 | 你的分數 | 備註 |
|------|------|---------|------|
| 定位清晰度 | 20 | | |
| 成果具體性 | 25 | | |
| 相關性匹配度 | 25 | | |
| 視覺可讀性 | 15 | | |
| 敘事一致性 | 15 | | |
| **總分** | **100** | | |

**評分區間：**
- 85-100：優秀，微調即可投遞
- 70-84：良好，針對 1-2 個弱點改善
- 55-69：需要結構性修改
- <55：建議大幅重寫

---

## 四、常見職涯問題類型與履歷對應策略

| 問題類型 | 履歷挑戰 | 對應策略 |
|---------|---------|---------|
| 轉職（跨產業）| 相關性低 | 強調可遷移技能，用 Skills 區塊置頂 |
| 轉職（跨職能）| 成果不相關 | 重新框架過去成果，連結目標職位語言 |
| 升職（同公司）| 無法體現 | 用「晉升」作為成果，說明升遷原因 |
| 空窗期 | 敘事缺口 | 主動說明，並說明期間的學習或貢獻 |
| 年資不足 | 經歷淺薄 | 放大專案、社群、學習成果 |
| 年資過深 | 職位要求不符 | 精簡版本，對應職位調整 |

---

## 五、AI 診斷工具的對應關係

> 本框架已部分實作於診斷系統（SYS-03）的 AI 提示詞中。

AI 診斷完整評估五個維度：定位清晰度（20%）、成果具體性（25%）、相關性匹配度（25%）、視覺可讀性（15%）、敘事一致性（15%）。
框架與本文件完全對齊（2026-04-11 更新）。

# 六大顧問框架（完整版）

> 狀態：有效 ｜ 最後更新：2026-04-15
> 來源：職涯顧問核心方法論手冊.docx（本機知識庫）
> 作者：蒲朝棟 Tim（CDA 認證職涯顧問）

---

## 框架總覽

以下六個框架構成完整的職涯顧問工作流程，**並非獨立模組，而是依序遞進、彼此整合的系統。**

| 框架 | 名稱 | 一句話定義 |
|------|------|---------|
| 框架一 | 心理障礙前置診斷法 | 在給任何技術建議之前，先診斷並解除客戶的心理阻礙 |
| 框架二 | 職能轉譯矩陣 | 將客戶的真實能力，翻譯成目標產業能理解且在意的語言 |
| 框架三 | STAR 深度重構法 | 用可驗證的行為事例取代主觀形容詞，重建履歷說服力 |
| 框架四 | 職涯敘事重構法 | 將不利的職涯事實，轉換為有主導感的真實敘事 |
| 框架五 | 財務逆推職涯定位法 | 用目標收入逆推職涯路徑的商業結構可行性 |
| 框架六 | 多路徑職涯策略藍圖 | 整合前五框架輸出，形成可執行的長期策略地圖 |

### 框架整合順序

- **框架一幾乎永遠是入口**：未解除心理障礙，技術建議幾乎不會被執行
- **框架二與框架三並行**：前者解決「說什麼」，後者解決「怎麼說」
- **框架四是條件性工具**：當個案存在不利事實時啟用，不是每個案例都需要
- **框架五適合方向迷茫或需要說服客戶轉型**：提供邏輯說服力
- **框架六是最終整合輸出**：在其他框架完成診斷與分析後才進行

### 優先級衝突處理原則

當客戶同時需要多個框架、但諮詢時間有限時（例如三天後有面試），以**「讓客戶帶著具體準備和自信離開諮詢現場」為最高優先**——先執行框架三（STAR 演練）和框架四（敘事重構），心理工作可在面試後繼續。框架五不適合在客戶財務高壓、急需工作的初期諮詢中作為主框架。

---

## 框架一：心理障礙前置診斷法

**Pre-Coaching Psychological Triage**

### 適用情境

客戶表面上帶著「技術性問題」來（履歷寫不好、面試失敗、不知道要轉哪個方向），但行動障礙的根源是心理層面，而非能力層面。

**典型個案特徵：**
- 有能力卻遲遲不投履歷，不斷說「再準備一下」
- 對自己的過往成就習慣性貶低（「我那個很普通，不算什麼」）
- 把外在事件（被辭退、空窗期）內化為「我不行」的自我評價
- 每次諮詢都有強烈認同，但回去後從不執行任何行動
- 目標頻繁更換，每次諮詢說的方向都不同（本質是逃避決定，而非真的轉向）

### 可觀察的三類心理障礙信號

在諮詢開場的 10-15 分鐘內主動觀察：

**語言信號：**
- 高頻使用「但是」來否定自己的優點
- 習慣用絕對化語言（「我一定不行」、「根本沒公司要我」）
- 對某類問題突然語焉不詳或迅速跳開（迴避區往往是核心阻礙所在）

**行為信號：**
- 知道要做卻持續拖延，超過兩週沒有任何實際行動
- 過度準備但不出手（履歷改了十幾版，從未投出去）

**認知信號：**
- 把「困難」等同於「不可能」
- 把「一次失敗」類推為「永遠如此」（過度類化）
- 對成功案例的反應是「那是別人，我不一樣」（防禦性否定）

### 執行步驟（共五步）

1. **表面問題接收，暫緩技術介入**（10-15 分鐘）：完整聽完，記錄語言信號
2. **區分「技術問題」與「心理障礙」**：技術問題可直接用方法解決；心理障礙需先處理
3. **透過提問，讓客戶自己命名障礙**（不替客戶下診斷）
4. **重構障礙的「成因邏輯」，而非直接否定它**：「你這樣的反應其實非常合理，因為……」
5. **確認心理解除後，才進入技術框架**：轉換信號 = 從「我不行」轉為對具體方法的好奇

### 重要限制

顧問不是心理諮商師。若客戶呈現的是達到影響日常功能的焦慮症、憂鬱狀態或明顯低自尊障礙，應告知服務範疇並建議尋求心理健康專業協助。

---

## 框架二：職能轉譯矩陣

**Transferable Skills Translation Matrix**

### 適用情境

客戶擁有真實能力，但所在產業的語言與目標產業嚴重錯位，導致履歷和面試無法被對方理解。幾乎所有轉職個案都需要某種程度的職能轉譯。

### 核心原則：轉譯有真實性邊界

職能轉譯必須基於客戶真實具備的底層能力，不是語言遊戲。**確認標準：「如果面試官深問，你能舉出具體事例嗎？」通過者才轉譯；通不過者，誠實告知這是能力缺口，需要補課。**

### 語言落差地圖範例

| 原產業語言（客戶慣用） | 目標產業語言（需翻譯成） |
|---------------------|---------------------|
| 訴訟標的金額管理 | 損失風險控管（Loss Prevention） |
| 書狀撰寫、判決預測 | 法律風險量化、商業決策支援 |
| 評估患者需求、處方建議 | 需求診斷（Needs Assessment）、B2B 顧問式銷售 |
| SOP 遵循、軍令執行 | 合規執行（Compliance）、流程標準化 |
| 高壓服務、投訴處理 | 情緒安撫、客戶關係管理（CRM） |
| 實驗數據紀錄、變異分析 | 品質文件撰寫、FMEA 概念應用 |

### 執行步驟（共五步）

1. **建立底層能力清單**：拆解工作到最小單位，問「這份工作最難的部分是什麼？」
2. **繪製語言落差地圖**：並排原產業語言 vs. 目標產業語言
3. **量化轉譯**：將能力轉譯為「對對方組織有意義的數字或結果」
4. **建立翻譯詞彙表**：整理目標 JD 前 10-15 個關鍵詞，逐一找對應事例
5. **10 秒測試（招募方視角審查）**：「我能立刻理解這個人能為我解決什麼問題嗎？」

---

## 框架三：STAR 深度重構法

**STAR Deep Reconstruction Method**

### 目的

用**可驗證的行為事例**取代主觀形容詞，強制客戶從「我做了什麼」轉向「我帶來了什麼結果、承擔了什麼責任」。

### STAR-D 結構（原創延伸版，含第五層）

- **S**ituation：背景與情境（製造張力，不只是說明背景）
- **T**ask：任務與責任範圍（用 Spearheaded / Orchestrated 等動詞強調主導性）
- **A**ction：具體行動（主導性動詞，避免被動語態）
- **R**esult：可量化的結果（連結對組織的損失/價值，不只是百分比數字）
- **D**eep Reflection（原創第五層）：對這段經歷的洞察與可塑性展現，體現學習能力

### 主導性動詞範例

取代被動陳述：Spearheaded、Orchestrated、Led、Reduced、Generated

### 量化提問工具

- 「這件事如果你沒做好，公司會損失多少？」
- 「你的介入讓風險降低了多少比例？」
- 「你省下了多少外部服務費用？」
- 「和之前的做法相比，新做法快了多少、省了多少、準了多少？」

---

## 框架四：職涯敘事重構法

**Narrative Reframing**

### 目的

將不利的職涯事實（被辭退、空窗期、提早離職、非線性職涯）轉換為有主導感的真實敘事。

**原則：重構不是造假，是幫客戶找到同一件事的「對雇主有利的詮釋角度」，同時保持敘事邏輯一致性與可驗證性。**

### 重構範例

| 不利事實 | 重構敘事 |
|---------|---------|
| 被辭退 | 主動暫停職涯（Career Break），用於方向重整 |
| 空窗期赴海外 | 跨文化適應力提升與身心重整 |
| 提早退伍 | 經審慎評估的主動轉換 |
| 非線性職涯 | 跨領域底層能力組合，構成差異化背景 |

### 執行要點

- 先幫客戶命名心理障礙，讓他理解「為什麼這樣感覺是合理的」
- 再引導他找到「同一件事的不同詮釋角度」
- 確認新敘事能通過「如果深問，你能說清楚嗎？」的測試

---

## 框架五：財務逆推職涯定位法

**Revenue-Back Career Positioning**

### 適用情境

- 客戶方向迷茫，需要用商業邏輯說服自己或說服顧問
- 斜槓規劃：「喜歡的事能不能養活自己」
- 評估多條職涯路徑的商業可行性

### 核心邏輯

**從目標年收入逆推 → 所需業績規模 → 商業模式結構**

例如：年收 300 萬
- 一對一時間銷售：需每月 XX 小時，時間上限在哪？
- 小班制/課程：需多少人 × 多少費用 × 多少場次？
- 顧問 + 產品混合：哪條路結構上走得通？

### 使用限制

- 不適合在客戶**財務高壓、急需工作**的初期諮詢中作為主框架（先穩定現金流）
- 不適合方向完全未定的客戶（先完成框架一、二，確認方向後再用）

---

## 框架六：多路徑職涯策略藍圖

**Multi-Path Career Strategy Map**

### 目的

整合前五框架的輸出，提供**含條件分支的可執行長期策略地圖**。不只是「告訴客戶要做什麼」，而是讓客戶根據自己的風險承受度做選擇。

### 藍圖組成要素

- **三條差異化路徑分析**（含各路徑的優劣與風險）
- **個人 OKR 初版**（第 1 個月、第 3 個月里程碑）
- **30 天立即行動清單**（具體可執行）
- **Plan A/B 風險應對**

### 何時啟動

其他框架完成診斷與分析後才進行。過早輸出藍圖 = 在不穩定的地基上蓋房子。

---

## 與現有 consultation-framework.md 的關係

`consultation-framework.md` 描述的是諮詢的**四階段流程**（開場→現況探索→建議→結尾）。

本文件描述的六大框架是諮詢**中間使用的分析工具**，兩者是不同層次：
- 四階段流程 = 時間軸（什麼時候做什麼）
- 六大框架 = 方法論工具箱（用什麼方法做）

---

*文件底部保留給後續補充：各框架的典型案例記錄、框架使用統計、失效警示記錄*

# 系統操作手冊（Operations）

> 狀態：待建立 ｜ 最後更新：2026-04-11

這個資料夾存放各系統的操作 SOP 與常見問題排查。

## 待建立的文件

- [ ] `deploy-vercel.md` — Vercel 部署流程（官網、診斷、儀表板）
- [ ] `deploy-render.md` — Render 部署流程（預約系統）
- [ ] `github-pat-management.md` — GitHub PAT 建立與更換 SOP
- [ ] `outreach-send-sop.md` — 外展發信完整操作流程
- [ ] `line-broadcast-sop.md` — LINE@ 廣播發送流程
- [ ] `troubleshooting.md` — 常見問題排查手冊

## 新增文件規則
1. 每個 SOP 必須包含：前置條件、逐步操作、預期結果、常見錯誤
2. 新增後更新 `knowledge/CLAUDE.md` 的文件索引

# 指令清單參考手冊
> 最後更新：2026-04-17 ｜ 狀態：有效

所有可以觸發行動的指令，分為兩類：對 Claude 說的 SKILL 指令，以及在 Claude Code CLI 輸入框打的 / 斜線指令。

---

## 一、SKILL 指令（在對話中說給 Claude）

對 Claude 說出以下關鍵字，Claude 會讀取對應的 `.claude/skills/` 檔案並執行完整流程。

| 指令 | 觸發行動 | 測試狀態 |
|------|---------|---------|
| `給我週報` | 全系統拉取 → 產出週報 → 存入 `reports/weekly/` | ✅ 已驗證 |
| `健康檢查` | 快速掃描所有系統健康狀態 → 輸出健康報告 | ✅ 已驗證 |
| `總管模式` | 全局分析 → 跨系統風險 → 建議行動順序 | ✅ 已驗證 |
| `盤點 [系統名稱]` | 深度單系統盤點（現況 + 問題 + 行動方案）| ✅ 已驗證 |
| `上線確認 [系統名稱]` | 三層確認清單 → ✅/❌ 明確結論 | ⏳ 待驗證 |
| `部署 [系統]` | Vercel/Render 部署流程 → 驗證 → 更新 inventory | ⏳ 待驗證 |
| `新增系統 [名稱]` | 五步驟系統加入流程，確認表全打勾才完成 | ⏳ 待驗證 |
| `任務追蹤` | 讀 tasks.md → 三類分類（推進中/卡關/久未更新）+ 建議下一步 | ✅ 已驗證 |
| `規則盤點` | 掃描所有 CLAUDE.md → 重複/失效/缺口三清單 | ✅ 已驗證 |
| `SKILL評估` | 工作流缺口分析 → 新 SKILL 草稿（含輸出規範）| ✅ 已驗證 |
| `改善追溯 [描述]` | 根本模式抽象化 → 往前掃描 → audit-log 記錄 | ✅ 已驗證 |
| `諮詢完成 [客戶代號]` | CRM 草稿 + 財務草稿 + 洞察提示問題 | ⏳ 待驗證 |
| `輪播貼文 [主題]` | 四維 Prompt 結構 → Threads 輪播草稿 → 存入 `content/drafts/` | ⏳ 待驗證 |
| `季度盤點` | 全局掃描 → 里程碑 → WAM 季均分析 → 下季決策 → 歸檔 | ⏳ 待驗證 |
| `收尾自查` | 6 Section 機械性核對：文件一致性/IMP掃描/audit-log時序/日誌完整/tasks/git | ⏳ 待驗證 |
| `系統驗證` | 瀏覽器 MCP 逐一驗證 8 系統功能 + 跨系統連結，輸出報告至 `reports/system-verify/` | ✅ 已驗證 |
| `診斷起草 [問卷答案]` | 問卷答案→P-type 診斷→完整報告草稿＋Tim 審查清單 | ⏳ 待驗證 |

### 使用說明
- `[系統名稱]` 填入：官網、看板、診斷、預約、LINE、外展、儀表板、知識庫
- `[客戶代號]` 填入：去識別化代號，如 C001、C002
- `[主題]` 填入：貼文主題關鍵字，如「薪資談判」「轉職時機」
- `[問卷答案]` 填入：Tim 從 Google Forms 收到的客戶填答內容（直接貼入對話）

---

## 二、Claude Code CLI 指令（在輸入框打 /）

在 Claude Code 的對話輸入框直接輸入，系統層級立即生效，不經過 Claude 判斷。

| 指令 | 觸發行動 | 建議時機 |
|------|---------|---------|
| `/compact` | 壓縮當前對話上下文，保留摘要 | 對話用量達 70-80% 時主動執行 |
| `/model` | 切換 AI 模型 | 複雜規劃 → Opus；一般任務 → Sonnet |
| `/init` | 分析專案所有檔案 → 自動生成 CLAUDE.md 草稿 | 新系統加入時，有現成程式碼的情況 |
| `/agents` | 建立具名持久 Agent（設工具/模型/顏色/記憶）| 需要專屬小幫手反覆執行特定類型任務時 |
| `/plugins` | 查看官方可安裝外掛目錄（Skills+Hooks+MCP 懶人包）| 評估是否有適合工作流的官方外掛 |
| `/mcp` | 查看目前已連線的 MCP 伺服器清單 | 確認 Chrome/Drive 等 MCP 工具狀態 |
| `/account` | 查看帳號目前用量與下次重設時間 | 感覺用量偏高時確認剩餘額度 |
| `/help` | 列出所有可用指令 | 忘記指令名稱時查詢 |

### 兩類指令的差異
- **SKILL 指令**：說給 Claude 聽，Claude 執行完整流程（讀檔 → 分析 → 產出報告 → 更新記錄）
- **CLI 指令**：在輸入框打 `/`，系統層級立即生效，不靠 Claude 判斷

---

## 三、維護規則
- 新增 SKILL 後，同步更新本文件的表格
- 測試狀態：初次設計完成標 ⏳，實際對話完整走過一次改 ✅
- 本文件路徑：`knowledge/operations/commands-reference.md`
- 對應 SKILL 規格：`.claude/skills/` 資料夾下各 `.md` 檔案

# 跨部門作業流程

> 狀態：有效 ｜ 最後更新：2026-04-11
> 負責部門：策略部（STR）

本文件定義職涯停看聽各類日常工作的跨部門協作路徑，避免錯誤判讀「誰負責什麼」。

---

## 流程一：內容發布（Threads 貼文）

```
內容部（CNT）          社群部（SOC）         開發部（DEV）
    |                      |                     |
規劃主題 →             排程發文 →            如需技術支援
更新 content-calendar   記錄數據               （看板功能修改）
                         ↓
                    每週追蹤互動數據
                         ↓
                    數據回饋給內容部
                    （哪些主題效果好）
```

**各部門動作：**
- 內容部：決定「寫什麼」，維護 content-calendar.md
- 社群部：決定「何時發」，執行發文，記錄 follower-history.json 數據
- 無需財務/法務介入

---

## 流程二：新客戶諮詢（從接觸到完成）

```
社群部（SOC）          業務部（BIZ）         客戶部（CRM）         財務部（FIN）
    |                      |                     |                     |
LINE/Threads              外展系統               諮詢後 24hr           收款後
潛在客戶詢問  →         （外部合作）→           記錄 client-log  →    記錄 monthly-report
    ↓
預約系統
客戶自助預約
    ↓
Tim 完成諮詢
    ↓
客戶部：建立 CRM 記錄（去識別化）
財務部：記錄收入
產品部：如有回饋，更新 product feedback
```

**關鍵規則：**
- 客戶記錄必須在諮詢完成後 **24 小時內**建立
- 收款才記錄收入，不記錄應收帳款為已收入
- 客戶代號格式：`C-YYYYMM-001`，與財務月報一致

---

## 流程三：系統功能更新上線

```
開發部（DEV）          資安部（SEC）         人資部（HR）          策略部（STR）
    |                      |                     |                     |
確認需求 →             安全審查 →           更新 inventory.json →   如影響架構
撰寫代碼                  ↓                  health_score            更新 CLAUDE.md
    ↓               通過安全審查
執行上線確認三層清單         ↓
（包含網頁 + 手機版測試）   允許部署
    ↓
部署（Vercel/Render）
    ↓
更新 projects/ 說明頁
更新 dev/tasks.md（移至已完成）
```

**不可跳過的步驟：**
- 任何部署必須先完成「上線確認三層清單」
- 網頁版 **and** 手機版都要測試，缺一不可

---

## 流程四：合作外展（找新合作單位）

```
業務部（BIZ）          內容部（CNT）         財務部（FIN）         法務部（LEG）
    |                      |                     |                     |
外展系統發信 →         如需準備提案內容 →    合作確認後 →           合作合約簽署
記錄 outreach-log      提供素材              記錄收入               記錄 legal/
    ↓
對方回覆 → 更新 outreach-log 狀態
進入洽談 → 業務部主導
達成合作 → 財務部記錄、法務部建立合約記錄
```

---

## 流程五：每週例行作業

| 星期 | 部門 | 作業 | 工具/位置 |
|------|------|------|---------|
| 週一 | 社群部 | 填上週 LINE@ 數據 | line official/weekly-log.md |
| 週一 | 內容部 | 確認本週 Threads 排程 | content/content-calendar.md |
| 週五 | 開發部 | 更新 tasks.md 本週進度 | dev/tasks.md |
| 月底 | 財務部 | 完成當月財務月報 | finance/monthly-report.md |
| 月底 | 人資部 | 確認所有系統健康分數是否需要更新 | hr/inventory.json |

---

## 跨部門溝通原則

1. **資料一次建立，不重複填寫**：同一筆資料只記錄在一個地方，其他部門讀取，不複製
2. **主責部門負責記錄**：誰處理這件事，誰負責更新對應檔案
3. **異常立即上報策略部**：任何跨部門協調問題 → 總管模式處理
4. **不允許口頭交接**：所有資訊必須落地為文字，存入對應部門資料夾

# LINE@ 廣播發送 SOP

> 狀態：有效 ｜ 最後更新：2026-04-11
> 執行時機：每次發送 LINE@ 廣播前
> 負責部門：社群部（SOC）

---

## 廣播類型與適用時機

| 類型 | 時機 | 頻率建議 |
|------|------|---------|
| 工具推廣廣播 | 推廣診斷工具、預約服務 | 每月 1-2 次 |
| 內容分享廣播 | 分享 Threads 高互動貼文 | 視內容品質決定 |
| 活動通知廣播 | 諮詢名額、優惠方案 | 不定期 |
| 週期性提醒 | 求職旺季前（金九銀十、年底）| 每季 1 次 |

---

## 發送前準備

### 步驟 1：確認訊息內容
廣播訊息結構（建議格式）：

```
【開場句】（1 行，引起注意）

【主要內容】（2-4 行，核心訊息）

【行動呼籲（CTA）】（1 行，告訴對方要做什麼）
🔗 [連結]

---
回覆「退訂」可取消接收廣播
```

**字數建議：** 80-150 字（太長會被截斷）
**CTA 連結類型：** 診斷工具、預約連結、官網、Threads 貼文

### 步驟 2：確認目標對象
- 全體好友：適用一般資訊分享
- 如有標籤分群：針對特定族群（如「轉職族」）

### 步驟 3：確認發送時間
| 時間 | 適合度 |
|------|-------|
| 週一至週五 12:00–13:00 | ⭐⭐⭐ 午休看手機 |
| 週一至週五 20:00–22:00 | ⭐⭐⭐ 下班後 |
| 週末 10:00–12:00 | ⭐⭐ 週末上午 |
| 週末晚間 | ⭐ 避免，打擾感強 |

---

## 發送步驟

1. 登入 LINE Official Account Manager
2. 左側選單 → 「群發訊息」→「建立訊息」
3. 選擇訊息類型：文字訊息
4. 貼上已準備好的內容
5. 設定目標：全體好友 或 特定標籤
6. 選擇「立即傳送」或「預約傳送」（建議預約在最佳時間）
7. 預覽確認後 → 送出

---

## 發送後追蹤

發送後 24 小時，至 LINE OA Manager 查看：
- 傳送成功數
- 已讀率（開封率）

將數據記錄到 `line official/weekly-log.md` 對應週次的「推播開封率」欄位。

---

## 廣播訊息範本庫

### 範本 A：診斷工具推廣
```
你的履歷，可能正在第一關就被刷掉。

用 AI 幫你做五維診斷：定位・成果・相關性・視覺・敘事
找出真正卡關的那一個維度。

免費試試看 👇
🔗 https://tzlth-resume-diagnosis.vercel.app
```

### 範本 B：貼文分享
```
最近在 Threads 分享了一件很多人搞錯的事——

「我什麼都願意嘗試」，是求職大忌。

點進來看為什麼，以及怎麼改 👇
🔗 [Threads 貼文連結]
```

### 範本 C：諮詢名額通知
```
四月還有 2 個一對一諮詢名額。

適合：投了很多封沒回音、不知道問題出在哪的你。

有興趣的話，可以先預約時間聊 👇
🔗 https://my-booking-system.onrender.com/
```

---

## 關鍵字自動回覆設定（LINE OA Manager）

關鍵字回覆讓好友輸入特定字詞時，自動收到對應訊息。設定後無需 Tim 人工回覆。

### 建議關鍵字清單

| 關鍵字 | 自動回覆內容 |
|--------|------------|
| 診斷、履歷、履歷診斷 | 「我幫你免費診斷一下 👇 只要上傳 PDF，1 分鐘出結果：https://tzlth-resume-diagnosis.vercel.app」 |
| 預約、諮詢、約 | 「可以在這裡直接預約 30 分鐘諮詢 👇 https://my-booking-system.onrender.com/」 |
| 價格、費用、多少錢 | 「諮詢費用請看這裡 👇 [預約頁面連結] 也可以直接回覆這則訊息問我！」 |

### 設定步驟（Tim 操作，約 5 分鐘）

1. 開啟 LINE Official Account Manager（電腦版）
2. 左側選單 → 「自動回應訊息」→「關鍵字回應」
3. 點選右上角「建立」
4. 填入關鍵字（如：診斷、履歷診斷）
5. 填入回覆內容（複製上方範本）
6. 勾選「完全符合」或「包含」（建議選「包含」）
7. 儲存
8. 重複步驟 3-7，建立所有關鍵字

> 完成後可以自己從 LINE 傳「診斷」測試是否正常觸發。

---

## 注意事項

- **每月廣播次數勿超過 4 次**（避免被封鎖好友）
- **每次廣播間隔建議 7 天以上**
- **不要在同一天發多則廣播**
- LINE@ 免費方案每月有訊息則數上限，超過需付費 → 發送前確認剩餘則數

# 合作外展操作 SOP

> 狀態：有效 ｜ 最後更新：2026-04-11
> 執行時機：每週或每兩週執行一次外展
> 負責部門：業務部（BIZ）

---

## 外展半自動流程概覽

```
Tim 說「生成本週外展草稿」
        ↓
Claude 讀取 outreach-log.md（確認哪些已發過）
        ↓
Claude 生成 5 封草稿 → 存入 business/outreach-drafts/YYYY-MM-DD.md
        ↓
Tim 閱讀草稿（約 5 分鐘）
        ↓
Tim 說「發送本週外展」 或 「修改第 X 封，然後發送」
        ↓
Claude 執行發信 + 更新 outreach-log.md
```

**核心原則：任何信件在 Tim 明確確認前不會發出。**

---

## 步驟一：啟動草稿生成

告訴 Claude：
> 「生成本週外展草稿」

Claude 會自動：
1. 讀取 `business/outreach-log.md` 確認哪些對象已聯絡過（避免重複）
2. 讀取 `business/outreach-drafts/README.md` 了解流程
3. 根據目標清單與現有模板，生成 5 封客製化草稿
4. 存入 `business/outreach-drafts/YYYY-MM-DD.md`

---

## 步驟二：審閱草稿（約 5 分鐘）

1. 開啟 `business/outreach-drafts/YYYY-MM-DD.md`
2. 確認以下幾點：
   - `{{稱謂}}`、`{{單位名稱}}` 等佔位符是否需要填入實際資訊
   - 信件語氣是否適合對象類型
   - 聯絡資訊是否正確（Email / LINE / 網站）
3. 如需修改，告訴 Claude：「修改第 2 封，把 XX 改成 OO」

---

## 步驟三：確認發送

審閱完成後告訴 Claude：
> 「發送本週外展」

Claude 會：
1. 執行發信
2. 在 `business/outreach-log.md` 更新：
   - 「已接觸」表格新增發信記錄
   - 「發信進度總覽」的累計數字更新

---

## 步驟四：追蹤回覆

| 情況 | 動作 |
|------|------|
| 對方回覆 | 告訴 Claude「OO 回覆了，內容是 XX」，Claude 更新 outreach-log 狀態 |
| 2 週無回應 | 說「生成追蹤信：OO 單位」，Claude 生成第二封追蹤信 |
| 進入洽談 | Claude 將狀態移至「進入洽談」區塊，業務部主導後續 |

---

## 外展節奏建議

| 情況 | 建議 |
|------|------|
| 剛起步 | 每週 5 封，固定週一或週三執行 |
| 有回覆在跟進 | 先處理跟進，再發新信 |
| 旺季（金九銀十）| 可加速至每週 10 封 |
| 整體回覆率 < 5% | 暫停新發信，請 Claude 分析信件改善方向 |

---

## 目標對象優先順序

| 優先級 | 對象類型 | 理由 |
|-------|---------|------|
| 高 | 退輔會 / 榮服處 | Tim 本身有軍職背景，共鳴最強 |
| 高 | 政府勞動局 / 就業服務站 | 有明確服務需求，合作正規 |
| 中 | 社區大學 | 學員符合目標族群，彈性合作 |
| 中 | 人資協會 | 提升專業形象，間接帶來客源 |
| 中 | 企業 HR | 潛在大訂單，但決策慢 |
| 低 | 大專院校 | 學生非主要目標族群 |

---

## 發信模板位置

模板存放於外展系統：
`C:\Users\USER\Desktop\CLAUDE寫工具\合作\templates\`

12 種模板：
- 各類型（人資協會 / 社區大學 / 勞動局 / 退輔會 / 企業HR / 大專院校）
- 每類有：第一封、第二封（追蹤）、LINE 版

---

## 追蹤紀錄位置

`tzlth-hq/business/outreach-log.md`

| 欄位 | 說明 |
|------|------|
| 累計寄出 | 每次發信後更新 |
| 已回覆 | 收到任何回應即計入 |
| 進入洽談 | 對方表示有意願且持續互動 |

# 諮詢完成後操作 SOP

> 狀態：有效 ｜ 最後更新：2026-04-11
> 執行時機：每次一對一諮詢完成後，24 小時內完成
> 負責部門：客戶部（CRM）+ 財務部（FIN）

---

## 概覽

每次諮詢完成後需要完成 4 件事：
1. 建立 CRM 客戶記錄（去識別化）
2. 記錄財務收款（收到款項後）
3. 確認後續追蹤計畫
4. 更新產品部回饋（如有用戶意見）

---

## 步驟 1：建立 CRM 記錄（諮詢後 24 小時內）

開啟 `tzlth-hq/crm/client-log.md`，新增一筆記錄：

```markdown
### [客戶代號]（C-YYYYMM-序號，例如 C-202604-001）

| 欄位 | 內容 |
|------|------|
| 諮詢日期 | YYYY-MM-DD |
| 諮詢類型 | 履歷診斷 / 職涯規劃 / 面試準備 / 轉職諮詢 |
| 來源管道 | Threads / LINE@ / 官網 / 轉介紹 / 其他 |
| 主要問題類型 | P1 履歷無效率 / P2 方向不清晰 / P3 面試表現差 / P4 薪資不到位 / P5 職場困境 / P6 轉職焦慮 |
| 使用的工具/框架 | 五維診斷 / STAR 法則 / 職涯三角形 / 其他 |
| 主要發現 | （2-3 句摘要，不含任何識別資訊）|
| 給出的建議方向 | （摘要）|
| 後續追蹤計畫 | 無 / 2 週後主動詢問 / 安排第二次 |
| 備註 | |
```

**重要：不可記錄真實姓名、電話、Email、公司名稱**
客戶代號需與財務月報一致。

---

## 步驟 2：記錄收入（收到款項後）

開啟 `tzlth-hq/finance/monthly-report.md`，在「收入」表格新增一行：

```
| 收款日期 | 顧問諮詢 | 金額 NT$ | 客戶代號 | 備註（服務類型）|
```

**注意：以收款日為準，不是諮詢日**（若諮詢日與收款日不同月，記在收款當月）

---

## 步驟 3：後續追蹤計畫

根據諮詢內容判斷：

| 情況 | 動作 |
|------|------|
| 客戶有後續問題 | 約定第二次諮詢時間（預約系統） |
| 2 週後詢問進展 | 在記事本 / 行事曆設提醒，LINE 主動問候 |
| 轉介紹潛力高 | CRM 備註「轉介紹潛力」，適時分享工具連結 |
| 完成且無後續 | CRM 記錄「完成」即可 |

---

## 步驟 4：產品回饋記錄（如有）

若諮詢中出現以下情況，記錄到對應產品 roadmap：

| 情況 | 記錄位置 |
|------|---------|
| 客戶提到 AI 診斷工具的問題 | `product/roadmap-diagnosis.md` → 用戶回饋區塊 |
| 客戶提到預約流程不順 | `product/roadmap-booking.md` → 用戶回饋區塊 |
| 客戶問到我們沒有的服務 | 告訴 Claude，評估是否加入產品路線圖 |

---

## 完整時序

```
諮詢完成
    ↓
24 小時內：建立 CRM 記錄（client-log.md）
    ↓
收到款項：記錄財務（monthly-report.md）
    ↓
如需追蹤：設提醒
    ↓
如有產品回饋：更新 roadmap
```

---

## 常見問題

**Q：客戶還沒付款，要記錄嗎？**
→ CRM 記錄可以先建立，財務記錄等收款後再加。未收款可在月報「未收款追蹤」表格備註。

**Q：諮詢是免費的（試探性會談），需要記錄嗎？**
→ 建議記錄，但財務欄位填 0 或留空。CRM 記錄來源資料很有價值。

**Q：客戶不想被追蹤怎麼辦？**
→ 不追蹤即可，CRM 備註「不追蹤」。所有記錄已去識別化，不存個資。

# 系統部署與回滾 SOP

> 狀態：有效 ｜ 最後更新：2026-04-11
> 執行時機：任何系統有功能更新、修復或緊急回滾時
> 負責部門：開發部（DEV）

---

## 各系統部署方式

| 系統 | 部署平台 | 觸發方式 | 部署時間 |
|------|---------|---------|---------|
| 官網 | Vercel | git push to main | ~1 分鐘 |
| 診斷 | Vercel | git push to main | ~2 分鐘 |
| 儀表板 | Vercel | git push to main | ~2 分鐘 |
| 預約 | Render | git push to main | ~3-5 分鐘（含冷啟動） |
| 看板 | 本機 Node.js | 手動重啟 | 即時 |

---

## 標準部署流程（功能更新）

### 第一步：上線前確認（三層清單）

執行 `/上線確認 [系統名稱]` 或手動核對：

**第一層：功能確認**
- [ ] 功能在本機正常運作？
- [ ] 邊界情況（空值、長文字、特殊字元）測試過？
- [ ] 桌機瀏覽器測試通過？
- [ ] 手機瀏覽器測試通過？

**第二層：跨系統影響**
- [ ] 不影響其他系統的 API 介面？
- [ ] 不影響共用環境變數？
- [ ] 不影響用戶現有操作流程？

**第三層：風險確認**
- [ ] 知道如何回滾（見下方回滾流程）？
- [ ] 部署期間有無影響服務可用性？

> 三層全部通過 → 執行部署。任一層有疑慮 → 先解決。

### 第二步：執行部署

**Vercel 系統（官網 / 診斷 / 儀表板）：**
```bash
git add -A
git commit -m "說明這次改了什麼"
git push origin main
```
→ Vercel 自動偵測 push，開始部署
→ 約 1-2 分鐘後上線

**Render 系統（預約）：**
```bash
git add -A
git commit -m "說明這次改了什麼"
git push origin main
```
→ Render 自動偵測 push，開始部署
→ 約 3-5 分鐘後上線（有冷啟動延遲）

**看板（本機）：**
1. 停止現有 Node.js 進程（Ctrl+C）
2. 執行更新的程式碼
3. `node server.js` 重新啟動

### 第三步：部署後驗證

1. 開啟實際網址確認頁面正常載入
2. 測試剛才修改的功能
3. 快速掃描其他主要功能沒有受影響
4. **手機版也確認一次**

### 第四步：更新記錄

```
dev/tasks.md → 將對應任務移至「已完成」
hr/inventory.json → 更新 last_updated、health_score（如有變化）
projects/SYS-XX.md → 新增變更記錄一行
```

---

## 緊急回滾流程

### Vercel 系統回滾（官網 / 診斷 / 儀表板）

**方法 A：透過 Vercel 控制台（最快）**
1. 開啟 vercel.com → 進入對應專案
2. 點選「Deployments」→ 找到上一個正常的部署（Promote to Production）
3. 點「...」→「Promote to Production」
4. 約 30 秒生效

**方法 B：透過 Git 回滾**
```bash
git revert HEAD          # 建立新 commit 反轉上一次更改
git push origin main     # 推送，觸發重新部署
```

### Render 系統回滾（預約）

**方法：透過 Render 控制台**
1. 開啟 render.com → 進入預約系統服務
2. 點選「Deploys」→ 找到上一個正常的部署
3. 點「Rollback to this deploy」
4. 約 3-5 分鐘生效

**注意：預約系統回滾不影響 MongoDB 資料**（資料庫獨立於程式碼）

### 看板回滾（本機）

```bash
git log --oneline      # 找到上一個正常版本的 commit hash
git checkout [hash]    # 切換到該版本
node server.js         # 重新啟動
```

---

## 環境變數管理

各系統的環境變數記錄在：
`tzlth-hq/security/security-log.md`

**加入或修改環境變數的流程：**

**Vercel（官網/診斷/儀表板）：**
1. vercel.com → 專案 → Settings → Environment Variables
2. 新增/修改後，需重新部署才生效（觸發一次 git push 或在 Vercel 手動 Redeploy）

**Render（預約）：**
1. render.com → 服務 → Environment
2. 修改後 Render 自動重新部署

**修改後記得更新 security-log.md（只記錄變數名稱和用途，不記錄實際值）**

---

## 各系統緊急聯絡資訊

| 系統 | 部署控制台 | 監控方式 |
|------|---------|---------|
| 官網 / 診斷 / 儀表板 | vercel.com | Vercel 自動告警 |
| 預約 | render.com | UptimeRobot（已設定）|
| 看板 | 本機 | 手動確認 localhost:3939 |

---

## 常見問題

**Q：Vercel 部署卡住或失敗怎麼辦？**
→ vercel.com → Deployments → 查看 Build Logs 找錯誤訊息 → 告訴 Claude 錯誤內容

**Q：Render 每次都要等很久才能訪問？**
→ Render 免費方案有「冷啟動」機制（閒置 15 分鐘後休眠），第一次請求需要 20-30 秒等待。UptimeRobot 每 14 分鐘 ping 一次防止休眠，已設定中。

**Q：部署後發現功能壞了，要趕快回滾嗎？**
→ 評估影響範圍：
- 影響用戶（診斷/預約/官網）→ 立即回滾
- 只影響自用工具（看板/儀表板）→ 可以先修復再重新部署

# 網頁內容學習分析 SOP

> 最後更新：2026-04-18 | 狀態：有效

---

## 一、觸發條件

### 應觸發（Tim 在對話中貼入以下類型 URL）
- Threads 貼文（非 YouTube）
- 部落格文章 / 長文
- LinkedIn 文章
- 電子報 / Newsletter
- 研究報告 / 學術文章

### 不應觸發（明確排除）
- YouTube 連結 → 改用 `yt-learning-sop.md`
- 操作型 URL（Vercel 後台、GitHub repo、Google Docs 等）
- 非內容頁面（首頁、登入頁、電商頁）
- Tim 只是轉貼連結但明確說「不需要分析」

---

## 二、內容類型判斷

收到 URL 後，先快速判斷內容類型，再選擇對應的讀取策略與分析重點：

| 類型 | 特徵 | 分析重點 |
|------|------|---------|
| **社群貼文型** | 字數 < 500、有互動數據（按讚/回覆/轉發）、發自個人帳號 | 觀點萃取 + 素材轉化潛力 |
| **長文章型** | 字數 500–8000、有章節結構、署名作者 | 方法論萃取 + 系統對比 |
| **技術文件型** | 結構化步驟、有代碼或操作截圖、官方或工具來源 | 操作方法 + 直接採用可行性 |
| **研究/報告型** | 數據密集、有引用來源、PDF 或白皮書 | 數據萃取 + 論點可信度驗證 |

> 判斷後在維度1輸出，不允許跳過類型判斷直接進入分析。

---

## 三、內容讀取策略

依內容類型選擇讀取方式：

| 類型 | 優先方式 | Fallback |
|------|---------|---------|
| **社群貼文型** | Chrome MCP `navigate` → `read_page`（accessibility tree，抓完整貼文+留言） | `get_page_text`（若 accessibility tree 不完整）|
| **長文章型** | `WebFetch` | Chrome MCP `get_page_text`（若 WebFetch 返回空或被封鎖）|
| **技術文件型** | `WebFetch` | Chrome MCP `navigate` → `read_page` |
| **研究/報告型** | `WebFetch` | 若為 PDF → 使用 Read 工具或 `/pdf` skill |

**讀取完整性檢查**（讀取後必須確認）：
- 社群貼文型：是否讀到完整貼文正文 + 主要回應？
- 長文章型：是否包含所有章節標題與內文？（非截斷版）
- 技術文件型：是否包含所有步驟說明？
- 研究/報告型：是否包含數據表格與結論段落？

若讀取不完整，必須在維度2說明限制，並在分析中標注哪些部分係推斷而非直接讀取。

---

## 四、八維分析輸出格式

完整分析必須依序輸出以下八個維度，不得省略：

---

### 維度 1：定性（基本資料）

```
- **平台**：[Threads / Medium / LinkedIn / 官方部落格 / 其他]
- **URL**：[完整連結]
- **作者**：[帳號名稱 + 一行背景描述]
- **發布日期**：[YYYY-MM-DD 或估算]
- **互動數據**：[按讚 X / 回覆 X / 轉發 X（如有）]
- **內容類型**：[社群貼文型 / 長文章型 / 技術文件型 / 研究報告型]
- **可信度評估**：[高 / 中 / 低，說明理由]
```

---

### 維度 2：讀取記錄

```
- **讀取方式**：[WebFetch / Chrome MCP navigate + read_page / get_page_text / PDF]
- **內容完整性**：[完整 / 部分（說明截斷位置）]
- **讀取限制**：[無 / 動態載入限制 / 登入牆 / 截斷 X 字後]
```

---

### 維度 3：核心概念五欄比較

針對文章中提取 2–5 個核心概念，每個概念填寫五欄：

| 概念 | A 是什麼 | B 解決什麼問題 | C 我們目前做法 | D 來源做法 | 比較結論（A/B/C/D）|
|------|---------|-------------|-------------|----------|-----------------|
| [概念1] | | | | | A：高/中/低；B：可用/可參考/不適用；C：保留/改善/替換；D：全採/部分採/不採 |
| [概念2] | | | | | |
| ... | | | | | |

> 每個比較結論必須給出明確方向（全採 / 部分採 / 不採），不允許「視情況」模糊帶過。

---

### 維度 4：可採用點（具體行動）

列出 0–5 個可採用的行動，每條必須包含：

```
- 【系統/部門】行動描述 → 影響 → 難度（低/中/高）→ P等級（P1/P2/P3）
```

範例：
```
- 【知識庫/KM】在 knowledge/references/ 新增 XXX 分類 → 提升方法論覆蓋率 → 低 → P2
- 【社群部/CNT】將 XXX 觀點轉化為 Threads 輪播貼文 → 驗證受眾反應 → 中 → P3
```

> 難度低且影響明確的項目，優先升為 P2；可能影響多系統的項目，先評估跨系統衝突。

---

### 維度 5：明確不採用

列出從文章中識別但決定**不採用**的做法，並說明原因：

```
- [做法] — 不採用原因：[與現有架構衝突 / 成本過高 / 不符受眾 / 已有更好的替代方案]
```

> 若完全沒有不採用項目，仍必須輸出此維度並說明「本文無需排除的做法」，不得省略。

---

### 維度 6：整體對比判斷

```
- **與現有系統的關係**：[補充缺口 / 驗證現有做法 / 挑戰現有假設]
- **最有價值的一點**：[一句話總結]
- **最需要注意的風險**：[一句話說明]
- **整體評分**：[高價值 / 中等參考 / 低價值，理由一句]
```

---

### 維度 7：立即行動（0–3 條）

僅列出「**本次對話結束前可以直接執行**」的項目：

```
1. [動作] → [預期結果]
2. ...（最多 3 條，超過列入 tasks.md P3）
```

> 若沒有立即可執行的項目，輸出「本次無立即行動，採用點已列入 tasks.md」。

---

### 維度 8：存入知識庫

**強制執行**：分析完成後，必須將條目插入對應的 `knowledge/references/` 檔案，位置為 `<!-- MANUAL END -->` 標記**之前**。

**路由規則**：

| 內容分類 | 存入位置 |
|---------|---------|
| 職涯顧問方法論 / 求職策略 | `知識庫/references/職涯顧問方法論.md` |
| 社群行銷 / 內容策略 / 演算法 | `knowledge/references/社群行銷.md` |
| AI 工具 / 自動化工具 | `knowledge/references/AI工具.md` 或 `自動化工具.md` |
| 學習方法 / Claude Skills / 工具使用 | `knowledge/references/學習資源.md` |
| 銷售技巧 / 客戶溝通 | `knowledge/references/銷售技巧.md` |
| 知識管理 / 第二大腦 | `knowledge/references/知識管理工具.md` |
| 不符合上述任何分類 | `knowledge/references/其他參考資料.md` |

**插入格式**：

```markdown
## [中文標題]（[YYYY-MM-DD]）

🔗 [完整 URL]

**作者**：[帳號/名稱]（[平台]）
**內容類型**：[社群貼文型 / 長文章型 / 技術文件型 / 研究報告型]
**分類**：[對應的 knowledge/references/ 分類標籤]

**摘要**：[2-3 句話，說明文章核心觀點]

**深度分析**：[1-2 句，說明與我們系統的關聯或對比發現]

**採用點**：
- [採用點1]
- [採用點2]（最多 3 條）

**用途標籤**：[關鍵詞1、關鍵詞2、關鍵詞3]

---
```

> **禁止**：分析完成但未插入知識庫 → 維度8未完成 = 整個分析未完成。

---

## 五、分析品質自查

完成八維分析後，在輸出前逐項確認：

- [ ] **維度1完整**：定性六欄均已填寫，可信度評估有理由
- [ ] **讀取記錄誠實**：若有截斷或限制，已在維度2說明，且分析中標注推斷部分
- [ ] **五欄比較有結論**：每個概念的比較結論欄位均有明確方向（全採/部分採/不採），無模糊帶過
- [ ] **採用點可追蹤**：每條採用點有系統名稱 + 行動 + 影響 + 難度 + P等級，可直接移入 tasks.md
- [ ] **不採用維度已輸出**：即使沒有不採用項目，維度5仍有內容
- [ ] **整體判斷有評分**：維度6有整體評分與理由
- [ ] **知識庫已插入**：維度8的條目已實際寫入對應 .md 檔案的 `<!-- MANUAL END -->` 之前
- [ ] **採用點 → tasks.md 轉化已完成**（見步驟九）

---

## 步驟九：採用點 → tasks.md 強制轉化

> **觸發時機**：維度 8 寫入知識庫後，立即執行本步驟，不可省略。

對維度 4 的每條採用點，逐條判斷並執行：

| 條件 | 動作 |
|------|------|
| 難度「低」，本次對話可執行 | 直接執行，完成後在 tasks.md 補 `[x]` |
| 難度「中」，近期可規劃 | 寫入 `dev/tasks.md` P2，附來源標記 |
| 難度「高」，長期追蹤 | 寫入 `dev/tasks.md` P3，附評估標準與來源標記 |
| 決定不採用 | 在對應知識庫條目補「**不採用理由**」段落說明 |

**tasks.md 條目格式**：
```
[ ] P2/P3：[行動描述] — [預期影響]（來源：[文章標題/作者] [YYYY-MM-DD]）
```

**禁止**：採用點只寫入知識庫條目而不轉化為 tasks.md 條目，導致知識停留在知識庫、不進入執行軌道。

---

## 六、最近修改記錄

| 日期 | 修改內容 | 狀態 |
|------|---------|------|
| 2026-04-18 | 初版建立，八維分析框架 + 四類型路由 + 觸發條件 + 品質自查 | ✅ |
| 2026-04-18 | 新增步驟九「採用點 → tasks.md 強制轉化」+ 品質自查第 8 條更新（修補：採用點停留知識庫不進執行軌道的結構性缺口）| ✅ |

# 每週例行作業 SOP

> 狀態：有效 ｜ 最後更新：2026-04-11
> 負責部門：策略部（STR）協調，各部門執行

---

## 週一早上（約 15 分鐘）

### 步驟 1：填入 LINE@ 上週數據
1. 開啟 LINE Official Account Manager（liff.line.me/1645278921-kWRPP32q）
2. 點選「數據分析」→「追蹤者」
3. 查看：總好友數、本週新增、本週封鎖
4. 點選「訊息傳送」→ 查看上週廣播開封率
5. 將數字填入 `C:\Users\USER\Desktop\CLAUDE寫工具\line official\weekly-log.md`
6. 格式：
   ```
   ### YYYY-WXX（MM/DD - MM/DD）
   - 總好友數：X 人
   - 本週新好友：X 人
   - 本週封鎖/取消追蹤：X 人
   - 推播次數：X 次
   - 推播開封率：X %
   - 聊天訊息數（流入）：X 則
   - 主要互動內容：（補充）
   ```

### 步驟 2：確認本週 Threads 排程
1. 開啟 `tzlth-hq/content/content-calendar.md`
2. 確認本週（當前日期 ± 7 天）有哪幾篇「待發布」
3. 如果主題已規劃但還沒寫稿 → 告訴 Claude「幫我寫 XX/XX 的貼文草稿」
4. 如果下週內容空白 → 告訴 Claude「規劃下週 Threads 主題」

### 步驟 3：確認外展草稿是否需要生成
- 如果上週草稿已全部發出，或本週有空執行 → 告訴 Claude「生成本週外展草稿」
- Claude 自動生成 5 封並存入 `business/outreach-drafts/YYYY-MM-DD.md`，Tim 確認後再發

---

## 週五下午（約 10 分鐘）

### 步驟 1：更新 dev/tasks.md
1. 打開 `tzlth-hq/dev/tasks.md`
2. 本週完成的項目移至「已完成」（填入日期）
3. 確認 P0/P1 有無需要新增或調整優先級

### 步驟 2：告訴 Claude「給我週報」
- Claude 自動執行全系統拉取 → 生成週報
- 週報輸出至 `reports/weekly-report.md`（摘要）+ `reports/weekly/YYYY-WXX.md`（存檔）

---

## 月底（每月 25–31 日，約 20 分鐘）

### 步驟 1：完成財務月報
1. 開啟 `tzlth-hq/finance/monthly-report.md`
2. 填入本月每筆諮詢收入（日期、金額、客戶代號）
3. 確認 LINE@ 月費（LINE Official Account Manager → 方案資訊）
4. 填入「本月收入合計」「本月支出合計」「本月淨利」

### 步驟 2：確認系統健康
- 告訴 Claude「健康檢查」
- 針對健康分數 ≤ 3 的系統，確認是否需要本月處理

---

### 步驟 3：月度 Lead/Lag 回顧（10 分鐘）
1. 翻本月四份週報（`reports/weekly/YYYY-WXX.md`）的「七、Lead 指標週結」
2. 哪個 Lead 連續 ≥3 週未達目標 → 判斷：換策略還是換行動
3. 對照 `strategy/roadmap.md` 本季里程碑：完成打 `[x]`，延遲標 `⚠️`

---

## 每季（4/7/10/1 月，約 60 分鐘）

### 說「季度盤點」→ Claude 執行五步驟
1. **全局掃描**：執行總管模式，各系統健康概況
2. **里程碑盤點**：確認 roadmap.md 本季清單 ✅/⚠️/❌
3. **WAM 季均分析**：讀本季各週報第七節，計算三組 Lead 季均完成率
4. **下季方向決策**：Tim 口頭說明 → Claude 更新 roadmap.md + strategy/CLAUDE.md
5. **歸檔**：輸出季度反思報告 → `reports/quarterly/YYYY-QX.md`

> 對齊 strategy/CLAUDE.md KPI「季度方向確認執行率」：4/7/10/1 月各一次

---

## 有諮詢完成當天

→ 見 `post-consultation.md`（獨立 SOP）

---

## 常見問題

**Q：忘記填 LINE@ 數據怎麼辦？**
→ 補填即可，LINE OA Manager 保留 60 天數據，可以補查

**Q：Claude 讀不到 weekly-log.md 怎麼辦？**
→ 確認檔案路徑：`C:\Users\USER\Desktop\CLAUDE寫工具\line official\weekly-log.md`

**Q：content-calendar.md 的主題想改怎麼辦？**
→ 直接編輯 calendar，或告訴 Claude「把 XX/XX 的主題改為 OOO」

# YouTube 影片學習分析 SOP
> 最後更新：2026-04-18 ｜ 狀態：有效
> 觸發時機：Tim 在對話中貼入 YouTube 連結時，Claude 自動套用本 SOP（不需說指令）

---

## 一、觸發條件

對話中出現以下任一形式，立即套用本 SOP：
- `https://www.youtube.com/watch?v=...`
- `https://youtu.be/...`

不應觸發情境：
- Tim 明確說「不用分析，只是參考」
- 連結不是教學/知識型影片（如音樂、娛樂、新聞）

---

## 二、字幕讀取策略

### 第一步：確認字幕可用性（必做）

先執行 JS 確認：

```js
const hasCaptions = 'captions' in window.ytInitialPlayerResponse;
```

| 結果 | 行動 |
|------|------|
| `true`（有字幕）| → 路徑 A：YouTube 原生「顯示逐字稿」|
| `false`（無字幕）| → 路徑 B：fallback 描述文字分析 |

---

### 路徑 A：有字幕（hasCaptions = true）

**主方法：YouTube 原生「顯示逐字稿」**
1. 捲動頁面至描述區塊（影片下方）
2. 若有「…更多」按鈕，先點擊展開
3. 在描述區塊中尋找「顯示逐字稿」按鈕 → 點擊
4. 等待逐字稿面板展開後，讀取面板全文

**依影片長度選批次策略：**

| 長度 | 策略 |
|------|------|
| < 15 分鐘 | 一次讀完全部字幕（單批次）|
| 15–45 分鐘 | 依 timestamps 分段，每段約 300 字幕，逐批讀取 |
| > 45 分鐘 | 先讀標題 + 影片描述判斷值不值得深讀，確認後再分批讀全文 |

**讀取工具：**
- 開啟面板：`mcp__Claude_in_Chrome__computer`（點擊操作）
- 讀取內容：`mcp__Claude_in_Chrome__get_page_text`（讀取面板全文）
- 長影片批次：`mcp__Claude_in_Chrome__javascript_tool` 滾動面板 + 分段讀取
- ⚠️ 原 `timeToSec()` 為舊 API 方法，已不適用本路徑

---

### 路徑 B：無字幕（hasCaptions = false）

1. 用 `mcp__Claude_in_Chrome__get_page_text` 讀取完整影片描述文字
2. 提取描述內時間戳記清單（若有）作為內容脈絡
3. **在維度 2 記錄**：「本影片無字幕，分析基於描述文字 + 時間戳記，非逐字稿」
4. 維度 3 比較結論標記 ⚠️：「推論依據為描述文字，非完整逐字稿」

---

## 三、八維分析輸出格式

### 維度 1：影片定性
- 頻道名 / 影片標題 / 時長
- 類型（擇一）：工具操作教學 / 方法論框架 / 案例分享 / 商業模式
- 類型決定「分析重點」與「存入位置」（見維度 8）

### 維度 2：字幕讀取批次記錄
- 說明字幕可用性（hasCaptions 結果：true/false）
- 記錄選擇路徑（A：YouTube 原生逐字稿 / B：描述文字 fallback）
- 路徑 A：說明批次數量與時間段範圍
- 路徑 B：說明描述文字長度 + 時間戳記清單是否存在

### 維度 3：核心概念提取（3–5 個）

每個概念必須完整填寫以下五欄（不得跳過）：

| 欄位 | 說明 |
|------|------|
| **是什麼** | 一句話定義 |
| **解決什麼問題** | 這個做法針對什麼痛點 |
| **我們目前的做法** | 具體描述現有機制，或寫「無」|
| **影片的做法** | 具體描述影片示範的方式 |
| **比較結論** | 見下方四條路徑，**必須選一條並說明理由** |

比較結論四條路徑：
- **A）影片更好** → 說明哪裡更好（更完整/更自動化/更有系統）→ 列入維度 4 可採用點
- **B）我們更好** → 說明為什麼（我們的機制更完整/已整合進 CLAUDE.md）→ 記錄於維度 5
- **C）各有優劣** → 說明各自的強項，判斷是否整合兩者優點 → 若可整合列入維度 4
- **D）我們無此機制** → 直接列入維度 4 可採用點

> ⚠️ 禁止因為「已有」就跳過比較。只有在比較後確認「我們更好」，才能記為 B。

### 維度 4：可採用點清單

格式：
```
- [系統/部門] 行動描述 → 預計影響 → 難度（低/中/高）→ tasks.md 等級（P1–P3）
```

難度定義：
- 低 = 本次對話可執行
- 中 = 本週可規劃（加入 tasks.md P2）
- 高 = 長期追蹤（加入 tasks.md P3）

無可採用點時，明確寫：「本影片無可採用點，原因：[說明]」

### 維度 5：明確不採用記錄

格式：
```
- [做法描述] → 不採用原因（我們已有更好版本 / 架構不符 / 成本過高 / 時機未到）
```

目的：避免下次遇到類似做法重複評估。
若無排除項，寫：「本影片無明確排除點」

### 維度 6：與現有系統整體對比

- 影片整體方法論 vs 我們目前系統的整體水準
- 判斷：值得全面學習 / 局部採用 / 僅供參考（說明原因）

### 維度 7：立即行動（0–3 條）

只寫「本次對話就能執行」的事。
若無立即可做的，此欄位寫「無，採用點已列入 tasks.md」

### 維度 8：存入知識庫（執行，不是建議）

依影片類型決定存入位置：

| 類型 | 摘要存入位置 | 採用點存入位置 |
|------|------------|--------------|
| 工具操作教學 | `knowledge/references/學習資源.md` | `dev/tasks.md`（P2/P3）|
| 方法論框架 | `knowledge/references/學習資源.md` + `knowledge/methodology/`（若有新框架）| `dev/tasks.md` + 可能新增方法論文件 |
| 案例分享 | `knowledge/references/學習資源.md` | `knowledge/client-patterns.md`（若有客群洞察）|
| 商業模式 | `knowledge/references/學習資源.md` | `strategy/` 相關文件 |

**強制執行**：摘要必須在本次對話中實際寫入 `knowledge/references/學習資源.md`，不得留待下次。

---

## 四、分析品質自查（輸出前逐項確認）

- [ ] 維度 3 每個概念都有比較結論（A/B/C/D），無空白
- [ ] 維度 4 每個採用點有難度標記與 tasks.md 等級
- [ ] 維度 5 有記錄（即使為空也明確說明）
- [ ] 維度 8 摘要已實際寫入 `knowledge/references/學習資源.md`
- [ ] **採用點 → tasks.md 轉化已完成**（見步驟九）
- [ ] 字幕可用性已確認（hasCaptions JS 執行，路徑 A/B 選擇已在維度 2 記錄）

---

## 步驟九：採用點 → tasks.md 強制轉化

> **觸發時機**：維度 8 寫入知識庫後，立即執行本步驟，不可省略。

對維度 4 的每條採用點，逐條判斷並執行：

| 條件 | 動作 |
|------|------|
| 難度「低」，本次對話可執行 | 直接執行，完成後在 tasks.md 補 `[x]` |
| 難度「中」，近期可規劃 | 寫入 `dev/tasks.md` P2，附來源標記 |
| 難度「高」，長期追蹤 | 寫入 `dev/tasks.md` P3，附評估標準與來源標記 |
| 決定不採用 | 在學習資源.md 條目補「**不採用理由**」段落說明 |

**tasks.md 條目格式**：
```
[ ] P2/P3：[行動描述] — [預期影響]（來源：[影片標題/頻道] [YYYY-MM-DD]）
```

**禁止**：應用場景只寫入學習資源.md 而不轉化為 tasks.md 條目，導致知識停留在知識庫、不進入執行軌道。

---

## 五、最近修改記錄

| 日期 | 修改內容 | 狀態 |
|------|---------|------|
| 2026-04-17 | 初版建立（八維分析框架）| ✅ |
| 2026-04-17 | 新增字幕可用性判斷（路徑 A：YouTube 原生逐字稿 / 路徑 B：fallback 描述分析）+ Dimension 2 擴充 + 品質自查第 6 條 | ✅ |
| 2026-04-18 | 新增步驟九「採用點 → tasks.md 強制轉化」+ 品質自查第 5 條更新（修補：應用場景停留知識庫不進執行軌道的結構性缺口）| ✅ |