最近一段时间，我们一直在跟做投标的用户一起梳理 AI 招投标流程。行业不同，标书格式不同，内部的岗位分工也不同，但是聊到最后，大家头疼的事情其实差不多。

文件太长、时间太紧、材料分散在不同人手里。最怕忙了很多天，最后因为一个不起眼的漏项前功尽弃。

一位电力行业的投标负责人跟我们说，他们经手的招标文件动不动就是上百页。过去光梳理要求就需要几天，技术方案和报价还没开始，人已经被各种资质条件、评分点和承诺项绕晕了。

后来先让 Agent 把每一条需要响应的内容列出来，再进入写作和报价，过去容易遗漏的资质响应明显少了。这个案例在 DesireCore 官网也有记录。

这件事情听起来很自然，实际做起来并没有想象中简单。刚开始讨论 AI 标书写作时，大家最容易关注“能生成多少页”“多久生成”“能不能直接导出 Word”。这些功能演示起来很直观，客户也很容易看到效果。

但是做过几个真实流程以后就会发现，生成文字反而不是最难的部分。

AI 的文字通常很流畅，目录、大纲、技术名词也都像那么回事。问题就在这里：它越像一份已经完成的标书，人越容易忽略它有没有把招标文件真正答完。

下面记录几个我们在实践中遇到的坑，以及后来在 DesireCore 里的处理方式。

坑一：把“生成完成”当成“标书完成”

如果只看演示，上传一份招标文件，几分钟后得到几十页甚至上百页内容，效果确实很好。我并不否认大模型在长文写作方面的能力，但投标不是作文比赛，篇幅和完成度没有必然关系。

例如招标文件要求提供近三年同类项目业绩，AI 很容易写出一段“公司拥有丰富的同类项目经验”，语句没有问题，放在技术方案里也很顺。

但评标时真正有用的是具体项目、合同时间、金额、验收材料，以及这些证据是否符合“近三年”和“同类项目”的定义。缺少这些材料，写得再好也不能得分。

所以后来我们要求，Agent 在处理关键资格项和评分项时，不能只给结论，至少要同时给出以下内容：

• 招标文件原文及所在位置；
• 满足、不满足或待确认的判断；
• 判断所使用的企业材料；
• 证书、业绩、人员等材料的有效期；
• 还缺什么，以及由谁补充。

没有证据时，宁可标记“待确认”，也不要根据上下文补出一个合理答案。这条规则看起来保守，但是标书里的很多问题并不是不会写，而是写了一个无法兑现或无法证明的内容。

坑二：盯标只做关键词推送

很多企业已经有标讯订阅系统，按行业、地区、采购人和关键词推送公告。它解决了“去哪里找项目”的问题，但没有解决“这个项目是否值得投”。

我们早期讨论盯标 Agent 时，也很容易落到关键词匹配和综合评分上。例如系统给出“匹配度 87%”，看起来很清楚，实际负责人还是不知道为什么是 87%，更不知道剩下的 13% 会不会直接导致资格不通过。

后来我们不再把一个分数作为主要结果，而是让 Agent 生成一份参投分析。它会把预算、截止时间、资格要求、业绩要求、保证金、交付周期等信息提取出来，再与企业现有的资质、人员、案例和风险底线逐项比较。

符合的附上证据，不符合的说明缺口，存在歧义的条款单独列为答疑问题。

Agent 可以给出参投建议，但是否投标仍然由人决定。报价、重大承诺和最终提交也是一样。在 DesireCore 中，这类节点可以设置为 人闸门，任务执行到这里会停下来等待确认。

我不建议把这些决定完全交给 AI，至少以目前的模型能力和责任划分，还不合适。

坑三：让一个 Agent 从读标做到查标

最简单的方案，是创建一个“招投标专家”，把招标文件、公司资料和历史标书全部交给它，让它完成分析、写作、检查和排版。简单项目这样做没有问题，复杂项目很快就会遇到上下文过长和角色冲突。

读标需要尽量保守，不能漏掉限制条件；技术写作需要在要求范围内展开；商务和资质更看重证据；检查则需要怀疑前面所有人的结论。

这几种工作放在同一个 Agent 里，它一边写答案，一边给自己检查，通常很难发现自己最初就理解错的地方。

我们的处理方式是拆开角色，但不是机械地多创建几个 Agent：

• 统筹 Agent 维护整体进度、响应矩阵和任务依赖；
• 读标 Agent 只负责提取资格项、评分项、否决项和格式要求；
• 技术、商务、资质等 Agent 只处理自己需要的材料；
• 检查 Agent 不参与前面的写作，最后从招标方和评标专家视角重新检查。

DesireCore 里的一次真实招标写作流程：统筹 Agent 掌握全局，读标、大纲、技术方案和文件检查由不同 Agent 分工。

不同 Agent 有独立上下文，交接时传递的是任务、依据、约束和已完成结果，而不是把所有历史对话再复制一遍。无关信息少了，能够并行的任务也不用排队。更重要的是，“写”和“查”终于由不同角色完成。

DesireCore 的 跨智能体协作主要就是为这类任务设计的。

需要说明的是，并不是 Agent 越多越好。标书规模很小、要求也比较简单时，一个 Agent 反而更省事。只有任务涉及多个专业、存在明显并行空间，或者需要独立复核时，多智能体才有意义。

坑四：做了大纲，没有做响应矩阵

AI 很擅长生成大纲，而且生成的大纲通常比人工从空白开始写更完整。但大纲只能说明“准备写什么”，不能证明“招标文件要求的内容都有人处理”。

后来我们把响应矩阵作为标书写作的主要中间产物。格式不复杂，核心是把招标要求和投标内容对应起来：

招标要求	原文位置	响应章节	证明材料	负责人	状态
必备资质	页码/条款	资格文件	证书、有效期	资质 Agent	待确认
技术评分点	页码/条款	技术方案	架构、参数、案例	技术 Agent	编写中
商务承诺	页码/条款	商务响应	承诺函、报价依据	商务 Agent	未开始

我把这张表理解为一张“欠账表”。每一个空格，都是还没有回答的问题；每一个“待确认”，都需要在提交前有人处理。大纲可以调整，章节也可以重写，但响应矩阵不能丢。

有了响应矩阵，统筹 Agent 才知道哪些任务可以并行，哪些任务需要等材料到位以后再开始。比如技术方案可以先搭框架，涉及具体产品参数的章节则必须等待厂商材料；人员配置发生变化后，项目简历、实施计划和相关承诺也需要一起更新。

这些依赖关系会由 智能任务编排持续跟踪，而不是等合稿时才发现前后不一致。

坑五：把标书检查做成全文润色

“帮我检查一下这份标书”是一个过于宽泛的任务。Agent 收到以后，通常会检查错别字、病句、表达和格式，再给一些比较泛的风险提示。这样的结果不是完全没用，只是很容易避重就轻。

我们后来把标书检查拆成几项互相独立的工作：

1. 完整性检查：招标文件中的资格项、评分项、承诺项和附件要求，是否在投标文件中有明确落点；
2. 一致性检查：项目名称、金额、日期、工期、人员、证书编号、数量和参数，前后是否一致；
3. 废标风险检查：否决项、签字盖章、授权、保证金、密封及上传要求是否遗漏；
4. 技术和评分检查：方案是否真正回答需求，证明材料是否足以支持对应评分；
5. 文档检查：目录、页码、标题层级、图片清晰度、附件索引和最终导出文件是否正常。

这些检查可以由不同 Agent 并行执行，最后再合并和去重。问题需要按照严重程度分类，至少区分“会影响提交或资格”“必须由人确认”“有时间再优化”。

如果把几百条意见不分轻重地全部扔给标书人员，结果和没有检查差不多，反而会让人错过真正危险的问题。

对于 AI 产生的修改，我们也不建议直接覆盖原文。DesireCore 的 超级文书会用 Diff 展示修改内容，用户可以逐条接受、拒绝或继续编辑。标书的责任主体仍然是人，AI 修改了什么、为什么修改，应该看得见。

坑六：每个项目都从头教一遍

通用模型知道招投标的基本概念，但不知道一家公司的实际情况。哪些资质即将到期，哪些案例可以对外使用，技术负责人习惯如何组织方案，报价低到什么程度宁可不投，这些信息不会因为换了一个更大的模型就自动出现。

很多经验也没有正式写进制度。例如老标书经理做检查时习惯先看哪些页面，法务看到什么样的承诺会立即要求复核，团队过去因为哪一类问题吃过亏。这些经验分散在人的记忆、旧标书和项目复盘中，人员一变动就容易丢失。

可培养 Agent 对这个场景的意义，就是把纠正留下来。第一次检查资质时，负责人告诉 Agent：“满足后面必须跟证据和有效期”；技术方案被退回，原因是没有逐条回应评分点；某个项目复盘发现丢分来自案例材料不完整。

这些都应该变成下一次任务会自动执行的规则，而不是只修改当前这篇标书。

用户的一次纠正，可以被 Agent 记录成可检查的原则。这才是“下次不再重犯”，而不是这次对话里暂时记住了。

在 DesireCore 中，Agent 的规则、示例、技能、记忆和工作流会保存到 AgentFS。这些内容是可以查看、迁移和版本管理的文件。Agent 学到新规则时会产生 Diff，用户确认以后再生效；如果教错了，也可以回滚。

这也是我认为 DesireCore 和普通 AI 标书工具最大的区别。模型负责推理和生成，企业自己积累的经验仍然属于企业。用得越久，价值不应该只体现在“这次少写了几个小时”，还应该体现在下一次不需要重复犯同样的错误。

如果从零开始，建议先做标书检查

我不建议企业一上来就追求全自动投标。一方面很难建立信任，另一方面问题容易被藏进一份看起来很完整的成稿里。

相对稳妥的做法，是先找一个已经结束、结果也明确的历史项目，把招标文件、最终投标文件和复盘材料放在一起，让 Agent 完整检查一次。

然后由团队里最有经验的人逐条评价：哪些问题找对了，哪些属于误报，还有哪些危险问题没有发现。修改规则以后，再用同一份材料重查，直到它能够比较稳定地复现团队的检查标准，再拿第二个项目验证。

查标稳定以后，可以继续接入读标和参投分析；响应矩阵准确以后，再尝试分章节并行写作；最后把中标、失标和实际交付情况带回复盘。这个顺序没有“一键生成百页标书”那么适合演示，但更容易落地。

衡量效果时，也不要只看生成速度。资格漏项数量、强制响应覆盖率、关键字段不一致数量、人工复核时间、返工次数和历史经验复用率，都比生成了多少字更有意义。

最后

需要说明：AI 可以辅助分析和写作，但不能替企业承担投标责任。资质真实性、报价、法律承诺、签章和最终提交，必须由获得授权的人确认。

涉及客户资料、报价、人员证书等敏感数据时，也需要根据企业的数据制度选择模型和部署方式。

我最后想说的是，我们想做的不是一台输入招标文件就自动吐出 Word 的标书生成器，而是让懂投标的人能够把工作方法教给一组 Agent：谁负责读标，谁负责写，谁负责找证据，谁负责挑错。

做完以后有回执，做错以后能够纠正，下次遇到类似项目不用重新开始。

一支可靠的数字投标团队，和真实团队一样，需要在一个个项目里训练和磨合。等新的招标文件进来时，它能够先把要求、缺口和风险摆在桌面上，再开始写作。我认为这比单纯追求“几分钟生成一份标书”重要得多。

---

相关阅读

• DesireCore AI 招投标解决方案
• 招投标助手：从招标文件解读到完整性检查
• 多智能体如何拆解、并行和交叉审核
• 像审代码一样审文档：DesireCore 超级文书