三十天到了。
第一天我寫的是一份看起來完全像真的假規則——那份東西騙過了我,也差一點騙過一個新人。
而這三十天做的所有事情,都是在回答同一個問題:
那,要怎麼樣才能相信它?
今天要誠實地結帳。
Day 3 我寫過一張表,列了三種人各自需要什麼。那張表當時是需求清單,今天要拿它當驗收條件。
做到了一半。
「現在長什麼樣子」這一塊,Day 11 之後換了來源——從程式碼和實際畫面抓,不從卡片推論。這部分我有信心。
而「為什麼當初決定不做」——那是我最想要、也最沒把握的一塊。
理由確實都在卡片的留言裡,而我也確實把留言完整保留了(Day 19)。但「被否決的方案」這種東西,有一個結構性的問題:它常常根本沒有被寫下來。
Day 18 那篇列了八個知識散落的地方,而最後一行是「人的腦袋」,標著抓不到。
那一行到今天還是抓不到。
這一組做得最好,而且我有實證。
原因不難理解——那是我自己每天在用的東西。 Day 12 那條「只給我理解的資料」,直接讓這一塊成為整個知識庫最紮實的部分。
而它真的被用在一件正經事上,下一節專門講。
這一組我要誠實:它是我假設出來的,而且到現在還沒有被驗證過。
Day 3 我就寫過,那三題沒有人來跟我要過,是我假設「如果我是 RD,我會需要知道什麼」寫出來的。
三十天後,狀況沒有變:沒有 RD 用過它。
我不知道那一組是對的還是錯的。我只知道我還沒有拿到任何證據。
這一節我要講得很小心,因為這裡最容易自我感覺良好。
後來有一批更大的回報進來——18 條測試失敗。(不是 Day 9 那批,那是更早、更小的第一批。)我用這套東西,把每一條都去查了一遍。
結果是這樣:
| 判定 | 條數 |
|---|---|
| 假的失敗(這條不該被開出來) | 5 |
| 真缺陷,而且已經修好了 | 5 |
| 那本來就是預期行為 | 2 |
| 混合(裡面有一條真的) | 1 |
| 真缺陷,而且疑似連卡都沒有 | 1 |
| 需要我另外確認 | 4 |
而那 5 條假失敗,成因我也分了類:
| 成因 | 條數 |
|---|---|
| 規格誤解(以為該有,規格說不該有) | 2 |
| 測錯方法(正確做法早就寫在卡上) | 1 |
| 名詞混淆(把 A 當成 B) | 1 |
| 文件過時(卡上寫的規則早就被移除了) | 1 |
這四種成因,每一種都對應到這套工具裡的一支。
而 Day 9 那個最貴的案例——那個被退掉的單——就是上面那個表的第一條。
我想強調這件事的意義:這不是一個 demo。 這是 18 條真實的回報、一個真實的爭議、以及一次真實的判決。而那 5 條假失敗如果沒有被攔下來,就是 5 次「有人去修一個不存在的問題」。
而這一段才是我覺得最該寫進來的。
那 18 條裡有 4 條被標成「需要確認」,意思是工具查不出來。
而那 4 條,我早就在系統裡回答過了。
答案一直都在。抓取的邏輯只挑了新人標記失敗的那些行,沒有去抓我回覆的那些。
所以整件事的真相是:
它不是不知道答案。是我沒有把答案餵給它。
這不是幻覺,也不是推理錯誤。它是 Day 12 那件事的反面——
我一直在小心不要餵不該餵的東西,卻沒注意到該餵的沒有餵到。
而這個洞的性質很典型:沒有任何錯誤訊息。 它老老實實地說了「這條我查不出來」,那是一個誠實的回答。誠實,而且錯過了一整塊已經存在的答案。
這裡我必須把話講白,因為前面那節很容易讓人以為整套都驗證過了。
被驗證的是工具那一端。而那個可以用自然語言問問題的介面,一直到最近才第一次被交到別人手上。
在那之前,板上的每一個問題都是我自己打進去的測試資料。
一個只有作者用過的東西,不能說它被驗證過。
所以如果要誠實回答標題那個問題,答案是:
工具那一端,有證據說可以信任。
問答那一端,還不知道——因為它才剛開始被用。
我本來想在這裡放一段真實使用者的回饋,那會是這三十天最好的收尾。
那件事還沒有發生。而我不想為了結尾漂亮就把它寫成已經發生了。
雖然沒有回饋,卻有另一個訊號,而且我覺得它比回饋更硬。
專案進行到一半的時候,我把那個網站下架了。
原因是 AI 給的建議——它提醒我,把那些內容公開放著有資料外洩的風險。我覺得有道理,而且 Day 12 整篇都在講邊界,所以我沒有猶豫,直接刪掉。
然後大概過了五天,新人來問我:那個網頁怎麼不見了?可以放回去嗎?
我想很誠實地說,我當下有點意外。
因為在那之前,我完全沒有把握那個東西有沒有人在用。它安安靜靜地掛在那裡,沒有人稱讚、沒有人抱怨、也沒有人來問問題。在我心裡,它比較接近一個我自己做爽的東西。
而那一句「怎麼不見了」,是我拿到的第一個證據:
我沒有辦法證明它有用。但有人在它消失的時候發現了,而且來把它要回來。
一份沒有人在用的文件消失,是不會有人問的。
這件事後來讓我對「怎麼判斷一個東西有沒有價值」的想法變了一點。我們習慣去問使用者「這個好不好用」,而那個問題很難得到誠實的答案——大部分人會客氣。
但「它不見了你會不會發現」這個問題,答案騙不了人。
後來我跟主管報備,做了一道登入的門,然後才重新上架。
我想停在這裡講一件事,因為它是這個系列最後一個、也是我最沒有預期到的反轉。
Day 17 我寫過,AI 有兩次把我從一個比較大、比較自動的方案,拉回一個比較保守的做法,而兩次它都是對的。
這是第三次。而這一次,它只對了一半。
風險的部分它說得沒錯——那些內容確實不該就這樣公開躺著。
但「刪掉」這個解法,在解決風險的同時,把價值也一起解決掉了。
五天之內沒有人受到任何資料外洩的傷害,而有一個正在上手的人,失去了他手上唯一一份可以照著走的東西。
真正的答案不是拿掉,是加一道門。
而這件事跟我整個系列在講的架構其實是同一句話:
邊界不是一個「給或不給」的開關。它是分層。(Day 13)
我自己寫了一整篇在講分層,然後在真的遇到風險的時候,我選了最粗暴的那個做法——全刪。
那一刻我沒有問「哪一部分有風險」,我問的是「有沒有風險」。
而這兩個問題,會得到完全不同的答案。
這一段是我寫這篇的時候還不知道、後來才查出來的。而我覺得它必須留在這裡。
那道門,擋錯了人。
它用的驗證方式,只在特定的連線條件下才成立。而新人在公司內網打開那個網址的時候,那個條件不成立——所以一個輸入了正確密碼的人會被拒絕,而且錯誤訊息還叫他「去用別的方式開」。
我自己測不出來,因為我是在自己的機器上開的,那個條件剛好成立。
而同一道門,也沒有擋住該擋的人。
它是一道畫在畫面上的門。內容其實早就已經送到瀏覽器了——關掉 JS、或是直接用指令去抓那個網址,整份資料都拿得到,不需要任何密碼。
所以完整的帳是這樣:
| 我以為 | 實際上 | |
|---|---|---|
| 新人 | 進得來 | 進不來 |
| 想看的人 | 進不來 | 進得來 |
兩件事都做反了。
而它跟前面那個錯誤,其實是同一個形狀:
刪掉的時候,我問的是「有沒有風險」,不是「哪一部分有風險」。
加門的時候,我問的是「有沒有門」,不是「這道門真的擋得住嗎」。
兩次都是——我確認了一件事存在,但沒有確認它成立。
而這正好是這三十天,我一直在別人身上檢查的那件事。
一、引用消失。
Day 29 講過,當我只餵少量事實的時候,答案變準了,但那些「這句話根據第幾條事實」的標記整個不見了。
而我後來重跑了八次去確認這件事,結果讓我更不安:它不是偶爾發生,是每一次都發生。 餵六條的時候,每一次輸出都帶著五到七個標記;餵兩條的時候,每一次都是零個,沒有例外。
也就是說,這不是一個可以靠重試繞過去的機率問題,它是那個做法本身帶來的。
而引用是整個可驗證性的基礎——沒有它,Day 11 那五個追問就問不下去。
這是我最在意的一個未解問題。 因為我目前找到最有效的那個做法,跟我最重要的那道防線,是互相排斥的。
二、搜尋撐不住真實的使用者。
Day 21 寫過我想加而還沒加的兩項:錯字、以及沒有斷句的輸入。
而我後來實際測了錯字。結果跟我原本以為的相反:它不會回零,它每次都回滿六筆——只是第一名變成了錯的那一筆。
所以問題不是「查不到東西」,是:
它每次都查得到東西,而你分不出來那是不是你要的。
一個查不到東西的知識庫,使用者至少知道要再試一次。而一個每次都給你六筆、但可能排錯的知識庫,他會直接把第一筆拿走。
三、它還綁在我身上。
Day 13 寫過那個難堪的發現:我做了一個知識庫來解決「知識綁在一個人身上」的問題,而那個知識庫綁在我的筆電上。
靜態版解決了一半——內容隨時打得開了。但那個會回答問題的部分,還是我在線上才有。
而 Day 17 講得更直接:我最初想做那件事,是為了把自己拿掉。而現在過濾資料的是我、判斷的是我、發現過期的還是我。
我讓它變可靠了,但我沒有讓它變得不需要我。
我想用一個不太漂亮但誠實的方式收尾。
沒有完成的: 它還不是一個可以放著自己跑的系統。它的品質上限,還是我的理解範圍。
完成的,是另一件事——我知道它在哪裡會壞,以及為什麼。
這聽起來像安慰獎,但對我來說那是真正的差別。
Day 1 那份文件的問題,不在於它有 8 處錯。是我當時不知道它會在哪裡錯。 我沒有辦法預測、沒有辦法防、只能等它出事。
而現在,那條界線是畫得出來的:
這張清單,就是這三十天的產出。 它不是一個功能,是一組可以事先判斷的預期。
而我現在做任何 AI 相關的決定,問的都是同一個問題:
如果它做錯了,我有沒有辦法知道?
有——那就交出去,錯了我會抓到。
沒有——那不管它表現得多好,我都不會用。
三十天前我寫的第一句話是,它說得頭頭是道。
三十天後我的想法沒有變:它還是說得頭頭是道。
而改變的是我這一端。我不再用「聽起來對不對」來判斷一件事——我問的是「這句話是從哪裡來的」。
那五個追問,問到我自己都覺得不好意思(Day 11)。而我現在覺得,那個不好意思是這整件事最好的註腳:
追問不是不信任的表現。它是把工作交出去的前提。
你不會把一件事交給一個你沒有辦法查證的對象。而一旦你有辦法查證了,你就敢交了。
這三十天我蓋的不是一個知識庫。是一套讓我敢把事情交出去的檢查方法。
而那個東西,對一個 QA 來說,大概是最熟悉不過的了。
iThome鐵人賽
看影片追技術