这一份是谁写的：由 HEYI 撰写，介绍我们交付的一个客户项目，客户未获具名授权前按其要求匿名。量化数据由客户提供，每一项的口径与「哪些数据我们不提供」都写在文末「口径与说明」里。
这一份里有什么
- 一份投标书十万字，十余个章节
- 五件挡在前面的事，找内容比写内容更耗时
- 五阶段流水线，其中两段是并行的
- 初稿 2 小时，而内容全部来自知识库
- 数据的口径，以及我们不提供什么
01 场景
每份投标书通常十万字以上，要覆盖十余个章节，且必须精准响应招标书里的每一条需求。
客户是一家 B2B SaaS 企业。使用方是客户的售前团队，年均参与上百个投标项目，覆盖金融、制造、医药、零售等多个行业。
每个投标项目的链路是固定的：拿到招标书 → 人工研读需求 → 翻遍知识库和历史方案 → 逐章拼写投标文档 → 多轮内审修改 → 排版定稿。交付标准很高——技术方案、功能方案、实施计划、运营服务、公司资质等十余个章节都要写，而且每一条都要对得上招标书。
02 挑战
光是「找到对的内容」就占去六成以上的编写时间。
01 招标书千差万别，需求解读全靠人工
格式不同——有 Word、有 PDF、有 Excel 或 PPT。技术需求散落在不同章节，有的嵌在评分标准里，有的藏在商务条款后面。一个资深售前顾问至少要 1 到 2 天才能完整梳理出一份招标书的核心需求，新人要 3 到 5 天，还经常遗漏关键条目。
02 知识散落各处，找内容比写内容更耗时
产品文档、技术白皮书、行业解决方案、客户案例、竞品分析都有积累，但分散在几十个文件夹、上百份文档里。写某个章节时要在产品手册、架构文档、历史投标书之间反复检索，光是找到对的内容就占去六成以上的编写时间。更糟的是同一个产品功能在不同文档里的描述可能不一致，用了哪个版本全看写的人当天翻到了哪份。
03 经验积累在人身上，人一走就带走了
哪个行业该突出什么资质、面对不同竞品该怎么组织差异化内容——这些策略只存在于几位资深售前的脑子里。人员调岗或离职后，新接手的人不知道该重点突出什么，只能凭感觉写。
04 多项目并行时，产能瓶颈立刻暴露
投标项目有明显的季节性集中，旺季时 5 到 8 个项目同时推进，每个项目至少占用 1 到 2 位资深售前 2 周时间。人手不够时要么放弃低优先级项目，要么仓促赶工交出质量打折的方案。客户团队负责人估算，因投标产能不足每年至少错过 15% 到 20% 的可投标商机。
05 章节名称不统一，每次都是「从头拼」
不同招标书对章节的叫法千差万别——有的要「技术架构方案」，有的叫「系统技术设计」；有的要求「实施部署方案」，有的叫「项目管理计划」。看上去不同的名称，实际对应的是同一类内容。但售前每次都得人工判断对应关系、从零组织内容，复用率极低。
03 方案
把「人工查找拼写」变成一条五阶段的流水线，一次操作触发。
- ① 文档解析：招标书直接传，支持五种格式，单次上传总量上限 10 万字符。不调用模型。
- ② 需求解读：结构化提取 7 个关键字段。只提取明确写出的信息。
- ③ 专家经验加载：五个模块全量注入。纯文件读取，不调用模型。与 ④ 并行。
- ④ 知识库检索：22 份文档按优先级加载，全量注入，不做向量检索。与 ③ 并行。
- ⑤ 投标书生成：综合前四阶段输出，生成完整投标响应文档。
五个阶段按顺序读，但③ 和 ④ 之间没有依赖，是并行跑的——总耗时压到两者中较长的那一个，不是两段相加。
01 需求解读：7 个字段，不替业务做假设
提取招标方名称、项目名称、技术要求、服务要求、功能范围、实施要求、必需章节七项。其中招标方名称必须有效识别，否则标记「不可继续」——防止后续全篇称呼写错。必需章节只取技术章节，自动过滤商务条款。系统只提取招标书中明确写出的信息，未提及的字段返回空值而不是猜测。
02 专家经验前置全量注入，不做被动检索
资深售前的投标策略整理为五个模块独立维护：行业与产品能力的适配关系、资质认证在什么场景下该推哪几项、面对不同竞品的差异化组织方式、各行业的痛点与方案侧重、全球化部署与合规。无论招标书是否提到这些维度，专家经验都作为写作底料加载进去——纯文件秒级读取，不调用模型，零额外成本。
03 知识库分层：22 份文档、五大分类、全量注入
按业务重要性分五层依次加载：措施模板（4 份，约 9400 行，覆盖项目概述、技术方案、功能方案、实施方案、售后服务、公司介绍）→ 产品文档（7 份，含完整功能清单、技术架构、AI 能力手册、开放平台接口文档）→ 行业方案（6 份）→ 客户案例（4 份）→ 综合方案（1 份）。全部以纯文本直接加载到模型上下文，没有向量库、没有检索损耗；每份文件设 5 万字符上限，防止单文件过大影响整体质量。
04 章节映射：客户叫什么名字，系统都认得
内置 10 个标准章节作为骨架——项目概述、技术方案、功能方案、运营服务、内容方案、实施方案、售后服务、公司介绍、竞争优势、附件材料。客户在招标书里指定自定义名称时自动映射到最接近的标准章节；未指定章节的按 10 个标准章节全量输出。每章不少于 1000 字的下限，防止薄弱章节影响评分。没有知识库支撑的内容不编造，标记「待补充」由人工确认——知识库优先，宁缺勿假。
05 全链路可追溯
每次模型调用的完整提示词可选存档便于复盘；支持查看推理过程；每个阶段的输出流式实时展示，售前顾问可在任一阶段介入调整；操作全程记录，出问题能精确定位到哪个环节、什么时间，30 天以前的记录自动清理。各智能体之间的通信经过签名验证，令牌 5 分钟过期自动刷新。
04 成果
初稿从 2 周压到 2 小时，而每段内容都来自知识库、未覆盖的需求明确标「待补充」。
- 改造前 · 初稿产出：2 周——每个项目占用 1 到 2 位资深售前，旺季排期就崩了
- 上线后 · 初稿产出：2 小时——上传招标书，解析、解读、匹配、生成一次跑完
量化数据由客户提供，口径见文末「口径与说明」。这里说的是初稿——之后仍要人工审核与排版定稿。
01 效率
需求解读从 1 到 2 天缩到 5 分钟；知识检索从「翻文档 2 到 3 小时」变成「自动加载 10 秒」——22 份知识文档、约 1.2 万行内容按优先级全量加载，零遗漏。
02 质量
内容来源全部可追溯：每段内容都来自知识库，未覆盖的需求明确标记「待补充」，不编造、不臆断。章节覆盖完整：10 个标准章节全量输出，自定义章节自动映射，每章不少于 1000 字。资深售前的五个模块经验全部结构化，新人用系统就能输出结构完整、内容有据的投标方案。
03 产能
单人可同时跟进的投标项目从 1 到 2 个提高到 3 到 4 个，原本由人承担的重复性查找与拼写大部分前移到系统完成。产能释放之后，不再被迫放弃低优先级项目。
04 体验与稳定性
五种格式的招标书直接上传，无需格式转换；生成的投标书一键导出 .docx，售前在此基础上微调排版即可提交；流式输出让生成过程实时可见，不用等到全部完成。另有离线演示模式，方便内部培训与客户展示。系统稳定运行，签名认证加短时效令牌保障服务安全，结构化日志 30 天自动清理。
售前顾问不再是文档搬运工，而是方案审核人。
系统出的是初稿。没有知识库支撑的内容不编造，标「待补充」交人工确认。
口径与说明
- 客户身份：客户为一家 B2B SaaS 企业。未获书面授权前不具名，本文也不披露客户的产品名、客户名单与其下游客户信息。
- 量化数据：2 周 → 2 小时、需求解读 5 分钟、知识检索 10 秒、单人同时跟进 3 到 4 个项目，由客户提供。「每年至少错过 15% 到 20% 的可投标商机」是客户团队负责人的估算，不是统计值。
- 「2 小时」指的是初稿：系统产出的是投标响应文档的初稿，之后仍需人工审核、补充「待补充」项并排版定稿。我们不讲「2 小时出标」。
- 关于「替代」：系统承接的是重复性的查找与拼写，人工审核环节没有被取代。我们不讲替代售前团队或无人化投标。
- 我们不提供的数据：中标率、中标金额、投标数量的同比变化——没有经审核的数据支撑，所以不说。
- 不点名的两类信息：客户面对的竞品名称，以及客户自己的客户名称与案例数据。前者是客户的内部竞争策略，后者与我方交付无关，都不作为我方案例的背书。
- 关于界面截图：系统里是客户的知识库原文与真实招标书，本文未使用截图。需要看界面时，我们用演示数据现场演示。
关于这个案例的常见问题
这个系统真的能处理我们所有的投标文档吗？
可以处理五种格式的招标书（Word、PDF、Excel、PPT等），单次上传总量上限10万字符。系统会解析招标书并提取7个关键字段，然后生成包含10个标准章节的投标响应文档。对于没有知识库支撑的内容，会明确标记'待补充'由人工确认。
2小时出初稿这个数据可信吗？是实际生产环境的数据吗？
初稿从2周压缩到2小时的数据由客户提供。这是指上传招标书后，系统完成解析、解读、匹配和生成的时间。需要说明的是，这指的是初稿产出，之后仍需人工审核、补充'待补充'项并排版定稿。我们不讲'2小时出标'。
这个系统能完全替代我们的售前团队吗？
系统承接的是重复性的查找与拼写工作，人工审核环节没有被取代。售前顾问的角色从文档搬运工转变为方案审核人。系统出的是初稿，没有知识库支撑的内容不编造，会标记'待补充'交人工确认。我们不讲替代售前团队或无人化投标。
知识库是如何组织的？需要我们做什么准备？
知识库按业务重要性分五层依次加载：措施模板（4份）→产品文档（7份）→行业方案（6份）→客户案例（4份）→综合方案（1份）。全部以纯文本直接加载到模型上下文，没有向量库、没有检索损耗。每份文件设5万字符上限，防止单文件过大影响整体质量。