先讲一个同事的遭遇他让 AI把文档里所有’按照’统一成’按’模型很勤快全文替换干净利落——顺带把一处不该动的法条引用也换了还把一句本来就通的表述改出了歧义。等他发现时文档已经发了出去回滚靠的是 WPS 的历史版本一身冷汗。这事其实怪不到某一个产品头上模型就是会犯错Agent 就是会勤快。真正值得追问的是——写操作应不应该默认直接落盘AI 幻觉治理喊了这么久落到文档场景答案就藏在确认机制的设计里。察元AI文档助手把写操作设计成两道闸门我管它叫双重保险。第一道预览闸document_replace、document_insert、document_apply_ops 这类直接改文档的操作只要调用时没带 confirmed:true就只返回一份 preview——改动前后的对照方案一个字都不写盘。AI 跟你说我改好了没有它只是给你看了个方案。你看了没问题再让它带确认执行第二次调用这时才真正动文档。批量场景同理一次两百条操作预览时每条改了什么、改在哪都摊开在你眼前。第二道确认闸另一批动作更严格document_add_comment写批注、proofread_apply_comments校对结果转批注、declassify_apply 和 declassify_restore脱密操作不确认就直接返回 CONFIRMATION_REQUIRED 错误码等于把你确定吗焊进了协议层。尤其是脱密这种敏感操作declassify_apply 除了 confirm 还要 password 和 keywords三重条件凑齐才执行。批注看起来无害为什么也要确认因为批注是写进文档交给别人看的东西同样代表你的立场。推荐的标准动作我的固定流程是三步配一句提示词就够先跑一遍校对dryRun汇总问题列表不要先改正文我确认后再写成批注第一步 AI 只读不写proofread_run 默认 dryRun仅返回问题列表第二步我人工过一遍列表删掉误报、勾出必须改的第三步让 AI 把确认过的问题写成批注这时才带 confirmed。整个流程里AI 的每次动笔都发生在我看过之后两次机会都在人手里。批量校对时再补一句问题按严重程度排序人过目的效率又能高一截。三个常见误区误区一以为预览之后 AI 会自己接着执行。不会不确认它就停在预览那一步这是机制不是礼貌。误区二确认之后就不看结果了。你确认的是方案执行完仍建议抽查尤其批量操作花一分钟核对锚点位置比事后翻历史版本便宜得多。误区三批注不算写操作、不用确认。恰恰相反批注钉进文档就是改变了别人看到的内容所以 document_add_comment 一样要 confirmed。什么时候适合直接确认也不是所有场景都要两步走。小范围、当场盯着的改动——改个标题、补一句话——直接确认效率更高反正结果就在眼前。大批量、跨章节、涉及数字和名称的改动坚持先预览后执行改动面越大预览的杠杆越高。拿不准的时候一律先预览这个习惯不会让你吃亏。为什么这比相信模型靠谱Agent 元年各种智能体都在抢着替你干活但模型可靠性的提升赶不上任务委派的增速。对文档场景我的看法是与其争论模型可不可靠不如把流程设计成模型不可靠也没事。preview 机制本质上是把 AI 的输出从动作降级成提案决策权留在人手里。哪怕模型再强一个版本这道闸也不亏——人眼扫一遍预览列表的成本永远低于事故回滚的成本。边界与提醒预览能挡住误改挡不住误判AI 认为该改的未必真该改列表里的建议仍要逐条过目尤其是涉及数字、名称、法条引用的改动。涉密处理、法务审核这类要签字担责的环节AI 只做提示不做决定脱密结果也以人工复核为准。让 AI 提方案、让人按按钮这个顺序别倒过来。