Files
santifer--career-ops/modes/zh-TW/apply.md
T
wehub-resource-sync d083df1fdb
CodeQL Analysis / Analyze (javascript-typescript) (push) Failing after 2s
Web CI / web typecheck + build (push) Failing after 1s
Release Please / release-please (push) Failing after 1s
CodeQL Analysis / Analyze (go) (push) Failing after 16s
chore: import upstream snapshot with attribution
2026-07-13 12:02:43 +08:00

5.6 KiB
Raw Blame History

模式: apply — 即時表單填寫助理

當求職者在 Chrome 瀏覽器中填寫職缺投遞表單時,這個即時助理能讀取當前畫面內容、調出該職缺的歷史評估報告,並為表單中每一個開放式或選擇式問題產生個人化的高品質回答草稿。

執行需求

  • 首選 Playwright 顯示模式:在這個模式下,求職者能直接看到瀏覽器視窗,而 AI 助理能與表單頁面進行元素互動與狀態擷取。
  • 不使用 Playwright 時:求職者需要提供包含表單問題的截圖,或手動把表單問題複製貼上給助理。

即時工作流程

1. 擷取 (DETECT)    → 讀取當前 Chrome 作用中分頁(截圖/URL/網頁標題)
2. 辨識 (IDENTIFY)  → 從頁面中擷取公司名稱與職缺名稱
3. 搜尋 (SEARCH)    → 比對 reports/ 目錄下已儲存的評估報告
4. 載入 (LOAD)      → 讀取對應的評估報告及 H 區的擬答草稿(若存在)
5. 校準 (COMPARE)   → 比對畫面上的職缺是否與先前評估的完全一致。若有變動,提出提示
6. 解析 (ANALYZE)   → 辨識頁面上所有可見的表單問題輸入框
7. 產生 (GENERATE)  → 結合報告脈絡與履歷 cv.md,為每個問題產生客製草稿
8. 呈現 (PRESENT)   → 輸出可直接複製貼上的格式化文字

步驟 1 — 擷取當前職缺表單

使用 Playwright:對作用中頁面進行快照截圖,並讀取網頁標題、URL 以及頁面主體文字。

不使用 Playwright:請求職者執行以下其中一項:

  • 傳送當前表單頁面的螢幕截圖(Read 工具能辨識並分析圖片)。
  • 手動複製表單上的問題並貼進對話框。
  • 直接說出公司名稱與職缺名稱,讓助理從本機歷史紀錄中搜尋。

步驟 2 — 搜尋歷史報告

  1. 從畫面或輸入的資訊中擷取公司名稱與職缺名稱。
  2. reports/ 目錄下搜尋對應的評估報告檔案(執行不分大小寫的模糊搜尋)。
  3. 若比對成功,載入完整的評估報告內容。
  4. 檢查報告中是否有「維度 H(開放式問題擬答草稿)」,若有,以它作為回答的基礎模板。
  5. 若找不到任何歷史報告,告知求職者,並詢問是否要針對這個連結快速執行一次 auto-pipeline 自動評估流程。

步驟 3 — 檢核職缺一致性

如果表單上顯示的職缺細節(如職級、所屬部門)與歷史報告有出入:

  • 向求職者提出提示:例如:「偵測到當前的職缺已從 [X] 變成 [Y]。需要我重新做一次快速評估,還是直接在現有話術的基礎上微調,適配新職缺?」
  • 若選擇微調適配:直接依新職缺名稱調整用詞,不重新評分。
  • 若選擇重新評估:執行完整的 A–G 評估,產生新報告並覆蓋舊報告。
  • 更新 Tracker:若有需要,在 applications.md 中同步更新該列紀錄的職缺名稱。

步驟 4 — 分析表單問答框

定位並解析當前頁面上所有的表單輸入項目:

  • 開放式問答框(如「你為什麼想加入我們?」、「描述一次你解決棘手技術問題的經驗」等)。
  • 下拉選單(如求職管道、是否需要工作簽證支援等)。
  • 單選/複選框(如是否接受出差、地點偏好等)。
  • 期望薪資欄(期望區間、報酬結構)。
  • 檔案上傳欄(上傳履歷 PDF、求職信 PDF)。

對每個問題進行歸類:

  • 維度 H 中已有擬答 → 取出並依當前表單的細部要求潤飾。
  • 新問題 → 依報告脈絡分析、STAR 故事及 cv.md 的量化指標現場撰寫。

步驟 5 — 產生客製答案

產生每個問題的回答草稿時,必須嚴格遵守以下原則:

  1. 立足報告脈絡:融入維度 B 的量化成果佐證與維度 F 的 STAR 面試故事。
  2. 調和語氣風格:若 _profile.md 中已設定求職者的 ## 寫作風格,必須以求職者的口吻進行語氣擬合。
  3. 雙向奔赴的語氣:回答既表現出對這個職缺的高度興趣,又透過具體指標展現解決對方核心痛點的能力。
  4. 細節決定成敗:在段落中提及 JD 裡寫到的具體系統架構或商業模式,證明自己認真研究過這個職缺。

輸出格式範例:

## [公司名稱] — [職缺名稱] 表單擬答草稿

關聯報告: #NNN | 綜合評分: X.X/5 | 偵測到的個人檔案類型: [類型]

---

### 問題 1: [表單上的原始問題描述]
> [為求職者準備、可無縫複製貼上的精修中文/英文回答]

### 問題 2: [表單上的下一個原始問題描述]
> [回答]

...

---

投遞前提醒:
- [此處填入需要求職者手動確認的個人資訊,例如期望薪資、最快到職日等]
- [提醒求職者在此處上傳先前客製好的履歷 PDF]

步驟 6 — 投遞後動作

當求職者確認已經成功按下「送出應徵/投遞」後,執行以下收尾與建檔工作:

  1. 使用規範的 CLI 將該職缺狀態更新為 Appliednode set-status.mjs <report#> Applied(不要手動編輯 data/applications.md 表格)。
  2. 將最終實際送出的表單回答歸檔,並更新到該報告的維度 H 區塊中,方便後續面試對照。
  3. 建議下一步行動:引導求職者使用 /career-ops contacto 指令,產生直達 LinkedIn 招募負責人的開發話術。

長表單捲動處理

如果表單問題較多,單次截圖無法完整涵蓋:

  • 指導求職者向下捲動頁面,並傳送下一部分的截圖或文字。
  • 採用迭代處理模式,逐屏辨識並記錄問答項目,直到表單所有問題處理完畢。