产品实践 · 实习项目

牛客网申助手|不再重复填简历

把「填得不够准」拆解为四类可定位的问题,再用一套三层字段体系把它解决

牛客网|产品共创者(远程)|2025.11~2026.02|用户调研、竞品分析、PRD 撰写

Situation

为什么值得做

官网填表是纯粹的重复劳动,是能用工具提效的部分。而一个校招生通常至少要投几十份简历,同一个填表动作会被重复几十遍,填一份简历甚至需要十几分钟。这个核心痛点,是「网申填表」值得被单独做成一个产品的原因。

需求其实早就被验证过——小红书上一款手动点选的填充插件卖出 1.2 万件。市面上共 8 款同类产品,按量级和定位分三梯队:

产品用户量级商业模式核心能力
第一梯队 · 高用户量,已跑通场景
塔塔网申神器Edge 47,000+ / Chrome 9,000+免费 100 次后 29 元/月AI 一键填写,多简历管理,主流企业覆盖
Simplify CopilotChrome 500,000+完全免费自动填充 + AI 简历定制 + 职位推荐 + 追踪
牛客简历助手依托牛客百万用户免费,导流 B 端变现一键闪填 + 企业字段库 + 高频词分析
第二梯队 · 有特色差异化
OfferLinkEdge 19,000+完全免费基础自动填充,本地存储,隐私无忧
求职方舟Edge 21,000+ / Chrome 5,000+基础免费 + 增值付费AI(DeepSeek)智能识别 + 笔面试一体化
信息填写插件(老李)1.2 万+ 售卖9.9 元买断手动点击填写,需 Excel 导入,本地存储
第三梯队 · 小而美
Cvmax(满分简历)Edge 3,241 / Chrome 1,000+付费订阅AI 驱动自动填充,简历优化服务
quick-offer(小紫)1,000+ 售卖9.9 元买断基础填写,本地存储

数据取数时间:2025 年 11 月。

三梯队的共同短板是字段识别。所以真正的问题不是没人做工具,而是没有一个真正好用的。用户对它们的抱怨也集中在这里——识别不准、自定义字段适配差、担心隐私泄漏。

Task

我负责什么

我参与项目前期的用户调研、竞品分析、需求定义与 PRD 撰写;开发、上线与后续迭代由牛客团队完成。我们的目标是,让用户在网申的时候点一次就能填完大部分官网表单,只需要补填少量没有采集到的字段。

  • 痛点定位:设计并执行 5 位用户访谈、40 份问卷与小红书社区调研,确认「耗时环节」和「既有工具的失败点」究竟在哪。
  • 竞品拆解:把 8 款同类产品按量级与定位分三梯队,逐项对比字段识别方式、商业模式与主要短板。
  • 字段体系与交互边界:定义三层字段结构,并划清哪些字段必须问、哪些不该动。
How it works

怎么运转

整个产品是两个解耦的过程,站内采集一次信息,网申可重复使用。信息采集在牛客站内完成——上传简历、解析、按模块归位、人工校对,沉淀成个人信息库;网申填写发生在每一次投递——识别官网表单字段、按要求做映射、一键填入、少数字段由用户补充。用户的简历信息保存在牛客的服务器。这也决定了产品的核心逻辑:采集的信息越全,投递时能自动填的空格越多。

牛客网申助手两段式流程:信息采集与官网投递 流程分两个解耦阶段。第一阶段在牛客站内采集:上传简历 PDF/Word,经①简历解析、②结构化归位、③校对补全,沉淀为个人信息库(基本信息、教育、实习、工作、项目)。第二阶段在招聘官网投递:④识别表单字段、⑤按各站要求做字段映射、⑥一键填充、⑦人工补全缺失项后提交。两段通过个人信息库连接——库里采集得越全,投递时可自动填的空格越多;填充中的补全结果回流信息库,下次不必再填。 第一阶段 · 信息采集(牛客站内,一次性) 新建在线简历 上传 PDF / Word ① 简历解析 提取关键字段 ② 结构化归位 按模块写入字段 ③ 校对与补全 确认、修正、补充 个人信息库 基本信息 | 教育经历 | 实习经历 | 工作经历 | 项目经历 采集一次,反复复用 第二阶段 · 官网投递(每次投递发生时) 库里采集得越全,能自动填的空格越多 打开招聘官网 进入投递页 ④ 识别表单字段 读出每个空格 ⑤ 字段映射 按各站要求取用 ⑥ 一键填充 逐字段写入表单 ⑦ 人工补全 缺失与特殊字段 检查并提交 补全结果回流
Action

关键判断

把「准确率低」拆解为四类可定位的问题

通过用户调研发现,用户多在抱怨市面工具填写不准确。我拿当时用户量最大的塔塔网做了实测:13 家企业、6 类招聘系统(Moka、北森、大易、智联、飞书与企业自研),逐字段核对它到底填错了什么,最后把错误分为四类——缺少字段(字段库里没有)、有值未填(简历里有但没填上)、填错(填了错的值)、乱填(填了根本不存在的值)。拆开之后,优化方向变得具体:「有值未填」和「乱填」是提升空间最大的两段,而「缺少字段」只能靠补库解决。它们分别对应不同的做法。

字段按「三层」组织,而不是一张平铺的清单

如果只列一张「要采集哪些字段」的表,产品会滑向「什么都想采」。基于竞品调研,我把需要采集的字段分成三层,每一层对应不同的采集时机和打扰成本。核心基础字段(姓名、学校、学历、专业、公司、职位、起止时间、简历附件)覆盖绝大多数表单的必填项,高精度解析、最高优先级填充;场景扩展字段只在检测到信号时激活,目标企业是国企才取政治面貌和籍贯,简历出现技术栈关键词才取 GitHub 与论文;动态交互字段(开放性问题、公司特定问题、工作期望)无法自动填,改为建历史答案库,用户填过一次,下次提供选项。

Result

结果

产品上线后累计 10 万+ 人使用、664 万+ 次调用,人均使用 60 余次,节省 90% 的网申填写时间(官方口径)。(取数时间:2026 年 10 月)这意味着它已经不是尝鲜工具,而是会反复使用的工具。我自己也使用了 90 余次,遇到需要填信息的表单就会打开它。

产品官网: 牛客网申助手牛客官网投递助手 PRD

Reflection

功能清单不是产品边界

我最初把投递追踪、AI 简历优化、岗位推荐等等功能列为网申助手插件后续需要做的功能迭代。牛客团队的处理方案是,这些功能不进入插件,而是以独立的产品「牛客 Agent 求职助手」落地,与插件并列。从结果看,两者是互补而非替代:网申插件负责把已有的简历信息填进网申表单,求职助手 Agent 负责找岗位、优化简历、管投递进度。

这让我修正了一个判断:不是所有需求都该塞进同一个产品。官网投递最核心的痛点只有一个——重复填写,网申插件把它解决到极致就够了。投递追踪、简历优化对一部分人有用,但不是所有人的刚需,硬塞进去只会稀释插件。功能边界该由核心痛点决定,不该由「还能加什么」决定。