访客这件事，问题从来不在登记本身
门口放一本登记簿，看起来是最省钱的做法。真正让行政和安全头疼的，是这本簿子之外的几件事：
- 该来的进不来、不该来的进来了。 客户按时到访，前台不知道有约；推销员套一句"找你们王总"就跟着人进了电梯。
- 来访事由写不清楚。 登记簿上多半是"洽谈"两个字，出了事回头查，既不知道他去了哪个楼层，也不知道谁接待的。
- 在访人数是个黑箱。 下班后楼里还有没有外来人员、消防演练要清场时谁还留着，只能挨个楼层喊。
- 离场没有闭环。 人走了没人划掉，访客卡没还回来，台账上永远挂着一批"还在楼里"的记录。
- 园区多门、厂区车间要单独管控。 访客从大门进来之后，能不能进车间、能不能靠近产线，两套规矩，靠门岗师傅凭脸记。
这是一类典型的"点状痛点"模块：业务不复杂，但涉及预约、到岗、核验、放行、离场几个环节，纸单和微信群接不住。用 Inkwell AI 构建器把它做成一个业务模块，成本远低于上一套专用访客机系统，而且能和现有的部门、员工、权限体系打通——被访人是谁、属于哪个部门，系统里本来就有。
下面按"数据怎么建 → 页面怎么用 → 移动端怎么配合 → 上线前查什么"的顺序讲清楚。
第一步：把数据建对，五张表撑起整条链
访客管理的坑，八成出在数据建错——把预约、来访、通行混在一张表里，后面所有统计都做不出来。建议按下面五张主表拆开，字段可以按自家情况增减。
1）访客预约单（一条预约就是一条记录）
主键建议用系统自带的编号规则生成"预约号"，方便门岗口报和电话查询。核心字段：
- 被访人（人员和部门从现有组织架构里选，不要手打姓名）
- 来访单位（建议做成可复用的选项数据，老客户第二次来不用重录）
- 来访事由（做成下拉字典：业务洽谈 / 面试 / 送样 / 施工维修 / 设备保养 / 政府检查 / 其他）
- 预计来访时间、预计离开时间（两个日期时间字段，缺一不可）
- 来访人数、随行人员（人数用于门岗预判放行方式，随行人员建议单独一张子表）
- 预约状态（待审核 / 已通过 / 已到访 / 已离场 / 已取消 / 过期未到）
- 接待区域（一个下拉字典：前台 / 会议室 / 车间 / 仓库 / 办公区，这个字段决定了进门之后能去哪）
- 特殊要求（备注：需携带身份证、需佩戴临时工牌、需专人陪同）
2）随行人员明细（子表）
一条预约可能来三个人。只写"3人"不够——安全事件追查要的是每一个人的姓名、证件号后四位、联系电话。子表字段：姓名、证件类型、证件号、联系电话。人数校验交给系统算，不要让前台自己数。
3）通行记录（每进一次、每出一次各留一条）
这是整模块的可追溯性来源，独立成表：
- 关联预约号（引用上面的预约单）
- 访客姓名（从随行明细或主访客带过来）
- 通行类型（进 / 出）
- 通行时间（系统自动写入，不要让人选）
- 通行门点（一个下拉字典：南门 / 北门 / 车间门 / 货运门）
- 核验人（门岗是谁验的，从人员里选）
- 核验方式（扫码 / 身份证 / 纸质登记补录）
- 访客卡编号（发出和归还都记这一栏）
4）门岗核验记录 / 遗留事项
临时访客卡是否归还、安全须知是否已告知、是否佩戴工牌——这些在门岗被反复口头确认的事，落成勾选字段就变成可查记录。
5）异常与关注名单（一表两用）
一条记录，用类型字段区分：黑名单（明确不得入场）、关注（需有人陪同）、超期未离场（系统按规则生成）。字段：对象姓名、证件号、单位、类型、原因、生效状态、登记人。
关于证件号这类信息，权限要单独收紧：只给门岗与安全负责人看，普通员工角色不应能查询。权限点按角色配置即可，不必为此单独建一套账号体系。
字段建完，别急着做表。先想清楚一个问题：哪些字段是门岗在手机上必须看到的？这套模块的价值，一半在门岗那一屏上。## 第二步：页面怎么用，四个界面覆盖全天
模块建好之后，日常只有四类人碰它：发起预约的员工、审批的被访人部门、门岗、行政安全负责人。给每类人一个界面就够了，不必贪多。
界面一：预约登记（员工提，前台补）
员工在电脑上填预约单，被访人默认带出自己，部门自动带出。提交后进入待审核状态。
- 待审核环节建议走审批流：由被访人所在部门负责人或被访人本人确认（"我确实约了这个人"）。这一步挡掉的就是冒充拜访。
- 审批通过后，系统生成访客通行凭证（二维码或短码），可以由接待人转发给访客，也可以到前台现场出示。
- 同一访客若当天已有有效预约，提交时给出提示，避免重复登记。
界面二：前台到岗登记
访客到达，前台（或自助岗亭）按预约号或手机号调出预约单，核对随行人数与人名，点"已到访"即自动生成一条"进"的通行记录，同时按接待区域发放对应临时卡。
如果访客没有预约（临时到访），走"现场登记"入口：录入单位、姓名、事由、被访人，系统发起一条补救审批给被访人确认，通过后放行。临时到访这条路径千万不要省——现实里它占访客量的一大半，把它堵死，门岗就会绕开系统自己记本子。
界面三：门岗核验台（手机端为主）
门岗最关心三件事，一屏就要答出来：
- 这个人有没有预约、约的是谁、事由是什么、允许去哪些区域；
- 他现在是否在访（有没有未闭环的"进"记录）；
- 名单上有没有他（黑名单/关注）。
手机端打开核验页，扫访客的凭证码或输入预约号，预约信息卡直接展开；核验人与时间由系统自动写入。离场时扫同一张码，点"确认离场"，通行记录闭环，同时提醒归还访客卡。
界面四：在访看板与统计报表
行政和安全负责人真正需要的视图，是这些聚合问题：
- 当前在访人数与列表：谁、在哪个区域、几点进的、接待人是谁——下班前扫一眼就能清场。
- 超期未离场：按预计离开时间比对实际通行记录，超时未离场的自动列出。
- 按日/周/月的访客量：按来访单位、事由、接待部门分组，用于判断前台排班和会议室占用。
- 访客轨迹：按人查，从预约到每一次进出，时间与门点齐全。安全事件复盘时这是唯一说得清的材料。
报表页在平台里就是普通的数据视图，加筛选条件即可按月导出，不需要额外开发。
第三步：自动化把"靠人记"的部分接过来
访客模块真正省人力，靠的是几条自动规则，而不是把纸单换成表单：
- 预约前一天/当天早上：给被访人和接待人发一条站内提醒（可同时走邮件），避免"忘了有约"。
- 超期未离场：定时任务每半小时比对一次在访列表与预计离开时间，超时的推送给接待人和门岗，而不是等下班清场才发现。
- 预约过期自动作废：到预计离开时间仍未到访的，状态自动置为"过期未到"，台账不会越堆越脏。
- 黑名单比对：现场登记提交时按证件号后四位或手机号自动比对关注名单，命中则转人工审批，不再自动放行。
- 离场未还卡：通行记录里"卡未归还"超过设定时长的，生成一条待办给门岗。
这些规则的载体是平台自带的工作流与定时任务能力：条件触发、按时间跑、结果推送给指定角色，都不需要写代码。具体配置方式参考 /docs/workflows-scheduler 。
第四步：移动端不是附加项，是主战场
访客模块有明确的双端分工，别把它当成"电脑端顺便也能看"：
- 电脑端：建预约、审批、导出报表、维护字典与名单、看统计。这些是坐办公室的活。
- 手机端：门岗核验、现场登记、离场确认、发临时卡。这些是站着走动的活，手机是唯一合适的终端。
在 Inkwell AI 构建器里，电脑端建好的模块会同步生成配套的手机端页面，字段和权限沿用同一套，不需要另建一份。移动端的使用方式可参考 /docs/mobile-guide 。
一个实操建议：门岗核验页的字段顺序按门岗的习惯排——先看脸和信息卡，再点放行；把"核验方式"这类需要选择的字段设默认值（扫码），减少点击。门岗是流程里最不愿意学新系统的人，界面每多一步，落地就多一分阻力。## 上线前，逐条查这六件事
模块本身建完只算一半，下面这份清单决定它第一周会不会被门岗弃用。
1）字典先行。 来访事由、接待区域、通行门点、核验方式，这四组下拉在试运行前就要定稿，字段名统一成门岗和前台都在用的说法。字典改起来不难，但历史数据不会跟着改，越早定越省事。字典的维护方式见 /docs/data-dictionary 。
2）权限按人分档。 至少三档：员工（提交自己的预约、看自己的接待）、门岗（核验、放行、现场登记，可看证件信息）、行政安全负责人（全量台账、导出、名单维护）。别让所有人默认看到全员台账，访客信息里有联系方式和证件信息。配置方法见 /docs/roles-permissions 。
3）关键字段必填与格式校验。 姓名、单位、被访人、预计来访时间、接待区域——这五项必须必填。证件号、手机号加格式校验，避免门岗慌乱中录入乱码，让后面的名单比对失效。
4）审批流只留一个节点。 访客审批不要套多层，两次转批的代价是访客在前台站十分钟。一个确认节点 + 超时自动通过（或超时提醒改派人）是更现实的设计。
5）在访视图与名单先灌一次真实数据验证。 拿一批历史访客登记补录（或用 Excel 导入一批），跑一遍"到访—在访—离场—报表"的完整链路，确认统计口径对得上。导入方式可参考 /docs/excel-to-module 。
6）发布前过一遍预检。 页面权限、菜单挂载、手机端同步这三项在发布预检里都会核，别在发布当天才发现手机端少了一张核验页。预检与发布流程见 /docs/module-test-publish 。
再加一条不属于技术范畴但最要紧的：门岗培训一次，贴在墙上一张流程卡。系统能不能活下来，取决于门岗是否觉得它比纸笔快。
之后怎么往下延伸
这套模块的第一版不要做全，做完访客这一条链就够了。站稳之后，几个自然延伸的方向：
- 访客与考勤衔接。 外部施工、外协人员长期驻场的，可以按天登记成"常驻人员"，纳入考勤与工时统计，不必每天走预约。这块可参考 /solutions/solution-hr-attendance 。
- 车辆与货运门禁。 厂区有货运车辆的，把车牌、司机、装货单号加进登记单，出门核验放行单，和访客共用一套门岗核验界面。
- 安全与施工管控联动。 施工维修类访客，把安全交底、临时用电审批挂到预约单上，进场前未完成交底的不放行。项目现场的同类做法见 /solutions/construction-site-ledger 。
- 设备维保外协人员。 设备厂商上门保养，把服务工单号关联到访客记录，事后能对上"哪次保养、谁来的、待了多久"。参考 /solutions/equipment-maintenance-workorder 。
适用边界，说在前面
- 它不是门禁硬件系统。 闸机、人脸识别、车牌道闸属于硬件与实时控制范畴，不在这个模块的能力里。模块负责登记、核验、放行记录与台账；门禁硬件该由专业厂商做，两边能否对接取决于厂家的接口能力。
- 访客量太小的场景不必上。 一个月只有十来个访客、单门单岗的公司，一本登记簿加一个门卫更省。这类模块的价值随"门点数、在访人数、出入频次"上升。
- 它不管保密合规的全部。 证件信息、走访轨迹属于敏感数据，留存多久、谁可查、能否导出，必须按自家制度定，系统只负责把这些规则配出来并留痕。
如果你手上的痛点是"谁在楼里说不清"或者"门口登记本查不出东西"，这就是一个值得做成模块的场景。用一句话把需求讲给 AI 构建器，第一版当天就能跑起来看，剩下的按上面清单一项项调——参考 /docs/quickstart-ai-builder 。