E 签宝的 PLG 业务主要是通过优惠、实用工具等方式吸引用户来驱动用户的留存和转化。E 签宝在多年的业务沉淀下，了解到实际用户在使用的过程中，脱离合同生命周期之外遇到的不少技术性卡点，因此提供了不少小工具产品，例如合并 PDF、文件转换器等，帮助 e 签宝用户群体更轻松、更容易的在合同生命周期下进行工作，提升用户体验效率。
项目背景
E 签宝现在已经沉淀了不少实用的小工具系列，但是目前这些小工具散落在各个链接之下，没有一个统一的集合点，用户难以找到入口，反而影响了使用。
随着 AI 的发展，一些相对简单、模块化的界面也可以尝试不在大量消耗设计资源进行产出，本次设计也希望可以通过设计全局模块的方式，让 AI 可以后续进行直接拼装页面，实现小工具模块的 AI coding化，节省设计和开发成本。
选择 PLG 作为探索和实验场地是经过慎重的考虑的，我们在之前的 AI 探索中逐渐发现，AI 擅长的是一些没有那么规范、统一，并且可以允许一些小瑕疵的 UI 页面，而运营类页面天然与其适配。
任务需求 | 对规范性要求 | AI 适配度 |
|---|---|---|
运营类页面开发 | 中等 | 高 |
运营类页面视觉化物料 | 低 | 极高 |
运营类页面页面模板化调用 | 高 | 高 |
在整个项目中，我们认为主要是需要解决以下三个问题：
如何抽离好模块，并告知AI 在实际的业务中该如何使用这些模块拼装后续的 UI 界面；
PLG UI 中存在大量视觉化物料内容，该如何利用 AI 规范化输出；
AI 工具种类繁多，但是从哪一步开始介入，如何介入的具体操作流程如何沉淀。
在本文的介绍中，我们也会从探索到最后落地都会围绕着三个问题展开。
前期探索
由于 AI 工具的能力大幅提升，最早期我们是希望设计师可以直接利用 Codex、Claude code 等工具至今进行 Vibe coding 的，这套方式高效、工期短，并且一单沉淀出标准方法工作流可以被产品和开发复用，大幅提升效率。
然而，理想很丰满，现实是骨感的。在实际的场景中，PLG 相关的业务都没有引入 EDM 移动端组件库，导致实际 Vibe coding 过程中，完全无法达到移动端真实的业务场景需要，在和开发的商议中我们确定了现在引入 EDM 组件库是一个相对有成本的行为，因此这种方式被迫放弃。
随后，我们开始考虑使用 stitch、Claude design 这一类 AI 设计工具来完成这部分操作。我们希望可以更快的压缩设计工期，让这部分内容可以直接输出结果。但是，即使是搭配了 design.md以及一些基础的组件库要求，效果依然不理想。
最主要的问题还是存在于风格稳定性和 AI slop 的问题。这也是现在很多 AI 设计工具在已有项目上的最大困境，因为上下文不足导致仅仅适合 0-1 的新项目，让设计规范、组件库本身就基于现有的 AI 平台搭建，而不是迁移到 AI 平台，即使有 design.md和组件库导入的加持，依然无法达到可以落地的设计效果。
通过以上的尝试，我们最终得出结论，对于这种设计文件，目前的 AI 能力还不具备完全自动化的能力，更需要让设计师人工设计好模块化结构让 AI 进行组装。
设计实践
回归 Figma 设计资产
我们最终还是回到了使用 Figma 绘制 UI 的方式，但是颇有不同——本次设计更加专注模块化的复用能力，例如上传模块、标题模块等等。
经过几次迭代反复推演，我们最终沉淀出了一整套 UI 业务组件。
除此之外，为了进一步覆盖业务组件模块无法覆盖的个别场景，我们还提供了一套 design.md 文件，利用 Codex 和 Figma MCP 输出，最后再由设计师进行校准，包含了设计变量样式、组件介绍等信息。
但是，这仍然没有结束。虽然我们解决了 AI 如何介入的问题和抽离模块的问题，但是，我们还有 2 个问题没有解决，AI 如何理解并进行拼装这些模块以及大量的视觉物料该如何规范标准化生成。
AI 标注文档
针对 AI 如何理解的问题，之前制作的 EDW 组件库的 API 介绍 skill 给了我们启发，我们打入了一个 markdown 文件，用于介绍小工具业务下的 UI 界面的组件有哪些，用于什么，该位于哪里，主要包含以下内容：
组件名称：用于和 AI 对齐组件叫法，高效协作；
组件描述：用于简要说明该组件的用法和使用场景；
布局说明：说明基础布局要求，例如该组件padding 和 magin 值等。
利用这个文档，我们可以保证小工具的 UI 在实际的 AI coding 过程中一定会使用组件，但是，无法确保组件被按照合理的顺序和排版布局，这时候就需要对 design.md 做出进一步更新。我们额外增加了页面模板内容，甚至与开发人员协作，把布局模板的 html dom 代码打入design.md文档，经过实际测试，我们发现效果显著。
但是，目前的视觉资产物料依然是由设计师提供，能否将这一步骤也进一步 AI 自动化呢？
视觉资产生成提示词沉淀
在项目过程中，Openai 发布了目前最强的生图模型 GPT image 2，借助其强大的生图能力，利用规范的提示词模板出图是一个可行的技术方案。
经过研究，我发现 Codex 已经可以进行比较高效的提示词反推工程，这套工作流程我还专门写了博客沉淀：一个参考图生成标准提示词模板。利用这种方式，我们沉淀了诸多提示词内容，包括视觉图标、背景等等。
门禁检查机制
现在一套流程已经完全通顺了，组件完成后，也可以几乎不需要设计师手动绘制 UI 参与这个过程，而且开发也可以几乎完全借助 AI 完成小工具的前端开发工作。但是，我们在实际过程中还是发现了问题，即使人可以避免过多运营位置等比较违背常规设计原则的问题，但是 AI 往往频繁的输出中出现了“漂移”现象，开始“自作聪明”的发挥一些本不需要的内容，导致UI 的设计完成度反而下降了。
我们最终发现，检查机制是必要的，我们在项目中尚未引入一种可以减少人工成本的检查机制存在。但问题也接踵而至，我们该检查哪些内容？
我们梳理了一下现在 AI 常见的诸多错误类型，发现主要可以分为以下几种：
过多的运营位展示，一个页面极限情况甚至多达 5 处，严重影响了用户体验；
未覆盖到的组件没能追随现有的视觉样式风格和规范；
部分页面的异常状态 AI 开始逐渐缺失，真本应是 AI 擅长的能力。
基于此，我们制作了一个 EDR（Esign design rules）skill用于检查最终的输出结果，其会分析基础的界面点击按钮、关键操作是否符合要求，同时关注上述的三个问题是否出现，并且根据问题的严重程度给出 3 个级别的评估标准：
blocked：禁止使用，即触犯了严重的边界问题，例如运营位超过 2 个，样式开始出现“自由发挥”的全新变量和样式或是没有覆盖全部异常状态；
warning：警告说明，一般是一些交互原则上的错误，但是不致命，例如按钮的位置不够显眼等，属于可以考虑后续慢慢迭代优化的问题；
suggestion：建议优化，一般是一些小细节问题，例如 banner 可以更加突出文案等，属于可以慢慢优化或是暂时忽略的无关问题。
利用这套门禁 skill，我们再次测试下来发现问题已经明显得到解决，基础原则性问题再也没有出现，PLG 小工具业务可以真正进入 AI Vibe Coding 阶段。
复盘总结
本项目陆陆续续开展了近1 个月的时间，这主要是因为现在团队还处于摸索流程的探索阶段，但是随着后续不断摸索到正确的路线，开发速度还会进一步提升。
在这个项目中，我们把一个简单的运营项目拆分成了 3 个步骤执行：
设计资产沉淀；
视觉资产标注和AI 设计规范输出；
门禁检查机制。
利用者一套完整额机制，我们成功把设计从一个运营需求中抽离，更专心放在实际的用户体验和交互设计上，同时节约大量的前端样式还原时间成本，让需求迭代速度提升超过 50%。
在本次项目中，我有了一些新的在 AI 时代下设计的新理解。
旅程和行为梳理变得尤为重要
AI 擅长的是执行代码，而不擅长确定用户该做什么，怎么做。这就需要产品经理和设计师一起构思好，用户要先做什么、后做什么，以及如何触发，当用户旅程被确定，AI 就可以先把流程跑通（这一直是最重要的）然后再做体验优化。
组件库基建是设计为 Harness 重要的支撑
我在曾经写过的 Harness 笔记（链接：https://harness-learn.pages.dev/）中说过，Harness 是为 AI 提供一个可以稳定运行的环境。而设计组件库、设计系统就是设计师为 Harness agent 时代提供的重要支撑。
如果可以把组件库设计和开发完美对接好，并且为 AI 提供足够的 API 和 props 信息，这样就可以更精确的还原设计稿，甚至在一些要求“不那么高”的页面搭配 design.md 直接出图，针对这个部分，我也专门写过一篇博客分享：如何 Vibe coding 自己的精致产品和网站。
检查机制的重要性
我们在项目初期因为主要是人工判断参与的原因导致我们忽略了 AI 工程的自检测问题，导致在输出国一段时间后，AI 开始漂移。AI 往往会受到上下文压缩、注意力丢失等问题的限制导致会丢失一些细节，因此我们必须利用 skill 规范化 AI 的自检工作，以一定的 token 和时间节约更多改版时间，这是经济和核算的。
75 次点赞
今天可以点赞一次
