顾问立场
保 · 稳 · 冲 · 不建议投
敢于劝退，是产品与招聘平台最清楚的分界。分数用来排序和解释，不是录用概率。
Case 01 · OfferOS
投之前，先看清楚这份工作值不值得投。
招聘平台负责找岗和开聊。OfferOS 停在更前面：把任意来源的岗位，整理成「该不该投、差在哪、怎么面」的可解释建议。
模型只看职业标签
- lock姓名、学校、项目原文不出站
- link岗位必须核验真实来源页
- description结论绑回简历行号
The Problem
匹配分很热闹，准备却对不上。
求职者并不缺岗位流。缺的是投递前的判断：这份 JD 是不是真的在招、和自己哪一段经历对得上、硬门槛有没有卡住、今晚该深挖哪两个岗。平台推荐偏开聊，简历润色偏措辞，两者都很难认真说「不建议投」。
现状是截图、收藏夹和表格各管一段。分数来了却没有证据，报告写了却没法对着原文准备面试。
痛点
- 黑盒分
看不到依据，无法决定投或不投。
- 假岗与过期页
搜索摘要不等于在招职位。
- 报告与行动脱节
建议改简历，却补造了没写过的经历。
「岗还是在平台上看；投之前，希望先有一个不站在平台那边的顾问。」
The Solution
投递前的专属求职顾问。
本地档案，不补能力
PDF / Word / Markdown 按模块归档。每条事实保留原文与行号。没写过的经历按未具备处理。
按需发现，核验再上榜
不维护岗位库存。联网搜索只认真实来源页及一跳详情，关闭岗与空壳页排除。
先筛后深
列表用规则快速分排序；点进岗位才生成长报告、公司背景和面试准备。
四维匹配
35%
知识技能
25%
工作经验
25%
核心能力
15%
个性特质
硬门槛只警示，不篡改原分和保稳冲档位。
Agent 分工
发现、JD 解析、详细判分、行动报告、公司背调走固定编排。快模型处理解析，长报告用更稳的生成；失败时页面标明规则兜底，不静默编造。
The Process
从简历到行动的一条链。
-
01 归档
本地提取证据
上传后按教育、工作、项目等模块落库。解析与证据绑定不调用模型，避免把隐私原文送出。
-
02 发现
最多六路搜索
招聘平台、企业站、技能方向与官网并行。默认目标 24 个核验通过的岗位，候选预算 96，并发 4。
-
03 排序
规则快速分
已识别技能覆盖 70 分，岗位方向 30 分；硬门槛不满足时最高 49。用于今晚多评少深，不是录用预测。
-
04 深报
点击后再核验
重新抓取详情，生成四维判断、公司背景、简历侧经历题和职位侧追问。原文证据在本地补回。
The Trade-offs
选择留下什么，比加上什么更难。
做过的选择
- 不做岗位大盘，做投前顾问层。
- 列表分用规则，长报告才用模型，避免每次搜索都等深报告。
- 硬门槛警示而不改分，避免「卡学历却看起来很匹配」。
- 面试准备不写改简历建议，防止补造未写经历。
明确放弃
- 不代投、不站内开聊，激励不和平台抢互动。
- 搜索摘要不拿来补造 JD；宁可见到空页。
- 公开 Demo 用虚构人物，真实简历进入独立访客空间。
- 分数与列表可能不一致，并在产品里说清楚原因。
The Results
可核验的闭环，而不是更长的生成。
24
默认一次核验通过的岗位目标
42
扩展搜索实测核验网页数（同轮 24 岗通过）
49
虚构样例中可回原文的事实条数
0
向模型发送的姓名、学校与项目原文
产品已部署公开 Demo 与管理端。管理端跟踪漏斗、质量与用量。公开入口默认进入虚构人物，避免把演示数据写进真实档案。当前仍以 HTTP 演示；正式收集真实简历前需要 HTTPS 与更完整的账户保护——这是已知边界，不是已验收能力。