技術提案寫完後，常見的問題是結論超出證據、前後使用不同假設，或表格和正文對不上。Google 在 2026 年 10 月 14 日公開推出 Deep Review，把 AI 用在這類文件審查工作，並提供每週兩次免費審查額度。
對需要送審設計文件、研究論文或技術報告的人來說，重點是找出哪些地方需要重新驗證。這篇整理 Deep Review 的定位與使用入口，並以設計提案為例，說明怎麼準備文件及處理回饋。
Deep Review 是什麼
Deep Review 是 Google Research 開發的 AI 文件審查系統，前身為 Paper Assistant Tool（PAT）。PAT 原本協助電腦科學論文在投稿前找出技術問題；這次公開版本把使用範圍擴大到其他複雜文件。它要處理的是長篇內容的驗證工作，與濃縮重點的摘要工具、調整語句的潤稿工具有不同任務。產品定位與開放資訊可見 Google 官方公告 。
例如，系統設計提案可能在前半部假設資料會即時同步，後半部卻用每日批次更新估算成本。兩個段落各自看都通順，放在一起才出現落差。文件審查要找的就是這種影響結論的關係；這是用途示例，並非本篇的實測結果。
免費額度、格式與資料保存方式
截至 2026 年 10 月 20 日，Google 公布的基本條件如下。使用前可以從 Deep Review 官方入口 查看當下可用功能。
網頁提供 Sign in with Google，說明登入後可查看已提交的文件及執行新的審查。右側的 Gemini API key 欄位則用於支付額外審查的 token 費用；每週兩次免費額度用完後，可以提供自己的 Gemini API Key 繼續使用。Google 帳號負責身分驗證，API Key 負責額外用量的計費。
| 項目 | 公開推出時的條件 |
|---|---|
| 免費使用 | 每位使用者每週兩次文件審查 |
| 輸入格式 | PDF、純文字 |
| 較高用量與程式整合 | 連接 Gemini API Key；另有 Deep Review API |
| 多檔案輸入 | 官方預告將提供，尚非首發支援 |
| 模型訓練 | 上傳文件不拿來訓練、微調或改善 Google 模型 |
| 保存期限 | 保存一年，用於在 Deep Review 介面向使用者顯示文件 |
要處理保密文件時，可以先核對組織是否允許把內容交給這項雲端服務，以及一年保存期限是否符合要求。確認可上傳後，再移除與審查無關的憑證、客戶識別資訊與內部連線資料，保留論證需要的條件、表格及引用。
分段審查如何保留全文關係
PAT 研究論文 描述的核心方法，是先依內容分段並配置運算預算，再由專門的 Agent 檢查，最後彙整與查證。各 Agent 專注指定部分時仍取得全文，才能追蹤跨章節的定義與引用。Deep Review 延續這種分工方式。
分工的價值在於讓審查任務更具體。以剛才的同步設計為例，檢查成本的工作需要對照前面承諾的更新頻率；若只提供成本那一頁，就缺少判斷所需的條件。最後彙整也需要把多處相同問題合併，避免同一個假設錯誤被列成數項獨立缺陷。
研究論文也指出，單純多跑幾次模型會增加待查的問題數量，錯誤指控同樣可能增加。因此收到較長的問題清單時，適合依原文證據判斷優先序，而不是以清單長度衡量審查品質。
文件準備與審查結果的處理方式
建議先選一份可以上傳、已有完整論證的文件，經官方入口登入。畫面提供 Upload document 與 Paste text 兩個入口，可選擇上傳文件或直接貼上文字。
這次以一篇中文文章實測，約等候 10–15 分鐘收到審查報告。儘管被審查的文章是中文書寫的，Deep Review 產出的依然是全英文的審查報告。這是目前測試的結果，實際等待時間與報告語言可能會隨著使用情境或是Google更新而改變。
文件審查需要的條件
用來審查的版本適合保留章節名稱、頁碼、表格標題、單位與來源，並註明哪些內容已確認、哪些仍是假設。如果一份容量規劃只寫「每天一百萬次請求」，卻沒交代尖峰分布、回應大小或延遲目標，審查者很難判斷架構是否合理。補齊條件，比只增加背景文字更有幫助。
Google Docs 或簡報可以先匯出成 PDF，確認文字可選取、圖表標籤完整，並檢查匯出後是否漏頁。PDF 與純文字是官方公布的首發輸入格式；Docs、簡報可以是文件用途，實際提交仍依入口提供的格式辦理。
審查回饋的核對與處理
下表是整理回饋的示例，可用於 Deep Review 或人工審查。每項問題都對回原文位置，再決定要補資料、重新計算或修改論證。
| 示例回饋 | 核對方法 | 後續處理 |
|---|---|---|
| 成本表使用的請求數與前文不同 | 查明兩處是否涵蓋相同期間與流量 | 統一條件，或補上差異說明 |
| 缺少失敗後的資料恢復流程 | 確認是否已有其他章節或附件描述 | 補流程，或加入明確交叉引用 |
| 某項技術能力沒有來源 | 回查該版本的官方文件 | 加入來源或縮小主張 |
| 指稱公式錯誤，但未提出有效理由 | 逐步重算並檢查符號定義 | 保留驗算紀錄，由負責人判斷 |
完成修改後，可以在版本紀錄保留問題、證據與處置結果。這樣下一位審查者能看出哪些地方改過，以及哪些建議經核對後沒有採用。對同一版本反覆要求審查時，也能避免把措辭不同的重複意見當成新問題。
研究成果與使用限制
ICML 的 PAT 試辦回顧 記錄了投稿前回饋的使用方式：意見只提供給論文作者，和正式審稿程序分開，審稿者及大會審查主管看不到這些回饋。這個設計讓研究者有機會先修正問題，再進入原本的審查流程。
PAT 論文列出的限制包含 PDF 解析問題，以及推理失誤導致誤判論證。遇到「某段證明不成立」這類回饋，可以要求負責該部分的人對照原文條件與計算；如果報告沒有提供足以重現的理由，就先列為待確認。早期 PAT 的評估也有自己的模型、題目與判分條件，本文不把它換算成公開版對所有文件的準確率。
對只有幾段文字的通知信，人工通讀或一般潤稿可能就足夠。當文件包含多個彼此相依的假設、公式、表格與引用時，安排一輪結構化審查更有用途。需要核准設計或投稿時，仍由負責人依實際證據與審查規則做決定。
常見問答
選擇使用方式時，可以先確認免費額度與回饋的適用範圍。
Deep Review 可以免費使用嗎
可以，公開推出時提供每週兩次免費文件審查。較高用量與 API 整合另走官方提供的 Gemini API Key 入口，使用前核對費用與額度。
審查報告可以當成正式同儕審查嗎
不行，收到工具回饋不會取得會議或期刊的審查資格。以 ICML 的 PAT 試辦為例，回饋用途是協助投稿者改稿，與正式審查分開。