简喵 02：需求分析——四类用户、四个场景、四个真实痛点

一个 AI 简历工具不应该从”我想做什么功能”开始，而应该从”用户到底卡在哪里”开始。

写完上一篇《为什么我要做简喵：一个被付费弹窗气出来的项目》之后，有人问我：

你做这个简历工具之前，到底有没有做过调研？还是拍脑袋就开始写代码？

这个问题很现实。

很多学生项目最大的问题，就是一上来先想技术栈：Spring Boot、Vue3、Redis、大模型、Docker、云服务器。看起来很完整，但仔细一问：用户是谁？为什么要用？现在不用你的工具会怎么解决？第一版必须解决哪个问题？

答不上来。

然后项目就会变成一个功能堆砌现场。首页很漂亮，按钮很多，模块很多，最后没人真的用。技术上很忙，产品上很空。

所以在正式做简喵之前，我先做了一轮轻量的需求分析。

说完全靠调研，是假的。说完全拍脑袋，也不准确。

调研的部分，是我和身边一些正在改简历、投实习、准备校招的同学聊了一圈。拍脑袋的部分，是我自己本来就是目标用户之一：普通 CS 本科生，有项目经历，但也会被简历表达、投递匹配、项目包装这些问题卡住。

这篇文章不是一份教科书式的用户调研报告。我不会假装自己做了几百份问卷，也不会堆一堆看起来很专业但没什么用的图表。

这篇文章只想回答一个问题：

简喵第一版到底应该做什么，又应该坚决不做什么？

一、需求分析不是列功能清单

很多人一想到需求分析，第一反应就是列功能。

用户登录。
简历上传。
AI 评分。
AI 润色。
PDF 导出。
JD 匹配。
面试题生成。
多版本管理。
分享链接。
投递追踪。
会员系统。
数据看板。

列完之后，看起来很丰富。

但这不叫需求分析，这叫愿望清单。

真正的需求分析不是问”我能做什么功能”，而是问：

用户现在为什么痛苦？
这个痛苦发生在什么场景？
用户目前怎么解决？
现有方案哪里不好？
如果第一版只做几个功能，哪几个最重要？
哪些功能听起来合理，但现在不该做？

简喵的需求分析也是围绕这些问题展开的。

我不想做一个”功能很多但没人用”的简历工具。第一版的目标只有一个：

让用户在最短路径里，把一份普通简历改得更清楚、更专业、更适合投递。

二、四类核心用户

如果只说”简喵面向大学生和求职者”，这个范围太大，最后做出来一定会失焦。

“大学生”不是一个足够具体的用户画像。

一个大一学生、一个大三找实习的计算机学生、一个跨专业转码的人、一个已经实习过准备秋招的人，他们的问题完全不一样。

所以我把简喵的核心用户拆成四类。

用户 A：有项目，但不会写的计算机学生

这是简喵最核心的用户。

比如一个大三计算机学生，GitHub 上有几个课程项目：图书管理系统、博客系统、待办应用、爬虫脚本。项目不一定多高级，但至少是真的做过。

问题是，一到简历里，他只会写：

负责前端页面开发和后端接口设计。

这句话不能说错，但几乎没有价值。

它没有说明用了什么技术，没有说明具体做了什么模块，没有说明解决了什么问题，也没有说明项目结果。面试官看到这句话，很难判断这个学生到底只是跟着教程敲了一遍，还是理解了项目里的关键设计。

同样一个项目，如果换一种表达，效果就完全不同：

基于 Vue3 和 Spring Boot 实现图书管理系统，负责用户登录、图书检索、借阅记录和后台管理等核心模块；使用 JWT 完成登录认证，基于 MySQL 设计用户表、图书表、借阅记录表等核心数据结构。

这段话并没有把项目吹成很高级的系统，但它至少说清楚了三件事：

第一，用了什么技术。
第二，做了哪些模块。
第三，具备哪些可迁移的开发能力。

这类用户的核心问题不是没有内容，而是不会把内容翻译成简历语言。

他们需要的不是模板，而是项目经历重写能力。

用户 B：有学习经历，但缺少求职化包装的转码用户

第二类用户是转码或跨专业求职的人。

比如一个金融、机械、自动化或其他专业的学生，自学了 Java、前端或 Python，刷了一些算法题，也做了几个项目。但他的简历经常有一个明显问题：学习痕迹很重，求职表达很弱。

常见写法是：

学习了 Spring Boot 框架，完成了一个电商项目。

问题在于，这种表达像学习笔记，不像项目经历。

企业不关心你”学习了什么”，更关心你”能用这些东西解决什么问题”。

同样是电商项目，如果只写”学习并使用 Spring Boot”，会显得很学生气；如果写清楚用户模块、商品模块、订单流程、权限认证、缓存设计、异常处理，可信度就会高很多。

这类用户的核心问题是：

他们有努力痕迹，但不会把学习经历转化成岗位能力证明。

他们需要的是求职化表达，而不是简单润色。

用户 C：有实习或工作经历，但没时间重写简历的人

第三类用户是已经有实习或工作经历的人。

这类人不一定不会写简历，甚至可能比学生更懂怎么表达。但他们的问题是：没时间、没精力、版本太乱。

比如一个前端实习生，去年简历写的是 Vue2 项目，今年主要做 Vue3 + TypeScript，但简历一直没更新。每次准备投递新岗位，都要重新打开旧简历、对照 JD、改项目描述、调整技能栈、导出 PDF。

不同岗位还要不同版本，最后文件夹里出现一堆类似这样的文件：

简历-最新版.pdf
简历-最新版2.pdf
简历-字节版.pdf
简历-腾讯修改版.pdf
简历-最终版.pdf
简历-最终最终版.pdf

看到”最终最终版”这几个字，就知道人类已经输给文件管理了。

这类用户的核心问题不是不会写，而是维护成本太高。

他们需要的是版本管理、JD 匹配和快速改写。

用户 D：面试前不知道怎么准备的人

第四类用户出现在简历投递之后。

很多人以为简历优化的终点是投出去。但实际上，简历上的每一句话都会变成面试里的潜在问题。

你写了 Redis，面试官可能问缓存穿透、缓存雪崩、缓存一致性。
你写了 JWT，面试官可能问 Token 续期、权限校验、Refresh Token。
你写了 Docker 部署，面试官可能问镜像构建、容器编排、日志查看。
你写了 AI 接入，面试官可能问 Prompt 设计、结构化输出、异常重试、成本控制。

很多人简历写得很漂亮，但面试时讲不清楚。

这比简历写得一般更危险。

因为面试官会觉得你不是不会写，而是在包装。简历上写的东西，如果自己讲不清楚，就会从加分项变成扣分项。

这类用户的核心问题是：

不知道自己的简历会被怎么追问。

他们需要的是基于简历内容生成面试题，而不是通用八股题库。

三、四个真实使用场景

有了用户画像，还不够。

因为同一个用户，在不同时间点打开简喵，需求是不一样的。产品不能只看”用户是谁”，还要看”他在什么时候、因为什么打开这个工具”。

我把简喵的核心使用场景分成四个。

场景一：投递前临时改简历

这是最高频、也最真实的场景。

晚上九点，用户在群里看到一个实习内推。岗位 JD 写着：

熟悉 Spring Boot、MySQL、Redis，有项目开发经验优先。

他打开自己的简历，发现项目经历写得很空：

使用 Spring Boot 完成图书管理系统。

他知道这样写不够，但又不知道怎么改。投递截止时间可能就在今晚，手动对照 JD 改简历太慢，找别人帮忙也来不及。

这个时候，他打开简喵，最想完成的动作是：

上传或填写简历。
粘贴目标岗位 JD。
系统指出简历和 JD 的差距。
AI 给出针对该岗位的优化建议。
用户确认后导出 PDF。

这个场景的关键词是：快、准、能投递。

用户不是来研究简历理论的，也不是来欣赏产品交互的。他就是要在短时间内知道：我这份简历哪里不匹配，应该怎么改。

所以 JD 匹配和一键优化，在 V1 里必须优先级很高。

场景二：GitHub 有项目，但简历写不出来

很多计算机学生最真实的情况是：代码仓库里有东西，简历里写不出来。

GitHub 里可能有好几个项目，但项目名称很普通，README 也很粗糙。用户自己回头看时，甚至不知道哪个项目值得放进简历。

这个场景下，简喵要解决三个问题。

第一，帮用户从 GitHub 仓库中筛选更适合写进简历的项目。
第二，提取 README、技术栈、提交记录等信息，理解项目大概做了什么。
第三，把项目内容转化成更适合简历的表达。

这里的重点不是”AI 编一个高级项目”，而是基于用户真实仓库做结构化整理。

如果用户只是做了一个普通图书管理系统，那就不能硬写成”高并发分布式图书智能中台”。那种写法短期看很唬人，面试时也会死得很有节奏。

简喵要做的是把真实项目写清楚，而不是把普通项目吹成宇宙飞船。

场景三：同一份简历要投不同岗位

很多用户只有一份万能简历。

投前端，用这份。
投后端，也用这份。
投 AI 应用开发，还是用这份。
投测试开发，稍微改几个词继续用。

这其实很危险。

不同岗位关注的重点不同。

前端岗位更关心组件化、工程化、性能优化、交互体验。
后端岗位更关心接口设计、数据库、缓存、权限、并发和系统稳定性。
AI 应用岗位更关心模型接入、Prompt、RAG、工具调用、成本控制和异常处理。

同一个项目，可以根据岗位强调不同内容。

比如一个 AI 简历项目：

投后端开发时，可以重点写接口设计、鉴权、限流、缓存、异步任务和部署。
投前端开发时，可以重点写编辑器交互、组件复用、状态管理和导出预览。
投 AI 应用开发时，可以重点写 Prompt 设计、结构化输出、AI 评分、JD 匹配和成本控制。

所以简喵需要支持多版本简历。

但注意，V1 不一定要做复杂的版本协作系统。第一版只要能做到”基于同一份简历生成不同岗位优化版本”，就已经能解决主要问题。

产品第一版最怕把简单需求做成复杂系统。明明只需要一个遮雨棚，最后开始研究穹顶结构，这种事在软件开发里每天都在发生。

场景四：面试前根据简历准备追问

简历优化之后，下一步就是面试准备。

很多用户会犯一个错误：只准备通用八股，不准备自己的简历。

但面试官最容易问的，恰恰是简历上的内容。因为这是你自己写上去的，默认你应该讲得清楚。

如果你写：

使用 Redis 缓存热点数据，提高接口响应速度。

那你至少要能回答：

为什么这个地方适合用缓存？
缓存 key 怎么设计？
数据更新后缓存怎么处理？
有没有考虑缓存穿透？
如果 Redis 挂了怎么办？
性能提升有没有具体数据？

如果这些答不上来，这句简历描述反而会变成风险。

所以简喵不应该只做”写简历”，还应该做”检查这份简历是否经得起追问”。

面试题生成功能就是为这个场景服务的。它不应该生成通用题库，而应该围绕用户简历中的项目、技术栈和具体表述生成追问。

这会让用户知道：哪些内容可以放心写，哪些内容写了但自己讲不清楚，需要补课。

四、四个核心痛点

用户和场景确定之后，简喵真正要解决的痛点就清楚了。

痛点一：项目经历写不具体

这是最常见的问题。

很多学生写项目经历时，停留在”我参与了什么””我负责了什么”，但没有写清楚”我具体做了什么”。

比如：

负责后端接口开发。

这句话太空。它没有告诉别人你设计了哪些接口，处理了哪些业务，使用了哪些技术方案，遇到了什么问题，最后实现了什么效果。

更好的写法应该是：

基于 Spring Boot 设计用户登录、简历管理、AI 评分等核心接口，使用 JWT 完成用户身份认证，并通过统一异常处理和参数校验提升接口稳定性。

这不是简单把句子变长，而是补齐了技术动作和业务场景。

简喵要解决的第一件事，就是帮用户把空泛表达改成具体表达。

痛点二：不会量化成果

第二个痛点是不会量化。

简历里经常出现这些句子：

提升了系统性能。
优化了用户体验。
提高了开发效率。
完成了项目核心功能。

这些句子看起来都没错，但说服力很弱。

因为它们没有数字，也没有判断标准。

更好的表达应该是：

将接口平均响应时间从 300ms 降至 120ms。
封装 15 个可复用组件，减少重复页面开发。
设计 8 张核心业务表，支撑用户、简历、评分记录等模块。
通过 Redis 缓存热点数据，降低重复查询压力。

当然，并不是所有学生项目一开始都有真实数据。很多课程项目没有用户量，也没有压测记录。

所以简喵不能直接替用户编数字。

正确做法应该分成两层。

如果用户提供了真实数据，AI 帮他放到合适的位置，组织成更有说服力的表达。

如果用户没有数据，AI 应该提示”建议补充可量化指标”，并告诉他可以补哪些指标，比如接口响应时间、页面数量、组件数量、数据表数量、功能模块数量、测试覆盖范围等。

这点很重要。

AI 简历工具最危险的地方，就是为了让简历好看而制造虚假信息。简喵要做的是提示用户补证据，而不是替用户编证据。

痛点三：不知道岗位关键词

第三个痛点是用户不知道不同岗位在看什么。

很多人投递时只看岗位名称，不会认真分析 JD。看到”后端开发实习生”，就把自己的通用简历扔过去。至于 JD 里到底强调 MySQL、Redis、微服务、消息队列、Linux、Docker 还是高并发，他没有认真拆。

这样投出去，简历就很容易和岗位要求错位。

简喵的 JD 匹配功能要解决这个问题。

它应该从岗位描述中提取几个信息：

岗位核心技能。
高频关键词。
加分项。
隐含能力要求。
简历中已经覆盖的内容。
简历中缺失或表达不足的内容。

比如 JD 要求：

熟悉 Spring Boot、MySQL、Redis，了解 Linux 部署，有 AI 应用开发经验优先。

而用户简历里只写了：

使用 Java 完成后端开发。

那系统就应该提示：

Spring Boot 没有明确出现。
MySQL 相关设计没有展开。
Redis 没有体现。
Linux / 部署经验没有体现。
AI 应用开发经验如果有，应该放到项目亮点中。

这样用户才知道该往哪里改。

简喵不是让用户迎合 JD 编经历，而是帮助用户把已有经历中和 JD 相关的部分提出来。

痛点四：表达太口语化

第四个痛点是表达不专业。

很多学生简历里的句子，像是在和同学聊天：

搞定了跨域问题。
写了很多页面。
做了登录功能。
用 Redis 做了缓存。
把项目部署到了服务器。

这些表达太口语，不适合简历。

不是因为它们不真实，而是因为它们没有形成专业表达。

可以改成：

简喵的 AI 润色不应该只是让句子变得”高级”，而应该让表达变得更准确。

这也是我不喜欢很多 AI 简历工具的原因：它们会把普通经历润色成一堆漂亮但空洞的词。看起来高级，实际没有信息量。AI 味重到像刚从提示词工厂流水线下来。

简喵要避免这种问题。

五、用户、场景、痛点和功能的对应关系

把前面的内容整理一下，简喵的核心逻辑其实很清楚。

这张表才是功能设计的基础。

不是因为”AI 评分听起来很酷”，所以我要做 AI 评分。
不是因为”面试题生成看起来很完整”，所以我要做面试题生成。
不是因为”多版本管理像专业工具”，所以我要做多版本管理。

而是因为这些功能分别对应了真实用户在真实场景里的真实卡点。

功能必须从问题里长出来，而不是从开发者脑子里冒出来。

六、V1.0 功能取舍：MoSCoW 分级

把用户、场景和痛点整理完之后，才能进入功能设计。

我用 MoSCoW 方法给简喵 V1.0 做了优先级划分。

MoSCoW 分成四类：

Must Have：第一版必须有，没有就跑不通核心流程。
Should Have：很重要，但可以在核心流程跑通后补。
Could Have：有了更好，但不影响第一版验证。
Won’t Have：当前阶段明确不做，避免范围失控。

Must Have：第一版必须做

V1 的核心链路应该是：

用户输入简历内容。
系统分析问题。
AI 给出优化建议。
用户确认修改。
导出可投递版本。

只要这条链路跑通，简喵就有基本价值。

Should Have：重要，但可以稍后做

这些功能都重要，但它们不能抢走 V1 的开发资源。

第一版最重要的是证明：用户愿不愿意用简喵来改简历内容。

Could Have：有更好，没有也能用

Could Have 的原则是：如果顺手能做，可以做；如果要牺牲核心功能进度，直接砍。

Won’t Have：V1 明确不做

这里最关键的是最后两项。

简喵可以帮用户表达真实经历，但不能替用户伪造经历。

AI 简历工具如果没有边界，很容易变成”求职包装机器”。它能让简历短期更好看，但也会让用户在面试里暴露得更快。

我希望简喵做的是增强真实表达，而不是制造虚假能力。

七、判断需求优先级的三个问题

为了避免功能越做越散，我给简喵设了三个判断问题。

问题一：没有这个功能，核心流程能跑通吗？

如果不能跑通，就是 Must Have。

比如 PDF 导出。没有它，用户即使完成了优化，也没法拿去投递。那前面的评分和润色就只是演示功能。

再比如简历内容编辑。没有编辑能力，用户就无法确认和修改 AI 建议，产品也不可能形成闭环。

问题二：这个功能解决的是”卡住”，还是”锦上添花”？

“不会写项目经历”是卡住。
“不知道 JD 关键词”是卡住。
“导出 PDF”是卡住。

但”分享链接访问统计”不是卡住。它有价值，但不是第一版必须解决的问题。

V1 应该优先解决用户卡住的地方，而不是做一堆看起来完整但不影响主流程的功能。

问题三：技术复杂度会不会拖慢 V1？

有些功能价值很高，但复杂度也高。

比如 PDF / Word 解析。

用户当然希望直接上传已有简历，然后系统自动识别内容。但现实是，简历格式千奇百怪，PDF 里可能有表格、分栏、图标、文本框、特殊字体。解析出来经常顺序错乱、字段丢失、格式混乱。

如果 V1 一开始就死磕 PDF 解析，很可能会把大量时间耗在边缘问题上，最后核心的 AI 优化反而做不好。

所以我的取舍是：

V1 优先支持结构化编辑和 GitHub 导入。
PDF / Word 解析可以做基础版，但不把它当成唯一入口。
等核心流程验证后，再逐步提升解析准确率。

这是一个典型的产品取舍：不是这个功能不重要，而是现在不该让它拖慢主线。

八、简喵 V1 的核心流程

经过上面的分析，简喵 V1 的核心流程可以压缩成一句话：

让用户输入真实经历，AI 帮他发现问题、优化表达、匹配岗位，并导出一份可投递简历。

对应流程是：

进入简喵
  ↓
创建或导入简历
  ↓
填写基础信息、教育经历、项目经历、技能栈
  ↓
AI 进行简历评分
  ↓
用户查看问题诊断
  ↓
选择项目经历或整份简历进行优化
  ↓
粘贴目标岗位 JD 做匹配分析
  ↓
生成针对岗位的优化建议
  ↓
用户确认修改
  ↓
导出 PDF

这个流程不复杂，但它必须稳定。

比起做十个半成品功能，我更希望 V1 把这条链路打磨清楚。

九、这篇文章真正想说明什么

这篇文章不是为了证明我做了多专业的用户调研。

恰恰相反，简喵的前期调研很轻量。它更像一个学生项目在启动前应该做的最低限度思考：

用户是谁？
用户什么时候用？
用户最痛的地方是什么？
第一版解决哪个问题？
哪些需求先不做？
为什么不做？

只要这几个问题想清楚，项目就不会一开始失控。

很多项目不是死在技术难度上，而是死在需求膨胀上。今天加一个模板市场，明天加一个在线协作，后天加一个会员系统，大后天又想做投递管理。最后看起来像一个完整求职平台，实际每个功能都浅得像雨后积水。

简喵第一版要克制。

它不做大而全的求职平台，也不做复杂排版工具。它先解决一个最核心的问题：

帮助用户把真实经历写得更清楚、更专业、更适合投递。

这就是 V1 的边界。

十、写在最后

需求分析不是把所有想法都写下来，然后一个个塞进项目里。

真正重要的是判断：

什么是用户现在最痛的？
什么是第一版必须解决的？
什么是看起来有用但会拖慢主线的？
什么是绝对不能做的？

对简喵来说，第一版最重要的不是功能数量，而是核心链路能不能跑通。

用户能不能输入真实经历。
系统能不能指出简历问题。
AI 能不能给出可用的优化建议。
用户能不能根据目标岗位调整简历。
最后能不能导出一份可以投递的 PDF。

如果这些能跑通，简喵就不是一个空壳项目。

下一篇，我会继续写简喵的产品流程设计：用户从打开简喵，到拿到一份优化后的简历，中间到底要经过哪些步骤，每一步页面应该解决什么问题，以及异常情况应该怎么处理。