先把AI按住不讓它寫code：美團筆試8887這份攻略，為何在校招圈瘋傳

校招季的牛客網，向來是考生們的情緒集散地。考完集體吐槽的場面年年都有，像先前六級考後那句「寫譯我討厭你」衝上熱搜一樣，考試結束的鐘聲還沒散，討論串已經排滿。不過這兩天在討論區被反覆轉發的，是一篇不太一樣的帖子：有人把「美團筆試8887」這類工程題的做題流程，整理成了一份近乎標準作業程序的攻略，開頭第一句就很有畫面感：先把AI按住，不讓它改程式碼。

這份攻略在解決什麼問題

美團的8887題型屬於工程實作題，給一份README和一個專案骨架，考生要在限時內把服務跑起來、通過公開樣例，最後由隱藏測試給分。原帖作者觀察到的痛點很具體：這種題最容易掛掉的地方，往往不是某個演算法不會，而是AI漏掉了一句看起來不起眼的約束。

原帖列舉的坑包括：請求欄位要嚴格校驗、失敗請求不能留下中間狀態、同一個冪等鍵重複請求要穩定回傳、已完成的狀態不能亂改、批次操作影響多個物件但整體只能提交一次、列表順序與版本變化必須穩定。這些規則單看都不難，疊在一起就開始套娃。公開樣例可能照樣能過，隱藏測試就會突然教育你。

攻略的第一步，是先讓AI讀README但不準動手，把需求整理成一份實作清單，寫進plan.md，分成實體與狀態、介面與欄位、校驗與錯誤碼、冪等與回滾規則、級聯修改、排序與精度這幾類。不確定的地方回原文核對，不準AI自己補預設規則。然後再讓AI換一個身分當需求評審，逐條對照找遺漏，一樣先輸出問題清單，不寫程式碼。

四段式推進：能啟動，比看起來厲害重要

真正讓這篇帖子被轉發的，是接下來的節奏感。原帖反覆提醒，別一開口就對AI說「把整個專案全部實作」，那樣經常得到一份表面完整、裡面漏水的程式碼。檔案一多，AI還特別容易修A壞B。

攻略的做法是切成四段，每段只做一件事，做完就啟動、測試、看結果。

第一段目標壓得很低：程式入口、服務啟動、最基礎的連通介面、基礎實體、統一JSON回應、路由分發、最基本的欄位校驗。能啟動、冒煙測試別掛就算達標。原帖的說法是，不要還沒跑起來就設計十層抽象。

第二段才上核心業務模型，處理實體關係、狀態選擇、規則匹配、遞迴層級、計算精度和穩定順序。這裡的關鍵提醒是：別只跟AI說「實作核心邏輯」，要把必須維持的性質一併說清楚，例如結果要可復現、回傳順序要穩定、多條處理路徑的結果要按題意合併。否則AI很容易寫出一份「這次剛好能跑」的邏輯，第二次請求結果順序就變了。

第三段是狀態變化與歷史記錄，原帖形容這一塊往往才是真正的難點：歷史記錄要按題目要求保留，不能順手覆蓋；已完成狀態再次變化要走規定的補償流程。攻略的做法是先要求AI講清楚資料流和回滾範圍，確認它大概明白了再放手寫。第四段最後補批次操作、一致性檢查、冪等衝突和全量原子回滾。

報錯可以貼，但不能只會「幫我修」

攻略的後半段談除錯，同樣是分級思維。原帖把失敗分成四組：P0是服務無法啟動、語法錯誤、介面格式錯誤；P1是輸入校驗、冪等、失敗原子性；P2是基礎業務規則和計算正確性；P3是跨模組依賴、狀態回放、批次快照這類互動問題。每次只處理P0，限定修改與錯誤直接相關的檔案，不重構、不改既有介面。

原帖也留了餘地：偶爾把完整報錯貼給AI沒問題，報錯本來就該讓AI看。關鍵是貼完要補一句自己的判斷，哪怕只是「我懷疑失敗回滾不完整，先檢查狀態有沒有殘留」，也比一句「幫我修」強得多。

最有意思的一條，是當某一輪分數完全沒變時該怎麼辦。攻略的答案是別機械地說「繼續修復」，而是讓AI停下來重新歸因：失敗規則對應哪段狀態變化、當前實現在哪一步違反了規則、為什麼上一輪修改沒生效、最小修復範圍是什麼、如何構造一個本地用例驗證根因。

走紅的原因：它把考生從搬運工變回工程師

這篇帖子會被瘋傳，某種程度上反映了這一兩年AI輔助做題的集體經驗。拿到限時工程題的人，多半都經歷過那種循環：把報錯貼給AI、AI打補丁、再貼、再補，分數紋絲不動，時間先燒完了。原帖提供的價值，是把「用AI」從祈禱式操作變成有節奏的流程控制，先拆需求、再分段實作、錯誤分級、無效就重新歸因。

換個角度看，這份攻略真正訓練的並不是提示詞技巧，而是工程判斷：知道什麼時候該讓AI停、知道失敗要分類、知道每一步要有可驗證的結果。這些恰好也是隱藏測試在考的東西。原帖作者自己也說，這套流程只是相對穩一點的版本，僅供參考，還註明了文中有借助AI潤色。

在筆試允許使用AI逐漸成為常態的現在，牛客網上這類方法論帖的走紅，說明考生社羣已經走過了「AI會不會取代做題」的爭論階段，進入更實際的階段：怎麼當一個合格的AI監工。這題沒有標準答案，但先按住AI別讓它亂寫，大概是眼下最多人認同的第一步。