苹方

要描述清楚这么多功能细节的助记词的规模不见得就比源代码的变更差异小。

算力也不是无限的，既然可控核聚变还没实现，哪怕 AI 的能力能够支持，有多少人愿意为了定制一个只有自己需要的个性化功能去花那么多钱去生成这个功能。

以前的面试可能是考查候选人的能力能不能匹配工作岗位，现在的面试尤其是小公司的面试已经是纯纯的筛人了，尤其是 Java ，大中厂退下来的初中级程序的候选人一大堆，相当部分技术广度和深度都不比小厂的小 leader 差，面试的目的就只是在一堆先天就匹配工作岗位的候选人里筛出（领导觉得）比较合适的。

可以诚实地解决问题为啥要搞歪门邪道？

导员应该给你解决问题，说服不了它就找它上一级能解决问题的，比如院党委。
初生牛犊的学生只要自身没问题，就是无敌的。

我觉得是 vscode 无插件版差的功能太多了，有很多人为它开发插件，培养了一批开发者，其中有一部分发现需要改改本体，就出现了一堆变体。

IDEA 哪怕是社区版，完成度也太高了，最高质量的扩展永远是 JetBrains 官方搞出来的，导致本体就已经是一个功能丰富且臃肿的状态了，哪怕对本体做一点点修改都很不容易。有些看起来比较小的改动就连 JetBrains 自己都处理不好。

罐装我理解会随客单送一罐（正常也够用的），更多需要收费。收费应该在客人提的时候就说明。

关键字：continuous testing

FYI gradle 更适合干这个事情。

不看看劳动合同怎么约定吗？我的是合同成立期间一切指定领域的产出归属公司（这个指定领域的范围相当之广）。

我觉得还是大部分人的视野被各种因素局限，我们生活中能看到的文化产品大部分来自东大，小部分来自西大和日韩，欧洲、亚洲其他区域、非洲、拉丁美洲的占比加起来可能都比不上日韩，这些地方的人口可没那么少，对很多宏观问题的直觉就很容易出问题。

现在 FFM 已经很好了，底层库也不应该过多考虑用户交互层面的事情，可以看下 jextract ，我自己是觉得足够好用了。

我是经常收到招行的类似电话，忙着就直接挂掉，有空就让他在招行 app 上给我发消息。

你为啥把工资交了但是不把存款也转了，是不是不信任她在留退路？

@youngxxx 我倾向于是黑灰产通过某种方式把审核模型搞崩之后大面积上线违规内容。把模型搞崩的方式就不清楚了，有可能是内容投毒，也有可能是利用了某个 0day 。具体还得等官方或者快手内部调查的结论。你这个人工瓶颈的理论过于不合理，制度设计导致某个流程依赖某个单点的人，这个单点的人出车祸都比你这个合理。

使用 Java 的有没有用过 eclipsestore ，基本上可以实现 OP 说的这个效果

快手这次显然不是自动审核机制缺位导致人工过载，如果真的有人类介入，事情怎么可能搞到这个程度。

快手明显是过度依赖模型审核，导致模型雪崩之后后台失去了对线上内容的控制，甚至都没有及时报警让人介入。

快手这次是风控和运营策略的失败，和审核没什么关系。

@5261 不会。

golang 程序员经常吐槽的 spring/java 味通常是指冗长低效的逻辑嵌套，比如封装 Accessor Methods ，堆叠套用各种工厂模式，还有屁大点事都要 New 一个对象。
这些是代码里的坏味道，但这是程序员的问题，不是面向对象的问题，假如有人看到面向对象的东西，就说这是 java 味，那是这个人的问题，不是代码的问题。
使用 fx 这样的 DI 框架，你首先就需要接受面向对象这个编程范式，这是个好东西，绝对可以帮你们消除混乱的全局状态，管理好应用的生命周期。
如果你们团队里有比较好的 Java 积累，我估计你们大概率确实会在 golang 里复刻一些在 java 里很常见的设计模式，这可以说是 spring 味或者 java 味，我觉得不是坏事，用 golang 的语法大概率可以写出更地道的代码，但能被大家理解，能解决问题，足够稳定的代码就已经是好代码了。