開發觀念基礎
後端在守什麼
後端是這次請求的守門人。它聽得懂輸入，但不該相信輸入自己帶來的結論。
請求進來的時候它在做三件事
第一，它收下這次請求：誰送來的、送了哪些欄位、缺了什麼。第二，它套用你們已經講好的規則：七天內、未拆封、有訂單編號，才有資格進退貨。第三，它去跟別的系統說話，例如訂單系統，把事實問回來，而不是請前端順便帶一包「我記得是這樣」。
PM 會寫的驗收句，大部分其實是後端的工作：「空白單號不准產生退貨結論」「超過七天就不可退，不要寫得比較婉轉」「訂單系統沒回答時，轉人工，不要猜」。這些句子若只寫在畫面上的提示文字，換一條路進來就失效。
為什麼不能只信前端
前端在別人的瀏覽器裡。小安可能手滑，顧客可能改了網址，另一個系統可能跳過你的畫面直接呼叫。就算大家都是好人，畫面也可能是舊的：你早上改了規則，她的分頁還開著昨天的版本。所以後端要重算，不接受前端捎來的「可退：是」。
這不是不信任客服。這是把規則放在一個你部署得了、記錄得了、回滾得了的地方。前端負責把話說清楚，後端負責同一個輸入永遠走出同一個該走的結果。兩個人都善良，但只有一邊適合當法官。
跟別的系統說話，也是它的工作
退貨結論通常不是後端自己發明的。它要問訂單系統：這張單存在嗎、下單日是哪天、是不是已經退過。問不到的時候，規則要事先寫好：停下來，交給人。不要為了演示順暢，在問不到時回一個看起來很完整的可退。
你跟工程師對這一段，可以只用三句：問誰、問不到怎麼辦、回答跟前端說的不一樣時聽誰的。聽誰的，答案幾乎總是後端剛剛問到的事實，不是畫面上記得的那一句。
範例 · 一個會出事的省事法
有人為了演示快，讓畫面自己判斷「下單日在七天內」，然後只送一句可退給後端。後端看到可退就去建退貨單。
- 小安的電腦日期被改過，畫面就算錯了。
- 另一個入口沒有這個畫面，規則根本沒跑。
- 該停的地方：後端自己問訂單日期，自己算七天，畫面只負責把結論顯示出來。
練習
寫三條你希望「不管從哪個入口進來都要成立」的規則。每一條補上：問哪個系統、問不到時做什麼。
若你寫不出問不到時做什麼，那條規則還不能上線。先寫停下來，不要寫「模型看情況」。
完成的時候
- 你能說明為什麼「畫面已經判斷過了」不夠。
- 你用退貨例子寫出一條後端必須重算、不能照單全收的規則。