企业官网建设流程全解析

立足

三年前刚开始做 Sketch 生成代码插件时，定位的就是原型工具，不是可用页面。我当时认为直接由设计稿生成可用代码是走不通的，原因有两个:

• 当时的前端自己都还处在争论用什么框架的时期，得先解决了这个问题设计工具才可能生成被大部分开发者接受的代码。
• 设计语言与编程语言差异比想象中的大。

关于第二点这里详细说明一下。设计稿中的图层通常表达的是离人眼前后顺序，前面的覆盖后面。而图层的分组也只是为了管理而已，没有逻辑上的聚合关系。如下图，背景的红色图层与形状图层是平级的，没有展示出包含关系。

并且在设计中常常会按类型而不是按逻辑归属把一些东西放在同一图层，这样设计师在修改的时候比较容易批量操作。而在前端的组件化中，组件几乎一定是按逻辑功能划分的。而组件的层级表达也是逻辑上的包含关系。这种关系只有一部分能和视觉上的从前到后匹配。以 React 为例，很多组件层级的表达就不是前后关系。

因此，想要实现视觉上到逻辑上的完美转化，只有两种可能，一是按逻辑的要求约束视觉上的图层、分组使用。二是靠机器学习之类的方式去智能识别(社区已有开源项目)。

第一种方式其实技术上可行，但是不人性。两个方面，一是给设计师造成了巨大的学习成本。这个巨大指的不是设计师学不会，而是指规则有可能因为开发者设计得不完善或者不够简便，使得设计师要做很多他自己无意义的额外操作。例如本来设计师一个图层可以画完的元素，在规则的要求下要进行分组分层。二是这些规则很可能忽视了设计师的需求，例如之前所提到的同一图层管理同一类元素的的问题。我有尝试使用社区内的一些方案，从设计师的角度来说，那种体验就像：

第二种方式当时虽然有想过，但是没有深入去探索，原因也是当时的前端变化太快，我认为找不到足够稳定的样本能去训练。

有了以上结论后，我想到了虽然直接生成可用页面不行，但是生成原型还是有可能的。设计师和前端的沟通成本也是一个需要解决的问题。最常见的就是设计师需要告诉前端某个元素 hover 上去是什么效果，点击是什么效果等。这些东西既然设计师已经画出来了，那么能不能把这个表达的方式自动化掉，省去人工沟通的成本。像 Axure 之类的原型工具就有类似的功能。只是这些工具一般都定位给产品做最初的原型设计，缺少了视觉上的细节，不能完全取代设计师和前端的沟通。

因此我开始做从视觉稿到原型的 Sketch 插件 Blade。这个插件虽然也在一定程度上要求设计师按某种规则来设计，但是这种规则对设计师已经是有意义的了，能省去他的口头描述。

旁观

在开发完第一版后，由于工作的调动就没再维护了。后来更是由于 Sketch 升级后的 api 变化导致不能用了。让我比较意外的是这两年间持续不断地有人开 issue，写 email 希望我继续更新。我在 issue 中委婉的表示项目已经不再维护，大家可以试试社区的其他方案。但社区的其他方案屈指可数，并且方向和定位其实也都不太相同。

按我所接触的顺序一一介绍一下。

Marketch，也是生成 html 文件，但是专注于标注功能，方便前端同学取位置和样式信息。这个定位非常精确，让前端不再需要自己装 Sketch。

从 Sketch 的生态体系看来其实插件可以分成两大类，一类是用来方便设计师的操作的，例如快速生成一些常用的元素，如头像、地图等。另一类就是扩展设计之外功能，例如生成标准、原型。对个人开发者来说开发前一类的插件难度比较小，而且收益很明确。而后者相对来说难度和收益就都不乐观了。在后来我再看到的第二类插件中，几乎都是团队进行开发的。例如 Framer 和 Proto.io。

这两个工具的共同点是都已经脱离了 Sketch 体系，变成了独立应用。以导入的方式来整合 Sketch/Photoshop 等工具的产出物。但定位也仍然是可交互的原型产品。直到 Launchpad 出现，才算得上我知道的第一个定位于生成可用页面的 plugin。

从 Lauchpad 所提供的功能看来，生成页面功能非常简单，只有简单的链接、表单，还不涉及到复杂的交互逻辑。生成的代码也不能二次开发。但是 Launchpad 做成了一门生意，并且好像运营得还不错。从跟我进行邮件沟通的设计师中，我也发现了不少想要直接建站的需求。再回过来看我之前认为这条路不能成功的两个原因，反思一下是我想错了吗？

第一个原因是我认为生成的代码必须要前端能接受才行。Launchpad 没有提供二次开发这个能力，似乎就回避掉了这个问题。但同时也就限制了能力。

第二个原因是设计语言和编程语言的差异。同样的，缩小了需要覆盖的场景，不提供二次开发，也使得对设计师造成的负担最小化。

这样看来不是对错的问题，而是本来定位就不一样。我在思考这个问题的时候其实并没有区分场景，定位的是从简单页面到复杂的单页应用应该都能适用的情况。Launchpad 提供了一个新思路，就是缩小场景后能实现一部分。

前面列举的相关的插件都是从设计的角度出发制作的。而不久前 Airbnb 的 react-sketch 插件则提供了一个新的角度。

它的目标是设计资产的管理。它的能力是将组件这种设计资产从代码导入到 Sketch，同时也能从 Sketch 导出到代码。所以即可以说站在了设计师的角度也可以说是站在了前端的角度。在知乎上有一个评价 react-sketch 的问题。前两个回答非常的透彻。读者可以看一看。回答里提到的这种工具在真实团队的适用并不乐观，我有同感。因为它站在了一个新的角度看问题，那么必须也得有一个站在同一角度的新角色(设计工程师?)出现才能显示出它的价值。否则单独对设计师、对前端，都会感觉意义不大。

同样，react-sketch 也提供了一个新思路，就是以设计资产这个维度来实现代码和设计元素的统一是有一定价值的。这种统一，其实也就是能互相转换。