簡歷上寫滿了組件名，面試官卻只問了一句：登入後購物車應該剩幾件

這兩天滑牛客網的求職板，大概躲不掉一篇長文：「面試官視角，手把手帶大家改一份 Agent 項目簡歷」。發文者是站上熟悉的技術博主「程序員花海」，對象是一份典型的後端項目簡歷：微服務、Redis、消息隊列、限流熔斷、搜尋引擎，連 AI 導購和虛擬線程都上了。乍看什麼都有，點進討論區才發現，大家圍觀的重點很一致：這種簡歷，好像就是上個月的自己。

先把那份簡歷攤開來看

原稿的項目名叫「微服務智慧電商平臺」。商品、訂單、購物車、用戶、搜尋、AI 導購，模組全列，技術棧從 Spring Boot、Spring Cloud Alibaba、Nacos 一路排到 JDK 21。以學生項目的標準看，能接的都接上了。

博主的第一刀卻下在這裡：把這些技術名詞暫時遮掉再讀一遍，每一段都在說「用了什麼」，沒有一段在說「遇到了什麼問題、為什麼這樣設計、出了異常怎麼處理」。

這句話之所以在討論區被反覆引用，是因為它命中了一個普遍經驗。很多人做項目是真的做過，但寫出來之後，經歷變成了組件清單。面試官順著其中一個詞往下追問兩層，回答就開始往背知識點的方向滑，從「介紹我做的項目」變成「默寫八股」。

一個購物車問題，問倒一片

改稿教學裡最出圈的段落，是關於購物車的一連串追問。

用戶未登入時加了兩件商品，帳號裡原本還有一件同款，登入之後應該變成幾件？如果選擇數量相加，登入請求重試一次，會不會又多加兩件？規格、商家或附加服務不同，還能不能合併到同一行？

這些問題沒有一個涉及新技術，全部來自最日常的使用場景。但沿著問下去，立刻觸及商品行怎麼建模、合併規則怎麼定義、重複請求怎麼處理。博主用它說明一件事：真實電商的每個業務領域都有得挖，學生項目的問題往往是每個領域都只做了增刪改查，把組件接一遍，看起來完整，實際沒進去。

湊單的例子更直觀。滿兩百減三十的活動，購物車裡有一百八十元活動商品和五十元非活動商品，總額兩百三十元，能提示已滿足滿減嗎？不能，因為活動商品只有一百八十。再加一件二十五元的商品，加的是活動商品，實付會從兩百三十變成兩百二十五；加的是非活動商品，變成兩百五十五。同樣的動作，結果完全不同。活動範圍、勾選狀態、優惠順序、金額由哪個服務計算，全藏在這二十五塊錢裡。

改法：把範圍縮小，把鏈路挖深

博主的建議並不是叫人放棄商城項目。做商城確實能把後端流程串起來，問題在於範圍。他的改法是限定單店鋪、普通實物商品、一種滿減規則，把購物車到結算預覽這一條鏈路做深。光這一條，就足夠講資料建模、併發修改、服務協作與業務一致性。

項目名也跟著改，從「微服務智慧電商平臺」換成「電商下單與商品檢索項目」，把讀者注意力引到實際做完的工作上。簡介同步重寫：面向商品瀏覽、購物車與下單場景構建後端服務，包含哪些模組，接入第三方大模型提供導購功能，完成容器化部署。原稿裡的「全鏈路優化」「提升用戶體驗」這類詞，後面必須有具體數字與場景支撐：多少併發、原來慢在哪、改善了哪個操作。

這波對 Agent 相關經歷的追問力度，其實和先前流傳的阿裏邊緣BU那份一面面經是同一個方向：面試官越來越不滿足於「用過大模型」，而是追你怎麼拆架構、怎麼處理異常。

留言區的共鳴與自嘲

討論區的回應大致分兩類。一類是共鳴，有人貼出自己的簡歷段落，問博主能不能也幫忙看看；有人說看完才意識到，自己的項目經歷全是「負責XX模組，使用XX技術實現XX功能」的句式，一句都經不起追問。

另一類是自嘲式的焦慮。有人感嘆連購物車合併都有這麼多學問，懷疑自己做的項目是不是假的；也有人回頭安慰，這些問題本來就是工作後才會真正遇到的，學生階段能想清楚其中一兩層，已經贏過多數人。

這種「看完焦慮、收藏起來、下次再改」的互動模式，本身也是求職社羣的日常樣貌，和酷安上那則用暗號發文的求救貼一樣，社羣總有自己的方式把焦慮包裝成可以傳播的內容。

一份簡歷教學，為什麼能刷屏

說到底，這篇長文提供的不是新知識。購物車合併、滿減計算、冪等處理，資料網上一搜都有。它真正提供的是一個視角轉換：把讀者放到面試官的座位上，看一份簡歷會被怎麼讀、怎麼問。

對正在準備秋招的人來說，這比任何一份「高分簡歷模板」都實用。模板教的是長什麼樣，這篇教的是會被怎麼問。而後者，才是多數人做簡歷時從來沒想過的事。

至於那些已經收藏文章的人，會不會真的坐下來改一遍自己的購物車邏輯，那就是另一回事了。至少這兩天，牛客網的求職板上有不少人，正對著「登入後應該剩幾件」這個問題發呆。