The Best Proof Is a Working Tool
前四篇都在思考。这一篇是动手。谈论「设计师要理解技术底层」，最有力的证明不是一篇文章，而是一个真实可用的工具。这个项目记录了从提炼痛点、选题决策到 Vibe Coding 开发的完整过程——以及一个对「设计师究竟能做什么」的亲身验证。
Vibe Coding 不是逃避技术，是以设计思维驾驭技术——不需要懂语法，但必须懂输入输出逻辑
最难的不是写代码，是想清楚「什么值得做」——痛点密度决定工具的生命力
Skill 是新时代的最小可交付产品：比 App 轻，比想法重，比文档可验证
Alan Kay 说，「预测未来最好的方式是发明它」。在 AI 工具链成熟之前，设计师和技术之间隔着一个需求传递的漏斗——从洞察到落地，中间要经过文档、评审、排期、实现，每一步都在消耗信息密度。
Vibe Coding 的出现，本质上是把「想法到原型」的路径压缩到了一个人可以独立完成的范围内。不是说每个设计师都要成为工程师，而是那些最贴近用户问题的人，现在有能力直接把解决方案造出来——无需等待，无需翻译，无需妥协。
这件事的意义不只是效率，而是认知的改变：当你亲自构建过一次，你对「可行性」的判断就永久升级了。你不再需要猜工程师会说「这个要多久」，你会知道哪里是真正的约束，哪里只是没人想过怎么做。这是设计师能力体系里无法通过阅读习得的一层——只能通过动手获得。
从设计师日常工作中提炼出 5 个高频痛点方向，核心判断维度是：痛点密度（多少人真的很痛）× 可行性（当前技术能做到多好）× 最小可用产品的定义清晰度（能不能在一个 Skill 里表达完整价值）。点击查看每个方向的分析：
最终选择了「走查验收工具」——原因很直接：走查是设计师最高频、最耗时的日常之一，每次上线前都要反复经历；而这件事的输入输出定义极其清晰，正好是设计师最擅长的——输入 Figma 链接和实现页面 URL，输出交互差异报告和状态覆盖缺口，这个价值闭环在一个 Skill 里就能完整表达。
构建过程用的是 Vibe Coding 方式：描述需求 → AI 生成初版 → 在真实场景测试边界（「如果某个组件状态在 Figma 里是隐藏图层怎么识别」）→ 根据边界案例调整 Prompt → 再次测试 → 循环。整个过程迭代了 12 次，其中 8 次是 Prompt 优化，4 次是输出格式的重新定义。没有一行代码是我逐字手写的。
最大的收获不是这个工具本身，而是这个过程让我彻底理解了为什么 Prompt Engineering 是一种设计能力：它要求你精确定义输入、输出、边界条件和兜底逻辑——和写交互文档本质上做的是同一件事，只是受众从工程师变成了模型。当你这样理解它，你就不会再觉得「写 Prompt」是程序员的工作了。
"The best way to predict the future is to invent it."
— Alan Kay · 不是所有想法都值得实现，但最有价值的想法往往只有在实现之后才能被真正理解。造出来，才知道它到底是什么。这不是一个完美的产品，但它证明了一件事：当设计师愿意走出 Figma，Vibe Coding 这条路是真实可行的。你不需要从零开始学编程，但你需要理解输入输出的逻辑、理解边界条件的处理方式、理解为什么某个 Prompt 的效果比另一个好——这些恰好是每个好设计师本来就在做的事情。能力从来不是凭空增加的，只是换了一个表达的媒介。