招投标群里隔三差五就有人甩一张 DeepSeek 的对话截图:「AI 看过了,没问题。」配图里模型回答得条理分明,连语气都很笃定。然后呢?然后有人开标当天才发现,某条藏在第一百多页的禁止性条款,AI 压根没提。
先把立场说清楚:这篇不是劝你别用 AI 审标——我们自己就是做 AI 审查的,劝你别用 AI 属于自己打自己。要拆的是一个具体动作:把整份标书扔进对话框,问一句「有没有问题」,然后把它的回答当成审查结论。这个动作里埋着几个坑,每个都有技术上的具体原因,不是「AI 不靠谱」一句话能概括的。
顺带对搜「标书审查deepseek」能看到的那批说法泼点冷水:「3 分钟审完」「99% 准确率」——这类数字通常不交代测试集是什么、错判怎么算。遇到这种宣传,先问一句「在哪些标书上测的」,问完基本就安静了。
大家说的「用 DeepSeek 审标书」,具体是怎么操作的
拆开看,「ai标书检查」这件事在现实里就两种玩法,而它们出问题的根源不一样——这一点市面上的文章基本不区分,只笼统地吹或者笼统地贬。
- 玩法一:在网页版或 App 里直接上传 PDF,问「帮我看看这份标书有没有问题」。这种用法受两个东西限制:单轮问答的形态(它只能就你问的角度答,你没问到的它不会主动逐条排查),以及上下文窗口对长文档的实际消化能力——下一节专门讲。
- 玩法二:自己接 API 写个脚本,把标书切片后批量提问。这比玩法一进了一步,但效果的上限不再由模型决定,而是由你自己写的切片和检索逻辑决定——切片把一条完整要求切成两半、检索没召回关键段落,模型再强也审不到。换句话说,玩法二的坑从「模型的坑」变成了「你自己工程能力的坑」。
公平起见也说清楚:这两种玩法不是不能用,是要用在对的地方。玩法一适合「点状提问」——让它解释一条看不懂的条款、检查一段承诺函的措辞、问某类项目通常要备哪些资质,这些单点任务它干得又快又好。玩法二适合有工程能力的团队做内部提效。它们不适合的,是「整份文件的地毯式排查」——这恰恰是大多数人扔 PDF 时心里期待它干的事。期待和能力错位,才是「AI 看过了」翻车的根源。
两种玩法有个共同的前提性问题:它们都默认「模型读完了整份文件」。这个默认,恰恰是最经不起推敲的。
上下文窗口:「塞得下」不等于「读得进去」
以 DeepSeek 为例,当前版本的上下文窗口是 128K token 这一档(以官方文档当前公示为准,版本迭代会变)。换算成中文,大约能塞下二三十万字——听起来一份标书绰绰有余,招标文件加投标文件一起塞都行。
先算一笔账,看看 128K 在真实项目里到底够不够。中文场景下一个 token 大致对应一个到一个半汉字;一页排满的标书正文按五六百字算,一份三百页的招标文件就是十七八万字——单这一份就已经贴着窗口上限了。再加上一份两三百页的投标文件?塞不下,只能截断或分批。也就是说「把招标文件和投标文件一起丢进去对照」这个想象中的用法,在很多真实项目上第一步就不成立,还没轮到「读得仔细不仔细」的问题。
但窗口大小和读得仔细是两件事。语言模型领域有一篇标题起得很形象的研究,《Lost in the Middle》(迷失在中间,发表于 TACL 2024):同一份材料、同一个问题,答案所在的段落放在输入的开头或结尾时,模型答得最好;放在中间位置,准确率明显下滑——下滑得足够显著,研究者直接拿这个现象当了论文标题。这不是某一家模型的毛病,是被反复复现过的普遍现象。
放到审标场景里,这个现象的含义很具体:招标文件加上投标文件动辄几百页,合并塞进窗口后,那条埋在第 150 页的技术偏离要求,正好落在「中间」——模型可能压根没「注意」到它,然后在你问「有没有问题」时,基于它注意到的部分,给你一个流畅而自信的「没有问题」。它不是撒谎,它是真的没看见,而你从回答的语气里分辨不出这两者。
有人会说:塞不下就分批读嘛。分批确实绕开了窗口上限,但引入了新问题:招标文件第 40 页的要求,对应的应答在投标文件第 210 页——两处不在同一批里,模型在读任何一批时都看不到完整的「要求-应答」对,核对就无从谈起。分批分得好不好,本质是文档结构拆得对不对,这又绕回了玩法二那个结论:上限在工程,不在模型。
这也是为什么正经的审查系统都不会把整份文件一次性塞给模型,而是先把招标文件拆成一条一条的结构化条目,每次只让模型对着一小段原文核对一条要求——招标文件解析这一步做得好不好,直接决定后面审查的上限。整份扔进去省掉的那点事,会在你看不见的地方加倍还回来。
AI 说「合格」,你追问一句「第几页第几条」,它答不上来
「AI 幻觉」这个词大家都听腻了,但科普文章讲的都是通用例子。放到审标这个具体场景里,幻觉有三种真实会发生的形态,一种比一种隐蔽:
- 引用一个不存在的条款。它说「根据招标文件第 3.2.5 条,贵方响应满足要求」——你翻遍招标文件,没有 3.2.5 条。结论可能碰巧是对的,但支撑结论的依据是现编的,这份「审查报告」的每一条你都得重新查一遍才敢用。
- 把几家投标方的内容串在一起。一次审多份投标文件时,模型可能把 A 家的业绩安到 B 家头上、把 C 家的报价当成 A 家的。单份审查时这个问题不明显,文件一多就冒出来——而恰恰是多文件场景(比如代理机构批量核、比如做独立性比对),最需要机器帮忙。多份文件的横向比对本身就是一件容易出错的事,这也是围串标识别要为它单独设计比对逻辑、而不是把几份文件拼起来一起问的原因。
- 判定给得斩钉截铁,出处一追就露馅。你问「这条为什么合格」,它要么重新组织一遍刚才的话,要么现编一个页码。编的页码翻过去是别的内容——这时候你才意识到,刚才那些流畅的「合格」,每一条都可能是这么来的。
如果一个审查结论说不清楚是从原文哪一页看出来的,这个结论本身就该打个问号——不管给结论的是人还是 AI。
第二种形态多说一句,因为它最容易被忽视:文件串台不会报错,不会有任何异常提示,输出照样通顺。你拿到的是一份「看起来审过了」的结果,里面 A 家和 B 家的信息已经悄悄换了位置。发现它的唯一办法是逐条回原文核对——而如果每条都要人工回原文核对,AI 帮你省的时间就全还回去了。多份文件的横向比对必须逐份处理、再按明确的维度比,这正是围串标识别单独成一个功能、而不是「多传几份文件一起问」的原因。
顺手给一个能立刻用的办法。拿到任何一份 AI 生成的审查结论(自己做的、别人发的、厂商演示的都算),用三个追问过一遍:
- 挑一条「合格」,问它原文在第几页——然后真的翻到那一页。页码对不上或者压根给不出,这份报告的可信度直接归零,后面不用看了。
- 问它一条你自己知道答案的问题。比如你清楚自己的质保期写的是三年,问它「投标文件承诺的质保期是多久」。答错了,说明它并没有真的读到那部分内容。
- 同一个问题换个措辞再问一遍。两次答案不一致,说明它在「生成回答」而不是「检索事实」——生成的东西每次都可能不一样,事实不会。
三个追问花不了十分钟,但能把「看起来审过了」和「真的审过了」区分开。这一套对人工审查报告同样适用,只是人类审核员通常在第一问就能给出页码——这恰恰是目前多数裸用 AI 给不出的。
「标书审查 skill」能不能救?——prompt 和机制是两回事
搜「标书审查skill」的人,多半是想找一段调好的提示词,让大模型审得更专业些。诚实的回答是:好的 prompt 有用,但它解决的是另一个问题。
prompt 能做到的,是让输出更规范——比如强制要求「每条结论必须附页码」,模型确实会每条都给你一个页码。但 prompt 管不了「页码是不是真的」:它约束的是回答的格式,不是回答的真实性。一个被要求「必须给出处」的模型,在找不到出处的时候,大概率不是承认找不到,而是编一个格式完全正确的出处。这就是 prompt 工程的天花板:它能让模型看起来更靠谱,靠谱本身要靠别的东西。
那「别的东西」是什么?是模型说了不算的校验机制。拿我们自己在妙笔审标里的做法举例:每条审查结论必须能定位到文档原文的具体页码,而且机器会把结论引用的原文和真实文档逐字核对一遍——对不上,这条结论就不算数,转成「人工复核」交给人判断。这一层校验不依赖模型自觉,它是架在模型输出后面的一道闸:prompt 是在请模型讲真话,校验机制是默认它可能讲错、然后逐条验。
这套机制的边界
逐字核对解决的是「结论查得到原文出处」这一件事,让它从「碰运气」变成默认动作。它不代表机器的判断就是终审——证据对得上,判断本身仍可能需要人来权衡,所以有些条目就是会标「人工复核」。把这个标记理解成系统的诚实,而不是系统的失败。
你可能会问:校验机制听起来是理所当然的事,为什么不是每家都做?因为贵。逐字核对意味着每条结论都要多跑一遍原文检索和比对,系统复杂度和运行成本都涨;而演示的时候,有没有这层校验肉眼看不出来——输出都一样漂亮。于是它成了典型的「用户看不见的成本」,砍掉它做出来的产品,演示效果一分不差,价格还能更低。分辨的办法上一节已经给了:挑一条结论追问页码,然后亲手翻到那一页。这一个动作,就是你替自己做的校验机制。
所以「审标书」到底该怎么分工
把前面四节收成一张表。只对照两个东西:把整份标书丢进对话框的裸用法,和先拆条目再逐条核对的结构化审查——至于人工代查、查重工具这些其他路径怎么选,标书检查软件那篇已经摆过全景,这里不重复。
| 维度 | 裸用大模型对话框 | 结构化审查系统 |
|---|---|---|
| 处理方式 | 整份文件一次塞进去,问什么答什么 | 先把招标文件拆成条目,逐条对着原文核对 |
| 证据可追溯 | 答不上页码,或可能现编一个 | 结论必须定位到原文页码,机器逐字核对,对不上就打回转人工复核 |
| 多文件比对 | 容易把几家投标方的内容串在一起 | 逐份处理后再做横向比对,比对维度是明确列出来的(报价雷同、关键人员重叠、模板照抄占比等) |
| 输出稳定性 | 同一份标书,换个问法结果可能不一样 | 走固定的审查项清单,复核路径可重复 |
表里「证据可追溯」那一行,顺带把一个常见误会讲清楚:错别字、格式这类检查,和「这条实质性要求响应了没有」的条款级审查,是两个深度的活——前者通用工具都能干,后者才是废标风险真正藏身的地方。形式审查和实质审查的边界,我们有一篇专门拆过。
可执行的行动建议就一条:不管用不用 AI、用哪家的,投标前给自己留一道自查环节——把招标文件里的强制性条款单独列出来,和自己的投标文件逐条对一遍。能自己查的先查,查不透的地方再找人工把关。工具的意义是把这道环节从「靠毅力」变成「靠流程」,而不是替你把这道环节省掉。
三个高频问题
标书审查智能体能不能替代人工审核?
不能,而且正经的厂商自己也不会这么宣称。这类系统的定位是投标人提交前的自查辅助——它把逐条比对这类机器擅长的活干完,把需要权衡判断的条目标出来交给人。最终判断永远要回到招标文件原文和现行法律法规。看到宣称「全自动、免人工」的,回想一下本文第三节那三种幻觉形态,然后问它:结论对不上原文的时候,系统怎么处理?
不用专门工具,直接问 DeepSeek 行不行?
当第一道粗筛,行:快速过一遍有没有明显漏项、让它解释看不懂的条款,这些都是好用法。但上面拆的三个问题——中间内容读不进去、引用会现编、多文件会串台——意味着它的「没问题」三个字不能直接当审查结论用,尤其是废标风险这种错一条就出局的地方。粗筛之后,强制性条款务必再走一遍逐条核对,无论用工具还是用人。
把标书传给 AI,内容会不会泄露?
这个问题该排在「审得准不准」前面。开标前的投标文件是企业机密——报价策略、技术方案、授权文件全在里面。用任何工具(包括通用大模型、包括我们)之前,先确认三件事写没写进对方公开的条款里:传输和存储怎么加密、文件保存多久、会不会被拿去训练模型。口头承诺不算,要看写下来的。我们自己的处理方式写在站内的隐私政策里,不在这里展开承诺——按同一个标准去审视就好。
收个尾。妙笔审标做的就是本文说的结构化那条路:把招标文件的要求拆成条目,逐条核对投标文件是否作出应答、标出废标风险;多份投标文件之间的横向比对交给围串标识别;所有结论定位到原文页码,方便你逐条复核。你可以在正式提交前用它自查一遍——它是辅助审查工具,不替代人工终审,也不是评标方使用的评审工具,最终以招标文件与现行法律法规为准。