Java后端想转全栈第一步不是学Vue而是先把需求问清楚我做了两个月的页面业务方看了一眼说不是这个去年三月我给自己定了个三个月转全栈的计划第一件事就是买了套 Vue3 TypeScript 的课。晚上十点下班回来啃composition API、Pinia、Vite 配置、ElementPlus 的表格组件一个一个过。啃到第五周我拿公司内部的运维工单系统练手写了个工单列表页分页、关键字搜索、状态彩色标签、批量派单按钮。样式我调了两个晚上边框圆角、hover 阴影、空状态插画都对齐了我觉得该有的样子。拿给运维组的老陈看。他盯着屏幕看了三秒说“我想要的是按人统计的谁手上压了多少没结的单。”我说列表里也有处理人啊你点开详情就能看到。他说“我每天早会上扫一眼就得知道该催谁。你这个我要点进去十几次还得自己数。”那天晚上我把页面删了大半。后来我复盘这件事问题不在 Vue 写得烂——说实话那页面的代码质量还行。问题在于从拿到需求到打开 IDE中间我只花了十分钟沟通而那十分钟我全用来问页面上要放哪些字段了一句都没问你到底想解决什么。这是我转全栈路上交的第一笔学费也是最贵的一笔技术栈可以花两个月补但如果你连要做什么都没搞清楚写得越快返工越大。为什么后端转全栈特别容易掉进这个坑我观察了自己和身边几个同样在转的同事发现这个坑不是偶然是结构性的。第一后端写代码前有天然的需求缓冲区前端没有。我们以前接到的活儿通常是这样的产品给一份 PRD里面字段、状态、边界都写清楚了我照着建表、写接口、写单测。我从来不需要自己问这个需求的目的是什么因为有人替我问过了。但转全栈之后尤其是做内部系统、小工具、业务方直接找过来的需求那个中间层没了。业务方丢一句话过来你得自己既是产品又是开发。而我下意识的动作是——把这句话翻译成一张表、一个列表页因为这是我十年里最熟练的动作。第二学会 Vue是个有明确终点的任务问清需求不是。框架有文档、有视频、有 demo学到什么程度能自己判断。需求澄清没有进度条你问了三个问题可能还是不知道够不够于是大脑本能地逃避它转向那个能立刻看到反馈的事情写代码。我前两个月就是这么自我欺骗的。每天都在产出Git 提交记录很好看但产出的东西没人用。第三我们习惯用技术语言复述需求然后在复述里把歧义偷偷保留下来。我把做个工单管理翻译成工单列表 增删改查翻译过程看起来很专业实际上只是把一个模糊的词换成了另一组模糊的词。统计到底是什么维度没结的单包不包括挂起的这些歧义在技术翻译里一点都没减少只是被藏进了数据库字段里等联调那天再爆出来。需求分析模块全栈链路真正的起点我后来开始用飞算JavaAI 做内部项目才第一次把这个环节当成一件正经事来做。飞算JavaAIhttps://www.feisuanyz.com把全栈开发拆成了四段需求分析 → 前后端设计 → 前端开发 → 后端开发。以前我看这个链路眼睛直接跳到第三段和第四段觉得前两段是写文档。真正吃过亏之后才发现前两段决定了后两段是不是白干。需求分析这一模块的官方定位是负责深度解析并梳理原始需求将其转化为结构清晰、逻辑严密的标准化需求文档与业务设计文档为后续的系统设计与开发阶段提供精准、可直接落地的执行依据。我关心的是它的操作步骤因为它把问清楚这件事变成了流程而不是靠个人自觉在智能会话中点「添加指令」选择/需求分析输入原始需求内容写得越详细出来的东西越扎实模型识别需求里的模糊边界发起问题澄清我逐条回复这些澄清问题产出需求文档 业务设计文档落在当前项目的 docs 目录文档可以直接编辑修改改完再往下走这六步里第三步是我以前从来不做的一步。问题澄清机制到底在澄清什么我第一次看到/需求分析给我抛回来一串问题时说实话有点不耐烦——我以为它会直接给我文档。但看完那串问题我沉默了。因为它问的每一条都是我以前做内部系统时被坑过、但从来没在事前问出口的东西。它的机制是这样的你给的需求越粗它反问的越多你回答得越具体它反问的越少。它不是在刁难你是在帮你把你以为你已经想清楚、其实没想清楚的地方标出来。用老陈那个工单系统举例。我最初输入的需求就一句话做一个运维工单管理后台能看到所有工单支持派单和统计。/需求分析抛回来的问题大致是这几类我做了删减和整理关于对象和角色这个系统的使用者有哪些角色运维组长、运维工程师、报单人是不是同一拨人不同角色看到的数据范围一样吗工程师能不能看到别人的单关于核心实体的定义工单的状态流转是怎样的从创建到关闭中间经过哪些状态一个工单是否允许被多次转派转派后原处理人是否还可见关于统计这个词的落点统计是按处理人维度、按工单类型维度还是按时间趋势没结的单包含哪些状态挂起、待用户确认算不算未结统计结果的更新频率要求是什么实时、T1、还是打开页面时算一次就够关于边界和异常工单超过多久未处理需要升级提醒提醒给谁已关闭的工单允许重新打开吗数据量级大概多少是否需要历史归档关于不做的事本期是否包含工单的附件上传、评论、消息通知我把这些追问按类别整理了一下后来做别的内部系统也一直照着这个表自查。它问出来的问题基本跑不出这五类类别典型问题不问的后果角色与视角谁用几个人用不同角色看到的页面是不是同一个做出一个全量大列表每个人都要自己过滤概念定义状态有几种怎么流转能不能回退枚举值靠猜上线后加状态要改全表历史数据口径统计按什么维度哪些数据算、哪些不算报表数字和对方手工表对不上信任归零边界与异常超时怎么办关错了怎么办数据量多大异常分支全是漏洞数据量大起来分页直接卡死本期范围哪些明确不做需求做到一半持续膨胀永远上不了线这张表里最容易被漏掉的是最后一行。我们做后端的习惯是把功能做全但内部系统真正的交付标准常常是先把最痛的那块跑起来。我把这几组问题截图发给老陈他打了二十分钟电话过来说了很多我从来不知道的事他们组有个不成文的 SLAP1 工单两小时必须响应挂起的单子不算积压但要在另一个口径里体现组长只关心自己组六个人别的一概不看。这些信息如果我直接写代码永远不会知道——因为他不会主动说我也不会主动问。澄清前后需求差了多少我把同一句话需求在澄清前后的差别拉了个表这是我后来做内部系统一直在用的对照方式维度澄清前我脑子里的版本澄清后文档里的版本目标做一套工单管理让组长 30 秒内判断该催谁让工程师知道自己今天要干什么首页工单列表全量默认按创建时间倒序组长视角按处理人聚合的负载看板 超时预警区工程师视角我的待办列表统计口径“统计”未定义未结 待处理 处理中挂起单单独一列不计入积压但计入挂起超 7 天提醒状态机大概有新建、处理中、已完成新建 → 待响应 → 处理中 →挂起 → 处理中→ 待确认 → 已关闭已关闭不可重开只能新建关联单超时规则无P1 两小时未响应标红并通知组长P2 八小时P3 不提醒数据范围所有人看所有组长看本组工程师看自己 被指派给自己的报单人只看自己提的本期不做没想过不做附件、不做评论、不做 IM 通知超时提醒只做站内红点数据量没问存量 4 万条日增约 120 条列表默认查近 90 天历史走归档表这张表右边那一列没有一行是我靠想能想出来的全是问出来的。而且注意最后两行——“本期不做和数据量”。这两条是我以前从来不问、但每次都埋雷的地方。不算清楚数据量分页和索引就是拍脑袋不划清楚不做什么需求就会在做了一半的时候自己长出新肢体。把澄清结果落到代码里差别是具体的澄清完之后很多以前拍脑袋的地方变成了确定的代码。举个最小的例子工单状态这个枚举澄清前我写的是这样// 澄清前的版本凭感觉写的四个状态看着挺全publicenumTicketStatus{NEW,PROCESSING,DONE,CLOSED}澄清之后状态不只是多了几个值而是带上了口径和流转约束/** * 工单状态。 * 口径与流转规则来自需求澄清结论不要随意增删枚举值 * 数据库里 status 字段存的就是 name()改枚举等于改历史数据语义。 */publicenumTicketStatus{/** 新建报单人提交尚未有人响应 */NEW(新建,false),/** 待响应已分配处理人等待首次响应受 SLA 计时约束 */PENDING_RESPONSE(待响应,true),/** 处理中已响应正在处理 */PROCESSING(处理中,true),/** 挂起等待外部条件用户回复、第三方处理不计入积压但计入挂起超时 */SUSPENDED(挂起,false),/** 待确认处理人已完成等待报单人确认 */PENDING_CONFIRM(待确认,false),CLOSED(已关闭,false);/** 是否计入未结积压统计口径。关键挂起单不算积压这是老陈明确说的 */privatefinalbooleanbacklog;TicketStatus(Stringlabel,booleanbacklog){this.labellabel;this.backlogbacklog;}privatefinalStringlabel;publicStringgetLabel(){returnlabel;}publicbooleanisBacklog(){returnbacklog;}/** * 允许的状态流转。需求澄清结论已关闭不可重开只能新建关联工单。 * 这里写死是为了在 Service 层统一校验不让状态被任意改来改去。 */privatestaticfinalMapTicketStatus,SetTicketStatusTRANSITIONSMap.of(NEW,Set.of(PENDING_RESPONSE,SUSPENDED,CLOSED),PENDING_RESPONSE,Set.of(PROCESSING,SUSPENDED,CLOSED),PROCESSING,Set.of(SUSPENDED,PENDING_CONFIRM,CLOSED),SUSPENDED,Set.of(PROCESSING,CLOSED),PENDING_CONFIRM,Set.of(CLOSED,PROCESSING));publicbooleancanTransferTo(TicketStatustarget){if(targetnull){returnfalse;}returnTRANSITIONS.getOrDefault(this,Set.of()).contains(target);}}差别在哪不在行数在于backlog这个字段和canTransferTo这个方法。backlog字段背后是老陈那句挂起的单子不算积压这是个纯业务口径不是技术判断。以前我会把这种逻辑写在 SQL 的where status in (...)里写死一个字符串集合改一次口径要翻三个地方。现在它就在枚举上统计口径变了只改一处。canTransferTo背后是已关闭不能重开这条规则。这条也是问出来的——我问他关错的单子怎么办他想了半天说那就重新提一个别改老的改老的审计说不清楚。这种话你不问他一辈子不会主动跟你说。另外提一句我在 Service 层会这么用它// 状态流转统一收口不要在 Controller 里各写各的 ifpublicvoidtransfer(LongticketId,TicketStatustarget,LongoperatorId){TicketticketticketMapper.selectById(ticketId);TicketStatuscurrentTicketStatus.valueOf(ticket.getStatus());if(!current.canTransferTo(target)){thrownewBizException(不允许的状态流转current.getLabel() - target.getLabel());}ticket.setStatus(target.name());ticketMapper.updateById(ticket);}这十几行代码省掉了我后来至少三次线上扯皮。哪些事AI替不了你必须自己扛用了这么久/需求分析我也摸清楚了它的边界。有三件事它做不到或者做不好得我自己接。一、它不知道你公司的政治和潜规则。模型能问出不同角色看到的数据范围一样吗但它问不出这个数据其实老板不想让 A 组看到。能不能问出来取决于你知不知道该往这个方向想。需求文档里那类某某领导要求先不开放只有人能补。二、澄清问题的答案最终必须由业务方拍板不是你替他答。我犯过这个错。它问我挂起单是否计入积压我自作主张选了计入因为我觉得这样统计更完整。上线一周老陈来找我说数据对不上他们手工表的口径。我只能改回去。现在我给自己定了条规矩凡是涉及业务口径的澄清问题一律回头发给业务方确认不自己填空。AI 负责把问题列全我不负责替业务做决定。三、本期不做的清单得你顶住压力去守。模型会根据你的回答把范围写进文档但业务方中途加需求的时候第一个找的是你不是文档。文档写清楚本期不做附件上传两天后对方说就加个小功能嘛你要是不挡那份文档立刻作废。回到开头那个问题转全栈到底该从哪开始学我的答案现在很明确如果你的目标是能独立把一个需求从 0 做到上线那第一个要练的不是 Vue是把一句话需求拆成一份能评审的清单的能力。Vue 你花两个月一定能学会它有边界。需求澄清没有终点而且它直接决定了你那两个月学的东西能不能换成业务认可。我现在的顺序是这样的供参考拿到需求先写下来一句话也算丢进/需求分析让它把模糊的地方反问出来把反问清单发给业务方逐条确认尤其是口径类和范围类拿到需求文档和业务设计文档自己再读一遍重点看有没有替业务方做决定的地方确认之后再动/前后端设计然后才是前端开发和后端开发最后说一句我这两年最深的体会前端页面做得丑一点业务方会让你改样式需求理解错了业务方会让你重做。前者是几个小时的事后者是几周的事。先问清楚再写代码。这句话我贴在工位上。关键词Java转全栈、飞算JavaAI、需求分析、全栈开发、后端转前端、需求澄清