FDE怎么把业务现场拆成AI能执行的数据对象

企业做AI应用，最容易忽略的一步，其实不是选模型，也不是写提示词。

真正容易出问题的，是业务对象没拆清楚。

业务部门说，希望AI帮忙分析客户风险。

听起来很直接。

可客户风险到底从哪里来？

是客户最近没有跟进，还是商机阶段停滞太久？是合同快到期，还是回款延迟？是售后工单变多，还是关键联系人换了人？

这些问题如果没有拆开，AI拿到的就只是一句模糊任务：帮我判断客户有没有风险。

它当然可以生成一段话，而且看起来还挺像那么回事。但企业不能只看一段话，企业要知道这段判断依据来自哪些数据，下一步要触发什么动作，谁来确认，哪些结果要写回系统。

所以FDE前沿部署工程师进入企业AI项目以后，第一件事往往不是马上做Agent。

更现实的做法，是先把业务现场拆成AI能够读取、理解、执行和追溯的数据对象。

这一步看着基础，却决定了后面AI应用能不能真正上线。

配图1：FDE把业务需求拆成对象、字段、规则和动作

AI要进入企业业务，先要有清楚的数据对象。对象不清楚，流程、权限、审批、追溯都会跟着乱。

一、为什么业务对象拆不清，AI应用就很难落地？

企业里的业务，从来不是一句自然语言就能说完的。

一个销售跟进场景，背后至少有客户、联系人、商机、跟进记录、报价单、合同、回款、任务提醒、销售人员、部门这些对象。

一个采购审批场景，背后有供应商、采购申请、物料、预算、合同、审批单、付款计划、库存、收货记录。

一个设备巡检场景，背后有设备台账、巡检计划、巡检记录、异常工单、维修记录、备件、责任人、验收结果。

业务人员平时说话会把这些东西揉在一起。

他说：帮我看看这个客户是不是要流失。

他说：这笔采购能不能自动走审批。

他说：设备有异常时，让AI直接派单。

这些话没有问题。业务就是这样表达需求的。

但FDE不能只停在这句话上。

因为AI真正执行任务时，需要面对的是更具体的结构。

它要知道读哪个对象，取哪些字段，按什么规则判断，结果放在哪里，动作交给谁确认，最终有没有写回系统。

如果这些对象没有拆清，项目很容易出现几个问题。

第一，AI回答看起来合理，但依据说不清。

比如AI说客户存在流失风险，可它到底看了跟进记录，还是看了合同到期时间？有没有看回款？有没有看售后投诉？如果依据查不到，管理层不会放心用。

第二，AI能读数据，但不能安全地改数据。

读客户资料是一回事，修改客户阶段是另一回事。读取合同金额是一回事，把回款状态写回系统又是另一回事。企业里很多动作都带责任，不能交给一段提示词随意决定。

第三，流程会断在人工环节。

AI生成了建议，但没有任务对象承接；AI识别了风险，但没有审批或提醒流程；AI生成了总结，但没有写回客户档案。业务人员看完以后还要手动复制、手动填表，时间一长就不用了。

第四，权限会变得很难控制。

不同角色能看到的数据不同。普通销售看自己的客户，销售经理看团队客户，财务看回款，售后看工单。AI应用如果没有对象级和字段级的边界，很容易出现不该看的数据被读到，不该改的字段被修改。

所以企业AI应用要落地，FDE首先要做一件有点笨、但很关键的事：把业务说法翻译成对象、字段、关系和动作。

二、FDE拆业务对象，先拆“名词”，再拆“动作”

FDE进入现场后，最怕一开始就讨论模型能力。

模型能不能总结，能不能分类，能不能生成报告，这些都要看，但太早讨论会把项目带偏。

更稳的办法，是先听业务人员怎么说，然后把里面的名词和动作拆出来。

我们还是拿客户风险识别来举例。

业务人员可能会说：

最近几个重点客户跟进不太正常，销售经理希望AI每天帮忙扫一遍客户情况，发现风险以后提醒负责人，并给出下一步建议。

这句话里，名词很多。

重点客户、跟进记录、销售经理、客户情况、风险、负责人、下一步建议。

FDE要继续追问。

重点客户怎么定义？是客户等级，还是合同金额，还是商机阶段？

跟进记录在哪里？是CRM里的记录，还是企业微信聊天，还是销售自己填的表？

风险有哪些类型？长时间未跟进算风险，商机停滞算风险，投诉增加算风险，回款逾期算风险，这些是不是都算？

负责人是谁？客户负责人，商机负责人，销售经理，还是客户成功负责人？

下一步建议要做什么？只是展示给销售，还是生成待办，还是进入销售管理流程？

问到这里，业务场景就开始变成数据结构。

客户对象要有客户名称、客户等级、所属行业、负责人、所属部门、最近跟进时间、当前商机阶段、合同状态、回款状态等字段。

跟进记录对象要有跟进时间、跟进人、沟通内容、下一步计划、客户反馈。

风险记录对象要有风险类型、风险等级、判断依据、触发时间、处理状态、负责人。

任务对象要有任务标题、任务内容、截止时间、执行人、关联客户、处理结果。

这时候AI要做的事也清楚了。

它要执行的是一组明确对象上的任务：读取客户和跟进记录，按规则生成风险判断，给出建议，必要时创建任务或提醒负责人。

这就是FDE的现场翻译能力。

业务人员讲的是问题，FDE拆出来的是对象。

业务人员讲的是动作，FDE拆出来的是流程。

业务人员讲的是风险，FDE拆出来的是规则、字段和日志。

三、对象拆完以后，还要看对象之间怎么关联

只把对象列出来还不够。

企业业务真正复杂的地方，往往在对象之间的关系。

客户和联系人是一对多。

客户和商机可能是一对多。

商机和报价单有关联。

报价单后面可能接合同。

合同后面接回款计划和开票记录。

售后工单又可能反过来影响客户风险。

如果这些关系没有建好，AI就只能看到一块块孤立的数据。

配图2：客户风险识别背后的业务对象关系

它能看到客户名称，却不知道这个客户最近有没有商机。

它能看到合同金额，却不知道回款有没有逾期。

它能看到工单数量，却不知道这些工单属于哪个客户、哪个项目、哪个产品线。

这就是很多企业AI项目看起来能回答，真正用起来却不准的原因。

AI不是没有能力，问题是业务结构没有给够。

FDE在这里要做的，是把对象关系梳理成一张业务结构图。

比如客户风险识别，可以形成这样一条关系：

客户关联联系人，客户关联商机，商机关联报价单，报价单关联合同，合同关联回款，客户关联跟进记录和售后工单，风险记录再关联客户和负责人。

这样一来，AI分析客户风险时，就不是只看一个字段。

它可以围绕客户对象，把跟进、商机、合同、回款、工单这些信息连起来看。

当然，连起来看不等于所有数据都能随便看。

哪些字段能读，哪些字段需要脱敏，哪些字段只能某些角色读取，还要继续交给权限设计。

但至少对象关系先清楚了。

FDE做业务对象拆解，重点不在画一张好看的图，重点在让AI知道每一步应该读什么、关联什么、生成什么、写回什么。

四、为什么织信适合承载这类业务对象拆解？

如果每次拆完对象，都要从零开发数据库、页面、流程和权限，FDE会被大量基础开发拖住。

企业现场变化太快。

今天客户风险识别要加一个“近30天未跟进”规则，明天管理层又希望加入“回款逾期”维度，后天售后部门说投诉记录也要算进去。

这些调整如果全部依赖传统开发排期，业务热度很快就过去了。

FDE需要的是一个能把对象、字段、关系、流程和权限快速搭起来的平台。

织信作为低代码平台，适合放在这个位置。

在织信里，FDE可以先把业务对象建起来。

客户、商机、合同、回款、工单、任务、风险记录，这些都可以作为应用里的数据对象。每个对象有哪些字段，字段类型是什么，是否必填，是否允许修改，都可以逐步配置。

对象之间也可以建立关联。

客户可以关联商机，商机关联合同，合同关联回款，风险记录关联客户和负责人。这样后续做页面、流程、报表和AI调用时，不需要每一步都从头解释业务结构。

流程也可以跟对象绑定。

比如AI识别到客户风险后，不只是生成一段提示文字，还可以在风险记录对象里新增一条记录，再触发提醒流程。销售确认后，系统可以生成下一步任务；销售经理处理后，风险状态可以更新。

权限同样可以落在平台层。

谁能看客户，谁能看合同金额，谁能查看风险明细，谁能处理任务，谁能修改客户阶段，这些规则要放在系统里，而不能只写在提示词里。

这就是低代码平台对FDE的价值。

它让FDE不用每一次都从底层开发开始，而是把精力放在业务拆解、规则设计、链路验证和持续迭代上。

织信不是让企业跳过工程能力。中大型企业的复杂场景，仍然可能需要接口、脚本、代码扩展和系统集成。

但平台能先把主要业务结构搭起来，让AI应用有一个稳定的业务底座。

五、AI Agent要执行任务，必须先有清楚的输入和输出

很多人讨论Agent，喜欢讲自主规划、工具调用、多步骤执行。

这些当然重要。

但在企业里，Agent能不能用，首先要看输入和输出是否清楚。

输入是什么？

是客户ID，还是客户名称？

是某个销售负责的客户列表，还是某个部门的重点客户列表？

是最近7天的跟进记录，还是最近30天的全部客户行为？

输出是什么？

是一段自然语言分析，还是一条风险记录？

是生成任务，还是触发审批？

是写回客户档案，还是只在页面上展示？

如果输入输出没有定义清楚，Agent会变得很飘。

它看似能执行任务，但每次执行的边界都不一样。今天读了客户，明天读了合同，后天又把结果写到另一个地方。业务部门觉得不稳定，IT部门觉得不可控，管理层也不敢继续放大。

FDE要做的，是把Agent任务拆成可控的输入、过程和输出。

以客户风险识别为例，可以这样定义：

输入：客户对象、跟进记录、商机状态、合同状态、回款状态、售后工单。

过程：读取当前用户权限范围内的数据，按企业设定规则判断风险类型，再由AI生成解释和建议。

输出：风险等级、风险原因、建议动作、关联客户、负责人、处理期限。

后续动作：创建风险记录，提醒负责人，必要时生成任务，处理完成后更新状态。

这样定义以后，Agent就不再是一个随便聊天的窗口。

配图3：Agent任务执行前需要定义输入、过程和输出

它变成企业业务链路中的一个执行节点。

它能做什么，不能做什么，读哪些数据，写哪些结果，谁来确认，系统都能说清楚。

六、对象拆解做不好，后面权限和追溯一定会补课

有些企业一开始为了快，会先做一个简单Agent。

先让它能回答问题，先让它能生成内容，先让业务部门看到效果。

这个思路可以理解。项目早期需要验证价值，不能一上来就做得太重。

但FDE心里要有一条线。

只要AI开始读企业数据，权限就要跟上。

只要AI开始触发流程，审批就要跟上。

只要AI开始写回系统，日志和追溯就要跟上。

而这些能力，最后都会回到对象和字段。

配图4：对象拆解之后，权限、审批和追溯才有落点

权限要控制到对象和字段。

客户对象谁能看？合同金额字段谁能看？回款状态字段谁能改？风险记录谁能关闭？

审批要绑定到对象和动作。

AI建议调整客户等级，要不要审批？AI创建采购申请，要不要预算校验？AI修改工单优先级，要不要负责人确认？

追溯也要落到对象和记录。

AI读了哪条客户记录，调用了哪个接口，生成了什么建议，写回了哪条风险记录，谁确认了这个动作，什么时候完成。

如果前期对象没有拆清，后面补权限、补审批、补日志都会很痛苦。

这也是FDE不能只追求演示效果的原因。

演示可以先轻一点，但底层对象最好从一开始就按真实业务去拆。

否则项目一旦从试点进入生产环境，就会发现很多东西要推倒重来。

七、FDE做对象拆解，最终是在帮企业沉淀AI应用资产

企业做AI应用，最怕每个场景都重新做一遍。

今天做客户风险识别，明天做项目延期预警，后天做采购审批助手，大后天做设备异常派单。

如果每个场景都从零开始，项目会越做越重。

但如果FDE在前期把对象拆得好，很多能力可以复用。

客户、合同、回款、任务这些对象，在销售、财务、经营分析里都能用。

员工、部门、角色、审批这些对象，在几乎所有业务应用里都会出现。

工单、设备、巡检、维修记录，可以在生产、售后、运维场景里继续复用。

当这些对象在织信里逐步沉淀下来，企业后续再做新的AI应用，就不用每次重新搭地基。

它可以在已有业务对象上继续加流程、加权限、加报表、加Agent。

这才是企业AI应用真正有价值的地方。

一个看起来很聪明的问答窗口还不够，企业真正要沉淀的是业务对象、流程规则、权限边界和AI执行能力。

FDE在这个过程中，既不是单纯的售前，也不是单纯的开发。

它更像一个把业务现场翻译成平台结构的人。

翻译得越清楚，AI越容易上线。

结构沉淀得越多，后面的AI场景越容易复制。

八、结语：AI落地先问业务有没有拆清

企业问AI能不能做某个场景时，FDE最好不要急着回答能或不能。

更值得先问的是：

这个场景涉及哪些业务对象？

这些对象在哪些系统里？

对象之间是什么关系？

哪些字段能给AI读取？

哪些动作可以自动执行？

哪些动作必须人工确认？

结果写回哪里？

出了问题能不能追溯？

这些问题问完，项目才有机会从一句需求变成一条可上线的业务链路。

织信这样的AI智能开发平台，适合帮助FDE把这条链路搭起来。

先把对象建清楚，再把流程跑起来，再把权限和日志补齐，最后把AI Agent放进明确的业务边界里执行任务。

企业AI落地，不是把AI放到业务旁边看热闹。

它要进入客户、合同、审批、工单、项目、设备这些真实对象里，成为业务动作的一部分。

第二篇讲到这里，核心其实很简单：

FDE要做的第一件事，是把现场语言拆成AI能执行的数据对象。

这一步做好了，后面的流程、权限、集成、追溯和持续迭代，才有地方落。