上個(gè)月旁聽(tīng)了一場(chǎng)內(nèi)部分享主題叫「AI 自動(dòng)生成經(jīng)營(yíng)報(bào)表」。演示的時(shí)候很熱鬧模型幾十秒吐出一張格式整齊的表格投屏上看著挺像回事。可等主講人把內(nèi)容貼進(jìn)真正的電子表格里問(wèn)題全冒出來(lái)了——數(shù)字全成了文本求和結(jié)果是 0合并單元格被沖散原本該是公式的列變成了寫(xiě)死的值源數(shù)據(jù)一改報(bào)表就再也不動(dòng)了。那一刻我腦子里蹦出來(lái)的判斷很直接這不是 AI 的能力問(wèn)題是文檔的接口問(wèn)題。生成一段看起來(lái)像表格的文本和真正在一份文檔里操作狀態(tài)中間隔著整整一層?xùn)|西。前者是說(shuō)后者是做。而做需要文檔本身提供一個(gè)可編程、可回滾、可校驗(yàn)的運(yùn)行時(shí)——這正是 univer 這類(lèi)文檔引擎值得被重新審視的地方。后面我想聊的就是這件事當(dāng) AI 不再滿足于往文檔里塞內(nèi)容而是開(kāi)始真的用文檔我們需要在工程上準(zhǔn)備什么。適合正在做 AI 工具調(diào)用、文檔協(xié)作、低代碼報(bào)表這類(lèi)產(chǎn)品的前端和數(shù)據(jù)方向的同學(xué)也適合單純好奇AI 到底怎么點(diǎn)表格的讀者。1. 「生成內(nèi)容」和「操作文檔」之間差著一整層狀態(tài)模型很多人第一反應(yīng)是把這事理解成提示詞工程只要讓模型輸出合法的表格結(jié)構(gòu)問(wèn)題不就解決了我一開(kāi)始也這么想直到把同一套提示詞換到不同的文檔底座上跑結(jié)果差異大到不像同一個(gè)模型干的活。差別不在模型在底座有沒(méi)有把文檔的狀態(tài)暴露出來(lái)。1.1 一個(gè)反直覺(jué)的現(xiàn)象模型能力漲了卡點(diǎn)反而更靠下早期模型笨瓶頸確實(shí)在理解層——它連把 B 列改成百分比這句話都解析不清楚。現(xiàn)在這層基本被抹平了模型能準(zhǔn)確說(shuō)出它要做什么甚至能自己規(guī)劃分幾步?？梢坏┧焓秩ジ哪銜?huì)發(fā)現(xiàn)新的瓶頸全部堆在文檔這一側(cè)改完之后單元格的行列索引對(duì)不上、公式?jīng)]重算、格式被覆蓋、改錯(cuò)了沒(méi)法一步撤回、多個(gè)會(huì)話同時(shí)改同一張表互相踩。換句話說(shuō)AI 從想不明白進(jìn)化到了想明白了但下不去手。這時(shí)候繼續(xù)優(yōu)化提示詞是無(wú)效功得把文檔從一個(gè)給人看的界面改造成一個(gè)給程序調(diào)用的運(yùn)行時(shí)。這個(gè)視角的轉(zhuǎn)換是我認(rèn)為整個(gè)討論里最關(guān)鍵的一步。1.2 為什么純前端渲染的老路走不通傳統(tǒng)電子表格的實(shí)現(xiàn)思路是界面即狀態(tài)單元格是 DOM 節(jié)點(diǎn)值掛在節(jié)點(diǎn)上選中靠 CSS 類(lèi)名改動(dòng)靠事件監(jiān)聽(tīng)。這套東西對(duì)人很友好對(duì)機(jī)器極其不友好——因?yàn)闆](méi)有一份脫離視圖的、可序列化的數(shù)據(jù)真相。舉個(gè)具體的例子。人看到的是第 3 行第 2 列現(xiàn)在是 12800但程序要去改它得先知道這是數(shù)據(jù)行還是表頭行上面有沒(méi)有隱藏行這張表是不是被凍結(jié)了合并單元格的左上角錨點(diǎn)在哪當(dāng)前用戶是不是正在編輯這個(gè)格子這些問(wèn)題在純 DOM 方案里全是隱式的而 AI 調(diào)用是沒(méi)有上下文感知能力的它只知道自己拿到了一個(gè)坐標(biāo)。只要有一個(gè)隱式假設(shè)沒(méi)對(duì)上寫(xiě)進(jìn)去的位置就偏了。1.3 文檔運(yùn)行時(shí)至少要提供三樣?xùn)|西在我實(shí)際用過(guò)的幾套底座里能真正撐起AI 操作文檔這個(gè)場(chǎng)景的都得同時(shí)具備三件事缺一不可一份脫離視圖的狀態(tài)模型工作簿 → 工作表 → 行列表 → 單元格能整體快照、能增量 patch、能序列化成 JSON 落庫(kù)。一條命令通道不是直接改數(shù)據(jù)而是發(fā)一條有語(yǔ)義、有參數(shù)校驗(yàn)、天然可撤銷(xiāo)的命令。一個(gè)可回滾的邊界一次 AI 操作對(duì)應(yīng)一個(gè)事務(wù)出錯(cuò)能整體退回去而不是留下半張改壞的表格。這三樣?xùn)|西日常給人用的表格軟件其實(shí)都偷偷實(shí)現(xiàn)了只是沒(méi)對(duì)外開(kāi)放成穩(wěn)定的 API。univer 讓我覺(jué)得有意思的點(diǎn)在于它從設(shè)計(jì)上就是圍繞這三個(gè)東西長(zhǎng)出來(lái)的——它把自己定位成文檔引擎而不是表格組件這個(gè)定位差異后面會(huì)越來(lái)越重要。2. 拆開(kāi) univer這個(gè)文檔運(yùn)行時(shí)里到底跑著什么我不打算把 univer 的每個(gè)包都念一遍包名和版本一直在演進(jìn)寫(xiě)死了反而誤導(dǎo)人。我按實(shí)際調(diào)試時(shí)的心智模型來(lái)講它內(nèi)部可以粗略切成四層每層在 AI 場(chǎng)景里承擔(dān)的角色完全不同。理解了這個(gè)分層你就知道該把 AI 接在哪一層、以及為什么不能接在別的地方。2.1 四層結(jié)構(gòu)數(shù)據(jù)、公式、渲染、命令層主要職責(zé)AI 場(chǎng)景下的角色該不該直接碰數(shù)據(jù)模型層工作簿/工作表/單元格/富文本/樣式/行列結(jié)構(gòu)唯一真相快照來(lái)源只讀投影不直改公式引擎層依賴圖、計(jì)算鏈、重算調(diào)度保證 AI 讀到的是算完的值間接依賴必須觸發(fā)重算渲染層基于畫(huà)布的繪制、視口、選區(qū)負(fù)責(zé)展示不產(chǎn)生狀態(tài)完全不碰命令與 UI 插件層命令注冊(cè)、參數(shù)校驗(yàn)、撤銷(xiāo)棧、協(xié)作廣播AI 的入口全部從這里進(jìn)這個(gè)表里最容易被忽略的是第三列和第四列的對(duì)比。很多團(tuán)隊(duì)做 AI 表格功能時(shí)圖省事直接往數(shù)據(jù)模型層塞值——反正改完渲染層會(huì)自己刷新看著是通的。但這么干等于繞過(guò)了命令層也就同時(shí)繞過(guò)了參數(shù)校驗(yàn)、撤銷(xiāo)棧和協(xié)作廣播。單機(jī) Demo 完全看不出問(wèn)題一上多人協(xié)作就變成我這邊改了對(duì)面不刷新用戶按 CtrlZ 撤銷(xiāo)的是別人的操作這種靈異現(xiàn)象。2.2 Facade 是給人和簡(jiǎn)單腳本用的Command 才是給 AI 用的univer 對(duì)外有兩套調(diào)用方式我調(diào)試的時(shí)候兩套都試過(guò)。一套是 Facade寫(xiě)法很像常見(jiàn)的鏈?zhǔn)?API比如拿到當(dāng)前工作簿、拿到某個(gè)工作表、再拿一個(gè)區(qū)域?qū)ο?、然后設(shè)值——讀起來(lái)非常順寫(xiě) Demo 特別快。另一套是命令需要你帶上命令名和結(jié)構(gòu)化參數(shù)扔給命令服務(wù)去執(zhí)行比如批量設(shè)置區(qū)域的值、插入行列、設(shè)置公式這些。給 AI 用我一定選命令。原因不在于命令更底層而在于三個(gè)具體差別可撤銷(xiāo)。走命令通道的改動(dòng)會(huì)自動(dòng)進(jìn)撤銷(xiāo)棧這意味著 AI 改錯(cuò)了用戶可以像撤銷(xiāo)自己的操作一樣撤掉它。Facade 直調(diào)很多時(shí)候不進(jìn)棧或者進(jìn)棧粒度不對(duì)?？尚ｒ?yàn)。命令執(zhí)行前有參數(shù) schema 校驗(yàn)AI 傳個(gè)不存在的 sheet 名、傳個(gè)越界坐標(biāo)會(huì)在執(zhí)行前被攔下來(lái)并報(bào)錯(cuò)而不是悄悄寫(xiě)到一個(gè)幽靈位置?？蓞f(xié)同。協(xié)作場(chǎng)景下命令是要廣播給其他端的直改數(shù)據(jù)模型不會(huì)廣播或者只廣播了一半。還有一點(diǎn)很實(shí)際命令天然是冪等設(shè)計(jì)友好的。你給命令帶一個(gè)唯一的 requestId重復(fù)執(zhí)行時(shí)可以在入口處攔掉。這在 AI 場(chǎng)景下不是錦上添花——模型調(diào)用超時(shí)重試太常見(jiàn)了沒(méi)有冪等保護(hù)重試一次就多插一行數(shù)據(jù)用戶看到的就是報(bào)表里憑空多出幾條重復(fù)記錄。2.3 公式引擎AI 最容易忽略的隱式依賴這一層我想單獨(dú)拎出來(lái)說(shuō)因?yàn)樗俏也鹊米钌畹囊粋€(gè)坑。AI 讀表格的時(shí)候它讀到的往往是單元格的當(dāng)前顯示值而這個(gè)值可能是公式算出來(lái)的。如果底層公式引擎還沒(méi)完成重算你給模型的是一份過(guò)期快照模型基于過(guò)期數(shù)據(jù)做決策改出來(lái)的東西自然不對(duì)。更麻煩的是反向的問(wèn)題AI 寫(xiě)入一批原始數(shù)據(jù)之后依賴這些數(shù)據(jù)的公式單元格需要重算重算結(jié)果又可能被 AI 在下一步讀取。這條鏈路如果沒(méi)接好你會(huì)看到模型反復(fù)自我懷疑——它讀了三次數(shù)據(jù)得到三個(gè)不同的值然后在思考過(guò)程中開(kāi)始道歉。我在實(shí)踐里的處理辦法是把「寫(xiě)」和「讀」嚴(yán)格分開(kāi)成兩個(gè)階段寫(xiě)完先觸發(fā)一次全量重算并等待完成再讓模型去讀。犧牲一點(diǎn)點(diǎn)時(shí)延換來(lái)的是模型看到的數(shù)字和用戶看到的數(shù)字絕對(duì)一致。這個(gè)一致性比省那兩百毫秒重要得多。2.4 快照與事務(wù)給 AI 準(zhǔn)備的「后悔藥」univer 內(nèi)部有快照能力可以把整個(gè)工作簿的狀態(tài)序列化出來(lái)。這個(gè)能力在 AI 場(chǎng)景里有一個(gè)非常實(shí)用的用法在每一次工具調(diào)用循環(huán)開(kāi)始前打一個(gè)快照循環(huán)結(jié)束后做一次校驗(yàn)校驗(yàn)不過(guò)就直接用快照還原。這比讓模型自己改回來(lái)可靠一個(gè)數(shù)量級(jí)。我試過(guò)讓模型在發(fā)現(xiàn)改錯(cuò)后輸出一條撤銷(xiāo)上一步的操作成功率大概七成——它經(jīng)常撤銷(xiāo)得過(guò)多或者過(guò)少因?yàn)樗鼘?duì)自己剛剛做了什么的理解是有偏差的。而用快照還原是確定性的百分之百回到原點(diǎn)。代價(jià)是內(nèi)存。一份幾千行的工作簿完整快照在幾十毫秒到幾百毫秒之間序列化出來(lái)可能幾 MB。所以我的做法不是每步都打快照而是按任務(wù)打一個(gè)用戶請(qǐng)求進(jìn)來(lái)打一次任務(wù)結(jié)束釋放。中間步驟靠命令級(jí)別的撤銷(xiāo)棧兜底。這兩層保護(hù)疊在一起基本能做到隨便改壞了都能回來(lái)。3. 把文檔包裝成工具接口設(shè)計(jì)上必須做的五個(gè)取舍到這一層問(wèn)題從文檔能不能被程序操作變成了怎么操作才不讓模型翻車(chē)。這兩件事的難度差很遠(yuǎn)。前者是工程問(wèn)題后者是設(shè)計(jì)問(wèn)題而且后者沒(méi)有標(biāo)準(zhǔn)答案只有一堆取舍。下面五條是我在真實(shí)項(xiàng)目里反復(fù)調(diào)過(guò)的每一條都附上我最后選了什么、以及為什么。3.1 給 AI 的 API 不該照抄給人用的 API人用的 API 講究靈活一個(gè) setValue 可以傳單值、可以傳二維數(shù)組、可以傳公式字符串、可以帶樣式。給 AI 用的 API 必須窄每種意圖一個(gè)獨(dú)立工具參數(shù)少、語(yǔ)義單一、失敗原因明確。我最終的工具有這么幾個(gè)讀區(qū)域、批量寫(xiě)值、插入行、插入列、設(shè)置公式、設(shè)置數(shù)字格式、合并單元格、刪除行。就這八個(gè)覆蓋了九成以上的報(bào)表操作需求。工具越少模型選錯(cuò)的概率越低參數(shù)越扁平模型填錯(cuò)的概率越低。我一開(kāi)始貪心做了十六個(gè)工具結(jié)果模型有相當(dāng)比例的錯(cuò)誤是選錯(cuò)了工具而不是填錯(cuò)了參數(shù)收斂到八個(gè)之后錯(cuò)誤率明顯下降。另外工具描述里一定要寫(xiě)清楚坐標(biāo)系。是 0-based 還是 1-based行號(hào)和列號(hào)哪個(gè)在前A1 表示法是絕對(duì)還是相對(duì)。這些在人看來(lái)是常識(shí)的東西模型會(huì)一本正經(jīng)地搞混而且搞混的方式很隱蔽——它不會(huì)報(bào)錯(cuò)它只會(huì)寫(xiě)到一個(gè)相鄰的位置上。3.2 讀取比寫(xiě)入難怎么給模型一份夠用又不爆 token的視圖寫(xiě)是明確的讀是模糊的。一張兩萬(wàn)行的工作表全量序列化給模型token 直接爆炸而且模型在超長(zhǎng)上下文里的定位精度會(huì)下降。但你要是只給個(gè)摘要它又沒(méi)法定點(diǎn)修改。我現(xiàn)在用的是三段式投影先給結(jié)構(gòu)工作簿里有哪些 sheet、每個(gè) sheet 的行列數(shù)、前兩行內(nèi)容當(dāng)作表頭猜測(cè)、每列的粗略類(lèi)型推斷數(shù)字/日期/文本/公式。再給窗口只給模型實(shí)際會(huì)被問(wèn)到的那個(gè)區(qū)域加上上下各三行的緩沖。最后給線索如果有公式列單獨(dú)列出公式文本讓模型知道這一列是算出來(lái)的不能直接寫(xiě)值。這套投影把一次典型請(qǐng)求的輸入 token 從幾萬(wàn)壓到了兩千以內(nèi)。壓下來(lái)的不只是成本更重要的是模型的表現(xiàn)明顯變穩(wěn)了——上下文越短它越不容易在中途忘了自己要干什么。3.3 事務(wù)粒度決定你能不能全身而退一個(gè)用戶請(qǐng)求模型可能規(guī)劃出五步操作。這五步應(yīng)該是一個(gè)事務(wù)還是五個(gè)事務(wù)我兩種都試過(guò)結(jié)論是按語(yǔ)義單元切不要按調(diào)用次數(shù)切。舉個(gè)例子「給這張表加一列環(huán)比、并調(diào)整成百分比格式」。這在語(yǔ)義上是一個(gè)單元用戶的心智是我要一列環(huán)比不是我要先插列再寫(xiě)公式再改格式。如果按調(diào)用次數(shù)切成三個(gè)事務(wù)用戶在中間一步失敗后點(diǎn)撤銷(xiāo)只會(huì)撤掉格式留下一個(gè)半成品列。按語(yǔ)義單元切失敗就整體回滾用戶看到的是沒(méi)改成而不是改了一半。實(shí)現(xiàn)上就是在工具循環(huán)外層包一層事務(wù)循環(huán)內(nèi)所有命令共享同一個(gè) undo 邊界。univer 的命令服務(wù)支持這種組織方式具體 API 名字各版本有差異但思路是通用的進(jìn)循環(huán)前開(kāi)邊界出循環(huán)時(shí)根據(jù)校驗(yàn)結(jié)果決定提交還是回滾。3.4 校驗(yàn)與自愈讓模型自己發(fā)現(xiàn)「改錯(cuò)了」我對(duì)模型的一個(gè)基本假設(shè)是它會(huì)認(rèn)為自己改對(duì)了。所以校驗(yàn)不能靠模型自省得靠程序斷言。我在每次寫(xiě)入后跑一組固定檢查區(qū)域尺寸是否和預(yù)期一致防止合并單元格把范圍吃掉數(shù)值列里有沒(méi)有混進(jìn)文本用類(lèi)型判斷不看顯示值公式單元格有沒(méi)有產(chǎn)生錯(cuò)誤值常見(jiàn)的是除零和引用失效關(guān)鍵匯總行是否等于明細(xì)的聚合結(jié)果這一條最能抓到邏輯錯(cuò)誤任何一條不過(guò)我不直接把錯(cuò)誤拋給用戶而是把斷言結(jié)果作為一條新的消息回灌給模型讓它自己重試一次。實(shí)測(cè)下來(lái)第一次校驗(yàn)失敗率大概在兩成左右回灌一次之后能修好其中的大部分。剩下的才升級(jí)給用戶而且?guī)厦鞔_的哪一步?jīng)]通過(guò)說(shuō)明用戶手動(dòng)改起來(lái)也快。這個(gè)自愈循環(huán)有個(gè)上限我設(shè)的是兩次。超過(guò)兩次還在同一個(gè)斷言上失敗說(shuō)明是這個(gè)任務(wù)的描述本身有歧義繼續(xù)讓模型試只是在燒錢(qián)。3.5 并發(fā)與協(xié)作多人加多 Agent 同文檔時(shí)的沖突這塊是最容易被低估的。一旦文檔進(jìn)入?yún)f(xié)作模式同一個(gè)格子上可能同時(shí)有用戶 A 的手動(dòng)編輯、用戶 B 的粘貼、以及一個(gè) AI Agent 的批量寫(xiě)入。三方并發(fā)誰(shuí)來(lái)贏我采取的策略是給 AI 留出存在感AI 的每一次寫(xiě)入都走正常命令通道帶上操作者標(biāo)識(shí)因此它產(chǎn)生的變更是能被其他端看到的、能被別人撤銷(xiāo)的、也能被別人覆蓋的。聽(tīng)起來(lái)有點(diǎn)殘酷——AI 寫(xiě)的東西可能被人隨手覆蓋——但這恰恰是對(duì)的因?yàn)樵趨f(xié)作語(yǔ)境下AI 就是一個(gè)普通參與者它不該有特權(quán)。真正需要額外處理的是AI 基于過(guò)期視圖做決策這個(gè)問(wèn)題。用戶在 AI 思考的這幾秒里改了數(shù)據(jù)AI 醒來(lái)后按老數(shù)據(jù)去寫(xiě)就會(huì)覆蓋掉別人的改動(dòng)。我的解法是在提交前做一次輕量的版本比對(duì)如果目標(biāo)區(qū)域在 AI 讀取之后被改動(dòng)過(guò)就中止并讓模型重新讀一遍。這個(gè)檢查很便宜但省掉了大量我的改動(dòng)怎么沒(méi)了的投訴。4. 一次跑通的鏈路讓 Agent 給銷(xiāo)售看板補(bǔ)一列環(huán)比講原理講多了容易空我把一次真實(shí)跑通的流程完整拆開(kāi)。場(chǎng)景不復(fù)雜一張按周匯總的銷(xiāo)售明細(xì)表列是「周次、區(qū)域、銷(xiāo)售額」需求是加一列周環(huán)比負(fù)數(shù)標(biāo)紅最后加一行合計(jì)。4.1 輸入準(zhǔn)備與權(quán)限收窄第一步不是寫(xiě)代碼是收窄權(quán)限。我給這個(gè) Agent 的工具集里刪除行、刪除列、清空區(qū)域這三個(gè)高危工具全部沒(méi)開(kāi)。原因很直白模型在規(guī)劃階段有可能把加一列理解成先刪一列騰位置這種理解在它的世界里是合理的但對(duì)用戶來(lái)說(shuō)是災(zāi)難。高危操作不開(kāi)放比事后校驗(yàn)便宜太多。同時(shí)我構(gòu)造讀取視圖只取有數(shù)據(jù)的區(qū)域把表頭行單獨(dú)拎出來(lái)做列名映射讓模型不用自己數(shù)第幾列是銷(xiāo)售額。4.2 工具定義與實(shí)際代碼工具聲明我用的是常規(guī)的函數(shù)調(diào)用格式參數(shù)盡量扁平。下面是簡(jiǎn)化后的核心部分// 工具聲明喂給模型的 schema節(jié)選 const tools [ { name: sheet_read_range, description: 讀取指定區(qū)域的值。坐標(biāo) 1-basedrow 為行號(hào)col 為列號(hào)從 1 開(kāi)始。, parameters: { type: object, properties: { sheetName: { type: string }, startRow: { type: number }, endRow: { type: number }, startCol: { type: number }, endCol: { type: number } }, required: [sheetName, startRow, endRow, startCol, endCol] } }, { name: sheet_write_formula_column, description: 向某一列批量寫(xiě)入公式。行范圍不含表頭。公式中用 {row} 占位當(dāng)前行號(hào)。, parameters: { type: object, properties: { sheetName: { type: string }, col: { type: number }, startRow: { type: number }, endRow: { type: number }, formulaTemplate: { type: string } }, required: [sheetName, col, startRow, endRow, formulaTemplate] } } ];派發(fā)層是這套東西的核心所有模型輸出最終都要在這里被翻譯成命令并且在這里做參數(shù)兜底async function dispatch(call: ToolCall, ctx: TaskContext) { // 1. 冪等同一個(gè) requestId 只執(zhí)行一次 if (ctx.seen.has(call.requestId)) return ctx.seen.get(call.requestId); // 2. 白名單校驗(yàn)sheet 必須存在 const wb univerAPI.getActiveWorkbook(); const sheet wb.getSheetByName(call.args.sheetName); if (!sheet) { return { ok: false, error: 工作表 ${call.args.sheetName} 不存在可選${listSheetNames(wb)} }; } // 3. 越界校驗(yàn)不信任模型給的坐標(biāo) const range normalizeRange(call.args, sheet.getMaxRows(), sheet.getMaxColumns()); if (!range) { return { ok: false, error: 坐標(biāo)越界請(qǐng)先調(diào)用 sheet_read_range 確認(rèn)區(qū)域 }; } // 4. 統(tǒng)一走命令通道帶上操作者標(biāo)識(shí) const result await executeViaCommand(call.name, { ...call.args, ...range }, { operator: agent, requestId: call.requestId }); ctx.seen.set(call.requestId, result); return result; }這段代碼里我最想強(qiáng)調(diào)的是第 2 步和第 3 步?？雌饋?lái)是兩層很無(wú)聊的防御性編程但它們攔掉的問(wèn)題占了我在線上觀察到的一半以上。模型編造一個(gè)不存在的 sheet 名或者給出一個(gè)超出實(shí)際行數(shù)的范圍這兩種情況極其常見(jiàn)。而錯(cuò)誤信息里帶上「可選xxx」這一點(diǎn)小設(shè)計(jì)讓模型的自愈成功率提升得很明顯——它看到合法選項(xiàng)后基本都能糾正過(guò)來(lái)看不到就只能瞎猜。4.3 執(zhí)行、校驗(yàn)、提交的完整循環(huán)整個(gè)循環(huán)的形狀是這樣的開(kāi)事務(wù)邊界打一次快照。把結(jié)構(gòu)視圖和用戶需求一起給模型讓它輸出第一批調(diào)用。逐個(gè)派發(fā)收集結(jié)果。跑斷言新列的數(shù)值類(lèi)型對(duì)不對(duì)、公式有沒(méi)有錯(cuò)誤值、合計(jì)行是否等于明細(xì)求和。斷言不過(guò)把錯(cuò)誤回灌回到第 2 步最多兩輪。斷言通過(guò)提交事務(wù)任何環(huán)節(jié)超時(shí)或異?？煺者€原。這里有個(gè)細(xì)節(jié)值得說(shuō)斷言里不能用模型給的期望值。比如模型說(shuō)合計(jì)應(yīng)該是 128400你不能拿這個(gè)數(shù)去斷言因?yàn)樗约壕褪遣碌?。斷言必須?lái)自文檔本身——合計(jì)行用公式寫(xiě)然后檢查公式的計(jì)算結(jié)果是否等于明細(xì)區(qū)域的聚合。讓文檔自己證明自己這是唯一靠得住的校驗(yàn)。4.4 實(shí)測(cè)的一些數(shù)字同一張約 1200 行的表跑二十次這個(gè)任務(wù)我記錄下來(lái)的大致情況指標(biāo)數(shù)值說(shuō)明單次任務(wù)平均耗時(shí)815 秒含一到兩次模型往返輸入 token單輪15002500投影后的結(jié)構(gòu)視圖一次通過(guò)率約 78%首輪斷言全過(guò)一次回灌后通過(guò)率約 94%剩余為歧義任務(wù)需要快照還原的比例約 3%基本都是坐標(biāo)理解錯(cuò)誤命令級(jí)重試次數(shù)平均 0.4 次主要是越界后被糾正這些數(shù)字不是基準(zhǔn)測(cè)試只是我自己記錄的經(jīng)驗(yàn)值環(huán)境和表結(jié)構(gòu)一變就會(huì)漂。但那個(gè)一次通過(guò)率不到八成、回灌一輪到九成以上的形狀在后來(lái)幾個(gè)不同場(chǎng)景里都很穩(wěn)定。它說(shuō)明一件事模型的第一次輸出不值得信任但它的第二次輸出質(zhì)量已經(jīng)夠用了。所以自愈循環(huán)不是可選項(xiàng)是必需品。5. 踩坑記錄Demo 里看不見(jiàn)、上線才炸的幾件事下面這些是真正讓我半夜爬起來(lái)看日志的問(wèn)題。它們有個(gè)共同點(diǎn)在小數(shù)據(jù)集上、單人場(chǎng)景下、手工點(diǎn)幾下就能驗(yàn)證的路徑里全都不會(huì)出現(xiàn)。5.1 合并單元格是坐標(biāo)系統(tǒng)的黑洞我以為坐標(biāo)問(wèn)題很好解決直到遇到帶合并單元格的表。合并之后被合并的那些格子在數(shù)據(jù)模型里其實(shí)是空的只有左上角的錨點(diǎn)單元格有值。AI 讀的時(shí)候看到一片空就會(huì)認(rèn)為這里沒(méi)數(shù)據(jù)寫(xiě)的時(shí)候往合并區(qū)域中間寫(xiě)值會(huì)被丟棄或者錯(cuò)位。更麻煩的是行列偏移。一張表里有三處合并表頭用戶視角的第 5 行和模型拿到的第 5 行可能不是同一行因?yàn)橹虚g有隱藏行。我最后的處理方式是投影時(shí)把合并區(qū)域顯式標(biāo)出來(lái)寫(xiě)成「A3:C3 合并值銷(xiāo)售額」這樣的注釋附在結(jié)構(gòu)信息里寫(xiě)入前檢查目標(biāo)區(qū)域是否與任何合并區(qū)域相交相交就拒絕并返回提示。這個(gè)檢查加進(jìn)去之后這類(lèi)問(wèn)題基本絕跡。5.2 循環(huán)引用不是報(bào)錯(cuò)是靜默死循環(huán)公式引擎遇到循環(huán)引用不同實(shí)現(xiàn)的行為不一樣。我遇到過(guò)一次特別難查的模型把環(huán)比公式寫(xiě)成了引用自己所在列形成了環(huán)。界面上沒(méi)報(bào)錯(cuò)只是那一列全顯示為空。模型讀到空值以為是數(shù)據(jù)缺失又寫(xiě)了一版公式還是環(huán)還是空。它在兩輪里反復(fù)橫跳最后給我一個(gè)該列數(shù)據(jù)源缺失無(wú)法計(jì)算的結(jié)論。事后我在斷言里加了一條任何寫(xiě)入的公式在提交前做一次依賴檢查檢測(cè)是否形成環(huán)。這個(gè)檢查必須由程序做因?yàn)槟Ｐ蛯?duì)自己寫(xiě)的公式有沒(méi)有問(wèn)題是沒(méi)有判斷力的——它覺(jué)得C2/C2-1完全合理。5.3 逐格寫(xiě)入會(huì)觸發(fā)渲染風(fēng)暴早期我是讓模型一次返回一個(gè)單元格的修改然后循環(huán)調(diào)用。一千二百行一千二百次命令每次命令都觸發(fā)一次重算和一次重繪。結(jié)果頁(yè)面卡了將近十秒用戶以為崩了。改成批量命令之后一次命令帶一個(gè)二維數(shù)組重算一次、重繪一次同樣的數(shù)據(jù)量壓到了一百多毫秒。這個(gè)教訓(xùn)很樸素AI 的調(diào)用頻率不等于人的操作頻率。人能一秒點(diǎn)兩下模型可以一秒返回五十個(gè)操作。所有按人的節(jié)奏設(shè)計(jì)的接口在 AI 面前都會(huì)變成性能陷阱。5.4 模型會(huì)很有禮貌地編造一個(gè) sheet 名這個(gè)坑我印象最深因?yàn)樗谋憩F(xiàn)形式特別合理。用戶說(shuō)在匯總表里加一行模型調(diào)用時(shí)傳的 sheetName 是「匯總表」而實(shí)際的表名叫「匯總」或者「Summary」。命令失敗模型看到錯(cuò)誤然后它做的事情是——換了個(gè)名字再試比如「匯總表1」。它不會(huì)先問(wèn)它會(huì)一路試下去。解法就是前面代碼里那個(gè)「可選xxx」的錯(cuò)誤信息。把合法選項(xiàng)直接喂回去它立刻就能選對(duì)。這條經(jīng)驗(yàn)可以推廣成一個(gè)通用原則給模型的報(bào)錯(cuò)信息要包含足夠讓它自我糾正的上下文而不是只描述錯(cuò)誤本身。5.5 重試機(jī)制把同一行數(shù)據(jù)插了三遍這個(gè)是最危險(xiǎn)的因?yàn)樗茐牡氖菙?shù)據(jù)正確性而不是顯示。我們的調(diào)用鏈路上有超時(shí)重試模型側(cè)也有 SDK 自帶的重試。兩邊疊加一次插入操作被執(zhí)行了三次。因?yàn)椴迦胄羞@個(gè)操作本身不冪等——插兩次就是兩行。后來(lái)所有寫(xiě)操作都強(qiáng)制帶 requestId在派發(fā)層做去重表同一個(gè) id 只認(rèn)第一次結(jié)果。另外把插入行這類(lèi)結(jié)構(gòu)性操作盡量改寫(xiě)成寫(xiě)入到已存在的空行這種冪等操作。能用冪等操作表達(dá)的意圖就別用非冪等操作。6. 這條路往哪走文檔運(yùn)行時(shí)接下來(lái)的三個(gè)變化把 AI 接進(jìn)文檔這件事我現(xiàn)在看到的還只是很淺的一層——本質(zhì)上是把人的點(diǎn)擊翻譯成了 API 調(diào)用。再往下走我認(rèn)為會(huì)有三個(gè)方向的變化而且這些變化會(huì)反過(guò)來(lái)影響文檔引擎本身的設(shè)計(jì)。6.1 從命令 API 到語(yǔ)義層現(xiàn)在的接口還是太機(jī)器了。模型要理解第 3 行第 4 列這種坐標(biāo)語(yǔ)義而這恰恰是它最容易出錯(cuò)的地方。下一步應(yīng)該是文檔自己提供語(yǔ)義層告訴調(diào)用方這張表有一個(gè)叫銷(xiāo)售額的列而不是第 4 列。列名、表頭、數(shù)據(jù)區(qū)域、匯總行這些概念應(yīng)該成為一等公民由文檔引擎維護(hù)而不是每次讓模型去猜。univer 這種把文檔模型完整暴露出來(lái)的引擎做這件事有天然優(yōu)勢(shì)——它內(nèi)部本來(lái)就知道什么是行、什么是列、什么是公式只是現(xiàn)在這些信息還需要調(diào)用方自己去拼。6.2 文檔變成可以跑的東西現(xiàn)在我們把文檔當(dāng)數(shù)據(jù)看讀寫(xiě)它的單元格。但文檔里其實(shí)已經(jīng)有一整套計(jì)算能力了——公式引擎就是一個(gè)圖靈完備的計(jì)算環(huán)境只是它的輸入輸出都困在格子里。我試過(guò)一個(gè)很小的實(shí)驗(yàn)把一段業(yè)務(wù)規(guī)則寫(xiě)成公式讓模型只負(fù)責(zé)填參數(shù)不負(fù)責(zé)計(jì)算。結(jié)果準(zhǔn)確率比讓模型直接算高出一大截因?yàn)橛?jì)算這件事本來(lái)就該交給確定性的引擎。這個(gè)方向往大了說(shuō)就是文檔從一個(gè)展示容器變成一個(gè)輕量執(zhí)行環(huán)境——規(guī)則、校驗(yàn)、聚合都在文檔里跑AI 只做它擅長(zhǎng)的部分理解意圖、填參數(shù)、處理異常。6.3 可審計(jì)會(huì)成為硬需求一旦 AI 能改文檔這次改動(dòng)是誰(shuí)做的、為什么做、中間試了幾次就變成了必須留痕的東西。我現(xiàn)在給每個(gè) AI 任務(wù)都記一條操作日志任務(wù) id、用戶原始表述、模型規(guī)劃出的步驟、每一步的命令參數(shù)、斷言結(jié)果、最終是否提交或回滾。這份日志的價(jià)值在多輪之后才顯現(xiàn)出來(lái)。用戶說(shuō)上周那個(gè)報(bào)表怎么少了一行你能順著日志一路查到是哪次 AI 任務(wù)、因?yàn)槭裁磾嘌詻](méi)過(guò)、回滾到了哪個(gè)快照。沒(méi)有這份東西AI 改過(guò)的文檔基本等于不可維護(hù)。最后分享一個(gè)我自己用了很久的小習(xí)慣每次給文檔加新的 AI 能力我會(huì)先手動(dòng)把那個(gè)操作做一遍然后問(wèn)自己我剛才這一下對(duì)應(yīng)的是哪條命令。如果我說(shuō)不出對(duì)應(yīng)的命令說(shuō)明這個(gè)能力還沒(méi)準(zhǔn)備好開(kāi)放給模型——因?yàn)槟Ｐ捅任腋菀自谀：貛г愿^。這個(gè)笨辦法幫我在上線前攔下了好幾個(gè)本來(lái)會(huì)很難看的問(wèn)題。