用 AI 寫論文最大的風險，不是寫得慢，而是它可能在不知不覺間編數據、編文獻。一個看似完整的段落，引用的論文並不存在；一張漂亮的圖，背後的數字是捏造的。這類問題在生成式寫作裡很難被發現，因為模型更關心「讀起來順不順」，而不是「是不是真的」。MuchSci 的論文水手（PaperAssist）試圖從流程設計上解決這個問題：全流程九步，每一步都產出真實檔案，並在關鍵節點卡住真實數據與真實文獻。
理解它的方式，是把「生成一段文字」和「完成一篇可核對稿件」分開。前者追求的是速度，後者追求的是可追溯。
01 論文寫作工具最怕什麼：編數據、編文獻
AI 寫稿的幻覺有兩種常見形態。
▲ 圖 1｜普通生成式寫作求快，論文水手求每一步都可核對
一種是數據幻覺。 模型不知道你手上有什麼數據，卻可能「合理推測」出一組數字，讓圖表看起來很完整。另一種是文獻幻覺。 模型能生成格式正確的引用，但那條引用對應的論文可能不存在，或者作者、年份、標題對不上。這兩種幻覺的共同點是：它們在局部看起來合理，整體驗收時卻很難一眼識破。
MuchSci 論文水手的做法不是讓模型更誠實，而是用流程把「編造」卡在外面。它要求你上傳真實數據、從真實資料庫建立文獻庫、引用時必須能在庫內找到對應條目。可疑的不是模型，而是沒有約束的生成環境。
02 論文水手的九步鏈路（前八步可見）
截圖裡展示了論文水手的自述介面，可以看到前八步。
▲ 圖 2｜論文水手介面：自述全流程九步，截圖可見前八步
第一步是定方向：把模糊想法整理成研究問題、創意卡和 Proposal。第二步是建文獻庫：多源檢索、轉去重、帶 DOI 和引用數、自動下載 PDF 入庫，然後基於庫內真實摘要寫文獻綜述。第三步是出規劃：生成大綱、章節骨架、目標期刊模板，並把 `data_needed`（需要真實數據的章節）標出來。
▲ 圖 3｜前六步完成選題、文獻、數據、圖表的原始積累
第四步是數據收稿：上傳 CSV / Excel / JSON，pandas 自動畫像，逐章映射「大綱要什麼 → 你手上有什麼 → 輸出缺口分析 + 行動清單」。第五步是數據分析：真實數據跑統計，出圖表。第六步是論文配圖：支援 8 種圖型、多面板拼圖 Figure a/b/c、按期刊欄寬匯出可編輯 SVG。
▲ 圖 4｜第七、八步把「寫出來」和「寫得可靠」分開執行
第七步是寫正文：按章節寫，正文引用用 `[cite:key]`，後台做三方核對（已用 / 缺失 / 未用）。第八步是審查自檢：最多 3 輪 + 鎖定，包括引用真實性校驗和去 AI 味引擎。全流程自稱九步，但截圖只展示到第八步附近，因此第九步的具體細節我們不作推測。
03 真實數據是怎麼被卡住的
數據真實性的關鍵，在於不讓模型有機會「填假數」。
▲ 圖 5｜三個卡點分別對應學術不端風險最高的三個環節
論文水手在數據環節做了幾件事。首先，數據必須上傳，不能憑空生成。其次，pandas 自動畫像後，工具會把大綱要求和現有數據做逐章映射，明確標出缺口。再者，缺口不會自動補上，而是生成行動清單，告訴你還需要什麼。這意味著，如果某個章節需要真實數據但你還沒提供，系統不會替你編一個合理的數字，而是把問題留給你解決。
這個設計的好處是誠實。它犧牲了「看起來完整」的速度，換取了「每一步都可核對」的可靠性。
04 真實文獻是怎麼被卡住的
文獻幻覺更難防，因為引用的格式可以非常規範，但來源是假的。
論文水手的處理方式是建立庫內文獻庫。檢索階段從多個真實數據源命中文獻，自動去重後下載 PDF 入庫。寫作階段的引用格式是 `[cite:key]`，後台會核對這條引用是否確實在庫內、是否被使用過、是否有應引未引的文獻。這種「已用 / 缺失 / 未用」的三方核對，把引用閉環從格式正確推進到了來源可驗證。
當然，這要求使用者真的把文獻庫建立起來。如果庫本身漏掉了關鍵文獻，後台核對也發現不了。所以它卡住的是「編造文獻」，不是「文獻檢索不全」。後者仍然是作者自己的責任。
05 邊界
照例把邊界擺在明面上。
① 本篇講的是功能機制，不是效果承諾。 論文水手透過流程設計降低編造風險，但不能保證每一篇產出的學術質素、創新性或投稿成功率。
② 真實數據與真實文獻的源頭責任仍在作者。 系統能卡住「填假數」和「幻覺文獻」，但無法替你判斷數據是否採集得當、文獻是否覆蓋全面、論點是否成立。
③ AI 參與論文寫作的允許範圍以所在機構現行規定為準。 涉及學術誠信、引用規範、數據使用的最終責任，始終在作者本人。