@lisongeee
感谢。目前对前端栈里面的概念还有点模糊，我大概了解你指明的问题所在了。🙏

看到「乘波体」这个概念，总是眼前一亮：真形象啊。

> “知乎体这两年最火热的模式，一种是 『 XX 是一种什么体验』，另一种就是『如何理解 XXX 』。前者迎合消费主义的需求，用来卖货的；后者就是帮你理解世界，把瓜吃上的。”

这不就是人生的意义所在吗？「体验」 vs 「理解」，「感性」 vs 「理性」，说成「卖货」和「吃瓜」有点贬低了。

楼主提到的积分机制，目前看只有对积分「消耗」的介绍，没有「生产」的部分，不完整啊。一套机制，各部分环环相扣，如果不完整就没办法讨论了。

另外，V 站有一些相关的帖子，共享一下：

端午在家，写了一个基于投票机制的自治社区，欢迎大家一起讨论： https://www.v2ex.com/t/685321
“先吃再给钱”的模式，可以用在内容付费论坛中吗？ 说说我的新思路： https://www.v2ex.com/t/710214
刚才刷牙的时候想到一个责任制的论坛的点子，各位看看可行性如何： https://www.v2ex.com/t/763846

@nothingistrue #13
你的方案是不是说给过号一定的延迟时间，而不是说叫了下一个号就立马把上一个算作过号？

@autoxbc #6
你这个是定量的做法，其他的都是大概估摸着。不过方式变化太大了，由商家主导变成了客户竞争竞价了。

@ansonsiva #11 > “过了几个号就再等几桌”
这个方法也算是定量，根据实际超时的情况来确定重叫的间隔，而且完全是商家主导的。

@nothingistrue #13 > “后面正在排队的人，他看到的等待人数，只能不动或者减少，不能增加”
没太看懂。比如一个人拿了 3 号，当前共排了 13 号，当前已经叫到了 7 号，那么这时拿 3 号过号的人又赶回来了，应该把它放到哪儿呢？对于 13 号，它看到的等待人数应该是 5 个(8 、9 、10 、11 、12)，那么 3 号肯定就没办法插到 13 号前面了，相当于它就得重新拿号了。

@sobigfish #8 > “医院号很大的不同是挂号相当于付费预约了，这个只是排队。”
两者的差别有很大吗？是因为排队拿号的成本相对低一些？还是说爽约不来的风险更大一些？感觉应该是后者。我觉得这两者的差别也会影响重新叫号的方式是不是合理。

@kevinlexming 如果导出的格式可以解析，那么导出就相当于备份了吧。一般只有自己不小心误删了某些笔记，才需要再导入这个功能吧。

@owaru
是的是的，就是这样的网站。这 2 个网站偏文字介绍，缺少一些直观的工作场景。感谢分享！🙏


@zhaodong
仅作参考嘛，贵在真实。文字可以描述工作内容，图片视频直观展现工作场景和状态。

@easychen
看了两个，很不错，每个视频短短十几分钟，侧重于展示人物的生活状态。对于工作的内容还是着墨不多。

@yunyuyuan
我是。。全栈吧，至少是在学习中。不过目前我也没有想好怎么做呢。

做顾问这个不错。
另外问下，自制力这方面有什么保障措施吗？楼主没有这方面的担忧吗？
我之前也尝试过，但自制力是个难点：目标明确尚且难以自控，目标分散时就更别提了。因为时间多了，人的欲望也会膨胀，以前想做不想做的事儿都会冒出来。

是呦，快七夕了，这铜板💰咋来得这么巧合。

这里插楼问一下：
配合了 Redux 的 React ，是什么模式呢？
我觉得，有一种理解可以是：它是 MVVM 的一个变形，因为它去掉了双向绑定中的，反向的一个绑定。
其中 Redux 的 store 可以看作是 Model ，然后每个组件的 props ，是根据 store 经过 map 得来的，即 mapStateToProps ()，为得是从 Model 层拿到渲染该组件所需的数据 ViewModel ，所以 props 可以看作是 ViewModel 。最后组件本身肯定是 View 了，而且 React 实现了 ViewModel->View 的单向绑定，只要 ViewModel 变化了，View 自动变化，但是反过来 View 到 ViewModel 并没有这个自动的过程，而且 View 层是直接修改的 Model 层的数据，不符合 MVVM 中，通过 ViewModel 来修改 Model 的过程。
所以，呃，其实把 Redux+React 看作是 MVC 其实更合适，但是确实也可以从中看到 ViewModel 和 Model 之间关系的影子，也可以看到 React 自带的“数据绑定”的特点。。写不下去了。

真秀，满满幸福感

@coderluan 有道理

@zhouyg 你这种说法不能解释为什么很多软件的菜单项后面，都把快捷键标上；解释不了为什么我在 4 楼被 Qt 尴尬打脸。

很多时候用好情境，是没必要查文档的。就拿主题里举的例子来说，Qt 这么庞大，我都不知道要从哪里去查这么一个环境变量的文档。

@AoEiuV020CN
就是这些小问题才影响体验啊。遇到个困难的 bug 解决了起码有成就感，遇到这种恼人的小问题只会因为耽误时间而感到不值和生气。

刚才才发现，Qt 是有提示的，需要点一下 input 输入框，框的末端会出现一个含义不太明显的标记。误会了，尴尬。

看介绍很不错，👍+🙏

我觉得一个关键的点是：运费计算规则是什么样的，运费与总重量有什么关系。

先看一个简单的情形：对于同一家商店，运费与商品的重量成正比。
比如商店 A ，1000kg 商品，运费是 1000 。那么商店 A 出售的每件商品，费用=商品价格+商品重量*1 元 /kg 。也就是说每件商品的含运费价格是可以计算出来的。比如一个小吃，进价 10 元，重量 1kg ，那么含运费价格=10+1=11 元。

单一商品在每个商店的含运费价格都可以计算出来，那么，对于这个商品，比较含运费价格，从最低的商店进货就行，数量不够就继续从第二低的商店进，直到数量足够。

既然单一商品可以这样做，那么所有的商品都可以这样做。所需要的只是把所有商品的含运费价格计算出来。

但实际生活中，运费跟重量并不是简单的线性关系(比如运输费与重量是分段的线性关系，图形上看是多段折线)。对于非线性的，我暂时还没想到有啥合适的算法，动态规划和背包算法应该是不合适的。

@coderlxm 有道理。不过这个兴趣就千人千面了。