考試結束鈴響之前，鍋裡的那把火還在燒

9月26日中午過後，牛客網上開始出現一批新的討論串，標題很統一：「9.26京東筆試」。發文的人剛放下考題，有人寫著「8863，最後幾分鐘才第一次提交，沒時間改了」，有人說「8730改到8874，一直roll到一個高一點的分，再讓它根據報錯改」。這一天是今年秋季招募的一場筆試，題目有兩道演算法題，外加一道AI coding。樓主還註明，文字和題目都是用豆包根據原題重新生成的，可能有些錯誤，將就看。

這些數字對廚房來說很陌生，但那種狀態你不會陌生：火已經開了，湯已經在鍋裡，你手上只剩最後幾分鐘。

第一道題是一座鏡子實驗室。n行m列的格子，每格要嘛是空地，要嘛是斜鏡。光線從每個格子、往四個方向各射一次，撞上斜鏡就轉向，一路走到離開邊界才算「逃離」。要算的是，所有可能的起點與方向裡，有幾束光最後出得去。

這題讀起來像光學，做起來像記路。光線在鏡子之間折來折去，方向一次一次被改寫，跟廚房裡燉一鍋東西很像：你以為它在直線前進，其實每次碰到一塊料，路徑就拐了一次。滷包丟進去，湯色往深處偏；冰糖下了鍋，香氣轉個彎往焦糖那邊走。你沒辦法盯著每一束光，只能相信規則，一次一次模擬下去。

第二道題的名字更踏實，叫「封條受力的安全起點」。一排歸檔記錄各有數值，初始值必須是G的倍數、落在範圍[L,R]內，接著依序承受n次增減，任何時刻都不能越界。最後要輸出：符合條件的初始值有幾個，最小的多少，最大的多少；一個都沒有，就輸出0 0 0。

這根本就是調味的數學。一鍋湯上桌前能容忍的鹹度是有區間的，你下手的第一勺是那個「初始值」，後面還要加醬油、加鹽、收汁濃縮，每一步都在往那鍋裡疊加變化。有經驗的人會先留餘裕，起手淡一點，因為鹹了救不回來，淡了隨時能補。題目裡最刺眼的是那個輸出「0 0 0」的情境：沒有任何安全的起點。廚房裡也有這種時候，鍋已經太鹹，怎麼選起點都來不及了，那就只剩下一鍋重新來過的水。

至於第三道AI coding，樓主的做法很直白：把readme整份塞給AI，弄出來一個八千多分的結果，懶得改了，直接交。底下留言一片「8876，抽卡抽爽了」「7776的成績要怎麼看」「為啥我改半天一直是7720」。有人找到了節奏：先讓AI roll出一個偏高的版本，再針對報錯一句一句修，效率會好很多。

這套流程，廚房裡的老師傅看了應該會點頭。第一版機器炒出來的菜不會完美，但先有一個能入口的底，比空著鍋發呆強。然後你試喫，哪裡鹹了補糖，哪裡膩了加醋，錯在哪修哪。盲改不行，對著報錯改才行，這跟對著舌頭的回饋下調味料，是同一種手藝。

留言區裡最一致的關鍵字是「時間不夠」。8770、8864、8871，一堆人卡在八千七到八千八之間，不是不會改，是鈴響之前沒有那幾分鐘了。這跟家宴那天很像：菜都對，火候都懂，就是賓客已經坐下，湯還差最後十分鐘的小火。你只能蓋上鍋蓋，端出現有的樣子。

討論串的相關推薦裡，還連著另一則9月25日晚間的貼文，一位長春大學的Java求職者寫下「秋招徹底失敗」：一個月裡官網投了上百家，溝通了近千條訊息，零面試，決定放棄這一輪。這段話跟筆試分數擺在同一個頁面上，讀起來特別有重量。筆試那端的八千八，跟這端的零面試，是同一場秋天裡的兩張餐桌。

如果你最近也在經歷這種一邊等結果、一邊不知道下一餐從哪裡開始的日子，可以回頭看看我們先前寫的轉正沒過的那個下午，先把冰箱打開。分數交出去之後能做的，往往就是把廚房的燈打開，看看還有什麼，明天從哪一鍋冷水開始煮起。

考試結束的鈴聲不會等你把菜擺完。但鍋子還在，爐火還在，下一場筆試跟下一頓飯一樣，總會再來。差別只在於，這次你已經知道要先讓它roll出一個夠高的版本，再對著報錯，一句一句修。