企业官网建设流程全解析

不用怀疑，这是我被问得最多的问题，没有之一。FDE这个岗位在AI应用开发团队里越来越像一个标配角色，简单理解就是全栈的AI落地工程师：要接模型、调Prompt、搭RAG链路，也要跟业务方对需求、算ROI、盯线上效果。比“FDE是干什么的”更让人头疼的，是另一个更实际的问题：AI场景多到数不清，第一枪到底该打哪里？

这个问题的背后，是很多团队共同的卡点。算法Demo跑得飞起，业务方却不知道从哪里接入；老板一声令下“全员AI”，一个月过去没有一个场景真正上线；也有人连续做了三四个AI功能，最后全成了摆设。我做了几年AI应用开发，也带过FDE团队，这类情况见得太多了。所以这一篇我专门聊聊，从FDE的视角，怎么从一堆看似诱人的AI机会里，挑出第一个值得打的目标，并且把它真正落地，而不是停留在PR稿里。

1. FDE到底是什么角色，为什么选场景比写代码还难

1.1 FDE的工作边界

FDE在不同公司叫法不太一样，有的叫Forward Deployed Engineer，有的叫Full-stack Development Engineer，还有团队干脆叫AI应用工程师。名字不重要，核心职责是固定的：把模型能力、工程链路、业务需求三者焊在一起。这个角色不是纯算法工程师，因为要写大量工程代码；也不是传统后端，因为必须理解模型能力边界；更不是产品经理，但得能把业务需求翻译成技术方案。

很多团队一开始没有这个角色，算法同学做完一个Demo就丢给后端，后端来一句“这不就是个接口”，业务方却说“这结果不对啊”，最后项目就死在部门墙之间。后来大家才意识到，必须有人对一整条链路负责：需求拆解、数据盘点、模型选型、Prompt编写、RAG流程搭建、测试回归、上线观测，甚至还要给业务方做使用培训。这就是FDE的日常，也是为什么FDE人才报价一路上涨的原因之一。

1.2 场景选择为什么难

为什么我总说选场景比写代码难？因为写代码时边界是清晰的，需求定了，剩下是执行问题。但选场景时，你面对的是两股力量：一边是“AI什么都能干”的技术叙事，一边是“业务什么都想要”的盲目期待。两边都在把你往热点上推，如果没有自己的判断框架，很容易成为追热点大军里的一员。

这两年最常见的“第一枪”选择是智能客服机器人，逻辑很简单：ChatGPT都这么强了，客服肯定最先被替代。但真正做过的人都知道，客服数据格式混乱、知识库长期不更新、用户问题千奇百怪，机器人一上线就答非所问，最后变成人工客服的额外负担。这不是AI不行，是场景选错了。所以场景选择本质上是在做减法，该问的不是“AI能做什么”，而是“我们现在的数据、工程、组织能力，能承接住哪个场景”。

2. 选第一枪最容易踩的三个坑

2.1 只追热点，不追真实业务痛点

这个坑最普遍，也最隐蔽。看到GPT火了就做聊天机器人，看到Agent火了就做全自动办公助手，看到数字人火了就想做数字人主播。问题是，热点是别人的成功，不一定是你的场景。做第一枪之前，不如先花一周去业务部门蹲点，看看大家每天把时间都耗在什么地方。

我之前帮一个制造业客户选场景，技术团队一上来就提案要做智能排产Agent，理由是这个方向在行业会上很火。后来我们跟车间主管聊了半个小时，发现他们最痛的是每天要处理上百份设备点检记录，数据分散在各个Excel表里，月底汇总要加班三天才能完成。这个场景听起来一点也不酷，但价值清清楚楚，数据也齐，三个月就上线了。所以第一枪能不能响，不取决于场景多前沿，取决于它是不是真痛点。

2.2 想一口吃成胖子

第二种坑是“大而全”。常见表现是希望第一个项目就搭建一个大平台，支持所有业务线的AI需求。听起来很有战略高度，但实际执行起来，光统一权限、数据标准、接入流程就能消耗掉两三个月，业务价值却一点没出来。等平台终于建好了，业务方早就没耐心了，平台就成了空架子。

我给团队的建议一直是：第一枪一定是个单点场景，越小越好。最好是一个部门、一个岗位、一个高频动作。把这个点做到“业务方真的愿意每天用”，比做一个完美的平台有用得多。先赢下小场景，再谈平台化，这个顺序不能反。一旦反了，FDE就会陷入无休止的底层架构讨论里，根本没有机会验证AI的业务价值。

2.3 只盯着算法指标，忘了交付闭环

还有一个陷阱是技术自嗨。模型效果在测试集上刷到90%甚至更高，上下文召回率、幻觉率各种指标都很漂亮，但一上生产环境就露馅：接口延迟两秒，业务方觉得卡；答案没有引用来源，用户不敢信；系统出错了没有兜底机制，只能靠人肉应急。这些场景我都经历过，问题从来不出在模型能力上，而是出在交付闭环上。

AI落地的关键不是离线指标，而是交付闭环。闭环至少包含四件事：用户明确知道怎么用、系统在出错时有人工兜底、使用过程有日志和反馈收集、每周能根据反馈迭代模型或Prompt。没有闭环的AI功能，本质上是个技术Demo。FDE的第一枪，目标不是做出90分的模型，而是跑通一个有反馈、能迭代的60分系统，这句话值得反复强调。

3. 第一枪该用什么标准来选

踩坑的教训很容易懂，但真正到了决策的时候，团队还是会纠结。我后来给自己总结了三把尺子，每次选场景都拿它们过一遍：算不清业务价值的不做，数据和权限打不通的不做，错误没法兜底、反馈建不起来的慎做。

3.1 尺子一：业务价值算不算得清

第一把尺子是业务价值可量化。不是说所有AI项目都要立刻有财务回报，但至少半年内能看到“省了多少人天”或“缩短了多少处理时长”。如果业务方只能说“提升体验”“赋能业务”，但说不清具体提升在哪个数字上，这个场景就要打问号。

举个例子，“客服工单自动分类”就比“智能客服”好算得多：每天一千条工单，人工分类平均一条两分钟，自动分类后人工只做确认，单条耗时降到二十秒，一天能省下多少小时清清楚楚。第一枪选择价值可计算的场景，还有个隐藏的好处：后续汇报和争取资源的时候，不需要讲概念，直接甩数字，数据不会骗人，也不会被挑战。

3.2 尺子二：数据和权限能不能打通

第二把尺子最容易被忽视，就是数据与权限是否已经具备。很多AI场景在纸面上很美好，一落地就发现，核心业务数据散落在五个系统里，有的没有接口，有的没有权限，有的数据质量差到根本无法使用。这些都不是算法团队能单独解决的，最后往往变成漫长的跨部门协调。

所以选场景前，FDE一定要亲自做一遍数据盘点，而不是听业务方说“数据都有”。重点看三件事：数据是否结构化、更新频率多高、接口权限能否在一个月内打通。我见过太多项目死在“数据打通”这一步，所以我的原则很简单：数据访问有硬障碍的场景，再诱人也不作为第一枪。数据都摸不到的AI项目，做出来也是空中楼阁。

3.3 尺子三：错误容忍度与反馈闭环

第三把尺子是错误容忍度。AI一定会犯错，所以你得先想清楚，这个场景犯错之后会怎样。如果AI生成的合同条款写错了，可能带来法律纠纷；如果AI把报销单据分类分错，人工复核时一眼就能看出来，问题不大。第一枪尽量选择那些“错误可见、影响可控、人很容易修正”的场景。

同时还要看能不能建立反馈闭环。用户在看到AI回答之后，能不能点“有用/没用”？能不能吐完整日志？两个月后能不能根据这些反馈提升效果？没有反馈机制的场景，就像打靶没有报靶员，打中了也不知道，打偏了也不知道，迭代自然无从谈起。反馈闭环越短，团队的学习速度越快，这是硬道理。

为了方便判断，我常用下面这张表来辅助决策，你也可以直接拿去用：

4. 我的建议：先打“内部高频工具AI化”

三把尺子说完，可能还有人问：道理我懂了，但第一枪到底选哪个场景？我给大部分团队的建议都是：先打“内部高频工具AI化”，尤其是知识密集、流程重复的内部环节。这个方向不性感，但极大概率能成。

4.1 为什么从内部场景入手

第一枪选内部场景有几个天然优势。第一，内部用户就在身边，反馈链路极短，今天上线明天就能收到吐槽，迭代速度快到飞起。第二，数据权限相对容易解决，不会被客户方或安全合规卡几个月。第三，错误容忍度高，内部工具出错影响面小，员工天然知道AI只是辅助，会自己做判断。

相比之下，直接做对外客户功能，要牵扯用户体验、合规审查、服务等级协议，每个环节都是硬骨头。不是说不能做，而是不适合当第一枪。先用内部场景练出团队的方法论和工程能力，再去做外部产品，成功率会高很多。我自己带过的项目里，凡是第一枪就冲向客户侧的，一半以上都会因为业务方需求变化而返工。

4.2 一个可复制的样板：知识库问答助手

如果实在不知道从哪下手，我建议从“知识库问答助手”开始。几乎所有公司都有大量内部文档、SOP、历史工单，员工每天要花很多时间在内部系统里翻找答案。给这些内容加一个RAG问答入口，是最典型、最容易见效的AI应用场景。

以我做过的一个售后知识库问答助手为例。业务背景是售后工程师处理故障时，需要在几千篇技术文档里找解决方案，平均每单要花十五分钟翻资料。我们收集了历史工单和SOP文档，做向量化存储，接上大模型做检索增强问答，让工程师直接在对话框里提问，AI给出答案和相关的原文引用。上线之后，资料查找时间从十五分钟降到三分钟，工程师愿意天天用，因为确实省事。

这个场景完美符合三把尺子：省了多少时间可量化、内部文档权限好打通、AI答错了有引用可追溯，工程师能立刻判断对不对。所以我说，知识库问答是AI落地第一枪的最佳练习场，也是FDE最容易打出成绩的地方。

4.3 最小可行闭环的搭建步骤

具体怎么搭？我按我们自己的实践拆成六个步骤，你可以直接参照。

第一步，明确用户和痛点。别上来就做，先找三五个目标用户聊，确认他们最常查什么、现在卡在哪。我们当时是跟售后组长聊了三次，才锁定“故障处理中查解决方案”这个高频动作。

第二步，盘点并清洗数据。把文档、工单汇总到一个地方，剔除过期和重复内容，按章节切成合适的段落。这一步最耗时，但决定了RAG的上限，一定要舍得花时间。

第三步，搭建RAG原型。选一个开源嵌入模型和向量库，加上一个大模型做生成。不需要多复杂，先把链路跑通，能回答就算成功。

第四步，建立人工评测集。从真实问题里抽五十到一百条，标好标准答案，每次改动后在评测集上回归。这一步很多人会省，但它恰恰是后期迭代的定盘星，绝对不能省。

第五步，小范围试用。找一开始聊过的那几个用户，让他们试用并收集反馈。重点不是看效果多惊艳，而是看他们愿不愿意继续用。

第六步，迭代上线。根据反馈修Prompt、调检索参数、优化数据切分，每周定期发布新版本，同时记录使用量和用户反馈。跑一到两个月，这个场景的基本盘就稳了。

5. 落地中的四个关键工程环节

选定场景之后，真正的工程挑战才刚刚开始。FDE不是把模型接上就完事，还要在一堆约束里反复做取舍。下面这四个环节，是我认为最容易决定项目生死的地方。

5.1 模型选型与成本核算

模型选型的核心不是“哪个最强”，而是“哪个最合适”。先明确场景对效果、延迟、成本的要求。像知识库问答这种场景，答案可以接受几秒延迟，但对成本要敏感，因为用户每次提问都要跑一遍检索和生成，日活一高，成本就会线性上涨。

实践里我们通常先用效果最好的模型验证上限，比如大参数商业模型。如果效果达标，再尝试换成规模更小或按量计费更便宜的模型。这时候评测集就派上用场了，用同一批问题对比不同模型的得分和成本，选出性价比最优解。成本核算建议用“单次问答成本×日均调用量×30天”来算月成本，同时把人工维护成本也算进去，不然到后期很容易被财务挑战。

5.2 RAG链路的细节

知识库问答看起来简单，细节其实很磨人。第一个是数据切分：切太短，上下文信息不足；切太长，检索噪声变大。实践里要根据文档结构动态调整，表格类数据单独处理，段落按标题层级切，保证每段是一个语义完整的单元。

第二个是召回策略。刚开始做RAG时，我习惯只做向量相似度检索，后来发现很多专业术语和简称会匹配不上，于是增加了关键词召回和重排模型，先粗召回再精排，效果提升非常明显。当然，复杂度也随之上升，所以初期不要一上来就搞全套，先把基础链路跑通，等数据多了、问题多了再逐步加。

第三个是引用与提示。生成答案时，要强制要求模型给出对应文档来源，没有找到相关内容就直接说“没找到”，不要编。这个简单的约束能把幻觉影响降到最低，用户也能自己判断要不要相信。很多FDE觉得这是小事情，实际线上事故里，有一半都是因为缺少这个约束。

5.3 Agent什么时候上

再聊一下Agent。很多团队一谈起AI落地就想上Agent，觉得能自动完成任务才叫AI。我的观点是：第一枪尽量少用Agent，先用确定性更强的“检索+生成”模式。因为Agent引入了工具调用和多轮决策，链路变长之后，出错和不可控的概率成倍增加，排错成本也高。

等基础场景稳定了，再考虑把一些固定流程Agent化。比如知识库问答跑到一定阶段后，可以加一个“自动查库存”的工具调用，让模型在回答方案时顺便查一下备件是否有货。这种“单工具、单步骤”的轻量Agent是合理的下一步，而不是一上来就做一个能自主规划完成所有任务的超级助手。步子迈得太大，容易扯到线。

5.4 评测与观测

最后是评测与观测。很多人觉得上线即结束，其实上线才是刚开始。我们团队有个不成文的规定：任何AI功能上线，必须同时上线日志和评测机制。线上要记录每一次提问、回复、用户反馈，每周抽检一定比例的用户会话，结合人工评测集持续回归。

观测指标不用多，初期就看三个：使用量、用户主动反馈率、回答被“点没用”的比例。使用量掉了，说明用户不用，不是体验差就是价值不明确；点踩比例高了，说明答案质量在下降，需要排查数据或Prompt变化。这个机制看起来很基础，但大部分人做AI项目失败，不是因为模型不行，而是因为没有反馈渠道，变成了瞎子打靶。

6. 第一枪打完，怎么决定下一枪

一个场景跑通之后，团队容易进入两种极端状态：一种是特别兴奋，想把所有流程都AI化；另一种是觉得这个场景太小，想立刻冲向宏大叙事。这两种状态我都经历过，都踩过坑。所以最后再聊聊怎么收尾和迈出下一步。

6.1 复盘：什么算打成了

第一枪打没打成，不看模型分数，看三个信号。第一，是否有稳定的一批活跃用户，比如每周至少使用三次以上，而不是上线当天几个人尝鲜后就不来了。第二，业务方是否愿意投入时间共建，主动提需求、帮忙整理数据、愿意参加迭代评审。第三，是否沉淀出可复用的工程模板，比如数据清洗流程、评测集构建方法、Prompt迭代规范。

这三个信号里只要有两个成立，就说明这个场景的打法被验证了。这时候不要急着庆祝，赶紧把经验和材料固化下来，它们是下一枪的弹药。

6.2 从单点到平台：场景复制的方法论

第一个场景跑通后，我们不要马上做大平台，但要开始抽象共性。比如知识库问答这个能力，售后部门能用，运营部门也能用，人力资源部门同样能用。当一个通用能力被多个部门同时验证，再考虑把它产品化、平台化，就是顺理成章的事。

复制的核心是提炼“场景模板”。我们后来总结出一套方法：先找新场景，再套用已有模板，判断哪些环节可复用、哪些需要定制。比如数据清洗往往要重新做，但评测集构建和Prompt迭代流程可以直接复用。这样每拿下一个新场景，边际成本就会低很多，团队的交付速度也会明显加快。

6.3 给FDE的几句实在话

最后说几句心里话。做FDE，一定要有“搞定事情”的心态，别把自己定位成纯技术人员。第一枪选得好不好，表面看是技术问题，本质上是业务洞察、组织协同和工程能力的综合体现。你要懂业务，才能找到真痛点；你要会沟通，才能推动跨部门配合；你要能落地，才能让业务方真正用起来。

不要追求完美，先上线一个60分的功能，再靠真实反馈打磨到80分。不要自己闷头做，每周跟业务方过一遍使用数据，让用户告诉你下一步改什么。也不要把希望全押在一个大模型上，模型会迭代，但你对业务的理解和数据资产的积累，才是长期的护城河。

如果非得用一句话回答“AI场景那么多，第一枪该打哪里？”我的答案始终是：打那个你身边最痛、数据触手可及、错了也不怕的地方。听起来确实不够性感，但能保证你不浪费弹药。第一枪打准了，后面每一枪都会越打越顺。