夜雨聆风一个客户，5 个系统，5 个名字，5 套信用额度。月底对账，没人说得清他到底欠多少钱。
先讲一个我亲历的烂摊子。
一家集团公司，做了五年系统。CRM、销售、财务、供应链、客服，五个系统，五批人建。
每个系统里都有"客户"。
听起来挺正常。
直到有一天，财务要拉一张全集团的客户对账单。
然后炸了。
同一个客户"华为"——
CRM 里叫"华为技术"
销售系统里叫"华为集团"
财务系统里叫"A0042"
供应链里叫"HUAWEI"
客服系统里叫"VIP-001"
5 个 ID，5 套信用额度，5 个联系方式。
财务小姑娘对着屏幕问我：这到底是同一个人，还是五个人？
我说：是同一个人。
她问：那他到底欠我们多少钱？
我没答上来。
(因为五个系统的账，根本对不上。)
为什么全国、全世界的企业，都会掉进同一个坑？
根子只有一个：系统设计，从一开始就围着"功能"转，没围着"业务对象"转。
软件系统不是由页面组成的。
它是由业务对象，和它们之间的关系组成的。
搞不清对象，再漂亮的功能，最后都会变成数据沼泽。
这就是需求分析方法论里，紧跟在"需求提取"后面的第二项核心能力——业务对象识别
先有对象，才有功能——顺序反了就是灾难
需求分析的第一步不是设计功能，而是认清这个系统到底管理哪些业务对象、它们怎么连。很多团队一上来就急着定功能：
"做几个页面？""有哪些按钮？""需要哪些菜单？"
很少有人先问一句——
这个系统，到底在管哪些业务对象？这些对象之间，是什么关系？
就拿一个物流系统说。
从功能看，它就是几个页面：创建订单、查询订单、分配车辆、查看轨迹。
但从业务本质看，它真正管理的是一堆对象：客户、订单、运输任务、车辆、司机、仓库、费用。
这些对象，织成了一张关系网。
软件系统，就是这张网的数字化表达。
顺序为什么重要？因为顺序一反，灾难就埋下了。
业务说一句"我要个客户管理模块"，产品就画了客户列表、客户新增、客户详情，开发建张 customer 表——收工。
看起来没问题。
可几年以后，销售有客户、财务有客户、客服有客户、CRM 有客户、供应链也有客户。
同一个客户，多个系统，多个定义，多个版本。
为什么？因为系统从功能出发，没从业务实体出发。 每个系统各建各的 customer，谁也没把"客户"当成一个全集团共认的对象。
主数据做不好，后果业内有句行话：报表打架、流程失效、审计风险层出不穷。
名词不等于实体——AI 怎么判断谁才是真对象
实体提取不是"找名词"。系统/信息/页面都是名词，但都不是实体。判真伪，看三条标准。很多人以为，让 AI 从需求里提取实体，就是让它把名词挑出来。
错。
NER（命名实体识别）技术圈里，有个出了名的老大难叫"假阳性"——模型把普通名词误判成实体，噪声一堆。
需求文本里，这种陷阱特别多。
比如一句话：
"系统支持快速查询历史订单信息。"
名词有几个？系统、历史订单、信息。
但真正的业务实体，只有一个：订单。
"系统"是工具，"信息"是描述，"查询"是动作——都不是对象。
那 AI 凭什么判断，谁才是真实体？看三条硬标准：
① 它有独立的生命周期吗？
订单会经历创建、修改、取消、完成——有自己的生老病死。是实体。
"查询"呢？查完就没了，没有生命周期。不是。
② 它有自己的业务属性吗？
订单有订单号、客户、金额、状态——一堆字段。是实体。
"提交"这个动作呢？没有属性。不是。
③ 它会被业务反复操作吗？
车辆会被分配、调度、维修——一直被折腾。是实体。
"页面"呢？它只是展示用的，没人对它做业务操作。不是。
记牢这三条，你就有了过滤"假实体"的筛子。
而实际操作里，最常见的三种认错，正好踩在这三条的反面——把页面当实体、把操作当实体、忽略隐藏实体（这个最阴，比如"管理员审核订单"，实体不是"审核"，而是藏起来的审批记录，因为系统得记住谁审的、什么时候审的、结果和意见）。
实体不是孤岛——关系和基数，决定系统骨架
实体识别出来只是开始，关键是它们怎么连。一对多、多对多，这些"基数"直接决定了数据库和架构。企业系统真正的难点，从来不是实体太少。
是关系太复杂。
一个供应链：供应商 → 采购订单 → 入库单 → 库存 → 销售订单 → 客户。一条链上每个对象，都和前后勾着。
AI 要识别的不只是"有哪些对象"，还有它们之间是什么关系。
关系分三种基数：
一对一（1:1）： 一个订单，对应一个支付记录。
一对多（1:N）： 一个客户，可以有多个订单。（这是最常见的关系）
多对多（N:M）： 一个商品可以出现在多个订单里，一个订单也可以包含多个商品。（这种最棘手，通常要拆出一张中间表）
为什么基数这么要紧？
因为它直接决定你怎么建表、怎么分库、怎么拆服务。
为什么那么多公司微服务拆不动？因为没人说得清——业务边界到底在哪。
实体关系画清楚了，领域自然就浮出来了。客户相关的实体聚成"客户域"，订单相关的聚成"订单域"，运输相关的聚成"运输域"。
从实体模型，到领域模型，这条路是通的。
AI 不是给你一句话，是给你一套资产
做完实体分析，输出不能是"我发现了 8 个实体"这种废话。它得是结构化资产——实体文档、注册表、全局数据字典。很多团队让 AI 跑完实体提取，最后只得到一句总结：
"本次共发现实体 8 个：客户、订单、车辆……"
这跟没做一样。
企业级的需求分析，实体提取的产出，必须是一整套可复用的资产。
拿一个"运输订单"实体举例，它的产出至少长这样：
实体名称： 运输订单业务定义： 客户提出运输需求后形成的业务单据核心属性： 订单编号、客户、起点、终点、状态关联实体： 客户、运输任务、费用单
每一条，都能往下接：实体定义进文档，所有实体汇总进注册表，字段口径进全局数据字典，关联关系最终汇成领域模型。
为什么这套东西值钱？
因为它就是未来 AI 生成代码之前，必须先读懂的"企业说明书"。
没有这层语言，AI 只能给你漂亮的页面、漂亮的代码——但很可能，不是正确的软件。
实体模型，是 AI 理解企业的第一层语言。
写在最后：对象对了，系统就对了一半
回到开头那个烂摊子。
那家物流集团，后来花了两年，做了一件特别不性感的事——把全集团的"客户"对象，重新梳理了一遍，统一成一份主数据。
慢吗？慢。
但月底对账那天，财务小姑娘终于不用再问"这到底是几个人"了。
因为从那天起，"华为"在全集团，就只有一个 ID。
企业的软件系统，本质上是在数字世界里，重建一个业务世界。
而业务世界的基本组成——
不是按钮，不是页面，不是菜单。
是一个个业务实体，以及它们之间复杂的关系。
所以需求分析的第一件事，永远不是问"需要哪些功能"。
而是问：
这个业务世界里，有哪些重要对象？它们如何共同运转？
当 AI 能看懂这些对象，它才真正开始看懂这家企业。
下一篇，我们解决一个更难的问题：对象太多怎么办——
《DDD 如何帮助 AI 理解复杂业务？——业务领域建模方法》
我们会拆开讲：
为什么大型系统，必须划分领域？
为什么部门边界，从来不等于系统边界？
AI 怎么自动发现业务领域？
怎么从一堆实体关系，长出领域模型？
关注我，我们一起，把"需求"这件事，从手艺活变成工程。