FDE 和普通工程师最大的区别是什么？普通工程师做一个产品要 3 个月，FDE 给客户出 demo 只要 1 周，甚至 1 天。怎么做到的？ 核心就一句话：不要从零写。这篇讲 5 个快速搭建 FDE demo 的技巧，帮你从"两周出一个 demo"变成"一天出一个 demo"。

技巧 1：不要从零写，用现成模板改

最浪费时间的做法：从零开始写后端 + 前端 + 数据库。

很多工程师的习惯是：接到一个项目，先设计架构、再写数据库表、再写后端 API、再写前端页面。一套下来两周过去了。

FDE 不能这么干。你要做的是：用现成的模板改，不要从零写。

比如客户要做知识库问答，你不用从零搭一个 RAG 系统——你直接找一个开源的 RAG 模板（LangChain 官方就有很多示例），把客户的文档喂进去，把 UI 模板套上去，半天就能跑起来。

为什么可以这样？因为 FDE 的 demo 不是最终产品——它只是用来和客户对齐方向的。只要能跑通核心流程、客户能看到效果，就够了。完美不完美，后面再说。

记住：demo 阶段的目标是"快速验证想法"，不是"做一个完美系统"。从零写是产品经理的思路，不是 FDE 的思路。

技巧 2：前端用一键出界面的工具

第二个浪费时间的地方：自己写前端页面。

很多工程师写后端很熟练，但前端是短板——写个输入框、按钮、展示区，调样式调半天。两天过去了，后端还没开始写。

FDE 做 demo 不用自己写前端。有一堆现成的工具，一键就能出界面：

Streamlit：Python 写几行代码，自动出一个 Web 界面。输入框、按钮、文本展示、图表，全都有。不用写 HTML/CSS/JS。

Gradio：和 Streamlit 类似，更适合 AI 应用——输入一个问题，输出一段回答，配个上传文件的按钮，几行代码就搞定。

Chainlit：专门为聊天机器人设计的 UI，内置了对话界面，你只需要写后端逻辑就行。

为什么这些工具够用？因为 FDE 的 demo 不需要好看——能看就行。客户关心的是"这个东西能不能解决我的问题"，不是"界面好不好看"。你花两天调样式，不如花两天调后端逻辑。

技巧 3：数据库先用最简单的

第三个浪费时间的地方：上来就设计复杂的数据库。

工程师的习惯是：先想表结构、索引、关系，然后设计一个"完美"的数据库模型。一套下来又一天过去了。

demo 阶段完全不需要这样。你先用最简单的：

SQLite：一个文件就是一个数据库，不用装服务、不用配连接。Python 自带 sqlite3 库，直接就能用。

JSON 文件：数据量小的时候，直接存在 JSON 文件里，读写都简单。

甚至内存：demo 阶段数据本来就不多，直接存在内存里就行——程序重启数据就没了，但没关系，demo 又不需要持久化。

为什么可以这样？因为 demo 阶段的目标是验证流程，不是生产环境。数据量小、用户少、不需要并发——简单方案完全够用。等客户确认了方向、真的要做生产系统了，你再设计正式的数据库也不迟。

技巧 4：LLM 直接调 API，不要自己训

第四个浪费时间的地方：想自己微调模型。

很多工程师看到客户效果不好，第一反应是："我来微调一下模型，效果肯定更好。"然后花一周时间准备数据、训练模型、调参——结果一周过去了，demo 还没给客户看。

demo 阶段完全不需要自己训模型。你直接调 GPT-4、Claude、DeepSeek 的 API 就行。为什么？

第一，demo 阶段的目标是验证"这个方向行不行"，不是"效果好不好"。方向对了，效果后面可以慢慢优化。方向错了，你训得再好也没用。

第二，现在大模型 API 的效果已经很强了。大部分 demo 场景，直接调 API 的效果就够了。你微调的那点提升，客户根本感知不出来。

第三，自己训模型又费时间又费钱——数据准备、训练、评估，一套下来成本很高。demo 阶段花这个钱不值。

记住：demo 阶段用现成的 API，生产阶段再考虑要不要微调。

技巧 5：先跑通核心流程，再加功能

第五个浪费时间的地方：想一次性把所有功能都做了。

接到需求，你脑子里有一堆想法："要做问答、要做上传文件、要做历史记录、要做用户登录、要做权限管理……"想着想着，功能清单越列越长。

demo 阶段不能这样。你要做的是：先跑通核心流程，再加功能。

什么是核心流程？就是客户的"输入 → 处理 → 输出"。比如知识库问答：输入一个问题 → 从文档里检索 → 生成回答。这三步跑通了，demo 就成立了。其他功能（上传文件、历史记录、用户登录）全都是锦上添花。

为什么要这样？因为你越早让客户看到能跑的东西，越早能对齐方向。客户看完核心流程，他会告诉你"我要加这个""我要改那个"——这些才是他真正关心的功能。你自己脑补的那些功能，客户可能根本不需要。

记住：先跑通"最小可用版本"，再根据客户反馈加功能。不要一上来就做一个大而全的系统。

FDE 快速出 demo 的核心是什么？

总结一下：这 5 个技巧，本质上是同一个思路——快速验证想法，不要追求完美。

普通工程师的思路是：追求完美，慢慢做，做完了再展示。

FDE 的思路是：追求速度，快速出 demo → 收反馈 → 迭代。能跑就行，不要追求完美。

为什么 FDE 要这样？因为 FDE 的工作对象是"客户"，不是"产品"。客户的需求是模糊的、会变的——你只有快速让他看到实物，才能搞清楚他到底要什么。你做得越完美、越慢，你和客户之间的偏差就越大。

一天出一个 demo，不是因为 FDE 工程师效率高——是因为 FDE 的 demo 不需要完美。想清楚这一点，你出 demo 的速度自然就快了。

你做 demo 一般要多久？1 天 / 1 周 / 1 个月？评论区聊聊。