FDE 职责与项目判断

1. 学员身份与项目背景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 案例拆解。公开交付模式从业务诊断和少量优先工作流开始，让工程师进入客户环境，连接数据、工具与控制机制，再将现场经验反馈给产品。案例的关键问题是：标准模型能力如何变成每天有人使用、有人维护的工作系统？

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

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

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

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

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

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

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