即便有，个人也很不看好。

1 、商品功能需求其实是不具有普世意义的。一个客观的产品特性，既可以包装为优势，也可以包装为缺点。全看话术和宣传引导。
2 、国内的消费者没有订阅消费报告的消费习惯。
3 、带有“好价”属性的商品评测，有效周期太短。

这几点共同导致了高质量的“好价”商品推荐做不下去。

10 年这种数额，找个律师做咨询最合适。
而且从公司这种态度来看，你们也没必要留一线了，可以直接拼 2n 。

是指摇杆的选购？拳霸就可以。目前 PC 摇杆的门槛很低了，也很成熟，说白了就是三和 /清水的摇杆+三和按键+逻辑板组装，拆开之后你就发现简单到你自己都能 diy 。

清水和三和的区别是清水的挡片更圆滑（你可以理解为 360 度旋转的时候卡顿感更小），而且回弹力更大，更沉，三和指向性更强（适合需要精准输入），更轻。如果你拆开就能发现，清水的摇杆限位器有弧度，弹簧更粗壮。三和则是彻彻底底的方形。

按键目前普遍是三和。触发键程极小，轻轻手一放就触发了。

小时候惊讶于 FC 上 1943 的画面革新表现，和 1942 相比不亚于换代。
帧数、音效、配乐、特效、手感、系统，都是质的提升。

@magic3584 #4 京东的真正自营的“鲜超”是七鲜。只要不是七鲜里买的，必然是从其他店铺、供应商进的，自营只是渠道自营。

生鲜不像电子产品，如果走电子产品自营的采购》入库》出库》配送，损耗太大，不能这么玩。

估计是这个店铺又签了京东，又签了每日优鲜。

相对简单的报价方法是“人天”。
既每个人，每天的工作量，多少钱。

这样既交代了 deadline ，又交代了价格。同时还能抵御需求变更导致的劳动力浪费问题。

当你点击识别的时候，显示设备才会发出声音信号。
跟过去微信玩的声波加好友差不多。

这种 app 有一个天然壁垒：记录者要单独操作记录，有很大的工作量负担。
所以现在很多多媒体 app 自带类似的功能，比如 iOS 中照片 app 的“回忆”和“精选照片”。

至于说必须要自己操作的话，我认为任何一个 note 类 app 都可以满足需求。
再上升一点可以晋升到 wordpress 这个级别。

刚充卡就容易这样，过段时间就解除限制了。找客服可以，但千万别透露你是跨区使用，透露了秒封。

@06_taro 感谢更正，学习了。

@delectate #25 同意你此楼的观点。不是技术导致实现变烂了，是实现的“人心”（广义上的，包括开发成本、开发能力、市场环境机遇、当前企业的软件工程架构等）变了。

于此同时，相对宽裕的客户端性能，也加剧了开发企业的摆烂心理。产生了相对更不绿色的客户端呈现需求，从而诞生了某些不环保的类似 webview 的 UI 呈现方式。

最后，低门槛的客户端呈现框架，吸引了更多非专业的，非专精的开发者进入客户端开发领域，更加加剧了客户端体验的劣化。

他们共同导致了目前客户端体验的急剧下滑。

@dingwen07 #22
“你不可能要求所有的公司都能开发出像 VS Code 那样优秀的 Electron （或者其他的 WebView ）程序”

这其实是不符合因果逻辑的。只是基于你既有的应用使用体验得出的经验理解。

确实有这种跨平台的 ui 技术之后，客户端的体验更烂了。但这并不是这个 UI 呈现技术本身的问题。
是更多的，非专业的人投入了客户端开发。
同样，我用原生组件如果我有意为之，可以做的比 Discord 更烂。

反之，如果某种 UI 呈现技术不存在，也并不能阻拦客户端劣化的势头，毕竟现在是互联网时代，业务、热度为王。

所以反对某些 UI 呈现的方式，并不能达到“让客户端质量、体验更好”的这个初衷。

头戴式 or 入耳式？
听什么风格？

挑耳机，很大程度上挑的就是品牌的调音偏好。
喜欢听迪曲，我给你推荐 akg 你肯定会疯。

@delectate #5
通读了你的回复，我认为你错位的理解了我的意思。或者说把我错误的归结到了某个刻板标签下。
这里面我觉得有两个点是值得去深刻思考的。

1 、webview ，或者说类似的 UI 框架技术真的会导致客户端性能的“极大"浪费么？（注意，我也认可其会造成浪费，但是否会导致兼容性质的变化？）
2 、UI 的实现方式真的会拉高程序的运行门槛么？或者说降低“极端场景”的可靠性？

我认为这两点的答案都是“否”。确实有应用使用某种类网页的 UI 呈现技术做的很烂，但这并不是 ui 呈现技术的问题。
换句话说，一个纯原生的 app ，依然可以做的很差。

最后就是你个人的论据问题。
“以前一张光碟，650m ，可以装几十个甚至上百个小游戏。现在呢？几十 g 的游戏，蓝光都放不下。”

为何过去的 cd 可以装下好多盗版游戏？因为其一般采取高压缩比+阉割流媒体过场动画的方式。再加上过去素材分辨率低（ ps2 的分辨率是 600*480 ），游戏脚本内容相对少，游戏小是很合理的。
然后就是过去的游戏很多受限于载体的存储空间限制，也都阉割了表现力。（比如最知名的宝可梦初代，为何只有 150 只精灵？因为没地方放了。）
最后，虽然从现在的视角看，当年的 app 做的很克制，且极致。但他们在当年也依旧撑满了当年的客户端性能。

所以“过去的程序对客户端的性能占用更克制”是彻彻底底的伪命题。

我认为从用户角度上讲，ui 的技术呈现方式并不应该被比较，或者说被纳入软件的评价体系。
只要其功能好用，布局合理，性能稳定就好。

足够，客户端编程用 air 正合适。

关键是“度”的问题。
每个人要根据你的既有条件来安排规划楼主所说的 1~5 。
每个人的资源都是有限的，需要在 1~5 中进行取舍。

世界上哪有这么多既要有要。

楼主没有详细描述，不知道目前问题在哪里。
如果可以的话，楼主可以 append 一些详细的问题。