Java转全栈一年后我觉得最难补的其实是产品思维一年前我以为最难的是 Vue现在我知道不是去年这个时候我给自己列了张转全栈的学习清单Vue3、ElementPlus、Pinia、Vite、Axios、CSS 布局、Node 环境。清单上全是技术名词我当时笃定地认为只要把这些啃下来我就能从写接口的人变成做功能的人。一年过去这些技术我确实都会了。现在给我一个中等复杂度的管理后台从建表到上线我能一个人扛下来。但如果要我说这一年补得最费劲的是什么答案一个技术名词都没有。真正卡住我的是另外三次一次是产品让我做借阅逾期提醒我做得特别完整——定时任务、站内信、邮件通知全上了上线两个月没人看因为我没问一句逾期之后用户到底要干什么一次是我把一个弹窗的确认按钮放左下角、取消按钮放右下角被设计同事提了三次我到第三次才反应过来这不是审美问题是使用习惯还有一次是我把借阅、预约、续借做成了三套独立的表和接口三个月后产品说要加续借次数限制我改了三天因为这三个东西本质上是一件事我当时根本没看出来。技术栈可以速成产品思维只能慢慢磨。这句话我以前在博客里见过当时觉得是鸡汤现在知道是事实。先复盘这一年我到底补了什么我把自己这一年补的东西按学的时候以为的难度和实际卡我的程度排了个序结果挺打脸的补的内容我以为的难度实际卡我的程度大概花了多久Vue3 语法和组件高低两周路由 / 状态管理 / 权限高中一个月CSS 与页面布局中中断断续续两个月前端工程化Vite、代理、打包中低一周数据库表结构设计低我本来就熟高一直没补完接口契约设计低高一直没补完产品思维没意识到要补最高还在补用户体验判断力没意识到要补高还在补业务抽象能力没意识到要补高还在补看最后三行——我列的原始清单里一条都没有。这不是清单写得不好是当时我根本不知道自己不知道。四个模块各能把你推到哪一步这一年我用飞算JavaAI 的完整链路——/需求分析→/前后端设计→/前端开发→/后端开发——做了几个项目。用得越多我对每个模块的能力边界看得越清楚。工具能推你到某个位置但那个位置之后必须你自己接管。需求分析它能把话问清楚但问不出值不值得做/需求分析最让我意外的是它的问题澄清机制。你把一段模糊需求丢进去它会针对边界发起追问你回复之后它才产出需求文档和业务设计文档。我第一次用的时候感觉像配了个会追问的产品经理。但它的追问是有边界的它追的是逻辑完备性不是商业价值。它会问逾期提醒提前几天发送不会问逾期提醒这个功能有没有人需要。前者是需求文档里的必填项后者是做不做这件事的判断。换句话说它保证的是需求描述没有漏洞保证不了这个需求是对的。必须自己接管的部分这个功能上线后谁会用、用的频率多高、不做会怎样。这三个问题它一个都答不了你得自己去找业务方聊或者自己去看数据。我现在的做法是拿到需求文档后先自己在文档开头加一段为什么做这件事写不出来就回去问。前后端设计它能给出规范的设计但给不出你的历史约束/前后端设计依赖需求分析产出的文档输出数据库设计、接口设计、技术栈决策这一整套。生成的 ER 图和接口文档确实规范字段类型、索引、外键关系都考虑到了接口也遵循 RESTful 风格。它的边界在于它设计的是应该有的系统不是你现有的系统。它不知道你公司有三张表是五年前外包做的、字段名是拼音缩写不知道你们所有接口必须带tenantId不知道你们有个老系统要通过视图同步数据。这些约束不在需求文档里只在你公司的历史里。必须自己接管的部分存量数据的兼容性、跨系统的字段对齐、以及那些技术上不合理但组织上必须这么干的妥协。设计文档给你的是理想态落地是妥协态中间这段路没人替你走。前端开发它能写出高保真页面但交互的分寸感得你来/前端开发依据前端页面设计文档产出代码npm install和npm run dev之后页面就出来了。第一次跑通的时候我挺震撼的表单、表格、分页、弹窗都是完整的样式也像样。但像样和好用之间差着一层。我总结过生成完必须自己改的地方搜索框回车不触发查询、表格加载 300ms 以内的闪烁、批量操作没有二次确认、错误提示用的是后端原始英文、移动端下表格直接横向溢出。这些都不是 bug是分寸感——什么时候该 loading、什么时候该禁用按钮、什么时候该给个乐观更新生成代码给的是通用做法不是你这个场景下的最佳做法。必须自己接管的部分交互细节的分寸、异常状态的呈现、以及最关键的——你自己去把每个页面点一遍。这一步不能省我试过省结果上线当天被反馈搜索之后分页没重置这个问题只要点两下就能发现。后端开发它能写出完整分层代码但业务规则的正确性归你/后端开发遵循接口规范产出 Controller 到 Mapper 的完整代码跑不起来可以用 AI 工具箱的一键修复。分层、命名、异常处理这些它做得比我手写还规整。它的边界是它按接口文档写代码而接口文档描述不了并发和边界条件。扣库存直接update set stock stock - 1在单线程下完全正确在并发下会超卖。生成的代码里这类问题不少因为它看到的是库存减一这个需求看不到可能有十个人同时借同一本书这个现实。必须自己接管的部分并发控制、幂等设计、边界条件的兜底、以及事务边界的划分。这些代码写起来量不大但每一行都需要你知道系统在真实压力下会怎么表现。最难补的三项能力技术部分不展开讲了教程到处都是。我重点说这三样因为它们没有教程也最容易被忽略。第一项产品思维——从怎么做退回到做不做后端做久了有个职业病接到需求的第一反应是拆解和实现不是质疑。产品说要逾期提醒我脑子里立刻开始盘定时任务用什么框架、站内信表怎么设计。这个反应速度是优点也是枷锁。产品思维本质上是一种后退一步的能力在做之前先问这个功能解决谁的什么问题、有没有更轻的解法、做完之后怎么判断它有效。我开始练这个能力的方式很笨拿到需求先写一段如果做完了没人用最可能的原因是什么写完再动手。借阅逾期提醒那个功能如果当时写了这段我大概会发现真正的问题是逾期罚款规则太重用户宁愿逾期也不还加提醒根本没用——后来产品把罚款改成阶梯式逾期率直接下来了。这个能力难补是因为它要求你从执行者视角切换到决策者视角而你过去几年积累的所有成就感都来自执行得快、执行得好。第二项用户体验——看不见但摸得着的那一层用户体验对后端来说是最陌生的一块因为它没有对错只有合适不合适。代码报错你一眼能看出来按钮位置不对你看不出来。我踩过几个具体的坑删除操作放在列表最右侧相邻位置用户手滑点错表单校验在提交时才触发用户填完八项才知道第一项错了列表加载的时候整个页面白屏一秒没有骨架屏。这些都是我做完之后别人提醒才知道的。我后来给自己定了条规矩任何页面做完自己用真实数据完整走三遍第一遍正常流程第二遍故意填错第三遍用手机。三遍走完八成的问题会自己冒出来。这比学任何设计规范都管用。第三项业务抽象——把三件事看成一件事的能力这是三项里最难说清楚的一项因为它没有可观测的产出。借阅、预约、续借在我当时的认知里是三个功能于是我做了三套表、三套接口、三套前端页面。三个月后产品提了个需求续借不能超过两次且预约中的书不能续借我改了三天。事后复盘我才意识到这三件事本质上是同一个领域对象——“用户对某本书的使用权”区别只在有效期和状态流转。如果当时抽象成一个book_usage模型加状态机那个需求半天就能改完。业务抽象难补是因为它需要你见过足够多的变化才知道哪些东西会变、哪些不会。这个没有捷径只能靠做完之后复盘——每当你改一个功能花了超出预期的时间就回去问一句是不是当初抽象错了。我这个习惯坚持了大半年判断力确实有提升但离一次做对还差得远。一份不带滤镜的学习顺序表如果让我重新排一遍这一年的学习顺序我会这么排。注意前四步是工具能帮上大忙的后三步基本只能靠自己阶段补什么工具能帮多少怎么练达标标准1需求表达与边界澄清大/需求分析的澄清机制每次需求先写清边界再动手前端看完文档不用再问你2数据库与接口设计大/前后端设计拿生成的设计文档对着老项目挑毛病接口一次定稿后期不改字段3前端工程跑通大/前端开发亲手npm install、改代理、点一遍页面能独立把生成结果改成能用的4后端代码落地与排错大/后端开发 一键修复记录每次报错建自己的排错清单常见错误十分钟定位5并发与边界意识小每个写接口问一句并发下会怎样能主动发现超卖、幂等问题6产品思维几乎没有动手前写没人用的原因敢砍需求能说清为什么7用户体验判断力几乎没有每个页面走正常/异常/移动端三遍别人不再给你提交互问题8业务抽象几乎没有每次返工复盘是不是抽象错了新增需求时改动集中在一处前四步大概三到四个月能过后四步我走了一年还在走。这一年我改掉的三个想法从我会什么变成这个能不能不做。以前接到需求想的是怎么实现现在想的是不做行不行、用现有功能凑一凑行不行。这个转变让我的工作量少了大概三成但交付的东西反而更被认可。从接口通了变成点一遍试试。后端出身的人对联调通过的定义是接口返回 200 且数据结构对。全栈的标准是用户能顺利完成任务。这两个标准之间隔着整个体验层。从学新技术变成补判断力。我现在的书架上技术书的比例在下降产品设计和领域建模的书在上升。不是技术不重要了是技术已经不是我的瓶颈了。最后工具能帮你把代码写完但没人能替你决定写什么、写成什么样算好。一句话总结飞算JavaAI 这四个模块能把从 0 到 1这一段铺成高速公路但从 1 到好用这一段路上没有路灯只能靠你自己磨出来的判断力走。给你一份可以直接执行的清单接到需求先写不做行不行写不出理由再动手需求文档开头自己补一段为什么做这件事拿到生成的设计文档对着老系统的历史约束挑一遍毛病前端跑起来之后正常流程、异常流程、手机端各走一遍每个写接口问一句十个人同时点会怎样每次返工超预期问一句是不是当初抽象错了每个季度回头看一遍自己做的功能有多少真的有人用第 7 条最扎心但也是唯一能真正磨出产品思维的办法。