先说结论
FDE 式项目发现的结果应该是一份可执行的试点章程，而不是泛化需求清单。它至少要写清用户任务、当前基线、数据条件、方案边界、评测方法、风险和停止条件。
读完你会得到
- 用真实任务访谈替代“想要什么功能”的空泛提问。
- 用价值、可行性、风险三轴选择第一个试点。
- 在开发前写出成功条件和停止条件。
发现阶段最容易被压缩，但它决定后续是在解决真实问题，还是为一个想象中的需求搭建演示。下面的方法可以直接用于一次 60—90 分钟的业务访谈和后续整理。
先问最近一次真实任务，不先问想要什么 AI
访谈问题
- 触发
什么事件让任务开始？谁收到什么材料？
- 过程
实际做了哪些动作、判断和系统切换？
- 例外
什么情况最容易卡住、返工或必须升级给他人？
- 完成
谁确认结果可用？用什么标准确认？
- 影响
延迟、错误或不一致会造成什么业务后果？
本节依据： [1] OpenAI
用三轴矩阵选择试点，而不是只看“能不能做”
| 维度 | 低分表现 | 高分表现 | 需要的证据 |
|---|---|---|---|
| 业务价值 | 偶发、影响小 | 高频或影响关键结果 | 任务量、时间、返工、等待 |
| 实施可行性 | 输入混乱、系统封闭 | 数据可得、接口清晰、负责人在场 | 样例、权限、接口、维护人 |
| 风险可控 | 错误难发现且后果大 | 可审核、可撤回、可小范围运行 | 审核点、回滚、升级路径 |
一页试点章程应该写什么
- 目标用户与任务
写具体岗位和任务，不写“全公司提效”。
产出：一句用户任务陈述 - 范围与不做事项
明确本轮数据、系统、部门和功能边界。
产出：范围列表 - 成功标准
同时设置业务、质量、采用和风险指标。
产出：指标与数据来源 - 评测样例
覆盖典型、边界、失败和高风险任务。
产出：版本化评测集 - 停止条件
写出什么情况下暂停、降级或回到人工。
产出：停止与恢复规则
| 类型 | 问题 | 填写方式 |
|---|---|---|
| 业务 | 是否减少等待、重复输入或返工？ | 记录试点前后同口径数据 |
| 质量 | 关键字段和事实是否正确？ | 人工标注样例并按错误类型计数 |
| 采用 | 目标用户是否持续使用？ | 观察任务覆盖与主动反馈 |
| 风险 | 错误能否发现、拦截和恢复？ | 执行边界与对抗测试 |
发现阶段结束时，团队必须能回答六个问题
- 用户
谁会在什么时刻使用？
- 任务
系统具体帮助完成哪一步？
- 数据
输入来自哪里，谁有权访问和维护？
- 质量
什么算正确，谁来标注？
- 风险
哪些动作必须人工确认，失败如何恢复？
- 归属
试点结束后谁负责采用、运营和迭代？
常见问题
项目发现需要持续多久？
取决于流程和数据复杂度。边界清晰的单流程可以先用一次访谈加样例复核形成初版；跨部门、涉及权限或高风险动作的项目需要更多轮验证。关键不是固定天数，而是试点章程是否有证据。
没有历史数据还能做试点吗？
可以，但应先建立最小基线，例如抽取一批真实任务记录时间、错误类型和人工步骤。没有基线时只能验证可行性，不能可靠声称业务收益。
资料来源与核对说明
文章中的行业定义与技术方法尽量引用官方或标准组织资料；表格、清单和决策框架是基于这些资料形成的编辑性整理，不代表来源机构对本站服务的背书。
- Forward Deployed Engineer (FDE) 职位说明OpenAI
用于核对 FDE 的职责边界：需求发现、范围界定、方案设计、构建、上线与生产采用。
- Generative Artificial Intelligence ProfileNIST
用于识别生成式 AI 全生命周期的特有风险，并把风险管理纳入设计与运营。
- NIST AI RMF PlaybookNIST
用于组织治理、场景映射、测量和风险处置四类工作。
- Evaluation best practicesOpenAI Developers
用于建立任务级评测：定义目标、收集数据、设置指标、运行比较并持续评估。
带上流程、样例和目标，添加企业微信沟通。首次沟通先判断是否值得做，不承诺没有数据依据的结果。