# AIelsen FDE Academy · W01 FDE 职责与项目判断

面向 FDE 的中文详细讲义 · v2 · 2026-09-08

## 1. 学员身份与项目背景

这门课训练的是产品方 FDE：你所在的团队已经有一个 Agent 产品，现在需要把它部署到一家企业，使它能够读取正确的数据、理解业务口径，并在授权范围内完成工作。你的主要任务不是再造聊天界面，也不是把客户说的每句话都变成功能，而是找出标准产品与客户实际工作之间的差距，决定哪些通过配置解决，哪些需要开发，哪些应回到产品团队处理。

贯穿课程的项目是一个**虚构的连锁零售会员运营项目**。经营负责人希望改善会员复购，运营人员每周手工拼接 CRM 和 POS 报表，门店认为总部推荐的人群不准确，IT 担心接口和数据权限。你先交付能够查询、分群、解释建议的 Agent v1，再根据评估结果扩展为可以受控发券、打标签的 Agent v2。零售只是练习载体：后续还要说明同样的方法迁移到销售研究、知识服务和供应链时需要改动什么。

课程采用“已有产品 + 客户扩展”的架构约束，但本站没有附带第三方商业 Agent 平台。下载包是 Python 标准库教学脚手架；浏览器实验采用预设逻辑。它们用来验证数据和控制机制，不能证明真实模型的理解、规划或工具选择能力。接入真实模型、提交任务轨迹是工程作业的一部分。

## 2. FDE 的职责：对交付负责，也对产品边界负责

FDE 需要同时处理三个问题：这件事是否值得做；当前产品能否在客户约束下完成；这次交付能为下一次留下什么。只完成第一项容易停在咨询报告，只完成第二项容易变成没有业务目标的开发，只完成第三项则可能为了抽象而抽象，错过当期交付。

| 协作角色 | 通常负责什么 | FDE 必须与其明确的接口 |
|---|---|---|
| 售前与商务 | 商机、采购流程、商业承诺 | 演示能力是否等于可交付能力，哪些承诺需要验证 |
| 产品与研发 | 通用能力、版本和产品路线 | 客户扩展点、缺陷归属、补丁回收方式 |
| 业务负责人 | 业务目标、使用资源和验收 | 谁提供基线、谁评判建议质量、谁承担业务决策 |
| IT 与安全 | 系统接入、身份权限、运行要求 | 接口负责人、测试环境、数据流、上线窗口 |
| 客户成功与运维 | 采用、续用、故障和服务衔接 | 交接内容、响应边界、效果复盘周期 |

这些是协作分工，不是职业高低排序。外包工程师同样可能对结果负责，FDE 也可能采用项目制合同。判断工作的性质，要看是否参与问题定义、是否完成生产适配、是否将经验反馈为可复用能力，而不是看岗位名称。

## 3. 立项前必须回答的四个问题

**为什么现在做？** 要求客户提供最近一次具体事件：什么时候做了什么决定，依赖哪些信息，哪里出现延误或错误，造成了什么后果。“我们要拥抱 AI”不是可验收的项目目标。

**谁能决定？** 区分预算拥有者、采购签约者、业务验收者、实际使用者。职位高不代表了解实际流程，使用频繁也不代表有预算权。画出决策链，并约定哪些人需要参加后续评审。

**资源从哪里来？** 预算只是资源的一部分。还需要数据样本、接口权限、业务专家时间、测试账户、上线窗口和运行负责人。没有这些条件，即使合同已签，项目仍可能无法验证。

**怎样算成功？** 先写可观察的成功条件，不急着报一个百分比。例如：“运营人员能在授权门店范围内生成可解释的候选人群；候选人群与冻结口径重算一致；未满足条件时系统能够澄清或拒绝。”业务结果指标在第 3 周进一步定义，不能把系统可用等同于复购提升。

## 4. 用四项判断形成立项结论

| 判断项 | 需要的证据 | 典型阻断 | 下一步验证 |
|---|---|---|---|
| 技术可行性 | 样本、接口、运行环境、产品自检 | 核心数据无法获得或必要接口不可用 | 先验证一个最小读链路 |
| 业务价值 | 任务频次、现有耗时、决策损失 | 没有实际使用任务，只有展示需求 | 观察一次完整业务操作 |
| 客户适配 | 负责人、参与时间、使用场景 | 无人评判好坏，或决策角色长期缺席 | 约定评审机制再继续 |
| 交付风险 | 安全要求、范围、依赖、周期 | 未授权数据处理或无法控制的关键依赖 | 暂缓受影响部分并提出替代路径 |

不要将四项简单求平均。高业务价值不能抵消无数据权限；接口演示成功也不能抵消无人使用。结论分为继续、条件性继续、暂缓，并附触发条件、证据负责人和复查日期。“条件性继续”应明确允许进行的工作，例如只使用合成数据搭建适配器，而不是默认可以使用真实数据。

## 5. Fit/Gap：把需求转成产品与交付的工作清单

假设客户提出“识别沉默会员并自动发券”。应先拆成身份映射、指标计算、人群选择、建议生成、权限确认、发券连接器、结果回查等能力，再逐项判断，而不是把整句话归为一个“大需求”。

| 分类 | 本课示例 | 处理方式 |
|---|---|---|
| 标准支持 | 产品已有会话与工具注册接口 | 运行版本自检，不重复开发 |
| 配置支持 | 工具开关、模型配置、租户参数 | 配置入版本库，记录默认值与影响 |
| 客户适配 | CRM 的 legacy_member_id 映射 | 写适配器和数据契约测试 |
| 产品缺口 | 确认记录无法绑定具体动作参数 | 提出通用扩展接口及回归测试 |
| 本期不支持 | 未验证效果就要求全量无人值守发券 | 写入范围排除与后续条件 |

最容易犯的错误，是把客户 ID、优惠策略、内部字段直接写进产品核心。这样虽能快速演示，却使升级和第二个客户交付都变得困难。反过来，也不要为一个客户尚未验证的需求立即设计通用平台。先隔离适配，出现第二个样本后再检验抽象是否稳定。

## 6. 工程起点：版本自检与扩展目录

下面是建议的项目边界示意，不是下载包已经实现的商业产品目录。`core` 代表你选择或获授权使用的标准运行时，`tenant_extensions` 是本次作业主要修改范围。

```text
core/                      # 会话、模型适配、工具注册、基础 trace
tenant_extensions/retail/
  data_adapter.py          # 客户字段 → 标准数据契约
  ontology.json            # 对象、关系、动作与版本
  metrics.sql              # 可重算的业务指标
  tools.py                 # 分群、建议、受控动作
  policies.json            # 字段、范围、动作约束
evals/                     # 数据、工具、模型任务分开评估
delivery/                  # 范围、决策、上线、验收材料
```

先运行下载包的 `python -m unittest discover -s tests -v`。保存解释器版本、测试命令、退出码和关键结果；记录哪些测试验证机制，哪些能力尚未实现。真实项目还应分别自检数据库、模型凭据、工具调用和日志写入，但不要把密钥或真实数据写入运行记录。某项不可用时应报告明确状态，不要把异常吞掉后显示“环境正常”。

## 7. 案例研读：部署能力为什么成为独立能力

阅读 [Deployment Company 案例拆解](/academy/zh/cases/deployment/)。公开交付模式从业务诊断和少量优先工作流开始，让工程师进入客户环境，连接数据、工具与控制机制，再将现场经验反馈给产品。案例的关键问题是：标准模型能力如何变成每天有人使用、有人维护的工作系统？

本周按 FDE 角色进行推演：先重放一次运营任务，记录取数、身份匹配、建议形成与接手过程；再用失败样本区分配置缺口、客户适配和产品共性问题。对“同一会员出现两个身份”的合成需求，先交付冲突样本与映射规则，不急于扩大自动触达。

提交三项结果：一个优先工作流及不做清单、一张带证据的 Fit/Gap 表、一项最小验证。评审者应能看出继续投入需要什么条件，以及哪个问题应由客户数据负责人、FDE 或核心产品团队解决。

## 8. 必做作业、思考与验收

**必做**：选择三个候选任务，为每项记录一次具体失败事件；完成四项立项判断和五类 Fit/Gap；运行教学包并提交环境自检记录。最后用一页项目判断书说明选定哪项任务、为什么暂不做另外两项，以及尚未获得的资源。

**思考**：如果商务希望你在演示中称为“已经支持自动运营”，而你只验证了只读分析，如何准确表达当前能力，并提出能够推进商机的下一步？写一段可直接用于项目会议的回答，不只写“拒绝承诺”。

**进阶**：为一个标准产品编写自检脚本，将每项依赖输出为 `pass / fail / not_configured`，并说明一个失败会影响哪些能力。

**验收要求**：评审者应能从文档找到原始证据、继续条件和责任角色；Fit/Gap 至少包含一项客户适配和一项明确不承诺的能力；自检结果不得把脚本模拟标为真实模型验证；下一周访谈对象与待确认问题可由另一位同学直接执行。