news 2026/10/1 6:03:28

AI协同驱动智慧园区运营:大模型与Agent融合落地实践

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
AI协同驱动智慧园区运营:大模型与Agent融合落地实践

1. 项目背景与核心价值拆解

接手这个项目的时候,产业园智慧运营在行业里已经喊了很多年,但真正落地的效果大多停留在“一块大屏、几套系统、若干IoT传感器”的层面。企业服务、招商引资、物业管理这三块业务各自为政,数据不通、流程割裂,AI顶多用在某个单点上做做智能问答或者OCR识别。这次我们想做的是把这三块业务真正拉到同一个技术框架下,让AI不再是零散的“点工具”,而是贯穿运营全流程的“协同大脑”。

先说清楚这个项目到底解决什么问题。产业园运营方的日常工作,本质上是在伺候三个“客户”:入驻企业(要服务)、潜在投资方(要招商)、园区物理空间(要维护)。过去这三条线是三个团队各自跑,招商团队拿着Excel表格筛选企业,企业服务团队靠着人工一条条读政策,物业团队用微信群接报修工单。信息割裂导致的直接后果是:一个企业今天刚被招商团队谈进来,明天企业服务团队还不知道它是什么行业、有什么诉求;物业那边因为对入驻企业缺乏了解,连会议室预约的审批都要人工核对。AI能把这三条线串起来,靠的不是什么黑科技,而是把数据打通、把流程标准化、把决策模型化。

这套方案的目标很明确:构建一个以数据中台为基础、以大模型和Agent为核心的协同运营平台。企业服务端,用AI让政策匹配、诉求应答、风险预警变得自动化;招商引资端,用AI做产业链分析、企业画像和智能撮合;物业管理端,用AI做工单调度、巡检预测和能耗优化。三者在底层共享同一套企业档案、楼宇设备、空间资源数据,在应用层通过统一的Agent协作框架相互触发任务。举个例子,物业巡检机器人发现某层楼频繁出现温度异常,这个信息经过AI分析后不仅生成工单,还会同步推送企业服务团队去调研该楼层企业是否有扩容或设备更换需求——这就是协同的价值。

适合谁参考这篇内容?如果你是产业园、写字楼、孵化器的运营方,被“系统买了一堆却用不起来”困扰过;如果你作为方案架构师或项目经理,正在设计智慧园区项目但不知道AI协同具体怎么切;或者你只是个对AI落地感兴趣的从业者,想看看非互联网行业怎么把大模型用出实际产值——这篇内容都能给你一些可以直接拿走的思路。没有太玄乎的理论,全部来自我们在项目中踩过的坑和验证过的方法。

2. 整体架构设计:AI协同的前提是数据与流程的“标准化”

2.1 三条业务线为什么需要一套架构

很多园区搞AI,最常见的做法是给招商团队配一套“智能招商系统”,给物业团队配一套“智慧物业平台”,再给企业服务部门上“政策计算器”。三套系统来自不同厂商,账号体系不一样,企业ID不统一,数据模型各说各话。招商系统里的“企业规模”用的是营收区间,企业服务系统里的“企业规模”用的是员工人数,物业管理那里的“企业”干脆就只是一个房号加联系人。这种状态下去谈AI协同,无异于让三个说不同语言的人合作写一本书。

所以第一步不是选AI模型,而是统一底层数据。我们把企业、空间、设备、合同、工单、诉求等核心实体做了主数据建模,所有业务系统必须遵循同一个数据字典。企业有唯一ID,关联所属产业链环节、租赁面积、能耗数据、服务记录、政策申报记录;楼宇和房间有空间编码,关联设备列表、巡检计划、工单历史。这个底座一旦建好,后面所有AI场景都只是在这层数据上做“加工”。

2.2 技术选型:大模型、Agent与工作流引擎的分工

在设计AI协同层的技术架构时,我们最终确定的是“大模型底座 + Agent编排 + 业务工作流”三层组合。大模型负责理解和生成,Agent负责逻辑判断与工具调用,业务工作流负责与现有系统对接和状态流转。这个组合不是拍脑袋定的,而是源于实际使用中的教训:早期我们试图让大模型直接调用业务系统API,结果模型经常幻觉出错误的接口参数,而且一个长任务中间模型一旦“犯傻”,整个流程就卡死。

后来引入Agent框架后,我们把任务拆解成更小的步骤。比如企业服务中的政策匹配,Agent需要做三件事:读取企业画像、检索政策库、生成申报建议。每一步可以独立调用工具,如果某一步结果置信度低,Agent会停下来询问需要补充信息,而不是硬着头皮继续编。再配合工作流引擎,实现跨部门的任务流转:招商Agent发现目标企业后,自动创建一条签约待办并通知企业服务Agent准备入驻服务包,整个过程有状态、可追踪、可回退。

模型选型上,我们没有盲目追求千亿参数。产业园场景中大部分任务面向的是中文政策文本和业务表格数据,百亿参数的商用模型已经足够,且推理成本更低、响应速度更快。代码生成类需求(比如让AI辅助写一些数据清洗脚本)用通用大模型,而企业知识问答、政策匹配这类需要高准确度的场景,我们采用“小模型精调 + 大模型兜底”的混合策略:先用精调的匹配模型从库中召回候选,再让大模型基于候选生成回答,把幻觉率压到可接受范围。

2.3 基础设施与安全边界

这一块容易被忽略但必须早规划。产业园数据涉及企业工商信息、法人联系方式、合同金额、物业门禁记录等隐私敏感内容,AI系统不能像消费级产品那样毫无边界地“什么都能聊”。我们的做法是:建立统一的知识库权限体系,AI问答、Agent工具调用都必须校验身份和角色权限,比如物业班组只能查工单相关数据,不能访问企业财务信息。

安全合规方面,特别注意了内容审核和模型输出管控。我们在AI网关层接入敏感词过滤和输出安全校验模块,任何生成内容在推送给用户之前都要过一遍合规检查。虽然项目本身不涉及高危内容,但园区未来可能要对接政务平台,这条红线早点绷紧没有坏处。

3. 企业服务的AI落地:从政策匹配到主动式关怀

3.1 企业画像构建:AI协同的地基

企业服务场景的起点不是AI,而是企业画像。过去园区对企业的了解仅限于签合同时填写的行业类别和联系方式,企业后续发展如何、有无融资需求、研发投入占比多少,统统不清楚。没有这些数据,AI再强也做不了精准服务。

我们的企业画像体系包含五大维度:基本信息(工商注册、股权结构)、经营状况(营收趋势、纳税评级、社保人数)、创新指标(专利数量、软著、高新技术企业资质)、空间行为(门禁出入频次、会议室使用率、能耗波动)、服务互动(历史诉求、参加过哪些活动、申报过哪些项目)。数据来源包括企业主动填报、公开数据抓取、园区IoT采集和运营人员录入。这五类数据汇入数据中台后,每个入驻企业都会生成一个动态的“健康度评分”,这个评分会成为后续AI决策的重要依据。

3.2 政策匹配与智能申报提醒

企业服务团队最耗人工的任务就是政策匹配。一个园区几十上百家企业,政策文件天南海北来自省、市、区、街道不同层级,发布时间又很分散。过去靠专人每天刷官网,看到政策就转发到群里让企业自己判断,效率低不说,还经常漏掉关键申报窗口。

我们用AI做了一个政策匹配引擎,核心逻辑不算复杂:先把政策原文通过NLP拆解出支持方向、申报条件、奖励额度、截止时间等结构化字段,再与企业的画像标签做加权匹配。比如一份“高新技术企业培育资助”政策,系统会自动提取“成立满一年”“研发费用占比不低于5%”“拥有自主知识产权”等条件,然后对照企业画像库里的专利数、财务数据、成立年限,计算出每个企业的匹配分。

这个系统的收益不只是省人力,还在于能够主动出击。匹配分超过80的企业,AI会通过企业服务Agent自动生成一份定制化的《申报建议书》,推送给服务专员,由专员确认后发给企业。以前专员要把一份政策解释给好几家企业听,而且每家的适配度还需要临时查数据,现在直接拿现成的报告去沟通,企业感觉专业度上了一个台阶。

3.3 企业诉求的智能受理与闭环

园区里企业提诉求的渠道非常多:前台电话、微信群、邮件、系统工单、线下面谈。在过去,这些诉求散落在不同渠道,有人用Excel记录,有人干脆靠脑子记,根本形不成闭环分析。AI协同的第一步就是统一诉求入口,把语音转文字、邮件解析、群消息接口全部接入智能客服Agent。

智能客服Agent能解决大约60%的标准化问题,例如“会议室怎么订”“停车卡怎么办”“网络故障报修”,这些问题有标准答案,直接知识库检索即可。剩下40%的复杂诉求,比如“想申请租金减免”“需要对接一家做视觉检测的供应商”,Agent会自动生成结构化工单,根据内容打上标签(如政策类、资源对接类、物业类),并流转给对应部门。

最有价值的是诉求数据沉淀后的分析。每季度我们都会用AI对历史诉求做聚类,找出企业反映集中的共性问题。一次聚类发现“周边配套餐饮太少”成为高频词,运营团队据此引进了两个快餐品牌和一家便利店,企业满意度明显提升。这就是协同的价值——物业、招商、企业服务的数据经过AI分析后,反哺了整个园区的运营决策。

3.4 企业风险预警与主动关怀

除了服务响应,企业服务团队还要关注存量企业的流失风险。企业续租与否,绝不会是突然的决定,通常会有很多前置信号:门禁刷卡频次下降、会议室预订减少、水电用量骤降、政策申报活动参与率下降、甚至开始在招聘网站同步更新多个岗位。这些信号分散在不同系统里,靠人去盯根本盯不过来。

我们训练了一个预警模型,把上述数据作为特征,输出企业流失风险等级。风险高的企业,AI会触发企业服务Agent发起定向关怀任务,例如在下一个节点安排管理层拜访、主动推送最新产业扶持政策、协调资源解决企业反映的人才招聘难题。这套机制上线半年后,我们园区的续租率提升了大概六个百分点,很难说全是AI的功劳,但至少它让团队能把有限精力花在最值得挽留的企业身上。

4. 招商引资的AI升级:让产业洞察驱动决策

4.1 基于产业链图谱的目标企业筛选

传统招商最典型的场景是政府或园区给团队下达指标——今年要引进多少家规上企业、多少家高新企业。招商人员接到任务后,开始翻行业报告、扒企业库、找中介要名单,然后一家家打电话陌拜,成功率极低。AI协同在这里能帮上大忙,但前提是我们得先建立一个适用于本园区产业链定位的企业知识图谱。

这个图谱的构建方式是:选定园区的几个优势产业方向(比如新能源、半导体设备、生物医药),然后梳理出每条产业链的上下游环节,再为每个环节挂载对应的企业库。数据源包括工商注册库、专利数据库、融资事件库、招投标网站等公开数据。图谱建好后,招商Agent可以回答“帮我找出近一年获得B轮融资、在锂电池模组环节、华东地区、团队规模50-200人的未入驻企业”这类复杂查询。

这比传统筛选方式的高明之处在于:我们不再是围绕单个企业做孤立判断,而是结合产业链完整性来做布局分析。如果园区已有三家电芯企业,缺少BMS管理系统企业,那么图谱会自动把BMS环节的候选企业推送为“高优先补链目标”,招商人员根据推荐理由针对性沟通,开场话术都能更专业。

4.2 智能评估:从人工打分到模型加权

招商项目评估是决策的关键环节。以前园区管委会开项目评审会,各人凭经验投票,经常出现“知名企业但严重不匹配园区产业定位”的项目被高票引进,结果没多久就因水土不服撤走。我们建设了一个招商智能评估模型,输入条件包括企业基本面、产业匹配度、投资强度、预期产出、环保能耗、合法性合规性等维度。

模型输出的不是简单一个分数,而是带解释的加权结论。例如某个企业评估总分75分,模型会指出“产业匹配度26/40,但预期产出只有8/20,主要原因是企业计划用地面积过大而预估亩产税收偏低”。招商团队拿到这份解释就可以提前与企业谈判条件,而不是等落地后再发现矛盾。这个模型用的不是深度神经网络,大多数权重来自专家经验法,加上历史入驻企业数据的回归拟合。好处是结果可解释,领导能看懂,团队也服气。

4.3 招商谈判辅助与全生命周期衔接

一旦目标企业进入谈判阶段,AI同样可以提供辅助。我们把企业历史公开信息、舆情数据、创始人背景、投资机构关系等整理成“企业简报”,招商人员手持一份动态更新的简报就能上场。Agent还能根据谈判进展自动生成一版“政策匹配建议”,包含可以给到的租金减免、装修补贴、人才公寓指标等,这个建议又会反过来联动企业服务团队为已签约企业准备服务包。

协同在这里体现得特别明显:招商谈成的企业信息不需要重复录入。签约后,企业档案从招商系统自动同步至企业服务和物业系统,空间资源自动锁定,装修入场、设备开启、门禁权限配置这些物业管理活动也全部通过工作流触发。新企业从签约到入驻,服务团队看到的不再是一张合同复印件,而是一串待办任务,每项任务都可以一键确认或转交。

5. 物业管理的AI协同:从被动响应到预测式维护

5.1 智能工单系统与多Agent调度

物业管理听起来离“AI”很远,实际上这部分的落地感最直观。以前园区报修流程是:企业人员打电话给前台,前台记下来转给维修班组,维修班组长根据经验安排师傅,师傅修完回来再手写工单回单。信息传递环节多、效率低,而且没有历史数据沉淀。

现在我们改造后的流程是:企业人员通过企业服务入口(网页、小程序或电话)提交报修,AI客服先通过语音识别自动生成结构化工单,包括问题类型、位置、严重程度等。工单进入调度中心后,物业Agent根据维修工技能标签、当前负荷、位置远近以及工单紧急程度,给出排序建议。如果工单是“高跳闸频率且涉及企业生产设备”,Agent会直接提升优先级并通知班长确认。维修结束后,师傅在移动端拍照上传,AI自动识别是否包含关键部位并提醒补充说明。

这套系统上线后最直观的效果是平均响应时间从45分钟缩短到18分钟。更重要的是,所有历史工单都变成了结构化数据,后续可以做故障预测和负荷分析。

5.2 设备巡检与AI视觉识别

园区的设备巡检,过去是保安和维修工按路线打卡,到了点位拍张照片完事,有没有认真看可能只有天知道。我们引入AI视觉识别和边缘计算设备,有两种落地形态:一种是在关键机房、配电房安装固定摄像头,AI自动检测仪表读数、设备指示灯状态、是否存在人员违规操作;另一种是给巡逻人员配置智能巡检终端,通过拍照自动识别设备外观异常,比如漏油、锈蚀、异响(通过声纹识别),并及时上传。

这块最大的难度不在算法,而在标签数据的积累。初期我们找了设备厂商要了大量标准设备的正常运行状态图片来训练识别模型,但是对于异常状态样本很少,模型很容易误报。后来采取的策略是“正常状态高置信识别 + 异常状态低置信提示”:如果模型不能确定设备状态,不直接报警,而是生成一条“需人工复核”的待办。经过几个月的样本补充,误报率才降到可接受水平。

5.3 能耗分析与空间利用率优化

物业成本里能耗是大头,空调和照明占总能耗的七成以上。AI协同的其中一个发力点是基于人流量和门禁数据的动态调参。我们在楼宇内布设了人员和环境传感器,将实时数据反馈给能源管理Agent。比如某楼层的会议室在上午10点到下午4点高频使用,Agent会建议空调系统在该时段加大新风量,而在晚间非工作时间自动切换为节能模式。

空间利用率优化是另一个容易被忽视的收益。通过座席传感器和门禁数据,我们定期用AI分析出哪些区域长期闲置,哪些会议室严重紧张。分析结果同时推送给招商团队,招商人员可以将闲置区域作为可扩展空间做推介;物业团队也能据此调整保洁和安保资源分配,不再对着同样面积搞“一刀切”服务。

5.4 物业管理与其他部门的联动场景

有一次巡检机器人发现B栋3层走廊湿度异常偏高,AI结合最近一周的工单记录和天气数据,推测可能是空调冷凝水管堵塞。物业Agent自动生成维修工单,同时推送企业服务Agent给同楼层的几家企业发送了一封提前告知邮件,内容包含预计施工时间及噪音影响。这样小小的一个联动,避免了企业因为不明施工而产生投诉。很多时候协同的价值不在于多么大的系统重构,而在于把这种“本来应该有人想到但通常没人能主动想到”的环节自动补上。

6. AI协同落地三大关键:知识库、Agent编排与工作流

6.1 统一知识库:所有AI应用的大脑

我们项目里最重要的一条经验是:先把知识库建好,再谈AI功能。知识库不只是FAQ文档,而是包括政策原文、园区规章制度、空间设施信息、产业研究报告、历史工单案例、企业服务流程指引等结构化和非结构化数据的总和。知识库的构建必须遵循“统一分类、统一标注、统一许可”三个原则。

具体操作上,我们把所有文档按部门、类型、敏感级别打上标签,利用嵌入模型生成向量索引,同时保留结构化字段用于过滤。比如物业绩效管理办法只允许物业经理级别及以上的账号访问,那么物业Agent在回答相关问题时,即使模型知道答案,最终展示时也需要通过权限校验。知识库每周更新,政策库有专人维护,AI初期回答错误后,我们会快速修正知识库,而不是反复调整提示词。

6.2 多Agent协作框架:让AI从“答复”走向“办事”

项目推进到中期,我们越来越觉得单点AI问答价值有限,真正能体现“协同”的是把多个AI角色组织起来干活。我们定义了几类核心Agent:服务Agent(对接企业)、招商Agent(对接投资方)、物业Agent(对接设备与工单)、运营分析Agent(负责数据分析与报告生成)。这些Agent之间通过一个内部消息总线通信,传递结构化任务对象。

举个例子,一个完整的“企业入驻”场景会被拆解成多个步骤:服务Agent发起入驻启动,招商Agent确认签约信息,物业Agent分配房间、初始化门禁和钥匙,财务Agent生成首期账单。任何一个步骤卡住,对应Agent会发消息给相关Agent要求补充信息,同时向运营人员推送待办提醒。整个过程有状态机管理,任何一步都是可回退的。

这里要提醒的是,Agent之间通信不等于完全无人接管。我们的经验是永远保留“人工审批”节点,重要动作比如免租审批、合同变更,Agent只能生成建议和草稿,最终必须由有权限的人点确认。这样既获得了效率,又不至于在AI推理出错时造成不可逆影响。

6.3 工作流引擎与系统集成注意事项

多Agent要想承载真实业务,就必须与现有系统做深度的集成。园区原有系统五花八门,有些是商业SaaS,有些是自研旧系统,有些还在用Excel加微信群。我们确定的集成策略是:以数据中台为枢纽,所有系统通过API对接,尽量不改动原系统的内部逻辑。对于没有开放API的旧系统,用RPA机器人补齐数据交互。

系统集成有个容易踩的坑:同步频率。一开始我们图省事,所有数据实时同步,结果下游系统频繁报错,数据库压力也大。后来调整策略:基础档案实时同步,业务交易数据准实时(秒级),分析统计数据定时(小时级或天级)。这样既保证了协同时效性,又不会因为琐碎更新拖垮系统。

6.4 模型迭代与效果评估方法

AI协同平台不是上线就完事的。我们在每类场景都定义了效果指标:服务场景看政策匹配准确率和诉求解决率,招商场景看评估模型推荐被采纳的比例,物业场景看工单平均响应时间和误报率。每个月拿这些指标开会复盘,定位模型表现薄弱的环节,收集新增的样本数据用于再训练。

模型迭代中特别要注意概念漂移。政策法规会变,园区业务方向会调整,企业类型也会更新。所以训练数据要留时间窗口,不能一次训完永久使用。我们的做法是每季度对核心模型做一次增量训练,每半年做一次全量评估,确保它们的判断标准没有偏离业务现状。

7. 常见问题与避坑实录

这节写几个我们在项目中实打实遇到的问题,给后来者提个醒。

第一个问题是外部数据质量参差不齐。抓取的企业工商信息、专利数据,经常出现重复、过期的问题。我们踩坑后规定:所有外部数据进入中台前都要过清洗规则,比如统一社会信用代码作为唯一键,地址、法人等字段通过规则和模型双重校验。宁可过滤一部分数据,也不要让脏数据污染AI决策。

第二个问题是AI生成内容“太正确但不适合具体园区”。大模型会一本正经地给出通用性建议,却不知道本园区实际情况。解决这个问题的办法是把知识库中关于园区自己的信息做得足够厚,不管是空置面积、租金底价,还是周边配套、过往案例,都要有准确的结构化条目。模型回答时强制绑定知识库内容,而不是凭空发挥。

第三个问题是多Agent并发协作时产生“死锁”。我们遇到过一个场景:服务Agent需要物业Agent确认会议室档期,而物业Agent又等待服务Agent提供企业联系方式,两边相互等着,流程就卡住了。后来我们在Agent框架里加入超时与升级机制,任何一个Agent发出的任务请求如果超过设定时间没有反馈,就自动转为人工处理并通知运营人员。永远不要让AI之间的交流变成黑盒。

第四个问题是用户习惯。企业内部人员刚开始不习惯跟AI对话,总觉得还是直接找熟人更快。我们在推行时选了高频低难度的场景切入,例如会议室预订、快递通知、政策分享,让员工切实感到方便,再逐步渗透到更复杂的决策辅助场景。如果一上来就强制所有人都用AI处理复杂任务,反弹必然很大。

8. 项目收益复盘与我的几点体会

项目上线运行到现在已经有十三个月。从整体数据看,企业服务团队的日常事务性工作量降低了约四成,招商线索筛选效率提升了两倍以上,物业工单响应速度提高了一半以上。最让我欣慰的不是这些数字,而是团队协作方式的变化:以前三个部门之间要靠微信群人工沟通的事情,现在很多自动流转了;过去沉淀在个人电脑里的经验数据,也开始变成组织资产。

我个人在实践中最大的体会有三点。一是AI协同项目的核心难点永远不在AI,而在数据基础和流程梳理。你连企业有多少家、工单怎么分类都没整清楚,就去买大模型,那是本末倒置。二是别指望一个超级AI搞定所有事,务实的做法是用多个专用Agent各自解决一个窄问题,再通过工作流把它们串起来。这种架构抗风险能力更强,就算单个Agent效果不理想,也方便替换或降级。

三是时刻保持对人机协作边界的敬畏。AI可以帮我们判断、推荐、提醒,但最终的决策权一定要留在人手里。有一次招商Agent推荐了一个高潜力企业,评估分数很高,但招商总监通过线下渠道了解到该企业管理层近期有重大变动,果断暂停了洽谈。后来证明这个判断是对的。类似这样的场景告诉我们:AI是协同者,不是独裁者。把AI当工具,然后让有经验的人去驾驭它,这才是产业园智慧运营走得通的路。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/1 6:03:21

C#实现DBSCAN聚类算法:直角坐标系点云分组与参数调优指南

简介:一份基于 C# 的 DBSCAN 聚类算法 WinForm 示例工程,面向学习聚类算法、从事数据分析、大数据预处理或机器视觉开发的初学者。程序启动后可在界面随机生成散点,并实时执行 DBSCAN 聚类,通过调整邻域半径 Eps、最小样本数 MinP…

作者头像 李华
网站建设 2026/10/1 6:03:13

Codex CLI 本地工作流实战:从协议原理到 Ollama 集成

1. OpenRig 不是 Codex,也不是 CLI 工具——先厘清一个被严重混淆的命名陷阱 最近在多个技术社区和开发者群聊里,频繁看到有人发问:“OpenRig 怎么安装?”“OpenRig 支持 Codex 吗?”“OpenRig CLI 报错 cc switch l…

作者头像 李华
网站建设 2026/10/1 6:02:04

WorkBuddy+微信企业级AI日报自动化架构设计

1. 这不是“发个消息”,而是一套轻量级企业级自动化工作流“我给 WorkBuddy 设了个闹钟:每天上午十点半,一份 AI 日报自动送进微信”——这句话乍看像极了某个程序员朋友在茶水间随口聊起的小技巧,但拆开来看,它其实浓…

作者头像 李华
网站建设 2026/10/1 6:01:56

苹果瑕疵检测数据集:开箱即用的YOLOv5/v8工业质检样本

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华