简介这套107页PPT围绕数字化转型中的企业架构设计展开面向企业架构师、IT规划人员及数字化转型项目管理者重点解决企业战略难以有效传导至IT建设、各领域架构割裂等问题。PPT从企业架构现状分析入手展示如何盘点业务域、数据域、应用域与技术平台并借助TOGAF与DDD融合的CSG-EAF 2.0总体框架依次梳理内容框架、设计方法和落地原则。资源为单个PPTX演示文稿大小约6.34MB共107页目录由现状分析、内容框架、设计方法及附件四大部分构成适合投影讲解、自学研读或作为内部培训底稿。预览中清晰呈现业务、数据、应用、技术四类架构的分层模型以及价值流贯通、数据同源、分层解耦、全面云化、安全遵从等设计原则同时给出架构制品清单、扩展元模型等交付物说明便于读者对照自身组织完成架构差距分析与蓝图规划降低设计走弯路风险。目前已有53人学习下载对正在启动数字化转型规划或梳理企业级架构体系的团队有较高参考价值。 前几天帮一家制造企业评审数字化转型项目对方把供应商做的一份企业架构规划书甩在桌上107页PPT框架齐全方法论引用了TOGAF和国内各种标准业务架构、数据架构、应用架构、技术架构四层齐整甚至还有现状诊断和演进路线图。可翻到后面我越看越觉得不对劲整份方案里几乎没有出现任何一个具体业务场景的真实数据流没有一条可被追踪的指标口径数据架构页面的核心就是一张把ERP、MES、CRM、OA连起来的拓扑图。我顺口问了一句“这份架构方案对应的第一笔IT投资应该投在哪个系统上投完之后哪个业务指标会变”全场安静了。这不是个例。我做企业架构咨询这些年见过太多类似的“PPT式架构”——交付物做得极其隆重却经不起一句“然后呢”的追问。企业数字化转型确实绕不开企业架构设计这个环节但很多人对它的理解跑偏了以为企业架构就是画图、写文档、摆框架是IT部门内部的自嗨产物。真正的企业架构设计本质是回答“钱往哪投、系统怎么建、数据怎么管、流程怎么走”的一套决策机制。这篇文章我想把这件事彻底讲透数字化转型语境下的企业架构到底在解决什么问题四层架构怎么拆解怎样从0到1搭建一套能落地的架构以及——最重要的一点——如何让架构方案活下来而不是被锁进抽屉里。如果你正负责或参与公司数字化转型的整体规划是做信息化部门的技术骨干或者是准备向架构方向成长的从业者这篇文章可以直接拿来当思路参考。1. 先拆掉认知壁垒企业架构不是画图而是做决策1.1 那些“画完就过期”的架构方案病根在哪里一份107页的PPT方案看起来什么都有了为什么落地的时候依然不知道怎么动手我后来复盘过大量这类案例病根其实高度一致架构师把“描述现状”当成了“设计目标”把“画出关系”当成了“做出决策”。企业架构领域有个典型现象——交付物文档的厚度与落地效果成反比。页面越多、图画得越漂亮往往意味着抽象层数越多离实际业务和系统越远。架构的本质是取舍与决策哪些业务能力要自建哪些要采购哪些系统要整合哪些系统要淘汰数据在什么时候什么系统产生、归谁管、谁可以用。你不给出这些可执行、可校验的决策画再多的图都是无效功。我见过最荒诞的一个案例一家零售企业的架构方案里把未来要建的会员中台画得无比完善却没有回答最关键的问题现有四套互相不互通的会员系统是并行存续到什么时候新中台和旧系统之间是切换关系还是并行关系这个问题没定开发团队根本无法开工。架构方案可以不完美但决策必须明确这是架构设计跟学术画图的本质区别。1.2 架构的本质把业务战略翻译成IT投资的语言要理解企业架构在数字化转型里的定位可以打一个生活化的比方。一家公司相当于一座城市。业务战略是城市的总体规划确定发展方向、产业定位和人口规模企业架构相当于城市的市政工程设计图——路网怎么布、水电气管网从哪里走、学校医院商场怎么配比。没有市政设计图总体规划就只能停留在愿景层面城市要建设时施工单位不知道该在什么地方铺设什么管道、预留什么接口。企业架构也是同样的逻辑。它处在“业务战略”和“IT建设”之间的翻译层把老板说的“我们要实现全渠道会员运营”“我们要把供应链响应速度提升30%”“我们要降本增效”翻译成“需要建几套系统、系统之间怎么交互、数据怎么流转、基础设施怎么支撑”。没有这个翻译层业务战略就是墙上标语技术团队只能各自为战今天这里建一个系统明天那里买一套软件最后数据孤岛越来越多跟数字化转型的目标背道而驰。1.3 转型期的企业架构和传统信息化的架构根本区别在哪传统信息化时代做架构核心是“流程复制”——把线下手工流程搬进计算机里把流程固化进ERP、OA这类套装软件。架构师做的事情相对确定选哪家供应商、配哪些模块、做哪些二次开发。但数字化转型时代企业架构设计的语境发生了三个重要变化。第一驱动逻辑变了。传统架构是流程驱动流程怎么走系统就怎么建数字化的架构由数据驱动因为业务模式不再是一条固定的流程线而是围绕用户、商品、订单、设备这些数据实体展开的动态网络。同一个用户的触点在门店、电商、小程序之间切换你不能再用一条静态流程去描述全部业务而是要把用户ID、订单状态、权益信息这些数据如何在系统间流动弄清楚。第二系统形态变了。过去一套ERP吃遍天现在技术架构是“套装软件自研系统外部SaaS数据平台”的混合体异构程度非常高。架构设计必须回答混搭系统之间的接口标准、数据同步机制、一致性保障方案——这比单纯选型复杂得多。第三交付节奏变了。传统ERP项目交付以年为单位数字化产品和能力的迭代交付以周为单位。架构方案如果再保持“三年规划、五年实施”那种静态节奏方案刚发布业务模式就变了架构自然变成废纸。这几个变化的共同指向是数字化转型需要的不是一份大部头的架构文档而是一套能持续运转、不断演进的架构治理机制。2. 四层架构的拆解逻辑别让每个概念都停留在名词层面聊企业架构都绕不开业务架构、数据架构、应用架构、技术架构这四层。但同样是这四层概念有人能拿来诊断问题、指导投资决策有人只能拿来凑PPT页数。区别在于你是否真正搞清楚了每一层在回答什么问题、产出什么东西、由谁负责。2.1 业务架构不是组织结构图而是业务能力地图很多人把业务架构等同于画组织架构图——市场部、销售部、财务部、生产部每个部门下面挂上职能和流程。说实话这种图对信息技术没有多大指导价值因为你无法从“哪个部门做什么事”推导出“系统应该建什么”。业务架构真正要画的是一张业务能力地图。所谓业务能力不是部门职责而是企业“具备的做事能力”比如“会员全生命周期管理能力”“订单履约能力”“供应商协同能力”“设备预测性维护能力”。这些能力可能横跨多个部门每个能力都可以评估成熟度水准都可以对应到具体的信息系统支撑需求。我看过一家制造企业的业务架构设计做得比较到位。他们没有按部门画而是把整个企业业务拆成了产品研发、采购供应、生产制造、营销销售、售后服务、职能支撑六大能力域每个能力域再往下分解成若干能力项每个能力项都标注了当前成熟度水平和目标水平。这样一来IT侧的立项优先级就有了客观依据成熟度最低但业务价值最高的能力就是第一笔钱该投的地方。做业务架构之前你要做好心理准备这项工作一定会触碰部门边界和利益。因为能力地图画完之后谁强谁弱、谁重复建设、谁的流程效率低下都会被摆到桌面上。这部分推进的难度通常不在于技术而在于协调。2.2 数据架构最容易膨胀、也最先暴雷的部分数据架构是三句话能讲清楚、三个小时能讲糊涂的典型领域。往大了说数据架构包含数据模型、数据分布、数据流转、数据标准、数据质量、数据安全……什么都往里装。但落到数字化转型实操我认为核心只有三件事数据资产盘点、数据流向梳理、数据责任归属。数据资产盘点的关键是识别企业关键的“业务对象”——客户、产品、订单、物料、设备、供应商、员工——这些对象的数据散落在哪些系统里每个系统存储的是哪个数据子集口径是否一致。举个最常见的例子客户。很多企业根本没有唯一客户ID的概念CRM里一套客户档案ERP里一套应收账款信息营销系统里一套会员标签三个系统对同一客户的描述可能各不相同字段、格式、判定规则都不一样。数据架构的第一步就是要把这种混乱状况摸清楚。数据流向梳理解决的是“数据从哪里产生、到哪里消费”的问题。比如一份客户订单从生成、审核、锁定库存、调度配送、签收到对账结算数据经历了哪些系统、经过了哪些加工转换。画清楚数据流之后哪里数据断点、哪里重复录入、哪里存在人工搬运一目了然。数字化转型里那些“线上化率低”“数据孤岛严重”的诊断结论本质上都是数据流没理清的表现。数据责任归属决定数据质量问题由谁负责。有些企业搞数据治理搞不起来卡点就在这里——按系统认责时IT说我只管系统运维不管数据质量按部门认责时业务说数据是系统算出来的我怎么知道对不对。数据架构的产出里必须有一份数据责任矩阵明确每个关键数据字段的唯一生产系统和责任岗位没有这张表后续的数据治理都是无源之水。2.3 应用架构中台不是买来的系统而是一条分层的协作逻辑应用架构是四层里跟IT团队日常工作贴合最紧密的一层也是最容易引发争议的一层。争议的核心通常是中台——建还是不建、建多大、用什么技术。这里我想先泼一盆冷水很多企业搞中台失败原因是把中台当成了一款可以采购的软件产品上一个“中台项目”来“建设中台”。但实际上中台是一条应用架构的分层协作逻辑把不同业务线之间公用的能力沉淀到中间一层由专门的团队负责建设和运营前台业务系统通过标准化接口调用这些能力。我判断一套应用架构设计得好不好就看三个分层是否清晰。前台是接触用户和业务的一线系统负责快速响应、频繁迭代比如电商前端、门店POS、移动端APP中台是沉淀共享业务能力的平台系统比如订单中心、会员中心、商品中心、支付中心让不同渠道的前台系统调用同一套交易逻辑后台是承载企业核心资源的底座系统比如ERP、财务核算、HR系统它们求稳、求合规不能频繁变更。“轻前台、厚中台、稳后台”这句话稍显笼统但对于大多数传统企业的数字化转型方向是对的前台避免堆砌复杂逻辑所有需要统一规则的业务逻辑尽量下沉到中台后台系统尽量少做二次开发通过中台隔离变化。我在评估应用架构方案时特别喜欢追问一个问题哪些系统属于稳定后台哪些属于需要快速变化的能力点。如果把企业最核心的竞争力逻辑写死在后台ERP的定制化代码里那这套架构的弹性就非常差如果所有业务逻辑都堆在前台又会造成条条业务线重复开发、口径不一致。把每个系统的定位想清楚比选什么技术栈重要得多。2.4 技术架构克制比前瞻重要技术架构在四层里食之无味、弃之可惜。大多数传统企业的IT部门没有能力也不应该去自研底层中间件或数据库主流选择其实相对固定云资源选哪家、微服务框架用哪个、数据库用MySQL还是PostgreSQL、消息队列用哪款、容器平台怎么搭。关于技术架构我个人的强烈建议是四个字趋于保守。数字化转型的收益来自业务能力和数据能力的提升不来自于你上了多新的技术。选技术栈的唯一标准是团队能不能长期驾驭、社区是不是足够活跃、遇到问题时能否快速找到懂行的人。一个新框架再炫酷如果你的运维团队没人会排查它半夜三更的内存溢出问题那就是灾难。技术架构还承担一个任务给上层应用架构划定边界约束开发团队不要自己造重复的轮子。技术规范里规定统一了日志规范、配置管理、服务注册发现、链路追踪方案才能阻止每个项目组各搞一套。3. 从0到1搭建一套能落地的企业架构实操路径怎么走3.1 第一步不是建架构组织而是圈定范围很多企业搞企业架构第一个动作就是成立架构委员会、发布架构管理办法、引入一套架构治理工具——这是典型的次序颠倒。工具和流程建得再完善没有架构内容可管理就是个空壳。我建议的第一步是把范围圈住。除非你的企业规模确实很大千亿营收、多元化集团否则不要一上来就做全集团全业务域的完整架构。选一个对业务影响最大的核心业务域切入比如制造业的生产制造域零售业的会员营销域从单个业务域打通四层架构做出样板。范围圈定后第二步是把关键角色拉到项目里来。这里有个很常见的误区认为企业架构是IT部门或外部咨询公司的事。实际经验告诉我业务架构部分如果业务部门不深度参与画出来的能力地图百分之百是闭门造车。企业做架构设计时至少要建立两个角色组一个业务架构组由核心业务域的负责人牵头一个技术架构组由IT部门的架构师牵头。两个组定期对齐而不是等IT自己画完再找业务签字确认。3.2 自下而上理现状自上而下定目标中间找差距搭建企业架构时大部分人的直觉是去找标杆、抄模板找一套“未来架构”来套企业。但我的实操经验恰恰相反先花大力气把现状搞清楚自下而上地理清业务运作的现状逻辑再自上而下地推导目标逻辑两条线在中间汇合以后差距自然呈现。具体操作上我一般分五步走。第一步业务架构盘点。用访谈配合工作坊的方式把选定业务域的业务能力地图画出来标注每个能力项的现状成熟度同时理清关键业务流程的断点和痛点。这里不要指望一次访谈能画细通常要做三轮——先粗画一轮框架请业务方指正再补充细节。第二步系统应用现状盘点。把现状IT系统清单整理出来每个系统属于什么业务域、用户是谁、核心功能是什么、技术栈是什么、维护状态如何。这里有个实用技巧不要只罗列系统名称一定要标注“健康度”——比如系统是否还在正常迭代当前负责维护的人还在不在公司。很多老旧系统的真实使用情况和文档记录相差甚远这个细节直接影响后续应用架构的整合方案。第三步数据流和接口现状梳理。挑两到三个核心业务对象比如订单、客户、物料把它们的全生命周期数据流画出来标注每个环节依赖哪个系统、是否存在人工搬运和重复录入。这一步的产出质量决定了后续数据架构的可信度。第四步目标架构设计。基于业务战略如果企业有清晰的战略就用没有清晰战略目标就基于行业对标和业务方的期望画出目标状态的业务能力地图推导出目标应用架构前台中台后台的分层逻辑和目标数据架构核心业务对象的唯一数据源和标准归属。第五步差距分析与路线图。把现状和目标做差集形成项目清单。这个阶段是最考验架构师功力的不是所有差距都值得立刻投入要把差距项目映射到业务价值矩阵上按“价值收益”和“实施难度”两个维度排序形成从近期到远期的演进路线图。3.3 这套方法的产出物不是什么厚文档而是三类决策依据按照上面的路径走完最终交付的核心成果有三类。一类是架构蓝图用来对齐认知。这份蓝图不追求大而全但要清晰到能让一个从来没参与过项目的人看懂未来企业有哪些业务能力、哪些系统分担什么角色、核心数据放在哪里。值得留意的是蓝图的颗粒度要足够细至少要能回答“某个具体的场景数据是怎么流转的”否则企业收到后仍然没法用于指导建设。另一类是演进路线图用来确定投资顺序。未来18个月要建哪些系统、整合哪些系统、哪些系统要被替换释放投资都在这份路线图里看到——它是削减重复建设的直接依据。还一类是架构原则与规范用来约束日常开发。包括数据标准、接口规范、技术选型标准、系统集成原则等等。不要贪多最初版本定5到8条最关键的原则就够了后续按需补充。很多企业的架构规范书厚得像字典实际上没人看因为没人能记住那么多条规则。3.4 落地节奏的建议三个月搭框架、六个月见成效、一年成机制在落地节奏这条线上这些年我带过不少企业迭代下来的经验是短期框架、中期见效、长期机制。第一个月到第三个月完成选定业务域的架构设计框架业务能力地图、应用系统图谱、数据流转图、演进路线图初稿。不要第一阶段就追求全业务域覆盖在试点域跑通流程积累经验。第三到第六个月是极其关键的成长期。很多架构项目死在这个阶段因为图已经画完了新鲜感一过没人再关心。这个阶段要做的是选定第一个落地项目用架构蓝图指导它完成立项、设计与实施并向管理层呈现“架构到底带来了什么”——比如原来需要三个系统人工搬运的数据现在通过接口自动打通了比如原来重复建设的两个会员系统被合并成一个。第六到第十二个月是固化机制的时候。把架构评审纳入项目管理流程新项目立项时必须过架构评审不符合架构规划的不允许立项。这标志着企业架构正式从“项目”转成了“机制”。4. 架构治理让架构从“一次交付”变成“持续运营”4.1 架构文档如果不和预算、立项挂钩就是一张废纸我反复强调一个观点架构方案发布之日就是它开始过时之时。业务在变、组织在变、技术在变任何静态文档都无法长期保持有效。真正让架构保持生命力的不是更频繁地修改文档而是建立一套让架构与企业的投资、立项、研发流程深度绑定的治理机制。这里有一个关键抓手架构评审权。架构评审的价值不在于挑毛病、卡脖子而在于把架构决策和资源分配绑定起来。新项目立项时必须回答几个问题这个项目需要新建系统还是复用现有系统如果新建跟现有系统是什么关系是替代还是共存涉及的数据是否遵循已有标准这个系统归到前台还是中台还是后台这些问题回答不了项目不允许立项回答清楚了架构规划才能真正在具体项目里被执行。4.2 架构守护者机制谁为架构的落地负责机制靠人承载光有流程没有责任人是走不通的。我见过的成功企业在架构治理上都设置了一个关键角色——架构守护者英文叫Architecture Guardian但我不太喜欢这个翻译叫“架构守门员”更准确。架构守护者可以是选定业务域的资深架构师也可能是技术经理职责是持续关注自己负责的领域里各项目是否遵循了架构蓝图和规范。他们的工作重心是预警、纠偏和记录发现一次系统建设偏离蓝图要及时提示团队并对偏离原因做登记对临时性的例外要设定恢复计划明确什么时候回到正轨同时要定期出具报告告诉管理层当前架构实现情况如何、哪些核心项目遵循了规划、哪些没有。4.3 架构体检季度评审加年度大体检两个节奏架构运行过程中还需要两种不同节奏的检查机制来确保健康度。季度评审看执行一次半天主要目的是检查近一个季度的新建、变更项目对架构的遵循度。评审材料不需要厚一张表就行——项目名称、涉及系统、遵循架构的情况、偏差说明、整改行动项。做季度评审的意义在于问题能够在早期被发现而不是等到年底爆雷。年度大体检看方向用一两周时间做系统性评估。业务战略有没有重大变化现有架构还适配吗哪些地方需要调整演进路线图这个体检可以由外部专家参与因为内部团队长期看自己的东西容易形成盲点外部视角能提出更有价值的挑战。4.4 治理中最容易出现的反模式与成功经验对应的是几个我在不同企业反复看到的失败反模式。反模式一架构委员会却开成了“过堂会”。委员会成员来自各业务线会上的汇报变成了各部门为自己项目争取支持的场合架构评审变成了利益博弈。这种情况应该避免架构委员会的成员要有独立于部门利益的身份定位。反模式二只评审、不反馈。会议开完了评审意见发给项目组然后呢没有追踪没有闭环时间一长项目组就知道“评审不过是走个形式”。现在应该让评估结果真正有分量例如与项目投入优先级挂钩以此形成激励。反模式三把架构治理做成IT内部活动。这种模式最具隐蔽性表面上评审流程规范、机制健全但业务战略团队完全没有参与架构和业务脱节。真正有效的架构治理至少要让业务战略负责人在年度架构方向评审中有一票话语权。5. 给中小企业和非技术背景管理者的一份轻量级操作版5.1 认清企业架构的“轻重两套打法”很多人一想到企业架构就联想到几百页的文档、庞大的治理组织、成熟的建模工具——那是大型企业在用的重型方案。中小企业或者大型企业的独立事业部不需要也不应该照搬。重型方案的表达框架重它试图完整覆盖全业务域对你的情况聚焦一条核心价值链加三个关键支撑域就够了。重型方案的处理流程重动辄九个月一年的咨询项目周期你只应该做一到两个月的速写版。重型方案的管理机制重召开固定的架构评审委员会你需要的是“一个明确的人、一次简短的评审会、一条清晰的决策记录”。如果对比重型EA和轻量EA的主要差异可以从这样几个维度看范围方面重型是全业务域覆盖轻量则是聚焦一条核心价值链。难度方面重型追求国际标准方法论轻量对症下药、解决具体问题。迭代方面重型是三五年中长期规划轻量是随业务动态滚动更新。治理方面重型靠委员会和流程机制轻量靠明确负责人和决策记录。我接触过一家年营收几个亿的贸易公司还不到百人的IT团队看到别人都在做“企业架构”就也拉了一支咨询团队做“数字化转型总体架构规划”整整做了八个月产出了两百多页PPT。但后来真正推动转型时最有效的是他们内部用一周做出来的那张核心业务数据流图这至少证明了一个判断中小企业真正需要的往往只是一个清晰的作战地图而不是一套完整的理论体系。5.2 最实用的轻量路径一张图、一张表、一个人具体操作方法上我建议用“三个一”起手。第一张图是核心业务数据流转图。用一张A3纸画出从客户接触开始经过订单生成、履约、交付、售后的核心业务过程标出每个环节的数据在哪些系统里产生和使用用箭头标出流转关系。这张图的价值是把无形的业务逻辑变成可视化的共识——建议找业务核心骨干和IT负责人坐到一起画画的过程中出现的分歧往往就是转型需要优先解决的问题。第二张表是关键数据责任表。列出企业最重要的5到10个业务对象客户、商品、订单、供应商、库存这些确定每个对象的唯一数据源头系统、权威维护岗位、关键质量要求。这张表是后续一切数据治理工作的基础不需要一次做全先覆盖最痛最乱的几个数据对象。第三个人是架构责任人。哪怕只有一个人也要明确一个对架构负责的角色通常是从技术总监或资深架构师里选由这个人负责维护架构文档定期搜集反馈、推动更新确保每一项架构决策有结果。这个人不需要专职但要考核要明确——实际上从大量案例里看很多架构没有人负责维护是架构方案流于形式的最直接原因。5.3 关键提醒别让“数字化转型”变成老板一个人驱动的项目最后一条经验在我看是对中小企业最实用的。很多中小企业的数字化转型是老板拍板发起、IT部门执行推进但业务部门的参与度极低。架构设计过程中业务负责人全部缺席只在汇报的时候露个脸转身走后该干什么干什么。这样的架构方案从诞生那天起就注定了被束之高阁的命运。轻量级架构设计里我会特别建议业务负责人要投入的实际时间不需要太多但必须是整个过程的重要节点在关键会议上有实质表态——比如在业务能力地图的评审会上确认优先级在路线图评审会上拍板投资顺序。没有这把手的局面是信息化部门在下面反复画图、反复修改但每一次修改的优先级却是由IT部门自己猜测出来的——这种“闭门造式车”是最常见的中小企业架构项目失败模式。6. 两套语言与期望管理架构最难过的是组织这一关做企业架构项目多年我最大的体会是技术问题几乎都能通过流程和工具解决最难的是组织问题——确切地说是两套语言之间的翻译问题。业务方和管理层讲的是生长逻辑我们要做新渠道、我们要提升客户体验、我们要降低库存周转天数。架构师讲的是支撑逻辑能力地图、数据实体、系统耦合度、接口标准。这两套语言之间本来应该有翻译层——但很多企业恰恰缺了这个环节最终的结果就是业务觉得架构师在玩概念架构师觉得业务听不懂专业内容双方在各自的语境里相互误解。我自己常用的应对方式之一是把业务架构汇报的对象顺序拔高。做架构设计之初第一个交流的对象不是CIO或IT老大而是业务副总裁或总经理。先听他讲业务痛点和战略方向再回到技术侧做方案。方案汇报时也不是先讲技术架构而是先讲“基于你的业务目标我们建议分三步走这中间有几个关键的决策点需要你拍板”——把架构语言翻译成业务决策的语言推动力会大很多。另外一个小技巧给架构正式定名时尽量别叫“企业架构规划”或“XX架构设计”业务和管理层听到“架构”两个字就觉得跟自己无关、是IT的事。起名时可以叫“企业数字化转型总体方案”或“XX业务线数字化作战蓝图”虽然本质是一回事但接受度会明显更高。这不是包装而是让对的人愿意真正看这份材料——只有被看见的方案才有落地的可能。说到底企业架构设计这件事衡量成败的标准从来不是“方案做得好不好”而是“组织有没有因此做出更清晰的决策”。如果你正在准备做一份企业架构方案不妨在动手之前就提前想清楚这份方案的目标读者、他们每个季度必须做的决策、你用什么样的输出物去辅助他们——想清楚了这些再开始画第一张图可能就不会是下一个被锁在抽屉里的107页PPT了。本文还有配套的精品资源点击获取