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更清楚地知道，哪些功能要保留，哪些要删除，哪些要转成远期规划。需求分析这门手艺，本质上就是练习做决策，在模糊中找到清晰，在复杂里找到关键。
