kingzeus

语言从来不是重点，相对而言，文档完备程度 /开发环境的友好度 更为重要

从产品层面来说，大部分情况下，都是根据业务场景去选择实现方案，包括选择开发语言的。小部分情况也是基于现有开发人员的技能来选择开发语言的，几乎就没有因为语言特性来选择产品开发语言的。

语言的很多特性是可以不用的，比如 C++有多重继承，在项目上完全可以忽略的，也不会影响产品性能。所以纯粹讨论语言特性没啥意义，大部分其实并不会被使用。

CRM 本质上不复杂，简单说来就是一堆的 CRUD 外加一个漂亮的前端。
如果你学习语言 /特定的技术的话，很多也是拿 crm 系统来做 demo 的，甚至于开源的代码也有一堆堆的。
所以，CRM 系统总体上来说，整体的技术难度不大，整个需求相对来说比较清晰，易于理解，或者说下限很低。

但是，CRM 系统几乎都会涉及定制开发，这个难度就不好说了，本来一个 BS 的系统，可能突然有了 CS 的需求，或者突然要加个移动端 /小程序。需要扩展的功能可能存在各个地方，如果前期没有规划，就会伤筋动骨。
另外，CRM 本质上是运营主导需求的，还有各种和客户的撕扯，特别是不懂技术，不同领域的甲方，这就是作为开发的乙方的噩梦。

CRM 系统的下限极低，上限又很高。于是，大家对于整个系统地开发难度 /时间 /成本的估算就千差万别了，免费的有，500 一套解决方案的 taobao 上也一堆，甚至于上百万的也不少见。

简单说，基础功能不难，成本几乎都在 UI 上。再上去，成本就在于业务系统的扩展性的设计，如何快速的响应需求开发以及尽可能低成本的开发。再复杂一些，可能就需要考虑硬件方面的限制以及如何更有效的扩容。

大部分的 CRM 关注的还是 UI 以及业务逻辑的设计，不太会触碰到硬件方面的限制

我用了 marginNote ，zotero 和 notion

@KURANADO 开始的时候，我也觉得很不错，而且我非常熟悉 Lua ，本来我想把 Hammerspoon 作为主力脚本来使用的。真的用起来，小问题还是不少。


1. 交互 /显示不太方便，Hammerspoon 主要还是按键操作为主，时间久了，按键容易忘。显示上也相对比较简单，稍微复杂点就会有各种小问题。
2. 功能扩展受限，api 还是无法支撑各种复杂使用场景。
3. 系统崩溃 /调试麻烦。

所以，Hammerspoon 倾向于只有一些简单操作的自动化流程。
不常用的功能，用脚本和 app 其实差不多。
复杂的功能 /交互复杂 /界面复杂 的话，还是推荐用 app 。
常用的功能，我 utools/python

我之前也写了一堆，最后发现很多还是用回了 app

mweb +1

前海开源新经济混合

信用卡地区错误，感觉上不了车了

@tommyzhang 有推荐的型号么？