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

模式: job — 完整的 A-G 維度評估

當求職者輸入職缺描述（JD 文字或 URL 連結）時，一律輸出以下七個維度的深度評估結果（A–F 評估 ＋ G 真實性）：

步驟 0 — 職缺原型辨識

將該職缺歸類為 6 種原型之一（參見 _shared.md）。若為混合型，標明最接近的 2 種。這會決定：

• 在維度 B 中優先比對哪些量化佐證（Proof points）。
• 在維度 E 中如何改寫履歷的專業摘要。
• 在維度 F 中優先準備哪些 STAR 故事。

---

維度 A — 職缺概覽 (Role Summary)

輸出包含以下資訊的表格：

• 偵測到的角色原型 (Archetype detected)
• 技術領域 (Domain － 平台／Agentic／LLMOps／機器學習／企業級等)
• 職務機能 (Function － 架構／研發／管理／交付／轉型等)
• 資深程度 (Seniority)
• 工作模式 (Remote － 全遠端／混合／進辦公室)
• 團隊規模 (Team size － 若 JD 中有提及)
• 一句話總結 (TL;DR)

---

維度 B — 履歷匹配分析 (Match with CV)

讀取 cv.md。建立一個對照表格，把 JD 中的各項硬性／軟性條件一一對應到履歷中的具體行號與量化敘述上。

針對不同職缺原型的分析側重點：

• AI 前線交付 (FDE) → 側重交付速度、全端開發及直接面對客戶的成果。
• 解決方案架構師 (SA) → 側重系統架構設計、複雜整合及企業級高可用性。
• 技術產品經理 (PM) → 側重產品需求探索 (Discovery)、藍圖規劃、商業指標及利害關係人溝通。
• LLMOps 工程師 → 側重評測 (Evals)、可觀測性、資料／訓練管線、線上穩定性。
• Agent 編排 (Agentic) → 側重多智能體編排、人機協作 (HITL)、高容錯與智能體工程。
• AI 轉型專家 (Transformation) → 側重變革管理、AI 工具在組織內的推行、團隊賦能與流程重塑。

能力落差 (Gaps) 與彌補策略： 針對辨識出的每一項能力落差，提供以下因應方案：

1. 這是硬性門檻（Blocker）還是加分項（Nice-to-have）？
2. 求職者是否有其他相近或可遷移的經驗可以等價替換？
3. 是否可以透過一個快速的作品或文章來補上這個空白？
4. 具體的彌補行動指南（如在求職信中如何避重就輕、準備怎樣的話術）。

---

維度 C — 職級判斷與求職策略 (Level and Strategy)

1. JD 所對應的實際職級 vs 求職者針對該原型的自然職級。
2. 「凸顯資深度（實事求是）」計畫：提供針對該原型的特定自我推薦話術，突顯資深度的具體成就，以及如何把創業／接案經歷轉化為競爭優勢。
3. 「如果對方給的職級偏低」預案：若整體報酬合理是否接受、是否在契約中約定 6 個月後重新評估職級、以及明確的晉升標準。

---

維度 D — 薪酬競爭力與市場需求 (Comp and Demand)

使用 WebSearch 工具查詢：

• 該職缺的當前市場薪資範圍（可參考 104、1111、CakeResume、比薪水、Glassdoor、Levels.fyi、Blind 等）。
• 該公司在業界的薪酬信譽（如勞健保是否以實際薪資投保、年終獎金是否確實發放、加班費是否給付）。
• 該職缺的市場需求趨勢（是急徵職缺，還是長期掛在人力銀行的儲備缺）。

在解讀薪資數字之前，必須先判斷公司類型。公開的薪資區間不能直接等同於契約上的固定本薪或穩定入袋的金額。

公司類型分類（必填）：

將招募主體歸入最接近的一類，並給出信心水準：

公司類型	典型薪資可信度	辨識訊號
大型科技公司 / 上市櫃企業	高到中	公開發行、職級體系清晰、工程團隊規模大、招募流程規範
成長期新創 / 已募資新創	中	有募資或營收成長，薪資可能混合本薪、選擇權、獎金
早期新創 / 未獲利新創	中到低	團隊小、職務邊界模糊、選擇權承諾多、薪資級距不清
傳統產業 / 大型集團	中	HR 流程正式，固定薪資較穩定，但獎金可能浮動
外包 / 顧問 / 系統整合商 (SI)	中到低	專案制、駐點客戶端、稼動率壓力、專案獎金不穩定
本地中小企業 / 服務業	低	小公司、HR 不規範、常見「薪資面議」「待遇從優」寫法
業務 / 獎金驅動型公司	低，除非本薪寫清楚	OTE、獎金無上限、底薪加獎金、業績 KPI
獵頭 / 人力仲介職缺	低到中	第三方刊登，薪資可能是客戶預算而非最終 offer
政府 / 學研機構 / 法人	中到高	薪級或職等公開（如工研院、資策會、國研院），但市場競爭力可能偏低
開源社群 / 教育社群	中到低	社群型組織，由協會／基金會／學校／合作方承接，實際用人主體不清

如果品牌方與實際招募／簽約主體不同，優先按實際契約主體／用人主體分類，再說明品牌關係。例如某科技社群的職缺若由協會、學校、外包公司或合作方刊登，應依實際招募主體判斷，而不是只看品牌。公司類型不確定時，標記為 Unknown，薪資可信度預設採用保守等級：低。

薪資可信度（必填）：

先檢查 JD 本身是否有薪資／報酬資訊。若 JD 沒有任何公開的薪資數字，也沒有「薪資面議」「待遇從優」「依公司規定」「本薪＋績效獎金」「含全勤」「最高可達」等模糊報酬表述，本節在需求趨勢之後只輸出兩行：

• 公司類型： {類別或 Unknown} — {信心水準 ＋ 一個證據短語}
• 薪資可信度： {等級} — JD 未提供薪資／報酬資訊；跳過薪資組成拆解、詳細市場數據表與 HR 查證問題

台灣特別注意： 依《就業服務法》第 5 條，經常性薪資未達新臺幣 4 萬元的職缺必須公開薪資範圍。若一個明顯低於 4 萬的職缺卻寫「面議」，這本身就是一個負面訊號，應在此註記。

當 JD 明確寫出薪資數字，或僅出現「薪資面議」「待遇從優」「依公司規定」「本薪＋績效獎金」「含全勤」「最高可達」「上不封頂」等模糊報酬表述時，進入完整的薪資可信度路徑，並拆解以下五項：

• 公開薪資區間： JD 原文寫出的薪資，必須逐字保留。
• 可能的契約固定本薪： 對勞動契約中固定薪資的保守估計。
• 浮動／條件性現金組成： 績效獎金、全勤獎金、業績獎金、津貼、加班費、年終獎金、專案獎金等現金項目。
• 預估穩定現金收入： 大機率穩定發放的現金部分。除非在地資料足夠，否則預設以稅前口徑說明；不要把福利算進穩定現金。
• 非現金福利： 選擇權、勞健保、勞退提繳、伙食津貼、交通補助、教育訓練預算、設備等不等同於固定現金的福利。

可信度分級：

等級	意義
高	明確寫為固定本薪，或有公開薪級／多方一致的資料佐證
中	區間大致可信，但薪資組成未完全拆開
低	公開數字很可能包含績效、全勤、業績獎金、津貼或「最高可達」的部分
Unknown	沒有可用的薪資資料

遇到以下表述，除非固定本薪單獨寫清楚，否則預設按低可信處理：「薪資面議」「待遇從優」「依公司規定」「最高可達」「上不封頂」「本薪＋業績獎金」「含津貼」「含績效」「含全勤」「KPI 獎金」「保障年薪 14 個月（未載明本薪）」，或跨度異常大的薪資區間。

當 JD 明確寫出薪資數字，或出現模糊報酬表述時，必須給出 3–6 個 HR 查證問題，例如：

• 勞動契約上寫明的固定本薪是多少？
• 公開薪資是否包含績效獎金、全勤獎金、業績獎金、津貼、加班費或年終獎金？
• 「保障年薪 N 個月」是否白紙黑字寫進契約，還是只是慣例？
• 試用期薪資是否打折？勞健保與勞退是否以實際薪資投保（而非高薪低報）？
• 哪些組成是每月固定發放，哪些取決於出勤、KPI 或公司盈餘？
• 若包含選擇權或員工酬勞（分紅），既得期間、歷史發放紀錄與實際預期價值是多少？
• 是否為「責任制」？若是，該職務是否經勞動部核定公告適用勞基法第 84-1 條，並經地方主管機關核備？（多數軟體工程職務其實不適用）

當 JD 明確寫出薪資數字，或出現模糊報酬表述時，以表格形式呈現查到的資料並標明來源。如果除了 JD 原文之外找不到可靠資料，如實說明，切勿捏造。 除非來源明確支持，否則不要把徵才廣告上的薪資當成實際入袋。

---

維度 E — 針對性客製方案 (Customization Plan)

建立一個表格，列出為了最大化匹配度，建議對履歷與 LinkedIn 頁面進行的 Top 5 修改方案：

#	履歷區塊	目前敘述	建議修改為	修改原因
1	專業摘要	...	...	...
...	...	...	...	...

---

維度 F — 面試準備計畫 (Interview Plan)

依 JD 的具體要求，從求職者的工作經驗中篩選並重新包裝 6–10 個 STAR+R 故事（STAR ＋ Reflection／反思）：

#	對應 JD 需求	故事名稱	情境 (S)	任務 (T)	行動 (A)	結果 (R)	反思與總結 (Reflection)

在反思欄中，務必提煉出學到的核心教訓，或如果重來一次會怎麼改進。這對展現資深度至關重要——資淺的候選人只描述過程，資深的候選人能提煉方法論。

故事庫同步： 若存在 interview-prep/story-bank.md，檢查這些故事是否已在故事庫中。若不存在，將其附加進去，以便隨著評估逐步建立一個隨時可調用的「黃金面試故事庫」。

依原型包裝故事：

• FDE → 強調極限交付時程、應對客戶緊急多變的需求。
• SA → 強調架構取捨、技術選型背後的邏輯。
• PM → 強調指標驅動、產品取捨 (Trade-offs) 與業務成長。
• LLMOps → 強調指標最佳化、評測體系的建立、大型模型的線上成本控制。
• Agentic → 強調智能體幻覺控制、編排系統穩定性設計、人機協作的設計。
• Transformation → 強調組織落地率、人員接受度、流程改造效率。

同時包含：

• 核心作品展示建議：建議求職者在面試中展示哪一個特定作品，以及展示的側重點。
• 防線陷阱問答：針對 JD 潛在的痛點或求職者履歷上的弱點（例如「為什麼離職」、「如何看待加班」、「可以接受責任制嗎」），設計高情商的擬答。

---

維度 G — 職缺真實性評估 (Posting Legitimacy)

深入分析職缺的刊登狀態與外圍訊號，判斷它是否為真正在招募的活躍職缺，幫助求職者避開只掛不招的「幽靈職缺」或純粹蒐集履歷的假管道。

台灣市場特有訊號分析：

1. 刊登時間與更新頻率（透過 Playwright 網頁快照或 WebSearch 輔助）：
   • 104／1111 等平台上的「更新日期」「應徵人數」「急徵」標籤。
   • 職缺首次刊登日期與最近一次更新日期（掛超過 3 個月且頻繁更新的職缺要提高警覺）。
   • 同一家公司是否長期同時掛著數十個相似職缺（常見於人力仲介或儲備性掛單）。
2. 職缺描述的具體與詳實程度：
   • 工作內容是否具體（有沒有提到公司具體的產品線或業務細節）。
   • 應徵條件是否寫實（例如同時要求「精通 LangChain」與「10 年以上大型語言模型經驗」這種時間軸矛盾的條件）。
   • 薪資區間的張力（例如「35,000 – 120,000」這種跨度過大的區間，通常代表實際給薪會偏低，或職缺只是虛掛）。
3. 外圍招募訊號（透過 2–3 次 WebSearch 查詢）：
   • 查詢 "{公司名稱}" 裁員 2026 或 "{公司名稱}" 勞資爭議。
   • 查詢該公司是否列在勞動部「違反勞動法令事業單位查詢系統」的裁罰名單上（這是台灣市場最直接、最公開的雇主風險訊號）。
   • 查詢該公司近期的募資狀態、財報或經營危機報導（上市櫃公司可查公開資訊觀測站）。
   • 若近期發生大規模裁員，評估該職缺所屬部門是否受到波及。
4. 歷史重複度偵測（透過 scan-history.tsv）：
   • 檢查該公司是否在過去 90 天內重複刊登相同職能但不同連結的職缺。

輸出評級：

• 高信心 (High Confidence) — 多個訊號互相印證，職缺確實處於急需且活躍的招募狀態。
• 審慎推進 (Proceed with Caution) — 存在部分混合訊號（例如公司剛裁員，但該產品線是新設立的成長重點），建議投遞前先透過人脈確認。
• 疑似虛假／已過期 (Suspicious) — 存在大量幽靈職缺指標，建議不要貿然花大量時間客製履歷。

---

評估後處理流程 (Post-evaluation)

在產生 Block A–G 的評估結果之後，必須無條件執行以下兩個步驟：

1. 儲存報告 markdown 檔案

將完整的評估內容儲存到本機路徑 reports/{###}-{company-slug}-{YYYY-MM-DD}.md。

• {###} = 依序遞增的 3 位數字（如 001, 002）
• {company-slug} = 公司英文名或拼音縮寫，全小寫，空格用連字號 - 取代
• {YYYY-MM-DD} = 評估當天的日期

報告檔案格式模板：

# 評估報告: {公司名稱} — {職缺名稱}

**Date:** {YYYY-MM-DD}
**URL:** {職缺原連結}
**Archetype:** {偵測到的原型分類}
**Score:** {X/5}
**Legitimacy:** {高信心 | 審慎推進 | 疑似虛假}
**PDF:** {CV 產生狀態，如 ❌ 或 ✅}

---

## A) 職缺概覽
(此處填入維度 A 表格與 TL;DR)

## B) 履歷匹配分析
(此處填入維度 B 對照表及能力落差彌補策略)

## C) 職級判斷與求職策略
(此處填入維度 C 的分析與話術)

## D) 薪酬競爭力與市場需求
(此處填入維度 D 的薪資資料及參考來源)

## E) 針對性客製方案
(此處填入維度 E 的履歷修改表格)

## F) 面試準備計畫
(此處填入維度 F 的 STAR 故事表及防線問答)

## G) 職缺真實性評估
(此處填入維度 G 的詳細訊號分析)

## H) 開放式問題擬答草稿
(僅在綜合評分 >= 4.5 且應徵表單有問答框時產生)

---

## ATS 關鍵字擷取
(列出 15–20 個從該 JD 中擷取的高頻核心技術／業務關鍵字，用於履歷最佳化)

2. 登錄到 Tracker 紀錄簿

在 data/applications.md 的末尾追加這筆紀錄：

• 依序遞增的 ID 編號
• 日期
• 公司名稱
• 職缺名稱
• 評分（如 4.2/5）
• 狀態（一律填寫為 Evaluated）
• PDF 狀態（預設為 ❌）
• 報告連結：根目錄相對路徑 [###](reports/###-company-YYYY-MM-DD.md)（注意：合併腳本會自動格式化）