鐵人檔案
當 AI 能快速產生程式碼，開發者的價值該如何重新理解？本系列用 30 天，從需求釐清、程式設計、資料與狀態，到測試、安全、部署及維護，透過實際情境，探討開發者仍需掌握的核心觀念。我們不只關心程式能不能執行，更要學會判斷問題是否解對、結果如何驗證，以及系統是否值得信任。工具與實作方式會改變，但軟體開發裡需要理解的問題、做出的取捨，以及承擔的責任，仍然存在。
客服建立一張訂單，平常不到一秒就能完成，最近卻經常等上三秒。資料有存進去，金額也正確，畫面最後都顯示成功，但每接一通電話，都要多等一下。 這時已經有值得處理的效...
建立訂單的監控圖上，超過三秒的操作比例從平常的2%升到20%。資料持續收集，儀表板也畫出了變化，但如果沒有人正在看，團隊可能還是等客服打電話才知道。 有數據可以...
建立訂單超過三秒的比例升高，監控跳出提醒。客服同時也回報：「剛剛那張訂單等很久。」我們知道系統變慢了，但同一分鐘內有許多人操作，要從幾萬行日誌裡找到他的那一次，...
訂單詳情頁的配送進度，平常呼叫第三方API只要0.5秒，今天卻要等上10秒。沒過多久，連不需要配送資訊的訂單列表，也開始變慢甚至逾時。 配送進度只是補充資訊，暫...
訂單新增了「通知Email」，讓客戶可以指定另一個地址接收出貨通知。沒有填寫時，就沿用訂單原本保存的Email。正式環境如果採不停機更新，兩台網頁主機逐台部署，...
下午兩點，一支批次修正程式把不該納入的訂單也更新成「已取消」。兩點二十分，客服發現異常，但這段時間裡，系統仍持續接單，倉庫也完成了部分訂單的出貨。 正式環境有主...
訂單系統原本只支援全額退款，已收款訂單的付款狀態會從「已付款」變成「已退款」。這次新增部分退款，讓客服可以退回部分款項，付款狀態也增加「部分退款」，原本的「已退...
昨天談到新增「部分退款」狀態時，售後追蹤排程也需要調整，才能繼續納入仍有有效購買的訂單。確認修改範圍後，接著會遇到另一個問題：新增狀態與修改排程，應該放在同一個...
報表匯出服務有個設定：所有工作節點合計，最多同時執行兩份大型報表。尖峰時段有人反映等待太久，團隊準備評估能不能調高上限。 程式看得出數字是 2，文件也寫「並行上...
三十天前，這個系列從一個問題開始：當AI能讀規格、寫程式、補測試，開發者究竟還需要懂什麼？ 一路寫下來，前提一直沒有變：規格是完整的，AI也能照著規格做出來。真...
