10 步工作流闭环

优先选高战略客户、高 ROI、能形成行业模板、能暴露产品关键缺口、能推动模型或平台改进的场景。选错场景，后面九步都是沉没成本。a16z 提醒：如果现场交付不能形成 compounding advantage，FDE 很容易退化为低毛利服务。

要回答的不是"客户想要什么功能"，而是：真正的业务目标是什么、当前流程如何运转、哪个环节最慢最贵最易错、谁是用户 / 买单者 / 系统 owner、数据在哪质量如何、失败成本与可接受风险、业务成功如何量化。

判断哪些用 LLM、哪些必须靠规则 / 检索 / 传统软件 / 数据清洗 / 流程改造；是否需要 RAG、fine-tuning、agent、human-in-the-loop；能否在客户现有系统集成；最小可上线版本是什么；哪些需求应拒绝、延后或转入产品路线图。FDE 的价值正是在模糊约束下做取舍，而非"客户说什么做什么"。

典型 AI FDE 架构横跨用户入口、身份权限（SSO / RBAC / 审计）、数据层、检索层（embedding / chunking / rerank / vector DB）、Agent 层（tool calling / planner / memory / state）、模型层（选择 / fallback / guardrail）、评估层、可观测性与部署层。

原型不是炫技，而是验证用户是否真需要、数据是否可用、模型是否达标、系统能否接入、成本与延迟是否可接受。它通常是 full-stack 的：前端、后端、模型调用、数据接入、权限、日志、反馈按钮一起做，并常常和客户工程师 side-by-side 在客户基础设施上写代码。

LLM 系统不是确定性系统，必须建评估体系：golden set、offline / online eval、人工复核，覆盖正确率、幻觉率、越权率、工具调用成功率。Google 要求 FDE 构建"what good looks like"的框架，让系统可被衡量与改进。Google Careers↗

从 demo 到 production 要处理鉴权与权限过滤、数据新鲜度、错误处理与 fallback、审计日志、安全合规、部署环境差异、成本控制、SLA / SLO、用户培训与线上响应。OpenAI 的政府 FDE 岗位直接要求 Azure / AWS / Kubernetes / Terraform 经验——这不是 notebook demo。

上线不等于价值产生。FDE 还要推动试点、培训、反馈收集、工作流调整、管理层汇报、指标复盘与扩大使用范围，对 adoption 与 impact 负责。

成熟组织最关键的动作：把一次性项目变成可复用模块、行业模板、连接器、eval harness、部署 playbook、产品需求与模型改进方向。这是 FDE 与外包工程师的分水岭。

场景验证成功后，向同客户更多部门扩展、同行业复制、打包成行业 solution、支持销售缩短销售周期、提升续约与 expansion——即 land and expand。