br_wang

@shineit 原来如此。之前几年折腾过一次 xcode 开发，证书这些都要手动弄还挺麻烦的。上个月想写了个 SwiftUI 小应用，又捡起来试了试，发现改善了很多，很多配置都能绑定账号自动处理了，还以为现在普遍都这么使用了呢。

如果付费软件的话，Paste 也不是不行……

现在不都是 xcode 管理证书啥的了么？

不如试下正则替换？
1. herry -> herry2
2. jack -> herry
3. herry2 -> jack

@sinux 烤箱，尤其是柜式烤箱，使用麻烦的就是要预热。不像空气炸锅，随拧随用。

空气炸锅蛮方便的，烤地瓜，烤鸡米花，烤三文鱼，烤烧饼，只要是想保持食物酥脆特性又不想开火，空气炸锅都是好的选择。微波炉不行，微波炉加热出来就塌了。

最近淘宝买了点饼胚，炖点五花肉，想吃时拿出来，空气炸锅、微波炉双开，5 分钟吃上肉夹馍，美滋滋。

微信小程序有 wx.scanCode API ，用的是微信客户端的扫码方案。
所以，搞个小程序？
https://developers.weixin.qq.com/miniprogram/dev/api/device/scan/wx.scanCode.html

如果仅仅是 css 框架，其实还是从开发实现角度来看待这个问题。

设计语言的关注的是系统或应用中视觉传达和用户认知的调和问题。

对于设计语言来说，视觉元素都是表义的，是能够通过组合和重复在用户头脑中建立统一认知的。

认知一旦建立，用户使用产品时的心智负担和学习成本就会大大降低。「绿色的通知就是代表操作成功，红色的说明报错失败了」——不用读具体的提示文案用户也能快速做出判断。

而任何对已建立认知的强行修改都会造成用户认知报错，产生负向情绪 。用户从不会认为是自己认知的问题，而是「这个产品 /功能太沙币了」。

看看 iOS 14 时间应用中 DatePicker 样式使用混乱造成的负向反馈（随便一搜的一条，https://www.reddit.com/r/iOSBeta/comments/he4xul/ios_14_changed_the_datetime_picker_in_the/，现在又回归统一了），

再看看 PS5 强行统一各区圈、叉按键功能在主机圈引发的嘲讽。

所以，当有几十个后台，大几百个页面需求要产出，而这些页面又是下游成百上千员工每天面对几个甚至十几个小时的工作环境时，统一的设计语言就太有必要了。

不光是用户侧的考量，开发、设计、需求三方能否在统一的视觉交互认知下，快速沟通、确认方案，进入实现阶段，对于能效高低至关重要。

「是不是好看」真的不是设计语言的核心，锦上添花还差不多。

@whywaoxaks 那到确实是。我自己这边通常就 chrome+几个编辑器，还没遇到那么多问题。