標題先罵同事、再推外掛：一則 V2EX 貼文，把「mock 該怎麼寫」吵了一遍

開發者社羣 V2EX 上出現一篇標題很有情緒的貼文：「我的前端同事開發聯調時竟然還在代碼裡寫臨時的 mock 資料！」發文人 Veliqo 描述了一個許多工程師都見過的場景：聯調介面時自己在程式碼裡寫死一份假資料，提測時再刪掉，甚至忘記刪就提交上去了。話鋒一轉，他介紹了自己做的 Chrome 外掛 reqix，可以直接在 DevTools 裡建立 mock 資料、修改請求與回應的 header、攔截請求、注入腳本，完全免費、免登入、資料存在本機。

看起來是一次常見的自薦分享，但這篇貼文接下來的走向，比外掛本身更值得看。

留言區先質疑的，是標題

貼文發出後沒多久，質疑聲就來了。有人直說「很討厭標題黨，尤其是這種推廣自己做的東西的」；有人問這到底是不是軟文推廣，認為該發到推廣節點；也有人回了句更直接的「這跟前端有什麼關係嗎？你後端就不會寫 mock 資料了」。

Deliqo 的應對算是誠懇。他先補充說明自己標題下得不恰當，下次會簡單直接介紹作品；面對批評的網友，他送上站內銅幣致歉，並解釋「分享創造」節點本來就都是介紹自己產品的貼文。幾小時後他再補充，承認標題黨的批評、說明外掛功能其實涵蓋更多，最後表示這款外掛不會再在 V 站推廣，感謝大家批評指正。一場推廣，就這樣在半天的來回之間收了場。

更有料的討論：AI 時代還要手動 mock 嗎

標題爭議之外，留言區其實冒出了一個真正有共鳴的技術話題：現在還有人手動寫 mock 嗎？

有網友直接斷言，未來一個大模型對話框就是全部，skill、MCP 這些東西都會成為歷史。也有人分享自己的做法，已經是寫好 skill 讓 AI 根據前端程式碼邏輯自動 mock 各種場景的資料，並建議原po考慮把能力做成 MCP 暴露出來，而不是做 Chrome 外掛。這樣的工作流並非空談，先前掘金上就有工程師分享過遷移代碼倉時用一批 skill 取代 MCP 的前端 AI 工作流，可見「讓 AI 生成假資料」確實已經是一批人的日常。

原po的回辯也反映了另一種務實立場：AI 可以一把梭，但總有需要修改介面資料、驗證測試的場景，總不能每次改個數都去找後端；真正的生產專案不能完全交給 AI，人工驗證的環節仍然要兜底，這時候攔截請求、改回應的工具就有用武之地。

也有單純的疑問派留言：「不寫 mock 資料，怎麼測試？」得到的回答是：不在程式碼裡寫，透過外掛來建立和管理 mock。工具派與 AI 派各自的理由，剛好把這個議題的兩面都攤開了。

順帶一提的辦公室生態

討論串裡還有一則跑題跑得很有畫面的留言：有網友說這算什麼，他有同事在程式碼註解裡罵主管，甚至把罵主管的話提交到測試環境，最後是從資料庫裡看出來的，人名還都用首字母代替。

從「mock 忘記刪」到「註解放不上檯面的話」，這條支線提醒了一件事：臨時資料與臨時文字只要寫進程式碼，命運往往就不是由寫的人決定的。

一個免費小工具的推廣貼，半天內經歷了標題炎上、作者道歉、AI 工具路線之爭，最後以「不再推廣」收尾。外掛本身能不能留住用戶還未知，但這串留言已經替「該怎麼優雅地介紹自己的作品」留下了一個現成的教材。