企业官网建设流程全解析

做新能源整车控制这几年，最常被新同事问的一个问题是：Simulink模型到底该建多细。建粗了感觉没啥技术含量，建细了仿真跑一天都不收敛，最后还得靠实车去补窟窿。我的答案一直很朴素：模型不是越细越好，而是该细的细、该粗的粗，建模的投入要跟着项目阶段和验证目标走。今天这篇东西，就是想把这件事展开聊透。

Matlab/Simulink在新能源车研发里早就不只是画框图用的工具。从动力电池SOC估算、整车能量管理策略开发，到控制策略自动生成C代码刷进VCU，它贯穿了“需求-设计-实现-测试”的完整链条。你可以把它理解成汽车行业的虚拟试车场加代码工厂：实车还没出来，控制逻辑已经在电脑上跑了几万公里；台架还没搭好，故障策略已经在模型里被虐了无数遍。

这篇内容适合正在学模型、准备入行新能源控制的学生，也适合刚转岗过来的软件和算法工程师，哪怕你已经搭了两三年模型但一直是凭感觉堆模块，下面这些关于选型、参数、验证和排查的思路，也能直接落地用起来。

1. 新能源汽车研发为什么绕不开 Matlab/Simulink 建模

1.1 系统级模型的价值与合理边界：该细的细，该粗的粗

传统开发流程里，控制策略要等整车和零部件样件出来才能验证，改一处逻辑可能就要重新刷件、重新测车，一个冬季标定周期就过去了。新能源车引入了电池、电机、电控三大件之后，系统之间的耦合比以前内燃机车复杂得多，电池SOC会影响扭矩限制，电机效率又会影响能量管理策略的阈值，任何一个环节改参数，上下游都会受影响。这种情况下靠实车来回迭代，成本和时间都扛不住。

Simulink建模的核心价值，是把“车”变成可以随时暂停、回放、注入故障的数学模型。你可以在同一套模型里跑WLTC、CLTC、NEDC，也可以自己定义一个爬坡工况，看看电机过载能力够不够；可以在电池模型里人为加入一节电芯的内阻偏离，验证均衡策略能不能兜住底。这些测试在实车上做一次可能要几万块，在模型里只是改一个参数的事。

从团队协作角度看，系统级模型还提供了一种共同语言。搞电池的、搞电机的、搞整车的、搞软件的各看各的文档，经常对不上；但只要大家都往同一个Simulink模型里灌输入、看输出，问题立刻暴露。所以我的建议是，哪怕还在预研阶段，也要先把整车纵向动力学的骨架搭起来，哪怕精度不高，也比没有强。模型边界就一句话：你要回答什么问题，决定了模型要细到什么程度。

1.2 基于模型设计（MBD）：让模型成为唯一事实来源

基于模型设计是Simulink在汽车行业最核心的方法论，英文叫Model-Based Design，简称MBD。它和传统写C代码思路最大的区别在于：可执行规范是模型本身，而不是几十页的Word文档。需求被拆解成模型里的模块和状态机，仿真是对规范的验证，生成代码是对规范的实现，文档甚至可以从模型自动生成。这样需求、设计、实现、测试就变成了一条链条，而不是四份对不上的文件。

在新能源项目里，MBD的好处特别明显。比如整车控制器VCU的高压上下电逻辑，用Stateflow状态机画出来，评审的时候大家盯着迁移条件讨论，一眼就能看到哪个状态的迁移条件重叠了，哪个状态没有超时保护。如果这段逻辑用C代码写，光评审if-else嵌套就要花半天，还不一定看得透。V字模型是这一套方法的标准参照：左边是需求分析、系统设计、模型验证，右边是集成测试、标定验证，Simulink模型就是整个V字的中轴线。

MBD还顺带解决了“测试前置”的问题。模型建完，先做模型在环测试，验证逻辑对不对；再通过自动代码生成得到C代码，把C代码在PC上做软件在环测试；最后才上硬件在环或者实车。层级越靠前，修bug的成本越低，这是整个行业公认的规律。实际项目里，MBD流程推进最难的不是工具，而是团队愿不愿意把模型当作“唯一事实来源”，很多东西一旦要求以模型为准，后续的变更管理、版本管理都得跟上。

1.3 工具箱选型思路：Powertrain Blockset 还是从零搭

很多新手一上来就纠结要不要用Powertrain Blockset、Simscape Electrical这些官方工具箱，担心自己搭的模型不专业。我的看法是，工具箱和手写模型没有高下之分，只有阶段之分。早期方案探索阶段，我甚至建议你用简单的数学模块先把物理关系理清楚，比如电池先用理想电压源串电阻，电机先用力矩查表，等框架稳定了再往里面换成高保真模型。

如果项目预算充足、又要做和热管理、电磁兼容相关的仿真，Simscape Electrical里的电池模组、电机模型精度确实高，但代价是仿真步长会被压得很小，计算量成倍增长。就拿我自己的经历来说，用Powertrain Blockset跑一次两小时工况，仿真时间比用简化模型慢五六倍不止。如果你的目标是验证能量管理策略，这个精度换来的收益很低。

所以我的工具箱选型原则是：策略验证用简化模型加查表，部件级详细性能分析再用物理模型工具箱。把V字模型左边“模型在环测试”和“软件在环测试”的模型分开管理，一套是控制策略模型，一套是被控对象模型，两者通过总线信号交互。这样做的好处是控制模型可以一直保持轻量，有利于后续代码生成。S-Function、MATLAB Function可以嵌进模型，但别把它们当成常规手段用，不然代码生成阶段会头疼。

2. 三电模型的搭建细节：电池、电机、整车动力学

2.1 动力电池模型与SOC估算：一阶RC模型为什么够用

动力电池建模是新能源仿真里最讲究的一块。电池是强非线性、强时变系统，温度、电流倍率、老化都会改变它的外特性，想把每个细节都建模出来不现实。工程上最常用的是等效电路模型，也就是把电池看成一个电压源串联若干RC网络。Rint模型最简单，一个内阻搞定；一阶RC增加一个极化环节，能比较好地表征电池的动态响应；二阶RC精度更高，但参数辨识和仿真开销也跟着涨。

以我做BMS算法时的经验，做SOC估算的话，一阶RC模型通常是性价比最高的选择。开路电压和SOC的关系曲线要单独标定，这个过程叫OCV-SOC标定，一般用很小的电流充放电，让电池近似处于平衡状态，记录电压与容量的对应关系。有了OCV-SOC曲线，加上实时电流，就可以用安时积分法估算SOC，同时用开路电压法做周期校正，避免积分漂移。一阶RC里的极化电阻和极化电容，一般用HPPC脉冲实验数据离线辨识，最小二乘拟合一下就有了。

如果要进一步提升精度，可以用卡尔曼滤波把模型预测和电压测量融合起来。卡尔曼滤波的工程细节比较磨人，光噪声协方差矩阵Q和R就得调很久。我的调参习惯是先用静态工况把R定下来，再在动态工况里看SOC估计的收敛速度，如果震荡就增大Q，如果响应太慢就减小Q。这个经验不是教科书写的，但实测非常管用。温度对电池内阻和容量影响很大，所以正式模型里至少还得加一张温度修正表，否则冬季仿真结果会严重失真。

2.2 永磁同步电机FOC模型：效率Map加惯性环节更实用

驱动电机现在主流是永磁同步电机，控制上基本都走磁场定向控制，也就是FOC。Simulink里建电机模型，可以走两条路：一条是用Simscape Electrical里的物理模型，画一个永磁同步电机图标，直接接逆变器和直流母线；另一条是用数学方程自己搭dq轴模型。做系统级能量管理策略验证时，我通常不关心电机内部的电磁细节，只要外特性准确就行。

最实用的做法是用效率Map图加一阶惯性环节代替电机的机电响应。转速和扭矩请求进入查表模块，输出电机效率、实际扭矩和母线电流，再加一个时间常数模拟扭矩响应延迟。效率Map一般来自电机台架测试，横轴是转速，纵轴是扭矩，里面的值是效率，Simulink里直接用Lookup Table(n-D)二维查表模块读取。这套模型虽然没有绕组电流、反电动势这些内部量，但对整车控制策略验证来说，扭矩响应够快、损耗够准，已经足够了，很多车厂的能量管理策略模型就是这么干的。

如果你要研究电机的弱磁控制、电流环PI整定，那就需要回到dq坐标系的详细模型。Clark变换、Park变换、SVPWM、电流PI环，一层层搭下来，跑一个工况能观察到转速波动和电流纹波。这类模型适合电机控制器开发团队，不适合整车能量管理。所以搭电机模型之前，先问自己一句：我要回答什么问题？答案决定模型边界。母线电压波动对电机外特性影响很大，做整车级仿真时最好在直流侧串一个简单的电池等效内阻，否则电机请求功率和电池输出功率会经常对不上。

2.3 整车纵向动力学与驾驶员模型：PID跟踪质量别忽视

整车模型是连接控制策略和外部工况的桥梁。纵向动力学模型的核心是行驶方程：驱动力减去滚动阻力、空气阻力、坡度阻力，再扣除加速阻力，得到车辆加速度。Simulink里通常用积分模块把加速度积分成车速，再用车速反馈计算阻力，形成闭环。这里有一个新手特别容易犯的错：直接用Constant模块给整车一个固定阻力，导致仿真结果在工况切换点极其生硬。

驾驶员模型是另一个容易被忽略的模块。它的作用是跟踪目标车速曲线，输出加速踏板和制动踏板开度，一般就是一个带限幅的PID控制器。PID参数如果整定不好，会出现车速跟踪不上或者踏板反复震荡的现象。我常用的做法是先调P，再调I，最后加D，目标是在CLTC工况下速度误差稳定在2km/h以内，同时踏板变化率不要过于频繁。整备质量、风阻系数、滚阻系数、轮胎半径这些基本参数，别在模型里硬编码，统一放数据字典或工作区间，标定起来方便得多。

把电池、电机、整车动力学和驾驶员模型串起来，就是一套最简可用的整车纵向性能模型。在这个基础上，你可以加制动能量回收策略，可以在驾驶员模型输出端加驾驶风格参数，比如激进驾驶对应更大的踏板增益。模型边界清楚之后，后续加电池热管理、悬架横向动力学都只是扩展，不会推翻重来。做行驶工况仿真时，我习惯先把路面坡度和风速这两个输入做成可配置的Inport，方便后面对接真实路谱数据。

3. 控制策略仿真验证：VCU、能量管理与 MiL/SiL/HiL

3.1 VCU状态机与扭矩管理：迁移条件和限扭优先级

整车控制器VCU是新能源车的“大脑”，它的逻辑天然适合用Stateflow状态机建模。高压上电、待机、行车、充电、下电、故障下电这些状态，每个状态都有进入条件、执行动作和迁出条件。用Stateflow画出来之后，评审时最直观，大家盯着的不是代码变量名，而是状态之间的迁移条件。上电时序在模型里表现成状态迁移的先后顺序，比如先闭合主正继电器，再预充，最后闭合主负继电器，顺序错一个步骤，高压系统就可能出问题。

实际建模时，有个细节很容易被忽略：状态机的迁移条件要覆盖所有组合，否则会出现“锁死状态”。比如行车状态下，如果驾驶员同时请求下电并且整车出现严重故障，这两条迁移路径的优先级必须提前定义好。我的习惯是在Stateflow里显式加入一个“安全状态”，任何未定义但可能发生的迁移，最终都导向安全状态，宁可多写一个分支，也不要让状态机悬空。

扭矩管理是VCU的另一个核心任务，本质是根据加速踏板开度、车速、电池最大允许放电功率，计算出电机扭矩请求。这里面有很多限制环节：电池SOC低时要逐步限扭，电机过温时要降额，车速过高时要限制最高车速。这些限制逻辑用查表和Min模块堆起来很方便，但要注意把优先级理清楚。我的做法是每个限制条件单独算一个扭矩上限，最后取最小值，并保留一个诊断信号，标定工程师看到诊断信号就能知道当前是被哪条限制限住了。

3.2 能量管理策略规则与阈值标定：迟滞带怎么调才不抖

对有发动机的插电混动车型，能量管理策略直接决定油耗和电耗。工程上最常见的还是基于规则的能量管理，也就是把工作模式分成纯电、串联、并联、直驱等，用SOC阈值和车速、功率需求来判断当前该用哪个模式。Simulink里实现起来就是一个大Stateflow加一堆查表模块，难的不是建模，而是阈值的标定。电量充足时优先纯电，SOC降到阈值后进入混动模式，发动机工作点尽量落在高效区间，这个逻辑本身不复杂。

标定这些阈值有个通用思路：先定义边界工况，再在这些工况下反复仿真，观察SOC轨迹、发动机工作点分布和油耗变化。比如电量维持阶段的SOC下限是20%，那就跑一个从100%电量开始的WLTC循环，看SOC下降到20%的时候策略会不会频繁启停发动机。启停次数太多，就要调大滞后区间，避免系统在阈值附近来回切换。工程上叫“迟滞带”，没有迟滞带的话，系统会抖得让人崩溃。

近几年深度学习、强化学习也开始进入能量管理研究领域，Simulink可以和Python协同，用强化学习智能体在线调整能量分配策略。但我的建议是，量产项目还是保守一点，规则策略加查表最稳妥，强化学习适合论文和预研。毕竟功能安全认证面前，一个“黑盒”策略很难解释清楚它为什么突然切到发动机模式。标定阈值时还有一个坑：不要只用一个工况调参，CLTC调出来的阈值上到WLTC可能完全不是一回事，多工况交叉验证才能让阈值有泛化性。

3.3 MiL/SiL/HiL分级验证：用Simulink Test搭自动化回归

Simulink里的模型验证是按层级爬的。MiL就是模型在环，控制策略模型和被控对象模型都在同一台电脑里跑，验证的是逻辑正确性；SiL是软件在环，把控制策略自动生成的代码放到PC上跑，验证的是代码和模型是否一致；HiL是硬件在环，被控对象模型跑在实时机上，代码跑在真实控制器里，验证的是控制器硬件和底层软件的运行效果。

每往下一层，就更接近实车，但成本也更高。MiL阶段一天能跑几百个工况，HiL阶段一个工况跑下来还要处理信号调理和IO映射。所以项目里我通常会规划一个“测试矩阵”：常规工况在MiL跑自动化回归，故障注入和边界工况在HiL跑，实车只做少数最终确认。这样既保证了覆盖率，又没有让测试成本失控。

Simulink Test是支撑这套流程的重要工具箱，它可以创建测试用例、建立测试基准、自动对比仿真结果和期望值，最后生成HTML测试报告。我在这上面吃过亏，早期用Excel管理测试用例，模型一更新根本不知道哪些用例要重新跑。后来把所有用例迁到Simulink Test里，配合模型引用，每次改动后跑全回归，半小时出结果，问题定位效率高了好几倍。自动化回归的关键不是工具，而是用例质量的积累，宁可少而精，不要多而滥。

4. 联合仿真与代码生成：从模型走向实车

4.1 Carsim/ADAMS联合仿真：步长与单位是两座大山

整车动力学的精细仿真往往需要联合仿真。Carsim在车辆纵向和横向动力学、操纵稳定性这块用得非常多，ADAMS则偏好多体动力学。联合仿真最常见的问题不是模型本身，而是接口设置不一致导致仿真失败或者数据错乱。Carsim会把整车状态输出给Simulink，Simulink把电机驱动扭矩、制动压力返回给Carsim，接口建好后要特别注意仿真步长的匹配。Carsim的传输周期通常设成1毫秒或5毫秒，Simulink侧建议用定步长求解器，步长和传输周期保持一致，或者设置成整数倍关系，否则容易出现数据插值错位。

还有一个坑是单位。Carsim默认用Kmph表示车速、Nm表示扭矩，但Simulink模型里经常要用m/s、rad/s，接口处不要忘了换算。我在一个项目里就遇到过，Carsim输出的车速直接接到整车阻力计算模块，结果阻力比实际大了3.6倍，仿真出来的能耗曲线完全没法看。联合仿真模型跑得极慢怎么办？先别急着加内存，看看是不是有大量高频状态输出进了Simulink，降低输出频率往往立竿见影。

ADAMS联合仿真一般通过联合仿真接口S-Function实现，同样要注意求解器选择。ADAMS那边如果使用变步长求解器，和Simulink的定步长匹配起来会非常腻，我的经验是两边都固定步长，才能在长时间工况仿真里稳定跑下来。联合仿真适合做操纵稳定性、平顺性这类动力学问题，如果只是做能量管理，完全没必要上这么重的工具，Simulink自带纵向模型就够了。

4.2 Embedded Coder代码生成：定步长离散是硬约束

模型最终要变成能刷进控制器的C代码，这一步主要靠Embedded Coder。代码生成之前，有一堆配置要做：求解器必须是定步长离散，模型里不能有连续积分器，输入输出要定义成Inport/Outport，存储类型要指定成标定用的实参或者常量。把模型当成“画电路图”来搭是没问题的，但生成代码时它对模型元素极其挑剔，任何隐含连续状态都会在代码里变成累赘。

代码生成里面最核心的概念是“任务与速率”。Simulink模型里不同模块可以有不同的采样时间，代码生成后对应不同周期的任务。比如电机扭矩控制在1毫秒任务里执行，能量管理策略在10毫秒任务里执行。配置任务周期时，要保证快速任务里读取的信号不会被慢速任务覆盖，否则会产生数据一致性问题。现在AUTOSAR大量应用，Embedded Coder也能直接生成AUTOSAR软件组件，端口对应运行实体，底层NvM读写、Dcm诊断服务都能通过配置映射到RTE。

我对新人的建议是，代码生成前的模型规范检查必须做。MathWorks官方有Model Advisor，能自动检查模型是否符合MAAB等规范，比如Goto/From标签是否配对、数据字典是否存在未定义对象。这些检查项看起来繁琐，但能省掉你在台架上排查一个偶发bug的三天时间。代码生成这一步，很多人只关心能不能编译通过，其实更该关心代码的可读性、可标定性、内存占用和执行效率，这些是要靠长期实践才能积累起来的感觉。

4.3 模型引用、外部模式与在线调试：工程协作提速

模型工程一大之后，所有人都在同一个文件里改，合并冲突会让人崩溃。解决办法是用Model Reference，把整车模型按功能拆成电池、电机、VCU等独立模型，上层通过模型引用模块组装。模型引用不仅支持增量编译，还能单独对子模型做测试，团队协作效率提升非常明显。做模型引用时，接口定义一定要稳定，不能今天加一个信号明天改一个端口，否则下游所有引用模型全要跟着改。

外部模式是Simulink连接实物和模型的利器。将生成的控制模型下载到控制器后，通过外部模式可以在线观测信号、实时调参，不用停下来重新刷写。做电机台架测试时，我经常用外部模式在线调PI参数，一边示波器看电流波形一边微调，效果非常直观。需要注意外部模式对通信实时性有要求，通常走CAN或串口，如果数据量太大，建议只订阅自己关心的几个信号，不要全量上传。

Simulink Test配合模型引用，还能做自动化测试流水线。团队约定：主模型更新后，CI服务器自动跑一遍全部测试用例，失败就把截图和仿真日志发给负责人。这种流程一旦跑起来，模型质量会稳定很多，也避免了很多“我觉得没影响核心逻辑”的主观判断。模型引用、外部模式、自动化测试这三件事，是我认为从“一个人搭模型”进化到“一个团队开发模型”必须迈过门槛。

5. 建模踩坑实录：乱码、发散、慢仿真与团队协同

5.1 MATLAB 2023 中文注释乱码：编码统一怎么做

很多同事升级到较新版本之后发现，老模型里的中文注释变成了一堆乱码，这个问题不是模型坏了，而是字符编码不一致。MATLAB历史上默认字符集改过多次，2023版本默认对UTF-8的支持更好，老版本模型保存时的编码可能不是UTF-8。出现乱码的时候，千万不要直接在模型里手工重新打字，那只是治标不治本。

解决思路通常有两种：一种是在MATLAB里统一设置默认字符集，利用feature('DefaultCharacterSet','UTF-8')切换，再用slCharacterEncoding('UTF-8')设置Simulink模型编码，然后重新打开保存模型；另一种是直接写一个脚本，批量遍历目录下所有模型文件，统一转换并另存为UTF-8。

% 统一 Simulink 模型编码 feature('DefaultCharacterSet', 'UTF-8'); slCharacterEncoding('UTF-8'); % 找到自己的模型后保存 save_system('your_model_name');

这里要特别提醒，转换编码前一定要先备份，因为如果老模型里有GBK编码写死的中文，强行转成UTF-8再保存，一旦操作失误恢复起来很麻烦。做过一次全团队字符集统一工作后你会发现，真正的坑不是转换本身，而是团队并行开发时有人用旧版本保存了旧编码，又把模型提交到了共享仓库。所以规范很关键：统一MATLAB大版本、统一编码策略、提交前先跑一遍模型完整性检查。

5.2 代数环、初始条件与仿真发散：三板斧排查

代数环是Simulink新手最常遇到的问题。当信号路径里没有存储模块，某个模块的输出直接依赖自己的输入，就会形成代数环，仿真的每一步都要迭代求解，不仅慢，还可能发散。最常见的是某个公式里同时用到了同一个信号的比例和微分量。解决办法很直接：在环路上插入一个Memory模块或者Unit Delay模块，打破直接依赖，虽然会引入一小步延迟，但对离散控制器来说通常可以接受。

仿真发散是我跑动力总成模型时遇到过好几次的问题。表象是某个信号在某一步突然变成NaN或者Inf。这种问题的排查思路，第一步先降低步长，看看是不是步长太大导致数值不稳定；第二步检查是否存在分母可能为零的表达式，比如车速为零时计算滑移率；第三步检查查表模块的输入是否超出了表头的范围，越界后又没有设置饱和处理。

如果模型里用了连续积分模块，求解器建议用ode45这类变步长求解器，但做控制策略时更推荐定步长离散求解器，因为更贴近代码生成后的运行环境。上面这些排查思路看起来基础，但实际项目里80%的发散问题都出在这几个点上，而不是什么高深的数值理论。

5.3 仿真越跑越慢：分级采样与快速加速模式

模型刚建好时跑得飞快，越到后面越慢，甚至一个循环要跑半小时，这是很多项目后期会遇到的状况。我总结下来，慢的根源通常有这么几类：一是模型里混入了高保真物理模型件，Simscape单元触发的小步长求解拖垮全局；二是大量使用连续积分和高频采样模块，即使系统不需要那么高的采样率；三是输出到工作空间的数据量太大，每个仿真步都在记录成百上千个信号。

提速方案也对应着来。最有效的一招是分级采样，整车动力学用10毫秒，电池热特性用100毫秒，把不需要高频采样的环节降下来，仿真速度能提升数倍。第二招是把连续积分器换成离散积分器，并选择合适的采样时间，贴近代码生成的离散环境。第三招是用信号记录组，只保存需要分析的信号，不要全选整个子系统输出。

还有一个容易被忽略的提速技巧：用加速模式或者快速加速模式运行模型。Simulink的快速加速模式会生成C代码后再仿真，模型复杂时速度提升非常明显。如果模型已经拆好了Model Reference，还能利用多核并行跑多个测试用例，库函数和参考模型缓存都能复用。修改标定参数需要反复调试时，用快速重启模式能省掉每次重新初始化模型的时间，批量扫参数特别划算。

5.4 模型整理与团队协同：命名、封装、版本管理

模型搭建完成只是第一步，能不能让别的工程师在半年后读得懂，才是衡量建模水平的关键。模块命名、信号命名、子系统封装、注释说明，这些都是日常功夫。我见过太多端口叫in1、信号叫sig2的模型，理论水平再高也没人敢接手。建议团队建立一套简单的命名规范，比如信号名统一用“Segment_Feature_Unit”的格式，传感器信号叫Batt_SOC_Pct，控制请求叫Mot_TorqReq_Nm，一看就知道含义。

子系统封装也很重要。每个功能子系统都要用Subsystem封装，配合文档和说明字段，还可以用注释框把设计背景、作者、修改日期写清楚。模型评审时，评审人第一眼看不懂搭建思路，后面很难给出建设性意见。另外，版本管理一定要用Git或SVN，并且配合Simulink模型比较工具，才能精确知道每次改动到底动了哪些模块。很多人觉得模型比较工具没啥用，真到了联调出问题、要找两个版本差异的时候，才知道它多值钱。

模型整理这件事，短期看是“浪费时间”，长期看是“省命”。我见过太多人宁可在自己脑子里维护模型地图，也不愿意花半小时把命名和注释补全，结果人一走，整套模型直接变成遗产。把模型当成一个需要持续维护的公共产品，而不是自己电脑上的私家代码，这才是团队级建模该有的态度。

最后再分享一个我一直在用的技巧：每次模型发版前，把Simulink模型的显示样式统一一下。把关键信号线加粗、用颜色区分不同子系统，甚至把多个工程师负责的区域用大色块分区。这个做法对评审和交接的帮助，比想象中大得多。很多人不舍得在这上面花时间，结果总在“这个模块是谁改的、为什么改成这样”的问题上反复浪费时间。模型即代码，也即文档，更是一个团队的公共产品。