這一年我帶著 AI 做了八個案子。兩個失敗、三個做到了、三個還在跑——而它們出自同一群人、同一段時間。
案子做了四個月,最後客戶要求重做。我們照 Prototype 做了,AI 沒有違反任何一條寫下來的規則。
案子功能全對、測試通過、單元測試覆蓋率 85%,我們拿到兩三百頁的開發規範還把它做成機器檢查——客戶說不符合規範,因為他真正在用的那套,跟他給我們的文件不一樣。
這兩件事教會我兩句話:在建造之前,要先明白你要建造什麼;你很在意的東西,務必要講清楚。
從客戶對 AI 沒信心,到用一套嚴謹的程序把它做到可以交付,這一年多的修煉,就是把「AI 能不能用」變成「我憑什麼說它是對的」。
這一兩年,「用 AI 開發」已經不是一個要不要的問題了。 我自己接的案子裡,從去年開始幾乎每一個都有 AI 參與——分析舊系統、產需求文件、寫程式、補測試、修...
昨天說這一年八個案子裡有兩個失敗、三個做到了,而兩邊出自同一群人。今天先拆失敗的那一個。它是整個 Part 0 的主案例,後面幾天的數字幾乎都從它身上來。 那個...
同一個原因,修了 20 次 昨天說三種失敗的共同點是「都沒有訊號」。而沒有徵兆的失敗並不會自己消失。它們只是被延後,然後全部堆到某個時刻才出現。 專案來到第三個...
昨天講的是發現:那些問題單的數量,跟真實的問題數量沒有關係。 今天講另一半:那些已經被發現、也已經被修好的問題,後來留下了什麼。 答案是:幾乎什麼都沒有。 兩類...
昨天談的是 AI 總是一個口令一個動作的處理 Bug,沒有累積,不會隨著經驗變多而增長。 今天往上游走,走到它們(Bugs)被種下去的那一刻。 Day 02 的...
昨天講的是 AI 做得太少——很多份讀取程式規格後的需求只有 50 行。 今天講相反的:AI 做得太多。 而且我認為這個問題更難處理,因為做太少你看得出來,做太...
今天講一種更難處理的:規格說了,而且說了兩件不能同時成立的事。這一種的難處在於,它不是「AI 做錯了」。是這個案子從一開始就沒有一致的判準,而沒有人發現。 規格...
轉換一個場景,到另外一個專案! 同一個團隊、差不多的時期,另一個大型系統的遷移案。這個案子的失敗方式,跟前面那個剛好相反。前四天講的那個案子是:功能做錯了。多欄...
Part 0 倒數第二天。 先回答昨天那個問題:哪一個案子先發生? 是昨天那個。 這系列裡我一直用「第一個案子」稱呼設計稿那個、用「第二個案子」稱呼昨天那個開發...
Part 0 最後一天。 前六天講的是「哪裡出錯了」。今天要問一個更難的問題,而且我到現在都還沒有完整的答案: 當一條指令要 AI 同時處理很多不同維度的事情...