Applied AI Field Guide：FDE 如何从真实工作走到可接受结果
很多 AI 项目从模型开始：先选择一个热门模型，再设计 Agent，再寻找业务场景。Applied AI Field Guide 提供了另一条路径：先观察真实工作和接受标准，再选择能够安全完成任务的最小机制。
项目地址：github.com/davidahmann/applied-ai-field-guide
先问结果，不要先问模型
客户说“想要一个 AI Agent”，还不是可以开发的需求。FDE 需要继续追问：
- 哪个流程现在最慢或最容易错？
- 谁在处理，输入和输出是什么？
- 哪个结果值得改变？
- 谁来判断已经变好？
- 资料、权限和责任是否具备？
例如：
模糊目标：让财务用 AI 审核发票
可验证目标：
对低风险、规则明确的发票生成异常候选项，
每项都引用依据，高金额付款不得自动通过，
财务审核员可以在原系统中确认或驳回。
第二个目标才包含工作范围、边界和验收方式。
现场调研不是收集需求清单
真实流程通常分散在系统、表格、邮件、群聊和老员工经验里。Field Guide 建议找到真正的流程知情者，观察一个有代表性的案例从头到尾如何完成。
访谈和观察至少要记录：
- 谁触发流程；
- 输入来自哪里；
- 哪些步骤依赖人工判断；
- 哪些例外最常见；
- 处理结果写回哪里；
- 谁继续使用结果；
- 出错时谁负责补救。
管理层的流程图可以作为起点，但不能替代现场证据。
价值判断：不是所有自动化都值得做
一个场景即使可以自动化，也不一定值得投入。需要同时看：
- 频率；
- 单次耗时；
- 错误成本；
- 数据可得性；
- 流程稳定性；
- 采用难度；
- 权限和合规风险；
- 是否有明确负责人。
价值工程的重点不是预测一个精确的 ROI，而是把假设拆开：哪些数字已经测量，哪些来自客户陈述，哪些只是估算，最后由谁确认。
选择最小机制
Field Guide 建议同时考虑多种实现方式：
确定性规则
→ 数据库查询
→ 检索
→ 传统模型
→ 基础模型调用
→ 受约束的 Agent 工作流
→ 人工复核
并不是所有任务都需要 Agent。规则稳定、输入结构化的任务，可能用普通程序更可靠；需要理解非结构化资料的任务，可以先使用检索和生成；只有在需要跨步骤决策和工具调用时，才应该增加 Agent 的自主性。
核心原则是：
Tokens are an input. Autonomy is a design choice. Accepted outcomes are the product.
这里的重点不是某个英文口号，而是三条工程判断：Token 是成本输入，自主性是风险选择，真正交付的是被客户接受的结果。
垂直切片比宏大平台更适合第一阶段
第一阶段不宜建设“全公司的 AI 平台”。更稳妥的方式是选择一个端到端的垂直切片：
一个角色
+ 一个真实流程
+ 一组受控数据
+ 一个明确结果
+ 一个验收人
垂直切片应该覆盖从输入到结果的完整链路，而不是只做一个孤立的模型演示。这样才能暴露权限、数据质量、人工接管和系统写回等真实问题。
评测和用户验收必须同时存在
技术测试只能证明代码按照声明运行，不能证明客户愿意使用。一个可交付的 AI 功能至少需要两层验证：
工程验证
- 输入是否能正确解析；
- 工具是否按预期调用；
- 错误和超时如何处理；
- 权限是否生效；
- 日志和回滚是否可用。
业务验证
- 结果是否帮助用户完成工作；
- 是否减少返工；
- 是否符合业务规则；
- 用户是否愿意持续使用；
- 验收人是否同意投入生产。
二者缺一不可。测试通过不代表项目完成，用户喜欢 Demo 也不代表系统具备生产条件。
上线之后仍然是 FDE 的工作
生产运营阶段要确认：
- 谁维护资料和规则；
- 谁处理异常；
- 何时重新评测；
- 模型或供应商变化时如何回归；
- 客户不再需要时如何退休；
- 失败时如何切回人工流程。
一个没有运营负责人的 Agent，最终会变成没人敢用、没人敢改、也没人敢下线的遗留系统。
总结
Applied AI Field Guide 适合作为 FDE 的判断框架：从工作现场开始，用证据定义问题，用小切片验证价值，用验收标准约束实现，再把系统交给有责任的人运营。
它是一套公开方法论和教学资源，不是客户生产系统的认证标准。具体资料、示例代码和许可证请以 项目当前仓库 为准。