iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
IT Operation

AI 時代下,如何建立真正可持續的軟體交付能力 系列

AI 讓軟體開發變得更快,也讓團隊更容易看見原本被速度掩蓋的問題。當程式、測試與文件都能被快速生成,真正影響交付能力的,會回到團隊是否理解需求、是否看得懂系統、是否能安全修改,以及是否能在風險擴大前取得回饋。這個系列想討論的,是 AI 進入開發流程後,團隊該如何重新建立判斷、協作、驗證與調整能力,讓速度不只停留在個人產出,而能轉成長期穩定的交付能力。

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

Day 1. AI 開始寫程式後,軟體開發者真正需要補上的能力

AI 正在改變軟體開發的工作重心 從手寫程式到引導生成 時代變了,自從 AI 參與軟體開發後,軟體開發者的日常工作出現巨大變化。過去開發功能時,開發者需要自己查...

2026-08-01 ‧ 由 Zion Wu 分享
DAY 2

Day 2. Vibe Coding 的風險:當理解能力流失後會發生什麼

「能動」不代表可維護 可執行只是最低門檻 使用 AI 進行 Vibe Coding 時,功能很快就能看到成果。畫面可以正常開啟、API 有回應、測試資料也順利通...

2026-08-02 ‧ 由 Zion Wu 分享
DAY 3

Day 3. 為什麼 AI 時代,行為驅動開發(Behavior-Driven Development, BDD)變得更重要

AI 生成程式碼時需要清楚的需求上下文 AI 會替模糊需求補上細節 AI 輔助開發讓程式碼產生速度變快。開發者輸入一段需求描述,AI 就能快速產生一連串相關的程...

2026-08-03 ‧ 由 Zion Wu 分享
DAY 4

Day 4. 從行為驅動開發(Behavior-Driven Development, BDD)規格到結構化提示詞:讓 AI 依照行為規則生成程式

提示詞工程需要回到需求工程 好的提示詞來自清楚需求 提示詞工程(Prompt Engineering)常被理解為撰寫精準的指令,讓 AI 產生符合需求的內容。在...

2026-08-04 ‧ 由 Zion Wu 分享
DAY 5

Day 5. 開發者的護欄:為什麼 Harness Engineering 是 AI 交付的先決條件

什麼是 Harness Engineering Harness 是 AI 生成流程的運行護欄 Harness Engineering 可以理解成一組讓 AI 產...

2026-08-05 ‧ 由 Zion Wu 分享
DAY 6

Day 6. AI 治理:如何建立團隊使用 AI 的邊界與風險控管

為什麼 AI 使用需要治理 個人效率會轉化成組織風險 AI 工具最先改變的是個人的工作方式。工程師可以用 AI 理解程式、產生測試、重構函式與撰寫文件。產品角色...

2026-08-06 ‧ 由 Zion Wu 分享
DAY 7

Day 7. 從寫程式到審查系統:AI 時代的閱讀、驗證與程式碼審查

AI 讓開發者的工作從撰寫轉向審查 程式碼產出增加後,閱讀量會上升 AI 進入開發流程後,開發者花在「從零寫出每一行程式」的時間會下降,閱讀、判斷、驗證與修正所...

2026-08-07 ‧ 由 Zion Wu 分享
DAY 8

Day 8. AI 加速開發後,價值流中的瓶頸會更明顯

AI 讓價值流中的瓶頸較容易被看見 程式碼生成不再是主要等待點 程式碼產出加快後,原本藏在流程中的等待也開始浮現。 過去團隊常將交付速度緩慢歸因於「開發還沒做完...

2026-08-08 ‧ 由 Zion Wu 分享
DAY 9

Day 9. 功能生成越快,需求理解落差的代價越大

AI 如何放大需求理解落差 模糊需求會快速變成錯誤功能 AI 讓功能生成速度變快,也讓模糊需求更快形成具體成果。以前需求寫得不清楚時,開發者會在拆解、設計或實作...

2026-08-09 ‧ 由 Zion Wu 分享
DAY 10

Day 10. Metrics 2.0:AI 時代如何度量開發效能

為什麼程式碼行數(LoC)會在 AI 時代失真 行數增加不代表價值增加 程式碼行數(Lines of Code, LoC)過去常被用來觀察工程活動量。 當開發工...

2026-08-10 ‧ 由 Zion Wu 分享