看著那些剛畢業的菜鳥工程師，每次開完會就被拍拍肩膀說「那個功能很簡單，你順手改一下就好」，然後傻傻地跑回座位改 Code，我真的覺得他們是在找死。在工廠裡，沒有工單（Work Order）就擅自改動，出事了是會被直接火掉的。但在軟體業，一堆工程師把這種「沒有 Ticket 就改 Code」的行為當作是高效率、好溝通。等到系統上線炸掉，別人一句「我當初不是這樣說的」，你就準備背黑鍋背到離職吧。

科技業最恐怖的鬼故事，往往不是什麼高深莫測的 Bug，而是「需求羅生門」。

阿姨以前在一家新創，部門以前有個熱心過頭的新人，某天下午 PM 走到他位置旁邊，口頭請他把購物車的運費計算邏輯「微調」一下，說這是大老闆急著要的。新人想說幫個忙，連 Jira Ticket 都沒要求開，直接改完發 PR 推上線。

結果到了週末，那個微調的邏輯跟原本的促銷系統產生衝突，導致全站運費全部歸零。老闆氣瘋了，徹查是誰改的。PM 在檢討會議上直接裝死：「我只是請他評估看看，誰知道他連測試都沒做就直接推上 Production？」

新人百口莫辯，Git Blame 上的名字就是他，沒有任何文件能證明這是 PM 強壓的需求。最後新人背了個大過，黯然離職。

這叫「缺乏可追溯性（Traceability）」。身為大廠工程師，你的第一要務不是寫 Code，而是建立完美的免責防禦工事。

面對模糊的需求或口頭交辦，請立刻啟動以下防呆機制：

1. No Ticket, No Work
   任何人找你改任何東西，哪怕只是一個標點符號，請他先去 Jira 開卡。如果不開，你的回覆永遠只有一句：「請把需求寫進 Ticket，指派給我並押上 Priority，我才會排進 Sprint。」用死硬的流程來過濾掉那些連文件都懶得寫的垃圾需求。

2. 在 Issue Tracker 上建立「結案邊界」
   當你收到一張寫著「系統很慢，請優化」這種智障 Ticket 時，絕對不要直接開始寫 Code。你必須在 Ticket 底下留言建立明確的 Acceptance Criteria（驗收標準）：「預計將 API 回應時間從 2 秒優化至 500ms。若超過 500ms 係因第三方資料庫連線導致，不在本次優化範圍內。」
   留言後，Tag PM 與 QA 要求他們確認。只要他們回覆了 OK，這張 Ticket 就成了你的免死金牌。

3. 善用「As Designed」與「Won't Fix」
   面對外包猴子 QA 亂開的 Issue，不要浪費時間跟他們吵。直接在 Ticket 貼上系統規格書的連結，附上一句「Behavior works as designed (系統行為符合預期設計)」，然後把狀態改成 Won't Fix 關卡。把皮球踢回去，讓他們自己去證明為什麼這是 Bug。