企业 AI 项目的第一步，不是写代码

很多 AI 项目一开始就急着做原型。团队觉得，先做出来给客户看，客户自然会知道要什么。这个思路有一部分道理，因为 AI 很多能力确实需要通过可见的东西激发想象。但如果问题一开始就选错了，原型越快，浪费也越快。

企业 AI 项目的第一步，不是写代码，而是判断问题值不值得做。

一个值得做的问题，首先要具体。不是“提升客服效率”，而是“客服主管每天要从三个系统里手动汇总升级工单，平均耗时两小时，而且经常漏掉高优先级客户”。不是“提升销售转化”，而是“销售无法判断哪些线索应该当天跟进，导致高意向客户延迟响应”。

其次，价值要可衡量。AI 项目不能只说“更智能”“更高效”。要尽量说清楚：节省多少人时，减少多少错误，缩短多少周期，提升多少转化，降低多少成本。指标可以一开始不精确，但必须存在。没有指标，项目就会用功能完成度替代业务结果。

第三，数据要现实。很多 AI 项目死在数据环节。数据在哪，谁有权限，质量怎么样，能不能接入，是否涉及敏感信息，输出是否可审计，这些问题都要在开工前摸清。否则模型能力再强，也只能在假数据里表现很好。

第四，组织要有人推动。没有业务负责人，没有一线支持者，没有决策者背书，项目会变成“大家都不反对，但没人真正负责”。AI 系统会改变流程和责任，必须有人愿意推动这种改变。

FDE 型团队要敢于拒绝错误项目。场景太虚，先不做。数据拿不到，先不做。没有业务负责人，先不做。价值指标讲不清，先不做。拒绝不是放弃客户，而是把客户带回正确的起点。

更好的方式是把拒绝翻译成路线图：这个场景现在不适合做，因为缺数据和业务负责人；可以先做一个更小的流程，顺手把数据基础补齐；等指标跑出来后，再扩展到更大的场景。

做对问题，比把错问题做漂亮更重要。AI 项目的第一行代码之前，最值钱的工作是判断：这个问题是否值得用工程资源打穿。

一个实用的判断表可以这样设计。痛点维度：这个问题是否发生频繁，是否影响关键角色，是否有明确的业务后果。价值维度：解决后能节省多少时间、减少多少损失、提升多少收入或降低多少风险。可行性维度：数据是否可得，权限是否可开，流程是否能改，用户是否愿意试。推动力维度：谁是业务负责人，谁是一线支持者，谁能拍板扩展。

四个维度都强，适合优先做。痛点强但数据弱，先补数据基础。价值强但组织弱，先找内部支持者。可行性强但价值弱，适合作为练手项目，不适合作为战略项目。这个判断过程，比技术选型更早，也更决定项目成败。

FDE 型团队还要学会把大问题切成小战场。客户说“全公司知识管理”，可以先切到“新人入职常见制度问答”；客户说“智能客服”，可以先切到“退款政策自动判断”；客户说“销售增长”，可以先切到“高意向线索识别”。切口越小，价值越容易验证，也越容易让客户内部形成信心。

这一篇可以给出一个“开工前十问”：谁是用户？他现在怎么做？哪一步最痛？痛点发生频率多高？解决后价值怎么算？数据在哪里？谁能授权？结果错了谁负责？谁会推动上线？成功后能不能扩展？这十个问题问不清，项目就不应该急着开工。

很多团队害怕开工前问太多，担心客户觉得麻烦。但真正成熟的客户会理解，前期问题问得越清楚，后面返工越少。FDE 的专业性不在于什么都答应，而在于能帮客户把不成熟的想法变成可执行的项目。