把崗位檢索、公司研究、JD 分析、定製簡歷、Cover Letter 和投遞確認連成一條線。
JobsFlow 不是“幫你寫一份簡歷”的工具，而是一個幫你搜崗位，做材料，整理投遞資訊的本地優先求職執行系統。
你的回饋，開發者會直接收到
- 统一控制入口：
scan / push / materials / audit / format / apply / base / intent / archive / sync现在都先经过统一 workflow gateway，再调用原有业务适配器；模型不能自行切换旧入口或绕过状态机。 - 规则真正进入运行时：SOP 规则不只写在
AGENTS.md或 README，而是登记在.sopcontrol/，由 JobsFlow adapter 在动作前检查、动作后写入 receipt；缺少确认、能力凭证、当前输入或必要产物时会 fail-closed。 - 材料链固定：材料制作绑定
materials-vnext-1，旧材料入口拒绝继续；基础版 → 有界 JD 定制 → CV/CL 内容审计 → DOCX/PDF 格式门的顺序由系统控制。 - 跨模型可接手：项目身份、规则摘要、任务状态和证据记录可在不同模型、Harness 和 Worktree 间复用；模型切换不会重新发明一套流程。
- 发布门：SOP Control 的规则、测试命令、CI 固定版本和 pre-push gate 已接入；控制面证据与私人求职运行数据分离，不把简历、JD、cookie、Google 凭据或运行台账发布到 GitHub。
求職難，往往不是「找不到連結」，而是整條鏈路運營不起來：
| 痛點 | 常見問題 | JobsFlow 怎麼做 |
|---|---|---|
| 崗位太多 | 瀏覽器標籤、聊天記錄堆成山 | 只在你設定的目標與地點範圍裡搜 |
| 不知道先投誰 | 憑感覺亂投 | 兩段評分 + 六維打分，優先級看得見 |
| 每個崗位都像重做一次 | 反覆改簡歷、求職信，格式也不統一 | 按職業方向先做基礎版，再針對具體 JD 出一整套 |
| 進度記不住 | 「這個投了沒？」 | 結構化臺帳（分級、今日新到、狀態、已投遞變色） |
| 錯過新崗位 | 想起來才搜一次 | 臨時模式：只掃上次之後的新崗，不重複不遺漏 |
| JD 重複抓取 | 評分時拉了一遍，做材料又拉一遍 | JD 緩存：評分時抓的全文按 URL 存下來，材料製作直接複用 |
| 普通工具 | JobsFlow |
|---|---|
| 看到 JD 就直接生成材料 | 先檢查薪資、語言、工作權、資格和附件要求 |
| 只改關鍵詞 | 研究公司性質、主營業務和崗位上下文 |
| 一份簡歷套所有職位 | 先做職業方向基礎版，再做單崗位差異化定製 |
| 模型沒看懂就靜默跳過 | Schema、評分門檻、證據映射和覆蓋度檢查強制執行 |
| 默認某個行業模板 | 根據你的簡歷、意向和行業動態生成，不把法律/合規當默認 |
| 自動替你提交 | 你審核材料，最後一步始終由你確認 |
一句話： 少內耗，多完成投遞。
- 少投錯，也少漏掉：初評按資訊質量調度，完整 JD 決定最終分數；資訊不足的崗位會明確待審。
- 寫得更像這個崗位：結合公司性質、主營業務、崗位上下文和 JD 重點，分別定製簡歷與求職信。
- 模型不聰明也不容易漏：薪資、語言、工作權、資格等硬要求由確定性 preflight 和質量門檻兜底。
- 始終由你做決定：系統準備材料和確認清單，但不會替你自動提交申請。
JobsFlow 不是讓模型自由串聯一堆腳本，而是把業務 SOP 固定為一條有邊界的流水線：
| 環節 | 固定標準 | 用戶如何使用 | 主要輸出 | 與下一環節的關係 |
|---|---|---|---|---|
/setup / /intent |
先確認簡歷事實、求職意向、行業範圍、語言/薪資/地點限制和掃描偏好 | 首次運行 setup；方向變化時用 intent 預覽→確認 | 私有畫像、搜索詞、評分配置、lane 映射 | 為掃描和材料提供唯一畫像來源 |
/scan |
緩存優先；初評只做深取調度；摘要不足和灰區職位進入救援 | 臨時、3 小時、daily 或自定義深度掃描 | 職位列表、lane、層級預覽、初/深評分、JD 狀態、assessment | 只展示，不入表、不生成材料、不分配永久編號 |
/push |
先生成不可寫 proposal，再由用戶確認；編號只在確認邊界分配 | 先看預覽，可按 URL/scan key 選擇，再確認 | 本地 ledger、CSV/可選 Sheets 投影、永久 job ID、綁定 package | 只有確認入表的職位才能進入 materials |
/materials |
CV 與 CL 各自從 lane 基礎版增量定製；先內容審計，再渲染 | 指定一個已入表編號 | canonical CV/CL、獨立審計記錄、DOCX、PDF、固定 Email | 內容和格式門全部通過後才可 apply |
/apply |
只做完整性、當前性和門禁檢查，不自動提交 | 用戶查看材料後確認下一步 | apply_ready 與投遞前檢查清單 |
最終點擊/提交仍由用戶完成 |
總流程和副作用邊界如下：
用戶簡歷 + 求職意向
│
▼
setup / intent ──→ 已確認畫像、搜索詞、lane 規則
│
▼
scan：檢索 → 初評調度 → JD 緩存/深取 → 深評 → lane 鎖定
│ （預覽：無永久編號、無寫表）
▼
push preview ──→ 用戶確認 ──→ ledger/CSV/Sheets + job ID + package
│
▼
materials：凍結職位輸入 + 基礎版 CV/CL
→ plan → bounded JD delta → canonical 完整 CV/CL
→ 獨立 CV/CL 內容審計 → lane-master DOCX → PDF → 格式門
│
▼
apply（只等待用戶提交）
基礎版不是一張空模板，而是按 lane 預先核對過的完整內容母版。具體職位只提交少量
rewrite / reorder / merge / add 操作，系統保留沒有被提及的 block，再編譯完整材料：
完整 lane 基礎版 CV/CL（已做事實核對）
+ 當前 JD 的少量定製 delta
─────────────────────────────
= 完整 canonical CV/CL
→ 子審計只重點看 delta，全文只做一次兜底掃描
→ 系統統一渲染，不讓模型重做版式
這樣把重複勞動前置到基礎版製作階段，避免每個職位都從零重寫，也能讓能力相對有限的 模型在固定 schema 和門禁內完成高質量定製。
git clone https://github.com/mixxmax/jobsflow.git
cd jobsflowPYTHON_BIN="$(command -v python3.12 || command -v python3.11 || command -v python3)"
"$PYTHON_BIN" -c 'import sys; assert sys.version_info >= (3, 10), "JobsFlow requires Python 3.10+"'
"$PYTHON_BIN" -m venv .venv
source .venv/bin/activate
python3 -m pip install --require-hashes -r requirements.lock
python3 setup.py --doctor换模型或换执行平台时，先运行只读检查：
python3 -m tools.workflow doctor
python3 -m tools.workflow doctor --strict-materials它会把“环境可用”和“材料基础版已激活”分开报告；缺少基础版时只允许继续检索，
不会让 /materials 静默使用空白模板。
跟你的 AI 助手說：
/setup ~/Documents/my-cv
系統會：讀簡歷 → 問你想找什麼類型的工作 → 詢問掃描深度（節能/平衡/廣覆蓋）和保留偏好（寬鬆/標準/精選）→ 生成配置（搜尋關鍵詞、追蹤表頭、方向字母）。然後問：
你想先做什麼？
先做基礎版簡歷（按方向分 A-F 版本，可選 G 能力擴展）
還是先開始檢索新職位？
- 選 先做基礎版 → 系統引導你按方向建立 A-F 基礎簡歷版本（需要時可啟用 G 能力擴展）
- 選 先檢索 → 直接掃新職位
沒有 AI 助手？終端運行
python3 setup.py --resume-folder ~/Documents/my-cv也可以。
產品線不把“基礎版簡歷”當成模型自由寫的一次性文本。/setup 會為每個 lane 建立私有
base_requests/<lane>/request.json，當前模型只需按照其中的固定 schema 填寫
response.json；主機再做事实锚点、数字、必需 section、STAR 最低结构、占位符与负面自述检查，
并用产品自带的匿名格式契约生成 DOCX。
python3 -m tools.workflow base status
python3 -m tools.workflow base init --lane A
python3 -m tools.workflow base generate --lane A \
--content JobSearch_2026/00_Profile/base_requests/A/response.json
python3 -m tools.workflow base confirm --lane A # 预览
python3 -m tools.workflow base confirm --lane A --confirm未确认的 draft_* 不会被材料链使用；确认后才成为 master_*.docx 和
cl_master_*.docx。CV 与 Cover Letter 分别从各自的基础版生成，具体岗位只做有限增量定制，
不会让模型从空白文档自由排版。格式契约保存在
templates/base_format_contract.json，个人内容仍只在本地实例保存。
/scan # 掃新職位
/push # 先預覽；用戶確認 proposal 後才寫入（可用 --local-only）
/materials 編號 # 給某個崗位做材料（編號從追蹤表中來）
/apply 編號 # 檢查材料並進入投遞確認（不會自動提交）
在 AI 對話裡直接說：
| 你想做的事 | 說 |
|---|---|
| 掃新職位 | /scan |
| 掃最近 3 小時 | /scan 3 |
| 掃最近 24 小時 | /scan daily |
| 預覽入表內容 | /push |
| 只預覽選定崗位 | /push --select <url-or-scan-id>,<...> |
| 確認後寫入 Google Sheets | /push --confirm <proposal-id> |
| 確認後只寫本地 CSV 臺帳 | /push --local-only --confirm <proposal-id> |
| 調低日常網絡深取成本 | /intent scan-depth 節能，確認後 /intent confirm |
| 多看一些 3.0+ 崗位 | /intent retention 寬鬆，確認後 /intent confirm |
| 只保留 3.5+ 崗位 | /intent retention 精選，確認後 /intent confirm |
| 給某個崗位做材料 | /materials <編號> <方向> |
| 深度分析某個 LinkedIn 崗 | 「深度分析這個崗位 」 |
簡歷/意向 → setup / intent → 已確認畫像、搜索詞、權重與 lane 映射
│
base request → 結構化基礎 CV/CL → 預覽確認激活
│
▼
scan：檢索 → 初評調度 → 緩存優先深取 → 深評 → lane 按 URL 鎖定
│
預覽結果（無永久編號、無寫表）
│
push preview → 用戶確認 → 永久 job ID + 本地 ledger + CSV/Sheets 投影
│
▼
materials：lane 基礎版 CV/CL + 當前 JD delta → canonical → CV/CL 子審計
│
lane-master DOCX → PDF → 頁數/文字層/文件名/元數據門
│
▼
apply_ready（仍由用戶最終提交）
這些能力現在都屬於主流程契約，而不是模型記憶：temp_two_pass.sh 只是兼容入口，
實際掃描由 workflow gateway 執行。每輪掃描建立一個官方 scan_runs/<run-id>/run.json，綁定掃描窗口、
評分產物雜湊、語義任務狀態和刷新游標；只有評分產物驗證成功後才提交游標。/push 若未指定
run_id，只會解析最新官方運行，不會把歷史 temp/daily 狀態當成當前結果。運行記錄同時保存計劃
請求、去重請求、門戶錯誤、初評淘汰、暫定行和深取結果，讓「少抓了什麼」可以被定位。
重複崗位過濾也在掃描層固定執行：臨時檢索只對比最近三次臨時檢索的身份，預覽/日檢索只對比本次時間窗口；不會為此重讀整張台賬，且即使門戶部分失敗，也會記住已成功看到的崗位而不立即重複展示。
台帳方面，本地 ledger 同時是崗位身份和編號的權威來源；CSV 和 Google Sheets 是可重放的投影。
同一批已確認職位可以向多個後端分別建立 proposal，而不會因某一個空投影重新分配 ID。push 回報
backend_resolution；auto 找不到完整 Google 配置時會明確提示並降級到本地 CSV。私人部署可在
JobSearch_2026/00_Profile/tracker_backend.json 保存後端選擇、表格 ID 和憑據路徑，憑據本身不進入產品倉庫。
JobsDB 仍遵守緩存優先、受控人工恢復和門戶熔斷：Cloudflare/WAF 不會觸發無限重試；日常 Chrome 未暴露 CDP 時，系統輸出不含 cookie 的人工恢復交接記錄和可重跑提示，未完成驗證不會被冒充成成功。 相同門戶請求會在掃描層去重，但仍保留查詢別名和頁碼，以便追蹤召回來源。這些診斷與降級只影響私人 運行實例，不會把 token、cookie 或個人資料帶入公開產品。
JobsFlow 不靠關鍵詞堆砌，而是把 JD 要求 → 已核實證據 → CV / Cover Letter / 申請郵件 連成一條可追溯鏈路：先判斷哪些要求有真實證據，再把最相關的證據放到模型和 ATS 最容易讀取的位置。這樣做的目標是讓真實能力被正確理解，不是偽造經歷、操縱 ATS 或承諾固定加分。
在深度 JD 評分中，簡歷匹配還可以進入 Agent-in-the-loop 語義匹配：系統把“事實基線”和“能力上沿”分開提交給當前執行任務的 agent，由 agent 判斷畫像與 JD 核心職責的語義關係。/setup 會詢問畫像上沿幅度：低（保守）、中（平衡）或高（擴展）；這個選擇只調節可遷移能力的判斷範圍和分數上限，任何檔位都不能把潛力寫成已做過的經歷。語義任務未完成時，掃描預覽會明確標記 pending_fallback、記錄待處理數，並將關鍵詞回退限制在 4.0 以內；正式 /push 默認不會把這類行寫入臺帳，需完成任務並重評後再推送。
用戶畫像不是機械的“簡歷關鍵詞 = 崗位關鍵詞”死對比，而是由簡歷事實、求職意向、行業常見要求和用戶選擇的上沿幅度共同形成。畫像生成後需要用戶確認；畫像不會隨着某一個職位偷偷改變。
低頻：/setup 或 /intent confirm
簡歷事實 + 求職意向 + 行業快查
│
▼
[LLM ① 生成畫像] ──→ 用戶確認 ──→ facts_anchor / capability_upper
│
每次深評：掃描後先查 URL 緩存（命中 = 0 網絡請求） │
未命中 → LinkedIn CLI → JobsDB 主 Chrome CDP 兜底 → CT 不開瀏覽器 → teaser 兜底
│ │
└────────── 已緩存 JD ──────┘
│
┌───────────┴───────────┐
▼ ▼
[LLM ② 職位定性] [LLM ③ 簡歷匹配]
公司性質 + 職位類型 direct / transferable /
lane + company_brief upper_only / none + 分數
└───────────┬───────────┘
▼
確定性封頂、資格檢查、lane/層級預覽
│
用戶查看後明確確認入表
│
分配永久編號並寫入臺帳
上述掃描介入中，②和③都只消費掃描階段抓到的緩存 JD，不重新打開門戶；能力相對有限的模型也可以按 list → show → complete 的結構化任務逐項執行，遺漏或未完成時自動回退到規則結果。公司簡介會在有 agent 結論時寫入「公司簡介」列，否則明確標記為待核實。
材料製作還有一個獨立的受控入口：主模型只提交當前 JD 的結構化定製 delta，系統合成完整 canonical CV/CL 後自動啟動獨立上下文子 Agent。子 Agent 只審 CV/CL 的 JD 映射、STAR、LLMO 位置、職位/雇主邊界、語法和殘句，不審 Email、DOCX、PDF 或版式；發現 P0/P1 時只把定位清楚 的 finding 交回主模型修訂，最多三次並對重複問題熔斷。內容通過後 Email 由宿主固定生成， DOCX/PDF 由統一 lane-master renderer 生成，模型不能繞過這些入口。
- URL-keyed JD 緩存默認保留 60 天，緩存文件保存全文、來源、字符數和抓取時間；評分、材料製作和重評優先複用緩存。
- 初評 3.3 是內部直接調度線，不是用戶的最終取捨線；摘要缺失/過短、已有緩存或落在灰區的崗位會被救援。
- 掃描深度把未命中緩存的網絡深取控制在節能約 10、平衡約 20、廣覆蓋約 40 個；緩存讀取不佔預算。沒拿到完整 JD 的崗位會進入
待審-JD不足，/scan temp仍只掃上次之後的新崗。 - 最終保留偏好由用戶選擇寬鬆 3.0、標準 3.3 或精選 3.5；它只重新篩選已保存的深評分數，不觸發新的網絡抓取。
- LinkedIn 優先使用 CLI detail；JobsDB 詳情只使用主 Chrome 的可見 CDP 會話（人工驗證一次後本輪串行復用）；CTgoodjobs 默認不打開瀏覽器。需要時可設置
PORTAL_JD_BROWSER=0完全關閉瀏覽器深取。 - PDF 繼續使用內容哈希緩存；未改變的 DOCX 不重複轉換。
JobsFlow 不把所有東西塞進表格或聊天記錄，而是用兩層結構管理求職：文件夾管理材料和證據，CSV/Google Sheets 管理崗位和狀態。
JobSearch_2026/
├── 00_Profile/ # 簡歷事實、求職意向、搜尋配置
├── 01_Masters/ # 按方向保存基礎 CV / Cover Letter（A-F；可選 G 能力擴展）
│ └── <方向>/<層級>/<崗位編號_公司>/
│ ├── jd_full.md # 完整 JD
│ ├── company_research.md # 公司性質、主營業務、來源
│ ├── application_preflight.json
│ ├── tailor_plan.md # JD → 候選人證據映射
│ ├── job_manifest.json # 生成字段、人工覆蓋和輸入指紋（私有）
│ ├── materials_validation.md # 投遞前統一驗證報告
│ └── CV / Cover Letter / PDF
├── 02_Tracker/ # CSV 臺帳、JD 緩存、掃描結果
└── 03_Applications/ # 可選的最終投遞歸檔
| 內容 | 文件夾 | CSV / Google Sheets |
|---|---|---|
| JD、公司研究、證據映射 | ✓ | — |
| CV、Cover Letter、PDF | ✓ | — |
| 匹配分、優先級、投遞狀態 | — | ✓ |
| 材料版本與修改記錄 | ✓ | 可記錄連結 |
掃描預覽只提供職位、lane、層級、分數、URL 和 JD 狀態，不產生永久崗位編號。
只有用戶確認 /push proposal 後，系統才分配崗位編號並把臺帳行寫入本地 CSV
或 Google Sheets。每個已入表的崗位編號再把臺帳行和材料包對應起來；Google
Sheets 只是可選的臺帳同步，不是 CV 或 Cover Letter 的存儲位置。
材料包裡的 job_manifest.json 是這條交接鏈的私有契約：系統自動生成職位名、JD 關鍵詞、文件名和依賴指紋；你確認過的措辭可以放在 overrides 中，批量重跑不會覆蓋。JD、畫像、公司研究或方向發生真實變化時，舊 CV/Cover Letter 會被標記為待重做，而不是靜默沿用。完成材料後可運行 python3 -m tools.job_materials validate --package <路徑>，統一檢查獵頭名稱外泄、目錄層級、英文材料中文殘留、殘缺句、公司名和求職信頁數。
掃描時只分配 lane（A–G）和匹配層級；檢索結果不會出現永久編號。 用戶確認入表後，系統才會為該崗位生成壓縮了三層資訊的正式編號：
C0-005
││ │
││ └── 序號：該 lane 共享連續三位數（001 起，接續已有最大號）
│└───── 層級：0=核心 / 1=一級 / 2=二級 / 3=剔除
└────── 方向：A-G，由 setup 根據你的職業自動生成
方向字母（僅作結構示例；實際內容由 setup 根據簡歷、意向和行業生成）：
┌─────┬────────────────────┬──────────────────────────┐
│ A │ 產品運營 │ product operations │
│ B │ 商業運營 │ business operations │
│ C │ 項目管理 │ program management │
│ D │ 數據運營 │ data operations │
│ E │ 客戶運營 │ customer operations │
│ F │ 相鄰機會 │ adjacent opportunities │
│ G │ 可選創新/科技能力線 │ optional innovation/tech │
└─────┴────────────────────┴──────────────────────────┘
層級數字（通用，不隨職業變化）：
┌─────┬──────┬──────────────────────────────────────┐
│ 0 │ 核心 │ 高度匹配（分數 ≥ 3.5）-> 優先投遞 │
│ 1 │ 一級 │ 中上匹配（分數 ≥ 3.3）-> 值得認真評估 │
│ 2 │ 二級 │ 中等匹配（分數 ≥ 2.5）-> 供給稀缺時考慮 │
│ 3 │ 剔除 │ 不匹配 -> 不入庫 │
└─────┴──────┴──────────────────────────────────────┘
示例：
C0-005 = 項目管理方向 · 核心匹配 · 第 5 號
A2-012 = 產品運營方向 · 二級匹配 · 第 12 號
B1-003 = 商業運營方向 · 一級匹配 · 第 3 號
（層級 3 的預覽行不會進入確認入表，也不會分配正式編號）
| 來源 | 崗位檢索 | 深度 JD | 說明 |
|---|---|---|---|
| ✓ | ✓ | 優先使用深度 JD；已抓取內容可由材料流程複用 | |
| JobsDB | ✓ | 部分 | 結構化資訊可直接使用；定製材料建議粘貼 JD 全文 |
| CTgoodjobs | ✓ | 部分 | 保持結構化/緩存路徑；定製材料建議粘貼 JD 全文；公開倉庫不攜帶任何個人 token |
| FreeHire | ✓ | 手動 | 作為額外崗位來源；可按崗位標識查詢詳情 |
JobsDB 是當前唯一需要瀏覽器深取兜底的主要門戶，處理順序固定為：
- 先按 URL 查 JD 緩存；緩存有效時不打開瀏覽器，也不消耗本輪深取預算。
- 緩存沒有全文時，先走受控的主 Chrome CDP detail 請求；遇到 WAF、Cloudflare、429 或空殼頁不無限重試，
連續挑戰會打開門戶熔斷，後續職位明確標記
paste_needed/待審-JD不足。 - 在私人運行實例中，系統最多發起一次人工恢復：只在用戶自己的日常 Google Chrome 中打開驗證頁， 用戶在同一個真實瀏覽器窗口中點擊一次 Cloudflare 驗證。驗證通過後，系統復用同一個已通過 CDP 認證的 Chrome context 順序抓取後續 JobsDB JD，並把經結構校驗的全文寫入共享緩存。
- 該過程不是無頭瀏覽器驗證，也不復制 cookie 到第二個瀏覽器；不得啟動新的
--user-data-dir或 隔離 profile。驗證未通過、超時、429 或內容未 驗證都不會關閉熔斷。瀏覽器會話、cookie 和個人 token 永遠不進入 GitHub。
這是唯一的 JobsDB 全文入口：portal_jd_browser.py、portal_jd_cdp.py 直接運行會被
jobsdb_gateway_only 阻斷；JobsDB Bun detail --teaser-only 只提供結構化摘要，不能替代
全文抓取。新模型或新 harness 不得自行設置內部 gateway 標記，也不得另起瀏覽器。
Chrome 136+ 的遠端調試開關模式可能讓 /json/version 返回 404，但仍提供
/devtools/browser 的 WebSocket；這是受支持的主 Chrome 路徑。網關只在正式掃描中
建立一次連接並用 Browser.getVersion 驗證，不會因 HTTP 404 反覆探測或改用無頭瀏覽器。
公開產品代碼只提供這套受控接口和安全默認值；私人運行實例才啟用用戶 Chrome 的人工恢復配置。 JobsDB 的處理不會自動生成材料、不會自動入表，也不會自動投遞。
瀏覽器自動化是結構化接口和緩存之後的後備路徑，並且不會在掃描時自動生成材料或提交申請。 Google Sheets 是可選的投遞臺帳同步方式；不啟用時可使用本地 CSV。 LinkedIn 可按用戶指定地點檢索；JobsDB 與 CTgoodjobs 的當前接入面向香港市場；FreeHire 覆蓋多地，但篩選能力目前更偏技術崗位。
痛點： 各種產品逼你從零填表，明明簡歷裡都有。
怎麼解決： 把已有 CV/簡歷放在一個文件夾裡，跟你的 AI 助手說 /setup ~/Documents/my-cv。它會讀完簡歷、問你「你想找什麼類型的工作」、自動生成搜尋配置、表頭、評分權重。你全程在對話裡完成。
完成 /setup 後，可以用 /intent add ... 增加方向，或用 /intent replace ... 替換檢索範圍；也可以用 /intent scan-depth 節能|平衡|廣覆蓋 修改抓取成本，用 /intent retention 寬鬆|標準|精選 修改最終清單取捨。所有修改都先生成預覽，只有用戶明確執行 /intent confirm 後才寫入私有配置。保留偏好變化只重篩已有深評結果，不重新打開門戶；歷史臺帳和已生成材料不會被悄悄改寫。
普通聊天中隨口提到的新想法不會自動改變檢索範圍；不明確是“增加”還是“替換”時，助手會先複述並確認。
痛點： 合規崗和產品崗共用一份「萬金油」簡歷，怎麼看都只沾一點邊。
怎麼解決： 按崗位類型做多套基礎版。每套從你真實經歷裡挑不同側重。基礎版上的表述會對照原始材料做事實核對，不是「AI 隨口一編」。
痛點： 關鍵詞一開，噪音崗位淹沒你。
怎麼解決： 搜尋只在你的範圍內跑。支持 LinkedIn、JobsDB、CTgoodjobs 與 FreeHire。新職位成批進表，一眼能看清。
痛點： 一個說不清的「匹配分」，你不敢信。
怎麼解決： 分兩關--
| 關卡 | 做什麼 | 不做什麼 |
|---|---|---|
| 初評 | 用標題+摘要確定深讀優先級；內部 3.3 直接進入 | 不把標題分數當最終結論，也不要求用戶調技術 gate |
| 救援 | 摘要缺失/過短、已有緩存或灰區崗位繼續進入 | 不因門戶卡片資訊少而靜默淘汰 |
| 掃描深度 | 節能約 10 / 平衡約 20 / 廣覆蓋約 40 個網絡深取 | 緩存命中不佔預算；成本不由最終分數線控制 |
| 深評 | 先讀 URL 緩存，再在預算內拉完整 JD 並保存分數 | 不因用戶改變保留偏好而重新抓取 |
| 入表/待審 | 用戶選擇寬鬆 3.0 / 標準 3.3 / 精選 3.5；未取到 JD 標記 待審-JD不足 |
不把 provisional 當最終排名，也不自動做材料 |
每次掃描會分別展示初評分佈和完整 JD 深評分佈（<3.0、3.0–3.3、
3.3–3.5、3.5+），並報告緩存命中、網絡深取、預算未覆蓋和待審數量。
用戶因此可以先看本輪分佈，再決定維持標準線還是切換寬鬆/精選；系統不會
悄悄把閾值包裝成客觀的“崗位質量”。
六維評分：簡歷匹配 · 資格可行 · 方向 · 行業 · 工時 · 薪資。setup 會按職業和用戶限制生成權重與硬性門檻；產品本身不內置某個行業的資格、 語言或年限假設。
每個被評分的崗位還會在私有工作區保存一份版本化的崗位評估記錄：把初評、深評、
最終分數，以及“支持優勢”和“待核對缺口”結構化保存，並記錄 JD 與評分配置的哈希。
JD 或求職意向改變後，舊記錄會被視為過期並重新評估；後續材料流程可以複用同一份判斷，
避免不同崗位步驟重複猜測。記錄位於 JobSearch_2026/02_Tracker/job_assessments/，
不會把候選人資料複製進公開產品文件。它不是隻寫不讀的日誌：CV bullet 排序、
Cover Letter/申請郵件的共同證據順序，以及面試缺口準備都會讀取同一份當前記錄；
記錄缺失或過期時會明確標記，不會悄悄重算後冒充原評估。
痛點： Excel 沒規矩，或進度只在腦子裡。
怎麼解決： 結構清楚的工作簿：優先級分層、今日新職位米色高亮、V 列材料狀態下拉、選擇「已投遞」整行變綠，並支持從「新發現」到「已投遞 / 面試」的狀態流轉。支持 Google Sheets 或本地 CSV。
痛點： 半成品、格式亂、文件散落各處。
怎麼解決： 選定崗位後，為每一個崗位生成一整套：簡歷 + 求職信 + 投遞說明 + 郵件草稿 + 發出前檢查清單。
定製分兩層：
| 層次 | 含義 |
|---|---|
| 基礎版（按職業方向） | 方向之間差別要大；要做事實核對 |
| 定製版（針對這個 JD） | 在已核對的基礎版上，突出這份 JD 最在意的點 |
定製版的做法：
- 先由確定性 preflight 抽取薪資、到崗、工作權、語言/牌照、年限和附件要求，生成必問清單
- 語言門會把 JD 中明確的工作語言與私有語言檔案比較：未聲明語言才會硬剔除，水平可能偏高只標記提醒，廣告使用的語言不會被誤當成崗位要求
- 薪資解析支持本地化數字、區間連字符以及
k/M/B、千/萬/億等金額後綴；格式存在歧義時保持中性並提示核對，不會靜默把範圍誤判成負數 - 先快查公司的性質、主營業務和崗位上下文，並保存來源
- 從 JD 提取職責要點、硬性要求與能力主題
- 由系統生成 JD→候選人證據映射、四段 Cover Letter 藍圖和質量門檻；能力相對有限的模型也不能跳過
- 從基礎版的經歷子彈中，按 JD 關鍵詞匹配度打分排序，把最相關的提前
- 在有事實證據時用 STAR 重述；沒有真實量化結果時不補造數字
- 與 JD 無關或弱關聯的經歷降序或刪除
- 不編造新經歷——只重排和重寫已有事實，不做 freestyle 發明
- 輸出結果附帶覆蓋度分析：哪些 JD 要點命中了、哪些還需要你手動補充
Cover Letter 的崗位/行業匹配段：定製版會用一段 1–2 句的小段落替換通用版原有的 公司興趣位置，按“崗位需求 → 候選人真實證據 → 可提供的價值”組織，並自然使用 JD 中重要且真實的詞語。優先使用已核實的公司業務；如果沒有可靠公司資訊，就只 寫 JD、崗位職能或行業語境；如果證據不足則保留通用版。該段不會增加總篇幅，仍以 通用版一頁長度為上限，也不會因為省略它而阻斷投遞。
職位標題也會先經過確定性處理：職位頁原文保存在 role_display；A/B 這類斜槓標題
拆成推薦主職位和備選職位，定製材料默認只寫一個主職位，歧義時可用
python3 -m tools.job_materials role show 查看，並用 role choose 確認。Paralegal (Corporate Funds)
這類表示專業方向的括號會保留括號和詞彙；只有地點、合同/工作方式或編號等明顯元數據
括號會從對外職位名中移除。文件名由主機統一生成：完整安全 stem 不超過 80 個字元時
盡量保留原始標籤；只有超過 80 個字元才壓縮過長公司法律後綴、職位範圍或部門尾綴。
壓縮只影響對外文件名，完整公司名和職位仍保存在 manifest/材料中，也不會把多個職位拼成
一個新職位；Cover Letter 通常只在開頭提及主職位一次。
斜槓連接的縮寫順序屬於展示差異而非事實差異，例如 ECM/IPO 與 IPO/ECM 等價；系統保留職位頁原順序，
不要求模型改寫、查證或翻閱其他崗位材料。
JD 要求：Experience in developing, implementing and monitoring an operational program
JobsFlow 會把重點拆成：流程設計 · 落地執行 · 指標監控
→ 優先匹配候選人已有的流程創建、跨團隊執行和數據跟蹤經歷
→ 在 Cover Letter 中結合公司業務，說明對該行業/公司的真實興趣角度
→ 如果簡歷沒有足夠證據，明確標記缺口並詢問用戶，不自動編造經歷或數字
職位頁顯示的“公司”不一定就是最終用人方，可能是獵頭、招聘機構或招聘諮詢公司。
JobsFlow 會把發佈者與用人公司分開核查，並將關係歸類為 employer、recruiter 或
unknown：
- 獵頭已披露客戶：外發 CV / Cover Letter 只使用已核實的客戶公司；
- 客戶未披露：外發文件名不帶獵頭名稱，Cover Letter 只寫崗位和行業語境，不猜測公司；
- 無法確認：質量門檻會標記待核實，不把職位頁顯示名直接當成僱主。
材料包內部仍會保留發佈者字段，方便追溯崗位來源；真正發送時使用
tailor_plan.json 中的 material_filenames 命名建議。這樣即使崗位來自 Michael Page
等機構，投遞出去的文件名和求職信也不會把機構誤寫成用人公司。
JobsFlow 把 LLMO 做成可審計的材料契約，而不是“寫進模型記憶”或承諾 ATS 加分：
- 每條已核對經歷都有穩定的
evidence_id、允許表述和禁止推斷； - JD 要點分為 Tier 1/2，並明確標記
covered、partial、uncovered或prohibited_to_claim； - CV、Cover Letter 和申請郵件共享同一畫像事實源；CV/CL 分別校驗，某個真實數字只出現在其中一份並不構成矛盾；
- 輸出保持可解析的純文本結構（單欄、標準章節、關鍵聯繫資訊不放在圖片/文本框/頁眉頁腳）；
- 系統先把 lane 基礎版凍結為完整內容母版；主模型必須先提交 plan，再經固定的
materials-vnext-1gateway 提交帶 JD anchor 的 bounded transform，系統保留未提及 block 並合成 canonical CV/CL。獨立子 Agent 主要審 before/after delta，同時對完整最終 CV/CL 做一次職位、雇主/獵頭邊界、一致性、語法與殘句掃描；它不讀長手冊、事實庫、Email、DOCX/PDF 或版式。沒有真實正面證據的要求只在內部標記為intentionally_omitted；P0/P1 只允許主模型修改 finding 指向的 block；每崗最多三次審計調用、同一問題第二次仍出現即熔斷； - 審計發現會沉澱為不含候選人原文的材料製作經驗，下一次同類崗位可直接避開已知問題；
- 機器 QA 指標是內部工程指標，不是 ATS 官方分數或錄用預測。
因此，即使使用能力相對有限的模型，系統也會先給出證據映射和禁止越界的邊界，模型只需按藍圖重排和重述，不需要自行“猜懂”整份 JD。
材料格式和存放也不是模型可選項：只有確認 /push 才建立绑定的
01_Masters/<lane>/<tier>/<job_id>_未投_<company>/ 包；/materials 只能在该包内写入。
CV/CL 内容通过固定的 tools.workflow 入口，从对应 lane 的基础 DOCX 模板渲染后再转 PDF；
缺少模板或绑定回执会直接阻断，不会把纯文本另存成“看似 DOCX”。CV/CL 也不会主动暴露
未声明的语言或其他缺口（例如不会写 “Cantonese is not declared in my language profile”）。
PDF 導出用 LibreOffice headless（不彈窗，不干擾你正在做的事）；簡歷和求職信默認輸出一頁，用戶明確需要時可調整。
痛點： 好崗位上架又下架，你還在改上週的求職信。
怎麼解決： 臨時模式記住上次刷新時間，下次只掃這段時間內的新崗。不用每次都掃滿 24 小時，效率更高，也不遺漏。
/scan # 臨時模式：只掃上次之後的新崗（自動記憶）
/scan daily # 掃最近 24 小時
/scan 3 # 掃最近 3 小時
- 不代替你點提交
- 不做多人云端 SaaS - 以本機為主
- 不默認給你套某一行業模板 - setup 時根據你的簡歷和意向動態生成
- 不替你做最終決定 - 投哪裡仍由你選
- 不在掃描時自動做材料 - 只有你點名某個崗位後才生成
它會自動替我提交申請嗎？
不會。JobsFlow 負責檢索、分析、準備材料和投遞前檢查，最終提交始終由你確認。
能力相對有限的模型也能用嗎？
可以。模型負責研究和措辭，硬要求抽取、評分門檻、公司來源、證據映射和質量檢查由確定性代碼兜底。
什麼職位都可以用嗎？
原則上可以用於各行業和職位。setup 會根據你的簡歷、求職意向和行業動態生成方向與表頭；不同招聘網站的職位覆蓋範圍可能不同。
簡歷會不會自動上傳？
默認本地運行。只有你主動啟用外部 LLM、Google Sheets 或招聘網站請求時，相關數據才會發送到對應服務。
JobsFlow 只有一套產品代碼、規則和狀態機。JobSearch_2026/ 不是另一條代碼或規則線，而是直接運行這套產品的一個本地實例，用來保存你的簡歷、搜尋詞、JD、評分、臺帳和產物。這些運行數據默認被 Git 忽略；GitHub 發佈的是同一套產品代碼和空模板，不包含個人資料。
首次使用由 /setup 根據用戶的簡歷、求職意向、行業和限制條件生成搜尋詞、評分權重、方向表頭與材料策略。模型可以提出公司/行業研究摘要和更貼近崗位的表頭，但必須經過結構校驗；缺少研究來源或模型能力不足時，系統使用可審計的通用回退，不會把法律/合規當成默認行業，也不會編造經歷、數字或公司事實。
為了讓能力相對有限的模型也能穩定工作，關鍵步驟由確定性代碼兜底：JD 硬要求與薪資問詢 preflight、兩段評分門檻、公司研究來源檢查、證據映射、材料覆蓋度與 PDF 導出檢查都不能被模型跳過。能力更強的模型只會提升研究和措辭，不改變這些安全邊界。
準備發佈或貢獻前運行：
python3 setup.py --doctor-json
python3 tools/security_guards.py
python3 tools/public_release_check.py --source
pytest -q發佈衞生、歷史清理和可復現檢查見 PUBLIC_RELEASE.md；完整的安全邊界與運行規則見 docs/system_rules.md。提交前請確認 python3 tools/public_release_check.py --source 通過，並只發布乾淨快照，不要把個人工作區歷史帶入公開倉庫。
當前主線：1.0.0 - 統一 SOP gateway 與狀態機、lane 鎖定和確認入表、基礎版增量材料鏈、獨立 CV/CL 內容審計、固定 lane-master DOCX/PDF 渲染、JD 緩存與受控 JobsDB 恢復。
使用招聘網站可能受其服務條款約束，請自行評估。
本項目不提供法律、合規或移民建議。
MIT - 見 LICENSE。