现场演唱会、体育赛事、展会等活动场景中视频监控系统已经开始大量引入 AI 分析能力比如人脸抓拍、行为识别、人群密度统计和车辆识别。与此同时也会有越来越多的活动主办方提出明确要求禁止 AI Surveillance 能力上线或者在某些区域、某些时段关闭这些能力。对工程师来说这不是一句口号而是一组需要落到配置、代码、模型、存储和审计日志里的工程需求。本文从一次实际工作中常见的需求出发——主办方要求现场视频监控只保留录像和人工查看不得启动任何自动分析识别功能——梳理如何在现有监控系统中完成 AI 功能的禁用、验证和审计并给出可复用的排查清单。1. 先搞清楚“现场 AI 监控”到底指哪些能力以及为什么需要按场景禁用1.1 现场监控中的 AI 能力通常由哪些模块提供在动手改造之前第一步是把“AI 监控”这个词拆成具体功能。只有明确知道系统里有哪些分析模块才知道要禁用什么。一个典型的现场活动视频监控系统可能包含以下 AI 能力能力模块常见用途处理的数据合规风险点人脸检测与识别识别嘉宾、重点人员、员工考勤人脸图片、特征向量敏感生物特征数据行为分析检测倒地、斗殴、奔跑、聚集人体关键点、行为标签容易误判可能过度干预人群密度统计判断区域拥挤程度、疏导人流头肩检测框、人数计数本身风险较低但仍属于智能分析车辆识别识别车牌、车辆类型车牌图片、车辆特征与个人关联时风险高徘徊检测发现可疑逗留目标轨迹坐标容易对个体形成持续跟踪热成像测温实时体温筛查温度数据、面部区域健康信息敏感需要特别授权这些模块通常在视频分析服务中运行。输入是摄像头 RTSP 流或视频帧输出是检测框、标签、特征向量和告警事件。禁用 AI 监控并不等于关闭摄像头而是指停止这些“对视频内容做自动识别和理解”的模块。1.2 “禁用 AI 监控”的业务含义不是关闭监控有一个常见误区业务方提出“禁止 AI 监控”项目组直接关掉所有摄像头或者把录像功能一并停掉。这其实偏离了需求。现场活动的安防诉求仍然存在需要录像留证、需要安保人员实时查看画面、需要事后追溯某个时间段发生了什么。真正被禁止的通常是带有自动识别、自动关联、自动告警能力的 AI 分析模块。因为这类模块会持续收集大量人员特征且处理逻辑对普通参与者不透明。因此在需求阶段要把“禁用什么”和“保留什么”分开写清楚。一个可操作的需求描述应该是保留多路摄像头实时预览、原始视频录像、本地存储。禁止人脸检测与识别、人体属性分析、行为识别、车辆识别、自动告警联动。允许无 AI 参与的运动检测或仅在本地计算纯帧差用于节省录像空间。审计所有配置变更、服务启停、模型加载、数据删除行为都要有日志。这样写清楚之后工程目标就从“不要 AI 监控”变成了“构建一个默认不加载、不运行、不存储 AI 分析结果的视频链路”。1.3 工程目标从配置开关到可审计证据从工程角度看禁用 AI 监控可以有三个层次第一层是配置开关。通过配置文件或管理后台把 AI 功能设为关闭。这个层次最快但只能控制应用自身的分支逻辑无法防止其他模块绕过配置。第二层是运行时降级。不在视频分析进程中加载模型权重不启动推理线程不初始化特征库。这个层次能保证当前服务确实没有运行模型。第三层是环境隔离与审计。从部署层面拿掉 GPU、取消 AI 服务容器、删除特征向量库并通过日志和指标留证据。这个层次适合合规审计。实际项目里建议按“先配置关闭、再进程降级、最后环境隔离”的顺序推进。不要把三个层次混在一起否则一旦出现“配置显示关闭但模型还在 GPU 上”的情况很难定位。2. 准备最小模拟环境本地 RTSP 视频分析服务2.1 用一个 MP4 模拟摄像头画面为了在本地验证禁用 AI 监控的效果不需要真的拿摄像头接进系统。可以用 FFmpeg 配合本地 RTSP 服务把一个测试视频模拟成摄像头实时流。推荐使用 mediamtx 作为轻量 RTSP 服务。它支持在本地快速启动一个 RTSP 端口适合做流媒体链路实验。以 mac 或 Linux 环境为例先下载并解压 mediamtx然后启动./mediamtx默认监听端口是 8554启动后可以通过rtsp://localhost:8554/访问。这里要说明mediamtx 的默认配置会开启 RTSP、RTMP、HLS 等协议实际现场项目只需要按需开启 RTSP 即可避免暴露其他协议。接着准备一个测试视频文件比如test_scene.mp4。然后用 FFmpeg 循环推流到本地 RTSP 服务ffmpeg -re -stream_loop -1 -i test_scene.mp4 \ -c copy -f rtsp rtsp://localhost:8554/camera1这里解释一下参数-re按原视频帧率读取模拟实时摄像头。-stream_loop -1无限循环播放避免视频结束导致取流中断。-c copy直接复制视频编码不做转码节省 CPU。-f rtsp输出为 RTSP 流。推流成功后可以用 FFprobe 验证ffprobe rtsp://localhost:8554/camera1看到视频流信息说明模拟摄像头已经就绪。2.2 项目目录结构在本地创建一个实验项目目录用来模拟一个只做录像、不做 AI 分析的视频服务ai-surveillance-disable-demo/ ├── config.yaml ├── main.py ├── audit.log ├── output/ │ └── recordings/ └── requirements.txt目录里不放置任何模型权重文件。这是因为禁用 AI 功能时最彻底的做法是让项目目录里根本没有模型可以加载。如果后续需要对比可以再单独建一个models/目录用于放测试模型但在禁用场景下不应被加载。2.3 依赖清单最小示例只需要三个 Python 依赖依赖库用途版本建议opencv-python读取 RTSP 流、写入录像、图像基础处理安装最新稳定版PyYAML读取 config.yaml 配置安装最新稳定版prometheus-client暴露审计指标可选用于验证推理次数为 0安装命令pip install opencv-python PyYAML prometheus-client需要说明的是这里没有安装任何深度学习推理框架比如 PyTorch、TensorRT 或 ONNX Runtime。原因是“禁用 AI 监控”的最强保证之一就是运行时环境根本没有推理依赖。2.4 启动 RTSP 服务并确认取流正常在进入代码之前先确认整条视频链路能通ffmpeg -re -stream_loop -1 -i test_scene.mp4 \ -c copy -f rtsp rtsp://localhost:8554/camera1然后另开终端用 Python 验证 OpenCV 能否读取import cv2 cap cv2.VideoCapture(rtsp://localhost:8554/camera1) if not cap.isOpened(): print(取流失败) else: ret, frame cap.read() print(取流成功帧尺寸:, frame.shape if ret else 读取失败) cap.release()这一步检查点有三个RTSP 服务端口可访问、FFmpeg 推流没有中断、OpenCV 能读取到视频帧。任何一步失败都要先解决链路问题再进入后续代码。3. 设计 AI 监控禁用开关全局策略、代码分支、模型卸载3.1 用 YAML 定义功能开关用一个config.yaml统一管理 AI 功能的状态是最直观的做法。配置示例stream_url: rtsp://localhost:8554/camera1 record: enabled: true output_dir: output/recordings fps: 25 ai: enabled: false features: face_recognition: false behavior_analysis: false vehicle_detection: false people_counting: false model_dir: models vector_db_path: data/features.db gpu_memory_limit: 0 audit: log_file: audit.log log_startup_snapshot: true这里有几个字段值得解释record.enabled控制是否录像。业务要求保留录像时这个字段为true。ai.enabled全局 AI 开关。禁用时代码里不允许执行任何推理分支。ai.features细分功能开关。即使全局开关被误设为true这里也要逐项关掉。ai.model_dir模型目录。如果模型目录不存在程序应启动失败并提示而不是静默跳过。ai.vector_db_path特征向量库路径。禁用时不应创建或写入。audit.log_startup_snapshot启动时把配置快照写入审计日志便于事后证明当时的状态。3.2 视频分析服务读取策略并跳过推理核心逻辑并不复杂在每一帧处理之前先判断ai.enabled是否为false。如果是就直接走“录像”分支不调用任何检测函数。下面是一个最小的策略读取示例import yaml import logging import cv2 from datetime import datetime def load_config(path: str): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def setup_logger(log_file: str): logging.basicConfig( filenamelog_file, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, ) return logging.getLogger(disable-demo) def write_audit_snapshot(logger, config): logger.info(startup snapshot) logger.info(fai_enabled{config[ai][enabled]}) logger.info(fface_recognition{config[ai][features][face_recognition]}) logger.info(fbehavior_analysis{config[ai][features][behavior_analysis]}) if __name__ __main__: config load_config(config.yaml) logger setup_logger(config[audit][log_file]) write_audit_snapshot(logger, config)这里还没有加入真正的视频处理。先让程序能读取配置并记录启动快照是为了后面验证“AI 功能是否被禁用”时有日志可查。当ai.enabled为false时主循环中应直接跳过模型推理。常见错误写法是在循环里用if config[ai][enabled]:来包住推理逻辑但初始化模型却在循环外无条件执行。下面这个示例展示了错误做法# 错误模型无条件加载 model load_model(models/yolov8n.onnx) # 禁用时不应执行 while True: ret, frame cap.read() if not ret: break if config[ai][enabled]: results model.infer(frame) # 这里才判断这种写法在禁用配置下仍然会加载模型浪费显存也可能触发特征库初始化审计时很难自证清白。正确做法是把模型加载也放在条件分支里或者在启动阶段就检查ai.enabled并直接退出。3.3 从开关到卸载模型、进程、特征库三层处理配置文件可以控制逻辑但不能替代部署层面的操作。在正式项目里禁用 AI 监控还需要做三件事第一删除或不下发模型权重。人脸识别模型、行为识别模型、车辆检测模型的权重文件都不应出现在生产服务器上。如果必须保留模型做离线测试应放在独立测试网段。第二停止推理进程。如果架构里有专门的 AI 推理服务比如一个 GPU 容器应通过容器编排的副本数设置为 0或者在部署文件中删除该服务。第三清空特征向量库。如果之前已经运行过 AI 分析特征库里可能残留人脸向量或行为特征。禁用前要先确认合规要求再决定是加密归档还是彻底删除。删除后要验证表结构或文件目录为空。以 Docker Compose 为例可以用 profile 控制 AI 服务是否启动services: video_recorder: image: recorder:latest profiles: [always] command: [python, main.py, --config, /app/config.yaml] ai_analyzer: image: analyzer:latest profiles: [disabled] deploy: replicas: 0当业务要求禁用 AI 时启动命令只启用alwaysprofiledocker compose --profile always up -d这样连 AI 分析容器都不会创建而不是创建后停止。两者在运维审计中差异很大。3.4 为什么前端隐藏不等于禁用有些监控平台管理界面有关闭 AI 分析的按钮但按钮只影响页面展示不一定影响后端分析服务。工程上要注意三点前端隐藏可能只是把检测框不画到画面里但后台仍在保存检测结果。管理后台的配置可能只对某个租户生效其他租户仍然在调用分析服务。如果 AI 分析能力在摄像头 IPC 设备内部执行平台前端更控制不了。因此判断 AI 是否被禁用不能只看管理页面要看数据链路里是否真的没有推理调用、模型加载和特征写入。这也解释了为什么审计日志和指标如此重要。4. 实现最小可运行示例关闭 AI 分析后的采集与录像链路4.1 需求描述为了让验证过程更贴近实际我们把场景收窄成三个明确的业务要求活动主办方要求现场摄像头只做录像不允许做人脸识别、行为分析、车辆识别、人群计数。录像保留 24 小时访问录像需要本地权限。系统启动和停止都要有审计日志。在这组需求下最小系统可以只包含“RTSP 取流 视频落盘 审计日志”三部分。4.2 核心代码只录像、不推理的处理器下面是一个可直接运行的最小示例。它读取config.yaml从 RTSP 拉流按录像配置写入 MP4同时写审计日志。由于ai.enabled固定为false代码里不存在调用 AI 模型的分支。import yaml import logging import cv2 from datetime import datetime from pathlib import Path def load_config(path: str): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def setup_logger(log_file: str): logging.basicConfig( filenamelog_file, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, ) return logging.getLogger(disable-demo) def record_stream(config, logger): stream_url config[stream_url] output_dir Path(config[record][output_dir]) output_dir.mkdir(parentsTrue, exist_okTrue) ai_enabled config[ai][enabled] logger.info(fstream_url{stream_url}) logger.info(fai_enabled{ai_enabled}) cap cv2.VideoCapture(stream_url) if not cap.isOpened(): logger.error(cannot open stream) return fps cap.get(cv2.CAP_PROP_FPS) if fps 0 or fps 120: fps config[record][fps] width int(cap.get(cv2.CAP_PROP_FRAME_WIDTH)) height int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT)) output_path output_dir / frec_{datetime.now().strftime(%Y%m%d_%H%M%S)}.mp4 writer cv2.VideoWriter( str(output_path), cv2.VideoWriter_fourcc(*mp4v), fps, (width, height), ) frame_count 0 while True: ret, frame cap.read() if not ret: logger.warning(failed to read frame, break) break if ai_enabled: # 这里在实际项目中才会执行模型推理。 # 禁用配置下这段代码不会被访问。 logger.warning(ai inference branch should not be executed) else: writer.write(frame) frame_count 1 if frame_count % 300 0: logger.info(frecorded_frames{frame_count}) cap.release() writer.release() logger.info(frecord done, total_frames{frame_count}) if __name__ __main__: config load_config(config.yaml) logger setup_logger(config[audit][log_file]) record_stream(config, logger)代码里的关键点ai_enabled在启动时只记录一次循环里不再读取 YAML避免性能损耗。if ai_enabled:分支里没有写推理代码只做了警告方便在误开启配置时发现异常。output_path使用时间戳命名避免覆盖旧录像。每 300 帧输出一次进度便于在日志里确认进程没有卡死。这个示例没有实现 24 小时自动清理。实际项目中录像清理可以交给外部定时任务或存储生命周期策略避免用应用代码轮询删除。4.3 启动命令与验证输出在项目目录下运行python main.py同时建议用一个终端查看日志tail -f audit.log正常日志内容应该是2025-01-01 10:00:00 INFO stream_urlrtsp://localhost:8554/camera1 2025-01-01 10:00:00 INFO ai_enabledFalse 2025-01-01 10:00:01 INFO recorded_frames300 2025-01-01 10:00:02 INFO recorded_frames600日志中不能出现load model、inference、face embedding等关键字。同时检查输出目录ls -lh output/recordings/能看到一个 MP4 文件。用 FFprobe 验证录像文件可播放ffprobe output/recordings/rec_*.mp44.4 从日志和输出判断是否发生推理禁用 AI 后特征向量库路径data/features.db不应该存在。可以用命令确认ls -la data/如果目录为空或不存在说明没有写入向量数据。还可以检查是否有模型文件被加载到内存。在 Linux 上可以通过进程的打开文件列表查看ls -l /proc/python_pid/map_files | grep -E onnx|engine|pt|pth正常情况应没有结果。如果出现模型文件说明程序或第三方库隐式加载了模型需要排查依赖。4.5 常见坑模型被提前加载、GPU 显存仍占用一个常见坑是很多视频分析框架在导入时会自动初始化全局模型。你在代码里没有显式调用load_model但 import 的某个 SDK 内部会加载默认模型。这类问题排查起来比较麻烦。处理方法有两个在import阶段之前就先读取config.yaml如果ai.enabled为false直接退出或者不导入任何 AI SDK。在启动入口处设置环境变量比如DISABLE_TORCH_VISION1避免框架自动加载预训练权重。另一个常见坑是 GPU 显存仍然被占用。禁用后检查nvidia-smi如果显存有大量占用说明某个服务还在运行模型。不要只看进程名应检查 GPU 进程列表nvidia-smi --query-compute-appspid,used_memory,process_name --formatcsv根据 PID 定位并停止对应进程。5. 怎么审计“AI 功能确实被禁用”检查链路和证据保存5.1 建立可执行的审计清单合规场景下审计人员不会只看你的代码更看重能留下哪些可检查证据。下面这份清单可以直接用在项目验收或发布前检查中。检查项检查方式预期结果启动配置状态查看 audit.log 中的 startup snapshotai_enabledFalse所有 features 为false模型文件检查模型目录和服务端文件系统不存在人脸、行为、车辆模型文件推理进程ps aux | grep -E analyzer|tensorrt|onnx无相关进程GPU 占用nvidia-smi --query-compute-appspid,name --formatcsv无分析进程占用特征库检查向量库文件或数据库表不存在或为空网络外发tcpdump 抓包检查是否请求外部识别服务无对外特征上传请求录像文件FFprobe 查看录像编码正常视频文件无检测结果叠加5.2 在启动时写入配置快照和哈希为了证明 audit.log 里的记录不是事后伪造的可以在启动时计算配置文件的 SHA-256并记录到日志。import hashlib from pathlib import Path def config_hash(path: str) - str: data Path(path).read_bytes() return hashlib.sha256(data).hexdigest()启动时调用logger.info(fconfig_hash{config_hash(config.yaml)})后续审计时如果怀疑配置被改动可以重新计算当前文件的哈希与日志对比。只要哈希不一致说明配置已被修改需要重新审计。5.3 用 Prometheus 指标暴露推理调用次数业务方如果要求持续可见的“AI 功能关闭”状态可以在服务里暴露一组运行时指标。from prometheus_client import Counter, Gauge, start_http_server INFERENCE_CALLS Counter(ai_inference_calls_total, Total AI inference calls) MODELS_LOADED Gauge(ai_models_loaded, Number of loaded AI models)在禁用模式下启动指标服务器后start_http_server(8000) MODELS_LOADED.set(0)在循环中只有当ai_enabledTrue时才会增加INFERENCE_CALLS。审计人员可以访问http://localhost:8000/metrics查看ai_inference_calls_total 0 ai_models_loaded 0这样就把“是否运行了 AI 推理”转化成了可连续观测的指标。5.4 验证没有外部特征上传有些 AI 监控系统会把视频帧或特征向量发送到云端服务。禁用状态下这类请求必须为零。最简单的方式是在防火墙或安全组层面阻断对外识别服务端口的访问。然后在本地网络出口做抓包验证sudo tcpdump -i eth0 -n tcp and port 443 -c 100活动场景中如果系统本身不需要连接外网建议直接限制摄像头和视频服务器所在网段只能访问本地存储不能访问公网。这样即使代码被绕过网络层也能兜底。6. 三种禁用方案怎么选配置开关、进程降级、物理隔离6.1 方案对比不同项目对“禁用 AI 监控”的强制程度不同选型也不一样。方案优点缺点适用场景配置开关实现快可远程切换容易被绕过审计说服力弱快速试点、内部测试进程降级不加载模型资源释放明显部署复杂需要改启动编排正式生产环境物理隔离最可审计不可远程开启变更成本高恢复慢强合规活动、外部审计6.2 配置开关适合快速试点配置开关适合在功能开发阶段使用。把ai.enabled设为false后主流程跳过推理分支。它的优点是改动量小缺点是无法阻止其他服务或脚本绕过配置。如果项目周期紧可以先通过配置开关验证整体流程但要在验收前补上进程降级和审计日志。6.3 进程降级适合正式生产进程降级指的是通过部署编排让 AI 分析服务完全不启动。视频录像服务和分析服务拆成不同容器或不同进程禁用时只启动录像服务。这种方案能释放 GPU、内存和 CPU 资源也能从根本上避免“配置关闭但进程还在推理”的问题。缺点是部署配置变复杂需要维护两套启动参数。6.4 物理隔离适合强合规要求如果活动主办方或法务要求最高级别的保证可以采取物理隔离。把智能分析服务器从视频网络中摘除不接入 GPU 资源甚至用无外网权限的独立录像一体机。物理隔离不是指拔掉摄像头而是指“不具备运行 AI 分析的环境”。它的审计说服力最强因为审计人员可以看到设备本身不支持 AI 功能。6.5 生产环境建议组合方案实际项目里很少只依赖一种方案。推荐组合是配置开关作为业务控制层进程降级作为部署兜底层审计日志作为证据层。三层同时生效才能覆盖“不小心开启”“后台绕过”“审计质询”三类问题。7. 常见问题与排查路径7.1 配置 disabled但程序仍然加载模型现象config.yaml中ai.enabled为false但服务启动后日志显示模型加载GPU 显存升高。可能原因模型加载写在函数导入阶段不受配置控制。第三方 SDK 在 import 时自动初始化。配置路径读错程序加载了默认配置。排查顺序检查启动日志中是否正确打印ai_enabledFalse。查看代码中所有import是否触发了 SDK 初始化。使用python -X importtime main.py检查导入耗时定位是否加载了深度学习框架。如果确认是第三方 SDK把 AI SDK 包卸载或用虚拟环境隔离。解决方式在入口处先读配置ai.enabled为false时不导入任何 AI 相关模块。删除models/目录中的权重文件。在部署脚本中不设置 GPU 资源。7.2 录像文件过大保留周期失控现象禁用 AI 后录像正常但存储空间快速耗尽24 小时保留策略没生效。可能原因没有配置定期清理任务。录像码率过高分辨率过大。OpenCV 的 MP4 封装不是关键帧对齐文件比预期大。排查方式du -sh output/recordings/ find output/recordings/ -type f | wc -l解决方式使用固定码率转码或者直接从 IPC 流中以原始编码写入避免二次编码膨胀。用系统 crontab 或存储生命周期策略实现按天清理。监控存储目录占用超过阈值自动告警。7.3 日志中出现了识别框标签但配置显示关闭现象回放录像或查看预览画面时出现人脸框、人体框或“person”“face”标签。可能原因识别框是设备端 IPC 叠加到视频流中的后端无法通过配置关闭。另一个分析进程仍在读取同一路 RTSP 流。预览客户端自己加载了本地模型。排查方式使用 FFmpeg 直接把原始流保存为文件查看是否包含识别框标签。检查网络中是否还有第二个视频分析容器在运行。查看摄像头的 ONVIF 配置确认设备内置智能分析是否开启。解决方式如果框来自摄像头端需要登录设备后台关闭智能分析或恢复出厂配置。停止所有额外分析进程。在录像链路中不叠加任何检测结果。7.4 审计时无法证明关闭状态现象合规审计时只有代码文件缺少运行时的证据无法证明服务当时确实没有运行 AI。原因项目没有保存启动配置、指标数据和删除记录。解决方式从下一次发布开始在audit.log中记录启动配置快照和配置哈希。暴露ai_inference_calls_total指标并保存到监控系统。对模型文件和特征库的删除操作写操作日志包含操作人、时间和文件哈希。预防建议在发布模板中加入“合规证据包”目录每次发布后自动收集配置文件、启动日志、指标快照归档到独立存储。8. 最佳实践与扩展方向8.1 需求阶段就把“禁止能力清单”写清楚在项目启动时与其说“禁用 AI”不如建立一张能力清单逐项确认状态。能力默认状态是否允许临时开启谁可以开启是否需要审计人脸检测禁用否无是行为分析禁用否无是人群计数禁用否无是车辆识别禁用否无是运动检测启用是项目管理员是这张清单要写进项目文档和验收标准避免后期理解偏差。8.2 发布前合规检查清单每次活动上线前按下面顺序检查一遍确认config.yaml中 AI 全局开关为false。确认模型目录不存在或为空。确认 AI 分析容器副本数为 0。确认特征向量库为空或已删除。启动服务并查看audit.log确认启动快照记录正确。访问指标接口确认ai_models_loaded为 0。随机抽一路摄像头用 FFmpeg 原始保存录像并回放确认画面没有检测框。确认录像保留策略已配置并测试删除逻辑。记录发布操作人、时间、配置哈希归档到证据目录。8.3 扩展方向隐私保护优先的监控设计如果业务方未来允许在部分场景使用 AI 分析可以提前考虑“隐私保护优先”的架构。例如在分析前对人脸区域做马赛克处理只输出人数统计结果或者把 AI 推理放在本地边缘设备避免原始视频外传再或者使用差分隐私技术让人群热力图无法反推个体轨迹。这些扩展方向的核心思路是一致的不是在所有场景默认开启 AI而是默认关闭由业务方按具体用途申请开通并留下完整审计链路。这样既能满足安防需求也能回应活动参与者对隐私的合理关切。对工程师来说处理“禁用 AI 监控”这类需求时最重要的技术判断不是如何写代码关闭开关而是如何让“关闭状态”在配置、进程、模型、特征库、日志和网络六个层面同时成立。把这个工程思维固化下来以后无论是做合规改造还是设计新的视频平台都能少走很多弯路。