你們有沒(méi)有過(guò)這種經(jīng)歷。

晚上把一份文檔說(shuō)明丟給AI，留一句，幫我整理一下，順便改得更清楚。第二天打開(kāi)，你大概率會(huì)覺(jué)得，挺好，字更順了，結(jié)構(gòu)更清楚了，排版也像樣了。

可容易出問(wèn)題的，往往就是這種時(shí)候。危險(xiǎn)的不是把內(nèi)容寫得很爛，而是寫得賊像對(duì)的。

比如合同本來(lái)寫的是，付款時(shí)間為驗(yàn)收后30天。AI卻寫成付款時(shí)間為交付后30天。

乍一看差不多，可實(shí)際天差地別。

微軟研究院上個(gè)月的一篇論文，專門研究了這件事。標(biāo)題叫《LLMs Corrupt Your Documents When You Delegate》，翻得更通俗一點(diǎn)，就是，當(dāng)你把持續(xù)修改文檔這件事交給大模型，它很可能會(huì)在一輪一輪操作里，把文檔慢慢改壞。

這里最關(guān)鍵的詞，不是文檔，也不是模型。

是“Delegate”，委托。

什么叫委托。不是問(wèn)AI一個(gè)問(wèn)題，拿到一個(gè)答案。而是你把一份已經(jīng)存在的材料交給它，讓它接著改，接著補(bǔ)，接著整理，接著沿著前面的思路往下做。

這其實(shí)特別像真實(shí)工作。老板給你一份方案，讓你改三輪。客戶把合同打回來(lái)，讓你再修兩版。同事發(fā)來(lái)一份表格，讓你統(tǒng)一格式，再補(bǔ)幾列說(shuō)明。

作者做了一個(gè)新測(cè)試，叫DELEGATE-52。可以把它理解成一場(chǎng)大規(guī)模壓力測(cè)試，看AI在長(zhǎng)期改文件這件事上，到底穩(wěn)不穩(wěn)。

它測(cè)了從Python代碼，到數(shù)據(jù)庫(kù)文件，再到樂(lè)譜、會(huì)計(jì)臺(tái)賬、字幕、菜單、家譜等52個(gè)領(lǐng)域的不同文檔。

怎么測(cè)的呢。先讓模型做一次正向修改。比如，把一個(gè)表按類別拆開(kāi)。再讓它做一次反向修改。比如，把拆開(kāi)的內(nèi)容重新合并回原來(lái)的樣子。

如果模型真的靠譜，那改完再改回來(lái)，文檔應(yīng)該和最初差不多。如果改不回來(lái)，就說(shuō)明它在這個(gè)過(guò)程中把內(nèi)容弄丟了，或者弄變了。

這種來(lái)回修改一直做很多輪，模擬真實(shí)工作里那種，你改一版，我再補(bǔ)一版，他又重排一版，最后又回頭改前面的情況。

結(jié)果挺意外，全軍覆沒(méi)。

一共測(cè)了19個(gè)模型，到了20次交互，全部模型平均退化大約一半。就連Gemini 3.1 Pro、Claude 4.6 Opus、GPT 5.4這些頂尖模型，平均也會(huì)損壞大約四分之一內(nèi)容。

這里的四分之一，不是說(shuō)頁(yè)面少了四分之一。而是內(nèi)容保真度少了四分之一。換成更好理解的話，就是你交給它的原始意思、原始結(jié)構(gòu)、原始細(xì)節(jié)，到了很多輪之后，已經(jīng)有相當(dāng)一部分被它改得不再是原來(lái)那樣了。

最容易讓人誤判的一點(diǎn)是，短測(cè)試看起來(lái)往往沒(méi)事。

前兩次交互時(shí)，這些頂尖模型的表現(xiàn)大多還在94%到97%左右，看起來(lái)完全能用。可一旦拉到20次交互，Gemini 3.1 Pro掉到80.9%，Claude 4.6 Opus掉到73.1%，GPT 5.4掉到71.5%。

很像剛?cè)肼毜膶?shí)習(xí)生，第一件小事他做得挺漂亮，于是你開(kāi)始放心，把更多事情交給他。結(jié)果到了第十件、第十五件，你才發(fā)現(xiàn)前面的幾個(gè)小錯(cuò)已經(jīng)連成一片了。

AI現(xiàn)在在很多文檔任務(wù)上，就是這種狀態(tài)。

更麻煩的是，它不是每一輪都小錯(cuò)一點(diǎn)點(diǎn)。

論文發(fā)現(xiàn)，很多損失都來(lái)自少數(shù)幾次重大的突然失誤。平時(shí)看著還行，改著改著，某一輪忽然把關(guān)鍵字段改錯(cuò)了，把某條邏輯鏈斷掉了，把某個(gè)重要限定條件抹掉了，一次就能掉很多分。

它不是那種一眼就能看出來(lái)的低級(jí)錯(cuò)誤。不是亂碼，不是整段消失，不是排版塌掉。而是你讀著很順，覺(jué)得沒(méi)問(wèn)題，可里面有幾顆螺絲已經(jīng)被擰歪了。

而且模型越強(qiáng)，有時(shí)反而越難看出來(lái)。弱一點(diǎn)的模型，常見(jiàn)問(wèn)題是直接刪東西，漏段落，丟字段。你一看就知道不對(duì)。

強(qiáng)一點(diǎn)的模型，更像一個(gè)會(huì)說(shuō)漂亮話的人。它保留外觀，保留結(jié)構(gòu)，甚至保留一種很專業(yè)的語(yǔ)氣，然后把意思悄悄換掉。

比如把“建議”寫成“決定”，把“可能”寫成“將會(huì)”。句子更完整了，語(yǔ)氣更穩(wěn)了，問(wèn)題也更隱蔽了。

論文里還有幾個(gè)細(xì)節(jié)，也值得聊聊。

第一，代碼任務(wù)確實(shí)是個(gè)例外。

52個(gè)領(lǐng)域里，編程是唯一一個(gè)大多數(shù)模型都達(dá)到了ready門檻的領(lǐng)域。因?yàn)榇a相對(duì)更規(guī)整，很多錯(cuò)誤還能靠測(cè)試、運(yùn)行結(jié)果、語(yǔ)法檢查抓出來(lái)。文檔、紀(jì)要、合同、說(shuō)明書就不是這樣。它們很多錯(cuò)誤不影響閱讀，但會(huì)影響意思。

第二，給AI加工具，不等于自動(dòng)變穩(wěn)。

很多小伙伴現(xiàn)在用OpenClaw、Claude Code這種Agent之前，喜歡安裝一大堆Skill或插件工具，覺(jué)得這樣會(huì)大大提升AI能力。

論文專門測(cè)了這件事。結(jié)果是，在一套基礎(chǔ)工具框架下，模型平均還更差了一些。

為啥呢？你可以把它理解成，一個(gè)本來(lái)就容易分心的人，現(xiàn)在手邊工具更多了，步驟更多了，來(lái)回切換更多了，未必就更穩(wěn)。更何況，模型很多時(shí)候并沒(méi)有像人類那樣只改一句、只替一列、只動(dòng)一個(gè)字段，而是還是在大塊大塊地重寫。

這很像你本來(lái)只是讓同事幫你改一行字。結(jié)果他打開(kāi)Excel、復(fù)制一份、重新排序、再粘回去，流程變復(fù)雜了，出錯(cuò)點(diǎn)也更多了。

第三，文檔越長(zhǎng)，情況越糟。

這也好理解。一頁(yè)紙的請(qǐng)假說(shuō)明，和一份40頁(yè)的合作協(xié)議，根本不是一個(gè)難度。

論文里測(cè)到，文檔越長(zhǎng)，模型后面改壞的概率越高。現(xiàn)實(shí)工作偏偏最常見(jiàn)的，就是長(zhǎng)文檔、長(zhǎng)表格、長(zhǎng)上下文。

第四，旁邊的無(wú)關(guān)材料也會(huì)添亂。

比如你把主文檔交給AI時(shí)，還順手把幾份參考材料、舊版本、會(huì)議記錄、相關(guān)制度文件一股腦都塞進(jìn)去。人有時(shí)候都要花半天分清哪些該看，哪些不用看，模型當(dāng)然也會(huì)被帶偏。

這和我們平時(shí)辦公太像了。桌面上同時(shí)開(kāi)著三個(gè)版本的合同。郵箱里躺著兩份舊紀(jì)要。群里還有一張截圖。

你讓AI從這堆東西里繼續(xù)改，很難保證它不會(huì)把不該混進(jìn)去的內(nèi)容混進(jìn)去。

第五，時(shí)間越長(zhǎng)，不會(huì)自動(dòng)變好。

論文把交互一直拉到100次，性能還是繼續(xù)往下掉，沒(méi)有出現(xiàn)明顯穩(wěn)定。意思很簡(jiǎn)單，現(xiàn)在的模型不是改著改著就學(xué)會(huì)穩(wěn)住了，而是改著改著，還是會(huì)繼續(xù)出新錯(cuò)。

當(dāng)然，這篇論文也不是在說(shuō)，AI一點(diǎn)都不能用。這點(diǎn)必須說(shuō)清楚。

作者自己的表述其實(shí)很克制。他們測(cè)的是一個(gè)基礎(chǔ)版的Agent框架，不是全世界最先進(jìn)、最精細(xì)的工程系統(tǒng)。所以不能把結(jié)論粗暴理解成，只要用了AI Agent就一定不行。

但這篇論文至少證明了一件事。

今天的AI，很適合幫你起草，很適合幫你提速，很適合幫你先走第一步。可它還遠(yuǎn)遠(yuǎn)沒(méi)有穩(wěn)到，你可以放心把一整條文檔工作鏈路交給它，然后自己徹底不看。

這也是為什么，很多人用AI寫東西覺(jué)得挺爽，用AI改東西卻越來(lái)越心虛。

寫，是從空白到內(nèi)容。改，是從原意到原意。后者難得多。

那咱到底該怎么用，才更安全一點(diǎn)。我覺(jué)得至少有五條，很實(shí)用。

第一，不要整包托管。

不要一句“你幫我全改完”就交出去。最好拆成小段，小節(jié)，小模塊。比如先只讓它改摘要，再只讓它整理表格標(biāo)題，再只讓它潤(rùn)色一段說(shuō)明。每次改動(dòng)范圍越小，翻車越容易被發(fā)現(xiàn)。

第二，重要材料盡量看改動(dòng)，不只看成稿。

如果工具支持diff，就看diff。因?yàn)檎獜念^讀一遍，人很容易被“讀起來(lái)挺順”騙過(guò)去?？梢坏┠阒豢锤牧四膸拙洌芏鄦?wèn)題馬上就冒出來(lái)了。

第三，把最敏感的東西單獨(dú)檢查。

金額、日期、時(shí)間、付款條件、地名、人名、版本號(hào)、試點(diǎn)范圍、是否生效、是否包含例外條款，這些地方最容易出大事，也最值得人工逐項(xiàng)過(guò)一遍。

第四，越是長(zhǎng)文檔，越別偷懶。

十頁(yè)以上的方案，幾十行以上的表，帶多個(gè)附件的合同，帶歷史版本的制度文件，這些都不要輕信“它應(yīng)該沒(méi)問(wèn)題”。文檔越長(zhǎng)，越該設(shè)檢查點(diǎn)。

第五，結(jié)構(gòu)化任務(wù)更適合交給AI，不好驗(yàn)證的任務(wù)更要謹(jǐn)慎。

如果一項(xiàng)工作有明確對(duì)錯(cuò)，有現(xiàn)成校驗(yàn)方式，有規(guī)則能卡住，比如代碼測(cè)試、固定格式轉(zhuǎn)換、嚴(yán)格字段檢查，那AI通常更值得信任。反過(guò)來(lái)，凡是那種讀起來(lái)很通順，但對(duì)錯(cuò)要靠人理解上下文才能判斷的內(nèi)容，風(fēng)險(xiǎn)都更高。

所以，下一次，當(dāng)你準(zhǔn)備把一份合同、一份方案丟給AI，然后安心去喝咖啡時(shí)，不妨多問(wèn)自己一句：這版看起來(lái)沒(méi)問(wèn)題的東西，是不是真的沒(méi)問(wèn)題？

畢竟，AI再?gòu)?qiáng)，它也不會(huì)替你背鍋。

如果你有任何看法，歡迎在評(píng)論區(qū)一起討論

如果有一點(diǎn)收獲，可以點(diǎn)贊、轉(zhuǎn)發(fā)、推薦文章，關(guān)注「AI機(jī)器人茶館」