★ FEATURED ARTICLE 1. 项目整体设计与思路拆解1.1 这个项目到底在解决什么问题先聊聊我看到“酒店 × 视觉AI”这个组合的第一反应酒店行业是一个典型的人力密集、流程固化、管理颗粒度粗的传统服务业。前台要办入住、客房要查房保洁、餐厅要盯出餐、安保要看监控每一个环节都靠人盯着而人盯就会出现疲劳、遗漏、标准不统一。视觉AI进场之后本质上做的只有一件事把过去靠人眼完成的状态感知和事件判断变成算法自动完成的实时感知和异常预警。这个版本迭代到V3.1说明已经不是第一版概念稿了。早期版本大概率踩过典型的坑比如把需求写成“做一个智能酒店系统”这种话交上去老师一定会追问做什么功能给谁用数据从哪来识别不准怎么办V3.1的意义就在于它开始用标准的需求分析框架去约束这些模糊的想法把“智能酒店”这种大词拆成可以评审、可以验收的具体条目。从软件工程的角度看需求分析说明书之所以在课程作业里反复被强调是因为它决定了后续设计、开发、测试的走向。一个需求文档如果有歧义开发阶段就要返工如果遗漏了边界测试的时候就要扯皮。所以这个项目表面上是在写文档实际上是在训练“把业务语言翻译成技术需求”的能力这才是软件工程概论这门课真正想让你带走的东西。1.2 视觉AI在酒店场景的技术选型逻辑做需求分析之前得先搞清楚视觉AI在酒店里到底落在哪些技术上。我按采集方式和应用目标把常见方案分为三类这个分类思路在写需求文档时可以直接搬到“技术约束”章节里。第一类是人脸识别相关。用在前台入住身份核验、VIP客人识别、员工通道门禁。这类技术成熟度较高但酒店场景有个特殊点客人到了前台才摘下口罩光线复杂、角度随意和安防场景那种受控采集完全不同。所以需求里必须写清楚采集距离、角度范围、光线条件否则后面算法团队会跟你扯皮。第二类是动作和行为识别。比如客房内跌倒检测、后厨未戴帽子检测、员工清洁次数统计。这类技术依赖姿态估计或检测模型但最大的瓶颈不是模型精度而是摄像头安装位置和视角。后厨的油烟、客房的昏暗光线、公共区域的人流遮挡都会直接影响召回率。需求文档里必须约束部署位置和场景条件。第三类是目标检测与区域分析。比如布草车定位、异常滞留物检测、公共区域人流密度统计。这类技术最成熟但业务上容易犯的错是把“检测出来”和“业务闭环”画等号。检测到遗留行李箱只是第一步后续要不要联动广播、通知安保、划定警戒时间这属于业务流程设计的范畴不是算法能替你决定的。这三类技术选型不是凭空拍脑袋而是围绕酒店已有的硬件条件倒推的。大多数酒店本来就有监控系统视觉AI的落地可以复用这些摄像头这是成本上的巨大优势。但要注意老酒店的摄像头往往分辨率低、帧率不稳、角度不合理需求分析阶段必须把这些存量问题列清楚否则后面上线会变成一场灾难。1.3 为什么需求分析要从V1写到V3.1很多同学写需求文档喜欢一次成型觉得写完了就完事。这个项目的V3.1版本恰恰说明了反例需求是演进的不是你一次性想到的。V1可能只写了“酒店管理系统”加上几个模块V2会加入用例图、原型草图V3开始出现非功能需求的量化指标。每一次版本迭代都是基于评审意见、反馈、自检后的修订。我在实际操作中习惯给每个版本维护一份“变更记录表”列清楚这一版改了什么、为什么改、谁提出的。这看起来是额外工作量但在答辩和复盘的时候非常有用——评审老师问你为什么这个功能去掉你能翻出上一版的记录解释原因而不是支支吾吾半天。V3.1这个编号本身就意味着你已经走过了完整的“反馈-修订-再反馈”循环这比文档内容本身更能体现你对需求分析过程的理解。2. 核心功能需求与业务模块拆解2.1 前台场景无感入住与身份识别先说前台。这是酒店对客服务的第一触点也是最容易产生排队、投诉、体验差的环节。传统流程是客人出示证件、前台人工录入、发放房卡。视觉AI进场后前台的核心需求可以拆成三块。第一块是身份快速核验。客人到前台摄像头抓拍人脸与证件照片做比对确认“人证合一”。这块需求要注意两个要素一是比对阈值怎么定太严会导致误拒客人换个发型就过不了太松会导致误纳安全风险骤增。需求文档里应该给出一个可调整的阈值区间而不是写死“准确率99%”这种无法验证的空话。第二块是VIP识别与二次到店提醒。老客人一进大堂系统识别身份并推送给前台员工这样员工就能主动打招呼、提前调出入住记录、推送偏好信息。这块需求的技术难度不大真正的难点在于“推送时机”和“推送内容”的定义——到底是刷脸后1秒内推送还是客人走到前台再推送推送的信息包含哪些字段会不会涉及隐私这些都要在需求分析里写清楚留给设计师和开发去落地。第三块是自助入住终端的视觉辅助。现在很多酒店有自助入住机但利用率低原因之一是用户不会操作。视觉AI可以做的是通过摄像头检测到客人在终端前的困惑表情、反复点击、长时间停留自动唤起人工客服远程协助。这块需求特别体现“AI人”的协同思路而不是盲目追求全自动。前台场景还很考验需求边界定义。人脸抓拍会拍到路人、送外卖的、接客人的司机这些非住客的采集数据怎么处理、保留多久、是否允许用户删除必须写清楚。我当时在写类似项目时直接参照了个人信息保护的最小必要原则在需求里加了一条“所有抓拍人脸仅在核验期间保留核验完成后立即进行不可逆脱敏”这个条目虽然不增加任何功能亮点但能让评审老师看到你对合规认真的态度。2.2 客房场景智能感知与主动服务客房是客人停留时间最长的私密空间视觉AI在这里会有比前台更强的隐私争议所以需求分析时要把“感知什么”和“不感知什么”画出一条非常清晰的线。合理的感知包括三大类。第一类是房态感知客人入住后摄像头判断房间里是否有人、是否已打扫、是否有异常噪音源。这个能力可以联动门禁系统——入住期间有人进入会触发提醒退房后保洁完成自动更新房态。第二类是事件感知卫生间跌倒、长时间静止、异常高温等。这类需求偏向安全关怀尤其是独住的老年人或商务客人跌倒检测在行业里是刚需。第三类是服务感知客人按了“请勿打扰”却离开房间、客人外出后长时间未返回等这些信息可以提醒客房部及时调整服务策略。但有三类内容我建议明确写在“不做”的清单里不做客人的行为习惯画像比如几点洗澡、晚上看不看电视不做对话内容识别不做场景内的性别年龄推断。这三条写进去的目的不只是合规也是为了防止后期需求蔓延让团队所有人清楚知道这个系统的边界在哪里。客房场景的另一个需求细节是摄像头形态。酒店客房不太可能装明显可见的监控头那对客人是巨大的心理压力。所以视觉AI的采集端往往是智能音箱、电视、空调面板上的低敏感度传感器或者采用“深度图像”方案只能识别轮廓和动作无法还原清晰人脸。需求分析时要明确采集设备的形态约束这会影响技术选型和成本评估。2.3 公共区域安全布防与客流分析大堂、走廊、餐厅、健身房、会议室这些公共区域视觉AI的落地阻力小很多因为酒店本来就有监控覆盖。这里的核心需求集中在两块安全布防和运营优化。安全布防类需求包括异常滞留物检测行李箱、背包出现在不该出现的地方超过N分钟、人员闯入禁区识别员工后台、设备间、消防通道、尾随行为识别一个人刷卡开门另一个人趁机跟入。这类需求写的时候一定要配上“处置流程”不能停在“识别出异常就完事”。比如检测到遗留物之后系统应该在第几分钟通知中控室、第几分钟派人现场查看、第几分钟启动广播提醒这些阈值要和安保部门确认写进需求文档。运营优化类需求包括大堂排队长度统计、餐厅高峰期翻台率分析、健身房设备使用热度、会议室占用率。这类需求的价值是给酒店运营提供数据支撑但很容易写飘——酒店真正关心的是“怎么改进”不是“数据好看”。需求分析时要明确每个数据指标对应的运营动作比如会议室的占用率数据如果超过60%是应该增加会议室数量还是调整线上预订小时的粒度没有这个对应关系数据需求就是个空壳。公共区域的需求还涉及跨摄像头跟踪。客人从大堂走到电梯间、再到楼层走廊如果要做动线分析就需要多个摄像头之间的目标接力。这个需求在技术上的复杂度比单点识别高很多涉及跨镜追踪的ID切换、算法重识别模型。写需求时如果确实需要这一块建议明确“时段范围”和“区域范围”比如只做公共区域不做客房层只做营业高峰时段不做全天避免无限扩大范围。2.4 餐饮与后厨卫生监管与运营联动很多酒店项目会漏掉餐饮和后厨但这恰恰是视觉AI应用价值很大的场景。酒店餐饮既包括面向住客的自助餐厅、早餐厅也包括宴会厅的食品制作流转后厨卫生是市场监督的重点也是酒店口碑的隐藏风险。后厨视觉AI的核心需求集中在穿戴规范检测厨师帽、口罩、手套的佩戴情况。技术上用检测模型就能做难点在需求细节上——比如“口罩佩戴”的判定标准是什么鼻子露出来算没戴还是戴错厨师中途摘帽喝水回来后没戴好系统要不要每一秒都报警这就要定义“违规持续时间阈值”。我见过不少项目直接写“检测到未佩戴口罩即告警”结果后厨一天响几百次最后所有人员都把提示当背景音完全失去作用。需求分析一定要把阈值和提示分级写清楚比如“疑似未戴3秒内忽略—短时违规3-30秒提醒组长—持续违规超30秒记录并推送”。明档和自助餐区的前场需求则以游客体验为主取餐区和用餐区的人流密度监测、明档排队长度反馈后厨产能调节、餐台剩余菜品可视化。前场和后厨的数据可以实现联动比如某个档口排队超过5分钟系统自动通知后厨增加出餐量。这块需求要写清楚数据联动的触发条件和消息通道否则开发时会不知道消息发到哪里。餐饮区域还有一个容易被忽略的需求食材存储区的摄像头追溯。虽然这不太涉及视觉AI的高深算法但可以通过摄像头记录进出冷库的人员和时间联动温度传感器数据在发生食安问题时快速倒查。这种需求源于实际业务痛点写进文档里会显得你对酒店餐饮的运营有真实理解。3. 需求分析实操从干系人到验收标准的完整闭环3.1 干系人识别与需求获取的核心方法需求分析说明书最容易出现的问题是“只从开发者视角写需求”。我拿到一个项目第一件事是做干系人分析把会用到这个系统、会被这个系统影响的人全列出来再逐个访谈或者模拟他们的诉求。酒店视觉AI项目的干系人至少包括以下几层酒店管理层关心降本增效和品牌风险、一线员工前台、客房、安保、餐饮关心系统是否增加工作量、是否误报造成麻烦、工程信息部门关心系统是否好维护、数据是否好对接、住客和访客关心体验和隐私以及外部监管消防、公安、食品安全相关要求。每一类干系人的诉求差异很大管理层想要“全面覆盖”一线员工想要“少打扰我”住客想要“无感但安心”监管方想要“有据可查”。这些诉求有时候是冲突的需求分析的价值恰恰在于暴露冲突、权衡取舍而不是回避。需求获取的方法我推荐组合使用不要单靠一种。问卷适合收集量化的满意度和优先级判断访谈适合深挖“到底为什么要这个功能”现场跟班观察能发现员工嘴上没说但实际在做的动作。比如你问服务员“客房清洁要不要识别布草有没有换”他说“要”但实际跟班时你会发现他压根不看系统推送只凭自己经验判断。这种需求采集的断层在真实项目中非常常见所以需求说明书里必须区分“用户声称的需求”和“用户真实的行为需求”后者才是系统必须承载的。3.2 从角色到用例怎么把业务故事转成技术需求需求分析说明书的核心表达工具是用例用例的质量决定了下游设计的清晰度。写用例时最忌讳的就是“泛泛的功能描述”比如“支持客人识别”这种话用例图都画不出来。我常用的写法是先给每个角色定义清楚目标再围绕目标细化主成功场景和异常分支。以“客人无感入住”为例主场景是客人到达前台系统识别身份调出订单核验证件发放房卡整个过程在N秒内完成。但真正体现需求深度的异常分支很多客人订单使用的是别人的身份证帮朋友订房、客人是外籍人士且面孔识别失败、摄像头故障时降级为人工核验、客人刚做完面部手术导致识别不通过。每一条异常分支背后都对应一项系统功能和一条业务规则少写一条开发测试的时候就会漏一种情况。用例之外还要配一个“术语表”。酒店行业和AI行业都有自己的黑话需求文档里如果出现“布草”“minibar”“直客”“召回率”“误报率”这些词而不给定义评审的时候大家就只能各说各话。术语表看起来是个不起眼的章节但它能有效防止需求在传递过程中的失真。我在V3.1这个版本的文档里专门留了一页术语表把酒店行业术语和技术术语都列清楚这也是版本迭代中觉得最值得保留的改进。3.3 非功能需求这些指标写不好系统必烂很多需求分析说明书的前半部分功能需求洋洋洒洒到了非功能需求就只有一句“系统应稳定运行”。这种写法等于没写。非功能需求才是真正决定系统上线后能不能用的关键。我按几个维度把视觉AI相关的非功能需求拆开。性能方面人脸识别的响应时间从前台抓拍到返回结果卡在2秒内、视频流的处理并发量高峰期同时在线多少路摄像头、告警推送的延迟从事件发生到通知到安保手机超过10秒就不具备救援价值。准确性方面这里严禁只写“识别准确率99%”因为识别任务不同指标完全不同——人脸比对是误识率和误拒率跌倒检测是召回率和误报率检测类任务是mAP。需求文档里要把不同场景的精度指标分开写并且注明测试数据集的构成比如“测试样本包含2000张酒店前台光线条件的抓拍图”这样指标才可验证。可用性方面一线员工平均年龄不小数字素养参差不齐系统界面必须做到多少时间内上手、是否需要专门的培训考核。我在文档里会写“系统核心功能培训不超过2小时员工可通过图文指引独立完成日常操作”这个指标比空泛的“易于使用”明确得多。兼容性方面要写清楚支持哪些品牌的摄像头协议、旧设备的接入方式、断网时系统如何降级。酒店的网络环境经常不稳定尤其后厨和走廊死角断网时如果整个系统瘫痪还不如不装。安全性方面数据加密存储、权限分级控制、日志审计留存这些在酒店这个行业尤其绕不开。3.4 数据需求与隐私边界设计视觉AI项目本质上是数据项目需求分析里如果没有单独的数据章节后面设计阶段一定会出问题。我习惯把数据需求拆成输入数据、输出数据、中间数据和持久化数据四类来写。输入数据包括摄像头视频流、前端设备状态、酒店PMS系统的订单和房态数据。输出数据包括各类识别结果、告警事件、统计分析报表。中间数据指人脸特征值、行为特征序列这类从原始数据加工而来的数据——这类数据最容易引发合规风险因为它们即使不是原始图像也能关联到个人身份。持久化数据指需要长期保存留作审计和追溯的记录比如入住核验记录、违规事件的录像片段。隐私边界设计要落实到具体的规则上。我在需求文档里写了几条硬约束人脸抓拍图片默认不保存原图仅保留脱敏后的特征值告警事件的录像默认保留30天超期自动清理客人有权查询和管理自己被系统采集的信息所有视觉分析数据与PMS系统关联时必须做假名化处理。这些约束表面上限制了系统的功能空间实际上是在保护项目不做成“监控黑箱”——一旦被媒体曝光为“酒店房间内暗藏摄像头分析客人行为”品牌损伤比省下那点人力成本大得多。4. 实操过程中踩过的坑与问题排查实录4.1 需求变更V3.1里那些被删掉的功能我前面提过版本迭代记录的价值这里展开说说因为真实项目中需求变更才是常态V3.1这个版本里被删掉的功能往往比新增的功能更值得复盘。比如早期版本里设想过“客房情绪识别”——通过摄像头判断客人心情好坏前台和餐厅据此调整服务。听着很智能但仔细一想情绪识别的准确率在实验室都只有70%左右到了酒店真实光线条件、不同人脸型、不同遮挡下效果根本没法保证而且万一推断错了服务员拿这个数据去强行关怀反而会让客人觉得被冒犯。这个需求在V3阶段被我删掉了移到“远期规划”里备注了放弃原因。又比如“全楼层跨镜追踪”这个功能技术上能做但投入产出比很差。为了客人在酒店里的动线分析需要部署大量摄像头点位、建设重识别模型、处理跨镜ID切换的时序问题而且数据价值对酒店运营来说并不直接。最后我把它降级为“电梯间、大堂两个关键点位的有限跟踪”只分析从大堂到电梯这条黄金动线。这种“做减法”的判断需求分析阶段必须想清楚。删除功能的决策标准我总结成三条技术上是否可靠、业务上是否真的有人用、合规上是否站得住脚。三条里任何一条不满足就放进远期规划而不是当前版本。这个标准我在答辩和内部评审时反复用几乎每次都能说服对方。4.2 需求分析说明书结构自查清单写完V3.1之后我自己会做一遍完整的自检这里给出一份可以直接拿去对照的检查清单。角色表是否包含了所有干系人住客、一线操作者、管理者、外部接口公安、消防消防系统是否都出现了每个功能需求是否有明确的优先级MoSCoW法则必须有、应该有、可以有、不会有至少要区分前两级。每个用例是否有异常分支如果只有主流程没有异常流说明用例深度不够。非功能需求是否有量化指标精度、延迟、并发、可用时间是否可测、可验数据需求是否覆盖了全链路从采集、存储、使用、共享到销毁每一环是否都有交代需求是否有追溯性每条需求能否追溯到具体的干系人诉求或业务目标而不是凭空出现。是否有明确的验收标准测试人员看到这个文档就能写出测试用例的颗粒度才合格。这份清单我在不同项目里反复使用实测下来最能暴露问题的是第一和第六条。干系人漏掉意味着会有人的需求没人负责需求没有追溯性意味着文档里总会出现一些“别人觉得应该有”但实际上没人真正需要的功能。4.3 需求分析中的边界划分哪些不做比做更重要视觉AI项目在酒店里的边界问题比较集中新手控制不住老手也会被业务方带偏。我在给这个项目做边界约束时明确划了三个“不做”。不做实时视频监控的全面回放。摄像头产生的数据量巨大如果全部都留存、全部可回放存储成本高隐私风险大而且运营人员根本不会看。所以需求里定义的是“事件触发才录制”——检测到异常事件前后各扩充10秒录制其他时间的视频流只做实时分析不落盘。这个设计大幅降低了存储需求和合规压力。不做基于视觉数据的用户画像分析。这个诱惑很大因为酒店很想知道客人的年龄、消费习惯、活动偏好但视觉数据做画像既不准也危险。我的判断是这类需求完全是“看起来有价值实际上会被投诉到死”的坑。不做纯替代人的无人化方案。比如“完全无人客房服务”——机器人送餐、自动清洁这类方案的成熟度和用户体验还没到那个程度。需求分析要立足于“AI辅助人而不是替代人”系统给员工提供决策支持、减少重复性低价值的盯防劳动但最终的服务责任和处置决策还是由人来承担。这样写不仅技术风险可控在伦理和合规上也更站得住。4.4 数据精度与业务容忍度的匹配视觉AI项目里最隐蔽的坑是算法精度和业务容忍度的错位。开发团队会说“准确率98%很好了”业务团队会说“98%意味着每天有几十次误报谁受得了”。两边说的都是对的问题在于需求分析阶段没有定义清楚精度指标和业务的对应关系。以客房跌倒检测为例如果误报一次就需要保洁跑一趟查看日误报率哪怕只有1%按200间房每天触发几百次员工一天全在来回折腾。所以需求分析不能只写“跌倒检测准确率高于95%”要写“每月每间客房的误报不超过2次且系统必须在房间无人时自动降低灵敏度”。后者才是业务能接受的指标。反过来有些场景的精度要求反而没那么高。比如后厨未戴厨师帽检测允许一定误报因为多看一眼浪费不了几秒但不能漏报漏一次可能就是安全事故。这类“宁错勿漏”的场景和“宁漏勿错”的场景必须在需求阶段就区分开否则算法团队只能凭经验猜一个阈值等到上线再调就晚了。我在V3.1里专门做了一个精度场景映射表把每个功能场景按“误报容忍度”和“漏报容忍度”打了分拿到这个表算法选型和验收标准都变得顺理成章。这类问题我在好几个项目里反复遇到过也已经形成了固定的处理套路拿到一个视觉AI需求先问一句“这个场景误报一次会怎样漏报一次会怎样”答案直接决定了检测阈值的方向。这两个问题问不清楚后面的所有精度指标都是纸面文章。5. 写在最后做需求分析的一些个人体会需求分析这件事在学校里是作业在真正的工作里是产品落地前最重要的一道关卡。回过头看这个酒店视觉AI的V3.1版本我觉得真正让我收获最大的不是学会了画用例图、写用例描述而是开始习惯用“系统不做哪些事”来定义系统的价值。视觉AI在酒店里有很多美好的想象空间但每一个想象的落地都要过三关技术上可不可行、业务上有没有人买单、合规上能不能站住脚。这三关过不去的功能做一个死一个。需求分析说明书的价值就是把这三关的问题在写文档的阶段全部暴露出来而不是等到开发完了、上线了才暴露那时候返工的成本就完全不一样了。如果你也在写类似的项目文档我最后给你一个建议找一个经验比你丰富的人做一个半小时的文档走查只做一件事——每看一个功能就问“这个功能是给谁用的解决什么具体问题”。你会发现很多当时觉得合理的需求在追问之下都会站不住脚。这不是你的能力问题这是需求分析本身的工作方式在不断追问中收敛在删减中逼近真实。能力和广度的积累也来自一次一次这样的迭代。下一次你写V4.0就会比V3.1更清楚地知道哪些功能要保留哪些要删除哪些要转成远期规划。需求分析这门手艺本质上就是练习做决策在模糊中找到清晰在复杂里找到关键。
阅读完成 · 觉得有帮助？
