AI Workflow

# 产品需求文档：JobMatch v2

**文档状态：** 草稿版 v2

**最后更新时间：** 2026-03-24

**产品名称：** JobMatch

## 1. 概述

JobMatch v2 是一款面向中国大陆实习生和应届生的轻量化岗位管理平台。其首版核心目标并非替用户做决策，而是帮助用户将岗位信息稳定记录、整理为固定字段、长期留存原始岗位描述（JD），并支持后续随时检索、回看、修改及归档。

首版产品将以小范围在线网页版最小可行产品（MVP）的形式验证价值。聚焦于岗位记录、字段提取、当前岗位信息管理及后台岗位描述（JD）快照留存，暂不支持投递跟踪、职业规划、自动推荐或自动排名功能。

## 2. 负责人

|  姓名  |      角色      |                     备注                     |
| :----: | :------------: | :------------------------------------------: |
| 你本人 |   产品负责人   |     负责产品方向、范围判断及验收标准制定     |
|  本人  |   技术负责人   |  负责前后端实现、数据结构设计及系统边界界定  |
|  本人  |   设计负责人   | 负责新建页、列表页、详情页设计及信息层级规划 |
|  本人  | 用户研究负责人 |       负责小范围内测及真实使用反馈收集       |

## 3. 背景

### 3.1 需求背景

实习生和应届生在求职过程中，常需在招聘软件、聊天记录、朋友圈及笔记工具间频繁切换。看到意向岗位时，多数人会先截图、收藏、转发给自己，或简单复制到备忘录中。

这种方式存在以下固有问题：

- 岗位信息分散，难以长期管理
- 同一岗位可能被重复保存，且内容不一致
- 一段时间后，用户往往无法记起原始岗位描述（JD）的存放位置
- 回看岗位时，需在多个工具间反复查找
- 多数用户有整理岗位的需求，但不愿维护复杂表格

### 3.2 如何推进

当前可通过更轻量化的方式解决上述问题：将原始岗位描述（JD）作为长期资产留存，同时通过固定字段整理岗位当前信息。既保留原文，又形成可编辑、可检索、可筛选的岗位记录。

该方向具备优先推进的条件：

- 用户已养成复制岗位文本的习惯，录入门槛低
- 大模型可辅助提取固定字段，且无需替代用户决策
- 在线网页形态可为后续岗位描述（JD）历史留存及平台数据来源拓展奠定基础

### 3.3 产品边界

JobMatch v2 的核心定位是岗位管理工具，而非决策判断工具。

首版主线功能不包含以下能力：

- 投递状态跟踪
- 能力差距分析
- 职业路径建议
- 自动岗位推荐
- 自动岗位排序
- 自动联系人力资源（HR）
- 自动持续抓取平台岗位信息

未来即便接入 BOSS MCP，产品主线仍聚焦岗位管理，而非平台聚合或黑盒决策。

## 4. 目标

### 4.1 产品目标

JobMatch v2 首版目标是让用户愿意持续将岗位信息录入系统，并将其作为核心岗位管理平台长期使用。

优先解决四大核心问题：

1. 岗位记录流程足够轻量化，降低用户多次使用的门槛
2. 岗位信息足够清晰，支持用户快速找回历史记录
3. 原始岗位描述（JD）得到长期留存，而非仅保留二次整理结果
4. 为后续结构化岗位对比及选岗环节奠定规范的数据基础

### 4.2 核心价值

对用户而言，核心需求并非系统替其分析，而是避免岗位信息持续丢失和散乱。唯有岗位信息被稳定收纳，后续的对比、选择及投递准备才有基础。

对产品而言，先打造轻量化岗位管理平台，相比同时开发投递管理、选岗建议、职业分析等功能更稳妥。可先验证用户的长期使用意愿，再决定下一阶段是否拓展更多能力。

### 4.3 策略一致性

本产品需求文档（PRD）遵循以下长期原则：

- 人工智能（AI）仅用于辅助字段提取，不替用户做决策
- 用户可查看、修改、确认当前岗位记录
- 原始岗位描述（JD）属于长期资产，需单独留存
- 手动录入是长期正式录入方式，不会因接入平台而取消
- 平台能力仅作为数据来源，而非产品核心定位

### 4.4 关键结果

**核心目标：** 验证用户愿意将 JobMatch 作为岗位管理平台持续使用。

- **关键结果 1（KR1）：** 小范围内测中，用户可在 3 分钟内通过「岗位描述（JD）粘贴」或「纯手动创建」完成一条岗位记录的保存。
- **关键结果 2（KR2）：** 100% 已保存的岗位需留存有效依据：原始岗位描述（JD）快照，或纯手动创建时填写的核心三字段。
- **关键结果 3（KR3）：** 100% 的字段提取失败场景均不阻断保存流程，用户可切换至手动录入路径完成操作。
- **关键结果 4（KR4）：** 小范围内测中，活跃试用用户中至少半数会在多个独立会话中重复新增或修改岗位记录。
- **关键结果 5（KR5）：** 核心可用性测试中，用户可在 30 秒内通过搜索或基础筛选找到已保存的岗位。

## 5. 目标市场细分

### 5.1 核心目标人群

首版主要服务以下用户：

- 中国大陆的实习生及应届生
- 正集中求职、投递、整理岗位信息的人群
- 岗位信息分散在多个软件及记录工具中的用户
- 希望通过轻量化、长期化、可回看的方式管理岗位的用户

### 5.2 核心待办任务

当用户在任意渠道看到值得关注的岗位时，期望快速记录信息、留存关键内容，并能在后续快速找回、补充及管理该岗位信息。

### 5.3 约束条件

该人群通常存在以下约束：

- 时间碎片化，不愿维护复杂系统
- 原始岗位描述（JD）来源分散，格式不统一
- 有时仅能获取部分岗位描述（JD），有时仅掌握核心信息
- 对黑盒化结论存疑，更信任可查看、可修改的记录
- 初期未必愿意绑定平台账号、邮箱或完整简历

### 5.4 V1 非目标人群

首版暂不优先服务以下场景：

- 招聘方、猎头或企业用户
- 需自动批量投递的用户
- 期望系统直接给出职业建议的用户
- 需公开检索全量市场岗位的用户
- 核心需求为投递流程管理而非岗位管理的用户

## 6. 价值主张

### 6.1 用户核心任务与需求

用户的核心诉求为：

- 稳定记录看到的岗位信息
- 不丢失原始岗位描述（JD）
- 快速形成可管理的当前岗位信息
- 后续需要时能快速检索到该岗位
- 为投递准备留存关键信息

### 6.2 用户收益

JobMatch v2 为用户带来的核心收益：

- 统一的岗位管理入口
- 可编辑的当前岗位记录
- 长期留存的原始岗位描述（JD）快照
- 比表格更轻量化、比笔记更结构化的管理方式
- 无完整岗位描述（JD）时仍可手动记录岗位信息

### 6.3 解决的痛点

核心解决以下用户痛点：

- 岗位记录分散在不同工具中
- 后续检索时无法快速找到目标岗位
- 回看岗位时需重新阅读大段文本
- 仅保留整理结果，丢失原始岗位描述（JD）
- 因资料不完整而放弃记录岗位信息

### 6.4 相比竞品的优势

相较于普通笔记工具，JobMatch 结构化更强；相较于复杂表格，更轻量化；相较于自动决策工具，更具可控性；相较于平台收藏功能，更适合长期留存及持续整理。

产品核心价值并非替用户决策选岗，而是帮助用户先理清岗位信息。

## 7. 解决方案

### 7.1 用户体验 / 核心用户流程

首版核心流程围绕统一新建页展开。

**路径 A：岗位描述（JD）粘贴录入**

1. 用户在任意渠道获取岗位描述（JD）
2. 用户将岗位描述（JD）粘贴至统一新建页
3. 用户手动触发字段提取操作
4. 系统从岗位描述（JD）中提取固定字段，仅填充当前空白字段
5. 用户核对并修改当前岗位信息
6. 用户保存岗位记录
7. 岗位进入主列表，后续可检索、筛选、归档及编辑

**路径 B：纯手动创建**

1. 用户无完整岗位描述（JD），但希望先记录岗位信息
2. 用户在统一新建页展开手动创建表单
3. 用户填写核心三字段：岗位名称、公司名称、所在地
4. 用户保存岗位记录
5. 后续获取原始岗位描述（JD）后，可补充并触发字段提取

**失败与降级处理**

- 字段提取失败时，系统主动引导用户手动填写
- 用户仍可保存岗位记录，不会因提取失败导致记录丢失
- 系统提供「重新提取」次级入口，但不阻断主流程

### 7.2 核心功能

#### 功能 A：统一岗位创建

首版通过统一新建页承载两种正式录入方式：

- 「岗位描述（JD）粘贴录入」
- 「纯手动创建」

两种路径均可生成正式岗位记录，纯手动创建并非临时占位，而是同等优先级的记录方式。

#### 功能 B：固定字段提取

首版采用固定字段体系，不支持自由标签。字段提取由大模型辅助完成，提取结果仅作为草稿。

当前岗位记录至少包含以下字段：

- 岗位名称
- 公司名称
- 归一化城市
- 完整地点文本
- 薪资原文
- 到岗时间
- 投递方式原文
- 简历命名方式
- 职位描述原文片段
- 职位要求原文片段

以下内容不单独设为字段：

- 经验要求
- 学历要求
- 自动总结建议

相关内容如需留存，统一纳入「职位要求」原文片段中。

#### 功能 C：当前岗位记录

用户日常查看、编辑、检索、筛选的核心对象为「当前岗位记录」。

核心要求：

- 所有固定字段支持用户修改
- 用户修改后的字段为当前生效的正式记录
- 检索、筛选及后续对比均以该层记录为核心依据

#### 功能 D：岗位描述（JD）快照留存

每次导入原始岗位描述（JD）时，系统自动留存一份快照。V1 版本先在后台留存，暂不要求前台展示历史快照列表。

历史快照的核心作用：

- 留存原始信息来源
- 支持长期追溯
- 为后续平台数据来源接入及版本变更奠定基础

V1 版本规则：

- 新快照不会自动覆盖当前岗位记录
- 同一岗位新增快照后，是否更新当前岗位信息需用户人工确认

#### 功能 E：检索、筛选与归档

首版主列表围绕岗位主记录设计，支持：

- 固定字段检索
- 原始岗位描述（JD）全文检索
- 按归一化城市筛选
- 按公司名称筛选
- 按归档状态筛选

岗位默认进入主列表，用户可将不再关注的岗位归档，保持主列表整洁。

#### 功能 F：重复提醒

首版仅提供轻量化重复提醒，不强制自动合并。提醒规则优先基于：

- 岗位名称
- 公司名称
- 归一化城市

后续接入平台数据后，优先以平台岗位 ID 作为岗位唯一标识；无可靠 ID 时，仅触发提醒，不自动强制合并。

### 7.3 技术方案

首版采用小范围在线网页应用形态，而非本地个人工具。

技术栈沿用现有基线：

- 前端：Next.js App Router、TypeScript、Tailwind CSS、DaisyUI
- 后端：FastAPI、SQLAlchemy、Pydantic、PostgreSQL
- 人工智能（AI）：由后端统一调用，用于固定字段提取
- 多渠道协作平台（MCP）：作为数据来源适配层，不存储核心业务状态

数据层建议从 V1 版本起清晰分层：

- 「岗位主记录」
- 「当前岗位字段」
- 「原始岗位描述（JD）快照」

后续接入 BOSS MCP 需遵循以下原则：

- 仅作为正式数据来源之一
- 手动粘贴岗位描述（JD）仍为长期核心录入路径
- 平台导入需由用户主动触发
- 平台能力不应改变产品「管理工具而非决策工具」的核心定位

### 7.4 核心假设

本产品需求文档（PRD）基于以下假设：

- 用户愿意持续使用轻量化岗位管理平台
- 固定字段相比自由标签更适合首版长期数据积累
- 在线网页架构更利于后续岗位描述（JD）历史留存及平台数据来源拓展
- 大模型字段提取是首版核心能力，但不可作为保存操作的前置条件
- 未来岗位对比仅需结构化字段罗列，无需系统替用户决策

## 8. 版本规划

### 8.1 V1 / 核心优先级（P0）

首版交付小范围在线网页版最小可行产品（MVP），核心验证「岗位管理平台」的价值可行性。

首版功能范围：

- 统一新建页
- 岗位描述（JD）粘贴录入
- 纯手动创建
- 固定字段提取
- 当前岗位记录编辑
- 原始岗位描述（JD）快照后台留存
- 检索功能
- 基础筛选功能
- 归档功能
- 轻量化重复提醒

首版明确不做的功能：

- 投递状态跟踪
- 岗位优劣自动判断
- 能力差距分析
- 职业路径建议
- 自定义标签体系
- 前台展示岗位描述（JD）历史版本

### 8.2 V1.1 / 次核心优先级（P1）

V1 版本验证通过后，进入下一阶段迭代：

- 支持用户主动发起的结构化岗位对比
- 对比对象仅限用户已保存的岗位
- 对比方式以结构化字段罗列为主
- 将 BOSS MCP 作为正式数据来源之一接入

本阶段仍需遵循：

- 产品仅辅助信息整理，不替用户排名
- 平台能力仅作为数据来源，不改变产品主线
- 手动录入仍为正式录入路径

### 8.3 远期规划 / 低优先级（P2）

更远期迭代方向：

- 前台支持查看同一岗位的岗位描述（JD）快照历史
- 探索用户画像或简历相关能力
- 明确需求后，评估拓展更多数据能力

以上均非当前版本成功的必要条件。

### 8.4 明确不做的事项

以下内容不属于本次新版产品需求文档（PRD）的主线范围：

- 自动投递
- 自动联系人力资源（HR）
- 自动推荐最优岗位
- 自动岗位排名
- 黑盒化选岗建议
- 全量市场岗位检索聚合
- 自动持续拉取平台岗位信息
- 以职业规划为核心的产品定位