FDE的职责与交付证据

从一句需求开始

"员工总在群里问制度，能不能做个助手？顺便帮他们提交报修工单。"

这是本课程的虚构教学情境。先不要选模型，也不要开始画聊天界面。问答和建单是两种任务：前者要找到适用的制度，后者会改变业务状态。它们的资料、权限、完成标准和故障处理都不同。

FDE 是 Forward Deployed Engineer。不同公司对岗位的分工和译名不完全相同。本课程关注面向客户的 AI 应用交付：理解问题、设计并实现方案、验证效果，让接手者知道怎样使用和维护。岗位范围可参考 OpenAI FDE 职责和 Anthropic FDE 职责；课程并非这些公司的官方培训。

谁负责什么

未知依赖要写成待确认。例如还没有报修制度，就不能在演示里承诺受理时限；还没有企业接口，只能说明模拟结果。业务认可也不等于获得真实数据和生产系统的接入许可。

模型回复不是完成凭证

比较下面两段模拟回复：

不合适："已经提交成功。"
当时证据：仅记录了请求发送，接口响应超时，没有工单编号。

合适："提交结果暂未确认。我会按本次动作标识核对状态；未核对前不会另建一张。"

超时描述的是系统没能及时拿到结果。它不能证明服务端没有写入，也不能证明写入成功。查到可靠工单编号或状态记录，才能更新完成说明。

几条问题答得好，只能说明这些例子表现不错。不能据此推断资料不足、字段缺失、越权或接口故障时也能正确处理。

动手：写第一张项目卡

这课不要求连接模型或企业接口。准备一个本地 Markdown 文件，使用合成资料，保存后续课节会继续修改的项目卡。

1. 把原需求拆成"制度咨询"与"报修建单"，分别写清输入和输出。
2. 写出第一期范围：授权制度问答、用户确认后的模拟建单。审批、付款、退款和删除不在范围内。
3. 列出依赖及来源。缺少制度、身份规则或接口说明的地方，标记待确认，不替客户补造规则。
4. 给任务写验收例子，至少包含正常、信息不足和禁止执行三类请求。
5. 为资料维护、异常处理和范围变更指定模拟角色，说明哪些决定需要谁确认。

可以从这份模板开始。它是拟定方案，不是已运行或已验收的记录：

项目：员工知识与服务工单助手（模拟）
用户及当前任务：
第一期做什么：
明确不做什么：
输入资料及来源：
允许的读取与写入：
用户看到的结果：
结果如何核对：
资料不足、无权限、结果未知时怎么办：
维护者与异常接手者：
待确认依赖：

检查你的产物

把"准确回答、自动建单、提高效率"换成别人能够判断的条件。例如"引用支持关键结论""缺少设备编号时追问""未确认时不写入""相同动作不产生第二张工单"。

找另一位读者，仅给他项目卡和测试请求，不额外解释。他应能判断系统该做什么、何时算完成、何时应停止或追问。无法判断的地方，就是下一次修改的重点。

本课自测检查你是否区分了输出、权限和完成证据。模块案例则让你把这些判断放回完整方案。读完或答对选择题，都不等于项目已通过真实交付验收。