做AI应用架构这几年有一个体会越来越深绝大多数智能应用最终不是死在算法精度上而是死在架构弹性上。业务一冲进来模块之间互相拉扯数据口径各说各话规则逻辑跟业务流程绑成一团AI模型再强也跑不动。这也是我为什么反复去拆百度智能运营平台这类产品——它不只是一个运营工具更是一套完整应对复杂业务场景的架构方法论。百度智能运营平台是什么用一句话概括把数据分析、用户画像、策略编排、渠道触达、效果回收串成一条自动化运营链路。运营人员在界面上配置一个活动策略平台自动完成人群圈选、内容匹配、渠道投放、效果归因再根据回流数据调整策略。这个过程听起来不复杂但真正拆进去之后你会发现能同时扛住多业务线、高并发、频繁策略迭代还能保持稳定演进的系统背后那套架构功力才真正值得研究。这次重点拆解的是其中四个最值得AI应用架构师借鉴的设计理念统一业务抽象、决策与执行分离、插件化扩展机制、可观测性与反馈闭环。这四个理念分开看很多做平台的人都会说我懂但放到一起并且每一层都做到足够深的系统并不多见。特别在AI应用场景下这四个理念几乎是必选项——智能系统天然面临高频率迭代和结果的不确定性没有架构层面的保障AI能力根本稳定不下来。这篇文章适合正在做AI应用、智能体平台、或大型业务系统的架构师和技术负责人。如果你管的是单一简单模块里面有些做法看着偏重但如果你负责的系统要接多个数据源、跑多套模型、支持快速试错那这4个理念可以直接拿去做架构体检。看完不妨对照自己的系统梳理一遍找到最值得先动手改造的那个点。1. 平台整体架构解析从业务视角重新理解“运营中台”1.1 智能运营平台到底解决什么问题先把痛点和背景交代清楚。运营这个活儿不是很多人想的那样拉个群、发个文案、投个广告背后是极其琐碎的工程协作。过去的主流流程是这样运营提需求数据团队排期写SQL提人群开发团队写接口对接各触达渠道最后投放完成后再人工回收数据复盘。一个活动从策划到落地少则一周多则一个月而且任何环节出问题都会顺延。我把这套旧流程的毛病归纳为三点。第一数据口径不统一。今天A工程师算活跃用户用的是近7天有登录明天B工程师用的却是近30天有任意行为人数能差出好几倍。不同团队做同一份人群包结果对不上最后全凭拍脑袋定夺。第二链路割裂。运营提需求只能通过工单、邮件、白板去流转。每一步都像传球球经常在半路掉地上。等到活动要上了发现人群数据还没交付或者渠道还没来得及接入。第三经验无法沉淀。一个活动效果好当时的策略参数、人群规则、文案、渠道组合全都存在某个人的文件夹里。这个人一离职这套经验就消失了后来的人要重新踩坑。百度智能运营平台把这条链路产品化。它重新定义了工作方式统一接入数据源建立全局的指标与标签体系人群圈选从SQL变成可视化配置策略执行由流程引擎自动推进效果数据自动回流形成配置—执行—优化的闭环。换句话说平台把运营经验从个人资产变成了平台资产。这个转变对架构师意义很大——它说明架构的第一块基石不是技术选型而是业务语义的统一。1.2 分层架构的核心拆解从模块上看这个平台大致分四层每层各管一摊事第一层数据接入与治理层。上游对接各业务库、日志系统、第三方数据源负责抽取、清洗、标准化、ID Mapping。这一层见不得光但最不能缺。没有统一治理过的底座后面谈用户画像、谈策略都无从谈起。第二层业务抽象层。把底层数据翻译成运营人员听得懂的业务语言用户标签、人群包、指标口径、行为事件。这一层是整个平台里最关键的一层因为它决定了系统能承载多少业务变化。第三层策略与决策层。跑的既有规则引擎也有AI模型推理还要做流程编排。职责就是回答三个问题圈谁、用什么内容、在什么渠道触达。第四层执行与反馈层。对接推送、短信、邮件、站内信等渠道执行触达动作同时采集各渠道返回的送达、点击、转化数据送回数据层形成新的闭环。这套分层并不是越复杂越好相反它保持了经典的稳定层在下变化层在上构图。下层的数据模型相对稳定上层的策略逻辑可以快速变化。每一层都能独立演进底层换数据源上层策略不动上层换渠道底层的标签体系也不用跟着改。你在自己的AI应用里也应该时刻问一句哪些模块在快速变化哪些相对稳定要把变化的部分尽可能收拢到独立层次别让它在系统里到处渗透、到处传染。1.3 应用架构师的第一课先分清“稳定层”和“变化层”分清稳定层与变化层这话说起来轻巧做起来特别容易跑偏。很多团队画架构图时一脸认真一到写代码就原形毕露业务流程图怎么走代码结构就怎么对应。结果业务一调整代码跟着大改。我审查过很多系统的代码库发现一个普遍现象凡是经常耦合到逻辑混乱的模块几乎都是没有明确层边界、业务变化直接穿透了稳定结构造成的。怎么分给你一个可操作的判断标准按变更频率与变更原因来切。比如用户标签这个东西标签的具体定义和规则会经常变但标签这个抽象概念不会变标签的增删改查、被人群筛选引用的方式也不会变。那么标签就是稳定层具体标签规则就是变化层。设计的时候稳定层做成核心模型变化层做成配置或用策略接入。百度智能运营平台就是把这一手贯彻到了几乎每一个业务领域。还想多说一句稳定层不是永远不变的层而是变化频率低、变化成本高、因此需要精心设计的层。用数据库设计来类比核心业务表的主键和索引是稳定层业务附加字段是变化层。稳定层的设计刻意保守变化层则可以大胆试错。这层关系理顺了系统的可维护性会明显提升后面要继续加AI能力也轻松得多。2. 架构理念一数据驱动的统一业务抽象2.1 业务对象建模的“降维”思路统一业务抽象应该说是整个平台的根基。什么叫统一业务抽象就是把底层再怎么乱七八糟的数据在平台层面都收敛成一套稳定、可理解的业务语义。百度智能运营平台里核心对象抽象出来掰手指头数得过来用户、事件、标签、人群、策略、触达记录、效果指标。就这些没了。很多人会不以为然不就是几张表的事吗但真正的复杂度藏在对象之间的关系上。举一个最典型的例子用户。用户在不同系统里可能以完全不同的ID存在有注册的账号ID有设备ID有手机号有邮箱。平台要做的第一件事就是建一张用户中心映射表把不同来源的ID全部规整到一个统一的user_id下。这个过程俗称ID Mapping是所有智能运营的基础设施。这个表结构实测下来可以这么设计CREATE TABLE dim_user_mapping ( user_id VARCHAR(64) COMMENT 统一用户ID, source_type VARCHAR(32) COMMENT 来源类型account/device/phone, source_id VARCHAR(128) COMMENT 来源原始ID, is_primary TINYINT COMMENT 是否主ID, update_time TIMESTAMP, PRIMARY KEY (user_id, source_type, source_id) );这样设计的好处是任何来源的数据进来都可以通过映射关系快速找到同一个用户的全景轨迹。没有这层映射用户画像就是一盘散沙策略引擎就算再强喂给它的也是错误的数据。我做这类设计时的体会是建模的价值不在于把实体做得多大、多全而在于能砍掉多少冗余。一味追求覆盖所有情况模型会越建越胖最后没人维护得动。对AI应用架构师来说这一点尤其重要数据越规范统一特征工程、模型训练、线上推理就越省心模型迭代速度直接受益。这比任何花哨的算法技巧都实在。2.2 统一指标与标签体系的实战价值统一指标体系与标签体系听上去像运营视角的事但它其实是技术系统能否长期稳定的关键。拆开来讲指标是可以量化的比如次日留存率、转化率、人均GMV标签是描述性的比如高价值用户、iPhone用户、30天未活跃。运营同学关心的是这两个东西的分类和数值压根不关心底层数据仓库的计算过程。要想做到统一背后需要几个条件都到位。指标层面必须有一份全局的指标定义清单。每个指标要有明确的名称、口径、计算公式、更新频率、取值边界。这里最容易出的坑是同名不同口径——比如GMV是包含退款算还是不包含退款算是只算线上支付还是包含货到付款一个指标定义不严谨后面做任何分析对比都会失真。标签层面要有生命周期管理。一个标签从创建、评审、发布到使用、下架每一步都应该可追踪。我还见过不少团队标签建了一百多个真正用起来的不到二十个剩下全是僵尸标签。没有治理机制标签体系会慢慢腐烂。在百度智能运营平台的架构里这两块做成了整个平台的业务字典。AI应用架构完全可以借鉴这个小而精的思路。你的系统也许不需要上一套完整的中台但至少要在团队里建立一份标准文档和评审流程。不然等业务起来之后日活用户这一个概念就能给你整出一部罗生门——各个表里定义不一样、对不上数你连排查都无从下手。2.3 架构师借鉴如何设计可复用的领域模型放到AI应用架构场景里怎么把上述思路落地我总结三条实操原则。第一先建模后写代码。不要一上来就急着撸业务逻辑。先用文档或画图工具把核心实体和实体之间的关系定义清楚。哪怕用Excel凑合都行但必须做。模型的草稿阶段修改成本极低等代码写出来了再改模型每改一次都是伤筋动骨。第二模型必须独立于实现。业务模型在描述上不该受技术选型的干扰。系统将来用MySQL、PostgreSQL、ES甚至图数据库都不应该改变你对业务实体的定义。技术选型是how业务模型是what别把这两层搅在一起。一旦搅在一起换存储的代价会连带着业务的大改。第三从第一天就考虑模型演进。具体来说所有的实体表和接口从设计之初就预留版本字段消息体里也带上schema_version。这样未来模型扩展字段新旧版本可以同时兼容不会一改结构就全线崩盘。我在团队里带项目时习惯用一个实体—关系—行为的模板做领域设计。实体是核心对象关系描述实体之间的关联包含一对多、多对多以及关联的约束条件行为描述每个实体能执行的动作和允许触发的流程。这个模板不算高深但应对90%的AI应用场景足够了。当然如果你的场景极其复杂也可以引入领域驱动设计里限界上下文的概念把模型拆细但前提是团队有一定的建模功底否则很容易拆成碎片。3. 架构理念二流程编排与智能决策的分离3.1 逻辑决策层与执行层的解耦第二部分聊整个平台最核心的一个架构隔离区流程编排与智能决策的分离。字面意思也好懂——流程负责什么时候去做决策负责到底怎么做才最优。可太多系统把这两层糊在一起。我在代码评审里见过大量类似的逻辑如果用户评分大于80就给他发优惠券如果评分大于60且最近30天没登录就发召回推送。一条条if else全写在业务代码里。刚开始看着直接等判断条件多了各个业务线同时叠加上来代码就变成意大利面谁也不敢动。更要命的是AI模型压根没法进来。你想要的模型是动态决策今天这个用户该不该触达、该用什么文案模型说了算。但如果判断逻辑全写在代码里你想把决策部分交给模型就只能改代码、重新发版。改一次两次能忍业务要天天调策略的时候研发团队就只能躺在需求单下面了。百度智能运营平台的解法是把决策单独拿出来做成独立可配置的策略层流程引擎只是执行方。策略可以是规则、可以是人群包、也可以是模型推理的输出。流程层拿到结果后按编排好的路径继续跑该发推送发推送该发优惠券发优惠券。于是策略升级不再需要发版流程变更也不会动到决策逻辑两边自动解耦。这是典型的策略驱动架构也是AI应用架构里一个非常值得复刻的分界线。3.2 引擎化设计的落地方式理念落地为技术决策引擎可以怎么设计这个问句我几乎每次技术交流都会被问到。最简单实用的一种用配置化规则引擎。把策略定义成JSON运行时由一个通用引擎解释执行而不是把策略逻辑编译进程序里。一个策略文件设计大概是这个样子{ strategyId: recall_high_value_202506, name: 高价值用户召回策略, version: 3, description: 针对近30天未活跃的高价值用户做召回, trigger: { type: schedule, cron: 0 2 * * * }, steps: [ { id: step_filter, type: segmentation, segmentRule: { operator: AND, conditions: [ {field: user_score, op: gt, value: 80}, {field: last_active_days, op: lt, value: 30} ] } }, { id: step_decision, type: model_inference, modelName: touch_probability_v2, outputField: touch_score }, { id: step_action, type: action, actionType: send_push, channel: app_push, templateId: push_recall_01 } ], audit: { owner: growth_team, approver: platform_admin } }这里有个很重要的点策略是数据不是代码。引擎只是一个执行器。将来要加入新的动作类型比如调用一个Agent工具链那就注册一种新的node type进去策略文件里换一下type就行完全不必改主流程。如果流程再复杂一点比如要做多阶段活动先小流量测试根据反馈决定是否全量开放再全量执行最后回流效果数据更新人群标签。那就必须引入真正的流程编排。决策引擎负责单点决策流程引擎负责多节点串联两者职责分开。再配合可视化的流程画布运营同学可以自己调整流程分支而不只是改配置。3.3 借鉴应用把你应用里的“规则”抽出来说回AI应用。很多AI应用里都布满判断逻辑要不要转人工、要不要降级、这个请求走模型A还是模型B。这些判断如果全用代码写死每次都要在发版前面卡一遍更谈不上快速试错。我早年做智能客服系统时这个教训特别深刻。最开始转人工的条件写在服务里三层if嵌套产品经理每次想调一个阈值都要提需求、排期、走发布流程等上线时候黄花菜都凉了。后来我硬是把判断逻辑抽到一个独立决策模块里做成可调整的决策树配置放在配置中心。效果立竿见影产品经理自己调条件当天就能生效不用再找研发。研发团队也解脱了不再被琐碎的策略变更反复打断。给你三个实操建议第一选出系统里变更频率最高的判断逻辑作为第一批抽取对象。别贪多从一个开始。第二抽出来的决策模块要能独立测试。能做到离线回放历史数据验证策略变更前后的差异这样上线才心里有底。第三不管决策还是流程执行都要有审计记录。谁改了什么策略、当时为什么改这些信息应该在系统里留痕避免后续追溯的时候凭记忆说话。4. 架构理念三开放生态与插件化扩展机制4.1 插件体系设计的关键抽象第三个理念是开放生态与插件化扩展机制。一个平台不可能什么功能都自己做完正确的姿势是定义好扩展机制让别人也能贡献能力同时不影响平台主体。百度智能运营平台能做到多业务线共存很重要的一点就是这套插件机制的功劳。设计插件体系接口定义只是最表面的部分。真正见功力的是三点插件生命周期管理、运行时的隔离、以及插件能触及的边界。生命周期管理很简单插件要有注册、安装、启用、升级、下线这几个明确的阶段。每个阶段对应的状态和数据都必须有记录。插件的升级一定要做到灰度发布先让小部分流量试跑确认无误再全量切过去。这个跟服务发布的思路完全一致只是对象变成了插件。运行时隔离通俗地说就是别让一个插件把主流程带崩。插件最好跑在独立的线程池或者独立进程里有超时控制、有异常隔离、有资源配额。如果插件与主进程共享一切一个插件内存泄漏就能让整个平台跟着抖。这个坑我见过太多次了必须警惕。边界控制就是插件不能想访问什么就访问什么。宿主系统暴露给插件的只应该是业务语义上的接口比如触达能力接口、人群查询接口而插件绝不能直接访问数据库。这跟做微服务时强调的服务间只通过接口通信、不共享数据库是同一个架构原则。4.2 权限与安全边界的设计考量插件机制本质上是开放能力。但放多少、开多大一定要有边界控制。对于平台级产品以下机制是必须有的第一注册审批。插件在接入前要提交插件说明、权限申请和接口文档。由平台管理方评估它需要的数据范围是否合理有没有过度申请。这跟移动应用商店审核上架是一个思路。第二运行时权限鉴权。插件调用宿主的任何API都必须以最小权限为准。插件A是用来做渠道触达的就不该允许它去查询用户标签全量数据。权限模型要提前设计别上线了再打补丁。第三强制审计。插件做的每一次关键操作都应该有日志调用了什么数据、执行了什么动作、操作用的是哪个调用方标识。平台越开放审计越重要。这块的钱省不得。第四配额熔断。插件频次、流量、错误率都要有配额与熔断机制。某个插件配置出错或者被外部异常流量冲击也不能拖垮平台。这种隔离故障半径的设计思想做平台的人应该刻在骨子里。这个理念放在AI应用架构里特别对应的场景就是多模型接入。现在的AI应用几乎必须支持多家模型提供方还要接各种工具链、Agent组件。把模型提供方当成插件来设计做好统一的模型网关你切换模型、做A/B对比、灰度发布都会非常顺手。反过来如果每个模型服务都各自独立对接代码里写死那过不了三个月系统就会被新模型需求拖死。4.3 架构师借鉴给系统留“后门”的正确方式这里的给系统留后门不是安全漏洞而是架构层面的扩展点。打个比方一栋大楼如果没有预留电梯井等住满人了想加电梯就只能砸墙。软件架构一个道理。没有扩展点的系统就是没有预留电梯井的大楼新需求来一个砸一次墙。通常来说AI应用值得预留扩展点的位置至少有三个数据接入处、策略决策处、效果反馈处。数据接入处将来要加新的数据源策略决策处将来要换新的模型或规则效果反馈处将来要接新的渠道归因。这三个位置是业务最活跃的地方也是最容易被新需求冲击的地方。设计扩展点的时候不用太顾虑。宁可初期少开放也不要一下铺开一堆。我看到过不少系统到处是SPI接口和插件点结果真正用到的没几个倒是文档复杂到没人看得懂。扩展点的数量应该严格控制。每加一个都要有充分的业务驱动不然就是过度设计。平台能力的发展永远是渐进的能力开得太多最后理顺的成本远高于早期忍住不开。5. 架构理念四可观测性与反馈闭环5.1 全链路追踪与监控设计第四个理念是绝大多数AI应用架构里最容易被省掉、也最要命的一块可观测性与反馈闭环。在传统业务系统里可观测性主要服务于排障。线上出问题了能通过日志快速定位是哪里出了错。但在AI系统里可观测性的角色完全不同——AI的输出有概率属性模型的判断会受输入质量、版本漂移、数据分布变化的影响所以出了错能看到错在哪里只是一个底线能看到为什么产出这个结果才是真正的需求。百度智能运营平台的策略链路一跑就是一大串数据进入、人群圈选、策略决策、渠道执行、效果回流。为了端到端可追踪平台在链路关键节点都做了埋点并用一个全局trace_id把所有环节串起来。不管问题是出在人群计算不准还是渠道送达失败都可以用trace_id把当时的输入、版本、中间结果完整捞出来。工程上建议trace_id从请求一进来就生成用分布式上下文透传到每个环节。日志里至少要记录输入参数、策略版本、关键中间结果、最终决策结果。有些团队觉得这些信息太多了日志体量会暴涨。但想想如果没有这些现场信息线上效果出现问题时要回溯几乎等于考古——缺一个环节就断一条线索。5.2 反馈闭环从数据到策略优化可观测性的更高阶价值不是能看到而是能驱动决策。当你把效果数据回流到策略层做自动对比和归因系统就开始具备自我优化的雏形。百度智能运营平台里的效果回流最后会落成策略效果报表运营看报表做决策再往后演进系统可以直接基于回流数据做自动调参运营只需要设定边界和审批。反馈闭环的设计有一个非常关键的原则反馈数据的口径必须与决策输入的字段一致。举个例子你的决策用了最近30天活跃天数这个特征那回流数据里必须记录这个特征当时的取值。否则一个月后复盘你根本说不清楚是用户特征变了还是策略确实失效了。这是很多人做反馈系统容易踩的坑只记录效果数字没记录输入特征。落到存储设计上建议起码有三张表决策日志表、执行结果表、效果归因表。决策日志表记录系统在什么条件下做了什么决策执行结果表记录渠道返回的结果发送、送达、点击、转化效果归因表把这两个关联起来并保存当时的特征快照。这套设计不只用于报表更是未来AI自动优化的原料库。5.3 借鉴应用构建自愈系统的基础自愈系统这个词听起来像科幻其实就是把反馈和策略打通之后的自然结果。系统能自动发现、定位、恢复靠的都是反馈闭环。拿运营平台举几个例子非常直观如果某个渠道的送达率开始掉低于阈值系统可以自动把流量切到备用渠道同时告警通知值班同学。如果某个策略的效果持续变差系统可以自动暂停该策略等人工复核后再决定是否重启。如果某个模型的线上指标跌了系统可以回退到旧版本模型。如果数据回流延迟系统能检测到并自动重跑或者补数。这些动作的通用逻辑都是用可观测数据作为输入用决策引擎产生动作正好跟前面讲的策略引擎衔接上。所以在架构层面可观测系统、策略引擎、流程编排不是三个割裂的东西而是同一个闭环的三个环节。AI应用要走向智能化、自动化这条闭环一定得打通。6. 实操总结与落地建议6.1 作为AI应用架构师如何落地这些理念解释完这4个理念最常收到的追问就是这跟我的系统怎么结合我按阶段给一条落地路径。起步阶段先做一次架构体检。把系统图捞出来问四个问题维度关键问题判断标准统一业务抽象业务语义是否全局统一同一个指标/实体在跨模块是否同名同义决策执行分离判断逻辑是否耦合在执行流程里改一个策略是否必须发版插件化扩展系统有没有明确扩展点接入新数据源/新模型是否需要大改反馈闭环效果数据是否形成自动化闭环决策日志与效果数据能否通过trace_id关联这四个问题如果都是否也没关系说明思路清楚了后面就是逐个击破。第二阶段选定一个核心场景试点。别搞大跃进全平台推倒重来不现实。选一条业务链路从数据接入、策略配置、执行触达、效果回流完整做成一个独立闭环。这个闭环跑通4个理念的价值就都能验证出来。跑通了再横向复制到其他场景。做架构改造一定要靠试点证明价值否则你写再多方案团队也不敢给你开资源。第三阶段逐步沉淀平台能力。当场景变多公共能力会慢慢浮现出来统一标签、人群引擎、策略配置、归因表……这些可以一步步收敛成平台。这个阶段建议团队引入领域驱动设计的实践把限界上下文对齐到业务边界上系统就会长成越来越稳的形态。6.2 踩坑经验与常见问题讲完了方法论再说说踩过的坑也算给后来者探路。第一个坑抽象过度。团队一上来就铺开业务建模建了一堆所谓万能实体结果三个月后连写代码的人都说不清模型之间的关系。这种问题的根源是没搞明白抽象应该从最小可用集开始。正确的打开方式是模型先小够用就好业务驱动再加。扩展容易收敛可难多了。第二个坑策略引擎做成黑盒。规则和配置越堆越多最后变成一个新的巨型泥潭。要避免这种情况关键是把策略也当代码管起来放在版本控制系统里有评审、有测试、有发布记录。很多系统一开始运维简单后来维护难都是策略缺少工程化治理的后果。第三个坑只采集数据不做闭环。有些团队把埋点做得密密麻麻月报照样用表格汇总数据在系统里躺了几个月没人碰。反馈闭环不落到工程链路里它就只是报告永远成不了优化智能系统的引擎。记住反馈闭环不是数据产品是系统设计的一部分。还有个常见问题值得单独分享模型接口版本管理。我早期做模型服务升级时曾经直接改了线上接口的输入输出格式导致下游多个服务一起挂掉。之后我立下规矩任何模型接口的变动至少提前两个版本周期做兼容方案。这道理跟数据库表结构变更一样别图一时省事给自己埋雷。6.3 最小可行性方案的实操步骤文章最后给一个可以直接落地的最小可行性方案换个说法一个一到两周能跑通的最小验证闭环。第一步梳理核心业务实体。不超过5个在现有系统里找到这几个实体的数据来源画清楚它们之间的关系。第二步建立统一口径文档。把每个指标、标签的定义、口径、来源列成清单拉团队一起评审。这一步看起来很基础却是后面所有架构动作的底座。第三步抽一条决策逻辑到策略服务。把系统里一两个判断改造成配置化用策略文件加决策引擎跑通一次。这一条链路全部补上单元测试。第四步打通效果数据。把决策日志和效果日志用trace_id关联起来做一张最简单的效果归因报表。第五步加上追踪标记。链路从入口到底层每个关键节点都带上trace_id。五步下来系统的基础架构格局会明显不一样。这套最小验证真的很值得做它不要求高深的理论只要求你动手把链路完整理一遍。理完你会发现很多之前想不清楚的问题都会浮现出来后面往哪个方向改良也会清楚很多。最后留个个人体会很深的建议吧。架构设计没有一步到位这种事真正有价值的不是那堆漂亮的架构图而是能不能在业务快速变化的过程中让系统保持可理解、可维护、可演进。你可以先挑这4个理念里最贴合自己现状的一个动手试试。把一条已经存在的复杂链路一步步理顺本身就是架构师真正的本事这种本事会越练越扎实。祝大家能在各自系统上少踩坑、多落地。