AI投标写作模型如何学会拒绝虚构

本月，Lucius团队通过其AI系统完整处理了一次活体招标：为格洛斯特郡某教区委员会设计并建造一块3G足球场，合同价值九十五万英镑，包含六份公开文件共一百三十三页。AI在大约五分钟内生成了初稿。这份初稿的开头异常醒目——一段提示语：请先阅读此内容：本稿中有十一个要求由尚未指明的交付合作伙伴回应。最低营业额以两年账目为凭，专业赔偿保险五百万英镑，地毯整体更换不得擅自修补，以及其他要求。

这段横幅正是作者最引以为傲的功能，它是一种拒绝。模型阅读了整套标书，理解买方要求后，比对了投标方实际可提供的证明，并拒绝为存在的差距编写虚构内容。这项功能看起来简单，但让大语言模型稳定做到这一点，消耗了团队约一年的失败试验。作者运营Lucius——一个读取公开招标文件并生成合规矩阵与初稿的AI系统。这篇文章不是推销，而是记录文档型AI如何以特定方式撒谎，以及他们每次如何修正。

为什么捏造是默认行为而不是边缘情况？投标回复不是营销文案。当供应商在标书中写“我们持有五百万英镑专业赔偿保险”时，这是买方会核实并可依据其采取行动的表态。错误不会仅降低评分，还可能导致标书被搁置，最坏的情况下排除在未来工作之外。语言模型独自运作时，优化目标是生成最合理的续写。在投标文件中，“我们的认证包括”的最合理续写是一长串认证列表，无论投标方是否真的持有这些认证。在训练数据中，合理性与真实性几乎处处同向。而在投标场景，二者恰好在最关键处背离——即评估者核查的各项声明上。

因此工程问题不是让模型写得更好——当前模型默认已写得不错，而是让系统逐行知晓自己有权声明什么。作者列举了第一次失败复盘：七月末他们审计了一份用于测试的NHS招标完整草稿。草稿读起来自信满满，同时将四十二个要求行委托给了某个联合体合作伙伴，并在行文中将这一安排作为既成事实。实际上根本不存在这样的合作伙伴。模型虚构了一家承受荷载的公司，名为[PARTNER_NAME]，直到文档底部才披露，而此前行文早已将该安排呈现为事实。更糟糕的是，他们自己的合规验证器将其中四十二行大部分评为已覆盖，因为验证器匹配关键词，虚构合作伙伴的段落正包含所需关键词。两个各自看似合理的组件组合在一起，构成了一套先编造再认证的系统。

修复方案是结构性的，而非纯提示工程。草拟流程现在会在任何章节撰写前，针对投标方真实档案做一次能力匹配检查。对于投标方无法证明的要求，系统不会编造内容，而是将其标记出来。作者强调，这一变化彻底改变了文档生成逻辑。模型被赋予的权限不再是“填满页面”，而是“仅陈述可证实的事实”。这种转变需要重新设计数据流、验证机制和输出格式。

经过十个月的反复迭代，团队最终磨出了可靠行为。如今Lucius在生成草稿的同时，会生成一份清晰的能力差距清单。投标方可以在提交前看到自己缺什么保险、缺哪年账目、哪些部分必须由尚未签约的分包商承担。这种透明度让AI不再是自动编造故事的工具，而是辅助人类做出真实决策的助手。对于依赖文档真实性的行业而言，这种“拒绝权利”的工程做法值得借鉴。