鐵人檔案
我是一名 QA。這 30 天，我要替公司做一個能回答「這張票要測什麼、這個改動影響哪裡、當初為什麼這樣決定」的知識庫——零 API 成本、資料不出公司、跑在一台沒有獨顯的筆電上。
但這個系列真正想講的，是過程中我一直撞到的同一件事：AI 產出的東西不是「會胡說八道」那麼簡單，它是大部分正確、少部分錯得很有說服力。
那少部分附了 PR 編號、檔名和條列格式，看起來完全像真的。我把 AI 統整的 18 張卡拿去逐項對照程式碼，抓到 8 處錯誤；其中一條甚至一路走到新人手上，變成一份「假的測試失敗」。
難的從來不是讓 AI 回答問題，是怎麼知道它答錯了。而這正好是 QA 每天
前面兩天講的都是「它為什麼會錯」。 Day 9 說錯誤發生在接線,不在零件。Day 10 說那是因為資料缺了一個維度。 今天要講一件更難堪的事: 那個維度之所...
Day 11 的結論是:事實要從程式碼和實際畫面來。 這個結論有一個很直接的後果——我得讓它看更多東西。 更多程式碼、更多環境、更多實際的資料。 於是下一個問...
昨天講的是什麼不給。 今天講另一半:那些可以給的東西,要放在哪裡。 這個問題聽起來很行政、很無聊——不就是選一個地方放檔案嗎? 但我後來發現,它決定了兩件事:...
前面幾天講的是我怎麼決定「什麼資料不給 AI」。 而在同一段時間裡,我手上還有另一個題目: 一個還在試用期的新同事,要給多少權限? 這兩件事我本來完全沒有放在...
如果你去讀現在大部分談 AI 應用的文章,會發現它們有一個共同的隱含假設: 資源是無限的。 context 不夠?換一個更大的。額度不夠?升級方案。整批資料丟...
這篇要從一句很短的話開始。 它出現在我的專案筆記裡,講的是已經抓下來的那批資料: 「已挖到的資料在 onboarding-kb(5 個 md,先不要全讀,需...
Phase 3 講完了邊界。從今天開始講,東西到底怎麼做出來。 而第一個問題就是最根本的那個: 要用什麼方式,讓一個模型懂我們公司的事? 常見的路有三條:...
昨天定了路線:事實要在建置的時候先整理好。 那接下來就是一個非常實際的問題: 這些事實,現在到底在哪裡? 我列了一遍,然後有點傻眼。 清單 在哪裡 放...
昨天講了資料從哪裡來。今天講它被整理成什麼。 結果是一份大約 5 MB 的檔案,裡面有 1,183 張票卡,來自兩套不同的系統。 但這篇不是要講「我把資料存成...
昨天那份 5 MB 的檔案,已經是完整而且可以追溯的了。 但它沒有辦法直接拿去用,原因很簡單:太大。 Day 16 那條規則說了,不能全讀。所以要能「需要時再...
