# 顧問方法論（Methodology）

> 狀態：大致完成（4/5 項已建立）｜ 最後更新：2026-05-13

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

## 待建立的文件

- [x] `resume-diagnosis-framework.md` — 履歷診斷流程與評分標準
- [x] `consultation-framework.md` — 諮詢對話框架（開場、探索、建議、結尾）
- [x] `career-problem-patterns.md` — 常見職涯問題類型與對應解法
- [x] `lecture-product-review-guidelines.md` — 講座簡報審查指引（2026-04-13）
- [x] ~~`client-case-template.md`~~ — 已由 `knowledge/cases/README.md` 取代（RCF-026，2026-04-29 建立，含三維索引 + 案例 MD 格式規格）

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

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

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

---

## 一、問題分類總覽

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

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

> **⛔ 對外名稱 = 命名 Source-of-Truth（2026-06-16 建立）**：本表「對外名稱」欄是 P1-P6 對外品牌符號的唯一定義來源。
> - **內部**（診斷邏輯 / SKILL / cases / client-patterns / 8 維 schema）：一律用代碼 P1-P6，對外名稱為輔。
> - **對外**（Threads 系列 / 客戶報告 / 官網案例 / L

…（完整內容請至知識庫網站查看）

# 職涯諮詢客戶 8 維度 JSON Schema v1.0

> 建立日期：2026-05-25 | 作者：Tim + Claude | 狀態：草稿（待 L210 實作驗證）
> 用途：為 SYS-10 LINE Bot Phase 4 個人化諮詢打底；定義客戶資料結構、KV 儲存規格、自動化機制

---

## 一、用途與範圍

### 本文件服務對象
| 對象 | 用途 |
|------|------|
| **L210 實作者** | Phase 4 Claude Tool Use 客戶資料萃取的完整規格 |
| **諮詢完整輸出 SKILL** | Stage 1 KV 寫入的欄位定義依據 |
| **Tim** | 了解哪些客戶資料會被收集與如何使用 |

### 明確不在範圍內
- LINE Bot 的 Gemini/Claude prompt 設計（→ L210）
- 諮詢完整輸出 SKILL 的程式碼修改（→ L210）
- line-webhook.js 的程式碼修改（→ L210）

### 個人化用途示例（讓 L210 知道為何收集這些資料）
```
career_status.employment_status = "求職中"
  → LINE Bot 回應求職類問題時，主動提供履歷/面試資源，不問「你現在有在找工作嗎？」

pain_pattern.

…（完整內容請至知識庫網站查看）

# 諮詢對話框架

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

---

## 一、諮詢的核心原則

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

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

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

---

## 二、諮詢四階段流程

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

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

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

**諮詢開場確認（ICF B 合規 — S0/S4 用，目標確認後接續，約 15 秒）：**

> 「那我說一下今天的流程——我會先聽你說狀況，中間我可能會問一些往深處挖的問題，最後我們一起整理出你可以帶走的方向。大概是這樣。你準備好了嗎？」

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

---

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

**目的：** 深入了解客戶

…（完整內容請至知識庫網站查看）

# 講座簡報審查指引

> 適用範圍：職涯停看聽旗下所有講座型產品（就業講座、工作坊、企業內訓）
> 建立日期：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 渲染時中文文字全數消失 |
| 文字框溢出 | 每次新增文字後確認文字框高度足夠，無截斷；特別注意「

…（完整內容請至知識庫網站查看）

# 履歷診斷框架

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

---

## 一、履歷的本質定義

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

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

---

## 二、五維診斷框架

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

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

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

---

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

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

**黃金公式：**
> 用 [行動動詞] + [方法/工具] + [量化結果]
>

…（完整內容請至知識庫網站查看）

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

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

---

## AI 調用前置說明（適用任何 AI 工具，不依賴 CLAUDE.md 中間層）

**何時調用此文件**
- 面談中需要選擇診斷/分析框架（S1/S2/S3 任何階段）
- 設計諮詢課程架構時（W 系列/C 系列，框架整合設計）
- 撰寫諮詢案例分析或知識庫條目需要引用框架名稱時

**快速框架路由**
| 情境 | 優先框架 |
|------|---------|
| 不知從哪裡切入 | 框架一（永遠是入口，心理障礙前置診斷）|
| 客戶把兩個問題綁成一個無解結（要不要走+去哪 / 適配 vs 環境 / 互斥 vs 時序 / 標籤異質）| **雙問題分離診斷**（見 `consultation-framework.md` 三‧六）——拆開排序後再進框架五/六 |
| 客戶有職能語言落差、準備轉職 | 框架二（職能轉譯矩陣）|
| 需要重建履歷事例 / 面試回答 | 框架三（STAR 深度重構法）|
| 客戶有不利職涯事實（辭退/空窗/非線性）| 框架四（職涯敘事重構法）|
| 方向迷茫 / 評估多路徑財務可行性 | 框架五（財務逆推職涯定位法）|
| 客戶 35+ 且有職涯

…（完整內容請至知識庫網站查看）

# 系統操作手冊（Operations）

> 狀態：有效 ｜ 最後更新：2026-06-10
> 更新頻率：事件驅動（新增/修改/刪除操作文件時同步更新本索引，不定期排程）

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

## 待建立的文件

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

## 現有文件（19 份，索引）

| 檔案 | 說明 | 負責 | 建立日期 |
|------|------|------|---------|
| `cross-department-workflows.md` | 跨部門工作流程定義 | STR | 2026-04-11 |
| `post-consultation.md` | 

…（完整內容請至知識庫網站查看）

# add_article.py 使用指南

> 最後更新：2026-05-20（新增 SKILL 指針：完整發布流程含 SEO 請使用 `發布文章` SKILL）
> 文件狀態：有效
> ⚠️ **建議**：新文章發布請優先使用 `.claude/skills/發布文章.md`（含聚落分類 + 延伸閱讀 + Twitter Cards 驗證 + 雙向內鏈）；本文件保留為 add_article.py 參數參考手冊
> 腳本位置：`C:\Users\USER\Desktop\職涯停看聽_網站\add_article.py`
> 版本：v1.1（2026-04-28 排程發布支援）

---

## 1. 這是什麼

`add_article.py` 是 careerssl.com 官網的文章發布腳本，由 Claude 執行（Tim 只需提供文章內容與基本參數）。

**執行後發生的事：**
1. 從 `blog/_article_template.html` 套入模板
2. 生成 `blog/SLUG.html`（文章頁面）
3. 更新 `blog/articles.json`（文章列表，新文章 prepend 到最前）
4. 雙向更新：舊的最新篇的 `article-nav-prev` 連結更新為指向新文章

---

## 2. 前置條件

| 條件 | 說明 |
|-----

…（完整內容請至知識庫網站查看）

# 定期更新客戶案例頁面 SOP

> 版本：v1.0 | 建立：2026-05-17 | 狀態：有效
> 對應官網區塊：`index.html` → `#cases` → `.cases-grid`
> LEG-1 合規：所有案例必須去識別化，無真實姓名／公司名／可識別資訊

---

## 觸發條件（任一成立即執行）

| 觸發類型 | 條件 |
|---------|------|
| 定期觸發 | 每季末（3 / 6 / 9 / 12 月底）|
| 數量觸發 | `knowledge/cases/` 自上次更新後新增 ≥ 3 個案例 |
| 品質觸發 | Tim 主動要求更新，或發現現有卡片有更好的替代案例 |

---

## 執行步驟

### Step 1：盤點 CRM 案例
```bash
# 列出所有案例檔案（按日期排序）
ls knowledge/cases/*.md
```
對照上次執行日期（見本文件底部「執行記錄」），確認哪些是新增案例。

### Step 2：P-type 缺口分析
讀取每個新案例的 `## 基本標籤 → P-type`，對比現有官網 #cases 的 P-type 分布：

> ⚠️ **映射 2026-06-16 重新校準（RCF-088 / 裁定 A）**：對外名稱已對齊 career-problem-patterns.md SoT

…（完整內容請至知識庫網站查看）

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

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

---

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

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

> ⚠️ **SKILL 測試狀態（✅/⏳/🕐/🗃️）以主 CLAUDE.md「標準指令集（SKILL）」表為唯一來源（SOT）**。本手冊只列「指令 + 觸發行動」，不再維護狀態欄，避免雙重維護漂移。

### 🩺 系統運維

| 指令 | 觸發行動 |
|------|---------|
| `給我週報` | 全系統拉取 → 產出週報 → 存入 `reports/weekly/` |
| `健康檢查` | 快速掃描所有系統健康狀態 → 輸出健康報告 |
| `盤點 [系統名稱]` | 深度單系統盤點（現況 + 問題 + 行動方案）|
| `系統驗證` | v2.0（2026-04-30 改版）：9 系統 HTTP（含 SYS-09 PIN 保護 307 預期）+ 跨系統連結 + 5 SSL 到期日 + sitemap valid + DNS（HTTPS 代理）+ 

…（完整內容請至知識庫網站查看）

# 職涯諮詢完整 SOP（三角色 × 三階段）

> 建立日期：2026-04-23 | 版本：v1.2（2026-05-03 多 Session 架構 Phase 0-4 落地同步）
> 涵蓋範圍：諮詢前 → 諮詢中 → 諮詢後完整工作流程

---

## 三角色定義

| 角色 | 觸發詞 | 時間點 | 輸入 | 核心輸出 |
|------|-------|-------|-----|---------|
| **A 諮詢前分析師** | `諮詢前分析 [客戶代號]` | 會議前 | 客戶背景資料（預約表單 / CRM 記錄 / Tim 口述）| 會前 Brief（4 區塊）|
| **B 會議記錄員** | `會議整理 [客戶代號]` | 會議中／後即時 | 逐字稿 / 筆記 / 錄音摘要 | 結構化會議摘要 |
| **C 後續規劃師** | `諮詢完成 [客戶代號]` | 會議後 24h 內 | 角色 B 摘要（可選）+ Tim 口述補充 | CRM + 財務 + 洞察（沿用現有 SKILL）|

---

## 角色交接說明

| 交接點 | 方式 |
|-------|------|
| **A → Tim** | 會前 Brief 直接在對話中輸出，Tim 諮詢前閱讀即可，不需存檔 |
| **Tim → B** | 諮詢結束後，Tim 將逐字稿 / 筆記貼入

…（完整內容請至知識庫網站查看）

# 跨部門作業流程

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

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

---

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

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

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

---

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



…（完整內容請至知識庫網站查看）

# 雙視角確認 SOP v1.0

> **建立日期**：2026-05-31
> **觸發來源**：RCF-058（tasks.md L360 Codex 採用條件達標）
> **設計原則**：兩個 AI 獨立評估同一輸入，不互看對方輸出 → 衝突點（非共識）才是雙視角的核心價值

---

## Use Case A：月底 IMP 雙視角對辯

### 觸發條件

整理知識庫 SKILL 執行時，同時滿足：
1. 當月日期 ≥ 25 日
2. 本月尚未在 `reports/reflection-log.md` 建立 `## 雙視角對辯（YYYY-MM）` 節

---

### 執行序列（嚴格順序，不可打亂）

#### Step 1：Claude 獨立撰寫月評（必須先於 Codex 執行）

1. Grep `knowledge/improvements.md` 找本月新 IMP 條目
   - 搜尋模式：`### IMP-\d+` + 當月年月（例：`2026-05`）
2. Claude 閱讀條目內容，獨立撰寫月評
3. 寫入 `reports/reflection-log.md`：新建 `## Claude 月評（YYYY-MM）` 節
   ```markdown
   ## Claude 月評（YYYY-MM）
   > 觸發：整理知識庫 SKILL Step 7.

…（完整內容請至知識庫網站查看）

# GEO 自查 Checklist v1.0
> 建立：2026-05-29 | 適用範圍：GSC 已索引 < 30 頁（早期階段）
> 升級條件：已索引 ≥ 30 頁 + ≥ 15 個關鍵字排名 6-20 → 改用完整 CITE 40 項評估
> 框架來源：CITE C/I/T/E 四維度 × 早期階段校準版（參考 knowledge/analyses/2026-05-24-threads-bing_sunzhi-seo-geo-claude-skills.md）

---

## 目標 AI Query（評估錨點）
> careerssl.com 希望被 ChatGPT / Perplexity / Google AI Overview 引用時，對應的問題：

| # | Query | 類型 |
|---|-------|------|
| Q1 | 找職涯顧問值得嗎 台灣 | 決策型 |
| Q2 | 工作 5 年轉職怎麼規劃 | 受眾定向 |
| Q3 | 轉職履歷健康診斷 | 產品直連 |
| Q4 | 職涯諮詢要準備什麼問題 | 購買前置 |
| Q5 | 履歷被篩掉是 ATS 還是內容問題 | 具體痛點 |

---

## 評分說明
- ✅ 合格（2分）：完全符合標準
- ⚠️ 部分（1分）：部分符合，需優化
- ❌ 未達標（0分）：缺失或明顯不足

---



…（完整內容請至知識庫網站查看）

# 主動知識補充 SOP（Active Knowledge Inflow）

> 建立日期：2026-04-28 | 負責部門：知識庫（KM）
> 目的：解決現有知識輸入機制「完全被動（Tim 剛好看到才有輸入）」的結構性問題
> 與現有機制的關係：被動輸入（LINE 資料庫 + Tim 貼 URL）仍保留，本 SOP 為**主動掃描補充**

---

## 一、五個知識領域定義

| 代號 | 領域名稱 | 核心關鍵字 | 掃描頻率 | 儲存位置 |
|------|---------|-----------|---------|---------|
| D1 | 台灣職場趨勢 | 就業市場、薪資、離職率、求職趨勢、主計總處、104報告 | 每月 | knowledge/domains/D1-taiwan-workplace-trends/ |
| D2 | 職涯顧問方法論 | career coaching, career transition framework, ICF, CDA | 每月 | knowledge/domains/D2-career-coaching-methodology/ |
| D3 | 課程/講座設計 | instructional design, workshop facilitation, adult learning, ADDIE | 每季 

…（完整內容請至知識庫網站查看）

# 知識流入 SOP（Knowledge Inflow SOP）

> 版本：v1.0｜建立：2026-04-27｜負責：知識庫 KM

---

## 一、全流程架構圖

```
Tim 看到好內容（不論在手機或電腦）
  │
  ├─【捷徑 B — 電腦前】直接貼 URL 給 Claude
  │    → 說「八維分析這個 [URL]」→ 立即執行 → 跳至「三、Claude 執行」
  │
  └─【標準路線 A — 手機 / 不方便時】傳至 LINE 群組
       ↓
    GAS 自動抓取 URL → Google Sheets「LINE_資料庫_GAS」C 欄（message_text）/ E 欄（filelink）
       ↓
    兩條並行路由：

    路由 A1（全量 / 全自動）：
      所有 URL → GitHub Actions sync → knowledge/references/（Gemini 淺度摘要）

    路由 A2（精選 / 週六批次）：
      Tim 在 O 欄標「Y」→ 週六複製 URL → 貼 Claude → 八維分析 → knowledge/analyses/
```

> ⚠️ **GAS Sheet 欄位說明**：A-N 欄已由 GAS 自動化使用（A=timestamp, C=messag

…（完整內容請至知識庫網站查看）

# LINE Bot Phase 4 Prompt Design Spec v1.0

> 狀態：設計完成，Phase A 實作待執行
> 建立日期：2026-05-25
> 負責系統：SYS-10（LINE 知識管家 Bot）
> 依賴：client-8dimension-schema.md v1.0（KV 結構 + 8 維度欄位）

---

## 一、架構概覽

### 目標
每當有已建檔客戶傳訊息給 Bot，產生個人化回覆（已知其職涯進度、P-type、服務狀態），並以非同步方式從對話內容更新 8 維度資料。

### 兩支 Gemini 呼叫

| 呼叫 | 函數 | 用途 | 模式 | Temperature | 時機 |
|------|------|------|------|-------------|------|
| 呼叫 1 | `geminiCallWithSystem()` | 個人化回覆 | 純文字 | 0.6 | 同步（等待後回覆） |
| 呼叫 2 | `buildStage2DetectionPrompt()` + `geminiCall()` | Stage 2 偵測 | JSON mode | 0.2 | 非同步（回覆後背景執行）|

### 三層提示架構（呼叫 1）

```
Layer 1（固定）：system_instruction 欄

…（完整內容請至知識庫網站查看）

# LINE@ 廣播發送 SOP

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

---

## 廣播類型與適用時機

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

---

## 發送前準備

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

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

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

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

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

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

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

### 步驟 3：確認發送時間
| 時間 | 適合度 |
|------|-------

…（完整內容請至知識庫網站查看）

# Tim 操作手冊索引

> 最後更新：2026-04-24（RCF-008 建立）
> 文件狀態：有效
> 用途：統一追蹤所有「Tim 實際操作/設定/驗證」類手冊，對應 classification-matrix 第 15 類

---

## 現有操作手冊清單

| # | 手冊名稱 | 對應任務 | 生成腳本 | Google Drive 位置 | 狀態 |
|---|---------|---------|---------|------------------|------|
| 1 | Tim操作手冊_知識庫架構升級_20260424.docx | 建立總倉儲 + NotebookLM A/C/D | build_tim_word_docs.py | ✅ 2026-04-24 雲端已上傳 | ✅ 已完成 |
| 5 | Tim操作手冊_新增15操作手冊資料夾+上傳現有手冊_20260424.docx | RCF-008 元手冊（建資料夾+上傳）| build_upload_manual.py | ✅ 2026-04-24 | ✅ 已完成 |
| 2 | Tim操作手冊_SearchConsole驗證+GA4拉資料_20260424.docx | 部落格 SEO 戰略 Step 2 資料補齊 | scripts/build_seo_review.py | 15_操作手

…（完整內容請至知識庫網站查看）

# 新工具評估 SOP

> 狀態：有效 ｜ 版本：v1.0 ｜ 建立：2026-06-10 ｜ 負責：KM
> 來源：江江教練 2026-04-19 通識課「給文科生的 AI 知識管理：Harness Engineering × LLM Wiki」（完整分析：`knowledge/analyses/2026-06-10-yt-jiangjiang-harness-lecture.md` 維度 3 概念 5）
> 適用情境：任何爆紅 AI 工具出現、需判斷「要不要進入 Tim 工作流」時

---

## 核心原則

> **「熱門工具我叫我的 AI 去研究」** — 不跟風立即學習，先讓 AI 評估，確認與職涯顧問業務有實際整合價值後才進入系統。

新工具爆紅時最大的成本不是「沒跟上」，而是「花時間學了一個 3 週後就不用的東西」。本 SOP 用 7 週節奏，讓 Tim 用最低時間成本做出「進 / 不進」的決定。

---

## 一、觸發條件（什麼叫「爆紅」）

以下任一成立 → 啟動第 0 週：

- Tim 在 **3 天內從 ≥ 2 個管道**（Threads / LINE 群 / 媒體報導 / 客戶提問）看到同一工具名詞
- 競品掃描（`knowledge-inflow-active-sop.md` D4）發現競品已廣泛採用某新工具
- Tim 主動說「[工具名] 要不

…（完整內容請至知識庫網站查看）

# 合作外展操作 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-

…（完整內容請至知識庫網站查看）

# 諮詢完成後操作 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 句摘要，不含任何識別資訊）

…（完整內容請至知識庫網站查看）

# 季度離線備份 SOP（Google Takeout 三層冗餘 Layer 3）

> 最後更新：2026-04-24（RCF-007 建立）
> 文件狀態：有效
> 執行頻率：每季一次（1/4/7/10 月第一週）
> 執行時間：30 分鐘（不含 Google 處理等待）

---

## 為什麼需要此 SOP

Google 帳號萬一被封（機率 < 1%/年但非零），會導致：
- Google Drive 主庫（總倉儲）失效
- NotebookLM Notebook A + B 失效
- Gmail 帳號失效
- Google One AI Premium 訂閱失效

Layer 3 離線備份是**最後一道保險**，確保所有資料仍可完整還原至新帳號。

---

## 執行時機

| 時段 | 動作 |
|------|------|
| 1/4/7/10 月第一週任意日 | 執行本 SOP（30 分鐘）|
| 重大內容變更後（例：新建 Notebook、大量上傳產品材料）| 額外執行一次 |

## 執行步驟（7 步）

### Step 1：開啟 Google Takeout
- 網址：https://takeout.google.com
- 使用 Tim 的 Google One AI Premium 帳號登入

### Step 2：選擇備份項目
勾選以下（取消其他

…（完整內容請至知識庫網站查看）

# SaaS 客戶擴張 SOP — 預約系統新客戶 Onboarding

> **最後更新**：2026-06-08（v1.1 早期維護複查）
> **文件狀態**：有效
> **負責部門**：開發部（DEV）— SOP 主檔；法務部（LEG）— 服務協議與 DPA；策略部（STR）— 商業條款
> **適用範圍**：預約系統 SaaS（shoppy09/my-booking-system）為新客戶在 Northflank 部署獨立實例的完整流程
> **參考實作**：Tim 自用實例 www.careerssl.com/booking（C-Light 整合 2026-05-19；前身 booking.careerssl.com，Northflank 遷移 2026-04-20，見 `dev/deploy-verify/SYS-04-2026-04-20.md`）

---

## 一、觸發條件

以下任一情境觸發本 SOP：
1. 新付費客戶完成簽約（SaaS 服務協議 + DPA）
2. 合作客戶申請使用（如姐姐-01 模式，免費或內部成本）
3. 試用申請通過後（試用 14 天，到期需轉付費）

**不觸發本 SOP 的情境**：
- Tim 自用實例已部署完畢，無需重做
- 客戶僅諮詢未簽約 → 走業務部外展流程
- 程式碼異動部署 → 走既有 deploy SKILL（

…（完整內容請至知識庫網站查看）

# SKILL 整合評估八維框架（Skill Integration Review Checklist）

> **建立日期**：2026-06-01
> **文件狀態**：有效 v1.0
> **用途**：任何 SKILL 設計評估、整合評估前，逐維度掃完後輸出完整 Gap 清單；禁止以開放式追問替代框架掃描
> **觸發時機**：查照中「執行計畫」包含修改 SKILL 文件 / 新增 SKILL step / 設計新 SKILL 流程時
> **來源**：IMP-156 第 2 次出現（2026-06-01）——4 輪補漏後萃取為預建框架

---

## 使用方式

1. 開始評估前先宣告：「依八維框架逐維度掃描」
2. 逐維度填入發現（有/無問題均記錄）
3. 彙整完整 Gap 清單後一次輸出
4. 不允許「想到再補」——框架掃完即為完整

---

## 八維框架（A-H，MECE）

### A. 資料流（Data Flow）

**自問**：每個輸入從哪裡來？流向哪個輸出？有無斷路、資料遺失、格式不符？

掃描項目：
- [ ] 所有輸入來源已列出（檔案 / 使用者貼入 / API 回傳）
- [ ] 每個輸入到對應輸出的路徑清楚（Q→Section 的對應關係）
- [ ] 輸出有無去識別化需求？時機是否定義？
- [ ] 輸出同步到哪些下游文件？（consulta

…（完整內容請至知識庫網站查看）

# 系統部署與回滾 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 介面？
- [ ] 不影響共用環境變數？
- 

…（完整內容請至知識庫網站查看）

# 客戶見證收集迴路 SOP

> 版本：v1.0 | 建立：2026-06-22（RCF-100）| 狀態：有效
> 對應官網區塊：`index.html` → `#testimonials` → `.testimonials-grid`
> LEG-1 合規：所有見證必須去識別化（無真實姓名／公司名）+ **取得客戶同意公開**才可上線
> 姊妹 SOP：`operations/case-update-sop.md`（#cases 案例卡，Tim 第三人稱案例）；本 SOP 管理 #testimonials（客戶第一人稱原話）

---

## 為什麼有這份 SOP（③⑤ 缺口合流）

社會證明有**兩種資產類型**，互補不重疊：

| 資產 | 是什麼 | 收集 SOP | 官網區塊 |
|------|--------|---------|---------|
| **案例**（B）| Tim 寫的去識別化 case study | ✅ `case-update-sop.md` + 諮詢完成 SKILL Q4 → `cases/` | `#cases` |
| **見證**（A）| 客戶第一人稱原話 quote | ✅ **本 SOP**（原本缺收集 SOP+curation 節奏）| `#testimonials` |

**③⑤ 合流機制**：⑤（客戶留存收集見證）→ 

…（完整內容請至知識庫網站查看）

# 網頁內容學習分析 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、有章節結構、署名作者 | 方法論萃取 + 系統對比 |
| **技術文件型** | 結構化步驟、有代碼或操作截圖、官方或工具來源 | 操作方法 + 直接採用可行性 |
| **研究/報告

…（完整內容請至知識庫網站查看）

# 每週例行作業 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. 如果主題已規劃但還沒寫稿 → 告訴 

…（完整內容請至知識庫網站查看）

# Git Worktree 實戰 Playbook

> 建立：2026-04-24（Session 21）｜狀態：有效
> 與 `dev/CLAUDE.md`「Git Worktrees 使用 SOP」配套。SOP 給規範，Playbook 給實戰細節。
> 首次建立於 2026-04-24 真實並行試跑（tzlth-hq repo，兩個任務並行：主目錄建本 playbook + worktree 強化 SOP Troubleshooting 章節）。

---

## 一、何時該用（決策樹）

```
Q1：是同一 repo 嗎?
  ├─ 否（不同系統 / 不同 repo）→ 不用 worktree（天然隔離）
  └─ 是
      ↓
Q2：真的需要並行嗎?（另一件事不能等）
  ├─ 否（順序做即可）→ 用 git stash 就好
  └─ 是
      ↓
Q3：並行時間預期 > 30 分鐘?
  ├─ 否（< 30 分鐘）→ stash/pop 仍較快
  └─ 是 → ✅ 用 worktree
```

**決策判準精煉**：同 repo + 真並行 + 長時間 → 三者皆 Yes 才用。

---

## 二、5 個核心指令速查

| 指令 | 用途 |
|------|------|
| `git worktree add <path> <branch

…（完整內容請至知識庫網站查看）

# 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. 若有「…更多」按鈕，先

…（完整內容請至知識庫網站查看）