实战：如何让AI竞标写作工具拒绝虚假承诺

本周我们通过自己的流程跑了一个真实的招标项目：为一支格洛斯特郡的教区议会设计并建造一个 3G 足球场，预算 95 万英镑，6 份已发布文件，共 133 页。AI 大约五分钟就生成了初稿。草稿开头是这样的：

请先阅读：这份草稿中有 11 项需求尚未找到您指定的合作方来响应。最低营业额需提供两年账目证明，专业责任险 500 万英镑，未经授权不得补丁式更换的全卷地毯铺设，以及其他。

这条横幅是我最引以为豪的功能，它是一种拒绝。模型阅读了全套资料，理解了买方的需求，将其与投标方实际能够证明的材料进行了核对，然后拒绝为这个差距编造内容。

让 LLM 可靠地做到这一点，我们大约花了一年的失败时间。这篇文章就是这些经验教训。我是 Lucius 的创始人，这是一款能阅读公开招标包并生成合规矩阵和初稿的 AI，但以下内容不是推销。任何 below 都不是广告。它是文档 AI 欺骗你的具体方式——这些是硬生生踩过的坑，以及我们每次做了什么改动。

为什么编造是默认行为，而非边缘情况

招标响应不是营销文案。当供应商在标书中写"我们持有 500 万专业责任险"时，这是买方会核实且可以追诉的一项陈述。写错了不会扣分，而是会让投标被作废，最坏的情况是被排除在未来业务之外。

语言模型在无人看管时，会为最合理的续写做优化。在标书上，"我们的资质包括"最合理的续写就是一个资质清单，无论投标方是否真的持有这些资质。在训练数据中，合理性与真实性几乎在所有地方都指向同一方向。在投标领域，它们分道扬镳的地方恰恰是评估人会检查的那些claims——而这正是钱所在之处。

所以有趣的工程问题不是让模型写得好。当前的模型默认就写得很好。问题是让系统逐行知道它有权声明什么。

经验复盘 1：幽灵合作方

去年 7 月底，我们审计了一份用于测试 fixture 的 NHS 招标完整草稿。草稿读起来信心满满。它还将 42 行需求 defer 给了一个 consortium 合作方，巧妙地编织在正文中，仿佛合作安排确实存在。没有合作方。模型凭空创造了一家承重公司，命名为 [PARTNER_NAME]，在文档底部的 deferred 部分才披露，而那时正文已经将这个安排作为事实呈现了。

更糟的是，我们自己的合规验证器将这 42 行中的大部分标记为已覆盖。它匹配了关键词，而幽灵合作方的段落包含了正确的关键词。两个组件各自在隔离状态下大致合理，组合起来却成了一个编造小说然后又为之背书的系统。

修复方案是结构性的，不是调 prompt 能解决的。现在起草阶段在任何 section 撰写之前，都会先对投标方的实际画像做一次能力匹配检查。投标方无法证明的需求会被路由到一个明确的、可见的合作方 slot，并在草稿顶部的横幅中暴露数量，而不是底部的脚注。验证器被重建，停止将合作方框架的段落计为投标方自身的证据。当系统自己的投标建议说这个标不值得投时，它会拒绝起草——因为为注定失败的标书写一份漂亮的草稿本身就是另一种谎言。

经验复盘 2：静默的覆盖率崩塌

LLM 流程中最可怕的不是崩溃。是那些报告为完成、实际是部分成功的状态。

我们的提取阶段曾在同一份 99 页 NHS 包的两次运行中（七天间隔），从 366 条提取出的需求跌到 184 条，每次运行都报告"完成"。原因是分块提取路径在第 33 页之后崩溃了：一块返回了空结果，代码悄悄地将空集合 union 到总数中。没有任何报错。流程还在自我感觉良好。包含评估人门槛标准的附件直接缺席于分析报告。

如果你的系统丢失了 50% 的需求却告诉用户"分析完成"，下游的所有诚实机制都是装饰。修复方案平淡无奇但至关重要：不允许 chunk 级别的结果被静默置空，覆盖率要按页面跨度来衡量而非假设计算，遗漏项 pass 要专门 hunts 第一次 pass 跳过的内容。平淡是关键。诚实的 AI 大部分都是管道工程。

经验复盘 3：坏掉的测谎仪

我们验证引用：每条提取的需求都带有页码引用和逐字引用，checker 确认引用确实存在于源文中。某一时点这个 checker 将 158 条引用中的 90 条标记为未验证。令人警觉，所以我们手动抽查了样本：27 条全都没问题，引用和页码都正确。仪器坏了，不是流程的问题。它在 PDF 文本层和模型引用之间的空白符和连字符差异上失败了。

这一条改变了我对整个类别的思考方式。如果你的真伪测量仪器是错的，你就不知道其他东西是否正常工作，而且两个方向的失败都是有害的：误报教会团队忽略仪表盘，漏报教会客户信任小说。我们现在将验证器当作一个有自己 eval set 的可测量组件，与提取和起草阶段同等待遇。先有尺子，再有测量。

系统现在的做法

这些经验复盘的成果，整理成一份清单。这些都不稀奇。每一项都是因为某个具体失败才加上去的。

每条需求提取时都附带页码引用和逐字引用，引用会机器验证against源文。

提取覆盖率按文档跨度来衡量，而不是假设计算，专用的第二轮 pass 专门查找遗漏项。"完成"是流程必须挣来的声明。

起草在投标裁决结果上做门控。如果分析说不要投，系统会说出来，而不是写。

起草前会运行能力匹配检查。投标方无法证明的需求会被路由到可见的合作方 slot，并在草稿顶部的横幅中计数。

系统不知道的名字会保持为括号占位符。它不会凭空编造项目经理。

因为这样的文章没有 artifact 支撑就很廉价：开头那个 run 已经全文发布，未经编辑。分析在 133 页包中发现了 45 条强制性需求，其中 13 条为高严重性，这 13 条中有 9 条是法律条款，位于合同条件而非规格说明中。草稿直接响应了 45 条中的 40 条，其余 11 条大声标出。完整案例研究在我们的研究页面，实际 PDF 可下载，带着 honesty banner 和一切，用一个明确标注的虚构演示投标方——因为编造一个真实的反而会偏离本文的核心观点。

我认为文档 AI 厂商的激励结构是反的。能赢得交易的 demo 是那个自信满满的，所以市场在为自信做优化，而编造的成本落在后面，落在客户身上，落在采购语境中——在那里，编造是会被取消资格的。厂商会称他们的覆盖率数字为"无幻觉"。不如问：告诉我你的系统在哪里说它不知道。如果它从不这样做，那它就在某处对你撒谎，而你们双方都不知道是哪里。

在这个类别中，拒绝就是产品。

我是 Davor， Lucius 的创始人。如果你做过有据可查的文档 AI 且不同意其中任何观点，我真心想要这场争论：contact@ailucius.com。

获取投标帮助

在你附近找一位投标撰写人。