痛点：保单散在各处，到期靠别人提醒，理赔卡在哪没人说得清
企业里的保险通常是一张很杂的清单：办公室和仓库有财产险，生产线有机器损坏险，几十台车各有交强险和商业险，一线工人有雇主责任险，员工与家属有团体意外与医疗险，做出口的还有货物运输险。这些保单由行政、人事、车队、财务分别经办，纸质正本锁在档案柜，电子版散落在经办人的邮箱和微信里。
于是每年都在重复三类事故。
脱保。 续保提醒掌握在保险业务员手里，业务员换了人、公司换了经纪公司，提醒就断了。等发现的时候，某台车的交强险已经过期两个月，或者厂房财产险在台风季前断了保。
理赔没人跟。 出险后报了案，然后是漫长等待：材料哪里不齐、定损定了多少、核赔走到哪一步，只有经办的同事知道。这位同事一休假，进度就成了黑箱。年底财务问「上回那笔赔款到账没」，答案是去翻聊天记录。
决策没依据。 老板想知道今年保费一共花了多少、各险种分别花了多少、哪几类事故赔得最多，行政只能给出一叠保单复印件。哪个险种该加保、哪个可以调低，全凭感觉。
这三类事故的共同根源，不是公司不重视保险，而是保单和理赔里的关键要素没有被结构化。起止日期、险种、保额、标的清单、赔付进度，只要还躺在 PDF 和聊天记录里，系统就没法替你盯着它们。要解决的不是「再买一个文件柜」，而是把这些要素变成一张可查询、可计算、可提醒的台账。
这正是 Inkwell AI 构建器能接住的一类活：用业务语言描述需求，AI 生成一个包含数据模型、管理页面、审批与提醒的完整模块，PC 端建好后移动端同步可用。下面按「数据怎么建 → 页面怎么用 → 自动化怎么跑 → 上线前查什么」的顺序讲清楚。
数据怎么建：两张主表、三张子表，别把一次出险塞进保单里
数据模型（可以理解为系统里的「表结构」，决定每条记录能存哪些字段）定得好不好，直接决定这套台账能不能回答老板的问题。保单场景最容易踩的坑，是图省事把所有信息堆在一张表里。下面六个设计决定，是这类台账跑得顺的关键。
决定一：保单是一张主表，一张保单一行。 主表记录保险单编号、保险公司、险种、被保险人范围、保额、保费、起止日期、缴费方式、经纪或业务员联系方式、当前状态。险种一定要走平台的数据字典集中维护（下拉选项的统一口径，见数据字典：管好下拉选项的统一口径），否则有人选「财产一切险」有人手填「财产险」，后面的分类统计就散了。状态也固定成几态：有效 / 即将到期 / 已过期未续保 / 已续保 / 已退保 / 已终止。
决定二：标的不塞备注，拆成明细子表。 一张保单往往保的是多个对象：一张车险保一台车，一张财产险保几个场所，一张团体意外险保几十个人。如果把这些信息写成主表里一段备注文字，就没法单独查「3 号车间在哪张保单下」「某位员工的意外险什么时候到期」。做法是一单多标的、子表一标的一行：车险挂车牌与车架号，财产险挂场所与资产编号，团意险挂人员（用平台的引用引擎跨模块取员工档案，选人而不是手打名字）。子表拆开之后，按标的反查保单才成立。
决定三：缴费计划也拆子表。 保费常有分期：签单付一笔，年中付一笔。子表一行一期，记期次、计划缴费日期、金额、实付日期与凭证附件。这样财务要的「本月应付保费」就是一次筛选，而不是翻保单看条款。
决定四：理赔单独建一张主表，挂在保单旁边而不是里面。 这是最容易被做错的一处。一次出险一条记录，独立编号，用引用字段关联到具体保单；同时记录出险时间、出险地点、事故类型、报案号、报损金额、定损金额、已赔金额、结案日期与状态。原因是：一张保单一年可能出险三次，也可能三年不出险，把「理赔状态」做成保单上的一个字段，第二次出险时历史就被覆盖了。理赔状态同样用字典固定几态：已报案 / 查勘中 / 定损中 / 待补材料 / 核赔中 / 已赔付 / 已拒赔 / 已结案。
决定五：理赔的过程节点与材料清单再拆一层子表，且只增不改。 一条理赔下面挂节点记录：日期、节点名称、经办人、本次提交或补充的材料、备注。要求「只增不改、更正另起一行」，是为了保住过程痕迹——半年后要复盘「为什么这笔赔款拖了四个月」，看的就是这串节点。材料原件（现场照片、事故证明、维修发票、诊断证明）走平台的文件存储上传，跟着节点归档。
决定六：续保不覆盖旧记录，新建一行并注明「续保自哪张保单」。 续保时如果直接把原保单的到期日往后改，去年、前年的保费数据就被一并改写了，年度支出统计立刻失真。正确做法是新建一条保单记录，用引用字段指向被续保的旧保单，旧保单状态置为「已续保」。同理，退保、批改保额也建议新建记录或走审批留痕，而不是静默修改历史行。
按这六条建完，两个问题就自然有了答案：这张保单保了什么、还差多少钱没付；这次出险赔到哪一步、还缺哪些材料。后续要做保险合同文本的归档与续签管理，结构与合同台账与到期预警那套是对齐的——保单本质上是合同的一种，只是多了一层标的清单和理赔过程。## 页面怎么用：一套数据，四种人看到四种视图
数据模型建好后，构建器会生成配套的增删改查页面。真正的落地工作，是按使用角色把这些页面组织成各自顺手的样子，而不是让所有人看同一张全量表。
行政/风控：保单台账列表。 默认按到期日升序排列「有效」和「即将到期」的保单，支持按险种、保险公司、经办部门、状态组合筛选；金额列自动汇总当前筛选结果的保费合计——老板问「今年团体险花了多少」，两次点击出答案。列表行按到期紧迫度标色：三十天内到期高亮提示，已过期未续保单独标红，规则交给数据流引擎算，不靠人工盯表。同一页面上还可以放一组汇总块：本年度保费支出按险种分布、即将到期的保单数量。
理赔经办：理赔跟进工作台。 按状态分组的看板式视图，把「待补材料」「核赔中」这两列放在最显眼位置，卡在某一环超过约定天数的记录单独标记——这类天数阈值按企业自己的管理要求配，系统只负责把「超期没动」亮出来。点进一条理赔是详情页：上半部分是出险信息与金额四个口径（报损、定损、已赔、差额），下半部分是节点时间线，谁在什么时候补了什么材料一目了然，最后是附件区。
财务：缴费与赔付视图。 一张按计划缴费日期排的清单，本月应付、已付、逾期三态分明，逾期项直接推到经办人的待办里。另一张是赔付到账清单：已结案但赔款未到账的记录单独列出，避免「案子结了、钱没收到」这种静默损失。
领导/老板：年度汇总页。 按险种、按年度统计保费支出与赔付金额，看清钱花在哪、赔了多少。这里有一个必须讲清的口径问题：赔付金额来自系统里登记的理赔记录，是「已登记」而不是「保险公司最终核定」的全量事实；想让这张汇总页可信，前提是理赔登记不漏——这正是把理赔搬进系统的主要理由。汇总页只呈现系统内记录的事实，不做赔付率承诺，也不预测次年保费。
四个视图共用同一套数据，区别只在筛选条件、列的取舍和权限范围。页面本身不需要写代码，用自然语言告诉构建器「我要一个按状态分组的理赔看板，超期未更新的标黄」就能调出来。
自动化怎么跑：四类规则替你记日期、盯进度
台账建好只是把信息搬进了系统；真正解决「靠人记」的是这一层自动化。平台提供四类现成能力，组合起来就能覆盖保单管理的主要时序动作。
一、到期与缴费提醒（定时任务 + 站内通知）。 平台的定时任务引擎按 Cron 表达式配置执行计划，可在页面上管理，不用改代码（参见工作流与定时任务）。给这套台账配三条每日任务：
- 扫描有效保单，对距到期日六十天、三十天、七天三个阈值的保单各发一次提醒，收件人是保单经办人；
- 扫描缴费计划子表，对「计划日期在七日内」和「已逾期未付」的期次提醒财务与经办人；
- 扫描理赔主表，对停留在同一状态超过阈值的记录提醒理赔经办人与风控负责人。
提醒走平台的站内信与通知能力发出，登录后有待办角标，点开直达对应记录。阈值天数做成系统配置项，管理要求变了改配置即可，不用重新构建模块。
二、状态推进与审批（工作流）。 理赔的关键动作建议走审批：接受赔付方案、放弃索赔、结案归档这类决定一旦定下就难反悔，让它在平台上留下审批意见与签署人，比在微信里说一句「就这样吧」稳得多。用平台的工作流引擎可视化配置节点（见工作流可视化编辑器），审批通过后自动把理赔状态推进到下一态，审批记录同时留在流程执行历史里。
三、数据流规则（条件触发的自动处理）。 数据流引擎管的是「满足什么条件就自动做什么」这类判断，适合处理那些容易漏看的口径异常：保单到期日已过且状态仍是「有效」→ 自动置为「已过期未续保」并通知；定损金额小于已赔金额 → 标黄提示核对；缴费计划各期合计与保单保费总额不一致 → 在详情页给出差异提示。这类规则不用写代码，配置即生效。
四、审计留痕。 保额、保费、赔付金额都属于敏感数据，谁改过、改前是什么、什么时候改的，由平台的操作审计日志自动记录，导出动作同样留痕（能力说明见AI 监控与审计日志）。理赔材料里常有身份证明、诊断证明，查看与下载范围要在角色权限里收口，别让全公司都能翻到。## 移动端：出险现场的那五分钟，决定后面三个月跟不跟得动
理赔拖得久，十次有八次不是保险公司慢，而是第一时间该留的东西没留下：出事时没拍现场，等想起来已经清理完了；事故证明当时没开，事后补办要跑好几趟；材料交了一轮又一轮，每次都说「还差一份」。把这些动作压到出险后的头五分钟，后面就顺。
PC 端建好的模块会自动同步出移动端页面（机制见移动端使用指南），对这套台账来说，手机上的主战场就三个：
- 现场报案：在手机上新建一条理赔记录，选关联保单、填出险时间地点与事故类型、上传现场照片与当事单据，直接把状态置为「已报案」。人还在现场，信息已经进了系统。
- 进度查看：领导出差时想看某张保单的保额、某笔理赔赔到哪一步，手机上点开就能看，不用打电话问行政。
- 待办处理：到期提醒与超期提示推送到待办里，经办人直接在手机上跟进、补材料、写节点备注。
行政在工地、仓库、4S 店现场时，这套组合最有用；回到办公室再用 PC 端做汇总与对账。两端是同一套数据，不存在「手机填一遍、电脑再录一遍」。
上线前查什么：七件事逐条过一遍
平台的模块发布前有预检环节，能把技术层面的错拦住；业务口径对不对，还得靠人拿真实数据试一遍。建议按这七条核对。
- 字典口径：险种分类与公司实际持有的保单是否对得上？把现有保单摞起来，按实际类别数一遍，看每个类别有没有地方填。理赔状态字典也要与实际流程核对——有些公司的流程里没有「查勘」这一环，多一个状态反而让人不敢推进。
- 历史数据怎么进来：存量保单不必一条条手录。把原来的 Excel 保单清单整理成标准表头，用平台的 Excel 导入能力一次性带进来（做法见用 Excel 一步建模块）；导入后抽样核对金额与日期，尤其注意日期格式被识别成文本这类问题。
- 日期边界：保单到期日晚于起保日的校验、缴费计划日期是否必须落在保单期间内，都要验。故意录一条反的，系统应该拦下并给出人话提示。
- 金额口径：保额、保费、报损、定损、已赔这五个数容易混。分别录一遍，确认列表、详情、汇总三处显示一致且带千分位；再试一期「缴费合计不等于保费总额」的数据，看有没有差异提示。
- 提醒真跑一遍：把定时任务临时调到几分钟后执行，用一条明天到期的测试保单、一条逾期缴费计划、一条卡在「待补材料」的测试理赔，分别验证提醒发出、点得开、收件人正确。测完调回每日计划并删除测试数据。
- 权限与敏感字段：按角色核对——业务部门能不能看到别的部门的保单保费？理赔材料（诊断证明、身份证明）是否只有风控与经办可见？导出有没有留痕？方法见角色与权限配置。
- 发布与灰度：先发布给行政与财务两个部门试跑两周，稳定后再放开给业务部门，发布流程与预检项见模块的测试与发布。
之后怎么延伸：从台账长成风控看板
这套台账跑顺之后，往外延伸的路径很自然，每一步都是在已有模块上加引用、加规则，不用推倒重建：
- 标的与资产打通：财产险的标的本就是固定资产，把标的子表的资产编号指向固定资产台账，保额与实际净值放在一起看，加保减保就有了依据。
- 被保险人与人员打通：团体意外险的被保险人引用员工档案，员工入职、离职时自动暴露「该加保」「该减保」的名单差异，避免离职人员还在保、新人却漏保。
- 续保决策有据：按险种看历年的保费与赔付记录，续保谈判时手里有事实，而不是只记得「去年好像赔过一次」。
- 事故预防：把理赔里的高频事故类型（车辆剐蹭、货物破损、机械伤害）导回安全管理，反过来指导培训与检查重点——这是台账之外真正的价值。
这套方案不做什么
把边界说清楚，比夸大能力有用：
- 不做核保与报价测算。 该不该保、费率多少、免赔额怎么设，是保险公司与经纪的专业判断，系统只记录你实际投了哪些保、出了哪些险。
- 不与保险公司系统做自动对接。 报案、定损、赔付金额的最终确认在保险公司一侧；本方案记录的是企业自己掌握的进度与结果，不做跨系统的自动报文。
- 不做扫描件字段自动识别。 纸质保单与理赔材料以附件形式归档、靠人工录入关键字段；想让历史保单一次性批量识别，需要另配识别能力。
- 不承诺赔付结果。 赔不赔、赔多少由保险公司按条款核定，系统能做的是让材料齐、进度清、责任明。
- 不做实时定位与人员轨迹。 出险地点是按文字登记的，车辆与人员的位置不在此方案范围内。
如果贵司现在正有一叠没人盯的保单、几笔拖着没结的理赔，建议从最小版本起步：先建保单主表加到期提醒，两周内让「哪张保单什么时候到期」这件事不再靠人记；第二版补上缴费计划与理赔主表；第三版再加节点子表与状态看板。业务语言描述需求、AI 生成模块、PC 与手机同步可用——这条路径在AI 构建器操作手册里有完整的操作步骤。