santifer--career-ops/modes/zh-TW/_shared.md

系統脈絡 -- career-ops (繁體中文版)

真實資料來源 (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 架構」。