選了「完整報告」並要求資料來源，文獻探討先寫著「本報告蒐集並整理」相關資料，旁邊卻又提醒需要補充來源。這些文字同時存在於早期模板裡：一邊描述已做過的工作，一邊承認材料還沒到位。

上一篇停在 Report Builder 最初的介面原型。接下來的版本開始依設定組裝不同報告，也加入真正建立文件的匯出程式。這些進展值得保留，但我也需要拆開一個很容易混淆的問題：輸出越來越完整，是否代表研究也越來越完整？

模式改變的是組裝方式

早期生成器不再只把固定段落放進預覽畫面，而是先判斷題目類型，選出對應內容，再依模式組合章節。「報告架構」安排研究背景、問題與方法；「完整報告」使用摘要、分析、討論與結論；「資料需求表」則列出應蒐集什麼、用途及優先程度。

這些資料被放進 GeneratedReport，也就是程式用來表示一份報告的物件。裡面有章節清單，每章再由段落、清單、提醒或表格等內容區塊組成。介面讀取區塊種類，決定用段落、清單或表格呈現，於是不同模式可以共用預覽程式，而不用各自重做一張報告頁面。[1]

這是實際的架構進展，卻還不是模型在閱讀文獻。那個版本的生成器按程式裡的規則與既有文字組裝內容；原始碼也明確將它標成模擬生成器，把接上真實模型留作後續工作。

風格與長度的作用也有邊界。以完整報告模式為例，選擇風格會替開頭加上相應語氣的提示，短版會裁短清單，長度選「深度研究」則增加補充文獻、數據與比較分析的建議。換句話說，程式改變了草稿的表達方式，並提醒還要做什麼，沒有因此多讀進任何研究。

對我而言，這個區分比選項名稱更有用。「深度」如果只是設定值，就應該說清楚它影響的是篇幅、結構，還是實際取得的材料。讀者無法只從下拉選單知道答案。

品質勾選，究竟檢查了什麼？

模式增加之後，報告也多了一份品質檢查表。這看起來像是替輸出加上保險，但當我回頭核對條件，發現有些項目只看內容欄位是不是空的，有些甚至直接給了通過值。以下節錄當時「完整報告」的分支，僅調整縮排與換行：

if (input.mode === "完整報告") {
  checks.push({ label: "段落完整", passed: true });
  checks.push({
    label: "內容具備分析",
    passed: content.analysis.length > 0
  });
  checks.push({ label: "結論不是單純重複前文", passed: true });
  checks.push({
    label: "有研究限制與未來建議",
    passed: content.limitations.length > 0 && content.futureWork.length > 0
  });
}

checks 存放檢查項目，passed 為 true 就表示通過。這段程式能呈現某些結構是否存在，例如分析文字不是空字串；但「結論不是單純重複前文」直接設為 true，並沒有真的比較結論與前文。標籤描述的能力，比判定條件走得更遠。

畫面上的完整度也要作同樣解讀。當時的計算依模式與長度的預設值，再參考是否填入補充資訊、是否要求圖表來調整，最後設上限。它不是讀過來源後算出的可信程度，也不是報告通過審閱的機率。

當條件只確認有沒有一段文字，名稱就不應讓人以為系統已經理解並查核了那段文字。現在再設計這類提示，我會先寫出它真正檢查的條件，再決定標籤，而不是先取一個讓人安心的名稱。

同一份報告，從畫面走向檔案

接著加入的匯出程式，沿用了同一份報告物件。純文字與 Markdown 會逐章處理區塊；Markdown 是用簡單符號標示標題與清單的文字格式。下面這段就取自當時的 Markdown 組裝函式

for (const section of report.sections) {
  lines.push(`## ${section.heading}`);
  for (const b of section.blocks) lines.push(...blockToLines(b, true));
  lines.push("");
}

這裡先把章節名稱轉成標題，再交由 blockToLines 把每個內容區塊轉成文字行。這種做法解決了不同輸出格式如何接收報告內容的問題，匯出器不必另寫一套生成邏輯。原本在內容裡的來源提醒，也能隨區塊一起輸出。

Word 文件則透過 docx 套件，把章節轉成標題、段落與表格，再打包為檔案。PDF 走的是另一條路：建立列印用網頁、開啟瀏覽器列印介面，讓使用者選擇另存為 PDF。這比最初只顯示尚未提供的匯出入口更進一步；不過，程式路徑存在，不等於每台電腦都已實際下載並檢查過檔案。

重要的是，這些轉換都不會替原本的段落找到證據。若輸入仍是一份待補來源的草稿，換成 Word 檔後也還是草稿。文件可以排得更正式，卻不會因為有封面與目錄，就完成原本沒做過的研究。

三種「完整」，不能互相代替

現在回頭看，我會把報告產品的完整度分開理解。介面完整，是使用者知道在哪裡輸入、如何選設定，以及去哪裡看結果。文件完整，是內容能用適當的章節與格式呈現，並交到讀者手上。早期的模式與匯出，主要就在這兩個方向前進。

另一層是證據完整：重要主張能找到依據，來源的內容與這句話之間確實有支持關係，尚未取得的材料不被當成已知。它不能用頁數、章節名稱或匯出按鈕來替代。這是我對產品責任的區分，不是說早期版本已經實作了這一層。

因此，我會把「格式要求」與「證據要求」分別寫清楚。前者回答文件應該長什麼樣，後者回答哪些內容有根據。兩者都需要檢查，只是驗證方法不同：檔案能打開，不能替一句話背書；一句話有根據，也不能保證匯出後的版面沒有問題。

讓模板留下需要完成的工作

先做模板並不是白費。模板、模式與匯出讓抽象的產品想法變成可操作的東西，也讓我能具體討論：報告要有哪些區塊？不同主題是否應該共用同一個骨架？內容如何在預覽與文件之間保持一致？這些問題在拿不到研究材料時，仍然值得先釐清。

但模板有一個容易被忽略的風險：先替答案決定形狀，接著讓每一格看起來都有內容。這也是開場那段文獻探討的矛盾。生成器可以安排一節「文獻探討」，卻不能只因那個章節存在，就寫成自己已經蒐集並整理過文獻。

當時也有值得保留的做法。來源區塊會提醒補充真實資料，引用格式提供的是待填的作者、年份與出處位置；資料需求表則說明還要蒐集哪些材料。它們不是研究成果，卻可以幫助使用者看見下一步，而不必把所有空白都包裝成結論。

如果你正在做自己的 AI 報告工具，可以挑出一句「已完成」的提示，核對它背後的條件。是有章節，還是有支持章節內容的資料？再檢查匯出時是否保留缺口說明，避免畫面上承認未完成，下載的文件卻把提醒拿掉。這些是我從早期程式整理出的改進方向，不是它當時已有的完整防護。

這一階段讓報告有了更多形狀，也更容易被帶走。接下來的問題，就從「要如何呈現」移到「內容根據什麼」：下一篇會走進來源與引用的基礎，看看一筆來源如何先成為系統能辨認和保存的資料。

參考資料

1. ResearchForge 專案 Git 歷史，〈Improve report generator with multi-style and multi-mode capabilities〉中的生成器與預覽程式。用於核對模式、內容區塊、來源提示、品質勾選與完整度計算；本文依歷史原始碼說明，不將回顧查核當成當年的實測。
2. ResearchForge 專案 Git 歷史，〈Add multiple document export options for generated reports〉中的匯出程式。用於核對 Markdown 轉換、Word 文件建立及瀏覽器列印流程，不宣稱已完成當年的跨格式或跨裝置驗收。