開發紀錄
事實、推論與未知:AI 交付不能把三者混在一起
用網站重構與文章輸出的案例,拆開交付說明裡的觀察、判斷和待確認事項,讓「已完成」有可以追問的依據。
- AI 協作
- 事實查核
- 驗證
- 交付說明
「主要內容已經放進 HTML,所以網站更快,SEO 也更好了。」
這句話把不同強度的結論接在一起。前半句可以讀取輸出檔案確認;後半句還需要速度與搜尋表現的證據。即使前半句成立,也不能把後半句一起算成已驗證。
和 AI 合作時,交付說明值得逐句讀。與其只問「測試過了嗎」,更有用的問題是:這句話描述了實際觀察、提出一個判斷,還是把尚未知道的結果說成已經發生?
事實要能指出觀察的位置
本站從 Vue 重構成原生 Astro 時,一個明確要求是:直接開啟某個網址,回傳的 HTML 就有該頁主要內容。
要支持這件事,可以讀取建置後的 HTML,確認正文和標題存在,而不是只看到程式裡寫了一個元件。這個觀察能支持「這個輸出檔案有正文」,但若要說「所有頁面都有正文」,就要再確認檢查涵蓋了哪些頁面。
事實不只要有來源,也要有範圍。某一頁、這次建置、本機環境和正式主機,是不同的觀察對象。把範圍拿掉,一句本來準確的回報就可能變成過度保證。
同樣地,找到一個元件檔案,只能確認檔案存在。要說它是原站的功能,還需要入口和實際使用關係。本站重構時曾多出技術篩選控制,回頭檢查才發現,舊站雖然留有相關元件,頁面卻沒有引用它。原本需要保留的是作品類別切換。
這類錯誤不必等到量測才看得出來。先把「檔案存在」和「功能曾經提供」拆開,就能找到缺少的證據。
推論可以保留,但要交代怎麼走到那裡
「網站主要供人閱讀,所以讓正文在建置時產生,符合這次的內容方向。」這是一個架構判斷。
它有依據:網站要呈現介紹、作品和文章,需求也明確要求初始 HTML 可讀。這些條件支持採用靜態內容的選擇,卻沒有把這個選擇變成所有網站都該遵守的答案。
推論不是不可靠的同義詞。設計和開發本來就需要判斷,問題是有沒有說明依據,以及在哪些條件下需要重新評估。
可以把交付中的推論寫成:
這次希望讀者直接開啟網址就能閱讀正文,因此把頁面內容放在建置階段產生。這符合目前的內容需求;若之後加入大量登入後的即時操作,仍要重新評估那些功能的實作方式。
這是說明格式示例,不是新的效能測試結果。它保留了選擇理由,也讓人知道判斷的前提。
未知應該指向下一個問題
沒有量測載入速度,不表示網站一定很慢;沒有搜尋流量資料,也不表示架構沒有價值。它們表示這次不能回報那兩種成果。
未知可以寫得很具體:
| 尚不能回答的問題 | 若需要回答,可以補什麼 |
|---|---|
| 新版是否比舊版快? | 在可比較的條件下量測前後版本,說明頁面、裝置與網路環境 |
| 手機閱讀是否舒服? | 由站主實際閱讀,確認寬度、段落節奏和內容順序 |
| 正式主機是否回傳正確頁面? | 部署後請求實際網址,核對狀態、正文與資源 |
| 筆記是否讓讀者更理解作品? | 補充讀者回饋或適合該問題的觀察資料 |
這些是後續查證方向,不是本站已完成的量測。
「尚未測試所有情況」太寬,讀者無法據此決定下一步。若這次只核對本機輸出,就直接說正式主機還沒核對;若內容與技術檢查完成,視覺還在等人確認,就把視覺列為待驗收。限制越貼近問題,越容易安排工作。
混合句要拆到能分別確認
下面的句子是刻意組合的交付反例,不是實際工具輸出:
草稿已接入文章系統,檢查也通過了,因此文章可以公開,讀者應該會更容易理解網站。
它至少需要拆成幾個獨立問題。
草稿是否接入,要看內容來源與本機預覽。檢查通過,要交代檢查項目及結果。可以公開,要有站主對內容和公開範圍的決定。讀者是否更容易理解,則不能由前三項代答。
比較清楚的說明會是:
文章已接入本機預覽,仍保留草稿狀態。工程檢查結果另列;內容、公開範圍與閱讀版面由站主確認。本文沒有讀者理解程度的量測,不回報這項成果。
不一定每次都要使用這個格式,但每一句都應該能單獨成立。連接詞不能替證據補上缺口。
證據改變時,先修正原本的結論
假設交付先寫「草稿沒有進入正式輸出」,後來卻找到一個草稿網址,不能只在末尾加上「仍可能有例外」。需要回頭確認:是不是舊的建置檔案沒有清乾淨、來源狀態讀錯,或正式查詢真的漏了過濾。
這是假設的排查情境,不是本站新發現的事故。重點是修正順序:先撤回不再成立的結論,再找原因,修正後重新讀取相關輸出。不能保留「已完成」的標題,讓讀者自己從附註猜出其實還沒完成。
交付前,挑一句最強的結論來追問
不必把每次合作變成逐字審判。可以先挑「全部完成」「沒有洩漏」「更快」「已公開」這類影響決策的句子,問它的依據和範圍。
如果能指出觀察,就按觀察範圍寫成事實;如果是從需求整理出的選擇,就交代推論前提;如果沒有資料,就留下具體的未知與查證方向。當三者分開,人才能決定要採用判斷、補一項檢查,還是暫時不公開。
紀錄範圍
本文以本站重構、功能取證與內容發布規則整理交付判讀方法。引言、交付反例及排查情境均為說明用途,不是原始聊天、測試紀錄或新量測。本文不宣稱這套方法已改善開發效率、搜尋表現或讀者理解程度。