前言

前四天,我們一直在談範本的「結構」——骨架、血肉、變動頻率。但有一件事,我們一直刻意留到今天才談:你到底怎麼定義「這是一份好報告」?

這個問題聽起來有點蠢——你每天在寫報告,難道不知道什麼叫「寫得好」嗎?但這正是第一階段最後、也最容易被忽略的一個陷阱:大部分人心中的「好報告」標準,是模糊的、直覺的、說不清楚的。而 AI 沒辦法學習一個說不清楚的標準。

一、一個扎心的測試

在往下讀之前,先做一個小測試:試著用三句話,對一個完全沒看過你部門報告的人,解釋「一份好的資安週報長什麼樣子」。

如果你發現自己講出來的是「就是…要清楚啊」「重點要抓到」「不要太囉唆」這種形容詞,而不是具體、可檢查的標準——恭喜你發現了問題所在。這些形容詞對人類來說可以靠經驗心領神會,但對 AI 來說毫無意義,因為它沒有你的經驗背景,只能照字面猜測「清楚」到底是什麼意思。

二、為什麼「先有人類標準」這個順序很重要

回顧 Day 1 的核心比喻:AI 是產線員工,而你在寫規格書。任何一條產線,品管標準永遠是在生產線開始運轉之前就先訂好的,不會是「先讓機器隨便做,做完再看順不順眼」。

如果你跳過這一步,直接開始寫 prompt、調格式,你會陷入一個困境:每次看到 AI 的產出,你只能憑「感覺哪裡怪怪的」去改,而不是對照一個明確的標準去改。 這種憑感覺的修改方式,正是 Day 2 提到的「不穩定」的根源之一——因為連你自己對「好」的定義,每次感覺到的重點可能都不太一樣。

三、如何把模糊標準,轉換成具體檢查清單

把抽象標準變具體,有一個實用的方法:針對每一個模糊的形容詞,追問「我怎麼知道它有沒有做到?」,直到答案變成一個可以打勾、可以量化的東西。

以「重點要抓到」這個常見說法為例:

• 模糊版:「這份報告重點有沒有抓到?」
• 追問一次:「什麼叫抓到重點?」→「就是主管關心的事情有寫到。」
• 追問兩次:「主管具體關心哪些事?」→「事件有沒有處理完、有沒有還沒解決的高風險項目。」
• 具體版(可檢查):「報告是否明確列出:①本週未結案事件數量 ②所有高風險等級以上事件的處理狀態」

這樣轉換之後,這條標準才真正能寫進 System Prompt,也才真正能拿來檢查 AI 的產出有沒有做到。

四、建立你的「報告品質檢查清單」

建議你把這套追問方法,套用在報告的幾個常見面向上,整理成一份清單。以資安週報為例,可以從這幾個角度切入:

這份清單一旦建立起來,不只是這階段的終點,更是接下來整個系列的度量衡:Day 11 的防呆機制,對應的是「準確性」;Day 21 的除錯,靠的就是逐項對照這份清單;Day 23 的 A/B Testing,也是拿這份清單當兩個版本的評分表,而不是憑印象比較「哪個比較順」。

五、今天的行動練習

拿出一份你過去寫過、自己覺得「這份寫得不錯」的報告,以及一份「這份寫得普通」的報告,兩相對照,問自己:這兩份報告的差別,具體發生在上面表格的哪個面向? 把你的觀察,套進表格的格式裡,寫出屬於你自己工作場景的第一版檢查清單——不用求完美,這份清單接下來會隨著實戰不斷修正。

小結

第一階段的五天,其實是在做同一件事:把腦中所有沒說出口的假設,一項一項攤開來講清楚。 從「AI 是產線員工」的心態,到「穩定性與可重複性」的目標,再到「骨架與血肉」「變動頻率」的結構拆解,最後落在今天——如果連「什麼是好」都說不清楚,前面所有的結構設計都會失去對照的標準。

有了這份品質檢查清單,我們才算真正做好進入第二階段的準備。下一篇開始,我們要進入具體的指令撰寫框架——CO-STAR,把今天累積的所有素材,系統化地填進一套業界通用的架構裡。