一、FDE 这个岗位到底是怎么回事

1.1 一句话说清楚 FDE

FDE 就是那个被派到客户现场、既懂技术又懂业务、能自己拍板做决策、把 AI 产品真正落地到客户业务里的人。

打个比方：你开了一家餐厅（AI 产品公司），菜谱（技术平台）有了，但每家分店（客户）的口味不一样、食材不一样、厨师水平不一样。FDE 就是那个被派到每家分店的大厨——他不是来教你怎么做菜的，他是来根据你店里的实际情况，把菜谱改一改、把流程调一调，让这道菜在你店里也能卖出去。而且他做完之后，还会把"这家店的改良方案"总结一下，告诉总部："你们菜谱里少了个步骤，下次补上。"

1.2 FDE 从哪来的

这个岗位最早是 Palantir 发明的。Palantir 是一家做大数据和 AI 的美国公司，他们发现一个问题：产品做得再好，到了客户现场总是水土不服。于是他们发明了一种工作方式——派工程师驻场，跟客户一起干活，现场解决问题。

Palantir 内部把 FDE 分成两个角色：

• Echo：偏业务，像侦察兵。驻在客户那里，搞清楚客户到底要什么、痛点在哪、关系怎么维护。你可以理解为一个"会写代码的产品经理"。
• Delta：偏技术，像特种兵。coding 能力强，现场快速做原型、部署调优、解决技术问题。你可以理解为一个"懂业务的程序员"。

他们配合的方式是：Echo 先搞清楚问题在哪，Delta 快速做原型验证，验证成功了就推广，推广过程中发现的共性问题再反馈给总部产品团队。

注意：国内这三家公司的 FDE 岗位，其实更偏 Delta 角色——要求你 coding 能力强，能独立做原型和交付。但同时你也要有 Echo 的能力——能跟客户聊业务、挖痛点。

1.3 三家公司的 FDE 有什么区别

简单来说：

1.4 FDE 最核心的 8 件事

1. 搭 Agent：用公司平台给客户设计 AI Agent 架构
2. 懂客户：深入客户业务，搞清楚 AI 能帮什么忙
3. 能拍板：在现场遇到问题不用等总部批准，自己就能做技术决策
4. 全流程负责：从需求调研到上线运营，从头跟到尾
5. 留资产：做完一个项目，至少留一个别家客户也能用的东西
6. 跨团队协作：跟 PM、BA、ETL 工程师、产品研发、客户成功经理一起干活
7. 搞数据：SQL 要熟，ETL 要会，知道怎么让数据"AI 友好"
8. Vibe Coding：用 AI 工具快速写代码、做原型、交付

二、核心知识点（每个都用人话讲明白）

2.1 AI Agent 到底是什么

大白话解释

传统软件就像自动售货机——你投币（输入），它按固定规则出货（输出），一切都在设计好的流程里。

Agent 更像是一个实习生——你给他一个目标（"帮我订一张明天去北京的火车票"），他自己去想该怎么做：先查余票，再比价格，然后下单，如果没票了还会换个方案。他不是按固定流程走的，而是根据情况自己规划。

当然，这个"实习生"有时候会犯傻，所以我们需要给他设规矩、给他工具、检查他的工作。

Agent 的五个零件

1. 感知：听懂用户在说什么。比如用户说"我想去北京玩三天"，Agent 要能提取出"目的地=北京、天数=3"。
2. 规划：想清楚该怎么做。比如先查景点，再排行程，最后算预算。
3. 记忆：记住之前聊过什么。比如用户说过"我不吃辣"，后面推荐餐厅就别推川菜馆。
4. 行动：调用工具干活。比如调用天气 API 查北京天气、调用订票系统买票。
5. 反思：做完之后检查一下对不对。比如发现行程里上午 9 点的景点还没开门，就重新调整。

手把手实例：TripPlan Agent 是怎么工作的

场景：一个外国游客说"我想下个月带家人来中国玩 5 天，预算 2 万人民币"

Step 1 — 感知（需求收集）
Agent 通过对话提取关键信息：
- 人数：一家三口（2 大 1 小）
- 时间：下个月 15-19 号
- 预算：2 万人民币
- 偏好：还没说，继续问

Agent 追问："您对住宿有什么要求？想看自然风光还是人文历史？"
用户说："想看长城和故宫，住得干净就行。"

Step 2 — 规划（行程生成）
Agent 开始规划：
- Day 1：到北京，入住酒店，逛王府井
- Day 2：长城一日游
- Day 3：故宫 + 天安门 + 景山
- Day 4：颐和园 + 圆明园
- Day 5：返程

同时调用后端工具查价格、查可用性。

Step 3 — 行动（工具调用）
Agent 通过 Function Calling 调了好几个接口：
- 查酒店价格 → 调酒店查询接口
- 查景点门票 → 调景点查询接口
- 查包车价格 → 调包车查询接口
- 算总价 → 调定价引擎

Step 4 — 反思（约束校验）
约束求解引擎检查：
- 时间有没有冲突？→ 没有
- 转场时间够不够？→ Day 3 故宫到景山步行 10 分钟，够
- 预算超没超？→ 总计 18500，没超

Step 5 — 输出
Agent 把行程方案和报价给用户，用户说"Day 4 能不能换成去胡同？"，Agent 重新调整，这就是迭代优化。

多 Agent 编排是什么意思

就是一个系统里有好几个"实习生"，各有各的特长，需要有人来分配任务。

五种常见的编排方式：

1. 路由模式：就像公司前台——来电了，前台判断是售前咨询转销售部，是技术问题转技术部，是投诉转客服部。一个"路由 Agent"根据用户意图把任务分给不同的专业 Agent。

2. 流水线模式：就像工厂流水线——第一步切菜，第二步炒菜，第三步装盘。前一个 Agent 的输出是后一个 Agent 的输入。

3. 主从模式：就像项目经理带团队——项目经理拆任务、分任务、收结果，团队成员各自干活。

4. 辩论模式：就像评审会——几个 Agent 各出各的方案，互相挑毛病，最后选最好的。

5. 层级模式：就像公司组织架构——总监管经理，经理管员工，一层一层往下。

我的 AI 客服用的是路由模式：用户消息进来，先过规则引擎（关键词匹配），匹配不上再让 LLM 判断意图，然后分给不同的 Agent 去处理。

Function Calling 怎么理解

Function Calling 就是给 LLM 装了一双手——它本来只会"说话"（生成文本），现在可以"做事"了（调用函数）。

类比：你打电话给客服，客服说"我帮您查一下订单状态"——她不是自己查的，她是转给后台系统查的，然后把结果告诉你。LLM 就是那个客服，Function Calling 就是她调用后台系统的能力。

手把手演示：

假设我们定义了一个查询天气的函数：

# 函数定义（告诉 LLM 有这个工具可用）
tools = [{
    "name": "get_weather",
    "description": "查询指定城市的天气",
    "parameters": {
        "city": {"type": "string", "description": "城市名"}
    }
}]

用户说："北京明天天气怎么样？"

LLM 的处理过程：
1. 理解用户意图 → 想查天气
2. 判断需要调用函数 → get_weather
3. 提取参数 → city="北京"
4. 生成函数调用 → get_weather(city="北京")
5. 系统执行函数，拿到结果 → "晴，25°C"
6. LLM 把结果组织成自然语言 → "北京明天天气晴朗，气温 25 度左右。"

关键点：LLM 自己不执行函数，它只是"决定调哪个函数、传什么参数"。真正执行的是你的代码。这就是为什么说"LLM 负责理解和创意，代码负责执行和安全"。

Eval 框架——怎么知道 Agent 干得好不好

Eval 就是给 Agent 打分。就像考试一样——你做完了题，总得有个标准来判断对不对。

为什么 Eval 很重要：Agent 不像传统软件，传统软件输入一样输出就一样，测试用例写好就行。Agent 的输出是不确定的，同样的输入可能给出不同的回答，所以需要一套评估体系来持续检查。

三种打分方式：

1. 人工打分：最准，但最慢最贵。适合关键场景的抽检。
2. 用 LLM 给 LLM 打分：让 GPT-4 来评估 GPT-3.5 的输出。快、便宜，但可能不准。
3. 自动化测试集：提前准备一批"标准答案"，跑一遍看 Agent 的输出跟标准答案差多少。

手把手实例：TripPlan 的 Eval 怎么做

我建了一个测试集，每个测试用例包含：
- 输入：用户需求（"3 天北京游，预算 5000"）
- 预期约束：时间不冲突、预算不超、景点真实存在

跑完之后看三个指标：
- 时间可行性：行程里有没有时间冲突？比如上午 9 点在长城，9 点半在故宫——不可能
- 预算合规性：总报价有没有超过用户预算？
- 资源可用性：推荐的景点是不是真的存在？酒店有没有在营业？

如果某个测试用例失败了，比如预算超了，我就去看是定价引擎算错了，还是 Agent 选了太贵的酒店，然后针对性修复。

2.2 RAG——怎么让 AI 知道你公司的事

大白话解释

LLM 就像一个很聪明但只读过课本的大学毕业生——他知识面很广，但不知道你公司内部的事。你问他"我们公司的退货政策是什么"，他不知道，因为他没看过你们公司的文档。

RAG 就是给他开了一扇门——在回答问题之前，先去你公司的知识库里搜一下相关内容，把搜到的内容当作参考材料喂给他，然后他再基于这些材料来回答。

类比：开卷考试。考试的时候你可以翻书，但答案还是你自己写的。RAG 就是让 AI "翻书"——先检索相关资料，再基于资料回答。

RAG 的完整流程

想象你在图书馆查资料：

1. 文档分块：把一本厚书拆成一页一页的（因为整本太厚搬不动）
2. 向量化：给每一页贴一个"内容标签"（数学上叫向量，其实就是一串数字，代表这页内容的"语义"）
3. 存储：把贴好标签的页面放进书架（向量数据库）
4. 检索：你提一个问题，系统拿你的问题也生成一个"标签"，然后在书架上找标签最接近的几页
5. 生成：把找到的几页内容连同你的问题一起给 LLM，让它基于这些内容回答

知识切片——怎么拆文档

这是 RAG 里最关键也最容易出问题的一步。拆得不好，检索效果就很差。

类比：切蛋糕。你不能切太大块（一口吃不下），也不能切太小块（看不出是什么蛋糕），更不能从中间横着切（把蛋糕上的字切断了）。

五种切法：

关键参数：
- chunk_size：每块多大。中文一般 256-512 个 token，英文可以大一点。太小了信息不够，太大了检索不精准。
- chunk_overlap：相邻两块重叠多少。一般设 chunk_size 的 10-20%。重叠是为了防止关键信息正好被切在两块之间。

手把手演示：给一个企业知识库做切片

假设客户给了一份 50 页的产品手册（Markdown 格式），我来设计切片策略：

Step 1：看文档结构
- 文档有明确的标题层级（# ## ###）
- 每个小节 1-3 页
- 包含 FAQ 部分

Step 2：选择切法
- 正文部分：按 Markdown 标题层级切（每个 ## 或 ### 一块）
- FAQ 部分：按 Q&A 对切（问题和答案不能分开）

Step 3：设参数
- chunk_size = 512
- chunk_overlap = 50

Step 4：跑一遍，看效果
- 检查有没有把一个完整步骤切成两半的
- 检查 FAQ 的 Q 和 A 有没有被分开
- 如果有问题，调整参数重跑

Step 5：加元数据
- 每个块加上来源（哪个文档）、章节（第几章）、更新时间
- 这样检索的时候可以按元数据过滤

Embedding——怎么把文字变成"标签"

Embedding 就是把一段文字变成一串数字（向量），这串数字代表了这段文字的"意思"。意思相近的文字，数字也相近。

类比：给每段文字一个"坐标"。就像地图上，北京和天津的坐标离得近（都是北方城市），北京和广州的坐标离得远。Embedding 做的就是给文字在"语义空间"里标坐标。

选模型：
- BGE：中文效果好，开源免费，可以自己部署。我做的 AI 客服项目用的就是这个。
- OpenAI text-embedding-3：通用性强，英文好，但要花钱，数据得出境。
- Cohere：多语言好，也要花钱。

FDE 现场怎么选：客户数据不能出境就用 BGE，没这个限制就 OpenAI，省钱就 BGE。

向量数据库——存"标签"的仓库

类比：普通数据库是按"关键词"找东西（像翻字典），向量数据库是按"意思"找东西（像问一个懂你的人）。

检索优化——怎么搜得更准

基础检索往往不够好，需要加几层优化：

1. 混合检索：向量检索（按意思搜）+ 关键词检索（按字面搜）。就像你找人，既看名字又看长相，双重确认。

2. Rerank（重排序）：先粗搜召回一批结果，再用更精细的模型重新排序。就像先海选 100 人，再面试挑出最合适的 5 人。

3. Query 改写：用户的问题可能表述不清，先改写一下再搜。比如用户问"怎么退"，改写成"退货退款流程"再搜。

4. 元数据过滤：搜之前先缩小范围。比如用户问"2024 年的退货政策"，先过滤出 2024 年的文档，再在范围内搜。

手把手演示：AI 客服的 RAG 链路

Step 1：建 IngestionPipeline
  - 加载文档：PDF/Word/Markdown 都支持
  - 切片：SentenceSplitter，按句子边界切
  - 生成向量：BGE 模型
  - 存入：Qdrant 向量数据库

Step 2：检索
  - 用户提问 → BGE 生成问题向量 → Qdrant 检索 Top-10
  - 同时用 BM25 做关键词检索，取 Top-10
  - 合并去重，得到候选集

Step 3：Rerank
  - 用 Cross-Encoder 对候选集重新打分排序
  - 取 Top-5 作为最终上下文

Step 4：生成
  - 把 Top-5 内容 + 用户问题组装成 Prompt
  - 要求 LLM "只基于以下内容回答，如果找不到答案就说不知道"
  - 生成回答，标注引用来源

2.3 MCP——让 AI 能连上你的系统

大白话解释

MCP 就像是一个"万能插座"——你家里有各种电器（空调、电视、台灯），每个电器的插头不一样，你不可能给每个电器单独拉一条线。于是你装了一个排插（MCP），所有电器都插在排插上，统一管理。

在 AI 的场景里，"电器"就是各种外部系统（CRM、ERP、数据库、文件系统），"排插"就是 MCP 协议。LLM 通过 MCP 可以连接各种系统，不需要每个系统单独对接。

MCP 的三层结构

你的 AI 应用（MCP Host）
    ↓
MCP Client（翻译官，帮 Host 跟 Server 说话）
    ↓
MCP Server（适配器，把具体系统的接口翻译成 MCP 协议）
    ↓
外部系统（CRM、数据库、文件...）

类比：你去国外出差，你只会说中文，当地人只会说当地语言。你需要一个翻译（MCP Client）帮你沟通，翻译会找当地的对接人（MCP Server），对接人再跟当地人（外部系统）交流。

MCP 提供三种能力

1. Resources（数据）：让 AI 能读到你的数据。比如"读取客户 A 的订单记录"。
2. Tools（工具）：让 AI 能执行操作。比如"创建一个退款工单"。
3. Prompts（模板）：预设好的 Prompt 模板。比如"用这个模板来回答退货问题"。

MCP 和 Function Calling 有什么区别

简单说：Function Calling 是"定制接口"，MCP 是"标准接口"。就像手机充电口——以前每个品牌一个口（Function Calling），现在统一用 Type-C（MCP）。

手把手演示：用 MCP 连接一个 CRM 系统

Step 1：写 MCP Server
  - 定义一个工具：query_order(order_id)
  - 定义一个工具：create_refund(order_id, reason)
  - Server 启动后，自动暴露这些工具

Step 2：配置 MCP Client
  - 告诉 Client Server 的地址
  - Client 自动发现可用工具

Step 3：Agent 使用
  - 用户说"帮我查一下订单 12345 的状态"
  - Agent 判断需要调用工具 → query_order
  - MCP Client 转发给 MCP Server
  - Server 调 CRM API 拿到结果
  - 结果返回给 Agent
  - Agent 组织成自然语言回复用户

手把手演示：写一个 MCP Server 和 MCP Client

光讲概念不够，我们直接看代码。下面是一个"天气查询 MCP Server"的真实例子。注意：MCP 协议还在快速发展，不同语言 SDK 的 API 可能略有差异，实际开发请以官方最新文档为准。这里用的是 Python SDK 的常见写法，用来展示核心思想。

Step 1：写 MCP Server（Python）

# weather_server.py
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent

# 1. 创建 Server
server = Server("weather-service")

# 2. 定义天气工具
WEATHER_TOOL = Tool(
    name="get_weather",
    description="查询指定城市的天气信息",
    inputSchema={
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "城市名称，如 北京"},
            "date": {"type": "string", "description": "日期，如 2024-06-15"}
        },
        "required": ["city"]
    }
)

# 3. 注册工具列表
@server.list_tools()
async def list_tools() -> list[Tool]:
    return [WEATHER_TOOL]

# 4. 处理工具调用
@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name != "get_weather":
        raise ValueError(f"未知工具: {name}")

    city = arguments.get("city", "")
    date = arguments.get("date", "today")

    # 实际项目中这里会调天气 API
    weather_data = {
        "北京": {"temp": "28°C", "condition": "晴", "humidity": "45%"},
        "上海": {"temp": "32°C", "condition": "多云", "humidity": "60%"},
    }
    info = weather_data.get(city, {"temp": "N/A", "condition": "未知"})

    return [
        TextContent(
            type="text",
            text=f"城市：{city}，日期：{date}，温度：{info['temp']}，天气：{info['condition']}，湿度：{info.get('humidity', 'N/A')}"
        )
    ]

# 5. 启动 Server（stdio 模式）
if __name__ == "__main__":
    import asyncio
    asyncio.run(stdio_server(server))

Step 2：写 MCP Client（Agent 端）

# agent_client.py
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def ask_weather(city: str):
    # 1. 配置 Server 启动参数
    server_params = StdioServerParameters(
        command="python",
        args=["weather_server.py"],
        env=None
    )

    # 2. 连接 MCP Server
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            # 初始化
            await session.initialize()

            # 3. 发现 Server 有哪些工具
            tools = await session.list_tools()
            print(f"可用工具: {[tool.name for tool in tools.tools]}")
            # 输出: 可用工具: ['get_weather']

            # 4. 调用工具
            result = await session.call_tool("get_weather", {
                "city": city,
                "date": "2024-06-15"
            })
            print(f"天气结果: {result.content[0].text}")
            # 输出: 城市：北京，日期：2024-06-15，温度：28°C...

# 运行
import asyncio
asyncio.run(ask_weather("北京"))

Step 3：Agent 怎么用这个 MCP Client

# 在 Agent 的 Function Calling 逻辑里
async def agent_handle_weather(user_query: str):
    # LLM 判断用户意图 → 需要查天气
    if "天气" in user_query:
        server_params = StdioServerParameters(
            command="python", args=["weather_server.py"]
        )
        async with stdio_client(server_params) as (read, write):
            async with ClientSession(read, write) as session:
                await session.initialize()
                weather = await session.call_tool("get_weather", {
                    "city": extract_city(user_query)
                })
                return weather.content[0].text

关键点：
- Server 和 Client 是独立进程，通过 stdio 或 HTTP/SSE 通信
- Server 必须实现 list_tools 和 call_tool 两个核心接口
- Client 先 list_tools() 发现能力，再 call_tool() 调用
- Agent 不需要知道天气 API 怎么调用，它只需要知道"有个 get_weather 工具"
- 天气 Server 可以换成 CRM Server、OA Server 等，Agent 代码不用改
- 重要提醒：MCP SDK API 更新较快，实际开发请以 MCP 官方文档 为准

2.4 Prompt 工程——怎么跟 AI 说话

大白话解释

Prompt 就是给 AI 的"指令"。同样的 AI，你问法不同，回答质量天差地别。就像你跟同事沟通——你说"帮我做个方案"，他可能给你一个随便的草稿；你说"帮我做个方案，针对 25-35 岁女性用户，预算 5 万以内，要包含执行时间表"，他给你的就靠谱多了。

五个写 Prompt 的原则

1. 说清楚要什么：别模糊。"总结这篇文章"不如"用 3 句话总结这篇文章的核心观点"。

2. 给结构：用分隔符把指令和内容分开。比如：
   ```
   请根据以下内容回答问题：

[内容]

问题：[问题]
```

3. 给例子：告诉 AI 你想要什么样的输出。比如：
   把以下句子翻译成英文： 例子：你好 → Hello 现在翻译：谢谢

4. 说清楚不要什么：比如"不要编造信息，找不到答案就说不知道"。

5. 让它一步步想：加上"请一步步思考"或"Let's think step by step"，AI 的推理能力会明显提升。

上下文工程是什么

上下文工程就是管理 AI 能"看到"的信息。AI 的"视野"（上下文窗口）是有限的，塞太多它会看不过来，塞太少它又不够用。

类比：你让一个新人写报告，给他 100 页参考资料他看不完，给他 1 页又不够。上下文工程就是挑出最相关的 10 页给他，不多不少刚刚好。

具体做法：
- 优先级排序：重要的信息放前面，次要的放后面
- 摘要压缩：太长的内容先压缩成摘要
- 动态选择：根据用户问题动态选择相关内容，不是一股脑全塞进去

SDD（Spec-Driven Development）是什么

SDD 就是"先写规格说明，再让 AI 写代码"。

类比：盖房子——你先画施工图（Spec），施工队（AI）按图施工。施工图画得越清楚，房子盖得越符合你的要求。

流程：
1. 把需求写成结构化的 Spec（规格说明）
2. 把 Spec 喂给 AI，让它生成代码
3. 人工审查代码，验证是否满足 Spec
4. 不满足就改 Spec 或改代码，迭代

好处：Spec 本身就是文档，不用额外写文档。而且 Spec 写清楚了，AI 生成的代码质量也更高。

Harness 工程是什么

Harness 就是 AI 应用的"脚手架"——把 Prompt 管理、模型路由、工具调用、错误处理、监控这些基础设施搭好，让 AI 应用像正规软件一样可维护、可观测。

类比：你不会每次写代码都从零开始搭项目框架吧？Harness 就是 AI 应用的项目框架。

2.5 Vibe Coding——用 AI 写代码

大白话解释

Vibe Coding 不是什么高深的东西，就是"用自然语言告诉 AI 你要什么，AI 帮你写代码，你来审查和拍板"。

类比：你是老板，AI 是你的秘书。你口述一封信的大意，秘书帮你写出来，你过目修改，最后你签字发出。决策权在你，执行在 AI。

我平时怎么用

1. 先想清楚要什么：在脑子里或纸上理清需求
2. 跟 AI 说清楚：打开 Cursor 或 Trae，用自然语言描述需求，把相关代码文件也提供给它
3. AI 生成代码：AI 给出代码草案
4. 我来审查：看逻辑对不对、有没有安全问题、性能行不行
5. 测试验证：跑一遍测试，有问题就让 AI 改
6. 迭代：改完再测，直到满意

三个关键原则

1. 架构决策必须人来：用什么数据库、怎么拆服务、安全策略怎么定——这些不能让 AI 拍板。AI 是执行者，不是决策者。

2. 小步快跑：别一次性让 AI 写一整个系统。拆成小任务，一次写一个模块，写完验证再写下一个。

3. 写测试：AI 写的代码必须用测试来验证。AI 不一定每次都对，测试是安全网。

手把手演示：用 Cursor 写一个 RAG 检索接口

Step 1：打开 Cursor，新建一个文件

Step 2：在 Cursor 的 Chat 里输入：
"帮我写一个 FastAPI 接口，接收用户问题，
调用 Qdrant 向量数据库检索相关文档，
把检索结果和问题一起发给 LLM 生成回答。
用 LlamaIndex，BGE 做 Embedding。"

Step 3：AI 生成代码草案，大概长这样：
- 一个 FastAPI router
- 一个检索函数
- 一个生成函数
- 一个组合接口

Step 4：我审查代码
- 检查：有没有做异常处理？→ 没有，加上
- 检查：有没有限流？→ 没有，加上
- 检查：Embedding 模型加载对不对？→ 对的
- 检查：检索参数合理吗？→ top_k=5，合理

Step 5：写测试
- 测试正常查询
- 测试空结果
- 测试超长问题

Step 6：跑测试，通过，提交代码

2.6 数据工程——怎么让数据"AI 友好"

AI Ready 数据是什么意思

就是让数据能被 AI "读懂"和"用好"。

类比：你有一堆食材（原始数据），但如果是冷冻的、没洗的、混在一起的（数据质量差），厨师（AI）做不出好菜。AI Ready 数据就是洗好、切好、分类放好的食材——厨师拿来就能用。

四个特征：

1. 说得清楚：每个字段都有明确的含义。比如 amt 这个字段名，AI 不知道是什么，改成 payment_amount 就清楚了。

2. 结构友好：数据结构别太深、太复杂。三层以上的嵌套，AI 理解起来就费劲了。

3. 方便检索：知识按主题组织，方便 RAG 检索。比如把"退货政策"相关的文档放一起，别散落在各处。

4. 质量过关：数据要准确、完整、及时。过时的数据比没有数据更可怕。

语义层 / Ontology 是什么

语义层：在原始数据上面加一层"翻译"，让用户和 AI 能用业务语言来查数据，而不是写 SQL。

类比：你不会 SQL，但你想查"上个月卖得最好的产品"。语义层就是把你这句话翻译成 SELECT product_name, SUM(quantity) FROM orders WHERE date >= '2024-05-01' GROUP BY product_name ORDER BY SUM(quantity) DESC LIMIT 1。

Ontology：定义一个领域里有哪些"东西"（实体）、每个"东西"有什么属性、东西之间有什么关系。

类比：电商领域的 Ontology：
- 实体：商品、订单、用户、店铺
- 属性：商品有名称、价格、库存；订单有金额、状态、时间
- 关系：用户"下单"订单，订单"包含"商品，商品"属于"店铺

有了 Ontology，AI 就不只是"查数据"了，而是"理解数据"——它知道商品和订单是什么关系，能做更智能的推理。

ETL 在 AI 项目里怎么用

ETL 就是"抽取-转换-加载"——把数据从各种地方搬过来，洗干净，放到该放的地方。

在 AI 项目里，ETL 的流程是：

1. 抽取：从客户的 CRM、文档库、数据库把数据拉出来
2. 清洗：去重、去噪、标准化。比如两个系统的客户名格式不一样，统一一下
3. 转换：把文档切成块（Chunking），把文本变成向量（Embedding）
4. 加载：向量存进 Qdrant，结构化数据存进 PostgreSQL
5. 治理：定期更新、监控数据质量、管理权限

手把手演示：给客户建一个知识库

Step 1：摸底
  - 客户有哪些数据源？→ CRM 系统、产品文档、FAQ、历史工单
  - 数据格式？→ CRM 是数据库，文档是 Word/PDF，FAQ 是 Excel
  - 数据量？→ 文档 200 份，FAQ 500 条，工单 10 万条

Step 2：抽取
  - CRM：写 SQL 导出
  - 文档：用 LlamaIndex 的加载器
  - FAQ：读 Excel
  - 工单：API 批量拉取

Step 3：清洗
  - 去重：同一份文档可能有多个版本，保留最新的
  - 去噪：去掉页眉页脚、水印、乱码
  - 标准化：统一日期格式、统一术语

Step 4：转换
  - 文档 → SentenceSplitter 切片 → BGE Embedding → 向量
  - FAQ → 按 Q&A 对切分 → BGE Embedding → 向量
  - 工单 → 按会话切分 → BGE Embedding → 向量

Step 5：加载
  - 向量 → Qdrant
  - 元数据（来源、时间、类别）→ Qdrant payload
  - 原始数据 → PostgreSQL 备份

Step 6：验证
  - 用 20 个测试问题跑一遍检索
  - 看召回率和准确率
  - 不好的调整切片策略或检索参数

2.7 Agent 幻觉控制——怎么让 AI 不乱说

大白话解释

"幻觉"就是 AI 一本正经地胡说八道。比如你问"公司的退货政策是什么"，它可能编出一个看起来很合理但实际不存在的政策。

类比：AI 就像一个特别想讨好你的实习生——你问它一个问题，它就算不知道，也会尽量给你一个"听起来像那么回事"的答案，而不是老实说"我不知道"。

为什么 Agent 比普通 LLM 更容易幻觉

普通 LLM 只回答一个问题，Agent 要多步推理、调用工具、组合信息——每一步都可能引入幻觉，而且会放大。一个工具返回了错误数据，Agent 把它当成事实接着推理，最终结果就歪了。

五种控制幻觉的方法

方法 1：严格约束输出格式

不给 LLM 自由发挥的空间。比如让 Agent 输出 JSON 而不是自然语言：

用户问："查一下订单 12345 的状态"
Agent 输出必须为 JSON：
{
  "order_id": "12345",
  "status": "已发货 | 待付款 | 已取消",
  "status_from": "CRM系统",
  "confidence": 0.95
}

如果输出不合法，直接 reject 重试。

方法 2：事实校验层（Grounding）

Agent 生成回答后，加一层校验——把回答里的每个"事实陈述"跟知识库对照一遍：

# 伪代码
def validate_agent_response(response, knowledge_base):
    facts = extract_facts(response)  # 提取回答中的事实陈述
    for fact in facts:
        if not knowledge_base.contains(fact):
            mark_as_potential_hallucination(fact)
    return report

方法 3：置信度阈值 + 拒绝回答

让 LLM 输出置信度，低于阈值就说"我不知道"：

response = llm.generate(prompt)
if response.confidence < 0.7:
    return "抱歉，我暂时无法确认这个信息，建议您联系人工客服确认。"

方法 4：强制引用来源

Prompt 里要求每条回答必须标注引用来源，没有来源的就不能说：

请基于以下知识库内容回答用户问题。每条回答必须标注引用来源。
如果知识库中没有相关信息，请说"我暂时无法回答这个问题"。
不要编造任何知识库中不存在的信息。

知识库：
[文档1] 退货政策：7天内可无理由退货，需保留原包装...
[文档2] 退款流程：退款将在3-5个工作日内到账...

用户问题：退货需要什么条件？

方法 5：人在回路（Human-in-the-Loop）

关键决策不让 Agent 自己做，必须人工确认：

• 金额超过 1000 元的操作 → 人工审批
• 涉及合同条款的回答 → 人工审核
• 新类型的问题（Agent 没见过）→ 转人工

手把手演示：给 TripPlan 加幻觉控制

Step 1：约束输出
  行程生成要求输出结构化 JSON，包含景点名称、时间、预算，
  每个字段都有明确的类型和范围约束。

Step 2：事实校验
  约束求解引擎自动检查：
  1. 景点名称是否在景点数据库中
  2. 时间安排是否冲突
  3. 预算是否在用户范围内
  任一检查不通过 → 打回重新生成

Step 3：置信度标注
  行程中每个推荐标注置信度：
  - 高置信度（>0.9）：热门景点，数据充分
  - 中置信度（0.7-0.9）：冷门景点，数据有限
  - 低置信度（<0.7）：不推荐，标注"信息有限，请自行核实"

Step 4：人工兜底
  首次使用的新用户 → 生成的行程先给人工审核
  用户投诉 → 该用户的后续行程都走人工审核

三、面试问答（像聊天一样准备）

3.1 岗位认知

Q1：你怎么理解 FDE？跟解决方案架构师有什么区别？

我觉得最大的区别在三个字——"扎进去"。

解决方案架构师更像画蓝图的人，他设计好方案，交给别人去落地。FDE 是自己画蓝图自己盖房子，从头到尾都在现场。

具体来说：
- SA 做完方案就走了，FDE 要一直待到上线运营
- SA 不用写代码，FDE 要写生产级代码
- SA 遇到问题要找总部批，FDE 在现场自己拍板
- SA 做完项目就完了，FDE 做完还要把经验沉淀下来给别人用

我创业这两年其实就是在做 FDE 的事——深入客户业务，独立做技术决策，现场交付，对业务结果负责。只是当时不叫 FDE 这个名字。

Q2：为什么从架构师转 FDE？

说实话，我做了 12 年技术架构，越来越觉得光做技术不够。技术做得再漂亮，如果对业务没有直接贡献，成就感就差那么一点。

FDE 最吸引我的就是"对客户业务结果负责"——你做的东西直接在客户那里产生价值，这个反馈是即时的、可感知的。我做 TripPlan 的时候，看到用户从"等 5 天才能拿到行程"变成"几分钟就拿到方案"，那种感觉跟做一个内部系统优化完全不一样。

另外，FDE 是 AI 时代的新物种，把 AI 能力真正落地到企业场景，这是未来几年最大的机会。我已经在 Agent、RAG、MCP 上有了实战经验，转 FDE 不是从零开始，而是把我已有的能力聚焦到这个方向上。

3.2 Agent 架构

Q3：讲讲你设计的 TripPlan Agent 架构

TripPlan 是给入境游客做的行程规划工具。以前旅行社人工排行程要 2-5 天，我们用 Agent 把这个时间压缩到几分钟。

整个架构我拆成了 9 个模块，核心是三个阶段：

第一阶段：收集需求。用户说"我想去北京玩 3 天"，Agent 通过对话把模糊的需求变成结构化信息——几个人、什么时候、预算多少、喜欢什么。

第二阶段：生成行程。Agent 通过 Function Calling 调后端接口查酒店、查景点、查交通，然后组合成行程方案，附带报价。

第三阶段：迭代优化。用户说"第二天太赶了"，Agent 重新调整。

这里有个关键设计——我坚持一个原则：LLM 负责理解和创意，代码负责价格、状态和资金安全。行程怎么排、怎么推荐景点，这些交给 LLM 发挥创意；但价格怎么算、订单状态怎么流转、支付怎么处理，这些必须用代码写死，不能让 LLM 碰。因为 LLM 会犯错，价格算错了就是真金白银的损失。

所以我还做了一个约束求解引擎，相当于给 Agent 加了一道"安检"——每次生成行程之后，自动检查时间有没有冲突、预算有没有超、景点是不是真的存在。检查不过关就打回去重新生成。

Q4：多 Agent 编排怎么做的？

我的 AI 客服系统用的是"规则引擎 + LLM 双层路由"的方式。

第一层是规则引擎，简单粗暴但快——用户消息里出现"退款"、"投诉"这种关键词，直接路由到对应的 Agent。这一层能处理大概 60% 的请求。

第二层是 LLM 判断，规则没命中的才走这层。LLM 看看用户到底想干什么，然后分给四个 Agent 之一：
- 知识问答 Agent：查知识库回答问题
- 插件调用 Agent：通过 MCP 调 CRM、OA 这些系统
- 人工转接 Agent：搞不定的转人工
- 闲聊 Agent：随便聊聊

这里有个关键设计——置信度阈值 + fallback。LLM 判断意图的时候会输出一个置信度，比如 0.85。我设了个阈值 0.7，低于这个值就不冒险，直接转人工。宁可多转几个给人工，也不能让 AI 答非所问。

Q5：Eval 框架怎么做的？

我在 TripPlan 项目里建了一套评估体系，从三个维度给 Agent 打分：

1. 时间可行性：行程里有没有时间冲突？比如 9 点在长城，9 点半在故宫——不可能。
2. 预算合规性：总报价有没有超过用户预算？分项报价准不准？
3. 资源可用性：推荐的景点是不是真的存在？酒店有没有在营业？

具体做法是建了一个测试用例集，每个用例包含输入需求和预期约束。跑完之后自动检查这三个维度，输出通过率。

除了自动化测试，我还会用 LLM-as-Judge——让 GPT-4 来评估行程的"合理性"和"创意性"，这是自动化测试覆盖不到的维度。

Eval 不是一次性的，要跟着业务一起迭代。每次改了 Prompt 或者换了模型，都要重跑一遍 Eval，确保没有退步。

3.3 RAG 与知识工程

Q6：RAG 链路怎么设计的？

我的 AI 客服系统用了 LlamaIndex 的 IngestionPipeline，整个链路是：

入库流程：
1. 加载文档——PDF、Word、Markdown 都支持
2. 切片——用 SentenceSplitter 按句子边界切，chunk_size 设 512，overlap 设 50
3. 生成向量——用 BGE 模型，中文效果好，还能本地部署
4. 存入 Qdrant——带上元数据（来源、章节、更新时间）

检索流程：
1. 用户提问 → BGE 生成问题向量
2. Qdrant 向量检索 Top-10 + BM25 关键词检索 Top-10
3. 合并去重 → Cross-Encoder Rerank → 取 Top-5
4. Top-5 内容 + 用户问题 → LLM 生成回答

生成控制：
- Prompt 里明确要求"只基于以下内容回答"
- 要求标注引用来源
- 找不到答案就说"我暂时无法回答这个问题"

这套方案在客户实际使用中，KB 问答命中率能做到 85% 以上。

Q7：知识切片策略怎么选？

这个没有标准答案，得看文档类型：

• FAQ 文档：按 Q&A 对切，问题和答案不能分开。这是最简单的。
• 产品手册（Markdown）：按标题层级切，每个 ## 或 ### 一块。保留结构很重要。
• 长篇政策文件：用 RecursiveCharacterTextSplitter，设 overlap 保留上下文。
• 对话记录：按会话切，一个完整对话放一块。

关键参数怎么调？我的经验是先跑一遍看效果，重点检查：
- 有没有把一个完整步骤切成两半的
- 有没有把 Q 和 A 分开的
- 检索结果里有没有明显不相关的

有问题就调 chunk_size 和 overlap，调完重跑，直到效果满意。这个过程没法偷懒，每个客户的知识库特性不一样，都得单独调。

3.4 客户交付

Q8：怎么介入客户业务？怎么判断哪些让 AI 做哪些让人做？

我的方法分四步：

第一步：画流程。跟客户业务方坐下来，把他们现在的工作流程从头到尾画出来。比如保险理赔：客户报案 → 客服登记 → 核保审核 → 定损 → 赔付。每一步花多少时间、多少人、出错率多少，都标出来。

第二步：找痛点。按"频次 × 耗时 × 出错率"排序，找出最值得 AI 化的环节。比如客服登记每天 500 单、每单 10 分钟、出错率 15%——这就是好切入点。

第三步：画边界。哪些 AI 能做、哪些必须人做。我的判断标准是：
- 错误成本低的让 AI 做：比如回答常见问题，答错了也就答错了，人工兜底就行
- 错误成本高的让人做：比如赔付金额审批，批错了就是真金白银
- 数据充足的让 AI 做：有足够历史数据训练和检索
- 需要创造性的让 AI 做，但加约束：比如生成行程方案，但必须过约束校验

第四步：小范围验证。先在一个小场景试，比如先只做 FAQ 问答，验证效果好了再扩大。

Q9：底座能力不够怎么办？

这是 FDE 最常遇到的情况，客户需求总是比产品能力跑得快。

我的做法是"绕过去 + 记下来"：

绕过去：底座不支持的功能，我自己写代码补上。比如底座的 RAG 效果不好，我就自建 LlamaIndex Pipeline + Qdrant，绕过底座直接做。但我会设计好接口，等底座能力补齐了能平滑切换回去。

记下来：把底座缺了什么、我怎么绕的、客户反馈怎么样，都结构化记录下来，反馈给产品团队。这不是抱怨，是"现场情报"——产品团队需要知道真实客户场景里缺什么。

比如我做 AI 客服的时候，底座不支持 MCP，我就用 Function Calling + 适配层先顶着，同时把"MCP 支持是客户刚需"这个信息反馈给产品团队。后来底座补了 MCP，我就平滑切换过去了。

3.5 数据工程

Q10：SQL 和数据工程能力怎么样？

SQL 是我的基本功，写了 12 年了。复杂查询、性能优化、分库分表都做过。

携程数据系统那会儿，我给 3500 个车站、3.6 亿种站站组合设计数据存储方案。当时的设计思路是：静态数据（站站之间的基础信息）用 from+to 做主键存一份，动态数据（某天某趟车的余票）用 from+to+date 存快照。这样静态数据不用重复存，动态数据按天覆盖，Redis 缓存资源省了 60%。

ETL 方面，AI 客服项目里我做了完整的知识库 ETL：从客户各系统抽取数据 → 清洗去重 → 切片 Embedding → 存入 Qdrant。这个过程让我对"数据质量怎么影响 AI 效果"有很深的体会——同样的 RAG 架构，数据洗得干不干净，效果差 30% 以上。

3.6 Vibe Coding

Q11：平时怎么用 AI 编程工具？

我日常用 Cursor 和 Trae，偶尔用 Claude Code。工作流大概是这样：

1. 先想清楚要做什么，在脑子里有个框架
2. 打开 Cursor，用自然语言描述需求，把相关文件加到上下文里
3. AI 生成代码草案
4. 我审查——重点看逻辑对不对、有没有安全问题、边界情况处理了没有
5. 写测试跑一遍
6. 有问题就让 AI 改，改完再测

有个原则我一直坚持：架构决策必须我来做。用什么数据库、怎么拆模块、安全策略怎么定——这些不能让 AI 拍板。AI 是很好的执行者，但它不理解业务上下文和长期演进的需要。

效率提升确实很明显。TripPlan 9 个核心模块，如果纯手写可能要 2-3 个月，借助 AI Coding 工具大概 1 个月就交付了。

3.7 场景设计

Q12：客户要做智能客服，你怎么设计？

我会分五步走：

第一步：摸底。搞清楚客户现在客服怎么做的——什么渠道接入、什么问题最多、人工成本多少、知识库有没有。

第二步：找切入点。按"高频 + 标准化"排序，先做最有价值的部分。比如 80% 的客服问题是常见问题，那就先做 KB 问答 Agent。

第三步：搭架构：
- 接入层：Web + 飞书/企微
- 路由层：规则引擎先过，没命中再让 LLM 判断
- Agent 层：KB 问答、插件调用、人工转接、闲聊四个 Agent
- 底层：RAG 链路 + MCP 连接客户系统 + 限流熔断

第四步：做 Eval。上线前建好评估集，上线后持续监控意图识别准确率、KB 命中率、人工转接率。

第五步：沉淀资产。做完之后把意图路由模板、RAG Pipeline 模板、Prompt 模板库、Eval 评估集模板都整理出来，下一个客户可以直接复用。

3.8 行为面试（Behavioral Interview）

行为面试在国际大厂面试中占比高达 50% 以上。核心套路是 STAR 法则：Situation（背景）、Task（任务）、Action（行动）、Result（结果）。面试官想通过你的过去行为，预测你未来会怎么表现。

Q13：讲一次你失败的经历，你从中学到了什么？

S：TripPlan 项目初期，我花了两周时间做了一个"全自动行程生成"——用户输入需求，Agent 一次性生成完整行程，中间不需要任何交互。

T：目标是让用户体感最流畅，不需要来回对话。

A：我做了 DDD 建模、9 个聚合、完整的状态机、Stripe 支付。上线后找了 10 个用户测试。

R：结果很差——用户普遍反馈"这不是我想要的"。原因很简单：用户的需求是模糊的，第一次说"3 天北京游"，Agent 自作主张安排了一堆博物馆，但用户其实想去胡同和美食街。没有中间对话确认，Agent 猜错了。

学到的：用户需求不是"问一次就确定的"，而是一个逐步澄清的过程。后来我改成了三阶段对话式工作流（收集需求 → 生成方案 → 迭代调整），用户满意度大幅提升。这件事让我深刻理解了"Agent 设计的核心不是技术多炫，而是交互设计"。

Q14：你跟同事/客户有过意见冲突吗？怎么解决的？

S：在 SGS 数字化项目中，我是一个"空降"的技术负责人。业务方负责人认为"数字化就是做个 App 把线下流程搬上去"，但我调研后发现，核心瓶颈不在 App，而在数据采集环节——实验室设备数据还是人工抄录，错误率 15%。

T：要让业务方接受"先做数据采集自动化，再做前端 App"的方案。但业务方已经跟老板承诺了"3 个月 App 上线"。

A：我没有直接反驳，而是做了三件事：
1. 花一周时间跟实验室操作员一起工作，拍下他们手工抄数据的场景，记录错误案例
2. 用两周做了一个数据采集的快速原型，让操作员实测对比——手工 vs 自动
3. 拿着数据找业务方负责人，用事实说话：数据采集自动化能让错误率从 15% 降到 1%，省下的人力够 App 项目多用一倍

R：业务方最终同意调整优先级，先做数据采集，再做 App。虽然 App 上线晚了两个月，但整体效率提升了 40%，业务方后来在年终总结里专门感谢了我的方案。

学到的：跟业务方沟通，不要讲技术道理，要讲业务数据。用他们的语言说话，用事实而非观点说服人。

Q15：你是怎么处理多任务并行，当所有事情都很紧急的时候？

S：创业期间，我同时管三条线：TripPlan 的产品迭代、AI 客服的客户交付、投资人的尽调资料准备。三件事都号称"本周必须完成"。

T：必须做出取舍，否则三件事都做不好。

A：我的做法分三步：
1. 对齐优先级：跟各利益相关方确认"硬 deadline"——TripPlan 是因为有广告投放排期，必须周三上线；AI 客服客户周四验收，但可以分阶段交付；尽调资料周五给就行。
2. 拆解 + 委托：TripPlan 后端的迭代我亲自做（核心模块），前端调整交给另一个同学；AI 客服先交付 KB 问答模块（最小可用），插件调用模块下周再补；尽调资料把框架搭好，数据部分让合伙人填。
3. 预判风险：提前跟 AI 客服客户沟通"周四先交付 KB 问答，插件调用推迟一周"，客户同意了，避免最后一天出问题。

R：三件事都按时交付了。TripPlan 周三上线，AI 客服周四 KB 问答验收通过，尽调资料周五提交。

学到的：多任务并行的核心不是"更努力"，而是"更早沟通"和"更果断取舍"。提前跟利益相关方对齐预期，比最后一天道歉管用一百倍。

Q16：你遇到过最大的技术挑战是什么？怎么解决的？

S：携程订单系统从 100 万单/天扩容到 1000 万单/天。当时的数据存储方案是单表，MySQL 已经扛不住了。

T：在不影响线上业务的前提下，完成数据存储架构的改造。

A：我做了三步：
1. 分析瓶颈：定位到热数据（当天订单）和冷数据（历史订单）混在一起，导致查询扫全表，索引也失效了。
2. 设计新方案：热数据存 Redis（当天订单），温数据存 MySQL 分库分表（近 3 个月），冷数据归档到 HBase（3 个月以上）。查询路由根据订单时间自动选择数据源。
3. 灰度上线：先切 10% 流量验证，观察 48 小时无异常，再逐步切到 100%。整个切换过程线上零故障。

R：系统稳定支撑了 1000 万单/天，Redis 缓存资源节省了 60%，查询延迟从 500ms 降到 50ms。

学到的：大流量系统的核心不是"堆机器"，而是"数据分层"——让热数据离计算最近，冷数据离计算最远。

Q17：你有没有跟上级意见不同的情况？怎么处理的？

S：在创业公司，我跟合伙人就"是否应该自建 RAG 链路"产生了分歧。合伙人认为"直接用 LangChain 的默认方案就行，别浪费时间"，但我坚持要自建 LlamaIndex Pipeline。

T：我需要说服合伙人，自建不是"重复造轮子"，而是为了满足客户的实际需求。

A：我的做法是：
1. 用 LangChain 默认方案在客户数据上跑一遍，记录结果：召回率 60%，很多中文文档的切片被截断了
2. 用自建 LlamaIndex Pipeline（中文 SentenceSplitter + BGE Embedding）跑同一批数据：召回率 85%
3. 把两边的对比结果和成本分析（自建多花 3 天，但召回率提升 25%）摆到合伙人面前

R：合伙人同意了自建方案。后来这个自建 Pipeline 成了我们 AI 客服产品的核心竞争力之一，3 个客户复用了这套方案。

学到的：跟上级有分歧时，不要争"谁对谁错"，而是用数据说话。做一个最小版本的两边对比，让事实来做决策。

3.9 三家目标公司差异化回答要点

面试不同公司，同一个问题的回答侧重点应该不同。以下是三家公司各自的"关键话术"：

火山引擎（字节跳动）

关键词：底座能力、现场替代方案、反馈闭环

蚂蚁数科（蚂蚁集团）

关键词：金融场景、合规安全、可信 AI

腾讯云

关键词：MCP 生态、Connector 集成、快速交付

3.10 自我介绍模板

自我介绍是面试的开场，几乎每场面试都有。不要背简历，要背一个"钩子"——让面试官知道你是谁、为什么适合 FDE、你想聊什么。

一分钟版本（适合电话/视频初筛）

您好，我叫吴来，做了 12 年技术架构和 6 年技术管理，最近两年创业做 AI 产品。

这两年我亲手从 0 到 1 交付了两个 Agent 项目：一个是给入境游客做的智能行程规划 TripPlan，从需求收集到行程生成到 Stripe 支付，全链路跑通；另一个是企业 AI 客服，用 RAG + MCP + 多 Agent 编排解决客服问题。

我觉得自己最匹配 FDE 的地方有三个：一是我能独立完成 Agent 全生命周期交付，二是我有面对客户直接交付的经验，三是我能在现场做技术决策，不需要等总部指示。

接下来我可以详细讲讲 TripPlan 或者 AI 客服项目，看您对哪个更感兴趣。

两分钟版本（适合现场/终面）

您好，我叫吴来，可能我的背景跟传统 FDE 不太一样——我做了 12 年技术架构，6 年技术管理，最近两年创业做 AI 产品。

我之所以对 FDE 感兴趣，是因为我创业这两年做的事情，本质上就是 FDE 的工作：深入客户业务、独立做技术决策、现场交付、对业务结果负责。只是当时公司没有 FDE 这个title。

我手上有两个比较完整的 Agent 项目。第一个是 TripPlan，给入境游客做智能行程规划。原来旅行社人工排行程要 2-5 天，我们用 Agent 把它压缩到几分钟。我做了 DDD 建模、9 个核心模块、三阶段对话式工作流、Function Calling 调后端接口、约束求解引擎保证行程合理、11 状态订单状态机 + Stripe 支付，还建了一套 Eval 评估体系。

第二个是企业 AI 客服。用规则引擎 + LLM 双层路由做意图判断，四个 Agent 分别负责知识问答、插件调用、人工转接、闲聊。底层 RAG 用 LlamaIndex + Qdrant，向量检索 + BM25 混合检索 + Cross-Encoder Rerank，KB 问答命中率做到 85% 以上。

除了这两个项目，我还有携程订单系统从 100 万扩到 1000 万的经验，对数据工程、SQL、系统架构都有比较深的理解。

我觉得我匹配这个岗位主要有三点：一是有 Agent 全生命周期交付能力；二是能在现场独立做技术决策；三是会用 AI Coding 工具高效交付。这三个能力加在一起，能让我快速在客户现场产出价值。

您看您对哪个项目或者哪个能力更感兴趣？我可以往深了讲。

自我介绍Tips

• 开头别啰嗦：不要说"我叫吴来，来自哪里，毕业于哪里"，直接说你能做什么
• 数字比形容词有用："85% 命中率"比"效果很好"有说服力
• 留钩子：结尾主动问面试官想听什么，把话题控制权交给他
• 根据公司调整：面火山引擎多提"现场补位"，面蚂蚁多提"可信/安全"，面腾讯多提"MCP/Connector"

四、你的经历怎么跟 FDE 匹配

4.1 你的核心卖点

4.2 弱项怎么应对

弱项 1：金融/医疗/能源行业经验不足

应对：我做过交通（携程）、IoT（共享设备）、检测认证（SGS）、旅游（TripPlan）四个行业，说明我跨行业学习能力很强。FDE 要的不是行业专家，是能快速理解业务的人。而且我最早在中国金融在线干过，金融数据平台也接触过。

弱项 2：没有乙方交付/售前经验

应对：创业当技术合伙人，本质上就是乙方——客户要什么我做什么，对客户业务结果负责。SGS 数字化项目也是服务客户。这不就是乙方交付吗？

弱项 3：没用过 WorkBuddy/CodeBuddy

应对：底层能力是通用的——RAG、MCP、Agent 编排这些我都会。具体产品上手很快，我之前也没用过 Cursor，一周就熟练了。

4.3 三个 STAR 故事

故事 1：TripPlan
- 背景：入境游客行程规划靠人工，2-5 天才能出方案
- 任务：用 Agent 替代人工，实现分钟级出方案
- 行动：DDD 拆 9 模块、三阶段工作流、Function Calling + 约束求解、11 状态订单状态机 + Stripe 支付、建 Eval 评估集
- 结果：分钟级出方案，验证了"对话→决策→支付"Agent 商业闭环

故事 2：AI 客服
- 背景：企业客服成本高、响应慢
- 任务：搭 LLM + RAG 智能客服
- 行动：规则引擎 + LLM 双层路由、LlamaIndex + Qdrant RAG 链路、MCP 打通内部系统、四层限流 + 熔断
- 结果：多渠道接入，KB 问答命中率 85%+，沉淀可复用模板

故事 3：携程订单重构
- 背景：老系统撑不住，日均 100 万订单要扩到 1000 万
- 任务：重构订单系统
- 行动：微服务拆 8 个子系统、分库分表 8 库 + 读写分离、状态机 + 消息队列解耦
- 结果：日均 100 万→1000 万+，可用性 99.99%

五、面试实战技巧

5.1 面试前必须做的事

1. 研究目标公司的产品：
   - 火山引擎：去体验豆包、扣子，知道互动助手/知识引擎/分析 Agent 是什么
   - 蚂蚁数科：看金融 AI 案例，了解保险/银行场景
   - 腾讯云：试试 WorkBuddy、CodeBuddy，理解 Skills 和 Connector

2. 准备三个项目的深度讲解：TripPlan、AI 客服、携程订单。每个项目能画架构图、讲设计决策、说取舍。

3. 补几个技术热点：MCP 协议细节、LangGraph 多 Agent 编排、Rerank 策略、Eval 工具（LangSmith、Promptfoo）。

5.2 面试中怎么表现

1. 别当纯技术人：每讲一个技术点，都关联到业务价值。"我用了 Function Calling"不够，要说"我用了 Function Calling，这样 Agent 就能实时查价格，用户拿到的报价是准确的，不是 AI 编的"。

2. 讲取舍：主动说"当时有两个方案，我选了 A 而不是 B，因为……"。FDE 最看重的是判断力，不是技术能力。

3. 讲现场感：用"如果我在客户现场遇到这个问题"的视角来回答。比如"底座不支持 MCP，我会在现场先用 Function Calling 顶着，同时反馈给产品团队"。

4. 讲沉淀：每个项目最后都说"做完之后我沉淀了什么"。意图路由模板、RAG Pipeline 模板、Eval 评估集——这些都是可复用资产。

5.3 几个坑别踩

坑 1："你不是 FDE 出身"

别慌。FDE 是新岗位，没有谁天生就是 FDE。你的创业经历就是 FDE 实践——深入客户业务、独立技术决策、现场交付、对业务结果负责。这四条跟 FDE 的核心职责一模一样。

坑 2："你 AI 经验才 1-2 年"

FDE 要的不是 AI 算法专家，是能把 AI 落地到企业场景的人。你有 12 年企业级系统经验 + 2 个 Agent 商业项目落地，这恰恰是 FDE 最需要的复合能力。纯搞 AI 的人不懂企业业务，纯搞业务的人不会写代码，你两边都行。

坑 3："你年龄偏大"

12 年积累带来的判断力和沉淀能力，是 FDE 的核心价值。而且我用 Vibe Coding 工具，交付效率不比年轻人低。年龄不是劣势，是差异化优势。

5.4 反问环节

面试最后一般会问"你有什么想问的？"，别浪费这个机会。好的问题能体现你的思考深度。下面是 5 个推荐问题，以及每个问题"为什么这样问"：

问题 1：FDE 团队现在几个人？主要服务哪些行业的客户？

为什么这样问：了解团队规模和成熟度。如果团队只有 3-5 个人，说明还在早期，对个人综合能力要求高，但成长空间大。如果 20 人以上，说明团队成熟，分工细。同时通过行业分布判断自己经验是否匹配。

问题 2：底座产品的成熟度怎么样？哪些能力需要 FDE 在现场补？

为什么这样问：这直接关系到你日常工作的痛苦程度。如果底座很成熟，FDE 主要做配置和集成，工作相对轻松但技术成长有限。如果底座不成熟，FDE 要写大量代码补位，累但成长快。同时这个问题暗示你"愿意在现场补位"，面试官会觉得你务实。

问题 3：现场反馈到产品迭代的周期多长？FDE 对产品方向有多大影响力？

为什么这样问：了解 FDE 在这个公司的真正定位——是"派去执行的兵"还是"有话语权的合伙人"。如果反馈周期短、FDE 能影响产品方向，说明公司重视现场声音，FDE 的发展天花板高。

问题 4：一个 FDE 同时负责几个项目？典型的交付周期多久？

为什么这样问：了解实际工作负荷。如果一个人同时扛 5 个以上项目，说明公司把人当资源用，深度不够。如果 2-3 个项目，能深入做。交付周期反映了项目复杂度——3 个月以内的通常是标准产品交付，6 个月以上的涉及深度定制。

问题 5：团队在 Agent 架构、RAG、Eval 方面有什么最佳实践？

为什么这样问：展示你对技术的关注，同时试探团队的技术水平。如果面试官能说出具体的最佳实践，说明团队技术氛围好。如果面试官含糊其辞，说明团队可能还在摸索阶段，你来了可能要带人——这既是风险也是机会。

5.5 面试后

1. 发封感谢邮件，简短重申你对这个岗位的理解和热情
2. 如果面试中有没讲清楚的点，邮件里补充一下
3. 如果方便，提供一些脱敏的项目材料（架构图、Eval 报告之类的）

5.6 薪资谈判

薪资谈判是个敏感话题，但有几个原则能让结果更好。

原则 1：让对方先报价

面试官问"你的期望薪资是多少？"时，尽量让对方先出牌。你可以说：

"我更看重的是这个岗位能做的事情和成长空间，薪资方面我相信贵公司对这个岗位有合理的预算，我想先了解一下你们的大致范围。"

如果对方坚持要你说，就报一个范围，下限是你真正能接受的，上限是你期望的。比如"50-65 万"。

原则 2：用"总包"谈，不只谈月薪

FDE 的薪资构成可能包含：基础月薪 + 年终奖 + 项目奖金 + 股票/期权 + 差旅补贴。谈判时把所有算进去：

"我理解贵司的薪资结构是基础月薪加年终加项目奖金。我目前的总包大概在 XX 万左右，我希望在这个基础上能有合理的增长。另外想了解一下项目奖金的计算方式，以及股票/期权部分。"

原则 3：强调你的价值，不是你的需求

不要说"我需要这个薪资是因为房贷压力大"——这不是对方关心的。应该说：

"我能独立交付 Agent 全链路，从 RAG 到 MCP 到 Eval 都不需要等底座。TripPlan 我从 0 到 1 三个月交付，AI 客服 KB 命中率 85%+。这种能力在市场上对标的是高级 FDE 或 FDE Lead 的定位。"

原则 4：留有余地

如果对方给的报价低于预期，不要说"太低了"，而是说：

"这个数字比我预期的要低一些。我理解可能有预算约束，但以我的经验和能力，我期望在 XX 万左右。我们可以再讨论一下吗？或者是否可以在其他方面做调整，比如股票或项目奖金？"

原则 5：三家目标公司薪资参考

注意：以上为市场参考范围，实际薪资受级别、经验、面试表现影响。

六、面试前速查清单

面试前 30 分钟过一遍这个清单：

• [ ] 能用一句话说清楚 FDE 是什么
• [ ] 能讲清楚 Palantir 的 Echo/Delta 模型
• [ ] 能画出 TripPlan 的 Agent 架构图
• [ ] 能画出 AI 客服的多 Agent 编排图
• [ ] 能讲 RAG 的完整链路（从文档加载到生成回答）
• [ ] 能讲 MCP 的三层结构和三种能力
• [ ] 能讲 Function Calling 的流程
• [ ] 能讲 Eval 的三个维度和三种方法
• [ ] 能讲知识切片的五种策略和关键参数
• [ ] 能讲"AI 做 vs 人做"的判断标准
• [ ] 能讲底座能力不足时的应对策略
• [ ] 能讲 Vibe Coding 的三个原则
• [ ] 能讲 AI Ready 数据的四个特征
• [ ] 准备好三个 STAR 故事
• [ ] 准备好反问环节的问题

七、深度自测题

面试官可能会追问的深度问题，提前自测一下：

题 1：Agent 的幻觉问题你怎么解决？

考察点：是否真正在实战中遇到过幻觉，还是只看了理论。

自测标准：至少能说出 3 种方法，每种方法要有具体实现细节（不是"加个校验"这种空话）。

参考答案要点：约束输出格式（JSON Schema）、事实校验层（Grounding）、置信度阈值 + 拒绝回答、强制引用来源、人在回路（Human-in-the-Loop）。详见 2.7 节。

题 2：RAG 检索延迟怎么优化？如果检索一次要 2 秒，用户等不了怎么办？

考察点：实战经验，是否做过性能优化。

自测标准：能说出至少 2 种优化手段，并且能解释原理。

参考答案要点：
- 换更快的 Embedding 模型（如 BGE-small，精度稍降但速度翻倍）
- 给 Qdrant 加索引参数优化（HNSW 的 m 和 ef_construct 调参）
- 向量检索 + 关键词检索并行，而不是串行
- 高频问题做缓存，命中缓存直接返回，跳过检索
- 异步预加载：用户还在打字时就预检索

题 3：如果客户数据只有 100 条，RAG 怎么做？

考察点：小数据场景的应变能力，不是所有客户都有海量数据。

自测标准：能说出小数据场景的特殊策略。

参考答案要点：
- 100 条数据，向量检索的意义不大，直接用关键词匹配就够了
- 把每条数据写成"一问一答"对，人工扩充到 300-500 条
- 用 LLM 做数据增强：让 LLM 为每条数据生成 3-5 个变体问题
- 小数据场景下，更重要的是 Prompt 质量——把 100 条数据直接放在 System Prompt 里，比 RAG 检索效果更好
- 如果客户愿意，快速积累用户真实提问，一个月就能把 100 条扩充到 500 条

题 4：你怎么保证 Agent 生成的代码是安全的？

考察点：安全意识，FDE 在客户现场不能引入安全风险。

自测标准：能说出至少 3 种安全措施。

参考答案要点：
- 代码审查：AI 生成的代码必须人工审查，重点看 SQL 注入、XSS、敏感信息泄露
- 沙箱执行：Agent 生成的代码先在沙箱环境跑，验证无副作用再上线
- 权限最小化：Agent 调用的工具/API 只给最小权限，不能给 root
- 输入校验：所有用户输入和白名单校验，防止 Prompt Injection
- 审计日志：Agent 的每次操作都记录，方便追溯

题 5：如果一个客户跟你说"你们的产品太差了，我要退订"，你怎么处理？

考察点：客户管理能力，情绪处理和问题解决。

自测标准：能展示出"先处理情绪，再处理问题"的思路。

参考答案要点：
1. 先倾听：不要解释、不要辩解，让客户把话说完。客户说"太差了"的时候，他需要的是被理解，不是被说服。
2. 确认问题：把客户说的复述一遍，确认你理解对了。"王总，我理解一下，您是说 XX 功能上线后效果不如预期，对吗？"
3. 给方案不给借口：不要解释"为什么没做好"，直接说"我们怎么解决"。"我们计划这周内做三件事：第一...第二...第三..."
4. 设定预期：诚实告诉客户能做什么、不能做什么、什么时候能做完。
5. 跟进闭环：解决后主动回访，确认客户满意。一次危机处理好了，客户关系反而会更牢固。

八、可准备的脱敏项目材料清单

面试中，如果你能现场展示一些项目材料，说服力会强很多。但不是所有材料都能带，要提前准备、脱敏处理。

8.1 哪些材料可以准备

8.2 脱敏原则

1. 客户名称一律替换：用"某航空公司""某检测机构"代替真实公司名
2. 具体数字做模糊处理：真实用户数改成"数万级""百万级"
3. API Key、数据库连接串、Token 全部删除或打码
4. 真实人名删除：客户联系人、合作同事的名字不要出现
5. 内部系统名替换：用"CRM 系统""订单系统"等通用名称

8.3 推荐准备的 5 张图

图 1：TripPlan Agent 架构图
- 包含：感知层、规划层、记忆层、行动层、反思层
- 标注 Function Calling、约束求解引擎、状态机、支付模块的位置

图 2：AI 客服多 Agent 编排图
- 包含：用户输入 → 规则引擎 → LLM 路由 → 4 个 Agent → 输出/转人工
- 标注置信度阈值和 fallback 机制

图 3：RAG Pipeline 流程图
- 包含：文档加载 → 切片 → Embedding → Qdrant → 检索 → Rerank → LLM 生成
- 标注混合检索和强制引用来源

图 4：MCP 连接客户系统架构图
- 包含：Agent → MCP Client → MCP Server（CRM/OA/ERP）→ 外部系统
- 展示一次 Function Calling 的完整链路

图 5：Eval 评估体系图
- 包含：测试用例集、自动化指标、LLM-as-Judge、人工抽检
- 标注三个维度：时间可行性、预算合规性、资源可用性

8.4 怎么展示

• 面试前：把这些材料整理到一个 PDF 里，存在手机里或提前发到面试官邮箱
• 面试中：当面试官问"能不能举个例子"时，主动说"我带了脱敏的架构图，要不要看一下？"
• 面试后：在感谢邮件里附上 1-2 张最相关的图，加深印象

注意：如果对方公司要求严格保密，就不要主动展示。先问一句"方便给您看一下我脱敏的项目材料吗？"，对方同意再展示。

版本：v3.1 | 2026-06-19 | 候选人：吴来