DEV Community: yi shen

How to build a consistent SVG family from a product brief

yi shen — Mon, 13 Jul 2026 01:00:23 +0000

Product teams rarely need one isolated illustration. A landing page may need a hero graphic, a dashboard needs empty states, and documentation needs small diagrams. If each asset comes from a separate search or prompt, the line weights, colors, and shape language drift quickly.

The fix starts before generation. Write a short asset specification that answers four questions:

What idea must the graphic explain?
Where will it appear and at what approximate size?
Which visual rules should every asset share?
What details would become unreadable at the final size?

A useful brief might say: "An empty state for a deployment history panel. Show a small server rack and one waiting status light. Use simple geometric forms, two stroke widths, rounded corners, and a muted blue accent. The image must remain clear at 320 pixels wide. Do not include text."

That prompt is specific enough to guide the output while leaving room for interpretation. Once you find a direction that works, reuse the same preset and recurring constraints for the rest of the set. Consistency usually comes from repeated rules, not repeated subject matter.

GlyPho is built around this kind of workflow. It generates editable SVG logos, icons, illustrations, patterns, and other product visuals from prompts. Its presets are intended to keep related assets in the same visual lane, and the exported SVG can move into code, documentation, presentations, or a design file without first being flattened into a bitmap.

Editable output is useful, but it still needs review. Open the SVG and inspect its viewBox, dimensions, paths, fills, strokes, clipping masks, and embedded metadata. Remove unnecessary groups or transforms if they make maintenance harder. For icons, check alignment on the pixel grid at the sizes your interface uses. For decorative illustrations, test both light and dark backgrounds.

Developers should also treat generated SVG as external input. Review the markup before embedding it, especially if the file contains scripts, event handlers, remote references, or unexpected foreign objects. A simple sanitation step belongs in the workflow.

Finally, store the prompt and preset name near the asset source. That small record makes later revisions much easier and gives the next contributor a concrete recipe for extending the family without starting over.

A practical prompt workflow for creating usable product visuals

yi shen — Mon, 13 Jul 2026 00:54:36 +0000

A good image prompt is closer to a small creative brief than a bag of adjectives. That distinction matters when you need an image for a product page, launch post, ad concept, or documentation cover. The result has to fit a real surface, not merely look interesting in isolation.

I use a four part prompt structure:

Describe the subject and its important physical details.
Name the intended placement, such as a landing page hero or square social post.
Define composition, lighting, and background in plain language.
State what should remain absent from the frame.

For example, "A compact mechanical keyboard with cream keycaps on a pale gray desk, photographed at desk height, soft window light from the left, open space on the right for a headline, no hands, text, or extra accessories" gives the generator decisions it can act on. "Beautiful premium keyboard photo" leaves most of those decisions unresolved.

Reference photos help when the subject has details that prose cannot describe efficiently. A product reference can establish shape, color, and proportions. A separate composition reference can communicate camera angle or spacing. Only use material you are authorized to upload, and check the generated image carefully before publishing it.

Muse Image puts text to image and image to image creation in one browser workspace. It supports prompts and reference photos, with settings for aspect ratio and output quality. The site positions the tool around product shots, social graphics, ads, thumbnails, and concept art. That makes it useful for testing a visual direction before committing time to a full photo shoot or detailed illustration.

Iteration works better when you change one variable at a time. Keep the subject and composition fixed while testing lighting. Then lock the lighting and adjust the background. Save the prompt beside the exported file so another person can understand how the image was made.

Before shipping, inspect logos, labels, hands, reflections, repeated objects, and small geometry. AI output can look convincing at thumbnail size while containing obvious mistakes at full resolution. Treat generation as the first draft. Crop, retouch, add real typography in your design tool, and verify that the final asset fits the dimensions of the page where it will appear.

当你的产品需要 50 个图标，但只剩两天：SVG 资产的工程化生成思路

yi shen — Fri, 10 Jul 2026 07:00:00 +0000

当你的产品需要 50 个图标，但只剩两天：SVG 资产的工程化生成思路

问题背景

很多独立开发者和小型团队都会遇到一个尴尬的时间点：产品功能已经完成，设计稿也基本定型，但资产（icons、插画、引导图）还停留在"先用占位图顶上"的阶段。等到上线前两天，PM 在群里说"图标统一一下吧"，设计师说"排期满了"，最后这个活往往落在工程师自己头上。

如果走传统流程：用 Figma 画、导出 PNG、再逐个替换，工作量随图标数量线性增长。更麻烦的是，设计师给到的 PNG 之后想改颜色或加 hover 状态，只能再让设计师改一次。

这篇文章记录一个更轻量的思路：用可编辑的 SVG 资产作为产物的图形层，让前端可以自己维护一份"图标族"，在产品迭代中持续可用。

核心思路

把图标当作"代码资产"而非"图片资源"来管理。SVG 在这一点上有天然优势：

文本可编辑：颜色、描边、填充都是属性，改起来不需要重出图
可被脚本批量处理：比如统一调整所有图标的描边宽度
体积小：相同视觉密度下，SVG 通常比 PNG 小一个数量级
可访问性友好：可以加 `

How I share AI-generated HTML previews without setting up a repo

yi shen — Wed, 08 Jul 2026 07:39:50 +0000

When an AI coding session generates a single HTML page, prototype, report, or dashboard, I usually do not want to create a repo, wire up CI, or configure a full static host just to show the result to someone.

My current workflow is:

Ask the coding agent to generate browser-ready output.
Build the frontend if it is React, Vue, Vite, Next static export, or another framework.
Upload the dist, build, out, a zip, or a single .html / .md file.
Share the live preview URL.

PreviewShip is useful for that last step: https://previewship.com/

The important detail is that it expects browser-ready output. For framework projects, run the build first and upload the generated folder. For one-off AI artifacts, a standalone HTML or Markdown file is enough.

This is mostly a small workflow improvement, but it saves time when you need a review link for a teammate, a client, or a quick QA pass.

这个 skill 有点意思，当你不知道动效如何描述的时候，使用这个 skill 告诉你动效如何描述。

yi shen — Fri, 03 Jul 2026 08:01:54 +0000

分享一个最近用着很顺手的小工具：skills。

做产品的时候最怕的就是「这个动效怎么说、怎么定」——给设计师写「弹一下」「再快一点」基本等于没说。skills 把常见的动效用统一的 token 描述出来，比如 ease-out、spring bounce、duration scale 这些，写在设计稿和代码里都能直接对齐。

最实用的几个场景：

和设计沟通时直接说「用 B2 的 spring」，不用反复对参考视频
前端可以照着 token 还原，跨设备不会偏
团队新人看一套表就能上手，不用再问「这个缓动到底是多少 ms」

它不是教你怎么设计动效，而是给你一套「动效语言」，让团队在同一个词表里聊。

仓库在这里 👉 https://github.com/emilkowalski/skills

动效设计 #设计系统 #前端开发

用一套 Prompt 生成可编辑 SVG 资产：把图标设计从"画完还要改"变成"改完还能用"

yi shen — Fri, 03 Jul 2026 06:32:29 +0000

用一套 Prompt 生成可编辑 SVG 资产：把图标设计从"画完还要改"变成"改完还能用"

很多前端在赶版本时会遇到一个尴尬场景：设计稿里 20 个图标，落地到代码时发现其中 5 个尺寸不对、3 个颜色要随主题切换、2 个需要在 hover 状态再变一次。拿到的是 PNG/JPG，处理方式要么让设计重出，要么自己拿 SVG 路径硬改——前者排队等资源，后者翻 Figma 找原始节点。

更系统的问题是：当一个产品需要"视觉语言一致"的一组图标或插画时，单张生成和"成系列生成"是两件完全不同的事。单张可以靠运气；成系列需要 prompt、风格预设、导出格式三个变量同时被控制住。

一种更省事的做法：风格预设 + 可编辑导出

最近在试 GlyPho 这类工具，它的思路是把"成系列 SVG 资产"拆成两件事：提示词质量决定构图，风格预设决定统一性。例如选 Minimal Outline 后，同一组 prompt 输出会是同一描边粗细、同一圆角半径、同一画布尺寸的图标；选 Notion Style 则会切换到手绘感、双色填充那一类。

这里的关键不是"AI 生成图片"本身，而是 SVG 仍然是矢量、可编辑、可被项目直接引用。导出的不是"图片文件"，而是带节点结构、可在 Figma / Illustrator / VS Code 里继续改的源码。

一次实战：以"设置类图标组"为例

我需要为新功能的设置面板准备 8 个图标：账户、安全、通知、外观、隐私、备份、集成、关于。

第一步：先写 1 个 prompt，把握住风格基线。
例如：

minimal outline icon, single stroke, 24x24 viewBox, no fill, 
rounded line caps, neutral gray stroke, on transparent background

第二步：用同一 prompt 模板生成其余 7 个，只替换主体词。
账户、通知、安全、外观……每张图都用上面的句式，只把最后的对象换掉。这是保证"系列感"最容易被忽略的一步——很多人每个图标单独写 prompt，结果每张图的描边、留白、圆角都对不齐。

第三步：导出 SVG 后做轻量校验。
可以用一条 grep 快速检查 viewBox 是否一致：

grep -h 'viewBox' *.svg | sort -u

如果输出超过一行，说明有图跑出了预设的画布，要么是 prompt 写漏了关键词，要么需要重跑一张。

第四步：把它接到设计 token。
把 stroke、stroke-width、fill 替换成 CSS 变量（例如 var(--icon-color)），图标就具备了主题切换能力，不用再为深色模式出第二套图。

一些踩坑点

Prompt 写得太满反而难统一。 风格词堆得越多，单张图可能更"好看"，但系列之间越难对齐。保持句式固定，比堆形容词更有效。
viewBox 不一致是最常见的隐性 bug。 一个是 24x24、一个是 32x32，CSS 里设 width: 1em 视觉上就完全错位。
AI 生成的 SVG 偶尔会有未闭合的 `或冗余transform`。 建议过一遍 svgo 之类的工具再做提交。
版权与商用。 用 AI 生成时，确认所用平台对产出物的商用授权条款。GlyPho 这类工具一般允许商用，但团队内仍建议把这点写进设计 SOP。

这套流程适合谁

独立开发者：产品发布前需要一套"看起来不业余"的图标，但又不想专门雇插画师。
小团队前端：当设计资源排队时，能在半天内交付一组风格统一的占位资产，后期再替换也方便。
写技术博客 / 做开源项目的人：README 和文档需要配图时，一致的视觉语言比"每张图风格迥异"更显专业。

可以带走的清单

先固定 1 句 prompt 模板，再批量替换主体。
选一个风格预设（Minimal Outline / Duotone / Notion Style 等），整组都跑同一预设。
导出后用脚本检查 viewBox 一致性。
用 CSS 变量替换 stroke / fill，为多主题预留空间。
跑一遍 svgo 清理冗余节点。

接下来你可以做的

挑你项目里最常用的 5 个图标（例如"新建 / 删除 / 设置 / 搜索 / 用户"），按上面的模板在 glypho.app 上跑一组 Minimal Outline 的 SVG，导出后接到你现有的设计 token 里。一杯咖啡的时间，就能验证这套流程在你自己的项目里是不是真的省事。

为什么你的产品 Logo 总是改到第八版：一个被低估的设计工作流问题

yi shen — Mon, 29 Jun 2026 09:04:50 +0000

上周帮一个独立开发者朋友看他的 SaaS 项目落地页，他给我看了一版 Logo，然后说："这是第八版了。"我问他前七版的问题出在哪，他说："每版都说不上哪里不对，但就是不像我的产品。"

这其实是一个非常典型的问题，而且不是审美问题。

设计资产为什么总是"差一点"

大多数独立开发者和小型团队在做产品视觉资产时，会卡在同一个地方：他们知道自己想要什么感觉，但不知道用什么词向设计师（或 AI 工具）描述这种感觉。

常见的描述是这样的："简洁一点""专业一点""不要太严肃""有点像 Notion 那种感觉"。这些词对设计师来说是模糊指令，对 AI 来说几乎等于噪声。结果就是反复生成、反复调整、反复不满意。

真正有效的设计描述，应该包含三个要素：

使用场景：这个 Logo 会出现在哪里？落地页 hero 区域？favicon？应用图标？
风格方向：是线条图标（Line Art）、双色填充（Duotone）、贴纸风格（Stickers），还是 Notion 那种柔和手绘感？
核心元素：你希望它传达什么概念？是速度、连接、工具属性，还是品牌名首字母？

把这三点写清楚，设计师或 AI 工具的输出命中率会高很多。

一个可复用的工作流

我后来给那个朋友推荐了一个流程，他用了一晚上就定稿了：

第一步：先确定风格方向，不要先画形状。 在动手之前，先去 Dribbble、Product Hunt、甚至竞品的落地页上截图 10 个你"觉得对"的 Logo。把它们放在一起看，你会发现自己的审美偏好其实非常一致——可能是都喜欢圆角、可能都偏好单色线条、可能都讨厌拟物化。这个集合就是你真正的"风格指南"。

第二步：用风格标签而不是形容词来描述。 不要说"简洁现代"，说"Minimal Outline + 单色 + 几何形"。风格标签比形容词精确得多，因为它们对应的是具体的设计语言。

第三步：先做小尺寸测试。 Logo 好不好，看的不是 1024x1024 的大图，而是 32x32 的 favicon。如果在小尺寸下还能识别核心元素，这个 Logo 才是合格的。

第四步：生成多版本横向对比，不要逐个调整。 这是最容易踩的坑：拿到第一版就开始改，改完发现还不如第一版。正确做法是一次性生成 5-8 个方向，整体对比后挑一个最接近的再迭代。

第五步：把 Logo 放进真实场景再看。 单独看 Logo 觉得不错，放到落地页上可能完全不对。一定要在 hero 区域、按钮上、加载动画里都测试一遍。

用 GlyPho 做的一次实验

我自己在测试一个工具时用了这个流程。需求很明确：给一个开发者工具产品做 Logo，要 Minimal Outline 风格，核心元素是"代码块 + 闪电"（表示快速执行）。

我用的是 GlyPho（https://www.glypho.app/），它的好处是不用从零开始描述，而是先选风格方向（Minimal Outline / Notion Style / Stickers / Duotone / Line Art），再写提示词。这个顺序很关键——先锁定视觉语言，再调整内容，效率比直接写一长串形容词高很多。

我一次性生成了 6 个版本，挑了 2 个最接近的微调，最后定稿用了大概 20 分钟。导出的 SVG 直接可以用，不需要再转格式。

这个流程的关键不是工具本身，而是"先选风格再写描述"这个顺序。如果你还在用"帮我画一个简洁现代的 Logo"这种 prompt，输出不满意是必然的。

读者可以带走的三个判断

如果你的 Logo 改了三版以上还没定，问题不在执行，在描述。 回去检查你的需求描述是不是只有形容词，没有风格标签和使用场景。
小尺寸测试比大尺寸评审更重要。 一个在 32x32 下看不清的 Logo，在任何场景下都不会好用。
批量生成 + 横向对比，比单点迭代高效得多。 不要在第一版上死磕，退出第一版，重新生成一批。

如果你现在的产品视觉资产还卡在"差不多但不满意"的状态，试试上面这个流程。大概率问题不在你的审美，在你的描述方式。

Daily content: 2026-06-29

yi shen — Mon, 29 Jun 2026 09:00:00 +0000

最近重构一个数据同步组件，翻旧代码才发现缓存层是 Map + SharedPreferences + 手写文件 IO 混着用的，索性把本地缓存方案重新梳理了一遍。

如果你的需求只是缓存接口响应几分钟、存点用户配置、或者离线保存草稿，选型其实不复杂。真正麻烦的是"既要又要"的场景：既要快、又要持久、还要监听变化、还得控制内存。

三个常见方案的真实体感：

内存缓存（Map / LRU）：最快，进程一杀就没。我之前把 token 放进内存 Map，应用被系统回收后用户重开就要重新登录，体验很差。

SharedPreferences / UserDefaults：简单 KV 存配置够用，但存大对象会卡 UI，频繁写入有性能问题，key 散落各处也不安全。

文件缓存（JSON / Room / SQLite / CoreData）：结构化、可查询、容量大。代价是 schema、迁移、版本兼容都得自己管。

我选型时会问自己三个问题：

数据丢了用户会不会感知到？会 → 必须持久化；不会 → 内存就行
有没有结构化查询需求？有 → 文件/SQL；没有 → KV 即可
写入频率高不高？高 → 避开 SharedPreferences，考虑批量写或内存层

几个容易踩的坑：把缓存当数据库用（缓存应该有 TTL，能容忍丢失）、忘了做容量控制（几个月后用户手机存储报警）、UI 线程同步读 SP 在老 Android 上会 ANR、不是所有本地数据都需要加密。

我的结论：缓存没有银弹。先想清楚数据的生命周期，比选哪个库重要得多。下次给项目加缓存前，建议先别急着换库，把现有数据分类一遍：哪些是配置、哪些是临时、哪些是业务数据。分类清楚后，技术选型自然就清晰了。

如果你也在重构老项目的缓存层，欢迎交流踩过的坑。

Product content: glypho.app

yi shen — Mon, 29 Jun 2026 08:30:31 +0000

用 AI 生成视觉素材时，我反复踩过的几个坑

最近在做一个独立产品，几乎每天都要出 logo、icon、插画。我试过用 AI 直接生成图片素材，结果发现这条路没有想象中那么顺。把过程写下来，给同样在用 AI 做视觉的独立开发者一点参考。

我原本以为能怎么用

最开始的设想很简单：写一句 prompt，让 AI 直接出整套视觉系统，包括 logo、空状态插画、营销图、社交媒体头图。几秒钟搞定，剩下时间专心写代码。

实际跑下来发现三个问题。

第一，分辨率对，但风格不可控。 AI 出的图看着像那么回事，但风格飘忽。这次给的是扁平，下次就变成了拟物风。整套素材放在一起，视觉完全不统一。

第二，输出格式不对。 产品里要嵌 SVG 图标，AI 出的 PNG 在 Retina 屏上糊，强行放大还出现锯齿。重新画矢量又回到原点。

第三，迭代成本高。 想改一个颜色，prompt 重写一遍，结果往往面目全非。

后来怎么解决

我换了一个工作流：先确定视觉方向，再批量出矢量素材。

关键点是把"风格"和"内容"拆开。风格先固定下来，比如选定 Notion 风格、极简线描、双色调这几种方向之一，再在这个方向里换不同的图标或插画主题。出来的素材统一度高，组合到产品里不会打架。

另一个关键是输出必须是 SVG。SVG 可以直接塞进 React 组件，也可以随时改颜色和尺寸，不用回去找源文件。

我自己在用 GlyPho 处理这一步。它的好处是风格预设比较明确，Minimal Outline、Notion Style、Line Art 这些方向是固定的，生成出来的素材在产品里拼起来不会违心。颜色变量也能直接在 SVG 里改，省掉一次重生成。

给独立开发者的具体建议

如果你也在用 AI 做视觉素材，有几个原则可以参考：

先定风格，再填内容。 不要一上来就让 AI"帮我设计一整套"，先把视觉方向锁死。
矢量优先。 产品里能塞 SVG 就别用位图，后期改色和适配屏幕都更省事。
一次只改一个变量。 想调颜色就只动颜色，别把 prompt 整体推翻重写。
保留风格示例。 每次生成后挑一张满意的留下来当锚点，下一轮用"参考这张的风格"来约束。
把视觉系统当成代码管。 命名、分类、版本都按代码资产来管理，不要散落在聊天记录里。

可以带走的一个判断

AI 生成视觉素材最大的问题不是"能不能生成"，而是"能不能用"。当你在产品里拼素材的时候，风格统一和格式可用比生成速度重要得多。工具选型的标准应该是"我能不能把输出直接放进产品"，而不是"我能不能在 5 秒内拿到一张图"。

下一步可以做的事：打开你现在在用的 AI 视觉工具，试着锁定一个风格方向，生成 5 个同主题的图标，看它们放在一起是否协调。如果不协调，问题大概率出在你没有把风格作为约束条件写进 prompt 里。

asdasdsa

yi shen — Mon, 29 Jun 2026 08:18:05 +0000

asdasdasdasdasdasd