Day 11 的結論是:事實要從程式碼和實際畫面來。

這個結論有一個很直接的後果——我得讓它看更多東西。 更多程式碼、更多環境、更多實際的資料。

於是下一個問題馬上就來了:

那,要給到什麼程度?

今天這篇講的是我畫的兩條線。第一條很好畫,大家都會同意。第二條是我自己畫的,而且它嚴格得多。

第一條線:機密

我們公司內部有一個 wiki,放的是維運相關的東西。

我打開看過之後,對這個專案的判斷很快就出來了,原話是這樣:

「我也不建議你去讀他,怕危險。」

那上面有什麼?我不會寫細節,但類型講得出來:

• 資料庫在哪裡、怎麼連
• 各種權限設定與登入資訊
• 雲端資源的組態——機器、搜尋服務、權限角色那一整套

這些東西的共同點是:它們不是「知識」,是「鑰匙」。

一個新人需要知道「這個功能怎麼用」,但不需要知道資料庫的連線字串。那不是上手的障礙,那是另一個層級的東西。

這條線沒什麼好討論的,我想多花一點篇幅在另一件事上——

為什麼「不給帳號」還不夠

我一開始的想法很單純:我不給它那個站的帳號,不就好了?

後來覺得這個想法太樂觀,原因有三個:

第一,資料的入口不只一個。 我不給帳號,不代表那些內容不會以別的形式出現——有人在票卡留言裡貼了一段設定、某個檔案剛好躺在專案目錄裡、某張截圖的角落拍到了不該拍到的東西。

第二,我自己也會手滑。 為了問一個問題,順手把一整段東西貼進去,這件事太容易發生了。

第三,也是最關鍵的一點——讀進去就收不回來了。

這一點值得停一下。刪掉一個檔案、撤銷一個權限,這些動作都是可逆的。但一段內容一旦進了對話,它就已經在那裡了。你可以把對話刪掉,但你沒有辦法確定它有沒有被記住、被記錄、被帶到下一個地方。

所以我的作法不是只有「不給」,而是在指令層明確寫出來:那個站不要去讀,那類內容不要主動去找。

把邊界寫成規則,而不是只靠「它應該碰不到」。

(這件事還有另一半,關於「權限給到哪裡」,那是明天和後天的題目。)

但第二條線,才是我每天真正在用的那條

上面那條線,任何做資安的人都會跟你講一樣的話。

而我自己畫的那條,從來沒有人要求過我,它是這樣:

我只給它讀我知道的資料。

第一次講出來的時候,連我自己都覺得這聽起來有點小家子氣——資料不是越多越好嗎?我手上明明有更多東西可以餵。

但理由其實很具體,而且跟保密一點關係都沒有:

我不知道的資料,如果過幾天被改掉了,我不會知道。

展開講:知識庫最大的敵人不是錯,是過期

一份文件寫錯了,它從第一天就是錯的,你有機會在驗收的時候抓到。

但過期不一樣——它上線那天是對的。

而且過期不會發出任何聲音。沒有人會來通知你「欸,你文件裡第 7 條從昨天開始不成立了」。它就靜靜地待在那裡,繼續正確地長著一副正確的樣子。

Day 8 那個最嚴重的錯,本質上就是這件事:卡片說「還沒修」,而東西早就修好了。資料變了,描述沒變。

那麼,誰有能力發現一份文件過期了?

只有一種人:知道那一塊現在長什麼樣子的人。

所以問題就變得很簡單了。如果我餵進去的是一塊我自己都不懂的東西:

• 它產出的內容,我當下看不出對錯
• 那塊東西如果下個月被改掉,我也不會察覺
• 而知識庫會繼續用很有自信的語氣,講一件已經不成立的事

我不是在防它出錯。我是在防一種我永遠不會發現的錯。

所以這條規則其實不是在管 AI

我後來把這件事想得更清楚了一點。這條線管的根本不是 AI,是我自己的驗證能力:

我能餵給它的範圍,等於我能驗證的範圍。

超出這個範圍的東西——就算它答對了,我也不知道它答對了。

而這句話的反面,才是真正嚇人的地方:

一個我無法驗證的正確答案,和一個我無法驗證的錯誤答案,對我來說是同一個東西。

它們長得一樣、讀起來一樣、都很有自信。我沒有任何方法把它們分開。

那我把它們放進知識庫,到底是在做什麼?

兩條線擺在一起

第二條線排掉的東西,比第一條多得多。

而且它排掉的全都是無害的資料——沒有任何保密問題,只是我不熟而已。

這條線的代價,我也得誠實講

它讓這個知識庫小很多。

有些新人一定會問、而且很合理的問題,我知道答案不在裡面。因為那一塊是別人負責的,我沒有真的跑過。

我糾結過這件事。少一塊內容,是實實在在的損失。

但後來我的想法是這樣:

Day 9 那個結論,在這裡又冒出來了一次。

這個知識庫最需要它的使用者,剛好是最沒有能力驗證它的人。

如果我放了一塊連我自己都驗不了的內容進去,我做的事情其實是:把一個我無法承擔的驗證責任,轉嫁給一個更沒有能力承擔的人。

新人讀到那一段,不會知道那是「我不確定的區域」,只會把它當成跟其他段落一樣可靠的東西。

一個小而可信的知識庫,和一個大而有幾個未爆彈的知識庫,我選前者。

而且這個選擇還有一個好處:我知道缺口在哪裡。 缺口是可以被補的;而未爆彈,你連它在哪都不知道。

那我不知道的東西,就永遠不寫了嗎?

不是。這條線不是「永遠不碰」,是順序問題:

不知道的東西,要先變成知道的,才能進去。

而「變成知道的」有幾種很具體的作法:

• 自己去跑一遍。 我是 QA,這本來就是我的工作方式。跑過一次,它就從「我不知道」變成「我知道」
• 去問那一塊的負責人。 而且關鍵是——那個確認本身要變成資料留下來,不能只留在對話裡。否則下次我還是不知道
• 在那之前,標記起來。 不是刪掉,是標成「未確認」,不進知識庫的正文

最後那一條,跟 Day 11 的結尾是同一句話:

一個誠實的「不知道」,比一個通順的猜測有價值太多了。

差別只在於,Day 11 講的是不要讓 AI 猜,今天講的是不要讓我自己猜。

明天:那這些不同等級的東西,各自放在哪裡?

今天講的是「什麼不給」。

但實際運作起來,事情沒有這麼二元——它不是一個「給 / 不給」的開關,而是分層:

有些東西是金庫,誰都不碰;有些東西是給新人看的,要讓它好找;而還有一個問題是——新人到底要從哪裡進去?

明天講三層存放,以及一個我想了很久的決定:為什麼入口我放了兩個地方。