「客戶永遠是對的」！

對你個頭。很多客戶根本不知道自己要什麼，只會天馬行空地亂開需求，公司裡部分的團隊只在乎業績的話，會對這些無理要求照單全收，然後跑來跟技術團隊說：「這個客戶很重要，你就加個 IF 判斷式 Workaround 一下，很快啦。」加你個頭，系統架構就是這樣被你們這群不懂技術的人給玩爛的

回顧 Day 01 那個被外包猴子兵團鬥走的 Tech Lead L。他當初為什麼會寫出那個充滿漏洞的產品？根本不是他技術不行，而是因為業務端接了一個瘋子的 B2B 客戶。

當時系統的底層架構明明是走非同步（Async）的 Event-driven 設計，客戶卻硬要一個「保證絕對即時、立刻回傳結果」的 API，而且完全不給時間重構。L 為了顧全大局，被高層逼著在非同步的架構上，硬生生焊上了一個會 Block 住整個 Thread 的同步機制。

結果呢？一上 Production，遇到流量尖峰，Thread Pool 瞬間被咬死，整個系統大當機。這時候那些當初逼他妥協的高層跟 PM 全都不見了，反而是外包的 QA 猴子跳出來抓著這個「系統不穩定」的 Bug 大作文章，把 L 批得體無完膚。

這就是軟體業最可悲的鬼故事：妥協的是你，寫出垃圾的是你，最後揹黑鍋、被鬥走的還是你。

在工業工程裡，防呆機制（Poka-Yoke）不只用在機器上，更要用在「需求變更管理」上。身為工程師，你不能只有技術，你必須學會用流程跟白紙黑字來保護自己。

當他人破壞架構的需求來找你時，不要再當逆來順受的爛好人，請直接啟動以下防禦機制：

1. 強制簽署技術債切結書（ADR）
   任何破壞現有架構的 Workaround，必須寫成 Architecture Decision Record (ADR)。在文件裡清楚標明：「這個做法違反系統設計原則，預計會在超過 1000 QPS 時導致系統崩潰。」然後，把這份文件丟給其他大官，要求他們在上面留紀錄 Approve。要死大家一起死，不要把責任全部推給工程團隊。

2. 用系統邊界（API Contract）當擋箭牌
   不要用嘴巴拒絕，用系統的物理限制來拒絕。在 API 的介面設計上，嚴格鎖死 Request 的格式與 Timeout 時間。客戶想塞不合規格的資料？系統直接噴 400 Bad Request。有人來吵？你就指著 API Spec 說：「這是跨部門定義好的 Contract，要改可以，請發起跨部門架構審查會議。」