五个环节，
从「老板想做 AI」到「系统真的在跑」
这套方法不是流程图，是踩过坑之后留下的检查点。 每个环节都有明确产出，你可以随时检查进度，看得到中间结果。
找对问题：从「我想做个智能体」问到「你真正要解决的是哪两个小时」
老板说想做个 AI 智能体，因为销售效率太低。继续问：低在哪？是找不到客户，还是客户来了没人跟， 还是销售每天要花两小时整理资料？聊到最后往往发现，真正的问题是最后那个。
他要的是一个智能体，他需要的是一个能自动整理客户资料、生成跟进建议的助手。 这两件事看起来很像，实际上完全不一样。
划授权线：先定 AI 能决定什么，再谈怎么实现
上线前真正要签字的不是模型选型，是一条授权线：AI 可以判断到什么程度、可以执行到哪里、出问题谁负责。 从 L0 只读，到 L4 自主闭环，每一级的回滚成本和签字人都不一样。
这条线不会随着模型变强自动上移。它必须有人在具体业务现场，一条一条谈出来、写下来、签下去。
打通流程：真实企业不是干净的演示环境
数据可能散落在 Excel、CRM、钉钉、企微和各种老系统里。有的要权限，有的涉及客户隐私， 有的还要求人工审核。真正的 FDE 要解决的不是「让 AI 回答一个问题」，是「让 AI 接入真实业务流程」。
客户信息从哪来、聊天记录怎么获取、意向怎么识别、建议怎么推给销售、销售怎么确认和执行—— 这些环节要一个一个打通，缺一个就断链。
按业务指标验收：不看模型分数，看业务数字
线索有没有人及时处理、客户资料整理还花不花两小时、客服平均响应时间降了多少—— 这些都是实实在在的业务指标。同时还要检查 AI 有没有出错、员工有没有真正采用、流程能不能长期稳定运行。
沉淀与交接：让系统离开我们也能转
一个部门跑通了，把成功经验沉淀成可复用组件，复制到其他部门。 同时把使用文档、迭代方法、维护责任交到你的团队手上。
企业 AI 落地的最小单位，不是一个 AI 工具，而是一个能够跑通的岗位或者工作流。 交接的标准是：我们撤了，这个工作流还在转。
FDE 不是流程中的某一环，是贯穿全程的那个人
很多人把 FDE 理解成「懂技术的售前」，这是误解。差别在于对什么负责。
| 角色 | 关注点 | 介入时点 | 对什么负责 |
|---|---|---|---|
| 产品经理 | 需求定义与优先级 | 前期 | 需求准确 |
| 解决方案架构师 | 方案设计与选型 | 售前 / 规划 | 方案合理 |
| 研发工程师 | 功能实现 | 开发期 | 功能可用 |
| 数据科学家 | 模型效果 | 建模期 | 指标达标 |
| FDE | 端到端可用性 | 全程 | 业务结果 |
动手之前，先回答三个问题
这三个问题答不上来，说明项目还没准备好。这时最该做的不是选模型，是把问题定义清楚。
这个判断出错时，代价是什么？
代价高的场景，必须设计人工兜底，授权级别也要相应收紧。代价低的可以先放开跑。
谁在系统上线后负责维护？
如果没有明确的人，项目注定烂尾。维护责任要在启动时就落到具体岗位上。
用什么指标判断它「有用」？
说不清楚就无法验收。指标要能在上线前定下来，并且能复测。
关于交付本身
你们的做法核心是什么？
一句话：让 AI 在你的业务里真的跑起来，并且跑得住。拆开就是五个环节——找对问题、划授权线、打通流程、按业务指标验收、沉淀与交接。少任何一环，项目都会在某处卡住。
为什么一直强调「验收标准」？
因为 AI 项目的扯皮几乎都出在这里。开发方说「功能做完了」，业务方说「没解决问题」，双方都没说错，只是从来没定义过什么算成功。验收标准必须在写第一行代码之前就写下来。
项目中途发现方向不对怎么办？
停下来重新判断，而不是硬着头皮做完。我们的合同按阶段验收，每个阶段结束都有一次「继续 / 调整 / 终止」的确认。已经交付的部分归你，不用为没做的部分付费。
你们会不会为了接单把方案说得很好？
不会，也没必要。AI 落地这行口碑传得很快，做砸一个项目的损失远大于多接一单。不合适我们会直接说，并且尽量给一个替代建议。
交付之后出问题谁负责？
质保期内我们负责修。质保期后有两种选择：按次支持，或者签年度维护。但更推荐第三种——交接时把人教会，日常小问题你们自己就能处理。