Day 1 我提過這件事,但只講了結局。從今天起講完整的過程。

我讓 AI 幫我把 89 張卡,統整成一份「每個頁面現在長什麼樣」的說明書。

這篇講我怎麼決定它該長什麼樣子。下一篇講我為什麼決定去驗證它。再下一篇講我抓到了什麼。

我要的不是「整理卡片」

先把需求講清楚,因為這一步錯了後面全錯。

看板上三個河道、89 張卡。同一個地方被改過好幾輪,規格前後不一致,而且都還沒上正式版。

我要的東西只有一句話:現在每個頁面、每項功能的最終版本長什麼樣。

注意這句話裡沒有「卡片」兩個字。

因為我要的不是卡片的摘要。如果只是把 89 張卡各自濃縮成一段,我會得到 89 段摘要——那解決不了任何問題。我還是得讀 89 段,而且它們彼此矛盾:同一個地方的第一次修改和第三次修改,會給你兩種互相打架的描述,而且兩段看起來一樣有自信。

票卡記錄的是「歷時的意圖」,我要的是「此刻的狀態」。

這兩件事的差別,是這整個 Phase 的主線。

第一個決定:以「頁面」為單位,不以「票」為單位

所以我做的第一個決定是粒度。

不要一張票一段,要一個頁面一張卡。

理由很直接:那是讀的人實際會遇到的單位。

一個 QA 要測的時候,他打開的是一個頁面;一個新人要學的時候,他看的是一個畫面;一個 PM 要問的時候,他問的是「這一頁現在是什麼行為」。

沒有人會問「第 47 號票現在怎麼樣了」。

而且用頁面當單位,還有一個副作用是我當時沒想到、後來很感謝的:它會強迫矛盾浮出來。

如果同一個頁面被三張票改過三次,用票當單位的話,三段描述會各自待在自己的卡裡,相安無事;用頁面當單位,三段描述被逼到同一張卡上,誰跟誰打架一眼就看得到。

那為什麼不用「功能」當單位?

當然可以照功能走。而且聽起來更合理——功能才是「一件事」,頁面只是它出現的地方。

但我遇到的實際狀況是這樣的:

有 10 個頁面,都有同一個「資料顯示」的功能。 其中 5 個拿來做報表,另外 5 個拿來看個資。它們的資料源頭是同一個。

而這 10 個頁面,預設顯示的東西全都不一樣。

現在假設其中一個報表頁出問題,其他 9 個都正常。

請問我要回報:

• 10 個頁面有問題?(因為它們共用同一個功能)
• 5 個頁面有問題?(因為同一組的都可能有)
• 還是 1 個?(因為我只看到那一個壞)

而且我該回報成功能的問題,還是那個頁面顯示的問題?

這不是文件怎麼寫的問題,這是我根本說不出一句完整的話。

而只要單位換成頁面,這些問題會全部消失:我看到哪一頁壞,就回報哪一頁壞。 範圍是自明的,不需要推論。

背後的道理其實很簡單:缺陷長在頁面上,不長在功能上。

你沒有辦法「觀察一個功能」。你能觀察的永遠是某一個畫面、在某一組條件下、顯示出來的樣子。既然觀察的單位是頁面,那記錄的單位就該是頁面——不然你寫下來的東西,永遠比你實際看到的多一層推論。

還有一個更麻煩的後果。

如果用功能當單位,那份說明書會長出一條這樣的句子:「這個資料顯示功能是這樣運作的。」

聽起來很乾淨。但那 10 個頁面預設顯示的東西都不一樣——所以這句話對其中至少 9 個頁面來說,都不夠精確。

一條同時描述 10 個頁面的敘述,對每一個頁面都只對一半。

(把這件事記著。Day 10 那篇會回來。)

但我要承認:這有一半是偏好

上面那些理由都成立,不過我不想把它說得像什麼普世真理。

真實的背景是:我們開票本來就沒有明確規範。

有時候一張票以功能為主,底下掛一堆頁面;有時候就是一個頁面單獨開一張。兩種都會出現,沒有人規定哪種對,也沒有人覺得這件事需要被規定。

在這種狀況下,「哪一種比較好」其實沒有標準答案。我選頁面,有一部分原因很單純——它讓我能工作。

所以我給自己訂了一組規則:

• 一張票 = 一個頁面,測一次就結束
• 跟這一頁無關的,開下一張票
• 只要跟這一頁有關、會影響這一頁顯示的,就寫進這張票裡
• 不要把 A 頁面的注意事項,附註在 B 頁面的票卡上

最後那一條是重點。

附註看起來很貼心——順手提醒一下,省得再開一張卡。但它的代價是:那條資訊從此只存在於「某個人剛好記得去看 B 的那張票」這件事上。

Day 2 講的那種「天書在留言區」,有一半就是這樣長出來的。

而這個選擇是有適用範圍的

我不會說所有票都該用頁面當單位。準確的講法是這樣:

大版本的第一批票卡,用頁面。 因為那個階段所有東西同時在動,你需要的是「範圍」——哪一頁、誰受影響、測到哪裡為止。這時候「概念上是同一個功能」幫不了你,它只會讓範圍變得更模糊。

後續的小功能,用功能開票完全沒問題。 那時候頁面已經穩定了,一個小改動通常只動一兩個地方,範圍本來就清楚,再拆成頁面反而是多餘的手續。

換句話說:

單位不是一個信仰,是一個跟著專案階段走的選擇。

而我當時之所以糾結,是因為手上那 89 張卡剛好是最壞的情況——它們是大版本的第一批,卻是用兩種單位混著開的。

我給的規則:不准偷懶

Day 1 那段的完整版在這裡。我交代的規則是:

讀完那一百多張卡,判斷每一項功能出現在哪些頁面。如果甲功能出現在第 1、2、3 頁,那這三頁都要各自寫出甲功能——不准只寫在其中一頁,然後補一句「其他頁面也有這個功能」。

會特別講這句,是因為我已經預期到它會想偷懶。

摘要類的任務裡,「其他頁面也有」是一種非常自然的壓縮。它省字、聽起來也合理。但對一個要拿去當測試依據的文件來說,那句話等於什麼都沒說——「也有」是什麼意思?一模一樣?還是長得不太一樣?

而這正是後來出事的地方。(先不解釋,Day 10 會整篇講。)

中途我改了兩次粒度

這部分我覺得比結果重要,因為它顯示「頁面」這個單位不是一開始就對的。

第一次調整:同一個名字,在兩個地方。

有一個「行銷來源」的區塊,在兩個不同模組底下都有。名字一樣、長得很像,但行為不一樣。

一開始它們被塞進同一張卡,結果就是那張卡開始出現大量的「在 X 模組下是這樣、在 Y 模組下是那樣」——一張卡在描述兩個東西的時候,句子會開始長出括號。

所以拆成兩張。

第二次調整:同一個頁面,不同的人看到不一樣。

有系統管理員權限的人,和沒有的人,打開同一個頁面看到的東西是不同的。

這件事一開始沒有被當成獨立的維度,而是散在各張卡的描述裡。後來我把「非系統管理員使用者」獨立成一張卡。

這兩次調整,其實在講同一件事:

「一個頁面」不是一個單一的東西。

同一個網址,會因為你從哪個模組進來、你是誰、你有什麼權限,而長得不一樣。而我原本的單位裡,沒有這些資訊的位置。

我當時只覺得這是粒度沒切好,調一下就好。

現在回頭看,這裡已經在預告 Day 10 那篇的根因了。

產出:16 張卡——後來變成 18 張

89 張卡,第一輪統整完是 16 張。

而最後拿去驗證的,是 18 張。

多出來的兩張,一部分來自上面那兩次粒度調整,另一部分來自一件更根本的事:

我在整理的過程中,測試環境上了新版本,新的卡片進來了。

這件事當下只是個小插曲——加就加,多兩張而已。但它其實把這份文件的本質講出來了:

我做的是一份描述「現在」的說明書,而「現在」在我寫的過程中就已經變了。

它不是一份文件,是一張快照。快照的問題不在於它會過期——那是必然的——而在於它看起來跟不會過期的東西一模一樣。

一頁寫著「目前版本」的文件,不會在第 30 天自動長出一行「本內容已不適用」。

(這件事後來變成我整個作法的轉折點。Day 11 會講。)

先不管數字。真正讓我停下來的是產出的品質。

每一張卡上都有:

• 對應的 PR 編號
• 相關的 feature flag 名稱
• 改到哪個 class、哪一條路由、哪一支 migration
• 影響幾個頁面

它看起來完全就是我要的東西。

條列清楚、每一項都附了出處、格式一致,而且是在幾分鐘內完成的——如果我自己做,這是好幾天的工作,而且我做不到這麼整齊。

一個我當時沒說出口的念頭

這裡我想岔開講一件事,因為它其實是後面四天的起點。

當一份產出物每一項都附了出處的時候,人會有兩種反應:

一種是放心——有 PR 編號、有檔名、有行號,那應該是查過的。

另一種是想去抽查。

這兩種反應的差別,不在於你信不信任 AI,而在於一個更基本的習慣:你把它當成「結果」,還是當成「待驗證的產出物」。

而我後來意識到一件有點諷刺的事:

如果這 16 張卡是我自己寫的,我不會去查它。

沒有人會抽查自己剛寫完的東西——因為你檢查的時候,用的是寫它時候的同一套理解,同一個誤會會重複發生兩次。

換句話說,它是 AI 寫的,反而是它被驗證的原因。

這件事我覺得值得記下來:我們對 AI 產出的懷疑,其實是一種很健康的品質機制。而它應該被用在所有產出物上,包括人寫的。

太好了,好到我不安

回到那 16 張卡。

我盯著它們看了一陣子,然後產生了一種很難形容的感覺:它好得不太合理。

不是因為 AI 做不到——它確實做得到。而是因為我知道輸入的那 89 張卡長什麼樣子:規格前後不一、同一處改過多次、有些卡連「是哪個頁面」都沒寫。

一份輸入那麼亂的資料,產出不該這麼乾淨。

乾淨的地方一定是被什麼東西填平的。我只是還不知道是什麼。

所以我決定做一件 QA 會做的事。

明天那篇的標題就是它:我決定去驗證 AI 幫我寫的東西。