痛点：问到"这台梯下次什么时候检"，答案在三个人的微信里
电梯这件事，物业和设施管理者的麻烦往往不在电梯本身，而在"证明"。
场景一：维保记录在维保公司手里。 电梯每段周期都有一次维保，来的是维保单位的师傅，走的时候留一张单子。单子攒在办公室抽屉里，物业自己手上没有一本完整的账。等业委会问"这一年到底维保了几次、每次做了什么、有没有漏"，或者上级主管部门来查，只能打电话找维保公司要——要得到算运气好，要不到就只能解释。
场景二：检验到期日没人盯。 电梯属于特种设备，要按规定接受定期检验，检验合格才能继续用。下次检验日期写在检验报告上，报告进了档案柜，日期没人往日历上记。等想起来的时候，往往已经过期。这不是"补个手续"就能过去的疏忽——超期使用的责任在管理方。
场景三：困人那天发生了什么，事后说不清。 有人被困在轿厢里，按了对讲，保安跑了过去，维保师傅赶过来，人被放出来。事后写了一份情况说明，写的是"处置及时、无人员受伤"。真要复盘——几点几分接到报警、几点几分谁到场、几点几分救出、原因是什么、上次维保是哪天、同样的问题是不是第三次出现——这份说明答不上来。记录不详，等于没有记录。
三个场景指向同一个缺口：电梯管理真正要能一句话答的，是四件事——这栋楼共有几台梯、每台什么证号什么状态；这台梯的维保这个周期做了没有、谁陪着确认的；这台梯下次检验什么时候到期；这台梯出过几次事、每次怎么关掉的。
需要说明它与两篇相邻内容的边界。电梯是特种设备，不是生产设备：生产设备台账关心的是运转与停线（见 设备维保与维修工单：报修、派工、完工验收闭环），电梯关心的是"法定检验还有效吗、第三方维保有没有按期做、出事了怎么留痕"。它也不同于消防器材点检（见 消防设施点检与维保：器材台账、检查周期与到期提醒）：消防器材是"这件东西还在不在有效状态"，检查动作由自己人做；电梯的维保动作由外部维保单位执行、自己人只做陪同确认，检验由法定检验机构出具结论，责任分担的方式完全不同——这正是本篇要立起来的结构差异。
数据怎么建：六张表把责任分清楚
用 Inkwell AI 构建器做这类模块，形态是固定的：业务数据（主档 + 记录表 + 明细子表）+ 管理页面（台账、待办清单、事件看板）+ 流程闭环（事件单与整改的操作确认）+ 移动端伴同（现场确认与事件上报）。构建器会按一句需求给出数据模型与页面骨架，真正决定这套东西好不好用的，是下面这几个建模决定。
决定一：电梯台账，一台一行，不要按楼栋按型号汇总。
一台电梯占一行，绝不写成"1 号楼 2 台客梯"这种汇总行。关键字段：
- 设备编号：企业内部唯一编号，建议带项目与位置前缀（如 B1-货梯-01），设唯一约束。同一台梯出现两种叫法（"1 号梯""1-1 客梯""B 座 1 号客梯"）是最常见的脏数据来源，建档时就要把命名规则定死。
- 使用登记证编号 / 注册代码：这是对外报数、对检验报告的关键标识，一个字段一义，不要和内部设备编号合并成一个字段。内部编号先有、登记证号后到是常态（新装梯就是这样），所以两个字段都要留，允许登记证号暂空后补。
- 安装位置与规格：项目/楼栋/单元、梯型（客梯、货梯、扶梯、医梯）、层站数、载重、品牌型号、投用日期。这些是维修报价和备件询价时对方第一个会问的信息。
- 维保单位与合同：不要只写一个单位名称字符串。维保单位应引用自己的档案（名称、资质证照、联系人、电话），台账上再挂维保合同的起止日期。合同是每年最容易被漏掉的一项，到期不续等于维保断档。
- 下次检验日期：电梯场景最重要的一个日期字段。由检验记录算出，不要人手填（见决定四）。
- 当前状态：在用、停用、检修、待报废，走数据字典固定几态。停用中的梯子不产生维保待办，否则待办清单会被噪音淹没。
- 责任落点：责任部门、责任岗位（有些项目还有电梯安全管理员），一台梯没有人认领，它就会长期处于"没人管但也没人报"的状态。
决定二：维保记录一次一行，明细下挂，陪同确认是必填项。
维保记录表不能做成"每次维保填一大段文字描述"。正确的结构是：
- 主表一次维保一行：电梯引用、维保日期、维保类型（半月、季度、半年、年度——类型走数据字典，具体周期以维保合同与属地规定为准）、维保单位、执行人、物业陪同确认人、开始与结束时间、结论。
- 维保项目明细子表，一项一行：机房环境、曳引机、钢丝绳、层门门锁、安全钳、限速器、缓冲器、平层、轿厢照明与对讲等，逐项记结果（正常/需处理/已处理）。一项一行，才能事后回答"这台梯的钢丝绳上次检查是什么时候、结论是什么"。
- 陪同确认必须是系统里的字段，而不是一句"已确认"。 物业陪维保这件事的价值在于：有一个人在系统里签了字。所以陪同确认人、确认时间必须落在记录上，缺了就不允许提交。这是这套模块最硬的一条约束——它把"我们也不知道师傅来没来"变成查得到。
决定三：困人与故障单独立主表，不做成维保记录的备注。
困人、滑梯、异常停梯、门锁故障，这些不是维保记录的一条备注，而是一张需要有人负责关掉的单子。独立建主表，字段是事件时间线：
- 电梯引用、事件发生时间、报警时间、到场时间、被困人数、救出时间、事件类型（困人/滑梯/停梯/异响/其他）、初步原因分类、处置过程、责任方判定（维保不到位/使用不当/设备老化/外部原因）、关联维保记录。
- 下挂处置跟进子表，每次跟进一行、只增不改：跟进时间、跟进人、做了什么、结论。
- 关闭有条件：必须填原因分类与整改措施，并由复核人确认。困人事件在关单前还应能看到"同台梯近 N 次同类事件"——这决定了要不要追究维保质量。
决定四：检验记录单独建表，下次检验日期由系统算。
定期检验不是一次"检查动作"，而是一份有有效期、有机构、有结论的法定文书。所以建检验记录表：检验日期、检验机构、检验报告编号、检验结论（合格/整改后合格/不合格——以检验机构结论为准）、下次检验日期、不合格项与整改情况。
关键一点：下次检验日期不要手填，配成"检验日期 + 周期"由数据流规则自动算出并回写到电梯台账。 手填的日期一定会错，而且错了没人发现。周期长度以属地规定与检验报告载明为准，系统里不要预置具体月数——这一点我们在正文和模板里都不给默认值。
决定五：部件更换与维修另立流水，不进维保记录。
钢丝绳更换、曳引轮车削、门机维修、变频器更换，这些是费用与寿命管理对象，不是维保项目打勾。建一条只增不改的维修更换流水：电梯引用、日期、部件名称、规格、数量、金额分列（报价/审定）、施工单位、关联事件单。金额只在这条流水里记一次，不在电梯主档上另存"累计维修费"——主档存汇总值，后面和财务对账时一定会重复计数。
决定六：所有记录只增不改，改错就作废另起一行。
维保记录、事件跟进、检验记录、维修流水，全部遵循这一条。理由很实际：这类数据迟早要被外部核对，一旦允许覆盖，出现争议时无法解释"这条记录为什么变过"。
页面怎么用：四个角色，四个入口
同一套数据，不同的人只该看自己那一段。做"什么都有"的大页面，结果是每个人都要在一堆字段里找自己要的东西。
电梯安全管理员（PC 端，主战场）
- 电梯台账页：按项目/楼栋、梯型、状态、下次检验区间筛选。把"本月到期""已过期""停用中"做成可筛视图，让该处理的梯自己浮上来，而不是靠人一页页翻。
- 电梯详情页：一台梯一页看全——基本信息、登记证号、维保单位与合同期、历次维保记录（含陪同确认人）、历次检验记录、困人与故障事件、维修更换流水、附件（检验报告、维保单扫描件、现场照片）。这一页就是"应对一次问询"的全部材料：检验员问、业委会问、维保公司换人对接，都能当场答。
- 维保待办清单：本周期应维保多少台、已完成多少、未完成的是哪些、卡在哪台。这是整个模块最该每天打开的页面。
- 事件看板：未关闭事件按类型与超期天数排序，困人类置顶，能看出"哪几台梯反复出事"。
- 到期总览：检验到期、维保合同到期、维保单位资质到期，三张清单放一页。这三件事都属于"漏一次就麻烦"的类型。
现场陪同人（手机端，维保当天用）
维保师傅来了，物业的人拿着手机进去：从工作台打开待维保清单，点这台梯，看到本次应做的项目列表，逐项确认，拍照上传（机房现状、钢丝绳、门锁、对讲、维保单签字页），填陪同确认人，提交。现场在手机里做完，"回办公室再补"这个入口就不存在了——补录是这套系统最容易被钻的空子。
保安/客服（手机端，事件上报）
困人、异常停梯这类事件，第一个知道的往往不是管理员。所以给现场岗一个极简上报入口：选电梯（或扫不了码就按位置选）、选事件类型、填时间与被困人数、拍照、提交。后面到场时间、救出时间、原因、处置由管理员在 PC 端补齐。上报要足够简单，简单到出事那一刻有人愿意填。
维保单位对接人（外部视角的处理）
外部单位一般不直接进系统。做法是把"需要对方知道"的东西变成可导出的清单：本周期未完成维保的台数、未关闭事件、待整改的不合格项，按周期导出交给对方，对方的回复再录回系统。不要为了一个对接人给外部开账号——账号治理成本远高于导出一次清单。
自动化：把"记得做"交给系统
这类模块上线后真正省事的，是三条自动规则。构建器里的位置分别是定时任务、数据流规则和工作流。
规则一：日期由系统算，不由人填。
- 检验记录保存时，按"检验日期 + 周期"算出下次检验日期，回写到电梯台账。
- 维保记录保存时，按维保类型算出下次维保应做日期，进入待办清单。
- 维修更换与困人事件不参与日期推算，只做统计。
规则二：定时任务只做提醒，不改数据。
每天跑一次，扫三类到期：下次检验日期临近、维保合同即将到期、维保单位资质临近到期。命中的生成待办与通知推给责任岗位。同一台梯同一件事只生成一条待办，避免提醒堆积无人看。定时任务的配置方式见 工作流与定时任务：让重复性工作自动跑。
需要强调一句：提前多少天提醒，是配置项，不是内置值。 不同项目的管理习惯不一样，交付时与企业确认后录入。
规则三：保存时拦截，而不是事后报警。
能用校验拦住的，就不要靠人看。至少三条：
- 维保记录未填陪同确认人 → 不允许提交。
- 事件单未填原因分类与整改措施 → 不允许关闭。
- 检验结论为不合格的梯，状态不做自动变更，但台账页上要显式标出"待整改"标签，并在到期总览里单独列。
拦截比提醒有效得多：只发提醒不拦单据，提醒会在一周内变成背景噪音。
审批用在哪，不用在哪。 这个场景不要全量上审批。日常维保记录、事件上报都不走审批（走了就没人愿意填）；该走审批的是三类：维保单位更换或合同续签、单次维修费用超过企业自定额度、电梯停用与报废。阈值由企业自己定，交付时配置，不要预置。
移动端怎么配合：三个场景，不是把 PC 页面缩小
移动端在这个模块里不是配角，它承载的是 PC 端根本做不到的三件事：
| 场景 | 谁用 | 在手机上做什么 |
|---|---|---|
| 维保陪同确认 | 物业陪同人 | 逐项打勾、拍照、填确认人、提交 |
| 困人与故障上报 | 保安、客服、前台 | 选梯、选类型、填时间与被困人数、拍照、提交 |
| 随时查一台梯 | 管理员、值班经理 | 查状态、查上次维保、查下次检验日、查未关闭事件 |
第三项看着不起眼，但用起来最频繁：主管在楼道里被人拦住问"这台梯上次检的是哪天"，掏出手机两下查到，比回办公室翻档案有用。移动端的页面构建与 PC 端是同一套数据，PC 上建好的模块会在手机上同步出现，做法见 移动端使用指南：工作台、模块页与手机上的 AI 构建。
需要说清楚的边界：现场没信号时不要指望系统兜底。 地下机房、电梯井道附近信号差是常态，手机端提交可能失败。稳妥的做法是拍照先存在手机相册，出到有信号的地方再补录，系统里保留"实际发生时间"和"录入时间"两个字段，两者不一致不影响记录有效性，但要求如实填。纸质维保单一并留存，作为兜底凭据。
上线前查什么：八条清单
模块建完不等于能用。这类台账最容易死在"建好了但数据是空的"或"数据有了但没人用"上。上线前逐条过：
- 存量电梯补录到位没有。 一台一行录进台账，重点是设备编号、登记证号、位置、维保单位、下次检验日期。这一项不补，到期提醒就是空的——很多人以为提醒没生效，其实是台账里没有那台梯。
- 编号规则定死并写进交付说明。 谁负责建新梯档案、编号规则是什么、位置变更怎么改。规则不定，三个月后同一台梯就会有两个名字。
- 数据字典先建好再看页面。 梯型、状态、维保类型、事件类型、原因分类，五组枚举一次定死，别让各部门自己填。字典的做法见 数据字典：管好下拉选项的统一口径。
- 周期与提前提醒天数由企业确认后录入。 法定检验周期、维保周期、提醒提前量，这些不预置默认值。以企业制度与属地主管部门规定为准，落成配置项。
- 历史纸质记录怎么处理有明确口径。 我们的建议是：不逐条补录历史，只把"最近一个完整周期"的维保记录和全部在有效期内的检验报告录进去，更早的纸质件扫描挂附件。逐条补录三年历史是典型的启动期陷阱——项目会卡在这里，然后再也没上线。
- 责任人字段填满。 每台梯都有责任部门与责任岗位，且这个人清楚自己要每天打开哪个页面。空着责任人的台账模块，第一天就会退化成一堆随手拍的照片。
- 权限按角色收窄。 陪同确认人只该看到自己负责的梯；事件上报入口开放给现场岗，但关闭事件的权限限定在管理员；维修费用这类字段单独控权。权限配置见 角色与权限配置：从内置角色到自定义授权。
- 先跑一遍真实流程再宣布上线。 建议挑一台梯，完整走一遍：建档 → 生成待维保待办 → 手机陪同确认 → 造一条困人事件 → 关闭事件 → 看这份记录在详情页是不是一页看得全。这一步能暴露八成字段缺失问题。
之后怎么延伸：四条自然的下一步
这套台账跑顺之后，能接的东西都是相邻业务，不需要重搭一套系统：
- 接合同： 维保合同的到期与续签，交给合同台账统一管，不在这里再维护一遍。参见 合同台账与到期预警：关键日期不再靠人记。
- 接检验与校准： 电梯的定期检验与计量器具校准是同一种"证书有效期"结构（一台一档 + 证书到期 + 提前提醒），可以参照 计量器具与校准：一台一档，证书到期提前提醒 的做法统一口径，让两种台账在到期总览里并列。
- 接费用： 维修更换金额攒够一年后，可以做按梯型的单台年维保成本统计——但这个统计的前提是金额只在维修流水里记一次。想清楚这一层，再决定要不要做成本分析。
- 接报修入口： 租户/业主侧的报修如果已经有模块（如物业报修），事件单可以由报修单自动生成，不必让两处重复录入。
不做什么：四条边界
这类方案最容易翻车的地方，是被当成"电梯物联网平台"来要求。说清楚不做的部分，比承诺做得到的部分更有价值：
- 不做电梯硬件与物联网接入。 不接电梯控制柜、不采集运行数据（开关门次数、运行里程）、不做故障自动上报。这套模块的数据由人录入与确认，不与电梯设备通信。
- 不做困人自动报警与视频联动。 五方对讲的接入、摄像头联动、乘梯行为识别，都不在交付范围内。系统记录的是"人报上来的事件"，以及处置时间线。
- 不替代法定检验结论。 系统记录检验机构出具的结论，不做合格与否的判定，不承诺"检验一定通过"。检验周期以属地规定与检验报告载明为准。
- 不做证件与单据的自动识别。 检验报告、维保单据靠拍照上传与人工录入关键字段，不做 OCR 自动提取。也不承诺"零困人""零故障"这类结果——这套东西保证的是可查、可追、到期可见、事件有闭环，不是不出事。
一句话收口：电梯维保与年检这套模块，交付的不是一个更漂亮的档案柜，而是四个可以随时回答的问题——这台梯的证还活着吗、这个周期的维保谁确认了、下次检验哪天到期、上一次出事怎么关掉的。把这几张表的关系定对，剩下的构建器会替你把页面和数据长出来。从一句话需求开始的做法，见 AI 构建器上手：从一句话需求到可发布的业务模块。