72 小时为客户做出第一个可用的 RAG Demo —— 一份 FDE 的实战清单
"3 天搞定一个 AI Demo"听上去像销售话术，但作为 Forward Deployed Engineer，这其实是一份可执行的清单。前提是你愿意接受：Demo 不是产品，Demo 是赌注；只有押对了，后面 4 周的 Pilot 才有意义。
过去两年我在日本和东南亚客户现场反复做过这件事：周一上午进客户公司开第一次会，周三下午就要拉一个 Demo 给对方的 C-level 看。第一次做心里发虚，做了几次以后我发现，72 小时其实够用——前提是你别把它当成"产品开发"，而是当成一次有结构的赌博。
这篇文章是我把这套打法整理成的清单，重点是 RAG 类问答 / 检索 Demo，但思路对绝大多数 LLM 落地场景都通用。
72 小时 PoC 的目标不是"产品"，是"赌注"
很多工程师第一次做 PoC 翻车，都翻在一个共同的认知偏差上：把 Demo 当成迷你产品。结果是 3 天里 60% 的时间在做认证、权限、UI 美化、Docker 部署，真正能让客户拍板的部分反而没时间打磨。
FDE 视角下的 72h Demo 只回答一个问题："在你这个业务里，LLM + 检索 + 你的数据，到底能不能解决你最头疼的那个场景？" 这个问题答得清楚，客户才会给你下一个 4 周。答不清楚，做得再花哨也白搭。
Day 0 · 进客户现场前的 5 个问题
我现在每次接到一个新客户，会在去现场前先把这 5 个问题答出来。能答出来的，72 小时基本稳；答不出来的，多半要花一周才能上手。
这些问题都是"业务问题"，不是"技术问题"。能在 Day 0 把它们答清楚，是 FDE 区别于普通工程师的核心能力。
Day 1 · 数据 + 检索骨架（不要碰 prompt）
第一天最容易跑偏的事，就是兴致勃勃地开始调 prompt。我自己的硬规则是：Day 1 不写一行 prompt，只解决"问题进来 → 找到对的内容"。因为 RAG 的 90% 翻车都不在生成端，在检索端。
这一天我会拿到一个数据切片（最少 50 条、最多 500 条），优先选客户最近一个月最高频的真实问题作为评测集，然后跑一遍最朴素的检索：
如果 Day 1 结束时 Recall@5 没到 70%，先别往下走，检索端的问题留到生成端再补救会非常痛苦。可以做的补救包括：加入元数据过滤、混合 BM25 + 向量、问题改写。
Day 2 · 把 RAG 串起来 + 准备 Demo Set
第二天才是 prompt + 生成 + 串通的工作。我通常按这个顺序：
Day 2 结束前留 2 小时，请客户对接人(不是决策方)远程看一遍 Demo，专门收集"觉得别扭"的地方。这些反馈在 Day 3 之前还来得及修。
Day 3 · 演示与"诚实的失败案例"
很多工程师演示时只敢演成功案例，怕失败被否掉。我的经验恰恰相反：主动演 1–2 个 Demo 答不好的真实案例，并解释为什么、以及 Pilot 阶段怎么解决。这件事在客户决策方眼里是巨大的加分项。
原因很简单：见过 PoC 的甲方都被吹翻过，他们最怕的是上线之后才发现 Demo 是精心挑过的。你主动展示"这一类问题我们今天还答不好，但我们知道为什么"，反而让对方相信你会真的把它做成。
演示节奏我习惯这样安排：
三个反复见过的翻车点
这几个坑我自己踩过，也见队友踩过。提前知道能少花 1 天。
Demo 演完之后真正重要的事
72h Demo 只是 FDE 工作的开始，不是结束。当晚我一定会做的两件事：
第一，写一份 1 页的 Decision Memo，记录 Demo 上跑通和没跑通的场景、推荐 Pilot 范围、所需资源、风险点。这份 memo 是和客户内部 sponsor 谈续约的弹药。
第二，把 Day 0–3 所有关键决定（为什么选这个分块大小、为什么放弃 BM25、为什么这个问题答不好）整理成 Architecture Decision Records。Pilot 阶段团队接手时，这份记录值千金。
FDE 这个角色让人着迷的地方就在这里：你既是工程师，也是销售，也是顾问，还是和客户一起把方案推向生产的合伙人。72 小时的 Demo 只是入场券——拿到入场券之后，真正的工作才开始。
如果你也在做类似的 FDE / Solutions Engineer 工作，或者正在客户现场为某个 RAG Demo 焦虑，欢迎邮件交流：shaoyanyan91@163.com