我不是设计师。
我是一个长期写代码、做产品原型、写工具链的开发工程师。也正因为这样，我特别能理解非设计同学遇到视觉需求时的尴尬：产品要一个原型，运营要一组卡片，汇报要一套 PPT，老板说“做得高级一点”，但你脑子里只有一句话：我该从哪儿开始？
直接让 AI 做，确实能很快出图、出页面、出 PPT。
问题是，它经常交出一种“看起来完成了”的东西：风格千篇一律，产品图像是编的，页面只有理想状态，移动端文字挤在一起，按钮点了也没有反馈。对设计师来说，这些问题也许一眼能看出来；但对非设计同学来说，最麻烦的是你不知道哪里不对，只觉得“不太像真的”。
所以我做了一个 Skill，叫 K叔Design。
它不是为了替代专业设计师，也不是教大家背一堆“高级感、极简、未来感”的设计词。它更像一个写给非设计同学的视觉交付助手：把模糊需求拆成流程，把设计判断变成检查项，把最后的产物变成能打开、能截图、能导出、能交接的东西。
1、Skill简介
Kz-Design 是一个面向非设计同学的视觉产出 Skill。
它适合产品、开发、运营、内容同学使用，尤其适合那些经常需要临时做 HTML 原型、Web 页面 Demo、PPT、信息图、社交卡片、公众号封面、教学说明页，或者需要评审一个页面“哪里像 AI 做的”的人。
它解决的问题很直接：当你不擅长设计语言，也没有完整设计团队支持时，如何把一句模糊需求推进到一个更像真实交付物的视觉产物。
我希望它交出来的不是“看起来有设计感的一张图”，而是一组可以复查的文件，比如：
-
index.html -
screenshots/ -
exports/*.png -
exports/*.pptx -
design-brief.md -
ui-spec.md -
implementation-handoff.md -
validation-notes.md
换句话说，它把专业设计里很多容易被忽略的底线，用开发同学更熟悉的方式表达出来：路径、状态、验证、导出、交接。
2、使用场景
我做它，主要是因为自己在开发和协作里反复碰到几类场景。
第一类是产品原型。比如一个开发或产品同学想快速做一个 SaaS 后台首页，用来对齐需求或演示流程。现在的 AI 通常不会离谱到把后台做成营销官网，但很容易做成一套“看着像 dashboard”的通用模板：顶部几张指标卡、中间一张趋势图、下面一张表格。第一眼没毛病，细看就会发现业务优先级不清，筛选和批量操作只是摆着，空状态、错误状态、权限差异也没有交代。非设计同学看着会觉得“差不多能用”，但拿去讨论真实流程时，很快就会卡住。
第二类是内容视觉化。比如把一份 Markdown、技术报告或复盘文档做成 PPT、信息图、教学页。这里最怕的不是不够漂亮，而是把网页思路硬搬到幻灯片上，一页塞满文字，最后既不能演示，也不能导出成可编辑文件。
第三类是社交卡片和封面。运营或内容同学经常要做小红书图文、公众号封面、平台缩略图，但这些东西有比例、安全区和阅读距离。不会设计的人最容易犯的错，是把整段话塞进图里，然后靠缩小字号硬撑。
第四类是设计评审。很多页面的问题不是“颜色不好看”这么简单，而是信息层级、素材职责、交互反馈、响应式边界和 AI 味一起出了问题。以前我得在提示词里一条条提醒 AI：别用紫蓝渐变，别堆圆角卡片，别加无意义数据，别乱画产品图。现在这些都写进了 Skill 的规则里。
做出来之后，最明显省掉的是反复补充约束的动作。
以前我要在提示词里反复说：
-
先确认媒介，不要把 PPT 写成网页
-
产品信息要核验，不要编
-
没有真实素材就诚实占位，不要手画假 Logo
-
按移动端检查文字溢出
-
原型要考虑 Loading、Empty、Error、Populated、Edge 五态
-
交付前要截图验证，导出物要检查
-
如果要给开发落地，要写设计交接
现在这些不再靠我临场想起来，而是被拆进了 Kz-Design 的工作流。非设计同学不用先学一套设计术语，也能让 AI 按更靠谱的交付顺序工作。
3、创作过程
这部分是我做这个 Skill 时花时间最多的地方。
一开始我没有想写一个“设计大全”。那样很容易变成一堆风格词：极简、未来感、高级、杂志感、科技感。对专业设计师来说，这些词可能只是起点；但对非设计同学来说，它们很容易变成唯一抓手，最后越写越虚。
所以我把开发里的几个习惯带进了这个 Skill：先分流，再定契约，再处理素材，再构建，再验证。
第一个问题：用户说一句需求时，AI 应该先走哪条路？
所以我先做了路由矩阵。比如：
-
用户说原型、交互 Demo、HTML 演示，就进入高保真原型路径
-
用户说 PPT、Slides、信息图，就进入固定画布和演示节奏
-
用户说小红书图文、社交卡片、公众号封面，就先确认平台比例、导出尺寸和安全区
-
用户说动画、MP4、GIF，就先写时间轴和关键帧
-
用户说 UI 规范、handoff、交给开发落地，就进入设计实现交接
-
用户说“哪里像 AI”“帮我变高级”，就进入设计评审与修复
这一步解决的是“别一上来就写 HTML”。对非设计同学来说，先选对产物类型，比先纠结配色更重要。
第二个问题：怎样让不会设计的人也能避开 AI 味？
我把一些经常翻车的东西写成了硬规则。比如默认不要用紫蓝渐变，不要每个地方都塞图标，不要用装饰性 emoji，不要把 UI 卡片套进页面卡片，不要用无意义数据凑看板，不要手画人物或产品图冒充真实素材。
同时，我把素材分了职责：
-
背景负责氛围
-
截图和预览负责证明
-
图标负责识别
-
装饰只负责节奏
这个写法其实很开发：每个东西都要有职责边界。一个背景图不能抢走主要信息，一个图标也不能替代说明。这样非设计同学不用凭感觉判断“好不好看”，至少能先判断“这个元素有没有用”。
第三个问题：交付怎样才算完成？
这个问题让我把验证写进了 Skill。
正式视觉产物交付前，Kz-Design 会要求做浏览器或截图验证；可交互产物要点过关键路径；Canvas、Three.js、动画类产物要确认非空、取景正确、能动；PPTX、PNG、PDF 这类导出物要检查实际文件、尺寸和可读性。
我还给它设计了默认交付目录。比如社交卡片不是只给 HTML，而是应该有 exports/*.png 和 screenshots/contact-sheet.png；设计交接不是只给截图，而是要有 design-brief.md、ui-spec.md 和 implementation-handoff.md。
这是开发视角下我最在意的一点：一个产物不是“看起来像完成了”就算完成。它要能复现、能检查、能交给别人继续做。
4、使用步骤
调用方式很简单。你不需要会 Figma，也不需要先想清楚“采用什么视觉风格”。只要需求属于视觉产出，就可以直接说目标。
比如你可以这样叫它：
做一个高保真 HTML 原型，主题是 AI 任务管理工具。
也可以这样：
把这份 Markdown 报告转成一套可编辑 PPTX，适合 10 分钟汇报。
或者：
做一组小红书图文卡片，主题是 AI 写作工作流，比例按小红书竖版来。
再或者：
帮我评审这个页面哪里像 AI 做的，并给修复清单。
它大致会按下面的步骤走：
-
识别你要的是原型、幻灯片、信息图、社交卡片、动画、方向探索、设计评审，还是实现交接。
-
锁定执行契约：语言、媒介、输出格式、画布或响应式目标、验证方式。
-
收集事实和素材。涉及品牌、产品、人物、规格等现代事实时，优先核验来源；没有素材就标注缺口。
-
确定设计系统和视觉方向。不是只给“高级感”，而是写清布局、字体、色彩、密度、动效和风险。
-
构建视觉产物。原型要有真实流程，PPT 要有固定画布和演讲节奏，社交卡片要按平台比例和安全区处理。
-
做验证和修复。检查文字是否溢出、交互是否可用、导出物是否存在，最后写入
validation-notes.md。 -
如果要给开发落地，再输出设计交接包。
实际使用时，非设计同学不用把这些步骤都写进提示词。Skill 会根据需求命中对应路径，并把容易漏掉的检查项补上。
5、效果展示
6、Skill 链接
Skill 分享链接：
https://gitee.com/kingzeus/skills
7、总结与思考
做完 K叔Design 之后，我对 Skill 的理解有一点变化。
以前我更容易把 Skill 理解成“能力包”：把一些提示词、工具、参考资料放在一起，让 AI 更懂某个领域。
但这次做下来，我觉得好的 Skill 更像“工作方式的固化”。它不只是告诉 AI 可以做什么，还要告诉 AI 什么时候停下来判断，什么时候必须核验，什么时候可以降级，什么时候需要验证，什么时候不能假装完成。
这个 Skill 目前我最满意的地方，是它把专业开发的工程习惯放进了设计交付里，也把一些设计判断拆成了非设计同学能执行的规则。
我以前对“高级感”的理解也比较模糊。很多时候大家说高级，最后会落到黑金、留白、大字、渐变、玻璃拟态这些词上。但真正做下来，我越来越觉得，高级感不是某一种固定风格，而是一种被约束过的秩序感。
它通常来自几个更具体的东西：
-
信息层级足够清楚，第一眼知道主角是谁
-
画面里每个元素都有职责，不是为了“丰富”硬加
-
字体、间距、对齐和留白有节奏，不靠堆效果制造完成感
-
素材是真实的、克制的，截图、产品图、背景、图标各司其职
-
细节有质感，比如边界、材质、阴影、纹理和状态不是默认值
-
能删掉的东西敢删，能弱化的东西不抢主信息
所以 K叔Design 里没有把“高级感”当成一句魔法提示词，而是把它拆成可检查的动作：先定视觉锚点，再定信息层级；先判断素材职责，再决定背景强度；先检查缩略图可读性，再谈装饰；先确认导出物可用，再说交付完成。
这也是我觉得概念设计很重要的地方。
非设计同学做视觉产物时，经常会直接进入“生成一个页面”或“做一张图”。但很多时候，真正需要先回答的是：这个东西想让人记住什么？它应该像一个工作台、一张研究海报、一份产品发布稿，还是一张可以转发的社交头图？画面里的主角是产品、流程、观点、数据，还是某种情绪？
这些问题其实就是概念设计。
概念设计不是先决定颜色，也不是先挑一种风格，而是先把抽象需求翻译成一个可以讨论的视觉假设。比如“给非设计同学的视觉交付 Skill”，它可以被做成工具界面，也可以被做成设计工作流，也可以被做成一个带冲击力的分享头图。不同概念会带来完全不同的布局、密度、字体、材质和素材策略。
我希望 K叔Design 能做的，就是在 AI 动手之前，先帮用户建立这个“设计读法”：它是什么媒介、给谁看、第一眼看见什么、靠什么证明、哪些东西不能造假、哪些细节必须验证。这样生成出来的东西才不只是“好看”，而是更像一个有明确设计意图的产物。
设计类任务特别容易有幻觉：页面看起来完整，就以为完成了；截图看起来不错，就以为能用；PPT 在浏览器里能看，就以为可以交付。但真实工作里，这些都不够。文字可能溢出，移动端可能乱掉，导出物可能不存在，交互可能点不动，开发也可能不知道该怎么接。
K叔Design 至少在规则层面把这些坑提前写出来了。它不是要让非设计同学替代设计师，而是让大家在没有设计支持、需要快速做出可讨论产物时，不至于完全靠感觉和运气。
后续我想继续优化三个方向。
第一，补更多真实案例。比如典型 SaaS 原型、社交卡片、PPTX、信息图、动画和设计评审的完整产物截图，让非设计同学更快理解它的使用边界，也能看到同一个需求在不同概念方向下会长成什么样。
第二，继续打磨导出流程。尤其是 PPTX、PNG、PDF、MP4 这类文件，不能只在浏览器里“看起来像”，还要保证最终文件真的可用。视觉产物如果不能导出、不能复查、不能交接，它的设计感再强也会停在演示层。
第三，增加更多设计评审样本。很多人并不是缺一个新页面，而是已有页面太像 AI 做的，需要知道问题在哪里、先改哪一处、怎么验证改完了。未来我也想让它更擅长解释“为什么这样更高级”：不是给一个审美结论，而是说清楚层级、密度、材质、留白和素材取舍背后的原因。
如果你不是设计师，但经常遇到“帮我做个好看点的页面”“把这个报告做成 PPT”“这张卡片怎么这么 AI”的需求，可以拿一个真实任务试试 K叔Design。
我也希望大家给我反馈：它的规则是不是太重？有没有哪些场景应该更轻？哪些设计产物最需要补案例？
对我来说，这个 Skill 最想验证的一句话是：
非设计同学也可以借助 AI 做视觉产物，但前提不是多学几个审美词，而是先把设计意图说清楚，再让 AI 按一套可验证的交付流程工作。
