1. 从一张草图到一套视觉语言diagram-design 到底在解决什么问题很多人第一次听到 diagram-design 这个词会下意识觉得它只是“画图”的另一种说法。但真正在项目里做过架构图、流程图、时序图、部署拓扑图的人都知道画图本身从来不是难点难点在于图与图之间的一致性、可维护性和表达效率。你画第一张架构图的时候可能花十分钟调颜色、对齐框线、选字体等到第十张图的时候你发现自己已经记不清第一张用的到底是哪种蓝、哪个圆角、哪条虚线代表异步调用。diagram-design 要解决的正是这个从“单张图好看”到“整套图成体系”的跨越问题。我把它理解为一套面向图表领域的视觉设计系统。它不局限于某一个绘图工具也不绑定某一种图形语法而是把图表当作一种需要被设计的“产品”来看待。就像 UI 设计有设计规范、有组件库、有色彩体系一样diagram-design 试图为图表建立同样的秩序感。你可能会问图表不就是把信息画出来吗至于这么讲究吗我举个实际场景你就明白了。假设你所在的团队正在维护一个中等规模的系统有网关层、服务层、数据层还有若干外部依赖。团队里五个人每个人负责画自己那部分的图。如果没有统一的 diagram-design 约定最后拼出来的全景图大概率是这样的有人用蓝色圆角矩形表示服务有人用灰色直角矩形表示服务有人把数据库画成圆柱有人画成带三条横线的矩形有人用实线箭头表示同步调用有人用虚线箭头表示同步调用还有人用带空心三角的箭头表示同步调用。图本身没错但放在一起就是一场视觉灾难。阅读者需要不断在脑子里做“翻译”认知负担陡增。diagram-design 的核心价值就在这里它通过形状语义、色彩语义、线条语义、排版语义四个维度的约定让图表从“个人表达”变成“团队语言”。形状语义解决“什么类型的元素用什么图形表示”比如服务用圆角矩形、数据存储用圆柱、外部系统用虚线边框矩形。色彩语义解决“什么状态或层级用什么颜色”比如核心链路用高饱和主色、辅助链路用低饱和中性色、异常路径用警示色。线条语义解决“什么关系用什么线型”比如同步调用用实线、异步消息用虚线、数据流向用带箭头的线。排版语义解决“文字怎么放、放多大、放哪里”比如节点标题居中加粗、描述文字左对齐小一号、图例统一放右下角。这套东西听起来简单但真正落地的时候你会发现每一个决策背后都有取舍。比如色彩语义如果你给每个服务都分配一个独立颜色图会变得花哨且难以维护如果你只用一种颜色又无法区分层级。我的经验是采用“主色 中性色 强调色”的三层色彩策略主色用于核心业务链路中性色用于基础设施和辅助组件强调色只用于需要读者特别注意的异常或关键节点。这样既保持了整体克制又保留了必要的表达力。再比如形状语义很多人喜欢用图标来代替几何形状觉得更直观。但图标的问题在于风格难以统一而且在不同尺寸下表现差异很大。diagram-design 的常见实践是几何形状为主图标为辅。几何形状负责承载语义图标只在图例或关键节点上作为补充说明。这样即使图表被缩小或打印成黑白语义依然清晰可辨。还有一个容易被忽略的点是图表的“呼吸感”。很多技术图之所以看起来累不是因为信息太多而是因为元素之间没有留白。diagram-design 通常会规定最小间距、对齐网格和边距规则。比如节点之间的水平间距不小于节点宽度的三分之一垂直间距不小于节点高度的二分之一画布边缘留白不小于 40 像素。这些数字不是拍脑袋定的而是基于大量实际阅读场景的反馈——在投影仪上、在文档里、在手机屏幕上留白不足的图都会迅速变得不可读。所以diagram-design 不是教你“怎么画一张好看的图”而是教你“怎么建立一套让团队持续画出好图的规则”。它的受众可以是技术架构师、产品经理、技术文档写作者也可以是任何需要频繁用图表沟通的人。接下来的内容我会从实际项目出发拆解这套设计体系怎么搭建、怎么落地、怎么避免常见的坑。2. 搭建 diagram-design 体系前必须想清楚的三个前提2.1 你的图表是给人看的还是给机器读的这个问题听起来有点奇怪但它直接决定了 diagram-design 的走向。给人看的图重点是阅读体验和认知效率给机器读的图重点是结构化和可解析。前者可以容忍一定的视觉冗余后者则要求严格的语法规范。我见过不少团队在这件事上犯迷糊。他们用 PlantUML 或 Mermaid 这类文本化工具生成图表然后试图用 CSS 去精细控制每一个节点的样式。结果就是代码里堆满了skinparam和样式覆盖维护成本极高而且一旦工具升级样式可能全部失效。这就是典型的“用机器的语言做人的设计”。我的建议是分层处理。底层用文本化工具保证结构正确和版本可追踪上层用设计系统保证视觉一致。具体来说你可以用 Mermaid 定义图的逻辑结构然后通过一套统一的主题配置来应用 diagram-design 的规则。如果工具本身不支持足够的样式控制那就把图导出为 SVG再用设计工具做二次视觉处理。关键是不要试图在一个层面解决所有问题。2.2 你的图表是一次性的还是长期演进的一次性图表比如某个临时汇报用的草图不需要太复杂的 design 体系够用就行。但长期演进的图表比如系统架构图、业务流程图、数据模型图就必须考虑可维护性。可维护性的核心是语义与样式分离。什么意思就是你在图里标注的是“这是一个数据库”而不是“这是一个蓝色圆柱体”。样式应该由统一的规则来决定而不是由画图的人手动指定。这样当团队决定把数据库的表示从蓝色圆柱改成绿色圆柱时只需要改一处规则所有图自动更新。在实际操作中这意味着你需要建立一个图表组件库。这个库可以是 Figma 里的组件、Draw.io 里的形状库、或者代码里的样式变量。不管形式如何核心是任何人画图时不应该从零开始调样式而应该从组件库里拖拽已经定义好的元素。这样既保证了一致性又降低了新人的上手成本。2.3 你的团队有多少人参与画图如果只有你一个人画图diagram-design 可以相对简单甚至只存在于你的脑子里。但只要有两个人以上参与就必须把规则显性化、文档化。因为不同的人对“好看”和“清晰”的理解差异巨大不写下来就一定会跑偏。我参与过一个项目初期只有两个架构师画图风格还算统一。后来团队扩张到八个人新来的人没有接受过任何图表规范培训结果三个月后同一个系统在不同文档里出现了五种不同的画法。最夸张的一次同一个服务在两张图里用了完全不同的颜色和形状导致新同事以为是两个不同的系统。所以diagram-design 的落地必须包含规范文档 模板文件 评审机制三件套。规范文档说明规则和理由模板文件提供开箱即用的起点评审机制确保新图符合规范。这三者缺一不可。3. 形状、色彩、线条、排版diagram-design 的四根支柱3.1 形状语义让每个图形都有固定含义形状是图表中最基础的视觉元素。在 diagram-design 体系里每一个形状都应该有明确的语义不能随意使用。形状语义使用场景圆角矩形服务/应用/处理单元微服务、函数、业务模块直角矩形基础设施/平台组件网关、消息队列、缓存圆柱数据存储数据库、数据仓库、对象存储平行四边形数据输入/输出外部数据源、报表输出菱形条件判断流程分支、决策节点虚线边框矩形外部系统/第三方依赖支付网关、短信服务圆形起点/终点流程开始、流程结束这张表看起来简单但实际使用时有很多细节要注意。比如圆角矩形的圆角半径太大显得卡通太小又和直角矩形难以区分。我的经验是圆角半径控制在节点高度的 10% 到 15% 之间这样既有辨识度又不失专业感。再比如圆柱的绘制很多人画出来的圆柱比例失调看起来像个压扁的罐头。正确的做法是圆柱顶部椭圆的短轴与长轴比例控制在 1:4 左右圆柱高度至少是顶部椭圆短轴的三倍。这样画出来的圆柱才有立体感同时不会占用过多垂直空间。还有一个常见问题是形状嵌套。比如一个服务内部包含多个模块你是画一个大框里面套小框还是把模块平铺出来diagram-design 的建议是嵌套层级不超过两层。超过两层图的可读性会急剧下降。如果确实需要表达三层以上的结构应该拆成多张图或者用编号和引用来关联。3.2 色彩语义克制比丰富更重要色彩是图表中最容易失控的元素。我见过太多图每个节点一种颜色最后看起来像打翻了调色盘。diagram-design 的色彩策略核心是克制。具体来说我推荐使用“三色体系”主色1 到 2 种用于核心业务链路和关键节点。饱和度适中明度较高确保在投影和打印时都能清晰辨认。中性色3 到 4 种灰度用于基础设施、辅助组件和背景。从浅灰到深灰形成层次但不抢眼。强调色1 种用于异常、警告或需要特别关注的节点。饱和度较高但使用面积要严格控制通常不超过图面总面积的 5%。这套体系的好处是即使图被转成黑白你依然可以通过明度差异区分不同层级。很多团队喜欢用红绿蓝来区分不同服务但红绿色盲的读者就完全无法分辨。用明度差异来传递信息是更稳妥的做法。还有一个细节是背景色。diagram-design 通常建议使用纯白或极浅的灰色作为画布背景避免使用深色背景。深色背景虽然在屏幕上看起来酷但打印时极其耗墨而且在文档中嵌入时容易和周围文字形成冲突。如果确实需要深色主题应该准备两套配色方案而不是简单地把浅色方案反相。3.3 线条语义线型、箭头、粗细都有讲究线条在图表中承担着表达“关系”的重任。diagram-design 对线条的规定通常包括线型、箭头样式和粗细三个维度。线型方面实线表示同步调用或强依赖虚线表示异步消息或弱依赖点线表示可选或未来规划。这个约定在大多数技术图表中通用但要注意虚线间距。间距太小看起来像实线太大又显得松散。我的经验是虚线间距控制在 4 到 6 像素线段长度控制在 8 到 12 像素。箭头样式方面实心箭头表示数据或控制流的方向空心箭头表示继承或实现关系无箭头表示关联但不强调方向。很多人喜欢用各种花哨的箭头比如菱形箭头、圆形箭头但这些在技术图表中容易引起歧义建议只在 UML 类图中使用。线条粗细方面主链路用 2 像素辅助链路用 1 像素这样即使图缩小主次关系依然清晰。但要注意线条粗细的差异不要超过两倍否则细线在缩放后可能消失。还有一个容易被忽略的点是线条交叉。当两条线必须交叉时应该使用“跳线”来表示不连接。跳线的弧度要统一通常是一个半圆半径略大于线条间距。如果交叉太多说明图的布局需要调整而不是靠跳线来补救。3.4 排版语义文字是图表的一部分不是附属品很多人在画图时把文字当作“填进去就行”的东西结果就是字体混乱、大小不一、对齐随意。diagram-design 把排版视为图表设计的核心组成部分。字体方面技术图表建议使用无衬线字体比如思源黑体、Noto Sans、Inter 等。这些字体在屏幕和打印上都有良好的可读性而且支持多语言。字号方面节点标题建议 14 到 16 像素描述文字 12 到 13 像素图例文字 11 到 12 像素。字号差异不要超过两级否则视觉层次会变得混乱。对齐方面节点内的文字建议居中对齐节点外的标注文字建议左对齐。图例统一放在画布的右下角或右上角不要随意摆放。如果图中有多个图例应该合并成一个而不是分散在各处。还有一个细节是文字与形状的间距。文字距离形状边缘至少要有 8 像素的内边距否则会显得拥挤。如果文字较长需要换行行高建议设置为字号的 1.4 到 1.6 倍这样阅读起来最舒适。4. 从零搭建一套可落地的 diagram-design 规范4.1 先收集现有图表做一次“视觉审计”在制定规范之前你需要先知道现状是什么。我通常会建议团队做一次“视觉审计”把过去半年到一年内所有重要的图表收集起来然后从形状、色彩、线条、排版四个维度做统计分析。具体操作是随机抽取 20 到 30 张图逐一记录每张图用了哪些形状、哪些颜色、哪些线型、哪些字体和字号。然后统计出现频率最高的选项以及差异最大的选项。频率最高的选项往往就是团队已经形成的“隐性规范”差异最大的选项就是需要重点统一的地方。这个审计过程通常会发现一些有趣的现象。比如某个团队一直以为自己用的是蓝色系审计后发现实际上用了七种不同的蓝。再比如某个团队觉得自己的图很统一审计后发现光是箭头样式就有五种。这些发现会成为制定规范时的重要依据。4.2 定义最小可行规范而不是追求大而全很多团队在制定 diagram-design 规范时容易陷入“完美主义陷阱”试图一次性定义所有细节。结果就是规范文档写了五十页没人看得完更没人执行。我的建议是先定义最小可行规范。所谓最小可行就是只规定那些“不统一就会出大问题”的要素。通常包括形状语义表哪些形状表示哪些元素色彩体系主色、中性色、强调色的具体色值线型约定实线、虚线、点线分别表示什么字体和字号标题、正文、图例分别用什么画布和间距规则最小间距、边距、对齐方式这五项定下来图表的统一性就能达到 80% 以上。剩下的细节比如阴影、渐变、圆角半径可以在后续迭代中逐步补充。4.3 把规范变成模板和组件而不是文档规范文档写完之后最大的挑战是让人用起来。如果规范只存在于文档里大多数人不会主动去翻。所以必须把规范“嵌入”到日常工具中。具体做法取决于团队使用的工具。如果用的是 Figma就建立一套图表组件库把常用节点、连线、图例做成组件团队成员直接拖拽使用。如果用的是 Draw.io就导出一套自定义形状库导入后即可使用。如果用的是代码化工具就把样式定义成主题文件通过配置文件引入。关键原则是让符合规范的做法成为最省事的做法。如果团队成员发现用组件库比手动调样式更快他们自然会用。如果发现用组件库反而更麻烦规范就形同虚设。4.4 建立轻量级的评审机制规范落地之后还需要一个反馈闭环。我推荐的做法是在团队内部建立一个“图表评审”的轻量机制。不需要正式的评审会议只需要在提交图表时由一位熟悉规范的人快速过一遍指出明显偏离规范的地方。评审的重点不是“好不好看”而是“是否符合约定”。比如形状用错了、颜色不在色板里、线型用反了这些是必须纠正的。至于布局是否最优、信息层级是否合理可以作为建议提出但不强制。评审的频率可以根据团队规模调整。小团队可以每周集中看一次大团队可以按项目或按文档批次评审。关键是保持反馈的及时性不要让问题积累。5. 实操中容易踩的五个坑和我的处理方式5.1 过度设计把图表当成海报来做我见过一些团队把 diagram-design 理解成“把图做得越炫越好”。于是加阴影、加渐变、加立体效果、加动画最后图确实很“好看”但信息传达效率反而下降了。图表的第一目标是清晰传达信息美观是第二位的。任何视觉元素如果对信息传达没有帮助就应该去掉。阴影和渐变在大多数技术图表中都是多余的它们只会增加视觉噪音。立体效果更是如此它会让节点看起来像按钮误导读者以为可以点击。我的处理方式是在规范中明确“禁止使用装饰性视觉效果”。只允许使用纯色填充、实线边框和必要的圆角。如果确实需要强调某个节点用颜色或边框粗细来实现而不是加阴影。5.2 颜色不够用当节点类型超过色板数量时这是一个非常实际的问题。假设你的色板定义了 8 种颜色但图中有 15 种不同类型的节点怎么办很多人的第一反应是“再加几种颜色”。但这样做的结果是色板越来越庞大最终失去约束力。我的建议是用形状和文字来补充色彩的表达力。具体来说如果两种节点类型在语义上相近可以共用一种颜色通过形状或图标来区分。比如“关系型数据库”和“非关系型数据库”都用圆柱表示但前者用蓝色后者用蓝色加一个小的“NoSQL”标签。这样既保持了色彩体系的简洁又保留了必要的区分度。如果节点类型确实太多那就说明这张图承载了太多信息应该考虑拆图。一张图最好只表达一个核心主题节点类型控制在 8 种以内。5.3 图例缺失或混乱读者看不懂你的图图例是图表的“说明书”但很多人要么不画图例要么图例画得乱七八糟。我见过一张图图例放在左上角但图例里的形状和图中的形状大小不一致颜色也有偏差读者根本对不上号。diagram-design 对图例的要求是图例必须与图中元素完全一致包括形状、颜色、线型和大小。图例的位置要固定通常放在右下角不遮挡主要内容。图例的排列要整齐按类别分组比如“节点类型”“连线类型”“状态标识”各一组。如果图中元素较少且形状语义非常直观可以省略图例。但只要图中出现了非标准形状或特殊颜色就必须加图例。5.4 版本失控同一张图在不同地方不一样这是一个非常隐蔽但危害很大的问题。同一张架构图在 Wiki 里是一个版本在 PPT 里是另一个版本在代码仓库里又是第三个版本。每个版本都略有不同但没人知道哪个是最新的。我的处理方式是建立单一数据源。所有图表都从一个地方生成或导出其他地方的图都是这个源的副本。如果用的是代码化工具就把图定义文件放在代码仓库里和代码一起版本管理。如果用的是设计工具就建立一个“图表主文件”所有导出都从这个文件生成。同时在图的角落标注版本号和更新日期这样读者一眼就能知道这张图的新旧程度。5.5 新人上手难规范太复杂记不住规范越复杂新人越难上手。我见过一个团队的 diagram-design 规范光颜色就有 24 种形状有 18 种新人看完直接放弃。解决这个问题的关键是分层。把规范分成“必须遵守”和“建议遵守”两层。必须遵守的部分尽量精简通常不超过一页纸。建议遵守的部分可以详细一些供有需要的人查阅。另外提供开箱即用的模板非常重要。新人不需要从零开始只需要在模板基础上修改内容即可。模板里已经预设好了形状、颜色、字体和布局新人只需要替换文字和调整节点数量。6. 让 diagram-design 持续演进的三个习惯6.1 定期回顾每季度做一次图表“体检”规范不是定完就完了它需要随着团队和项目的变化而演进。我建议每季度做一次图表“体检”抽取最近一个季度的图表看看有没有新的模式出现有没有旧的规则不再适用。比如团队开始使用新的技术栈可能需要新增一种形状或颜色来代表新的组件类型。再比如团队发现某种线型在实际使用中容易引起歧义可能需要调整约定。这些变化都应该及时反映到规范中。体检的另一个目的是发现“规范漂移”。即使有规范人们在实践中也可能逐渐偏离。定期体检可以及时发现这些偏离并决定是纠正实践还是调整规范。6.2 收集反馈让画图的人参与规范优化规范的使用者是画图的人所以规范的优化也应该由他们参与。我通常会在团队内部建立一个简单的反馈渠道比如一个共享文档或一个聊天群让大家随时提出对规范的建议和疑问。反馈的内容可以包括某个规则在实际使用中不方便、某种新的图表类型没有对应的规范、某个色值在特定场景下看不清等等。这些反馈积累到一定程度就可以作为规范迭代的输入。关键是让团队成员感觉到规范是“我们的规范”而不是“管理层强加的规定”。只有这样他们才会主动遵守和优化。6.3 保持克制不要为了规范而规范最后也是最重要的一点规范是为了解决问题而不是为了规范本身。如果某个规则在实际使用中并没有带来明显的收益反而增加了负担那就应该考虑去掉它。我见过一些团队规范越来越复杂但图表的整体质量并没有提升。原因就是他们在不断添加规则却很少删除规则。好的规范应该是精简的、有针对性的每一条规则都能回答“它解决了什么问题”。所以每次迭代规范时除了添加新规则也要审视旧规则是否仍然必要。如果某条规则已经内化为团队习惯或者已经不再适用就可以考虑删除或简化。7. 一个完整的 diagram-design 应用示例为了让你更直观地理解这套体系怎么用我以一个虚构的“在线订单系统”架构图为例走一遍完整的设计流程。7.1 第一步明确图的主题和读者这张图的主题是“在线订单系统的核心架构”读者是技术团队的新成员和外部合作方的技术人员。因此图需要清晰展示系统的核心组件、数据流向和外部依赖但不需要深入到每个类的设计细节。7.2 第二步列出所有需要表达的元素根据系统实际情况列出以下元素客户端Web、移动端API 网关订单服务支付服务库存服务消息队列订单数据库支付数据库外部支付网关外部物流系统7.3 第三步按形状语义分配图形根据前面定义的形状语义表客户端用直角矩形基础设施/平台组件API 网关用直角矩形订单服务、支付服务、库存服务用圆角矩形服务/应用消息队列用直角矩形订单数据库、支付数据库用圆柱数据存储外部支付网关、外部物流系统用虚线边框矩形外部系统7.4 第四步按色彩语义分配颜色核心业务链路订单服务、支付服务、库存服务用主色基础设施API 网关、消息队列用中性色数据存储用中性色偏深外部系统用浅灰异常或需要强调的节点用强调色本例中没有7.5 第五步按线条语义连接元素客户端到 API 网关实线箭头表示同步请求API 网关到订单服务实线箭头订单服务到支付服务实线箭头订单服务到库存服务实线箭头订单服务到消息队列虚线箭头表示异步消息订单服务到订单数据库实线箭头支付服务到支付数据库实线箭头支付服务到外部支付网关虚线箭头表示外部依赖库存服务到外部物流系统虚线箭头7.6 第六步排版和布局客户端放在最左侧垂直排列API 网关放在客户端右侧三个核心服务水平排列在网关右侧消息队列放在核心服务下方数据库放在核心服务右侧外部系统放在最右侧图例放在右下角包含形状说明、颜色说明和线型说明7.7 第七步检查和调整完成初稿后检查以下几点所有形状是否符合语义表所有颜色是否在色板内所有线型是否符合约定文字是否清晰可读间距是否足够图例是否完整如果发现问题及时调整。比如发现某个节点颜色不在色板内就替换为最接近的色板颜色。如果发现线条交叉太多就调整布局。这套流程看起来步骤不少但实际操作中熟练之后可以在半小时内完成一张中等复杂度的架构图。关键是前几次要严格按照流程走形成肌肉记忆后就可以灵活运用了。8. 工具选型不同场景下的 diagram-design 落地方式8.1 设计工具路线Figma、Sketch、Adobe XD适合场景需要精细视觉控制、图表数量不多、团队有设计资源。优点视觉控制力最强可以实现任何想要的效果。组件和样式系统成熟适合建立图表组件库。缺点手动操作多不适合大批量生成图表。版本管理和协作需要额外注意。我的建议如果团队有设计师可以用设计工具建立一套图表组件库然后由设计师或经过培训的工程师使用。关键是要把组件库维护好确保所有人用的是同一套组件。8.2 代码化路线Mermaid、PlantUML、Graphviz适合场景图表数量多、需要频繁更新、希望版本可追踪。优点文本化定义易于版本管理和自动化生成。适合嵌入文档和代码仓库。缺点视觉控制力有限复杂样式难以实现。不同渲染引擎的效果可能有差异。我的建议用代码化工具定义图表结构然后通过主题配置应用 diagram-design 的规则。如果工具本身样式控制不足可以导出 SVG 后用脚本做后处理。关键是不要试图在代码层面解决所有视觉问题。8.3 专业图表工具路线Draw.io、Lucidchart、ProcessOn适合场景需要平衡视觉控制和操作效率、团队没有专业设计资源。优点操作直观上手快。支持自定义形状库和样式模板可以较好地落地 diagram-design。缺点高级功能可能需要付费。不同工具的格式兼容性有限。我的建议如果团队没有设计师专业图表工具是最务实的选择。可以在工具中建立一套自定义形状库和样式模板然后要求团队成员从模板开始画图。这样既能保证一致性又不会增加太多操作负担。8.4 混合路线代码生成 设计工具精修适合场景对视觉要求高、图表需要频繁更新、团队有一定技术能力。优点兼顾效率和视觉质量。代码负责结构和批量生成设计工具负责精修和特殊处理。缺点流程相对复杂需要维护两套工具链。我的建议对于核心架构图、对外展示图可以采用混合路线。先用代码生成基础结构再导入设计工具做视觉优化。对于内部沟通图直接用代码化工具或专业图表工具即可。9. 写在最后一些个人体会做 diagram-design 这些年我最大的体会是图表的本质是沟通设计只是手段。一套好的图表设计体系应该让画图的人更高效让读图的人更轻松。如果一套规范让画图变得更麻烦让读图变得更费劲那它就是失败的。另一个体会是一致性比完美更重要。一张图可能不够惊艳但如果它和团队其他图保持一致的风格读者就能更快地理解它。相反一张图再好看如果和周围图格格不入读者反而需要花更多时间适应。还有一点是规范要为人服务而不是人为规范服务。我见过太多团队为了遵守规范而遵守规范结果画出来的图僵硬、死板失去了表达力。规范应该是底线而不是天花板。在遵守基本约定的前提下画图的人应该有足够的空间去发挥。最后如果你正在考虑在团队里推行 diagram-design我的建议是从小处着手先解决最痛的问题。不要一上来就搞一套大而全的规范而是先统一最常用的几种形状和颜色让大家感受到一致性带来的好处然后再逐步扩展。这样推行的阻力最小效果也最持久。