iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
Software Development

綠燈不等於做對:AI 開發的驗收工程 ——從兩個失敗的案子,到驗收交付 系列

這一年我帶著 AI 做了八個案子。兩個失敗、三個做到了、三個還在跑——而它們出自同一群人、同一段時間。
案子做了四個月,最後客戶要求重做。我們照 Prototype 做了,AI 沒有違反任何一條寫下來的規則。
案子功能全對、測試通過、單元測試覆蓋率 85%,我們拿到兩三百頁的開發規範還把它做成機器檢查——客戶說不符合規範,因為他真正在用的那套,跟他給我們的文件不一樣。
這兩件事教會我兩句話:在建造之前,要先明白你要建造什麼;你很在意的東西,務必要講清楚。
從客戶對 AI 沒信心,到用一套嚴謹的程序把它做到可以交付,這一年多的修煉,就是把「AI 能不能用」變成「我憑什麼說它是對的」。

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

Day 21 - 黃金範例:與其寫十條規則,不如給它一個範本

今天講整套流程裡投報率最高的一步。 如果 Part 2 你只做一件事,我建議是這件:準備兩三個修到完美的黃金範例。 理由是 Day 13 提過的那個觀察,今天完...

2026-09-19 ‧ 由 kuokaini 分享
DAY 22

Day 22 - 在 AI 寫完的那一秒攔下來

Phase 3:驗證閉環。這是整套流程的成敗關鍵。 今天講三支腳本。它們全部很短、很土,而且是那個 36/37 能成立的原因。 分層:能便宜擋掉的,就不要留到昂...

2026-09-20 ‧ 由 kuokaini 分享
DAY 23

Day 23 - 規格格式:寫可驗證的行為,不要寫實作步驟

今天講規格格式。 一句話先講完設計原則: 規格描述「可驗證的行為」,不是「實作步驟」。 這句話聽起來很抽象,但它決定了昨天那個「規格覆蓋率」能不能成立。 兩...

2026-09-21 ‧ 由 kuokaini 分享