这几年信创国产化替代推进下来我们面对的投标环境里 WPS 已经是绝对主流Office 反而成了稀客。工具链也得跟着换以前靠 Office 宏做应答对照表现在整套流程迁到 WPS 加察元AI文档助手开源加载项Apache-2.0上反而更顺了。这篇写给投标专员和标书统稿人评分办法逐条对照这件事怎么做才能不漏、不虚、不糊。先说这件事的本质别把会拿的分丢了。评标办法三十来条应答内容散在技术标八个章节里漏应答一条就是白丢分比漏应答更隐蔽的是应答了但口径对不上——评分项要求提供近三年类似项目合同复印件应答章节里写的是公司具有丰富的同类项目实施经验算应答了吗解释权在评委但你自己得先知道这里有洞。第一步把评分办法变成对照表评分办法那几页粘贴进 WPS用内置的「生成摘要」和「提取行动项」助手把评分条款抽成干净清单条款号、评分内容、分值、证明材料要求。然后在文档里建对照表左列评分条款右列几栏——应答位置、应答摘要、证明材料、状态。表格不用自己一格格抠。察元的表格能力有 12 个 action口语化下指令就行在合计行上面插入一行列结构和上一行一致AI 会先读表头和列结构找到锚点行列再执行插入表头需要跨列合并时用 cell_merge同行选区就是合并列。三十几行的对照表几分钟成型这一步的效率差距最直观。第二步两份文档交叉核对对照表建好接下来把应答稿逐条对进去。我的做法是用 Claude Code 连察元起在本机的 MCP 服务服务地址 http://127.0.0.1:62588/mcp只监听本机回环地址标书不出域两份文档用 document_open 同时打开然后交给 Agent打开评分办法和应答稿两份文档按评分条款逐条对照每条找出应答位置并摘要应答内容应答缺失或口径对不上的把批注标在应答稿对应位置并注明对应的是第几条评分项长文档不担心document_chunks 分块读document_locate 定位关键词。评分项里的硬词——年份、金额、数量、证书名称——逐个到应答稿里找呼应找不到呼应的批注里写得明明白白。所有结论以批注形式钉在应答稿上正文一字不动。几个操作细节值得说。两份文档用 document_open 打开后让 Agent 先读评分办法那一侧先有清单再做核对顺序反了容易漏。核对结论全部钉在应答稿侧而不是评分办法侧原因很实际应答稿是要改的文件批注钉在改动现场处理完销号评分办法是参照物往参照物上钉批注只会把它弄脏。定位不到应答内容的条款Agent 会在批注里写明未找到应答——这种先别急着信人工再搜一遍同义词评分项写驻场服务应答稿里可能写现场服务机器报缺失人要会翻译。偶尔文档改动后锚点失配工具返回 LOCATE_MISMATCH重新跑一遍核对就行不用怀疑人生。第三步人工判分值批注出来后剩下的判断是人的活哪些口径不符其实是应答充分、只是措辞不同哪些是真窟窿要连夜补补进去的证明材料有没有、来不来得及盖章。AI 标记的是缺失和不一致两种状态怎么处理是投标负责人的决策——这一步偷懒前面全白干。状态列我们用三态管理已应答、口径不符、缺失。定稿前唯一允许留的状态是已应答另两态要么补齐要么走偏差说明不允许留着过夜。评分办法里带星号、写着不满足即无效投标的条款单独标红逐条双人复核——这类条款的应答质量是生死线不是得分项。对照表随标书归档是我们的固定动作评标办法逐条对照表留底下个同类项目直接复用框架只换条款内容。它还有个后手价值评标结果出来后对照得分表回看哪些应答真正有效、哪些只是自我感动一眼见分晓下个项目的应答策略就从这张表里长出来。工具的意义不在这一次查得全在于把逐条对照从靠责任心的事变成靠流程的事。最后把位置摆正评分解释权永远在评标委员会手里对照表是自查工具不是打分器。它能保证的是每一条都被看过不能保证每一条都被评委认可——后一半靠的是应答质量本身。形式分靠工具兜底内容分还得靠人磨。