做过技术负责人的人,大概都懂那种"这次肯定不一样"的幻觉。我当了这么多年CTO,每次遇到新工具都以为找到了银弹,结果栽了无数次跟头。最近琢磨"Claude Design"和"Open Design"这对概念,让我重新检视了一堆以为早就想明白的事。最反直觉的发现是:设计没有绝对的好坏,只有商业策略和项目成熟度的匹配问题。
这事我在自己频道录了期视频,因为发现网上讨论都浮于表面。核心矛盾其实是创作自由与控制权的博弈,以及这种博弈怎么落到日常写代码、画界面的具体场景里。
设计 saga:一切从哪开始
聊网站设计,普通人先想的是视觉、配色、字体。但工程师视角完全不同——我看的是架构能不能扛住增长,后期好不好维护。正是在这个维度上,我区分出了两种对立路径。
所谓"Claude Design"(我自己起的名),指那种封闭式的做法:框架和工具给你定死大量规则。典型代表是高度特化的拖拽建站工具,或者大厂那套 proprietary 的设计系统。卖点是快和一致,拖拖拽拽就能上线。我承认这很诱人,但代价是什么?
"Open Design"则是彻底开放。纯 HTML、CSS、JavaScript,最多加个 React 或 Vue 这类前端框架,但没有封闭系统的枷锁。对开发者来说,这是张白纸,控制权完全在自己手里。创意没有天花板,但从零搭建或整合各种组件的责任也全得自己扛。
我的实验与现实的毒打
两种路线我都用真实项目测过。Claude Design 的初期速度确实离谱——快速原型、简单企业官网,品牌视觉规范已经定死、不想搞大创新的场景,它飞一样快。一致性有保障,团队学习成本也低。但问题来了:客户突然要一个系统没预设的功能,那就是地狱。你花在绕开限制上的时间,比从头写还多。更糟的是代码变成一坨补丁,难以维护,更难扩展。
Open Design 是我的舒适区。复杂界面、精细动画、真正能留住用户的交互,这种自由度无价。我能优化到像素级的性能,对接任何 API,可维护性也强得多——因为控制权在我手里,不在某个供应商那。代价是时间:开发时间、设计时间、
热门跟贴