收到一份 RFP，别先让 AI 写提案：先做一张可追溯的需求矩阵

一份客户 RFP（Request for Proposal，方案请求文件）发进邮箱后，最容易发生的事情不是没人会写，而是所有人都同时打开了旧提案、产品资料和报价表。几天后，团队交出了一份看起来完整的文件，却说不清哪些要求已经回答、哪些只是沿用了旧版本、哪些承诺根本没有证据。

我现在更愿意把 RFP 自动化的第一交付物定成一张可追溯的需求矩阵，而不是让 AI 直接写一篇提案。矩阵先把客户每个问题编号、拆出来，连到批准过的能力资料和当前状态；答案草稿只是后一步。

这篇文章给出一条小团队可以估算工作量的路径：从 PDF/Word 进入、文档解析、逐项建表，到缺口、人审、版本和验收。它不替方案负责人承诺能力，也不把“不知道”藏在流畅文字后面。

传统流程通常是：销售把 RFP 转发给方案、产品、交付和法务；每个人在自己的文件夹里找旧答案；方案人员再把内容拼成一份新文档。问题不在于谁不努力，而在于 RFP 的问题编号、回答依据、材料版本和责任人没有被放在同一张表里。

这种流程会制造三种风险。一个问题可能被漏答；旧提案里的功能或案例可能已经失效；一段语气很确定的话，可能没有任何批准材料支撑。把文本写得更顺，并不会修复这三件事。

所以母命题很简单：RFP 自动化应该先把“客户问了什么、我们凭什么这样答、还有什么不知道”变成可检查的记录，再生成提案段落。读者最终要拿到的不是一篇漂亮示例，而是一套可以复用的矩阵字段和审批路径。

• question_id：客户原始问题编号或人工补的稳定编号；
• requirement：问题原文和必要的上下文；
• answer_status：supported / partial / unknown / excluded；
• evidence_refs：批准能力矩阵、产品资料或案例的文件名、版本、页码；
• owner、reviewer、due_at：负责补充、审核和截止时间；
• draft_answer：只允许基于证据生成的回答草稿。

文档解析器解决的是“把 PDF、DOCX 和表格读成带结构的内容”。这里可以用 Docling：它支持 PDF、DOCX、PPTX、XLSX 等格式，并能导出 Markdown、HTML 和 JSON；官方项目说明也提供本地执行能力。它适合先做 RFP 试点，尤其是需要保留标题、表格、页码和阅读顺序的场景。

Docling 的代码许可是 MIT，但模型权重和依赖不能自动继承这个许可。它更适合有 Python/Docker 基础、需要把客户文件留在内网的小团队；如果只有几份简单文本，直接人工复制可能更省事；如果 RFP 有复杂扫描件、手写批注或大量图表，必须先用样本验证，不要把“能打开文件”当成解析正确。

n8n 解决的是“文件从哪里来、按什么顺序处理、结果写回哪里”。它是 fair-code 工作流自动化工具，不是 CRM，也不是知识库。可以用 Webhook 或邮箱节点接收文件，用 HTTP Request 调 Docling 服务，用规则节点写入表格或数据库，再把待审核矩阵交给方案负责人。它可以自托管，但服务器、凭据、备份、第三方 API 和许可证边界都需要维护。

模型只放在窄的一段：把已解析的问题归一化、从批准材料中找候选依据、生成答案草稿和缺口问题。价格、交期、认证有效期、客户案例和法律表述必须来自受控资料或人工输入，不能让模型凭常识补全。

准备清单先不要超过一个试点能承受的范围：一份已授权 RFP；10–20 份已批准的能力矩阵、产品资料和历史案例；每份材料的 owner、版本、生效日期和失效日期；一个能保存原文件与结构化记录的位置；一个方案负责人和一个业务审核人。先选一个产品线，不要一开始覆盖全公司。

目标流程可以写成：触发上传 → 保存原件并计算 file_hash → 用 Docling 解析 → 识别章节、问题编号和表格行 → 按产品线与版本匹配批准资料 → 生成带证据的答案草稿 → 校验覆盖率和有效期 → 人工审核 → 输出矩阵、缺口清单和提案初稿。解析失败或表格错位，都要在人工队列停住。

模型的输入应限制在单个问题、召回的批准段落和输出 schema 内。一个可执行的输出形状可以是：{question_id, answer_status, draft_answer, evidence_refs:[{file,version,page}], missing_info, needs_human_review}。如果没有足够依据，answer_status 必须是 unknown，draft_answer 留空或只写需要补充的问题。

n8n 的规则可以先做三道硬检查：if evidence_refs.length == 0，则禁止进入提案草稿；if source.expiry_date < today，则标记 expired；if answer_status in ['partial','unknown']，则创建 owner 任务。每一次处理都带 submission_id 和 file_hash，重复上传只关联原记录，不新建第二个项目。

• 触发：RFP PDF/DOCX 上传或进入指定邮箱；
• 保存：原件、收到时间、项目 ID 和 file_hash；
• 拆题：规则优先识别章节、问题编号和表格行；
• 匹配：按产品线、材料版本和关键词召回批准资料；
• 人审：方案、产品、交付和法务/合规分别确认自己承担的部分。

第一道人工检查发生在拆题后：方案负责人确认客户问题没有被模型合并错，尤其是“必须满足”和“加分项”不能混为一谈。第二道发生在证据匹配后：资料 owner 确认版本、适用地区和有效期。第三道发生在提案输出前：技术、交付、商务和法务分别确认自己承担的承诺。

这条边界很重要。模型可以把“我们支持某类接口”改写成客户易读的句子，但不能把“计划支持”写成“已支持”，不能把内部测试写成客户案例，也不能把一个产品线的认证挪到另一个产品线上。RFP 的自动化目标是减少查找和漏答，不是把承诺权交给模型。

如果需要接入 CRM 或项目系统，建议先写入“RFP 项目”和“待审核矩阵”，不要直接改变商机阶段或发送客户邮件。只有人工批准后，才把最终版本导出或交给现有提案流程。

解析失败：保存原文件和失败页码，转人工，不让模型根据文件名猜内容。扫描件或表格错位：标出页码和字段，要求人工修正后再匹配。材料过期：保留旧版本引用作为提示，但禁止进入 supported 答案。

重复执行：以项目 ID + file_hash + question_id 做幂等键，重复运行更新处理日志，不重复创建问题。模型超时或 JSON 不合规：只重试模型步骤；规则产出的原始问题和证据不丢。外部模型不可用时，仍应交付问题矩阵和缺口清单，而不是伪造提案。

答案没有证据、涉及价格/交期/合同/合规、或者多个部门意见冲突时，状态都应停在人工队列。日志至少保留原文件链接、解析版本、材料版本、模型版本、规则结果、人工决定和最终输出位置；普通通知里不要复制客户 RFP 全文。

先准备一组黄金样本：正常数字 PDF、Word 表格、扫描页、重复上传、过期材料、无答案问题、跨章节问题和带敏感承诺的问题。每份样本都由业务人员先标出正确的问题编号、证据页码和应当 unknown 的位置，再让流程回放。

至少看五个结果：问题编号覆盖率 100%；每一项都有原文定位；过期材料不会成为唯一依据；unknown 和冲突项全部有负责人；重复执行不产生重复主记录。答案草稿的文字质量可以再优化，但这五项没有通过，就不应该进入正式提案。

上线后，业务 owner 每周处理未匹配和冲突清单，技术维护者每月检查解析器、模型、凭据、磁盘和材料索引。新版本材料先进入待批准状态，旧版本不应被静默覆盖。