多门店企业行业AI人事系统SaaS部署的最佳实践

我参与过19个多门店企业的信息化选型与落地，其中7个项目直接涉及AI人事系统的SaaS部署。最早一个项目是2021年帮一家152家门店的连锁餐饮企业做人力系统切换，上线第三个月就遇到区域数据断流的事故，不是因为系统不稳，而是我们在部署阶段对“数据主权”和“权限矩阵”的理解出了偏差。这件事让我彻底明白：多门店企业部署AI人事系统，真正的难度从来不在功能配置，而在管理逻辑和系统架构的匹配。市面上绝大多数SaaS产品功能列表看起来都差不多，但真正上线后能不能用、好不好用、会不会反噬管理效率，差距全在部署阶段被锁死。这篇文章把我过去几年踩过的坑、验证过的判断、和多家企业IT与HR部门反复博弈后沉淀下来的经验，拆解成一套可复用的部署框架。如果你正在评估选型或准备上线，这篇文章至少能帮你避开三个最贵的错误。

一、核心结论：多门店AI人事SaaS部署的本质不是“上线一套软件”

先给结论，再拆逻辑。

核心结论一：多门店企业部署AI人事SaaS，本质是在构建一套“管理控制塔”而非采购一个工具。单门店企业上人事系统，解决的是一维问题，把HR从事务性工作中解放出来。多门店企业面对的则是三维问题：总部管控力、区域灵活度、门店执行力三者之间的永恒张力。系统的每一次配置选择，都是在为这三者的权力边界划线。

核心结论二：部署成败的关键分水岭不是“选哪家厂商”，而是“用什么节奏和规则把系统嵌进现有管理肌理”。我见过同一套系统在A企业成功、在B企业翻车，差异不在于产品本身，而在于部署策略和变革管理。

核心结论三：AI能力是部署的“放大器”而非“救火队”。基础数据质量和流程标准化程度决定了AI发挥的上限。如果考勤数据混乱、排班规则从来没人说得清楚，上了AI排班只会加速混乱的再生产。这个判断在后面第三章会展开详述。

把这三个结论拧成一句话：多门店AI人事SaaS部署的最佳实践，是在正确的时机、用正确的节奏、把正确的模块交到正确的人手里，并在全过程中保持“数据资产意识”和“组织变革意识”的双线并行。

二、真实场景解剖：多门店人力管理的五层结构性困局

要理解部署策略，必须先理解场景。我2019年帮一家区域零售品牌做管理诊断，当时他们87家门店分布在5个省，人力管理的问题能拍一部纪录片。这里用匿名化处理后的真实场景，把多门店企业人力管理的困局拆成五层。

1. 考勤层：时间数据在地理和制度双重维度下失准

第一家店用指纹机，第二十五家店改用刷脸设备，后来收购的一个区域用纸质签到。总部HR每个月收到各门店的考勤表，格式多达十几种。最极端的案例：一个区域经理用Excel手工合并考勤，连续三个月漏算了某个员工30多小时的加班，最后在仲裁时才被发现。

这不是个别现象。多门店企业扩张过程中，考勤硬件和制度版本不一致是常态。不同门店的开业时间、班次类型、加班规则、节假日计算方式都可能不同。SaaS系统部署要解决的第一个问题，就是把多版本的考勤规则统一到一个可配置的框架里，而不是要求所有门店适配同一套逻辑。

2. 排班层：经验驱动的“人肉排班”遇到规模天花板

一家120家门店的连锁火锅企业，排班靠各店长手动操作。店长根据“感觉”排班，明天感觉会忙就多排人，感觉会淡就少排。总部无法干预，因为总部也不知道每家店明天会不会下雨、旁边商场有没有活动。

结果是：好店长排出的班次人效高、员工满意度高；普通店长排出的班次要么人力冗余、要么高峰时段缺口。经验和能力的不均衡直接转化为成本和人效的不均衡。当门店数超过50家，总部不可能再靠“培养更多好店长”来解决这个结构性问题。

3. 算薪层：300个区域变量下的计算黑洞

多门店企业的薪酬计算复杂度是单门店企业的几何级增长。不同城市的社保基数下限不同、公积金比例不同、个税专项附加扣除规则虽然全国统一但申报情况因人而异。加上门店层面的绩效提成规则、全勤奖、工龄工资、异地调动补贴，我见过最复杂的案例涉及超过300个变量。

2020年一家企业因为薪酬计算出错，被员工集体仲裁，最后追溯发现是某个区域HR在计算跨省调动员工的社保衔接时间时出错了，这个错误连续滚了14个月。SaaS系统的算薪引擎能不能处理这种“区域差异+个人差异”的叠加，是选型和部署时必须验证的核心能力。

4. 合规层：劳动法规的地域差异制造“合规盲区”

很多人忽略了这一点。中国的劳动法规在省级和市级层面存在大量差异。比如综合计算工时制的审批规则、高温补贴的发放标准和时段、婚假天数，这些都不是全国统一的。多门店企业如果总部在某一个城市，很容易默认以总部的规则覆盖全国，这在法律上是非常危险的。

我在一个项目中盘点过一家跨8省的企业，发现在3个省存在不合规的加班计算方式，而HR部门居然不知道，因为总部HR只看汇总数据，不看法条原文。SaaS系统在部署时必须建立合规规则库的“属地化配置”，这是很多厂商不会主动提醒你的。

5. 数据层：门店经营数据与人力数据的割裂

最后一个困局最为隐蔽。绝大多数多门店企业的人力数据和经营数据是两张皮：HR系统里看得到工时、人力成本，收银系统里看得到营业额、客流，但这两组数据从来没有真正“对话”过。

当一个店长说“我人手不够”，总部无法用数据验证，不知道这个店的客流峰谷、翻台率、人均产出。反过来，当总部砍人头预算，店长也无法用数据证明这会伤害服务质量和业绩。人力数据和业务数据的割裂，让“人效”沦为一句口号而不是一个可管理的指标。

三、最常见的三个部署误区，每个都至少烧掉企业六位数

这节来自我亲身参与过的失败复盘。以下三个误区，我在至少三个不同项目里见过不同程度的翻车版本。

1. 误区一：“选最全的功能，一次性全上，一步到位”

2021年一个项目，企业选了一套功能极其丰富的系统，从招聘、入职、考勤、排班、绩效、薪酬、培训到人才盘点，全部模块在两个月内同时上线。结果上线三个月后，系统使用率不到40%，大量功能无人问津，一线店长抵触严重。

复盘时发现三个致命问题：

第一，功能堆砌不等于价值实现。很多功能总部觉得很重要（比如人才盘点、九宫格），但一线店长根本不关心。店长关心的是：排班能不能快一点？员工请假能不能手机上搞定？

第二，组织消化能力有上限。一家企业的管理习惯和数据基础是有限的，同时涌入十几个新模块，HR部门和一线管理者根本没有足够的认知带宽去吸收。

第三，问题反馈被稀释。当所有模块同时上线，出问题时你分不清是哪个模块的问题、还是系统本身的问题、还是操作培训的问题。问题定位困难导致解决效率极低，久而久之“系统不好用”就变成了所有人的集体认知，而这个标签一旦贴上就很难撕掉。

我现在的标准建议是：先上“高频刚需”模块，用成功建立信任，再用信任推动扩展。考勤和排班是一线使用频率最高的功能，也是管理价值最容易被感知的切入点。

2. 误区二：“我们先用免费版或轻量版试试，后面再升级”

这个误区的迷惑性极强。听起来很稳妥，实际上在多门店场景下是一个昂贵的陷阱。

我亲历过一个案例：企业先选了一个轻量SaaS跑基础考勤，一年后发现需要AI排班和薪酬联动，但轻量版的架构不支持这些扩展。数据迁移成本、重新培训成本、管理习惯切换成本加起来，比当初直接上专业版还高出70%。

更严重的是数据连续性问题。迁移过程中历史考勤数据出现格式不兼容，导致一批员工的年假余额、加班累计对不上，引起内部不满。

多门店企业选人事SaaS，做的是“基础设施级”的投资决策，不是买个试试看的消费品。评估时应该以“三年后我的需求是什么”为基准来审视当前系统的架构弹性，而不是以“当前最痛的一个点”来决定。

3. 误区三：“AI功能越强越好，我们直接上全自动排班”

这是最近两年出现的新误区，随着“AI排班”“智能预测”的火热而蔓延。

2022年底，一家企业把排班完全交给AI算法，全面取消店长排班权。结果两个月后出现明显问题：AI基于历史客流数据预排的班次，无法应对突发天气、隔壁新店开业、市政施工封路等“非结构化变量”。这些变量是AI训练数据里不存在的。于是出现连续好几次门店高峰期人手不足、顾客投诉激增的情况。

核心问题在于：当前的AI排班模型擅长处理“规律性业务”，对“低频高影响的偶发事件”缺乏应变能力。而店长恰恰是这些偶发事件的“传感器”。

正确的部署姿态不是“AI替代店长排班”，而是“AI生成排班建议 + 店长基于本地信息做调整 + 调整数据回流优化模型”。这形成一个人机协作的增强回路，而不是一次性的自动化替代。

四、专业判断框架：选型评估的六个“必查项”

选型是部署的前置环节，选错了部署再好也无用。以下是经过多个项目验证的六个“必查项”，每一个都对应着多门店场景下的特定风险点。

1. 多组织架构的灵活度，不只是“支持多层级”这么简单

几乎所有人事SaaS都声称支持多组织架构，但这个“支持”的深度差异巨大。你需要验证的是：

能否支持“业务组织”和“行政组织”双线并行？比如一个员工行政上归属A门店，但业务上被借调到B区域做支援，他的考勤、绩效、薪酬数据应该怎么流转？很多系统只能走单线组织树，遇到借调场景就崩溃。

组织架构调整时，历史数据会不会“断血缘”？门店拆分、合并、关店、新开店，这些在连锁企业是高频事件。系统能否在组织架构变更后自动追溯和重算历史数据？我在一个项目中专门测试过这个场景：把一家店的10名员工模拟拆分到两家新店，然后回溯6个月的薪酬报表，不少系统在这里出现了数据不一致。

以I人事为例，其组织架构设计支持多层级、多类型组织的灵活组合，在连锁零售和餐饮行业的部署中，我发现其“组织调整后的数据自动重算”能力是一个被低估但极其重要的功能点，尤其在企业经历并购整合或区域重组时。

2. 权限矩阵的颗粒度，“总部-区域-门店”三级的权责闭环

多门店企业的权限管理远比单门店复杂。不是简单的“总部看全部、门店看自己”。

你需要验证的场景包括：区域经理能否看到所辖门店的排班详情和人力成本？店长能否在一定预算内自主调整编制？总部HR能否实时看到每家门店的考勤异常？同时，敏感薪酬数据是否只对特定角色开放？

一个好的权限矩阵应该是“可配置的角色权限+可下放的审批节点+可追溯的操作日志”三合一的体系。我在评估系统时会设计一个“权限穿透测试”：用不同角色登录系统，逐一检查每一个数据字段的可见性和可编辑性，记录所有盲区和越界点。

3. 算薪引擎的区域合规能力，属地化规则的覆盖度和更新速度

这个检查项非常具体：

（1）社保公积金计算规则是否覆盖你所有业务省份？是否支持定期自动更新？

（2）是否支持不同门店使用不同的薪酬结构和核算周期？比如餐饮门店和总部职能部门可能在发薪日和薪酬结构上完全不同。

（3）能否处理跨区域调动员工的薪酬衔接？当员工从A省调往B省，他的社保转移期间的基数计算、补缴逻辑，系统是否自动处理？

我用过的一个检验方法是：调取系统过去12个月的规则更新日志，看国家或地方政策变动后，系统厂商的响应速度。一些有实力的厂商（I人事在这方面的表现给我留下较深印象）能做到政策发布后5个工作日内完成系统规则更新，这个效率对多区域企业来说直接关联合规风险敞口。

4. 外部系统对接的深度，不是“有API”就行了

“我们支持开放API对接”是SaaS厂商最常用的回答，但这个回答涵盖了从“真正好用”到“几乎不能用”的全部谱系。

你需要追问的是：有没有与你已在使用的收银系统、ERP、企业微信/钉钉的预置连接器？这些连接器是厂商自己维护的还是依赖第三方中间件？数据传输的实时性如何？

我曾帮一家客户测试过一个声称“支持对接主流收银系统”的SaaS，实际对接后发现：客流数据只能按天同步，不能按小时，这意味着“按小时预测排班”的AI功能完全无法使用。厂商的回应是“可以定制开发，周期3个月，费用另计”。

在多门店场景下，“人效分析”要真正发挥作用，必须实现人力数据和业务数据的准实时打通。I人事在餐饮零售行业的不少部署案例中，已经跑通了与主流收银和ERP系统的业务数据对接，这是我看重的一个务实能力。

5. AI能力的可验证性，不要听PPT，要看“双盲测试”

判断AI能力真伪，我有一套简单有效的方法：

让厂商用你企业脱敏后的真实数据跑一遍，然后用业务指标来验证。比如排班场景下，把过去3个月的实际客流数据和实际排班数据给到系统，让AI生成“最优排班方案”，然后和实际发生的排班结果做对比，看人均产值、工时利用率、高峰期覆盖度这几个硬指标是否有明显改善。

一家厂商如果不能或不愿做这种测试，你要对其AI能力的真实性保持怀疑。另外要留意区分“规则引擎”和“机器学习”，很多号称AI排班的产品，本质上是把店长排班经验转写成if-else规则，没有真正的预测和优化模型。

6. 部署与服务体系，上线不是结束，而是开始

最后但绝对不可忽视的一点。SaaS模式下，厂商的持续服务能力直接影响系统在企业内的生命力。

你需要考察的维度包括：实施团队是否有同行业同规模的经验？上线后的支持响应机制是什么样的？是否有专属客户成功经理？季度业务回顾机制是否建立？

一个容易被忽略的细节：厂商的人员流动性。如果一个厂商的客户成功经理半年换三拨，你的系统在内部就很难建立起稳定的使用习惯和信任关系。

五、部署实施的“三步走”路线图

基于前面的选型框架，进入真正的部署实施阶段。以下是我在多门店企业项目中反复验证过的“三步走”路线图。

1. 第一步：试点验证（1-2个月，2-5家门店）

不是全量上线，而是精选试点。

试点的选择很有讲究。不要选最好的店，也不要选最差的店。选2-5家“典型门店”，代表你不同业态、不同区域、不同规模的截面。试点的目标不是证明系统多好用，而是提前暴露问题。

试点期间需要做三件事：

（1）数据清洗与对标：把试点门店的历史考勤数据、排班记录、薪酬明细做一次完整盘点和清洗。脏数据不入库，这个原则能让你避免后续无尽的纠错。

（2）规则配置与验证：把每家试点门店的考勤规则、加班规则、排班逻辑在系统里一一配置，然后用人肉跑一遍验证。特别关注跨门店借调、跨天加班等边界场景。

（3）一线反馈收集机制：指定试点门店的对接人，每周做一次使用反馈汇总。这个反馈是后续全量推广时的“说明书”和“培训案例库”。

2. 第二步：分批推广（2-3个月，按区域或业态批次推进）

试点跑通之后，进入分批推广阶段。不建议一次性推到全部门店。我的经验是按区域或业态分3-5批，每批上完后稳定2-3周再启动下一批。

这个阶段有四个关键动作：

（1）建立“推广作战室”：总部HR、IT、厂商实施团队组成联合小组，每日同步进度和问题。推广期的问题响应速度直接影响一线对系统的信任度。

（2）培训分层执行：店长层、区域经理层、普通员工层，三层的培训内容和深度完全不同。店长需要掌握排班、审批、数据查看；区域经理需要掌握数据分析和异常管理；普通员工只需会打卡、请假、查工资条。

（3）设置“过渡期双轨运行”：新系统上线后，原有考勤方式保留1-2周作为备份。这不是对系统不自信，而是给一线一个心理安全垫。

（4）建立问题升级通道：一线问题→门店对接人→区域HR→总部项目组→厂商支持。每一级有明确响应时限，比如一线问题4小时内回复。

3. 第三步：优化迭代（长期持续）

全量上线不是终点。SaaS系统的一大优势是持续迭代，但很多企业把它当“装完就完了”的本地软件用，完全浪费了SaaS的价值。

优化的方向包括：

AI模型调优：基于积累的数据持续优化排班模型、人效预测模型的准确率。这个需要厂商配合，也是判断厂商AI能力真伪的持续性检验。

流程自动化扩展：从考勤排班逐步扩展到入职、转正、调动、离职的全生命周期自动化，再到绩效、培训等模块的逐步上线。

数据应用深化：把人力数据和业务数据的联动从“看报表”升级为“做预测”，比如根据下季度开店计划预测人力需求、基于历史数据做关键岗位离职预警。

六、行业实践案例与数据观察

以下案例经过脱敏处理，但数据和场景均来自实际项目。我会尽量保留有参考价值的细节。

1. 餐饮连锁案例：152家门店的考勤排班重构

这是我在2021-2022年深度参与的一个项目。152家火锅连锁门店，分布在12个省份，员工总数约4800人。

部署前状态：考勤设备七种不同品牌，排班全靠店长手动，总部HR每月用两周时间合并薪酬数据。关键痛点是：人力成本占比持续上升（从22%爬到28%），但店长仍然喊“人手不够”。

部署策略：选择I人事作为核心人事系统（此前评估了三家厂商），采用“试点（5家店）+分批推广（按3个区域分三批）+全量上线”的三步走节奏。

关键决策点：我们先上考勤和排班模块，薪酬模块维持原有系统并行两个月，确保数据一致性后再切换。这个决策避免了薪酬计算出错的风险。

数据观察：上线6个月后，工时利用率从71%提升到84%，排班耗时从店长平均每周6小时降到1.5小时，薪酬计算错误率从1.2%降到0.04%。更关键的是：总部第一次能实时看到每一家门店的实时人效数据，这个变化对管理决策的影响远超效率提升本身。

2. 零售连锁案例：跨区域合规管理的系统化落地

第二个案例是73家门店的区域零售企业，主营服装连锁，分布在华东和华南6省。

部署背景：这家企业之前经历过一次劳动仲裁，因为华南某市的高温补贴发放不符合当地标准，被员工集体投诉。这个事件促使管理层决定系统化解决多区域合规问题。

部署重点：合规规则的属地化配置是整个项目的核心。我们和厂商一起，把6省23市的所有劳动法规差异逐一录入系统，包括最低工资、社保基数、高温补贴、婚假天数、加班计算规则等。这个过程花了将近一个月，但让所有区域HR第一次有了“合规清单”而不是凭记忆和感觉办事。

关键收获：系统上线后，合规风险的“被动发现”变成了“主动拦截”，当某个区域HR试图录入一条不符合当地法规的薪酬计算规则时，系统会自动提示。从上线至今，这家企业没有再出现一起劳动合规纠纷。

3. 先进制造场景：AI排班从“能用”到“好用”的三次迭代

第三个来自先进制造行业，一家有21个生产基地的企业，每个基地有多个生产班组。排班需要考虑的因素包括：设备产能、订单波动、员工技能等级、安全生产要求、法定工时限制等。

关键经验：AI能力需要“喂养”足够多的高质量数据才能发挥作用。上线第一个版本，AI排班准确率只有72%，远低于店长手动排班的85%。团队没有放弃，而是做了三件事：

第一，回头清理了6个月的历史生产数据，修正了37处数据错误；

第二，把排班约束条件从最初设计的12个细化到31个，包括员工技能与工序的匹配关系；

第三，建立了“AI预排+班组长微调+数据回传”的闭环，让每一次人工调整都成为下一次AI学习的素材。

三次迭代后（约4个月），AI排班准确率达到91%，超越了经验最丰富的班组长。这个案例让我真正理解了“AI部署不是上线一个功能，而是启动一个持续优化的飞轮”。

七、不同规模与阶段下的行动取舍

部署策略不能一刀切。以下按企业规模和扩张阶段给出差异化的取舍建议。

1. 快速扩张期企业（每年新增门店超30%）：牺牲局部效率保全国统一

快速扩张意味着管理复制速度决定了增长质量。这个阶段的部署原则是：标准化优先于个性化。

具体来说：用SaaS的标准配置先让新门店快速接入管理框架，不纠结于个别门店的特殊需求。哪怕某个区域的特殊排班规则暂未被系统完美支持，也暂时用近似方案替代，等系统稳定后再做精细化配置。

代价是：局部可能会有3-5%的效率损失。收益是：管理框架不会因为扩张而崩溃。这个取舍在快速扩张期是值得的。

2. 稳定运营期企业（门店数基本稳定）：打磨数据应用深度

门店数不再大幅变化的企业，部署重心应从“管控”转向“优化”。

核心动作是打通人力数据与经营数据的闭环，做真正的“人效分析”。比如：把每家门店的人均产值、工时利用率、人力成本占比做成月度趋势图，关联门店的营收、客流、客单价，找到人效改善的杠杆点。

这个阶段可以启用更多AI能力：离职预警、人效预测、智能排班深度优化等。因为数据基础已经比较扎实，AI发挥的边际价值更高。

3. 跨业态集团（旗下有不同业务类型）：建立“共享核心+业态插件”架构

同时经营餐饮、零售、制造等不同业态的集团企业，管理复杂度最高。

部署策略建议：选择具备“多业态支持”能力的SaaS平台作为核心（统一组织架构、薪酬发放、合规管理），然后为不同业态配置差异化的“业务插件”（考勤规则、排班逻辑、绩效方案）。

这里最忌讳的就是“一个系统覆盖所有业态”，在现实中没有哪个通用产品能完美适配差异巨大的业务场景。但同时要避免“不同业态用不同系统”，那会导致集团层面完全丧失数据整合和管理洞察能力。

八、容易被忽略但至关重要的三个部署细节

以下三个细节，我几乎在每个项目都遇到，但很少有厂商或文章会专门提到。

1. 历史数据迁移的“清洗窗口期”

部署SaaS时，历史数据迁移不是“全量搬过去就行”。我问过很多企业：你的历史考勤数据有多少是准确可靠的？大部分回答是“不太确定”。

我的建议是：只迁移最近12个月的完整数据，更早的数据仅保留汇总级别。同时利用这个“清洗窗口期”做一次全面的数据盘点，把格式不一致的、逻辑矛盾的、重复或缺失的记录挑出来处理掉。

迁移全量脏数据等于在新系统里埋满了未来会爆炸的地雷。

2. 移动端体验决定系统在一线的生死

总部HR在电脑上用系统，一线店员和店长在手机上用系统。如果移动端的打卡、请假、排班查看等功能的体验不好，加载慢、操作复杂、界面反人类，系统在一线的使用率就会断崖式下跌。而一旦一线不使用，所有基于数据的管理决策都成了无源之水。

在选型阶段至少让5个一线员工代表试用移动端超过一周，收集他们的真实反馈。不要只看功能演示时的流畅度。

3. 系统切换的“情感过渡期”设计

最后这个点很少有人提。系统切换不仅是技术动作，也是情感动作。对于一家用了很多年旧系统或手工方式的门店来说，切换到新系统意味着学习成本、不确定性和对自身价值的重新定义，特别是对于年纪较大、不熟悉智能设备的店长或老员工。

成功的做法包括：提前2-4周做预热沟通，解释“为什么换、换了对你有什么好处”；在切换期间设置“老带新”的辅导机制；对适应快的门店公开表扬并分享经验。

忽略这个情感维度，即使系统本身优秀，也可能在组织层面遭遇冷暴力式的抵制。

九、总结：多门店AI人事SaaS部署的长期主义

回顾整篇文章的核心脉络：

第一，部署的本质不是技术动作，而是管理升级。系统是镜子，映射出管理逻辑的清晰度。如果内部管理逻辑本身是一团浆糊，再好的系统也只会加速混乱的可见化。

第二，不要在功能列表上做加法，而要在核心场景上做深度。考勤、排班、薪酬，这三件事稳了，再逐步扩展其他模块。欲速则不达在多门店场景下尤其成立。

第三，数据质量是AI的上限，组织接受度是系统的下限。两条线都要抓，偏废任何一方都会让投入打水漂。

第四，选对厂商很重要，但更重要的是选对和厂商合作的方式。把厂商当作“实施伙伴”而非“软件商”，在部署过程中充分借助厂商的行业经验和产品迭代能力。

如果要从这篇文章带走一个立刻能用的动作：在本周内，找3-5家典型门店，做一次历史人力数据的全面盘点。你可能会发现，在选任何系统之前，自己的数据地基需要先修补。而这件事做完，你至少已经比80%的多门店企业更接近成功的部署。

最后说一个我自己的判断：未来三年，多门店企业的人力管理必然走向“AI辅助决策+属地灵活执行+总部数据洞察”的三层架构。今天部署AI人事SaaS，本质上是在为这个即将到来的管理范式构造基础设施。早一步做对部署，就早一步建立人效管理的竞争壁垒。早一步做错部署，付出的纠错成本可能比从零开始更高。

值得做的，就值得做对。