站在零售数字化项目坑里爬出来的我第一眼看到“Flutter鸿蒙共赢”这几个字想到的并不是什么高深的技术选型而是去年年底一个连锁便利店客户的真实诉求门店几百个SKU哪些在动销、哪些在仓库里睡大觉、哪些该补货、哪些该清仓全部靠店长拍脑袋总部的采购Excel表看得眼睛都快瞎了。他们要的其实就一句话——把SKU卖得动卖不动这事跟库存压了多少货这堆数变成一张手机上看一眼就明白的图。而恰好那阵子我刚把一套Flutter写的App适配到鸿蒙上跑通两边需求撞到一起就有了这个智慧零售场景下的SKU动销与库存健康度看板项目。这篇文章我会把整个项目的设计思路、核心的业务计算模型、Flutter跑鸿蒙的实操细节以及上线后踩过的那些坑全部摊开来聊。适合正在做零售数字化、供应链看板或者刚把手头Flutter工程往鸿蒙上迁移的朋友参考纯干货不铺垫。1. 项目全貌与方案选型为什么是Flutter 鸿蒙 SKU动销1.1 智慧零售里的真实痛点货架上的“沉默库存”零售行业的库存问题表面看是“压货多、周转慢”本质上是信息断层。总部看到的月报是汇总后的平均值门店看到的是每天进销存的台账数字而真正影响决策的“动销速度”和“健康状态”这类衍生指标反而没有任何系统能给个准话。这个项目要解决的核心问题有三个层级。第一层是“看得清”每个SKU的销量趋势、动销频次、库存水位是多少第二层是“算得准”把动销数据和库存数据映射成一个可量化的健康度分数而不是只靠“感觉卖得不错”来判断第三层是“跟得上”店里店长、总部采购、运营总监各自打开同一个看板看到的是同一套逻辑得出的结论。跟我之前做过的纯报表项目不太一样这个项目的难点在于数据口径的统一和指标模型的可解释性。你直接甩一个综合健康度分数给店长他不信你得能拆出这个分数是怎么来的、由哪几个指标组成、为什么这个周显示黄色预警。所以架构上从一开始就不是做一个大而全的后台而是把核心指标的计算做成了可配置、可拆解的服务。技术侧还有个隐性需求——客户的店员手里的设备五花八门有安卓、有苹果还有陆续换上的国产鸿蒙设备如果每个平台各做一个原生App维护成本直接翻倍。这就引出下面这个选型问题。1.2 技术选型的底层逻辑Flutter与鸿蒙的“共赢”关系先说结论如果只是把鸿蒙当成Android的换皮那是会踩大坑的。鸿蒙的UI框架、路由机制、生命周期管理跟Android有本质差异尤其HarmonyOS NEXT之后彻底砍掉了AOSP兼容层很多老的Android思路直接失效。选Flutter的原因不光是跨端省成本更重要的是Flutter的渲染引擎是自己那套Skia/ImpellerUI层并不依赖系统的原生控件所以在鸿蒙上跑Flutter引擎本身是自带渲染能力的只需要适配好平台通道、生命周期、输入事件这几层。说直白一点Flutter App在鸿蒙上更像一个“自带渲染器的应用”系统要管的只是给Flutter引擎提供一个宿主容器和必要的系统服务调用入口。这个“自带渲染器”的特性让Flutter做鸿蒙适配的成本比React Native那类依赖原生桥接的框架低很多。我在工程里直接沿用了原有Flutter业务代码花在鸿蒙适配上的时间主要集中在入口工程配置、平台插件补齐、以及部分系统能力比如通知、存储权限的鸿蒙化调用。当然不能回避的是Flutter官方对鸿蒙的支持走的是OpenHarmony社区分支并不是Flutter SDK自带的。实操起来需要把依赖切到社区的ohos分支版本并配合DevEco Studio完成鸿蒙侧的编译打包。具体怎么配后面第3章我会详细讲。1.3 整体架构设计从订单数据到健康度看板这个项目的整体链路不复杂但每个环节都有值得抠的细节。数据从门店POS系统和ERP仓库系统流出经过ETL清洗后入数仓然后通过指标计算服务产出SKU动销表和多维健康度评分最终由Flutter编写的看板App拉取接口并渲染前端图表。我画在纸上的架构分四层。第一层是数据采集层门店的一笔订单就是一个事实记录POS的数据通过定时任务同步到Kafka仓库的出库入库单据走ERP的增量接口第二层是计算层Spark批处理计算昨日、近7日、近30日的动销指标同时在Redis里维护实时热Key支撑“今日实时动销”这种对时效性要求高的指标第三层是服务层面向C端的查询接口按门店、品类、时间范围三个维度组合返回指标数据接口设计上直接按看板组件所需的数据结构来定避免前端做二次计算第四层是展示层Flutter App内的首页看板、SKU列表、库存预警三个大模块。关于Flutter在其中的角色它是纯展示层不做业务计算。所有指标口径都在服务端算好App只负责渲染和交互。这么设计的原因很简单——业务人员在不同端上看到的数字必须完全一致如果App端也做一套打折逻辑Debug的时候会疯掉。2. 核心业务模型拆解SKU动销分析与库存健康度量化2.1 动销脉动从订单流水到趋势信号如果说“动销”这个词听起来有点玄那就用最直白的话解释动销就是商品真的被卖出去换成了钱而不是躺在仓库里吃灰。一个SKU的动销分析不能只看总销售额更要看它是均匀地卖还是在某几次促销里集中爆发。我在这套系统里引入了几个关键指标第一个是动销率公式很简单有真实销售记录的天数除以统计周期天数乘以100%。比如一款饮料在过去7天里有5天产生了销售记录那它的7日动销率约为71.4%。这个指标比销量本身更能反映产品有没有稳定的消费需求。第二个是动销深度看的是同一个SKU在多少家门店里有动销记录。覆盖的门店越多说明这个SKU的接受度越广。哪怕它总销量不高只要动销深度在涨说明铺货正在起效果反过来如果总销量高但动销深度很低很可能只是少数几个门店在冲量潜在风险是过度依赖单一门店。第三个是动销波动度计算周期内每日销量的变异系数用来判断销售是稳定还是脉冲式。零售业务的季节性很强不是所有SKU都要求“稳定”比如冰淇淋就天然是夏季脉冲但像牙膏、纸巾这类日用品波动度过大往往意味着消费习惯没有养成或者促销把未来的销售透支了。这三个指标合在一起就是“动销脉动”的数字化表达。业务人员在App上看到的不只是“某SKU卖了多少”而是知道它卖得稳不稳、在哪些门店卖得动、有没有出现异常波动这三条信息叠加起来才谈得上对库存做健康度判断。2.2 库存健康度评分模型把直觉变成可计算的分数库存健康度这个事很多团队的做法是圈几个阈值库存大于多少算积压小于多少算缺货。这种粗暴切分在真实生意里经常被投诉因为“合理库存”跟SKU的品类、毛利、供货周期、季节系数都强相关。我采用的方案是加权评分法每一个SKU在每日数据跑批后会按五个维度打分最后合成一个0到100的健康度综合分。这五个维度分别是库存周转天数得分、库龄得分、动销率得分、安全库存覆盖率得分、缺货风险得分。其中周转天数得分是最基础的一项以该SKU过去30天的日均销量为分母当前可用库存为分子算出按现有速度需要多少天卖完。不同品类设定不同的基准线生鲜3天内合理日用百货15到30天季节性商品按对应季节压缩或放宽。得分逻辑是偏离合理区间越远扣分越多不管是积压还是空转都算不健康。库龄得分针对的是“沉睡库存”按入库时间算库龄超过30天、60天、90天分别触发不同的衰减权重。这里有个容易被忽略的细节库龄得分必须按批次算同样的SKU可能有一批入库15天、另一批入库70天库存账看似总量正常实际结构已经分化了。所以我在计算时按批次加权70天的批次占比越高整体扣分越重。动销率直接复用2.1的指标覆盖率得分则是回答一个更实际的问题以现有库存和平均每日销量还够卖几天用安全库存作为一个缓冲阈值低于安全库存且供应链补货周期内预计消耗完就要提级为缺货预警。缺货风险得分用来识别那些“今天能卖但明天就断”的SKU这类往往被总库存充足的表象掩盖住得用下单补货频率和预测销量来单独判断。五项得分各占20%权重最终输出一个健康度总分同时映射到“健康、预警、风险、积压/缺货”四个档位。得分模型上线后我记得最清楚的一个案例是有一款坚果礼盒月销售额很高按传统指标算是明星品但它的动销深度极低只有两家门店在卖且库龄超过80天健康度总分只有51分系统把它从“明星品”降级为“风险品”采购核实后果然发现是连锁节日促销冲的虚量节后退货率高达三成。这就是模型把直觉数字化之后的价值——不再被表面销量骗到。2.3 数字化映射的可视化呈现从指标到看板模型算出来的健康度分数不是给人看的最终形态真正在店里值班的店长没空研究85分和82分的区别。所以前端要做一次“从数字到图形的映射”。首页大图用的是SKU动销热力矩阵横轴是最近7日动销率纵轴是库存健康度得分每个SKU按气泡形式散在矩阵里气泡大小代表30天累计销售额。这个矩阵图的好处是一眼能看出问题分层右上角是又卖得好又库存健康的“明星区”左上角是卖得好但库存有风险的“补货区”右下角是动销差但库存还多的“清仓区”左下角则是不好卖且库存也不深的“淘汰观望区”。页面侧栏是库存健康度预警列表按门店维度聚合展示TOP风险SKU、风险原因打标库龄过长、周转过慢、覆盖过窄、建议动作补货、调拨、促销、清仓。实际操作中我发现店铺店长最关心的不是列表本身而是“今天要做的事”——所以这个预警列表直接接入了任务流店长点“确认处理”后会生成一条事务记录追踪到处理结果。颜色体系上我用四色状态来区分健康等级绿色表示健康、黄色表示预警、橙色表示风险、红色表示严重异常。需要特别说明的是颜色阈值不是简单的“分数大于80是绿”而是结合SKU所在品类的差异化基线动态生成的。比如生鲜品类健康度65分可能已经是绿色因为周转本身就快、风险周期短而家电品类即使健康度80分仍可能显示黄色因为它们资金占压大、周转慢稍高一点的库龄都意味着风险。这个动态阈值逻辑是跟业务方反复过了三轮才定下来的。3. 双端开发实战Flutter工程接入鸿蒙的关键步骤3.1 工程初始化与鸿蒙化的正确姿势Flutter要跑在鸿蒙上市面上的资料很乱我实测下来最稳的路子是走OpenHarmony SIG社区维护的flutter_flutter仓库的ohos分支。整个迁移改造的核心是在原有Flutter工程里增加一个鸿蒙平台入口而不是把Flutter SDK替换掉重来。先把Flutter SDK切到支持鸿蒙的版本通过命令git clone -b ohos拉取社区分支并替换本机Flutter SDK路径。然后配DevEco Studio在原有Flutter工程中新建一个鸿蒙壳工程这个壳工程的职责是用HarmonyOS的UIAbility作为启动入口在其加载时初始化Flutter引擎实例并把Flutter的Dart代码作为so/har资源打包进鸿蒙应用。工程结构上会新增entry/src/main/ets目录里面是ArkTS写的入口和Flutter容器管理类。业务开发几乎还是纯Dart在pubspec.yaml里如果用到原生插件得确认该插件是否有鸿蒙的实现。这里最常踩的坑是很多第三方Flutter插件只有Android/iOS的实现鸿蒙运行时会直接MissingPluginException。我当时的做法是写一个插件适配层优先用官方鸿蒙实现没有的走自定义平台通道调用原生能力。编译链上鸿蒙侧需要配置签名、权限声明且版本匹配很有讲究。我用的组合是Flutter ohos分支的3.7.x版本搭配DevEco Studio 4.0和HarmonyOS SDK API 10。工程能跑通之后每次改动Dart代码都需要先执行flutter build hap生成鸿蒙产物再由DevEco加载运行不能直接沿用Android的install流程这个节奏一开始容易搞混。3.2 组件通信与状态管理的落地细节跨端开发最容易出问题的往往不是UI而是数据流的组织和事件传递。这个看板项目里我采用Riverpod做全局状态管理把SKU列表、健康度分值、门店筛选条件都定义为异步状态源业务组件通过watch监听变化保证了页面切换时数据的一致性。组件通信分三层来梳理。第一层是跨页面通信看板首页点击某个SKU气泡跳转到SKU详情页并传参我用Router传参加Provider覆盖初始状态两种方式结合第二层是同页面不同区块的数据同步比如顶部日期筛选器变化后热力矩阵、预警列表、统计数据区要同步刷新这里用了一个共享的ProviderfilterProvider所有区块都依赖它一改全改第三层是Dart侧与鸿蒙原生侧的通信用的是MethodChannel的自定义封装例如获取设备推送Token、查询系统存储权限这类能力统一封装成PlatformBridge类用平台分支判断当前运行在哪个系统上。这里分享一个关于异步任务的细节有同事问过为什么Flutter里.then的回调有时看起来像微任务有时又像宏任务。实际在Dart里Future.then默认就是以微任务方式调度的但如果你在回调里又嵌套了新的Future、调用了耗时Native方法或者回调所在的zone被改写了调度方式就会出现“明明先注册却是后执行”的错觉。在动销看板这种加载远程指标数据的场景我建议所有接口请求统一走async/await不在链式then里做跨页面的导航触发避免微任务与现任务交替时出现白屏闪烁。3.3 页面渲染与导航适配鸿蒙的布局习惯双端布局适配是UI层面最费时的一块。鸿蒙原生是ArkTS声明式语法跟Flutter的Widget树确实有差异但如果页面完全用Flutter构建那UI代码就是一份不需要重写。问题主要出在使用PlatformView的场景——比如嵌入PDF报表、播放营销视频这类。Flutter在鸿蒙上渲染本身靠Impeller新版或Skia旧版而PlatformView的嵌入走的是TextureLayer hybrid合成。实测下来少量、小区域的PlatformView比如单张商品图、简短视频没什么问题但如果在列表里快速滑动大量PlatformView鸿蒙侧容易掉帧因为每次混合合成都要做纹理拷贝。我的建议是能不用PlatformView就不用商品图、报表图全部转成Flutter侧渲染或直接走网络Image组件。导航结构上因为看板App是Tab应用底部导航在Flutter里用自身的BottomNavigationBar不存在适配问题。但鸿蒙有个交互习惯跟Android很不一样——右侧边缘左滑手势是返回Flutter侧GestureDetector如果拦了水平滑动就会跟系统返回手势冲突。项目里动销矩阵图需要横向拖拽查看就必须在GestureDetector上设置gestureSettings来协调。这点刚上线时被测试同学反复提bug后来在detail页禁用了边缘返回只保留顶部返回按钮才消停。4. 动销与健康度看板的功能设计与实操要点4.1 SKU热力矩阵一张图看懂全场动销热力矩阵是首页的核心组件交互上看是个可缩放可拖拽的坐标图。处理的数据规模是最大单店约3000个SKU全部门店汇总后可达40000个以上如果一次性把全部门店的SKU都渲染出来移动端内存直接爆。所以矩阵图默认只展示当前筛选门店下的SKU总店维度则只展示聚合到品类层的气泡点进去再下钻到SKU明细。气泡布局上我用了Flutter的CustomPaint自绘实现并没有直接套第三方图表库因为第三方库在气泡数量超过500后性能普遍明显下滑而且悬停气泡展示指标详情、点击气泡跳转SKU详情这类交互自绘更好控制。绘制逻辑不复杂先按横纵坐标把SKU归入25个网格再对每个网格内的气泡做碰撞避让防止气泡重叠。这步避让算法用的是最简单的斥力迭代每帧只跑一轮在400点以内帧率能稳定在60Hz。气泡颜色的语义上面已经讲过但要强调一个小细节矩阵中的坐标轴标签不能只显示数字范围要显示业务语义比如横轴0.5的位置要标“动销良好”而不是“50%”门店店长不是数据分析师语义化标签能使看板完全不需要培训就能看懂。4.2 库存健康度预警阈值怎么定才不会被骂预警阈值是整个项目里被业务挑战最多的地方。一开始我拍脑袋按“库存金额大于销售额的三倍”定积压线结果上线第一天就有六十多个SKU触发红色预警其中一半是季节性商品——夏季还没到仓库当然提前备货了。加班改了一周终于把规则改成一个三维判定模型。第一维是周转天数与品类基线的偏移比例不是看绝对值而是看相对差异第二维是动销率的变化方向如果一个SKU动销率连续七天上升即使绝对库存偏高也降到黄色预警而不是红色第三维是库龄结构超过90天的静置库存占比大于30%时直接触发红色预警。这套三维规则跑了一个月之后业务反馈“预警准确率能接受了”但我们还有一个不可说的潜规则——预警排序不只是按分数还要乘以“可处理性”权重。什么是可处理性比如一款进口矿泉水因为供应链周期长库存健康度分数低但让门店清仓是做不到的因为下个月还要卖。这种SKU预警排到后面去把处理精力聚焦在“现在就能处理”的呆滞库存上。这个加权逻辑对项目落地起到非常关键的作用建议做类似系统的人一定保留这个思路。4.3 Flutter下的图表与大数据量性能优化图表渲染的性能优化是Flutter做数据密集型应用绕不开的大山。动销趋势这里我一开始直接用fl_chart绘制近30日的销量折线但数据点一旦到上百个包在ListView里滑动时会明显卡顿原因是折线图每次setState都会重绘全部路径。后面改成了三个优化组合。第一个是图表组件用RepaintBoundary包起来隔离重绘范围不随页面的其他部分一起刷新第二个是把数据点做抽稀日粒度指标在折线图里不需要精确到天按区间聚合成10个左右的点曲线的视觉形状几乎不变绘制量减少了80%第三个是列表页的SKU卡片改成const构造 懒加载配合Flutter的ListView.builder一次只构建可见区域的数据。这三个优化做完后真机滑动帧率从25帧提升稳定到55帧上下。内存上动态监控发现过一个问题看板页所有页面都作为Tab懒加载常驻内存长时间使用后图片缓存暴增。处理方案是设置ImageCache最大字节数为80MB并且每次从后台切回来时清理不可见Tab的图片缓存。这个数值不是随便设的80MB对于中端鸿蒙设备是安全线超过容易OOM。5. 常见问题与排查实录含性能与稳定性5.1 Flutter在鸿蒙上的典型报错与处理这一章节直接放出我这两三个月来在鸿蒙设备上调试时碰到过的具体报错和处理方式真实有效。第一个是e/flutter (31173): [error:flutter/runtime/dart_vm_initializer.cc(41)] unhandled exception occurred。很多人一看到Dart VM初始化报错就以为SDK有问题实际上这个报错是“未捕获异常”的通告头真正的原因在报错后面的堆栈里。我遇到的一次是底层MethodChannel调用时原生侧抛了业务异常但Dart侧没有try-catch包裹异常直接穿透到引擎层。修法是给所有异步调用加统一异常捕获区返回一个可预期的Result对象而不是裸抛异常。第二个是Flutter平台插件在鸿蒙上运行时崩溃报MissingPluginException。排查步骤是看插件目录下有没有harmonyos的实现没有就改用自定义MethodChannel包一层让原生侧用一个统一入口接收并分发。注意鸿蒙上的原生插件包后缀是.har不是.aar社区仓库很多还没跟上得要自己做适配。第三个是关于Flutter的Impeller渲染引擎Impeller在鸿蒙的兼容性还在改进期部分中低端设备上打开三分屏或快速切换页面时出现渲染花屏。临时方案是回到Skia渲染在AndroidManifest里flutter.engine配置加上--enable-software-rendering的兼容模式等Impeller版本稳定再切回去。这个影响不大因为看板以图表为主软件渲染对性能影响很小。第四个是Future回调时序问题有的团队在页面A发起接口请求后在.then里直接Navigator.push跳转页面B结果偶发出现页面B先blank一帧再出内容。原因我在前面分析过Dart微任务队列的执行优先级与平台消息循环协同的问题在鸿蒙上比Android更容易触发。解决思路很粗暴跳转操作放在接口数据return之后显式赋值然后由UI层根据状态监听触发而不是在then回调里做导航。5.2 动销计算偏差那些数据对不上的夜晚业务部门对数据看板最敏感的不是功能有没有而是昨天前台显示的数字跟财务报表对不上。这里发生的两次偏差复盘一下第一次是订单状态过滤不完整。POS同步过来的订单流里有已取消、已退款、仅预占库存未支付等状态第一版ETL偷懒直接按状态字段全量入数仓结果“动销率高得好假”的SKU查下来发现多数是记账但未实付的订单。修正方案是在ETL层增加订单状态枚举白名单乙未付款不参与动销计算同时核对线下退款单保证“动销”对应的是真实资金流动。第二次是时间窗口跨时区问题。连锁门店分布在新疆和北京两地如果用服务器时区统一算昨日销量新疆门店夜里12点前的销售会算到第二天动销天数因此多了一天健康度里周转天数就偏差了。修法是所有动销指标计算之前先把订单时间按门店所在时区做本地化再按本地日期做切分。这个坑很容易踩建议做零售类数据项目的都在ETL层显式记录门店时区字段。5.3 看板App在鸿蒙端的基础问题速查表问题现象可能原因快速处理Flutter引擎初始化极慢或卡死在启动页鸿蒙壳工程里Flutter引擎创建时机不对或没有复用预热引擎实例在UIAbility的onCreate里预加载引擎并复用同一FlutterEngine实例动销看板图表白屏或闪退Impeller渲染不兼容切换至Skia兼容模式或通过命令行临时禁用Impeller商品详情页返回手势与图表拖拽冲突系统边缘返回手势拦截在图表所在页面禁用返回手势统一用顶部按钮返回更新Dart代码后鸿蒙包不生效忘记重新执行flutter build hap先build hap再在DevEco里运行不能直接热重载到鸿蒙壳工程库存预警推送收不到鸿蒙通知未申请鸿蒙通知权限或Push Kit未配置在module.json5中声明通知权限并按鸿蒙Push Kit规范完成配置列表页大SKU数据滑动掉帧图片缓存过大或列表未懒加载设ImageCache上限为80MB使用ListView.builder构建卡片项这里面我特别想再强调一次第一行的问题Flutter在鸿蒙上的启动优化非常重要。壳工程每一次冷启动都重新创建FlutterEngine的话鸿蒙的中端设备普遍要2秒以上才看到首帧对比Android上约1秒的体验有明显差距。我最后是让壳工程只创建一个引擎实例常驻页面切换只做Flow的切换而不是引擎重建。启动时间从2.1秒压到1.2秒操作体感完全不一样。5.4 实操心得给Flutter和鸿蒙新接触者的避坑建议说几个零散的实战心得未必写在任何官方文档里但每一个都是真金白银换来的。第一鸿蒙工程里引用Flutter依赖的时候不要直接照抄网上示例里的CocoaPods或者gradle的写法。鸿蒙走的是一套独立的构建链路Flutter产物要打成har包引用关系在oh-package.json5里配跟Android的gradle完全不通用。刚开始我拿Android的思路硬套编译报错到怀疑人生。第二动态权限的处理思路跟Android也大不一样。鸿蒙在API 9之后采用了严格的权限分组像定位、通知这类权限如果不在module.json5里先声明代码里申请会被直接忽略且不报错。看板第一次上线时门店定位上报功能在鸿蒙上静默失效查了半天才发现是权限声明漏了。第三Responsive UI不代表做三套布局。鸿蒙平板和手机尺寸差异挺大的但Flutter本身就有良好的自适应能力合理使用LayoutBuilder和MediaQuery就能覆盖绝大部分不要每遇到一个新设备就单独写布局。第四团队协作时Dart侧代码没问题的情况下鸿蒙和Android之间最大的摩擦点在版本号。Flutter ohos分支的版本演进比官方主分支慢不要随手升Flutter SDK版本否则鸿蒙壳工程编译时SDK版本和引擎产物不匹配会在DNS解析阶段报大量莫名其妙错误。我是固定了一个已验证的版本组合升版本前先在测试机上完整跑一遍鸿蒙链路。结束前最后一条实用经验这个项目上线跑了一个半月后我最大的体会是技术选型Flutter鸿蒙其实只占三成精力剩下七成都在跟数据模型和业务口径斗智斗勇。再漂亮的控件也顶不住业务一声“这个数不对”的投诉。所以如果你也要做类似“动销库存健康度”的系统我强烈建议把第2章的指标模型设计部分拉长讨论周期先让业务方认可算法逻辑再开始写第一行代码。另外预计算与实时计算相结合这个架构在类似规模的零售看板项目里值得复用。用Spark批处理算昨天和近7天的全量指标用Redis实时累加当日订单做“今日动销”——两个口径中间靠一个补偿任务去对齐既保证了指标深度又保护了接口的响应速度。如果你正打算折腾Flutter上鸿蒙别怕踩坑先把一个最简Shell跑通再把复杂业务一层层加进去。这大概是我在这次项目里最想强调的一句人话了。