售前文档生成平台的诊断阶段：为什么我们把「标书优先」改成了「方案优先」

背景

客户是一家高科技制造企业。售前团队日常要产出三类文档：交流 PPT、方案书、标书应答，另外还有报价清单。

诉求很直接：能不能用 AI 把这些文档生成出来，部署在内网，数据不出去。

问题

这类需求最容易犯的错误，是把它当成一个「文档生成」的技术问题，直接进入选型和开发。

我们先做了一轮售前访谈与文档盘点。结果推翻了五处原有规划，其中三处会直接影响开发投入的方向。

诊断发现

一、建设重点：标书优先 → 方案产线优先，标书并行

原规划以标书应答为第一优先级，因为标书看起来最标准化、最适合自动化。

访谈拿到的实测流程是：

标书全流程约 10–15 天：通读 1 天 → 分工 1 天 → 技术应答与方案 3–7 天 → 商务并行 → 排版 1 天 → 评审修改 2–3 天 → 定稿检查 1 天 → 打印递交 1 天

最耗时、返工最多的一步是「编写方案」。 而方案能力本身就是技术标正文的核心——方案产线和标书产线共享同一个发动机。

调整后：先做方案书 + 交流 PPT 产线，标书应答并行推进（不降级）。对客户的叙事和 MVP 的第一个可用物，都以方案打头。

二、量化目标：按实测基线重新校准

客户自己的成功口径是：提效 50%、新人 3 天出合格初稿。

对外承诺就按这个口径签认，内部目标定得更高。 原估算偏乐观这件事本身说明了一个问题——量化目标必须以客户的实测基线为准，而不是以我们的估算为准。这也是很多 AI 项目验收时扯皮的根源。

三、一个原规划里完全没有的价值主张

访谈里最意外的一条：售前一周的时间分配相当平均，而最挤占时间的不是写文档，是内部沟通。

原话是：「如果每周多一天，会用来内部沟通。」

这不推翻「文档产出是瓶颈」的基本判断（其他证据组仍然支撑），但它给平台增加了一条此前完全没有的价值主张——项目空间共享上下文等于少开会、少传话：方案和标书的口径自动一致、评审在线留痕、进展看板代替口头同步。

这条价值主张不做访谈是想不出来的。

四、IT 环境与预想完全不同

原假设是纯内网、无外网、有明确的 GPU 资源。实际情况是：能上外网、没有内网系统、GPU 资源的具体情况售前团队本身并不知情。

更关键的是，部署约束、数据分级规则、对外部 API 的态度这几个决定架构的问题，决策权集中在一个人手里——这意味着需要一次专门的对齐会，而不是继续和售前团队讨论技术方案。

五、文档盘点：15 项根本没有模板

盘点下来，售前要产出的文档里有 15 项是没有标准模板的——背景速览、需求调研表、招标文件分析、商务标文件包、澄清答疑、述标 PPT、交付实施方案、验收方案、变更单、项目周报、复盘报告、工时统计等等。

「没有模板」意味着这些文档的生成不能靠模板填充，只能靠知识库加生成，且质量难以预先约定。同时也意味着它们不适合作为第一批产线。

原规划里被列为「快赢」的背景速览，因为现状痛感弱，被降级。

设计要点

诊断之后的方案设计，有三条值得记录。

本地模型选型做了实测对照，不看跑分

开发环境用一张消费级显卡跑本地模型，生产切换到双卡专业卡，靠配置切换而不是改代码。

选型换过一次档：原定模型与所用工具链的工具调用兼容性差——实测三次调用零次正确，换成另一个模型后三次全对。这类问题在任何公开跑分里都看不到，只能实测。

另外有三条实测约定，写错任何一条都会出事，包括思考模式的默认开关（显著影响 token 消耗和速度）、以及调用接口的选择（不同模型对思考内容的暴露行为不一致，不能凭上一个模型的结论推断）。

知识库片段级签认：未签认不被引用

知识库不是一个文件夹，而是可以逐条编辑的片段集合——产品描述、参数、案例各自独立，带分级标签，并有一道研发签认流。

未经签认的片段不会被产线引用。

这条规则解决的是售前文档最要命的问题：拿过期参数去投标。改一处，全平台生效。

平台边界说明书

配套输出了一份《平台边界说明书》，列出十大边界与待确认清单，包括备份容灾口径、生成任务的知识库快照锁定（保证可复现）、平台服务仅内网监听、录音留存的合规前置确认、行业复制时的知识库分区预留、存储容量规划。

边界写在前面，是为了让后面的验收有依据。

当前状态

这个项目目前处于开发起步阶段，没有交付结果数据。

已完成的是：需求诊断、产线优先级重排、量化目标校准、技术选型定案、平台架构与边界说明、界面原型。

已验证的是：三条产线的方法在共创阶段跑通过，产出过真实交付物；本地模型的选型经过实测对照。

尚未完成：平台本身的开发、知识库的规模化建设、量化目标的实测验证。

经验与边界

最值得记录的一条：诊断本身就是交付物。

这个项目的访谈只花了很短时间，但推翻了五处规划——如果直接按原规划开发，第一个 MVP 会是一个标书产线，量化目标会按偏乐观的估算签，架构会按错误的 IT 环境假设设计，而「少开会」这条最能打动人的价值主张根本不会出现在方案里。

企业 AI 项目里最贵的成本不是开发，是把力气用在错的方向上。 一轮认真的诊断，成本是几天，收益是避免几个月的返工。

边界：

• 本文描述的是诊断结论与设计决策，不是交付结果——提效数字是客户的目标口径，不是已实现的成绩
• 关键决策集中在单一角色手里，这是项目风险，需要专门的对齐机制
• 15 项无模板文档的生成质量目前无法预先承诺，需要在产线打磨阶段逐项验证