度假村安保定岗定编:岗位梳理、编制测算与排班设计
1. 度假村安保部为什么卡在“人不够又人不少”的怪圈里接到这个项目需求时客户给我的反馈是两句完全矛盾的话。总经理说安保部人不少了夜班有人在睡觉工资一分不少发安保队长说旺季一到客人投诉找不到人保安累到请假都没人顶。这两句话放到一起其实就是很多服务型企业安保管理的真实写照——不是简单的人数问题而是岗位和编制没有跟着真实工作量走。这也是华恒智信这次给某度假村做安保部定岗定编体系设计的切入点。1.1 需求表象领导觉得人浮于事队长觉得人不够用这类项目开始前需求方内部通常已经吵过一轮。高层看到的是“人头成本”和“现场效率”之间的矛盾中层看到的是“排班没人替”和“临时任务没人接”的窘境。度假村安保部尤其明显因为它的工作时间和运营时间高度错位客人白天活动、夜晚休息但安保反而在深夜最紧张旺季客人暴增淡季客人稀少安全标准却不能随之降低。如果不先把岗位和编制讲清楚最终结果只有两种要么硬性砍人导致安全管理出漏洞要么继续按“去年多少人今年也多少人”的人头惯性运作。这两种情况我都见过太多。1.2 定岗定编不是“算人数”而是先回答三个问题很多企业把定岗定编直接理解为“减编”这是一个很危险的误解。定岗定编的真正逻辑是先根据组织目标和业务流程确定需要哪些岗位再根据岗位的标准工作量确定需要多少人最后再谈人岗匹配和排班方式。具体到这个项目里我们只围绕三个问题展开度假村安保部到底承担哪些安全职能门岗、巡逻、监控、消防检查、应急处置之间是什么关系每个岗位在常态、旺季、夜间、节假日分别有多少有效工作量哪些工作是必须完成的哪些是可以合并或由技术手段替代的按现有班次结构和员工休假制度需要多少编制才能稳定覆盖所有值守时段而不是靠“临时加班”硬撑把这三个问题回答清楚“定岗定编”这个概念才算真正落地。1.3 为什么安保部最适合先做定岗定编我当时建议客户先从安保部切入而不是一上来就做全公司全员定编是因为安保部的业务边界相对清晰可量化程度高。巡逻路线是固定的值守点位是固定的监控时间基本是全天候的突发事件的响应过程也有一套相对明确的流程。这意味着我们可以用工作写实、现场测量、排班数据分析这些工具把“感觉人手不够”变成“某岗位在某个时段确实缺口多少人”。相比之下行政、财务、市场营销这些部门的产出往往偏脑力、偏项目制测算起来主观性更强反而不适合作为定岗定编的第一批试点。先拿安保部这种“看得见、算得清”的部门做样板既好验证也容易让管理层看到方法论的可靠性。2. 项目启动后我们到底盘了什么四类信息收集与岗位梳理定岗定编最怕“坐在办公室里拍脑袋”。很多人力资源顾问拿到一张组织架构图就开始算编制但真正到了现场才会发现架构图上的“巡逻岗”和实际巡逻路线根本不是一回事。2.1 信息收集的入口岗位说明书、排班表、巡逻路线、事件记录这次项目开始后我们花了将近一周时间做信息收集主要分四类数据类别来源渠道要回答的问题岗位文件岗位说明书、现有编制表、部门职责清单岗位设置是否重复、职责边界是否清晰排班数据过去6个月排班表、考勤记录、加班申请人员到底覆盖了哪些班次是否存在靠加班补位工作量数据巡逻打点记录、门禁记录、值班日志、事件报告每个班次实际工作量有多大忙闲时段如何分布行为数据现场跟岗写实、监控抽查、员工访谈制度要求的标准动作是否被执行哪些环节存在“磨洋工”这其中最容易被忽略的是事件记录。安保部门的日常工作里突发事件虽然只占一小部分但恰恰是它决定了“最低人员配置”。如果只看常规巡逻时间会得出“人手富余”的结论一旦把夜间醉酒客人处理、消防主机报警、停车场纠纷等事件频次加进去编制口径马上就不一样了。2.2 把巡逻路线跑一遍用“测量观察”取代“感觉”做安保类岗位测算我非常建议咨询顾问或者人力资源负责人亲自把巡逻路线走一遍。这个项目里度假村的巡逻路线覆盖客房区、餐饮区、湖滨步道、停车场和后勤区一圈走下来大概2.8公里。一开始我们按普通人步行速度估算2.8公里大概需要35分钟。但跟着保安员实际走了一遍之后发现全程要打点、要检查消防栓、要留意可疑人员、要在岔路口停留观察同时还要用对讲机回应监控岗的呼叫。一圈走下来通常要45到50分钟遇到节假日客人问路、有人醉酒、车辆占道时间会更长。这就是“纸面数据”和“真实工作量”的差异。如果只按地图距离去测编制一定算少了。2.3 岗位工作量的“忙闲结构”分析信息收齐后我们把安保部的主要岗位按“忙闲结构”拆开看门岗早晚上下班、客人进出高峰非常忙碌深夜相对安静但岗位本身不能离人因为它是第一道安全关口。巡逻岗白天餐饮区、后勤区人员流动频繁处理求助和纠纷较多深夜巡逻频次可以调整但安全风险更高不能简单地按“没人就是没事”来减配。监控岗全天候需要有人盯守同时负责消防主机、电梯对讲、异常报警夜间容易疲劳单人长时间值守存在隐患。消防巡检岗通常按规范频次执行比如每日两次重点部位巡查工作量相对固定但培训、持证、应急处置要求高。做这个分析时我们发现度假村安保部最典型的问题是“忙闲错配”白天大量保安员集中在门岗和巡逻线上到了夜间反而只剩下最低配置一旦出现突发事件最近的支援力量可能要跑几百米甚至更远。编制总量看起来不低实际有效覆盖并不均衡。3. 从岗位职责到编制测算把安保工作量变成可计算的人数信息收集完成之后真正核心的部分就是编制测算。我的做法是把每个岗位每天的工作量拆成可计算的动作再换算成人头数。这样才能让管理层心服口服而不是听你说“我觉得要加一个人”。3.1 用工作写实法给每个岗位定“标准工时”工作写实听起来很复杂其实就是选定淡季、平季、旺季各几个代表性班次跟在员工身边记录他每一个动作的起止时间。比如门岗保安从早上的车辆引导、访客登记到晚饭后的客人问询、夜间巡查每个动作都要记下来然后剔除掉正常的等待和休息时间得出“标准作业工时”。一个比较典型的算法是岗位日有效工时 Σ各项任务标准时间 × 标准频次理论编制人数 岗位日有效工时 ÷ 单人每日有效工时举个例子。白班巡逻岗的工作量可以这样测算巡逻6次每次45分钟合计270分钟消防设施巡查2次每次20分钟合计40分钟车辆疏导和客流引导4次每次10分钟合计40分钟处理客人求助或纠纷2次每次15分钟合计30分钟交接班准备约20分钟。加起来是400分钟约6.7小时。按8小时工作制、85%工时利用率计算单人每日有效工时约为6.8小时理论上一个白班巡逻岗配1个人刚好但几乎没有缓冲。一旦遇到突发事件、员工培训、临时请假这个岗位就会立刻出现缺口。所以真正定编时不能只算理论值还要加机动系数。3.2 巡逻、值守、监控三类岗位要分开算很多企业算安保编制时喜欢“一个岗位一个人”地排这是把问题想简单了。正确的做法是按岗位性质分类测算巡逻类岗位按“路线长度 × 巡逻频次 × 单次耗时”计算。比如某条路线单次需要45分钟规定每2小时巡一次24小时内总共12次那么单日这项任务需要9小时再叠加其他任务后才能得出这个岗位需要几个人轮转。值守类岗位按“点位数 × 班次数 × 倒班系数”计算。24小时需要有人在岗的岗位无论夜里有没有事编制都不能省。倒班系数通常要考虑员工每周休息、法定节假日、年假、培训等因素一个24小时值守点位的实际定编一般在4.2到5.5人之间具体取决于排班方式。监控类岗位按“屏幕数量 × 注意力持续时间 × 交接频次”计算。监控岗的疲劳度很高一个人长时间盯屏会导致漏看率上升所以既不能按“一屏一人”来配也不能为了省人让一人同时盯几十个画面。这三类岗位的测算逻辑完全不同混在一起算就会出现“门岗多了监控岗少了”的结构性错配。3.3 淡旺季“弹性系数”到底怎么给度假村的经营特点是淡旺季非常明显安保工作量也会随之波动。给弹性系数时不能简简单单地乘以1.2或1.5就完事而是要用工作量数据来反推。这次我们做了一个简单测算把淡季某个巡逻岗的日均有效工作量定为基准值再把旺季周末最大客流时段的工作量统计出来。假设淡季日均任务是5.2小时旺季日均任务是7.8小时那旺季系数就是7.8除以5.2约1.5。这意味着旺季需要在淡季基础编制上增加约50%的人员弹性。但这个弹性不宜全部进入正式编制而是通过临时用工、内部支援、延长排班班次等方式消化否则到了淡季就会出现大量窝工成本。4. 安保部定岗定编方案长什么样岗位序列、编制口径与排班设计测算完成之后就要形成可落地的方案。这部分最考验专业能力因为方案不仅是一张人数表还要回答“怎么排班”“谁来管”“临时缺人了怎么办”这些现实问题。4.1 岗位序列管理、技术、操作三类分开设计安保部门看起来都是“保安员”但内部其实是三类不同性质的岗位岗位序列典型岗位编制逻辑管理类安保经理、安保主管/队长按管理幅度和班次数量配置不能脱产技术类消防中控员、监控值班员按设备数量、值守时长、持证要求配置操作类门岗、巡逻岗、车场岗按点位覆盖、巡逻频次、忙闲时段配置管理类岗位最容易超编。有些度假村一个小安保部配了四五个“队长”每个队长只管两三个人结果现场遇到问题还是要普通保安员去解决。我们当时的建议是主管和队长必须兼着巡逻督导、应急处置的职责不能变成纯粹的“脱产干部”。技术类岗位有一个容易被忽视的点就是持证要求。消防中控员需要有消防设施操作员证这个证不是随便找人就能顶上的。所以定编时不能只算人头还要算出“有多少个持有有效证件的人可以排进班次”。证书不足岗位编制再合理也排不出来。4.2 排班方案8小时三班倒还是12小时两班倒定编和排班是两件事但实际落地时它们必须一起考虑。同样的一个24小时值守点位用8小时三班倒和用12小时两班倒需要的编制人数、员工疲劳度、交接成本完全不一样。排班方式优点缺点适用场景8小时三班倒劳动强度均衡、培训时间多、利于发现隐患交接次数多、每人覆盖天数少、需要人数多门岗、消防中控岗12小时两班倒交接次数少、员工连续休息时间多、人数需求略低夜班疲劳度高、连续在岗时间长、管理难度大巡逻岗、偏远点位、通勤成本高的岗位这次项目里我们对不同岗位采用了不同排班策略。核心门岗和消防监控岗保留8小时班次保证人员状态稳定相对偏远的巡逻点位调整为12小时班次减少交接中出现的信息断层。两个班次之间还加了半小时重叠时间用于交接重点事项这半小时的成本不能省。4.3 编外弹性池临时用工和内部支援怎么管度假村安保还有一个现实问题旺季人手不够淡季养不起那么多人。所以我们在方案里设计了三级弹性用人机制第一层员工自愿加班但设置月度上限避免疲劳作业第二层内部安全联络员由礼宾部、客服部、工程部里受过消防和急救培训的员工兼任旺季或大型活动时抽调第三层外部保安公司临时支援明确合同中的监管责任和服务标准不能“把人派过来就完事”。这里要提醒一点外部支援人员的管理界面必须提前说清楚。是归安保队长统一指挥还是只负责指定点位出了问题由谁承担责任这些在定编方案里都要有对应口径否则临时用工越多管理风险越大。5. 落地推进数据争论、部门博弈与验收标准定岗定编方案做得再好落不了地也是废纸。这个阶段往往会遇到各种阻力有来自部门负责人的也有来自员工层面的。5.1 试点先行先调排班再调人头我们的原则是“先调班次再动人头”。因为排班调整不涉及减员降薪员工抵触小但能立刻检验编制测算是否合理。当时先选了门岗和一个靠近主入口的巡逻片区做两周试点把原来的固定班次改成动态班次白天客流大的时候加强门岗和车辆引导夜间则把人力向监控和重点楼道倾斜。试点期间暴露出一个问题白班有些人确实闲下来了管理层看到后第一反应是“可以把这些人砍掉”。但我们拦住了这个动作。短期的“闲”可能只是因为客流量还没上来不代表这个岗位冗余。把观测期拉长到覆盖一个完整周末和一个大型宴会场景后再对数据做判断结论才靠谱。5.2 不把“减人”当结果而是把“人放到更需要的地方”这个项目在沟通会议上安保队长最关心的就是“会不会裁员”。我们反复强调定岗定编不是简单减编至少在这次测算中保安员总编制数量变化不大真正改变的是岗位结构和排班结构。比如原来门岗白班有3个人站在那里高峰期还忙不过来夜间只有1个人值守客人喝多了闹事都没法快速支援。调整后白班门岗缩成2人把多出来的人补进巡逻联动岗既解决白天人力资源浪费也解决夜间响应距离远的问题。员工看到方案后情绪明显缓和因为没有人被直接裁掉反而排班更合理。5.3 用三个月的考勤与巡逻数据做验证方案落地后我们设了三个验证指标巡逻到位率是否按规定的频次和路线完成打点突发事件平均响应时间从呼叫到人员到场花了多久员工加班时长和请假率是否出现新的疲劳和离职风险。三个月后回访时门岗高峰期的排队投诉下降夜间突发事件的到场速度比原来快了不少员工因为排班导致的请假人数也在下降。更重要的是安保队长终于能拿出数据说明白“哪段时间真的缺人”而不是再靠喊。6. 复盘之后最值得带走的经验项目结束后我个人复盘了很久。安保部定岗定编这件事表面上是算人头本质上是在算“安全责任怎么分配”。如果只把它当成编制核定工具很难让业务部门认同。6.1 从“按人头预算”到“按工作量预算”大多数企业做年度人力预算时用的是“今年多少人明年加几个”的逻辑。安保部门尤其容易这样因为管理层觉得安全工作是“成本”只要不出事就行。但实际做完这个项目后你会发现更值得推荐的预算是“工作量预算”先把每个岗位的年度工作总量算出来再折算成标准编制然后乘以该岗位的薪酬单价。这样无论以后客流量怎么变都能快速推算出人力需求而不是等旺季来了再临时抢人。6.2 安保定岗定编的常见误区结合这次案例和我过往的经验整理出几个高频误区把岗位空闲等同于人员冗余。值守类岗位的“空闲”本质上就是安全储备没出事不代表不需要人。只算岗位数不算班次数。一个岗位如果三班倒一个班次需要1人实际至少需要4到5人而不是三个岗位配3个人。忽略临时替班机制。没有机动编制员工一请假就需要队长顶岗队长一顶岗管理就瘫痪。照搬同行业编制标准。同为度假村有的占地20万平方米有的只有80间客房安全风险完全不在一个量级照搬无异于刻舟求剑。6.3 最后分享一个小技巧每次给客户交付定岗定编方案我都会让对方拿三个问题来“拷问”方案夜里凌晨两点这个岗位出事谁负责旺季最大客流的那个小时安保力量在哪里临时有人请假时岗位职责怎么交接任何一份方案如果在这三个问题上答得含糊就说明还没真正落地。这也是我做完这个度假村安保部项目后最深的一点体会定岗定编不是扔出一张人数表而是要让人力配置在任何时间、任何场景下都经得起安全考验。能把这一点想透方案才算真的有价值。

相关新闻

声子晶体仿真:三角晶格与六角晶格的能带计算实战

声子晶体仿真:三角晶格与六角晶格的能带计算实战

如果你做过一段时间的声子晶体仿真,应该会跟我一样,在第一次接触三角晶格和六角晶格时被名字绕晕。这篇内容我整理了在Comsol中从零搭建两种晶格模型、跑能带、提取数据的一系列实操经验。不绕理论,重点讲清楚为什么三角晶格和六角晶格在单胞…

2026/10/14 2:46:54 阅读更多 →
零代码搭建MCP Server:1Panel、Cline与FastAPI三大实战路线

零代码搭建MCP Server:1Panel、Cline与FastAPI三大实战路线

简介:面向已有一定AI工具使用经验、希望为其扩展外部能力的开发者和技术爱好者,一份docx文档系统梳理了零代码搭建MCP Server的完整路径。内容以“翻译官”比喻阐明MCP Server如何让AI理解复杂上下文并调用外部工具,重点给出三类方案&#xf…

2026/10/13 0:01:58 阅读更多 →
GitHub Copilot 学生认证后,Base URL 改到 TaoToken 的完整配置与验证

GitHub Copilot 学生认证后,Base URL 改到 TaoToken 的完整配置与验证

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

2026/10/13 0:01:58 阅读更多 →

最新新闻

2026 PCSX2 开源PS2模拟器:2500款老游戏在PC上稳跑

2026 PCSX2 开源PS2模拟器:2500款老游戏在PC上稳跑

2026 PCSX2 开源PS2模拟器:2500款老游戏在PC上稳跑 【免费下载链接】pcsx2 PCSX2 - The Playstation 2 Emulator 项目地址: https://gitcode.com/GitHub_Trending/pc/pcsx2 把BIOS文件丢进一个文件夹,拖入一张光盘镜像,PS2的开机动画就…

2026/10/14 2:46:28 阅读更多 →
CDL网表与LVS实战:从语法到版图提取的避坑指南

CDL网表与LVS实战:从语法到版图提取的避坑指南

简介:电路描述语言(CDL)教学演示文稿围绕C17基准电路,系统讲解如何用该语言描述电路结构、连接关系和逻辑功能,面向数字电路课程学习者、EDA入门者及需要完成电路描述实验报告的学生。内容先梳理语法规则,将…

2026/10/14 2:46:28 阅读更多 →
仓颉标准库 std.argopt 命令行参数解析指南:parseArguments 与 ArgumentSpec 实战详解

仓颉标准库 std.argopt 命令行参数解析指南:parseArguments 与 ArgumentSpec 实战详解

人工智能AI 技能文档开发工具 【免费下载链接】DocAgent 项目地址: https://gitcode.com/Cangjie-SIG/DocAgent 点击查看 免费下载 std.argopt 是仓颉(Cangjie)标准库中负责命令行参数解析的包,它提供从命令行参数字符串中解析出…

2026/10/14 2:46:28 阅读更多 →
LinkSwift:如何快速简单地完成网盘直链解析,一键拿到 8 大网盘直链

LinkSwift:如何快速简单地完成网盘直链解析,一键拿到 8 大网盘直链

LinkSwift:如何快速简单地完成网盘直链解析,一键拿到 8 大网盘直链 【免费下载链接】Online-disk-direct-link-download-assistant 一个基于 JavaScript 的网盘文件下载地址获取工具。基于【网盘直链下载助手】修改 ,支持 百度网盘 / 阿里云盘…

2026/10/14 2:46:28 阅读更多 →
Spring Data JPA实战:实体映射、事务控制与N+1优化

Spring Data JPA实战:实体映射、事务控制与N+1优化

1. 项目概述:为什么一个“JPA实战Demo”值得花三小时重写五遍你是不是也经历过这样的场景:刚学完JPA的基础注解——Entity、Id、GeneratedValue,信心满满地新建一个User类,跑起来却报org.hibernate.MappingException: Unknown ent…

2026/10/14 2:46:28 阅读更多 →
Vue 3 轻量级数据透视表组件:支持拖拽+聚合+Excel导出

Vue 3 轻量级数据透视表组件:支持拖拽+聚合+Excel导出

简介:这是一份面向Vue.js中高级开发者的数据透视表功能实现组件包,专为需要在Web应用中快速集成交互式聚合分析表格的前端工程师设计。资源提供两个核心Vue组件:支持拖放配置行列的完整数据透视表,以及轻量级仅聚合功能的PivotTab…

2026/10/14 2:45:28 阅读更多 →

日新闻

AnyPS5通用适配层设计:兼容性与性能的工程取舍

AnyPS5通用适配层设计:兼容性与性能的工程取舍

1. 从"AnyPS5"这个名字说起:它到底想解决什么问题第一次看到"AnyPS5"这个标题,我脑子里冒出来的第一个念头是:这大概率是一个围绕"跨平台运行"或者"通用适配"做文章的项目。名字里的"Any"…

2026/10/14 0:00:41 阅读更多 →
Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

1. 项目概述:Flutter跨平台二手交易应用开发作为一名长期从事移动应用开发的工程师,我最近完成了一个基于Flutter框架的二手物品交易平台项目。这个项目最吸引我的地方在于它完美结合了Flutter的跨平台优势与HarmonyOS的生态特性,实现了"…

2026/10/14 0:00:41 阅读更多 →
DFS算法解决飞机降落调度问题实战

DFS算法解决飞机降落调度问题实战

1. 项目背景与核心思路飞机降落问题是一个经典的调度优化场景,也是算法竞赛和面试中的高频题目。这个题目要求我们合理安排多架飞机的降落顺序和时间,确保所有飞机都能安全着陆而不发生冲突。在实际航空管制中,这类问题直接关系到飞行安全和机…

2026/10/14 0:00:41 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/13 2:54:56 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/13 16:22:04 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/13 1:58:08 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

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

2026/10/13 22:01:27 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

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

2026/10/13 14:57:39 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

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

2026/10/12 18:11:17 阅读更多 →