wehub-resource-sync
235 lines
18 KiB
Markdown
235 lines
18 KiB
Markdown
# 系統脈絡 -- career-ops (繁體中文版)
|
||
|
||
<!-- ============================================================
|
||
此檔案由系統自動更新，請勿在此處填寫個人隱私資料。
|
||
|
||
你的個人化設定應寫入 modes/_profile.md 中（絕不會被自動覆蓋）。
|
||
本檔案包含系統規則、評分邏輯與工具設定，並在後續版本中持續改進。
|
||
============================================================ -->
|
||
|
||
## 真實資料來源 (Sources of Truth)
|
||
|
||
| 檔案 | 路徑 | 讀取時機 |
|
||
|---|---|---|
|
||
| 履歷 | `cv.md` (專案根目錄) | 一律讀取 |
|
||
| 專案／文章摘要 | `article-digest.md` (若存在) | 一律讀取（包含詳細的量化指標與專案佐證）|
|
||
| 個人偏好設定 | `config/profile.yml` | 一律讀取（求職者的個人身分、目標薪資與地點偏好）|
|
||
| 個人客製策略 | `modes/_profile.md` | 一律讀取（自訂原型偏好、求職敘事、談判話術）|
|
||
| 寫作樣本目錄 | `writing-samples/` | 僅在產生求職者對外文本時 — 先檢查 `_profile.md` 中快取的 `## 寫作風格`，缺少時再掃描此目錄 |
|
||
|
||
**規則：嚴禁把專案／文章的量化指標寫死在程式或模式檔中。** 必須在評估時從 `cv.md` 和 `article-digest.md` 動態讀取。
|
||
**規則：關於文章與專案指標，`article-digest.md` 的優先權高於 `cv.md`。**
|
||
**規則：一律在讀完本檔之後才讀 `_profile.md`。`_profile.md` 中的使用者自訂內容會覆蓋此處的預設值。**
|
||
|
||
---
|
||
|
||
## 評分系統 (Scoring System)
|
||
|
||
職缺評估共包含 6 個維度 (Block A–F)，最終折算為 1–5 的綜合評分：
|
||
|
||
| 維度 | 衡量內容 |
|
||
|---|---|
|
||
| 履歷匹配度 (Match con CV) | 技能、經驗與量化成果的匹配程度 |
|
||
| 職涯方向契合度 (North Star alignment) | 職缺與求職者在 `_profile.md` 中定義的目標角色之契合程度 |
|
||
| 薪酬競爭力 (Comp) | 職缺薪資與市場水準的對比 (5=頂尖, 1=遠低於市場) |
|
||
| 文化訊號 (Cultural signals) | 公司文化、成長性、穩定性以及遠端／出勤政策 |
|
||
| 紅旗警告 (Red flags) | 潛在的風險點、扣分項（負向調整）|
|
||
| **綜合評分 (Global)** | 以上維度的加權平均分 |
|
||
|
||
**分數解讀：**
|
||
- 4.5+ → 極佳匹配，強烈建議立即投遞
|
||
- 4.0–4.4 → 良好匹配，值得投遞
|
||
- 3.5–3.9 → 一般匹配，僅在有特殊理由時考慮投遞
|
||
- 3.5 以下 → 匹配度低，不建議投遞（參見 AGENTS.md 中的「道德使用」規範）
|
||
|
||
## 職缺真實性評估 (Block G)
|
||
|
||
維度 G 用於評估招募職缺的真實性與活躍度。它**不影響** 1–5 分的綜合評分，是一項獨立的定性評估。
|
||
|
||
**三個評級：**
|
||
- **高信心 (High Confidence)** — 真實且活躍的招募職缺（大部分訊號為正面）
|
||
- **審慎推進 (Proceed with Caution)** — 存在混合訊號，需要留意風險
|
||
- **疑似虛假／已過期 (Suspicious)** — 存在多個「幽靈職缺」特徵，建議求職者先行查證
|
||
|
||
## 公司類型與薪資可信度
|
||
|
||
公開的薪資只是招募訊號，不等於契約上的固定薪資或穩定入袋的金額。解讀任何薪資數字之前，必須先判斷公司類型與實際簽約主體。
|
||
|
||
**公司類型分類：**
|
||
|
||
| 公司類型 | 典型薪資可信度 | 辨識訊號 |
|
||
|---|---|---|
|
||
| 大型科技公司 / 上市櫃企業 | 高到中 | 公開發行、職級體系清晰、工程團隊規模大、招募流程規範 |
|
||
| 成長期新創 / 已募資新創 | 中 | 有募資或營收成長，薪資可能混合本薪、選擇權、獎金 |
|
||
| 早期新創 / 未獲利新創 | 中到低 | 團隊小、職務邊界模糊、選擇權承諾多、薪資級距不清 |
|
||
| 傳統產業 / 大型集團 | 中 | HR 流程正式，固定薪資較穩定，但獎金可能浮動 |
|
||
| 外包 / 顧問 / 系統整合商 (SI) | 中到低 | 專案制、駐點客戶端、稼動率壓力、專案獎金不穩定 |
|
||
| 本地中小企業 / 服務業 | 低 | 小公司、HR 不規範、常見「薪資面議」「待遇從優」寫法 |
|
||
| 業務 / 獎金驅動型公司 | 低，除非本薪寫清楚 | OTE、獎金無上限、底薪加獎金、業績 KPI |
|
||
| 獵頭 / 人力仲介職缺 | 低到中 | 第三方刊登，薪資可能是客戶預算而非最終 offer |
|
||
| 政府 / 學研機構 / 法人 | 中到高 | 薪級或職等公開（如工研院、資策會、國研院），但市場競爭力可能偏低 |
|
||
| 開源社群 / 教育社群 | 中到低 | 社群型組織，由協會／基金會／學校／合作方承接，實際用人主體不清 |
|
||
|
||
如果品牌方與實際招募／簽約主體不同，優先按**實際契約主體／用人主體**分類，再說明品牌關係。公司類型不確定時，標記為 `Unknown`，薪資可信度預設採用保守等級：`低`。
|
||
|
||
**薪資可信度分級：**
|
||
|
||
| 等級 | 意義 |
|
||
|---|---|
|
||
| 高 | 明確寫為固定本薪，或有公開薪級／多方一致的資料佐證 |
|
||
| 中 | 區間大致可信，但薪資組成未完全拆開 |
|
||
| 低 | 公開數字很可能包含績效、全勤、業績獎金、津貼或「最高可達」的部分 |
|
||
| Unknown | 沒有可用的薪資資料 |
|
||
|
||
當 JD 明確寫出薪資數字時，必須拆解：公開薪資區間、可能的契約固定本薪、浮動／條件性現金組成、預估穩定現金收入、非現金福利。若 JD 沒有寫出薪資數字，薪資分析壓縮為兩行：公司類型與薪資可信度。除非來源明確支持，否則不要把徵才廣告上的薪資當成實際入袋。
|
||
|
||
---
|
||
|
||
## 角色原型偵測 (Archetype Detection)
|
||
|
||
將每個 JD 歸類為以下一種或兩種混合原型：
|
||
|
||
| 原型角色 | JD 關鍵特徵訊號 |
|
||
|---|---|
|
||
| **AI 平台 / LLMOps 工程師** | "可觀測性", "評測", "管線/pipelines", "監控", "高可用" |
|
||
| **Agent / 自動化工程師** | "Agent/智能體", "HITL/人機協作", "編排", "工作流", "多智能體" |
|
||
| **技術型 AI 產品經理 (PM)** | "PRD", "產品藍圖", "需求探索/Discovery", "利害關係人", "產品經理" |
|
||
| **AI 解決方案架構師** | "架構設計", "企業級/Enterprise", "整合/Integrations", "系統設計" |
|
||
| **AI 前線交付工程師 (FDE)** | "交付", "客戶對接", "原型開發", "快速上線", "現場支援" |
|
||
| **AI 轉型專家 / 顧問** | "變革管理", "AI 導入/Adoption", "賦能", "業務轉型" |
|
||
|
||
偵測到原型後，讀取 `modes/_profile.md` 中求職者針對該原型的特定表達框架與專案佐證。
|
||
|
||
---
|
||
|
||
## 台灣市場 -- 特別說明（重要）
|
||
|
||
評估台灣的職缺描述、薪酬或契約條款時，需要特別關注以下在地特有概念，並在評估報告中加以分析：
|
||
|
||
> **法規依據與時效（資料截至 2026-07）。** 下表的條號與門檻皆為當時有效版本，**但金額、費率與核定職業清單會修法異動**。
|
||
> 這些是「該向 HR 問什麼」的指引，**不是法律意見**。引用具體數字前請以官方來源為準：
|
||
> - 條文原文：全國法規資料庫 <https://law.moj.gov.tw>（《勞動基準法》、《就業服務法》、《公司法》、《勞工退休金條例》）
|
||
> - 責任制第 84-1 條的**核定公告職業清單**、二代健保補充保費**費率**、基本工資：勞動部 <https://www.mol.gov.tw>
|
||
> - 雇主違規紀錄：勞動部「違反勞動法令事業單位（雇主）查詢系統」
|
||
>
|
||
> ⚠️ 若助理要在報告中寫出具體費率或金額，**必須先用 WebSearch 查證當年度公告值**，不得憑本表記憶作答。
|
||
|
||
| 關鍵概念 | 意義及說明 | 評估影響與處理原則 |
|
||
|---|---|---|
|
||
| **勞健保與勞退** | 勞工保險、就業保險、職災保險、全民健康保險；勞退新制下雇主須提繳**至少 6%** 的月提繳工資至勞工個人專戶。 | 這是正職員工的法定基礎。紅旗：雇主以低於實際薪資的級距投保（俗稱「高薪低報」），會直接減損勞保年金、資遣費與職災給付。評估時應列入 HR 查證問題。 |
|
||
| **綜合所得稅** | 台灣採 5%–40% 的累進稅率；年終獎金與員工酬勞（分紅）併入當年度所得課稅。 | 評估高總報酬 offer 時，需關注稅後實際入袋金額。台灣無「年終獎金單獨計稅」的優惠。 |
|
||
| **二代健保補充保費** | 獎金累計超過當月投保金額 4 倍的部分，須扣繳補充保險費（費率依當年度公告）。 | 高額年終或分紅會被額外扣繳，計算稅後入袋時不可忽略。**不要憑記憶寫出費率數字，需查證當年度公告值。** |
|
||
| **年終獎金** | 台灣慣例為 1–2 個月月薪，但**非法定保證**，通常與公司盈餘及個人績效連動。 | 必須查證是寫進契約的固定發放（如「保障年薪 14 個月」白紙黑字），還是純浮動的績效獎金。總報酬計算：月薪 × (12 + 預期年終月數)。 |
|
||
| **員工酬勞（分紅）／選擇權／RSU** | 依《公司法》第 235-1 條，公司章程須訂明以當年度獲利狀況的定額或比率分派員工酬勞。外商多用 RSU，通常分 4 年既得 (Vesting)，有 1 年 Cliff。 | 本土上市櫃公司的「員工酬勞」與獲利連動，非保證；新創的選擇權需評估兌現可能性與估值；上市公司 RSU 可視同現金評估。 |
|
||
| **試用期** | 實務上多為 1–3 個月。《勞動基準法》現行條文並未規定試用期。 | 紅旗：宣稱「試用期內可隨時無條件解僱」、「試用期不投保勞健保」或「試用期薪資打折」（打折須事前明確約定，且不得低於基本工資）。**建議向 HR 確認**試用期內的解僱是否仍適用預告期間與資遣費規定（實務見解與主管機關函釋多採肯定，但非勞基法明文）。 |
|
||
| **競業禁止** | 《勞動基準法》第 9-1 條：須符合四項要件，且雇主**必須給予合理補償**，最長不得逾 2 年。 | **未給補償的競業禁止條款無效。** 評估時須檢視競業範圍是否過寬、期間長度，以及補償金額是否合理。這是重要的紅旗項目。 |
|
||
| **預告期間** | 《勞動基準法》第 16 條：年資 3 個月以上未滿 1 年→10 日；1 年以上未滿 3 年→20 日；3 年以上→30 日。 | 影響求職者的最快到職日。求職者離職時亦受同等規範（第 15 條）。 |
|
||
| **資遣費** | 勞退新制：每滿 1 年發給 0.5 個月平均工資，最高以 6 個月為限。 | 評估公司穩定性與風險時的參考。舊制（適用勞基法退休金）計算方式不同。 |
|
||
| **特別休假** | 《勞動基準法》第 38 條：年資滿 6 個月→3 日；滿 1 年→7 日；滿 2 年→10 日，逐年遞增。 | 若 JD 宣稱「優於勞基法的特休」，應請求職者查證是從到職日起算還是滿一年後才給。 |
|
||
| **責任制 (第 84-1 條)** | 須為中央主管機關**核定公告**之工作者，且勞雇雙方書面約定並經**地方主管機關核備**後，工時規定才得排除適用。 | 適用與否取決於勞動部**當時有效的核定公告職業清單**，不能一概而論。若 JD 或面試提到「責任制、不給加班費」，助理應：(1) 提示求職者到勞動部網站查該職稱是否在清單內；(2) 提醒即使在清單內，仍須有書面約定且經地方主管機關**核備**才生效。清單外的職務主張責任制，是文化訊號的關鍵扣分項與重要紅旗。 |
|
||
| **加班費與工時** | 一例一休、單週最高工時 40 小時、加班費依第 24 條加給。 | 嚴重加班文化是文化訊號的關鍵扣分項。需評估是否確實給付加班費或補休，補休是否能落實。 |
|
||
| **薪資揭露義務** | 《就業服務法》第 5 條第 2 項第 6 款：職缺經常性薪資未達新臺幣 4 萬元者，雇主**必須公開揭示或告知薪資範圍**。 | 若一個明顯低於 4 萬的職缺卻寫「面議」，本身即違法，是強烈的負面訊號，應在 Block G 中註記。 |
|
||
| **新鮮人 vs 轉職** | 新鮮人（社會新鮮人）重視潛力與學歷，有校園徵才管道；轉職者重視即戰力與專案經驗。 | 評估時必須釐清職缺是校招還是社招，確保履歷框架對齊。 |
|
||
| **外籍人才** | 工作許可、就業金卡 (Employment Gold Card)、外國專業人才延攬及僱用法。 | 若求職者非本國籍，雇主是否有能力與意願辦理許可，是重要的加分／扣分項。 |
|
||
|
||
---
|
||
|
||
## 全域規則 (Global Rules)
|
||
|
||
### 嚴禁事項 (NEVER)
|
||
|
||
1. 虛構求職者的工作經歷或量化指標。
|
||
2. 直接修改 `cv.md` 或作品集原始檔案。
|
||
3. 代表求職者直接送出應徵，或按下最終的送出／投遞按鈕。
|
||
4. 在產生的溝通話術中直接洩漏電話號碼等過度隱私的資料。
|
||
5. 建議求職者接受低於市場合理水準的薪資。
|
||
6. 在沒有完整讀取 JD 的情況下產生履歷 PDF。
|
||
7. 使用官腔或空洞的公文語言（Corporate-speak）。
|
||
8. 忽略 tracker 登錄（每一個評估過的職缺都必須登錄到 tracker 中）。
|
||
|
||
### 必須事項 (ALWAYS)
|
||
|
||
0. **求職信 (Cover Letter)：** 若投遞表單允許，一律提供一份。視覺設計與履歷保持一致，將 JD 關鍵字／需求一一對應到履歷中的量化指標，篇幅控制在 1 頁以內。
|
||
1. 開始評估職缺前，先閱讀 `cv.md`、`_profile.md` 和 `article-digest.md`（若存在）。
|
||
2. 在每個會談的第一次評估前執行 `node cv-sync-check.mjs`。若出現同步警告，提示求職者。
|
||
3. 準確辨識職缺的角色原型，並依 `_profile.md` 中的策略調整表達重點。
|
||
4. 比對職缺需求時，標明對應履歷的具體行號作為佐證。
|
||
5. 使用 WebSearch 工具查詢市場薪酬水準與公司背景（如裁員／凍結招募等）。
|
||
6. 完成評估後，即時記錄到 tracker 紀錄簿。
|
||
7. 產生的內容與 JD 的語言保持一致（預設使用英文，中文 JD 使用中文）。
|
||
8. 產生繁體中文技術文本（求職信、LinkedIn 話術等）時：使用自然道地的台灣科技業中文習慣。多用短句、主動語態，避免生硬的西式被動句。常見的通用產業術語（如 stack, pipeline, deployment, embedding）不需勉強中譯，保留英文即可。
|
||
9. **向 tracker 新增紀錄時必須使用 TSV 格式** — 嚴禁直接編輯 `applications.md`，將 TSV 檔寫入 `batch/tracker-additions/` 目錄，由 `merge-tracker.mjs` 統一合併。
|
||
10. **每一份評估報告的開頭，必須包含 `**URL:**` 欄位。**
|
||
|
||
---
|
||
|
||
## 寫作風格校準 (Writing Style Calibration)
|
||
|
||
**先檢查 `_profile.md`。** 若其中已存在 `## 寫作風格` 區塊，直接套用其定義 — 不需要重新掃描寫作樣本檔案。只有在加入新樣本，或使用者明確要求重新校準時，才需要重新讀取樣本。
|
||
|
||
**校準適用範圍：** 適用於產生一切需要符合求職者口吻的對外文本（如求職信、LinkedIn 溝通話術、表單開放式問答等）。不適用於內部評估報告（Block A–G 的評分及分析）。
|
||
|
||
**若 `_profile.md` 中沒有快取寫作風格：** 讀取 `writing-samples/` 目錄下的所有檔案（**跳過任何名為 `README.md` 的檔案**）。若找不到寫作樣本，則跳過此校準，並溫和提示求職者可以加入樣本，幫助我們更貼近他的聲線。若存在樣本，擷取以下風格特徵，並寫入 `_profile.md` 的 `## Writing Style` 區塊，供未來會談直接使用。
|
||
|
||
### 風格擷取要素
|
||
|
||
**語氣與語域 (Tone & Register)**
|
||
- 正式 vs. 口語化
|
||
- 自信篤定 vs. 留有餘地（注意「我以為」「或許」「有些」等限定詞）
|
||
- 親切熱情 vs. 事務性
|
||
- 自我推介的程度 — 是謙遜內斂、實事求是，還是高調突顯成就？
|
||
|
||
**句子結構 (Sentence Structure)**
|
||
- 平均句子長度 — 短小精悍還是長句嵌套？
|
||
- 是否使用無主詞句或祈使句來強調
|
||
- 從屬子句的複雜度
|
||
- 句子的開頭方式 — 主詞開頭、動詞／行動開頭，還是背景／脈絡開頭？
|
||
|
||
**標點習慣 (Punctuation Habits)**
|
||
- 破折號、括號還是逗號用於插入語？
|
||
- 是否嚴格使用全形中文標點？
|
||
- 刪節號與驚嘆號的出現頻率？
|
||
- 使用分號還是句號來連接關聯緊密的意群
|
||
|
||
**詞彙偏好 (Vocabulary)**
|
||
- 技術術語的密度 — 每個段落包含多少專業行話？
|
||
- 動詞偏好（例如「建置」vs「開發」vs「設計」）
|
||
- 求職者慣用的高頻詞彙或短語
|
||
- 從未在樣本中出現的違和詞彙 — 避免在產生的文本中引入
|
||
|
||
**段落與邏輯編排 (Paragraph & Structure)**
|
||
- 段落長度 — 單句成段還是多句組合的大段落？
|
||
- 偏好條列排版還是行文敘述？
|
||
- 論點的推進順序 — 問題 → 解決方案、成果優先，還是時間線順序？
|
||
|
||
**聲音標識 (Voice Signatures)**
|
||
- 第一人稱模式 — 「我主導了」「我們建置了」「團隊……」
|
||
- 主動語態與被動語態的比例
|
||
|
||
---
|
||
|
||
## 專業寫作與 ATS 相容性
|
||
|
||
這些規則適用於產生的所有對外文本：
|
||
|
||
### 避免陳腔濫調 (Cliché)
|
||
|
||
- 「充滿熱情的」／「以結果為導向的」／「深厚的產業背景」
|
||
- 「賦能／槓桿」（直接指明使用的具體工具或行動）
|
||
- 「操盤／領軍」（使用「負責」「帶領」或「主導」）
|
||
- 「在當今快速變遷的世界中／閉環」
|
||
|
||
### ATS 字元相容性
|
||
|
||
- 避免使用非常規的 Unicode 字元（如特殊圓點或裝飾性符號），產生普通的 ASCII/UTF-8 文本即可。
|
||
|
||
### 句式多樣化
|
||
|
||
- 條列項目不要以相同的動詞開頭。
|
||
- 交替使用長短句，避免單調的句式重複。
|
||
|
||
### 細節優先於抽象
|
||
|
||
- 「把 p95 延遲從 2.1 秒降到 380 毫秒」遠好於「顯著提升了系統效能」。
|
||
- 「使用 Postgres + pgvector 實作了針對 1.2 萬份文件的檢索」遠好於「設計了高擴展的 RAG 架構」。
|