按下「生成」之後，畫面先出現等待中的灰色區塊，再換成有標題、章節與結論的報告。這是 ResearchForge 最初版本已經寫進程式的互動。可是，沿著按鈕往下讀，找不到模型正在寫作的呼叫；控制這段變化的，是一個計時器。

這讓我重新界定系列的起點。它當時還叫 Report Builder AI，先做出的是「一份報告如何出現在使用者面前」的介面原型。我想從這個差距開始：當畫面已經有成品，程式究竟完成了什麼，又還沒完成什麼？

生成按鈕後面，先是一個計時器

第一版讓使用者填入主題、選擇報告類型與讀者，再調整語氣及參考材料。流程有前進與返回，也會阻止空白主題進入下一步。這些互動確實存在，不能因為研究能力尚未建立，就把整個原型說成毫無功能。[1]

但「生成」是另一回事。以下節錄初始版本按下生成按鈕時會執行的函式，只略去空白行，保留原本的邏輯：[1]

const handleGenerate = () => {
  setIsGenerating(true);
  setHasGenerated(false);
  // Simulate generation delay
  setTimeout(() => {
    setIsGenerating(false);
    setHasGenerated(true);
  }, 2500);
};

isGenerating 與 hasGenerated 是控制畫面顯示的狀態。按鈕先打開等待畫面，再由 setTimeout 排定回呼，把畫面切到報告預覽。程式裡的 2500 是模擬等待的設定值，單位是毫秒，不是模型速度的實測結果。

這段程式解決的是原型裡「等待時顯示什麼、結束後顯示什麼」的問題。它沒有送出研究請求，也沒有接收生成內容。預覽中的主要段落早已寫在頁面裡，只有部分位置代入主題、讀者與語氣。把標題換成另一個題目，不會讓固定的商業建議自動變成那個題目的研究結果。[1]

因此，這裡真正完成的是介面狀態的切換。我不能從 hasGenerated 這個變數名稱，推論背後已有一套文字生成服務。

有參考材料欄位，不代表內容讀過它

更值得追問的是，畫面已經有「參考材料」輸入區，也有是否包含資料來源的開關。對研究工具而言，這些名稱都帶著承諾：填進去的材料應該影響正文，顯示的來源應該能解釋正文根據什麼。

初始程式卻停在更前面。輸入區會把文字存進 referenceMaterial，也就是存放參考材料的欄位，但生成函式不讀取它；預覽與複製文字的邏輯也沒有拿它來組成內容。資料來源開關控制的是固定清單要不要出現，不是搜尋或查核來源的程序。[1]

例如，假設我把主題填成「校園圖書館的借閱服務」，再放入一段關於借閱流程的材料。依照這版程式，畫面仍會沿用資源配置、供應商協商等固定建議。這是依程式邏輯推演的例子，並非真實使用者測試；它也不是模型答錯，因為這條路徑還沒有呼叫模型。[1]

我現在會特別留意這類斷點。調整文字語氣之前，先問輸入有沒有被使用。如果材料根本沒進入處理流程，再完整的章節也無法證明報告讀過那些材料。

原型的價值，不需要靠研究成果來證明

這並不表示應該跳過介面，直接建造龐大的研究系統。先做可操作的原型，能讓我檢查原本抽象的問題：主題放在哪裡輸入？哪些設定適合一起出現？讀者能否分清楚編輯區與預覽區？等待時要留下什麼提示？

在這個階段，固定內容有它的用途。它讓版面與操作流程可以先被討論，不必等所有後端能力都到齊。代價是，檢查原型的人必須知道哪些內容只是展示用，否則很容易把介面的完整感延伸成對內容的信任。

複製與匯出就是很清楚的例子。第一版有把組好的 Markdown 文字交給剪貼簿的程式；Markdown 是用簡單符號標示標題與清單的文字格式。但 PDF 與 DOCX 按鈕只會顯示尚未提供的提示，沒有建立檔案的邏輯。我只能說「有匯出入口」，不能把它寫成「已經能下載文件」。[1]

這也是我回看舊版時需要修正的說法。「能產生報告」把太多事情塞進同一句話：可以看到預覽、可以取得文字、可以下載檔案、內容有來源，未必同時成立。把它們分開，才看得見下一步真正缺少的工作。

把起點留在它真正的位置

早期開發學習紀錄提到，專案曾面對範圍過大的問題。「報告」可以是商業摘要、讀書心得，也可以是研究報告；名稱相近，所需的資料與寫作方法卻不同。紀錄描述了後續收斂方向的思考，但它是事後整理，不能拿來證明最初程式已具備那些能力。[2]

因此，我把這篇的歷史範圍停在最初那個生成器原型。它有主題設定、內容選項與預覽，沒有在生成路徑裡完成材料處理。學習紀錄能補充「問題為何逐漸被重新理解」，實際程式則告訴我「當時做到哪裡」。兩種資料可以並讀，不能互相代替。

現在回頭看，我當時解的是如何讓報告出現在眼前，尚未解決報告裡的話憑什麼可以相信。這個起點仍然重要；它把一個產品想法變成可檢查的介面，也讓「填入材料」與「使用材料」之間的距離，有了具體可以追查的位置。

沿著一個輸入，檢查它走到了哪裡

如果你也在做 AI 內容工具，可以先挑一個輸入欄位，沿著程式追到輸出。不要先數畫面上有多少功能，而是看這個值在哪裡被存下來、由哪段邏輯讀取，最後改變了什麼。

以這次的參考材料為例，只確認文字框能輸入還不夠。接著應該檢查產生正文的函式是否收到材料，以及輸出是否能說明用了哪部分內容。這是我從舊程式整理出的檢查方法，不是宣稱早期已經有完整的自動化驗證。

同樣的方法也能用在完成狀態上。當畫面亮起「完成」，試著問它是由什麼事件觸發：計時器的回呼執行了、外部服務回應了，還是結果真的經過檢查？每個答案代表不同的能力。介面上的同一句提示，不應掩蓋背後仍未完成的步驟。

即使日後接上真正的文字生成，也不能只靠「材料已送入」就認定引用成立。還得能從正文的一句話，回頭找到支持它的材料。追蹤欄位的去向，是找出缺口的起手式；它本身並不保證內容正確。

下一篇，我會接著看早期版本如何加入模式、模板與文件匯出。那些改動讓交付形式更完整，也適合用來繼續拆解：一份文件變得更像成品，究竟替內容解決了哪些問題，又留下了哪些問題。

參考資料

1. ResearchForge 專案 Git 歷史，〈Create initial version of the AI report generator website〉中的生成器頁面與後端路由。用於核對模擬生成、固定正文、參考材料欄位與匯出入口；本文依原始碼判讀，未宣稱重跑當年的服務。
2. ResearchForge 專案文件，〈早期開發學習紀錄〉。用於理解報告類型與產品範圍的反思；屬事後整理，不作為首版能力或精確工時的證明。