企业官网建设流程全解析

1. 为什么要把空调系统和微电网放在同一张图上设计

前年夏天，我在一个园区微电网项目现场盯着EMS屏幕。下午三点零七分，屋顶和车棚的光伏出力从420kW开始往下掉，而园区集中制冷站的两台离心机组还在往上爬，加起来电耗眼看就要突破500kW，到傍晚六点半才能缓下来。那一瞬间我特别直观地意识到一件事：如果不把空调负荷和微电网的调度策略放在一起设计，配再大的电池也填不上这个"剪刀差"。

这个项目让我下定决心把暖通空调和微电网协同设计这件事好好梳理一遍。这篇文章就是基于那次经历，加上后续几个项目的复盘总结出来的。适合三类人看：一是做建筑机电设计的工程师，想搞清楚微电网到底怎么反过来影响空调系统选型；二是做微电网和能源管理的同事，想知道空调负荷这块"可调动的肉"到底有多大；三是刚入行的学生或转行者，想找一个把暖通、电气、自控串起来的切入角度。

1.1 空调负荷：建筑能耗里的"大头"和"活变量"

说到建筑能耗，暖通空调常年占据40%到60%的份额，公共建筑尤其明显。一栋三万方的办公楼，夏季空调尖峰电耗占到全楼总用电量的一半以上并不稀奇，照明和插座反倒成了配角。但这部分负荷有两个容易被忽略的特征。

第一个特征是它跟随室外气象、人员密度、室内设备发热来波动，一天之内的变化幅度可以超过一倍，而且这种变化不是线性的——气温超过30度之后，每升高1度，冷负荷的增量会明显变快。第二个特征是它自带惯性，你把制冷主机压掉一半，室内温度不会立刻跟着飙上去，可能过一两个小时才会有明显感觉。这两个特征放在微电网视角下，意味着空调负荷不是"只能被动供电的对象"，而是整个建筑里最值得精细调控的资源。

很多做微电网的同事一开始只盯着储能电池，把电池容量配得很大，结果发现初投资居高不下，回收周期被拉得很长。原因很简单：电池去平抑那些十几分钟、几十分钟级的波动是划算的，但让它去对抗整个下午的负荷攀升，等于让短跑运动员跑马拉松。

1.2 微电网最怕的不是缺电，而是出力和负荷对不上

建筑微电网以屋顶光伏为主要电源时，光伏出力曲线和建筑负荷曲线天然错位。光伏在中午前后出力最高，下午两点以后开始衰减；而办公建筑的制冷负荷往往在下午两三点才到峰值，傍晚下班前还有一个尾巴。没有储能的情况下，中午的光伏超出负荷那部分要么逆流上网，要么被限制掉，傍晚需要用电的时候光伏又帮不上忙，只能从大电网高价取电。

储能能把中午的富余电量搬到傍晚，但电池的容量做大了，成本、消防、占地、寿命全是问题。这时候如果能发动空调系统来"削峰填谷"，情况立刻不同：中午光伏大发时主动把室温多降一点，把冷量存在建筑结构里，下午光伏出力衰减后少开机组甚至停掉一两台主机，让之前蓄下的冷量慢慢释放。光伏曲线和负荷曲线的错位，就这样被建筑的"蓄冷能力"给缝上了。

1.3 协同的第一性原理：热惯性就是一台不花钱的"虚拟电池"

许多项目方第一次听我说"建筑热惯性可以当储能用"时，都会反问：这玩意儿储能效率多少？循环寿命多少？答案是，它不是电池，但它的作用机制和电池高度类似。

建筑围护结构、室内家具、空气本身都在吸热和放热。粗略估算，每平方米建筑面积在允许的舒适温度范围内上下浮动1度，大约能"存"进或放出10到30瓦时的热量，具体要看结构是重质还是轻质。一栋三万方的办公楼，按每平米净高平均计算，可用的热质量储能轻松达到1500到4500千瓦时——这个量级已经超过大部分建筑微电网实际配置的电池容量。电池最怕深度充放电损伤寿命，热惯性则没有循环寿命一说，你可以每天来回"充放"它而不需要担心衰减。

代价也有：热惯性的"充放电"功率小、响应慢，释放冷量的速度受制冷末端的换热能力限制；而且转移的能量要通过制冷机组来搬运，效率受机组COP影响。所以协同设计要解决的核心问题，就是给热惯性和电池分好工：热惯性负责小时级的负荷平移和削峰，电池负责分钟级的功率平抑和应急保障。两者搭配起来，整个微电网的调度空间会大得多。

2. 负荷侧摸底：先知道自己手里有多少可调的家底

很多项目一上来就谈控制算法、谈AI、谈平台，却连建筑的逐时负荷曲线都拿不出来。协同设计的第一步，永远是把负荷侧的"家底"摸清楚。我们当时花了三周时间做这项基础工作，后来回头看，这三周是整项目最值钱的投入。

2.1 能耗基线与逐时负荷曲线的建立

如果建筑本身有楼宇自控系统（BAS/BMS）和分项计量，直接导出历史一年的逐时电耗、冷量、水温等趋势数据。没有分项计量的项目，至少要把变压器低压侧的总表和空调配电柜的总表数据拉出来对齐。这里有个容易被忽略的坑：BMS的趋势记录经常存在坏点、断档和时钟漂移，直接拿去分析会被误导。我们当时的处理办法是先做数据清洗：剔除节假日和异常尖峰，把断档时段用前后同类型日的数据补上，再按周类型分类，分别画出工作日、周六、周日的典型负荷曲线。

有了基础曲线之后，要做负荷分解。把总电耗里照明插座这类基本稳定负荷去掉，剩下的气象敏感部分才是空调负荷。最简单的分解方式是做回归：以室外干球温度、太阳辐射、前一小时负荷作为自变量，用多元线性回归或随机森林拟合出负荷与气象的关系。拟合出来的残差部分再去看是不是和人员活动、大型设备启停对得上。这一步的价值在于，它告诉你空调负荷里"天气决定的部分"和"运行决定的部分"各占多少，后者才是协同控制真正能调动的空间。

2.2 热惯性到底怎么量化：从RC模型到现场辨识

负荷曲线只是结果，要给控制算法提供依据，还得拿到建筑的热动力学参数。这里最常用的做法是RC热网络模型，通俗讲就是把建筑拆成一组"电阻"和"电容"：墙体和空气之间、室内空气和室外空气之间的传热用热阻R表示，墙体和室内空气的蓄热能力用热容C表示。最简单的二阶RC模型包含两个节点：室内空气节点和围护结构节点，每个节点有自己的热容，节点之间以及节点与室外之间用热阻连接。

参数从哪儿来？设计图纸和规范里的理论值只能当初始猜测，真正靠谱的办法是现场辨识。我们做过一次很典型的实验：在非工作日的夜间，把空调系统完全关停两三个小时，记录室内温度的上升曲线，再启动机组恢复设定温度，记录温度回落曲线。这两条曲线用指数函数去拟合，时间常数就出来了。常规办公楼的室内空气节点时间常数在0.5到2小时之间，围护结构大质量节点的时间常数在8到24小时之间。这两个时间常数决定了协同控制的"时间窗口"：你提前预冷一两个小时，是能真实转换成下午的削峰能力的；你打算提前两小时之外的那些控制动作，大部分能量都散到围护结构里去了，效果要打折扣。

这里必须多说一句：很多做仿真的人喜欢把模型建得很精细，几十个节点、上百个参数，结果现场根本辨识不了这么多参数，最后模型失真。实际项目里，两阶RC模型加上准确的太阳辐射和室内发热扰量，精度已经足够支撑小时级的协同调度。参数少，辨识才可靠。

2.3 可调节潜力与舒适度边界怎么划

有了热惯性的时间常数，就可以估算可调节潜力了。以夏季为例，一栋允许设定温度上下浮动2度的办公楼，预冷1.5小时的蓄冷量大约相当于把下午高峰负荷平移2到3小时的容量。这个量听着不大，但配合储能电池，足够把下午最贵的那段电价躲过去。

可调节潜力不是想调多少就调多少，边界条件全部来自人员舒适度。夏季办公空间常态设定温度按国标GB 50736控制在24到26度，这已经是设计底线；但协同控制在"过渡时段"可以更灵活地制定规则：有人时段尽量维持26度内，预冷阶段可以短暂把温度压到22到23度以保证预冷深度，但持续时间要有个上限，否则人员投诉会直接让系统被迫切回手动。无人时段（夜间、周末、节假日）的约束可以放宽到18到28度，这给了夜间利用低谷电预冷很大的操作空间。更重要的一点是，温度只是舒适度的一半，风速、辐射温度、湿度都在起作用。项目里我见过只盯干球温度的控制策略，结果湿度偏高，人照样觉得闷。协同控制的天花板不取决于算法，而取决于你对舒适度边界的定义是否周全。

3. 微电网侧设计：光伏储能不是拍脑袋定的

负荷侧摸清之后，才轮到微电网侧的容量配置。这里的顺序问题很重要：应该是先确定负荷的可调节能力，再反推光伏和储能需要配多大。顺序反了，配置出来的微电网大概率是"大马拉小车"或者"小马拉大车"。

3.1 光伏容量：先看屋顶和负荷匹配，再看电价

建筑屋顶光伏的容量主要受三方面约束：可用屋顶面积、结构荷载、并网接入容量。常见的办公建筑屋顶，扣除设备基础、机房、女儿墙遮挡之后，可用面积也就是总屋面的六到七成。按目前主流双面双玻组件每平米功率密度150到180瓦来算，一万平米的建筑实际能装的光伏大约在800千瓦到1.2兆瓦之间。很多项目在这一步就容易犯冒进：能装多少装多少，结果逆变器容量超过了配电变压器的反向潮流承受能力，并网审查根本过不去。

协同设计视角下，光伏容量的优选逻辑应该同时看两条曲线：光伏出力曲线和空调负荷曲线在时间上的相关性。如果目标是把高比例光伏电量就地消纳，光伏容量建议控制在"典型晴好天气中午出力不超过建筑此刻总负荷"这个范围附近。因为超出部分要么逆流，要么被电池吃掉再放出来，中间的变换损耗和电池循环损耗都是一种浪费。这些年我们做过的方案里，光伏容量大约在建筑峰值负荷的30%到60%之间，配合空调柔性调节，自消纳率可以做到85%以上；再往上加光伏，边际收益就明显下降。

3.2 储能配置：容量、功率和寿命的三角博弈

储能配置是整个微电网设计里最容易陷入争论的部分。业主想要尽量多配，觉得容量大了更"可靠"；电气工程师担心消防和接入审批；投资测算的人盯着全生命周期成本。实际算下来，建筑微电网的储能主要干三件事：平抑光伏短时波动、配合削峰填谷、离网状态下保障重要负荷。

功率等级怎么定？看你要平抑的波动幅度和底座负荷。一台2000千瓦的制冷站主机，启停时的功率阶跃可能高达一两百千瓦，储能功率至少得覆盖这个阶跃量的60%到80%，否则平滑效果不明显。容量等级怎么定？看你想撑几个小时。常规做法是配0.5C到1C的功率容量比，也就是1兆瓦的储能，容量选0.5到1兆瓦时，放电时长半小时到一小时，专门兜住午后光伏衰减到负荷落坡之间那段缺口。如果你想用它做更长时间的能量搬移，那要和建筑热惯性统筹算账：热惯性已经把下午的缺口削掉一大块，电池只需要补剩下的部分，容量能省不少。

寿命账也要算清楚。磷酸铁锂电池在80%放电深度下循环寿命大约6000次，按照每天一次深循环算，理论寿命16年以上，但实际运行中高温、大倍率充放都会加速衰减。控制策略里要做两件事保护电池：一是设定荷电状态运行区间，比如把日常运行限制在20%到90%之间，留出上下缓冲；二是对大倍率充放电次数做限制，把秒级和分钟级的功率波动尽量交给空调和逆变器去扛，电池只承担小时级的能量搬移。这个分工如果设计得好，电池的等效满充循环次数可以降下来一大截，全生命周期成本明显改善。

3.3 并离网策略与电能质量的兜底设计

建筑微电网绝大多数时间并网运行，但设计上必须把离网工况提前想清楚。离网状态下，空调这类大功率异步负荷的启动电流会带来很大的频率和电压冲击，而光伏出力又随时可能大幅变化，这时候储能必须承担起主电源的角色，冷机启动顺序必须做软启动和错峰。我们有一个项目因为没做冷机启动顺序控制，第一次离网试验直接把PCS顶到过流保护，整个园区短暂失电。后来加了冷机变频软启动和负荷分批投入逻辑，才把离网切换成功率提上来。

还有一个常被忽略的细节是电能质量。变频冷机、水泵、风机都是非线性负荷，谐波会反向注入微电网母线；光伏逆变器本身也会产生谐波。协同设计阶段就要把有源滤波器或者逆变器的谐波补偿功能纳入考虑，否则EMS看到的电压电流数据全是"脏"的，控制算法再聪明也会被带偏。

4. 控制策略设计：规则、预测控制与强化学习的取舍

微电网和暖通空调的协同，最终要落到控制策略上。这一节是整个项目技术含量最高的部分，也是我和电气专业同事争论最多的地方。

4.1 控制架构：四层结构各管什么

不管算法多高级，控制架构必须分层，否则现场根本跑不起来。我习惯把协同控制系统分成四层：

• 设备层：冷机、水泵、风机、变频器、PCS自身的控制回路，响应时间在秒级以内，只认本地信号。
• 区域层：各楼层、各分区的温度控制回路，调节水阀、风阀和风机盘管，保障局部舒适度。
• 系统层：制冷站的群控策略，决定开几台冷机、各台加载到多少、供回水温度设多少，响应时间在分钟级。
• 能量管理层：也就是EMS，做小时级和一刻钟级的调度，决定电池充放、光伏限功率、冷站目标功率设定值，同时下发需求响应信号。

协同控制的核心接口在系统层和能量管理层之间。能量管理层不应该直接去启停冷机，那样太激进，现场风险高；它应该下发的是"未来一小时冷站功率不要超过多少千瓦"或者"下午两点到四点的供冷目标温度上调1.5度"这类约束，由系统层的群控去把约束消化成具体的设备动作。这么设计的好处是，每一层只需要守住自己这一层的目标，出问题时有明确的责任边界，调试的时候也能逐层排查。

4.2 基于规则的控制与MPC的差距有多大

项目初期为了快速跑通，我们用的是典型的规则控制：光伏预测出力大于负荷预测时，把冷站供回水温度降0.5度并加大冷冻水流量，多蓄冷；电价进入高峰段时，电池放电，同时冷站功率限制到平时峰值的70%；傍晚室内温度回升到26度以上才允许恢复满负荷。这套规则在典型天气下效果不错，节费约8%到10%，但到了多变天气就露馅了：下午突然来一片云，光伏出力掉得比预测快，规则库里没有对应的触发条件，只能等温度超限后再补救，舒适度已经波动了。

这个时候就该MPC上场了。模型预测控制的思路不复杂：每15分钟滚动计算一次未来24小时的调度方案，综合考虑负荷预测、光伏预测、电价、电池状态和建筑热模型，找到一组控制动作使得"电费+舒适度惩罚"最小，然后只执行未来一小时的第一步，下一个周期重新滚动计算。MPC最核心的优势是它把"储能电池SoC""室内温度""围护结构蓄热状态"这些状态量放在同一个优化框架里统筹，天然就能解决不同响应速度资源的分工问题。

实测下来，在同样的建筑和微电网配置下，MPC比规则控制多节费5到8个百分点，舒适度超限时间反而更少，因为它在温度还没越界的时候就开始调整策略了。

4.3 MPC落地的关键：预测数据、目标函数和约束

MPC的大致目标函数可以写成：

• 目标：最小化未来N个时段的总电费，加上舒适度越限的惩罚项。
• 决策变量：冷站功率设定值、供回水温度设定值、电池充放电功率、光伏限功率比例。
• 等式约束：电网交换功率等于建筑其他负荷加空调功率减光伏出力加电池出力。
• 不等式约束：室内温度必须在舒适度上下限内、冷机功率必须在最小安全出力以上、电池SoC必须在运行区间内、冷机启停间隔必须满足最小停机时间。

看着复杂，落地时关键在于预测数据的质量。这里有个容易被低估的细节：预测不是越准越好，而是要"可信"。光伏预测用数值天气预报加卫星云图，15分钟滚动更新的版本，均方根误差能控制在15%以内；负荷预测用历史相似日加温度预报，误差控制在8%左右；电价直接按签订的合同电价曲线填入，这个最准。三个预测数据源都要留一个可配置的权重接口，因为每个项目的预测能力不一样。

优化求解我用过商业求解器和开源求解器各跑过一版。商业求解器在几百个变量的规模下端到端求解只要几百毫秒，完全够用；开源求解器在这个规模下也没问题，只是数值性能上偶尔要调 tolerance。这里提醒一句：不要为了显高端把优化周期缩短到分钟级以下，因为建筑负荷和光伏出力的变化本来是分钟级以上的，太快的滚动不仅计算浪费，还会让冷机频繁调整设定值，机械磨损和系统振荡都跟着来。

4.4 强化学习：看起来很美的选项

几乎所有业主和领导第一次听方案都会问：为什么不直接用人工智能？我理解这个期待，但作为实际干活的人，我得说清楚强化学习在真实建筑项目里的现实约束。

强化学习的优势在于它能从数据中学习到难以建模的非线性规律，不需要精确的RC模型。但它的劣势同样致命：训练需要大量试错，而在真实建筑上随便试错会给租户带来不可接受的热舒适波动；仿真环境里训练出来的策略与实际现场的差距，需要大量的在线微调；一旦策略发散或者陷入不好的状态，运维团队很难像调试规则控制一样快速定位问题。我目前见过跑通RL落地并且长期稳定运行的公共建筑项目，少之又少。

更务实的路线是"规则兜底+MPC优化"：天气和电价模式正常时，MPC全权负责；遇到MPC模型失准或者预测数据异常时，回退到规则控制保证基本功能；数据积累到一定程度，再用离线强化学习去改进MPC的目标函数权重。这种渐进路线工程风险小，团队也更容易建立信心。

5. 仿真先行：把协同策略放在数字孪生里"过一遍"

控制策略不能直接上真机，风险太大。我们的流程是仿真先行，真机验证在试运行期再逐步切换。

5.1 联合仿真平台的搭建方式

做建筑微电网协同仿真，常见路线是EnergyPlus或TRNSYS做建筑热过程，Simulink或Python做控制策略，再加上光伏、储能、PCS的电气模型，通过联合仿真接口串起来。EnergyPlus作为建筑能耗仿真的老牌引擎，逐时精度可以接受，缺点是非实时、步长固定；TRNSYS则对暖通系统部件建模更灵活，适合做冷站水系统。控制侧我们用了Python，把MPC的滚动优化包在Python里，通过接口和仿真引擎交换数据。为了把光伏出力和电价的变化动态纳入进来，还要在仿真环境里加入一个"外部环境"模块，按时间轴推进气象数据和电价信号。

这里有一个工程细节：联合仿真的时间同步。建筑仿真引擎一般以15分钟的步长推进，而控制策略需要在每个步长内完成优化求解，还要考虑计算耗时。我们在仿真里采用"仿真时间推进-控制决策-结果回灌"的三步循环，保证每一步的控制决策都是基于当时最新的状态，而不是拿上一时刻的旧数据。这个问题不做对，仿真结果会和实际行为差得很远。

5.2 典型场景测试怎么设计

仿真工况设计直接决定了你会不会在真机上翻车。我们至少跑四类场景：

• 晴好夏日：光伏出力饱满，负荷峰值高，重点检验"中午多蓄冷、下午削峰"的协同效果。
• 多云扰动日：光伏出力频繁波动，重点检验储能和空调的功率协调，以及MPC滚动更新的反应速度。
• 极端高温日：负荷接近设计峰值，舒适度约束吃紧，重点检验空调柔性和舒适度的底线在哪里。
• 需求响应事件日：电网下发削减命令，检验系统在多长时间内能把关口功率压到目标值以下。

每个场景都记录一组核心指标：光伏自消纳率、可再生能源渗透率、电费节省比例、峰值需量、舒适度达标时数占比、电池循环次数折算。四个场景跑下来，策略的优劣和风险点基本就清楚了。

5.3 仿真到现场部署的衔接问题

仿真里跑得很好的策略，到了现场大概率要打折扣，这是常态。三个最常见的落差来源：一是仿真用的气象数据是典型年数据，现场天气不会按典型年来；二是仿真模型没有考虑设备实际性能和衰减，比如冷机实际COP比铭牌低的可能不止10%；三是现场传感和控制回路的延迟比仿真模型大得多。

所以现场部署阶段，我们的策略是从"开环建议"开始：所有MPC给出的设定值先只是在操作画面上显示，由运行人员确认后再执行。跑两周数据，对比建议值和人工作出值的差异，确认没有大的逻辑漏洞，再切到"半自动"——自动执行但保留人工一键切回。最后才进全自动。这个渐进过程通常会花掉六到八周，但换来的是运维团队的信任，这笔账非常划算。

6. 我在实际项目里踩过的几个坑

最后分享一些具体的坑，都是真金白银买回来的教训，写出来希望后来者少走弯路。

6.1 时间尺度错配是最隐蔽的问题

EMS的调度周期通常是15分钟，而冷站群控的调节周期更短，5分钟左右就要对温度变化作出反应。如果EMS把设定值下发的频率和群控的执行频率没有对齐，会出现"群控还没来得及执行完，EMS又发来新指令"的情况，冷机设定值来回抖动，既费电又伤设备。解决的办法是在EMS和群控之间加一个"设定值变化率限幅"和"最小执行间隔"逻辑，EMS指令先进入缓冲队列，只有在群控确认当前指令执行完毕后才接收下一条。类似的错配还发生在电池和空调之间的功率分配上：电池响应以秒计，空调响应以分钟计，协调不好时电池会把空调还没来得及降下来的功率差全部扛下来，导致电池过放。需要把空调的"预期降载曲线"提前告诉EMS，让电池只补实际差量而不是预测差量。

6.2 通信协议和现场传感器的现实问题

暖通系统和微电网系统的通信协议天生不搭。冷站群控多走BACnet或Modbus，而光伏逆变器和PCS更习惯Modbus TCP或私有协议，电池系统往往还带一套自己的BMS通信。打通这些协议不是技术难题，但现场调试会占据大量时间。我们后来统一用一个边缘网关做协议转换，边缘网关向上用MQTT把数据发到EMS，向下分别对接BACnet、Modbus和私有协议。这个架构改动不大，但把协议问题和业务逻辑彻底解耦了，调试效率提升明显。

传感器的问题更现实。某个项目装了一堆高精度温湿度传感器，结果调试时发现制冷站供回水温度测点有两处安装位置离得太近，读数几乎一样，等于没有测点。花了一个星期重新安排安装位置。另一个项目装了新的电表，但电能质量分析仪校准没做，谐波数据含糊其辞，把EMS的功率数据污染了一周。我的经验是：正式投运前，对每一个参与协同控制的测点做一次完整的量程校准和回路核查，宁可多花三天，也不要带着脏数据上线。

6.3 运维人员的人机接口设计

这件事直接决定了项目能不能长期活着。我们遇到过最典型的失败案例：运维师傅发现控制策略在某个雨天触发了冷站功率限制，室内温度升到了27度，他没有去查控制逻辑，而是直接把EMS里的自动模式切到手动，从此再也没切回来。协同控制再先进，只要运维人员不信任，它就是废纸一张。

所以人机接口的设计要和控制算法本身同等重视。操作界面上至少要讲清楚三件事：当前系统处于什么模式、系统下一步打算干什么、运维人员可以怎么安全地干预。每次策略切换和设定值调整都要留痕，并且要有明确的"一键回退到本地手动"按钮。我后来养成了一个习惯：项目交付时，花半天时间专门给运维团队讲"当你不理解系统在做什么时，它大概率是正常的，请先查日志再决定要不要接管"。这句话看起来简单，实际上救过我好几次项目。

6.4 团队协作的语言问题

暖通工程师和微电网工程师，工作语言差异很大。暖通的人关心的是冷量、温度、COP、压差；微电网的人关心的是功率、电量、SoC、PCS。协同设计一开始，我们开过几次会，双方各说各话，互相觉得对方不专业。后来定了一个规矩：所有协同接口都用"功率"和"时间"来表述。比如"冷站下午两点到四点的功率上限是450kW"，而不是"下午降低供水温度0.5度"；"电池在下午两点前保持90%电量"，而不是"电池多充一点"。这个表述约定推行之后，双方沟通效率明显提升，错误理解大幅减少。我建议所有做这类项目的团队都尽早定下这个协作规范。

协同设计这条路，方向是对的，但每一步都需要暖通、电气、自控、软件几个专业的人真正坐在一起把边界条件摊开来讲清楚。建筑热惯性不是万能的，电池也不是万能的，它们配合起来能做的事情比任何单一系统都多。按前面这套方法一步步走，踩过的坑可以少踩一大半。