KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
01. 客户要的真是一个 Agent 吗？ — keel 龙骨
客户提出：“给值班团队做一个自动诊断 Agent。”如果直接讨论模型、RAG 和多 Agent，你很可能在优化一个未经验证的解法。FDE 的第一步是找到真实决策和瓶颈。
客户提出：“给值班团队做一个自动诊断 Agent。”如果直接讨论模型、RAG 和多 Agent，你很可能在优化一个未经验证的解法。FDE 的第一步是找到真实决策和瓶颈。
先问流程，不先问功能
观察一次支付故障从告警到初步结论：谁收到告警、去哪些系统查什么、在哪一步等待、哪种例外需要人工判断、错误诊断会造成什么损失。访谈至少覆盖操作员、系统 owner、安全/合规和最终决策人；他们的成功定义通常不同。
告警 -> 识别租户/服务 -> 查 ticket/metrics/change
-> 判断证据是否充分 -> 建议下一步 -> 人工决定是否执行
Agent 只适合其中需要非结构化理解或动态工具选择的部分。固定顺序、强规则和高风险终态更适合 workflow、查询或人工控制。
Discovery Brief 的最低字段
| 字段 | 必须回答 |
|---|---|
| Problem | 当前谁在什么情境下损失什么时间/质量？ |
| Baseline | 现状有多少样本和测量，不靠印象？ |
| Stakeholders | 用户、owner、审批人和受影响者是谁？ |
| Constraints | 数据、权限、延迟、成本、监管和现有系统是什么？ |
| Non-goals | 本阶段明确不自动化什么？ |
| Decision owner | 谁能批准范围、数据访问和上线？ |
配套实验：
python courses/advanced/fde-customer-delivery/course/project/examples/01_discovery_and_metrics.py
先观察缺少 baseline 或 owner 时 DiscoveryGate 怎样拒绝项目进入 solution design。
故意制造失败
把目标写成“提高 AI 效率”，或把 stakeholder 只写成“客户”。这些字段无法决定数据、架构和验收，门禁必须失败。Discovery 不是追求文档长度，而是阻止未定义问题过早消耗工程资源。
本章交付物
一页 Discovery Brief，包含现状证据、三类 stakeholder、约束、非目标、决策 owner 和待验证假设。
自测
- 如果移除模型，问题是否仍然存在？
- 哪一步需要概率判断，哪一步必须确定？
- 谁承担错误诊断的后果？
- 哪条假设最可能让项目失去价值？