iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
Software Development

當 AI 越來越會寫程式,開發者究竟還需要懂什麼 系列

當 AI 能快速產生程式碼,開發者的價值該如何重新理解?本系列用 30 天,從需求釐清、程式設計、資料與狀態,到測試、安全、部署及維護,透過實際情境,探討開發者仍需掌握的核心觀念。我們不只關心程式能不能執行,更要學會判斷問題是否解對、結果如何驗證,以及系統是否值得信任。工具與實作方式會改變,但軟體開發裡需要理解的問題、做出的取捨,以及承擔的責任,仍然存在。

參賽天數 6 天 | 共 6 篇文章 | 0 人訂閱 訂閱系列文 RSS系列文
DAY 1

Day 01 - 序言

在軟體開發中,我們已經能把規格文件、架構背景與既有程式碼餵給AI,讓它協助梳理設計、生成實作,甚至撰寫測試。但隨著AI產出程式碼的速度遠超以往,一個根本問題浮上...

2026-09-15 ‧ 由 AntonyKao 分享
DAY 2

Day 02 - 程式寫對了,問題卻解錯了

使用者提出的功能,真的能解決他的困難嗎? 接到需求文件時,我們通常會開始想:畫面怎麼做、API怎麼設計、資料要怎麼存。但在動手前,我會先弄清楚這個功能要改善...

2026-09-16 ‧ 由 AntonyKao 分享
DAY 3

Day03 - 需求寫得很清楚,為什麼還不能直接開始寫?

從已確認的需求出發,理解限制、討論取捨,並驗證結果。 昨天透過訂單與庫存服務的例子,談到「重新處理」按鈕背後,其實是營運人員希望能查明異常結果,並自行接續處...

2026-09-17 ‧ 由 AntonyKao 分享
DAY 4

Day04 - 需求沒寫出來的地方,通常最容易出事

如何找出假設、限制與例外情況? 昨天延續營運後台的例子,談到批次重新處理訂單時,需要核對庫存服務的容量,確認正常訂單與批次作業能否一起滿足服務要求。 假設團...

2026-09-18 ‧ 由 AntonyKao 分享
DAY 5

Day05 - 不是每個問題,都值得做成一個功能

如何比較效益、成本,以及不做的代價? 前幾天從「重新處理」按鈕,談到批次操作與排隊期間的狀態變化,需要照顧的地方越來越多。 今天先往回看:營運人員原本的困難...

2026-09-19 ‧ 由 AntonyKao 分享
DAY 6

Day06 - 把大問題切小,是開發的基本功

如何把完整需求拆成自己能理解、實作與驗證的問題? 昨天談到自動恢復的效益與成本。決定要做之後,接下來就是把需求轉成實際的程式修改。 「完成自動恢復」是一個目...

2026-09-20 ‧ 由 AntonyKao 分享