前几天跟一个做AI项目的朋友聊天,他说了一件事:
他们团队做了一个很好的AI应用Demo,模型能力、界面交互都到位了,老板当场也表示认可。但散会之后,老板在微信群里单独问了一句:“这个东西,跟我们现在的系统到底是什么关系?”
他愣了几秒,发现这个问题其实没有认真想过。
这件事让人意识到一个关键点:AI项目推进过程中,到底有哪些问题是项目负责人必须能讲清楚的?不是讲给技术团队,而是讲给老板、客户和业务部门。
后来整理了一个清单,大概有12个问题。一个项目负责人如果能用自己的话把这12个问题回答出来,这个项目至少有很大概率不会停留在Demo阶段。
第一组:你到底在做什么
1. 什么叫AI原生?你的项目算不算?
不是简单指用了大模型,也不是传统系统外面套一个Chatbot。
可以这样理解:系统的关键业务能力,是不是由AI/Agent参与组织的,而不是完全依赖预先写死的规则、流程和页面。大模型负责理解、推理、生成;Agent负责识别任务、调用工具、组织流程、输出结果。如果这两件事在你的项目里没有发生,那可能还不是AI原生。
2. Agent和Chatbot有什么区别?
Chatbot主要回答问题,Agent要完成任务。
Agent会理解目标、调用工具、访问数据、组织流程,并在必要时请求人工确认。一个只会回答“你的库存是多少”的系统,和一个能主动识别缺料风险、推荐调拨方案、发起审批、通知相关人员的系统,中间差的就是Agent。
3. Agent和传统Workflow有什么区别?
传统Workflow的特点是:流程在执行前已经写死,系统按固定路径运行。
Agent的特点是:根据当前任务、上下文和工具结果,动态决定下一步做什么。
企业业务里变化场景很多——客户临时改计划、供应商突然延迟、系统库存和现场库存不一致——这些场景里,固定流程很难覆盖,Agent的价值就在这里。
第二组:你靠什么靠谱
4. 为什么需要本体(Ontology)?
大模型擅长“聪明”:理解自然语言、组织推理、生成解释。
但企业业务要求“靠谱”:不能编造事实、不能漏掉规则、不能查错数据、判断要可追溯、过程要可审计。
本体就是让AI靠谱的机制。它把业务对象、关系、规则、约束和数据映射结构化管理起来,让AI在可信的业务事实边界内推理。
一句话:大模型负责聪明,本体负责靠谱。
5. 本体和RAG有什么区别?
RAG解决“知识引用”问题——先从企业知识库中检索相关内容,再让大模型基于这些内容回答或推理。
本体解决“业务结构与规则”问题——定义业务对象是什么、有什么关系、遵守什么规则、在什么边界内行动。
两个都要。只有RAG,AI回答有依据但判断不靠谱;只有本体,AI懂业务但没有知识来源。
6. 为什么需要Data Agent?
没有Data Agent,AI只能基于固定SQL或静态数据回答。
有了Data Agent,AI才能根据当前问题动态判断:需要什么数据、去哪里查、如何查询、如何验证结果。
企业业务是变化的——客户临时修改预测、邮件里出现数据库尚未更新的信息、供应商通知延期——这些场景里,固定SQL覆盖不了,Data Agent的价值就出来了。
第三组:人放在什么位置
7. 为什么需要Human-in-the-loop?
企业AI不应追求所有动作完全自动化。关键动作需要人确认。
哪些地方需要人工确认?修改关键业务数据、写回业务系统、向客户或供应商发送正式通知、执行高成本方案、影响客户交付承诺的动作。
Human-in-the-loop的核心是:AI负责发现、分析、建议,人负责确认、授权和承担业务责任。
8. 现场问题谁来转化成平台能力?
这是一个很容易被忽略的角色。
技术团队知道怎么建系统,但不一定知道现场最痛的业务Case是什么。业务团队知道痛点,但不一定能说清楚AI应该怎么落地。
需要一个懂业务、懂技术边界、懂客户现场的人,负责把客户问题转化成Agent、Skill、数据规则和人机协同流程。这个角色在Palantir被称为FDE(Forward Deployed Engineer)。你未必需要照搬,但你的AI项目里,一定要有这样一个人。
第四组:你怎么证明价值
9. 为什么这不是传统外包?
传统外包交付功能,平台型AI项目沉淀能力。
外包的逻辑是:客户提需求,团队写代码,交付完结项。
平台型AI项目的逻辑是:通过高价值业务Case打穿场景,把知识、数据、Agent和流程沉淀为可复用、可验证、可进化的平台资产。目标不是长期堆人,而是形成越来越强的平台能力。
10. 为什么要按业务Case周迭代?
AI项目不确定性高,不能长时间闭门开发。
每周一个业务Case,可以让业务团队快速验证,形成真实反馈循环。这一个Case里沉淀的Agent能力、数据规则、异常处理逻辑,下一个Case可以直接复用。
迭代速度本身就是竞争壁垒。
11. 你的项目怎么商业化?
AI项目的商业价值不应该只按人月计算。
可以逐步转向:平台能力、Agent结果包、业务Case包、运营服务、长期订阅或使用费。
客户不为“用了AI”买单,而为经营结果买单——异常处理是否更快,成本是否改善,依赖个人经验的过程是否变成可追踪的系统。
12. 怎么复制到其他业务或客户?
不复制系统本身,而复制方法。
找高价值业务Case,绑定业务部门,打通数据和工作流,沉淀本体、Agent、Skill和治理机制。第二个客户不再从零开始,第三个更快。
复制的关键是:通用知识、业态知识和客户适配分层沉淀,而不是每个项目重新来过。
结尾
这12个问题,不是为了考倒谁,而是一个项目负责人在真实推进过程中一定会碰到的。
能讲清楚,不代表项目一定成功;但讲不清楚,项目很大概率会卡在某个地方——可能是老板不批预算,可能是客户不续约,可能是业务团队不用。
回头看开头那个朋友的故事。后来他又跟老板聊了一次,把上面这些问题里的几个关键判断讲了一遍。老板没有当场拍板,但说了一句话:“我终于大概知道你们在做什么了。”
这件事本身,可能比Demo更重要。
