樣例全過、提交歸零：網易這場9月29日筆試，把「有思路」三個字逼成了流行語

9月29日晚間，網易互娛的線上筆試結束後不到一小時，牛客網的討論串就開始長出熟悉的形狀：有人貼出自己沒寫完的解法，有人問「aicoding判分標準是什麼」，有人只留下一句「算法做不出來」。這種筆試結束當晚的集體發文，已經是秋招季的固定儀式，而這一場之所以特別熱鬧，原因有兩個：AI Coding題不顯示分數，以及一道「想得到、寫不完」的算法題。

樣例過了，分數卻是個謎

最先引發困惑的是AI Coding環節。多位考生反映，樣例測試可以通過，但系統沒有顯示任何分數參考。有人回憶，以前做過的筆試裡，AI Coding至少會給出「8888」這類分數顯示，「這次都沒有，不知道該怎麼判斷」。隔天還有新留言繼續追問判分標準，可見這個黑箱讓人不心安。

這種不安其來有自。同一天稍早的另一篇網易互娛筆試討論裡，就有人寫下「用了一個多小時最高還是四十多分」，顯示AI Coding的分數浮動本身就很劇烈。當分數可見時，考生至少能即時調整策略；當分數隱藏時，連「該不該放棄算法題、把時間押去AI Coding」這種取捨都失去依據。

那道設備調度題：思路容易，實作很硬

算法題則貢獻了本串最多的哀號。「思路容易想到但是理清楚寫出來比較困難」「有思路 a 不了」「感覺思路很清晰，但是實作的話真的就是有點複雜」，這幾句話在討論串裡反覆出現，幾乎可以當成這場筆試的註腳。

從留言拼湊，這是一道設備調度類的模擬題。寫得最完整的樓主分享了自己的框架：把樣本抽象成開始與結束兩種事件，用優先佇列維護事件流與等待佇列，再用計數陣列追蹤各類設備的空閒數量。這位樓主點出題目最關鍵的一步，就是抽象出事件之後可以用掃描線的思想處理，避免按時間逐刻枚舉而超時。

其他人的版本各有出入。有人維護三張表：設備數量表、等待分配佇列、運行中佇列，每輪依序檢查釋放與分配，自稱過了；也有人用三個優先佇列、每個時間點遍歷所有設備，過了五成；用Golang的slice與閉包洋洋灑灑模擬一通的，最後過了三成；單純按入場時間排序沒加待處理佇列的，樣例能過、正式測試資料歸零。

「測試能過、用例歸零」為何集體發生

「測試用例早就過了，一提交0%」是另一個高頻句式。有考生事後想出原因：進入等待狀態後需要按優先級排序，自己只按入場時間排，樣例資料恰好沒踩到這個坑，正式測試就現形了。這正是模擬題的殘忍之處，樣例通過只代表主流程對，邊角規則一漏就是全盤歸零。

對照來看，這類「題海與臨場落差」的焦慮並不只在網易這場出現。稍早流傳的浩鯨科技那場近五十題的Java一面，展現的是另一端的極端：題目多到講義翻完一遍。兩種考法方向相反，考生的無力感卻很一致。

一場筆試，一晚的互助現場

值得留意的是這些討論串的功能變化。名義上是發洩，實際上最熱的樓層都是解法交換：事件抽象、掃描線、優先佇列的維護順序，寫得像小型複盤會。有人直言「只刷了hot100做筆試完全不夠」，下方自然有人接著討論該補哪些專題。

這也和牛客網近期的整體氛圍相呼應。從用友校招時間軸被圍觀到各家筆試夜的集中發文，這個社羣在秋招季扮演的角色越來越像一個即時情報站：進度有人曬、題目有人拆、焦慮有人接。至於「應該是沒希望面了」這句留言有沒有成真，討論串裡還沒有後續，只能等下一輪發文揭曉。