Anthropic 在 Sonnet 5.5 釋出頁描述了一次內部測試：把一家上市公司的季度財報材料、電話會文字記錄和幻燈片模板交給模型，要求製作 10 頁經營覆盤。兩位專家認為第一版已可直接傳送。
這個例子把 AI 的交付單位從一段回答推進到一組真實工作檔案。對團隊而言，問題隨之變成：檔案能開啟、版式很好看之後，誰證明裡面的數字、解釋和行動建議值得采用？
下面是一套建議的驗收流程，不是復現上述實驗，也不是 Buda 對 Sonnet 5.5 的實測。它適用於“原始材料 → 工作底表 → 經營演示稿”這樣的跨檔案交付。
下單時就約定三個檔案，而不是隻要一份 PPT
第一份是證據表：每條關鍵事實對應檔名、頁碼或段落、期間、單位和原文。第二份是工作底表：保留計算過程、公式及必要的原始數值。第三份才是面向管理者的演示稿。
缺了前兩份，漂亮的 PPT 會讓稽核人逆向追查每個數字。把可追溯材料作為交付物，既能減少複核成本，也能讓下個週期複用同一套口徑。
輸入包也需要邊界：使用哪個季度、幣種、合併範圍與模板；是否允許搜尋補充資訊；缺失資料如何標註；哪些判斷只能寫作建議，不能冒充管理層原話。先明確這些，再讓 Agent 開始製作。
第一關：文件裡的事實有出處，判斷有身份
抽查所有影響結論的事實，而不只是第一頁。收入、利潤、客戶數量、業務調整和管理層承諾，都應能回到原始材料的具體位置。
把內容分成三類：來源明確陳述、模型推導、建議行動。例如“公司預計下季度需求改善”可能是管理層指引；“需求改善會抵消成本上漲”則可能是推導。即使兩句話相鄰，也不能用同一個引用把推導包裝成官方承諾。
對於資料沒有覆蓋的問題，交付物應標註缺口。允許 Agent 補充搜尋時，必須記錄新來源和日期；不允許搜尋時，不應憑訓練記憶補齊最新資料。Sonnet 5.5 的提示文件也建議用搜尋核對可能變化的具體事實。
第二關：表格不只核對結果，還要核對計算鏈
以下為假設示例，不是任何公司的真實財務資料：上期收入 100、本期 120，增速應為 20%；上期毛利率 25%、本期 28%，變化是 3 個百分點，而不是 3%。PPT 裡的數字應引用同一工作底表，避免重新輸入後發生漂移。
檢查期間是否對應、千與百萬是否混用、幣種轉換是否註明，空值有沒有被當作零。重算影響結論的總計和比率，並檢查公式是否覆蓋新增行、是否用錯誤分母、是否遺漏隱藏篩選的資料。
交付 Excel 時，開啟檔案並重新計算，檢查公式與引用，不能只看快取的顯示值。交付 CSV 時，它通常不承載可復算公式，應另附計算指令碼或說明。對業務關鍵數字，人工抽查或獨立程式核驗優於讓同一 Agent 再口頭保證一遍。
第三關：PPT 的敘事應與底表一致
一頁“增長改善”可能沒有算錯，卻忽略了低基數或一次性收入。核對數字之後，還要檢查標題是否誇大、圖表是否隱藏負面變化、時間軸是否一致，以及結論是否足以支援下一頁的行動建議。
可以要求每一頁寫清一個問題、一個判斷和對應證據。不要為了湊滿 10 頁增加材料無法支援的結論。對於仍需決策的事項，標註“待決策”和選項，不把模型建議寫成已批准計劃。
最後在實際展示環境裡開啟：字型替換、圖表截斷、標題溢位、模板錯位、備註和敏感資訊洩漏都屬於交付失敗。數字正確但觀眾看不清，也沒有完成工作。
走完一個經營覆盤：同一組數字，三份不同責任的檔案
下面使用完全虛構的公司與數值，只演示驗收方法。假設上期收入 100、本期 120；上期毛利 25、本期 33.6；本期收入中有一次性專案 18。輸入材料分別是財務表、管理層電話會文字記錄和演示稿模板。財務表有數字，電話會說新客戶需求改善，但沒有給出它對收入增長的貢獻。
證據表先建立四條記錄。 每條都帶上原始檔、位置、期間、單位和提取值。比如收入 120 對應本期財務表的收入行，一次性專案 18 對應附註；“新客戶需求改善”對應電話會原文段落。最後一條應標為管理層表述，而不是一個可以參加加減乘除的數值。
工作底表再計算，而不是讓 PPT 臨時心算。 總收入增長為 (120-100)/100=20%；本期毛利率為 33.6/120=28%，比上期 25/100=25% 提高 3 個百分點。若僅為觀察而從本期扣掉一次性專案，結果是 102；這只是本期的調整值。上期是否存在類似專案未知，因此不能直接把 (102-100)/100=2% 宣稱為可比的持續性增長。
演示稿最後組織判斷。 這一頁可以寫“總收入增長 20%，需拆分一次性因素”，並展示 100→120 的增長和本期 18 的組成；不能寫“核心業務穩定增長 20%”。下一頁可列待核查事項：上期一次性因素、新客戶收入貢獻、下一季度訂單證據。結論留有缺口並不是交付差，而是沒有把未知內容偽裝成已知。
這就是跨檔案驗收的重點：底表算得對，只解決了數學問題；經營結論還取決於分母、調整口徑和證據是否可比。
一次錯誤如何沿檔案傳播，退回時就沿路徑修復
假設證據提取時把一次性專案 18 讀成 1.8。底表的調整後收入會變成 118.2，演示稿便可能誇大持續性表現。此時只改 PPT 上的一句話，錯誤仍留在底表，下一次重生成就會回來。
退回單可以明確寫：
證據表 E04 的提取值應核對附註原文，18 與 1.8 不一致。確認單位及來源後修正 E04，重算底表受影響的調整項，再更新所有引用該項的頁面。總收入和總毛利率不依賴這一調整項，但仍需檢查它們的頁面說明是否被同步改錯。上期調整口徑缺失，保留待核查，不生成可比增速。
這份退回單同時指定了源頭、影響範圍和不能擅自補齊的缺口。Agent 的修復報告應列出改了什麼、重算了什麼、哪些頁變了、哪些檢查沒跑。稽核人再抽查源頭和依賴項，而不是接受一句“已全部修好”。
發出前，一套有責任人的驗收記錄
驗收表不必複雜，但每一項要有物件和失敗動作：
| 檢查物件 | 可接受的證據 | 失敗時怎麼處理 |
|---|---|---|
| 關鍵事實與單位 | 對應原始位置、提取值與期間 | 退回證據表，暫停依賴結論 |
| 關鍵公式與分母 | 獨立重算結果、公式引用檢查 | 修底表並同步所有依賴圖頁 |
| 調整後指標 | 兩期口徑和調整規則一致 | 不釋出可比增速，標註缺口 |
| 經營判斷 | 明確區分原話、推導與建議 | 改寫標題，撤掉無來源因果 |
| 實際展示 | 在目標裝置開啟的版本、無截斷或敏感備註 | 修版式或移除敏感內容再匯出 |
| 最終放行 | 稽核人、輸出版本、未解決項與用途 | 不把草稿當批准版本傳播 |
證據表審查、公式檢查和最終放行可以由不同人承擔。部門確認資料口徑，不等於批准整份行動建議；演示稿批准內部討論，也不等於批准外部發布。把用途寫清楚，才能讓團隊知道這份檔案到底能拿來做什麼。
對重複任務，可以先固化模板、欄位定義和退回單，再讓 Agent 批次執行。批次生成不應擴大缺失事實的補全許可權；連續幾個季度使用，也不能讓舊指引和舊審批自動變成當前有效記錄。
把三關變成可退回的交付流程
先讓 Agent 交證據表和底表，再確認關鍵口徑，最後生成演示稿；或先做一版完整草稿，但在傳播前執行同樣的驗收關口。哪種順序更合適，取決於返工成本與期限。
發現問題時，退回具體檔案、頁碼和欄位。例如“第 4 頁增長率來自錯誤期間，請修正底表 C8，並同步第 4、7 頁”，比“再嚴謹一點”更容易驗證。修復後核對受影響檔案，不必毫無區別地重做全部內容。
儲存驗收記錄：輸入版本、輸出版本、檢查項、稽核人、結論與未解決問題。換一名稽核人或進入下個季度時，才能知道哪些口徑已經確認，哪些數字必須更新。
讓執行與可信記錄各自有歸屬
Buda 承接 Agent 執行、上下文與可複用流程。可以把輸入包、檔案產出要求和驗收清單組織為重複使用的工作流；如果使用可安裝的 Skill，可以在 Buda AI 的 Marketplace 搜尋並安裝，再按團隊任務調整。
當已核實的經營事實、指標定義或批准事項需要成為正式記錄時，Busabase 可以透過 ChangeRequest 讓變更經稽核後進入可信知識庫，並留下審計軌跡。它不替稽核人驗證財務事實，也不意味著 Agent 生成的整份演示稿自動獲得批准。
模型完成更多檔案工作，人類的價值便更多體現在設定口徑、發現異常和判斷行動。能直接傳送的第一稿值得關注；能持續被複核、修正和複用的交付流程，才適合進入團隊日常工作。
FAQ
兩位專家認可第一稿，是否等於無需稽核？
不是。它是廠商報告的一次內部測試結果，沒有構成所有財務場景的保證。
Word、Excel、PPT 可以用同一清單嗎？
可以共享來源和版本要求，但驗收物件不同：文件看事實與判斷，表格看計算鏈，PPT 看敘事與展示。
應該先追求自動化，還是先建驗收標準？
先寫出最小驗收標準和失敗退回方式，再擴大自動化範圍，避免把稽核債務留到傳播之後。
圖表複雜時，提高 effort 就夠了嗎？
不一定。官方提示測試表明，裁剪、放大和程式碼工具有助於讀取密集圖表；工具與輸入質量也需要納入設計。