牛客網近日流傳一篇標題為「秋招第二掛 小紅書」的貼文，發帖人應徵小紅書PE跨境電商交易平臺崗位，經歷一面、二面與三面（文中稱「+2面」）後未錄取，於是把整輪面試題目整理發布。貼文標籤含「秋招面試記錄」與「小紅書」，依留言時間軸判斷，面試與發文均發生在本屆秋招期間。發帖人在文末附註，內容由AI整理，部分專有名詞因語音辨識錯誤未逐字修正。
一面：背景、專案深挖與兩道技術題
依貼文整理，一面共二十三題，涵蓋六個區塊。背景與求職意向部分包括自我介紹、職業規劃（技術基建或業務方向）與個人興趣。專案深挖聚焦發帖人履歷中的「風控歸因Agent」，追問面向包含：專案背景與解決的問題、架構難點、V1至V3版本的選型推導、如何量化上下文隔離帶來的成本下降，以及「先污染後治理」的設計質疑，即既然可預判Token消耗量大，為何不一步到位而先跑起來再優化。
風控業務認知的題目包括對風控全局的理解、系統架構組成與各系統職責。實習成長與AI實踐部分，面試官問及平日如何學習AI、Claude Code三層架構的實作細節、Harness概念、發帖人稱為「龍蝦OpenCloud」的專案（此為語音辨識訛誤的說法之一），以及大模型訓練的理解與實作經驗。
技術題為一道開放設計題與一道演算法題。設計題情境為電商熱點福利品庫存數十萬觸發秒殺，要求以秒殺鏈路負責人身分設計高TPS方案；追問包含Redis庫存扣減為何用Lua腳本、本地快取與Redis及DB之間的一致性保證、資料庫單行TPS上限的因應，以及一百次請求合併為一次寫入DB的落地細節。演算法題為反轉鏈表，要求口述思路並寫程式碼。
二面：開場先問是否已拿字節offer
二面紀錄顯示，面試官在自我介紹後隨即問「你拿到字節的offer了嗎？」，並問及對小紅書業務的了解與應徵動機。實習經歷深挖聚焦處置平臺提供的能力、治理服務的業務線範圍與一年多來的精力分配。
核心專案環節的追問密度明顯提高，方向包含：歸因Agent解決的具體問題、是否屬於線上風控還是事後研判、以客訴判斷廣告主被風控原因的場景題、是否使用開源框架搭建、為何不基於Codex或CC以Skill方式開發、為何選內部框架而非發帖人提到的OpenClaw或Horus等開源框架、業務收益量化，以及框架在上下文管理與效果評測上各提供多少能力。面試官另問是否調研過CC的Compact與Old Code Compress背後的執行細節、Codex的壓縮方式。
穩定性部分針對履歷上寫的「穩定性技術沉澱」提問。開放性問題包含AI時代下受過計算機訓練者與文科生的差異與自身優勢、最大優點與待改進處，以及工作地點意願（面試官說明團隊主要在杭州與上海）。
值得留意的細節是反問環節後的面試官回饋。依貼文，二面面試官主動問發帖人「一面有沒有回答不好的」，並給出兩點建議：其一，回答太直奔主題、缺少鋪墊；其二，講述時間過長，應適時停頓讓面試官提問。
三面後未錄取，留言區聚焦「隨緣」說法
三面紀錄相當簡短，僅寫「+2面，問了下專案收益、挑戰難點」，末尾一個「掛」字交代結果。發帖人未說明三面至收到結果的時間間隔，也未提供各輪面試的具體日期。
留言區討論目前可見兩類說法。一則留言稱自己「後天面這個」，並表示「感覺現在面試都是隨緣，過不過根本不取決於你」。另一則留言來自發帖人本人，說明內容經AI整理，語音辨識錯誤的名詞未逐一修正。
就崗位輪廓而言，PE在此脈絡下屬工程職類，業務線為跨境電商交易平臺，考題橫跨風控系統、LLM Agent工程與高並發電商設計，與本臺先前整理的小紅書9月27日秋招筆試紀錄中「選擇題加編程題加AI coding」的題型結構可相互對照，反映該公司本屆校招對AI實作能力的側重。同期牛客網上，攜程Java秋招一面面經亦見Redis同步與熔斷設計等後端考點，顯示快取一致性與高並發場景仍是電商類技術面試的共同命題方向。
需要說明的是，本篇面經為單一發帖人自述，面試題目、面試官建議與錄取結果均無法獨立核實；文中的OpenCloud、OpenClaw、Horus等名稱已由發帖人標註可能為辨識訛誤，讀者宜以原始貼文與後續官方或當事人補充為準。