本专题写给在政企 AI 项目里"陪着招投标走完全程"的 FDE/FDSE。它不是投标经理的培训手册,而是把 FDE 在售前阶段的真实动作——技术方案撰写、可行性论证、PoC 设计、评标得分提升、售前与交付的衔接——拆到可执行的颗粒度。所有模板、字段、案例都来自真实交付,可直接套用。核心立场:售前 FDE 不是"陪标的工程师",而是"决定这一单能不能拿、拿了能不能交付"的胜负手。

一、FDE 在售前/招投标里的真实位置

很多人对 FDE 的刻板印象是"客户现场的工程兵",但在中国政企市场,一个 FDE 总工时的 30%–40% 消耗在售前阶段(免费 PoC、方案评审、标书撰写、答辩),这个比例远高于海外(海外 FDE 售前工时通常 < 15%)。原因很简单:中国政企的决策链是 业务处室 → 信息中心 → 大数据局 → 分管领导 → 招投标 → 总集成商中标 → 分包到 ISV → FDE 进场,从首次接触到签约平均 6–12 个月,大型央国企 12–18 个月。在这条长链上,FDE 是唯一一个既懂技术、又能进客户现场、还懂业务的人,售前阶段几乎绕不开。

FDE 在招投标里承担四件事,缺一件就丢分:

售前动作	产出物	对中标的影响	不是 FDE 干会怎样
技术方案书撰写	标书技术分册(60–100 页)	直接占技术分 40–60 分	销售写的方案空洞、对不上需求,技术分垫底
可行性论证	技术可行性报告 + ROI 测算	决定评委敢不敢投你	客户质疑"是不是画饼",商务分也跟着塌
PoC 设计与执行	PoC 演示 + 指标对比报告	大单(500 万+)的入场券	没做 PoC 直接投标,技术分被做过 PoC 的对手碾压
报价支撑	工作量分解(WBS)、人天/算力/许可拆分	让报价有依据、不被判低价恶意竞争	报价被质疑"低于成本",废标

一句话:FDE 在招投标里是技术方案的真值来源。销售负责关系和商务,FDE 负责让评委相信"这家能干出来"。这俩活儿都干不好,标就是废的。

二、中国政企招投标流程:FDE 必须背熟的五个环节

很多 FDE 以为招投标就是"看到标书就投标",这是对流程的致命误解。中国政企的招投标是强流程、强合规的游戏,任何一个环节踩雷都直接废标。FDE 要在客户关系早期就理解整条链:

2.1 需求立项(招标前 6–12 个月)

客户业务部门提出需求,信息中心立项,走预算。FDE 在这个阶段就该进场——通过免费的技术交流、行业分享,把客户的需求规格往自己有优势的方向引。一个关键的灰色技巧是"参数引导":在客户写技术参数时,把自己产品的独特能力(如某种特定场景的精度、某种私有化部署能力)写进技术参数,后面对手达不到参数就被废标。这是合法的(只要参数不是为单一供应商量身定制的歧视性条款),但需要在《政府采购需求管理办法》框架内操作。

2.2 标书编制(招标前 1–2 个月)

客户(或委托的招标代理)编制招标文件,含技术参数、商务要求、评分细则、合同草案。FDE 必须在公告前拿到标书草稿(合规前提下,通过客户主动征求意见)做"投标可行性预审",核心看三件事:是否有歧视性条款(指向单一供应商)、评分细则是否对自己有利、技术参数自己能否完全满足。看到对己不利的条款,这时还能反馈;公告一出就不能改了。

2.3 公告与投标(招标公告后 20–30 天)

《招标投标法实施条例》规定,依法必须招标的项目,自招标文件开始发出之日起至投标人提交投标文件截止之日止,最短不少于 20 日。这 20–30 天就是 FDE 真正写标书的窗口。一个千万级 AI 项目的技术标通常 80–150 页,FDE 是主笔,需要拉着算法、平台、交付、安全几个方向的人一起写,自己总稿。

2.4 开标与评标(投标截止当日或次日)

评标委员会由招标人代表和从专家库随机抽取的专家组成,5 人以上单数,技术经济专家不少于成员总数的 2/3。FDE 通常不进评标室,但要做两件事:一是写"澄清答复预案"(评委一定会问的 5–10 个问题及标准答案),二是准备现场答辩 PPT(很多项目有述标环节,15–30 分钟,常常是 FDE 上台)。评标方法下面单讲。

2.5 中标与签约(评标后 3–15 天)

中标候选人公示 3 天,无异议后发中标通知书,30 天内签合同。FDE 在这个阶段要做售前交付交接:把售前承诺的所有指标、架构、工期、风险,无遗漏地传给交付团队。这一步做不好,就是经典的"售前吹牛、交付背锅",后面专门讲。

流程红线:FDE 不要碰三类合规雷区——串通投标(与客户/对手私下串标价、串方案)、商业贿赂(给评委/采购人员任何形式的好处)、资质造假(业绩、人员、证书造假)。这三条任一踩中,轻则废标+列入政采黑名单(1–3 年禁入),重则刑事追诉。FDE 是技术角色,不碰商务灰产,这是底线。

三、评标视角:综合评分法与最低评标价法

中国政府采购(《政府采购法》及财政部令第 87 号《政府采购货物和服务招标投标管理办法》)规定,评标方法只有两种:最低评标价法与综合评分法。AI 项目因为是技术复杂、定制化重的服务类项目,95% 以上用综合评分法;最低评标价法只适用于技术标准统一的通用货物(如标准服务器、办公电脑),AI 项目几乎用不上。

3.1 综合评分法的分值结构

总分 100 分,典型拆分(以一个千万级政务大模型项目为例):

分项	权重	评分点	FDE 主战场
价格分	10%–30%(服务项目不低于 10%)	低价优先:基准价/投标价 × 价格分值	FDE 不直接控价,但提供工作量依据
技术分	40%–60%	技术方案、架构、技术路线、PoC 结果、创新性	FDE 的主战场,直接决定胜负
商务分	15%–25%	企业资质、同类业绩、团队、认证	FDE 提供项目案例与团队简历
服务分	10%–20%	售后方案、培训、SLA、本地化服务能力	FDE 设计 SLA 与培训方案

关键事实:财政部令第 87 号第 55 条明确,货物项目价格分值占总分值比重不得低于 30%,服务项目不得低于 10%。AI 是服务类,价格分通常 10%–20%,这意味着技术分(40–60 分)是真正的胜负手。FDE 把技术分从 35 分提到 50 分,价格上让对手 10 分都赢。

3.2 价格分的计算:低价优先,不是越低越好

价格分用统一公式计算,最常见的是"基准价法":所有有效投标报价的算术平均(或最低价)作为基准价,投标价等于基准价得满分,偏离基准价按比例扣分。这意味着报价太低不仅不加分,还会触发**"低于成本价"质疑**——评标委员会可要求投标人书面证明报价不低于成本,证明不了就废标。FDE 在这里的价值是给销售一个有依据的工作量分解,让报价既不偏离基准价太远,又能在被质疑时拿出成本佐证。

3.3 技术分的常见评分维度与 FDE 对策

技术分通常拆成 4–6 个子项,FDE 要逐项吃透评分点,做到"每个评分点都有明确响应":

评分维度	典型分值	评委看什么	FDE 怎么拿分
需求理解	5–10 分	是否准确抓到客户痛点,有无遗漏	用客户原话回写需求,逐条对应,配业务流程图
总体架构	10–15 分	架构是否合理、先进、可落地	上架构图(业务/应用/数据/基础设施分层),标注技术选型理由
技术路线	10–15 分	算法/模型选型是否适配,有无创新点	对比 2–3 种路线,给出选型矩阵,讲清为何选这个
实施方案	8–12 分	工期是否合理、方法论是否成熟	给甘特图、里程碑、风险管理表、质量保障措施
PoC/创新	5–10 分	有无实证、有无差异化亮点	PoC 指标对比、客户场景的真实验证结果
安全合规	5–10 分	等保、数据安全、信创适配	等保 2.0 测评、数据分级分类方案、昇腾/信创适配证明

FDE 的得分秘诀不是"写得长",而是"对得上评分点"。评委在 2–3 天内评几十本标书,每本平均看 1–2 小时,评分点的每一句问询,必须在标书里有"评分点原话 → 响应内容 → 证据"的一一对应。响应漏一个点就丢一个点的分。

四、技术方案书的写法:八段式模板

一个能赢标的技术方案书通常包含八个部分,FDE 按这个模板写,既覆盖评分点,又显得专业。下面是每个部分的写法要点和常见反模式。

4.1 需求理解(开篇,5–10 分)

不要复述招标文件,要做"需求的二次解读"。结构:客户现状(2–3 个量化痛点)→ 业务目标(用客户战略语言表述)→ 技术目标(拆成可度量的指标)→ 本方案的核心价值主张(一句话)。每个痛点配一组数据(如"现有工单平均处理时长 4.5 小时,目标降至 1 小时内"),让评委一眼看到你懂业务。

反模式:开篇就是"我公司具有 20 年经验……"。评委一秒翻过。需求理解段必须以客户为主语,不是以自己为主语。

4.2 总体架构(核心,10–15 分)

上分层架构图,标准做法是四层一张图:业务应用层(具体场景功能)→ AI 能力层(大模型/Agent/知识库/向量检索)→ 数据与平台层(数据治理、MLOps、模型仓库)→ 基础设施层(GPU 算力、存储、网络、信创适配)。每层标注关键技术选型、与现有系统的集成点、数据流向。配一张集成关系图说明与客户现有 OA/ERP/数据中台怎么对接。

反模式:架构图照搬某个通用模板,与客户业务无关。评委会问"这个组件具体解决什么问题",答不上来直接扣分。

4.3 技术路线(决定技术分高低,10–15 分)

这是 FDE 真正展现技术深度的部分。核心是"选型矩阵":列出 2–3 种候选技术路线(如"通用大模型 + RAG" vs "领域微调大模型" vs "规则引擎 + 小模型"),从精度、成本、可维护性、合规、上线周期五个维度打分对比,给出选型理由。然后讲模型层(基座选型、微调策略)、数据层(数据治理、标注流程)、应用层(Agent 编排、工具调用)的具体做法。

反模式:只写一条路线,没有对比。评委会认为你没思考过;或者写了对比但只说"我选的最好",理由空洞。

4.4 实施计划(8–12 分)

上甘特图,拆成 5–7 个阶段:项目启动 → 需求调研 → 方案设计 → 开发与适配 → 测试与试运行 → 上线与培训 → 验收。每个阶段标注工期、交付物、责任人、关键里程碑。配一张风险管理表:列出技术风险、数据风险、合规风险、人员风险各 3–5 项,每项给出应对措施。AI 项目特别要写模型迭代计划(上线后每月/每季度的再训练、效果回归)。

反模式:实施计划写得跟通用 IT 项目一样,没有 AI 特有的"数据准备""模型迭代""效果验收"环节。评委一眼看出不懂 AI。

4.5 团队配置(在商务或服务分里,5–10 分)

给出项目组组织架构图(项目经理、技术经理/FDE、算法工程师、数据工程师、平台工程师、测试、交付),每个核心角色配个人简历(姓名、学历、相关项目经验、认证)。AI 项目特别要突出算法和 FDE 角色的人数与资历,这是评委判断"能不能干出来"的关键。一个千万级项目至少配 1 个项目经理 + 1 个 FDE + 2–3 个算法 + 2 个平台 + 1 个数据。

反模式:团队表只列岗位不列人,或者列的人资历明显不够(如算法工程师只写"本科应届")。评委会怀疑交付能力。

4.6 同类案例(商务分,5–10 分)

列 3–5 个与本项目高度相似的案例:行业相同、规模相近、技术路线一致。每个案例给项目名称(脱敏)、客户行业、合同金额(可选)、建设内容、上线时间、效果数据。案例的相似度比数量重要——5 个无关案例不如 1 个一模一样的。

反模式:把公司所有案例都堆上去,不管相不相关。评委会觉得你在凑数。

4.7 风险与质量保障(技术或服务分,5–10 分)

技术风险(模型效果不达标、数据质量差、性能瓶颈)、项目风险(需求变更、人员流动、客户配合度)、合规风险(数据出境、个人信息保护)分三类,每类 3–5 项,每项写发生概率、影响程度、应对措施、责任人。配质量保障体系(代码评审、模型评测、UAT 测试、灰度上线)。

反模式:只写"我们将加强风险管理",没有任何具体措施。这种回答等于没写。

4.8 售后服务与培训(服务分,10–20 分)

写 SLA(故障响应时间、解决时间、可用性指标)、服务期(通常免费 1–3 年)、培训计划(管理员培训、业务用户培训、技术交接培训,各几人几课时)、本地化服务能力(本地团队人数、驻场安排)。AI 项目特别要写模型效果保障服务(上线后效果回退如何处理、是否承诺重训)。

反模式:售后写成"7×24 小时响应",但不写具体 SLA 等级和违约责任。客户最看重可追责的承诺。

五、可行性论证:让评委敢投你

很多 FDE 以为可行性论证是技术方案的一部分,其实它是独立的一份说服工具——在客户内部立项、在评标时打消疑虑、在售后验收时挡子弹。可行性论证分四个维度,每个维度都要有数据、有依据、有边界条件。

5.1 技术可行性

回答"这个 AI 项目能不能做出来"。论证方法:对标行业基准(如"当前行业 SOTA 在此任务的 F1 为 0.85,本项目目标 0.80 可达)、PoC 实证(拿出 PoC 的指标数据)、技术成熟度评估(TRL 等级,本项目关键技术处于 TRL 几)。避免使用绝对化表述("一定能达到 95% 准确率"),改用区间("基于 PoC 结果,预计准确率在 88%–92% 区间")。

5.2 数据可行性

回答"有没有足够、足够好的数据"。论证方法:数据资产盘点(客户现有多少数据、什么类型、什么质量)、数据缺口分析(需要补哪些数据、怎么补)、数据标注可行性(标注量、标注成本、标注工具)。AI 项目失败的 60% 是数据问题,这一段写不实,评委不敢投。

5.3 合规可行性

回答"过不过得了法务和监管"。论证方法:数据合规(《个人信息保护法》《数据安全法》要求的告知同意、数据分级分类、出境审查)、算法合规(生成式 AI 服务备案、深度合成算法备案)、行业准入(金融行业的算法可解释性要求、医疗行业的医疗器械软件 NMPA 认证)、信创合规(央国企要求的国产化适配:昇腾/海光芯片、麒麟/统信 OS、达梦/人大金仓数据库)。

5.4 ROI 可行性

回答"花这笔钱值不值"。论证方法:成本测算(建设成本 + 5 年运维成本)、收益测算(降本:替代多少人天、节省多少成本;增收:提升多少效率、带来多少业务增量)、回收期(典型 AI 项目 12–24 个月回本)、敏感性分析(收益的乐观/中性/保守三档)。ROI 测算要用客户自己的财务口径,不要用通用行业数据。

四个可行性是一个矩阵,任何一个维度被判"不可行",整个项目就黄了。FDE 的价值是在售前就把"不可行"的风险挖出来,要么解决、要么提前说服客户调低预期,而不是等到交付阶段才发现根本做不出来。

六、PoC 设计:用最小成本赢标

PoC 是大单(500 万以上)的入场券。但 90% 的 FDE 把 PoC 做成了免费打白工——做了 Demo、客户说"不错",然后没有然后。正确的 PoC 是一个有明确成功标准、有签约承诺、有时限、有数据的小型项目,目标是"用最小成本证明价值,并锁定主合同"。

6.1 PoC 的四要素(缺一不可)

1. 明确场景:只选一个最有代表性、客户最痛、FDE 最有把握的场景,不要贪多。场景定义要写成"输入是什么、输出是什么、评判标准是什么"。
2. 明确指标:量化指标 + 业务指标。量化指标(准确率、召回率、响应时间)用技术口径;业务指标(工单处理时长降低、人工坐席替代率)用客户业务口径。两个都要。
3. 明确成功标准:在 PoC 启动前就写死"如果指标 A 达到 X%,客户承诺签订 Y 万元主合同"。这是 PoC 的命脉——没有成功标准的 PoC 等于免费给客户做 R&D。
4. 明确时限:PoC 周期 不超过 8 周。超过 8 周客户热情衰减,FDE 投入失控。

6.2 PoC 该不该收费

应该收费,哪怕只收 20–50 万元。免费 PoC 的三大问题:客户不珍惜(投入度低)、客户内部决策不严肃(PoC 结果没人推动)、FDE 被白嫖(做完就散)。收费 PoC 反而提升中标率——付费的客户有内部承诺,会主动推进主合同。如果客户坚持免费,FDE 退而求其次:用最小数据集 + 最小算力 + 现成模型,把 PoC 成本压到 1–2 人周,并且写进 PoC 协议"PoC 结果知识产权归 FDE,客户不得转交第三方"。

6.3 PoC 的执行节奏(8 周模板)

周次	动作	产出
第 1 周	场景定义、数据准备、客户对接	PoC 方案文档 + 数据清单
第 2–3 周	模型选型、Prompt/微调、系统集成	可运行的 Demo(内测)
第 4–5 周	客户业务人员试用、效果调优	试用反馈 + 优化记录
第 6 周	指标测评、数据收集	测评报告(技术指标 + 业务指标)
第 7 周	演示、答疑、客户内部汇报	演示 PPT + 答疑纪要
第 8 周	谈主合同、转交付	主合同条款 + 售前交付交接

6.4 PoC 的数据必须可审计

所有指标对比都要进客户内审报告,作为后续主合同的归因依据。具体做法:PoC 启动前固化一组"基线数据"(现有方案的处理结果),PoC 结束时用同一批数据跑 FDE 方案,得出对比指标。基线和对比数据都由客户方人员参与采集(不是 FDE 自己测自己),并签字确认。这样客户内审、上级审批都有据可查,主合同推进才有依据。

七、售前与交付的衔接:别让售前吹的牛交付兜不住

这是中国 AI 行业最普遍的灾难:售前 FDE 为了拿单,把指标、工期、成本往好了承诺;交付 FDE 进场,发现根本达不到,要么扯皮要么烂尾。FDE 不是销售,不能靠"卖出去就算赢"的思路干活——拿了一单交付砸了,这家客户永远不会再给你机会,而且行业口碑会传开。

7.1 售前承诺的三条红线

FDE 在售前阶段对客户做承诺时,必须守住三条线:

1. 指标承诺有依据:任何指标承诺都要有 PoC 数据、行业基准或可复现的实验支撑,不口胡。承诺"准确率 95%"前,先想清楚用什么数据测、谁来测、测不到怎么办。
2. 工期承诺有余量:售前承诺的工期按交付估算的 1.2–1.5 倍 报。AI 项目的不确定性(数据质量、模型迭代、客户配合)远高于传统 IT,留余量是给交付团队留活路。
3. 范围承诺有边界:明确写清楚"做什么、不做什么、什么算验收通过"。最怕的是"我们要做一个智能客服"这种无边界的承诺,交付时永远验收不完。

7.2 售前交付交接的强制清单

售前 FDE 拿单后、交付 FDE 进场前,必须做一次正式的售前交付交接会,产出一份《项目交接文档》,至少包含:

• 客户决策链图谱(谁拍板、谁反对、谁中立、各人关注点)
• 售前承诺清单(每一项承诺、对应的技术依据、达成的难度评估)
• 风险清单(售前阶段已识别但未暴露给客户的风险)
• 技术方案完整版(标书技术分册 + 内部详细设计)
• PoC 数据与代码(数据集、模型、代码仓库、复现步骤)
• 客户技术环境说明(网络、算力、账号、现有系统)
• 关键联系人(客户方、内部、第三方)

交接会要求售前 FDE、交付 FDE、项目经理、销售四方到场,逐项过交接文档,任何一方有疑问当场澄清。交接文档签字后,售前 FDE 才算正式脱手。

7.3 反模式:三类典型割裂

反模式	表现	后果
指标割裂	售前承诺准确率 95%,交付实测只有 75%	验收扯皮,尾款收不回,客户关系破裂
范围割裂	售前说"做一个 Agent",交付发现客户要 10 个场景	工期爆炸,人天超支,FDE 被加班拖垮
团队割裂	售前 FDE 拿单后调走,交付 FDE 完全新人	客户感觉被骗,知识断层,项目踩坑重来

优秀的售前 FDE 不只是赢标,而是让这一单可交付、可验收、可回款、可复购。赢标不等于赢客户,交付成功才是真正的赢。

八、售前 FDE 的核心能力

售前 FDE 不是技术最强的工程师,而是能快速理解客户、能设计方案、能讲明白方案的复合角色。这三项能力缺一不可。

8.1 快速理解客户(48 小时原则)

进客户现场 48 小时内,FDE 要能回答五个问题:客户是谁(行业、规模、战略)、痛点在哪(2–3 个量化痛点)、谁拍板(决策链)、对手是谁(在跟谁比)、客户为什么买(业务动机)。方法:会前功课(读客户年报、行业报告、招标历史)、现场访谈(业务、技术、决策者各聊一遍)、桌面研究(客户公开系统的现状评估)。48 小时之内给销售一份《客户简报》,这是售前工作的起点。

8.2 方案设计(架构 + 选型 + 取舍)

FDE 要在 1–2 周内拿出一套可落地的方案:不是 PPT 上的框图,而是有架构、有选型、有数据流、有风险、有工期的完整设计。核心是取舍能力——在精度/成本/工期/可维护性之间做权衡,并讲清楚为什么这么取舍。一个不会做取舍的 FDE,要么过度设计(客户嫌贵)、要么设计不足(交付不出来)。

8.3 讲方案(述标与高层汇报)

述标是 FDE 上台的高光时刻,通常 15–30 分钟,加 10–15 分钟答疑。讲方案的三个原则:结论先行(一句话说清"我们做什么、带来什么价值)、讲故事而非堆功能(用一个客户场景串起整个方案)、留答疑钩子(故意留一两个有深度的点,引评委提问,展示 FDE 的深度)。讲方案前必须彩排 3 次以上,把每页的过渡、每句金句、每个可能的提问都过一遍。

九、真实招标案例拆解

9.1 案例一:某省政务大模型项目(中标金额 2800 万,综合评分法)

• 客户:某省大数据局,建省级政务大模型平台。
• 评分结构:价格 15 分、技术 50 分、商务 20 分、服务 15 分。
• FDE 的关键动作:
  1. 立项前 8 个月进场,通过免费行业分享,把"私有化部署 + 信创适配"写进客户需求参数(本厂优势项)。
  2. 立项后做 6 周付费 PoC(80 万),指标对比:公文起草人工修改率从 60% 降至 25%,锁定客户内审报告。
  3. 标书技术分册 120 页,八段式结构,每个评分点逐条对应,配 4 张架构图、3 张选型矩阵、1 张甘特图。
  4. 述标 25 分钟,FDE 主讲,留"昇腾适配算子替换"作为答疑钩子,展示深度。
• 结果:技术分 47/50(最高),价格分第 3(略高于基准价),总分第 1 中标。
• 复盘:赢在售前早期介入 + PoC 锁单 + 技术分碾压,价格分让了 2 分也没影响。

9.2 案例二:某央企合同智能审查项目(废标,教训)

• 客户:某央企法务部,合同条款风险审查。
• 评分结构:价格 20 分、技术 45 分、商务 25 分、服务 10 分。
• FDE 的失误:
  1. 立项后才开始介入,客户需求参数已被对手引导(对手的"多模型路由"参数写死,FDE 不满足)。
  2. 没做 PoC,直接投标,技术方案空洞。
  3. 述标时 FDE 临时换人(原售前 FDE 调走),答疑环节答非所问。
• 结果:技术分 28/45(倒数第二),总分第 4,未中标。
• 复盘:输在介入太晚 + 没 PoC + 述标掉链子。这三个错误任何一个都足以输掉。

9.3 案例三:售前交付割裂的灾难(某市 12345 工单分类项目)

• 背景:售前 FDE 承诺"工单自动分类准确率 90%",交付 FDE 进场发现客户实际数据噪声大、标签体系混乱,实测只能到 78%。
• 后果:验收阶段客户拒收,要求退尾款 30%;售前 FDE 已离职,交付 FDE 背锅,项目延期 4 个月,FDE 团队连续加班 3 个月重训模型才勉强达到 85%。
• 教训:售前承诺必须留区间(88%–92%)而非绝对值;售前交付必须做交接;数据可行性论证必须真实,不能为拿单粉饰数据。

本专题小结

AI 项目的招投标与售前,是 FDE 价值最被低估、又最决定成败的阶段。本专题的核心要点:

1. FDE 在售前占 30%–40% 工时,是技术方案的真值来源,不是陪标的工程师。
2. 中国政企招投标是强流程游戏,五环节(立项、标书、投标、评标、中标)踩雷即废标,FDE 要全程参与。
3. AI 项目 95% 用综合评分法,技术分(40–60 分)是胜负手,FDE 的主战场。
4. 技术方案书有八段式模板(需求理解/架构/技术路线/实施/团队/案例/风险/服务),按评分点逐条响应。
5. 可行性论证四维度(技术/数据/合规/ROI),任一维度不可行项目就黄。
6. PoC 四要素(场景/指标/成功标准/时限),收费 PoC + 可审计数据,才是赢标工具。
7. 售前承诺三条红线(指标有依据、工期有余量、范围有边界)+ 售前交付强制交接,避免"售前吹牛、交付背锅"。
8. 售前 FDE 三能力(理解客户、方案设计、讲方案),48 小时原则 + 1–2 周方案 + 3 次彩排述标。
9. 不碰三类合规雷区(串通投标、商业贿赂、资质造假),这是 FDE 的职业底线。

一句话总结:售前 FDE 的使命不是赢标,而是让这一单可中标、可交付、可验收、可回款、可复购。

本专题来源

• 《中华人民共和国招标投标法》及《招标投标法实施条例》(国务院令第 613 号,2012 年施行)
• 《中华人民共和国政府采购法》及其实施条例(国务院令第 658 号)
• 财政部令第 87 号《政府采购货物和服务招标投标管理办法》(2017 年施行)第 53、55 条(评标方法与价格分权重规定)
• 财政部令第 94 号《政府采购质疑和投诉办法》
• 《政府采购需求管理办法》(财库〔2021〕22 号)
• 《生成式人工智能服务管理暂行办法》(国家网信办等七部门,2023 年)
• 《互联网信息服务深度合成管理规定》(国家网信办,2023 年)
• 《个人信息保护法》《数据安全法》《网络安全法》
• 等级保护 2.0 系列标准(GB/T 22239-2019)
• Palantir、Databricks、Anthropic、阿里云、华为云等厂商 FDE/解决方案架构师公开方法论与招聘材料
• 真实交付复盘:政务大模型、央国企合同审查、12345 工单分类等若干政企 AI 项目(项目名称已脱敏)
• 本 corpus 内相关专题:深度专题三十一(选型)、深度专题三十二(反模式)、深度专题四十(商业谈判与报价)、深度专题四十七(ROI)、深度专题五十二(中国市场特点)