鐵人檔案
當 AI 能快速產生程式碼，開發者的價值該如何重新理解？本系列用 30 天，從需求釐清、程式設計、資料與狀態，到測試、安全、部署及維護，透過實際情境，探討開發者仍需掌握的核心觀念。我們不只關心程式能不能執行，更要學會判斷問題是否解對、結果如何驗證，以及系統是否值得信任。工具與實作方式會改變，但軟體開發裡需要理解的問題、做出的取捨，以及承擔的責任，仍然存在。
在軟體開發中，我們已經能把規格文件、架構背景與既有程式碼餵給AI，讓它協助梳理設計、生成實作，甚至撰寫測試。但隨著AI產出程式碼的速度遠超以往，一個根本問題浮上...
使用者提出的功能，真的能解決他的困難嗎？ 假設我們維護一套接單系統。使用者送出訂單後，系統會呼叫庫存服務扣減可售數量，再更新訂單狀態。某天，營運人員提出需求...
需求已經確認，現有系統撐得住嗎？ 昨天透過訂單與庫存服務的例子，談到「重新處理」按鈕背後，其實是營運人員希望能查明異常結果，並自行接續處理。今天把這個例子往...
昨天談到批次重新處理訂單時，需要核對庫存服務的容量。假設團隊評估後，決定讓批次工作先排隊，再以受控的速率處理，營運人員稍後查看逐筆結果。 流程看起來很完整：勾選...
如何比較效益、成本，以及不做的代價？ 前幾天從「重新處理」按鈕，談到批次操作與排隊期間的狀態變化，需要照顧的地方越來越多。 今天先往回看：營運人員原本的困難...
如何把完整需求拆成自己能理解、實作與驗證的問題？ 昨天談到自動恢復的效益與成本。決定要做之後，接下來就是把需求轉成實際的程式修改。 「完成自動恢復」是一個目...
這一行取得庫存，下一行就拿來判斷能不能接單。這個判斷成立嗎？ 維護訂單系統時，可能會看到這一行： var stock = await inventory.G...
AI能幫忙取名字，也能發現命名異常。我們需要懂的，是這個名字在系統裡代表什麼。 昨天談到，同樣叫做庫存，可能是在庫量，也可能是可售量。名稱提供了理解的起點，...
一段修改狀態的程式，誰能改？什麼狀態能改？哪些入口可能繞過檢查直接改？ 除了確認條件寫得對不對，也要看這段判斷放在哪裡，以及其他功能會不會經過它。這是從一段...
取消出貨的API回傳成功，客服畫面就可以顯示「已取消」嗎？要看這個成功，代表取消已完成，還是系統已經收到要求，準備稍後處理。這個差別會直接影響後面的程式。畫面要...
