极空间家里用了好多年了，没发生过问题。

但这东西好用的前提，是你完全不想折腾，全用它自带的客户端和功能。我是给父母用，他们拍了几个 T 的照片上去，完全傻瓜化。他们出去玩，相机拍完存储卡插上去，或者连上相机，手机 App 直接导数据了。

你既然有能力折腾，那还是建议自组。环境可控，更方便一些。他们这魔改版的系统，你当成普通 Linux 用肯定会有各种问题。

说白了是你不信赖医生的诊断，你相信自己的判断，补一颗牙顶起来就行。但你有没有想过，如果你是正确的，那你这颗牙会顶起来整个左侧。说明它本身就先接触，需要打磨掉。

当然看不看，怎么看还是你自己做主。你如果想要比较好的诊疗环境，可以去私立诊所。很多北大口腔的医生也在外面上班。你找专家就可以了。

北大口腔比较适合有一定经验的患者。他那还是带教医院，里面普通号大概率是实习生。而且患者太多，天天都排的很满，自然谈不上有什么良好体验了。个人感觉，主治以上的水平还是值得信赖的。找口腔诊所的问题是你得赌医生水平，而北大口腔的大部分都不错。

另外正畸是很看经验的，就算是北大口腔，正畸科也有很多经验一般的医生。建议多看几家医院，多挂几个医生咨询了再说。这个选定了以后后悔，开始正畸再想换医生，一般医生是不接的。

@EJW 是的，主要问题还是预算不够。索尼的 9 系还是很好的，但你要是只有 7 系的预算，那不如看看国产。

@HTravel Termux 还支持 Go 和 Python ，很多时候你 Github 上拉了代码扔里面编译一下直接就能跑，非常好用。

@kyokaka 主要是 NPM ，或者说 JS 的包依赖关系过于复杂，导致这种供应链攻击防不胜防。

前端生态就是这样，依赖树越复杂，某个节点被干掉的概率就越高，你换什么包管理都没办法。

肌肉的力量取决于两方面，一是你有没有那么多肉，二是你的神经有没有办法募集更多的肌肉来完成动作。
新手的话两方面都会涨的很快。但你两个月就遇到“瓶颈”的话，大概率不是因为什么小重量还是大重量的问题。应该是你本身就举不起来这个重量。

其实长肌肉主要看的还是总容量。你越偏向低重量高次数低组间间隔，就越偏向“耐力”。越偏向高重量低次数高组间间隔，就越偏向“力量”。

但不管怎么说，动作标准都是前提。不仅能减少受伤概率，也能让你的肌肉更好更容易发力。比如你卧推姿势不对，全靠三头加肩膀顶起来的话，那很快你就会卡在某个重量上了。毕竟这两个部位肌肉就那么多，怎么也比不过胸的。

这类东西非常适合不太专业的前端，比如全栈或者后端转型的那种，快速糊一个大概还看得过去的 UI 。该有的功能都有，凑合用也没啥明显的 Bug 。

也不用考虑太多细节，性能，兼容性。反正你做个企业内部用的破系统，撑死了也就几百上千人用。开发从前端到后端就你一个，那自然怎么省事怎么来。组件库有的功能自动带上，组件库没有的功能也不会给你做。反正后面还排着一大把的需求呢，屎上雕花这种需求领导根本不在乎。

你如果养了一个前端团队，那肯定要自己搞了。特别是 AI 越来越普及，总得证明自己的价值。一套内部用的，样式风格等等都契合企业风格的组件库，多迭代几个版本都能养活前端+设计+测试三个团队的 KPI 了。

但一个内部系统就你一个前端开发。你跟领导说后面五十个需求暂停一下，你要花一两个月搞一个特别牛逼，能适配多种浏览器，五彩斑斓的黑全覆盖的主题切换器，你看领导砍不砍你。

《 Cowboy Bebop 》

虽然剧情都烂熟了，但还是会时不时的拿出来当 BGM 。

你可以详细了解一下睡眠周期，以及睡眠的不同阶段中哪些部分会被抑制，哪些会被激活。

最简单的，很多人睡眠大概就是 90 分钟一个周期，你尽量控制在 90 分钟的整数倍醒来，再看看你会不会还是像现在这样。至于你自己个人的具体时间，你可以带个有睡眠监测的手表或者手环看看，能明显看到周期的循环状态。

个人认为你可能是因为睡眠质量不太好，或者被意外打断。
晚上的话，你可以简单试试褪黑素。
午休尽量要么 10~20 分钟，保证在深度睡眠以前被唤醒。要么睡够 90 分钟，在进入下一个周期以前醒过来。

169 换了个国产，确实体验不错。

现在就看哪家能造出来电磁滚轮，平替掉 Master 3 了。


@git00ll 有几个板载配置，写到鼠标里的。也支持云同步，换电脑打开网页就行。另外横向滚动你可以按 Shift 。

个人理解，Engineering 就是在现实世界中，使用各种方法解决特定问题。

核心是在可接受的成本下，达成可接受的目标。

这个成本既包括软硬件，也包括人力成本，学习的成本。
目标可以算产出项目，也可以认为是单元测试覆盖率等等。

总而言之现实世界总有各种限制，并不完美。但你很多时候也不想要一个完美无缺的产品，能用就行。
成本和目标标准互相妥协，最终糊了个能跑的，就是 Engineering 了。

我倒是想看看，到底有多少人能来你这帖子里回复

“很多点根本算不上缺点，最多算“差异””
“尤其是对 XX 的批判令人发笑”
“我最讨厌这种 XX 本位主义，把所有和 XX 不一样的地方都归为“缺点””

虽说你的原文已经被/go/pointless ，但至少字数够少，看一遍也不费事。
但这 AI 转写的，我甚至连 “技术亲历者”，都没看完。

有效信息几乎为零，全部都是车轱辘话来回说。这已经不是表达的事了，纯纯是浪费时间。

暂且不论“幸运”与你的核心论点“每个人都应该投身到 AI 变革中去”有没有什么关系，只说 AI 扩写的这一大坨，全部都在扩展你给的几个技术点。
作为论证来说，AI 输出的这段不去论证你的论点，不去说明“幸运” 是如何 “应该投身到 AI 变革中去”的。而是纯纯将附属论点扩写了一遍。导致整段文字的有效信息更少了。

你被“批评内容空洞”，那么应该考虑原因，更好的表述你的论点。AI 没有提出观点的能力，你让它在空洞上继续糊，只能越糊越空洞。

生产力工具的重大革新，带来的除了生产效率的提高，也带来了越来越高的行业壁垒。

再过一些时间，等普及的更广以后以后你就能发现了。当每个公司都有能力配上满血 Coder 模型的时候，水平差的程序员就越来越难以找到工作了。

Vibe Coding 的一大缺点是，你要熟悉你使用的技术，你搭建的架构。你很清楚每次模型给你吐出来那一坨屎，是只帮你糊了屎山上的一个需求，还是从底下掏了个大洞。
当你两眼一抹黑，甚至都看不懂它输出的代码时，你是完全没有能力 Debug 的。甚至它为什么出问题你都看不懂。

更别说初级程序员连“提供清楚且准确的 prompt”都未必能做到了。

最终就会变成，有经验的人拿着 LLM 大杀特杀，两天就能给你糊出来原来要半个人月的项目，甚至结构清晰，单元测试都给你带上，输出的垃圾代码都能给你改好再提交。
水平差点的拿着 LLM 吐的一坨屎，这也跑不起来，那也跑不起来。随便一点就崩溃，加一个功能带崩三个。

在没有 LLM 的时候，这些低端体力活的代码总要有人写。降点薪总还是能找到个活的。现在这些体力活代码都被 LLM 代劳了，从业壁垒自然越来越高。

可以，但是不要这么搞。

这是公司安全策略问题，不是技术问题。

我之前也看过电压力锅，总结如下：

缺点：结构复杂，清洗麻烦。功率比燃气灶低，上汽慢。便宜的压力低，想要和燃气压力锅一样压力上到 100kpa ，至少要上千的锅才行。对比二三百的燃气压力锅差很多。

优点：可以定时，预约。怕炸了你定好时间人出门就行了。安全性好一些，超压了可以断电，而不像燃气压力锅一样堵了也一直烧着。

当然电的声音也小，不过还是喜欢传统压力锅那个阀门泄气的声音，这就看个人喜好了。

@magic3584 对，你得找供应商要这个 ARM 的国产系统对应的驱动和测试程序以及代码。如果他们不提供，那你根本做不了，不是说有测试程序或者驱动的代码重新编译就可以的。

国产系统大部分都是魔改 Linux ，所以你至少要找个 Linux 驱动才能开始你这活。厂家只提供 Windows 驱动的话，你这活没法做的。

Windows 和 Linux 的驱动模型不一样，你没法直接拿 Windows 驱动的代码编译一下就跑在 Linux 上。非常简单的通用设备可能还好点，找个通用的开源驱动改改就行了，但涉及到厂家定制的就没办法了，比如加密狗这种。

你用不惯国产系统开发，可以找个 ARM Linux ，然后找你那国产系统测试。最后即使跑不起来，修改量也不会很大，就是 Debug 级别，改改就行。但你找个 ARM Windows 的话，驱动接口测试程序啥的都不一样，改起来就太麻烦了。

@magic3584 那很麻烦，如果这活不是砸死你头上了，建议不要接。

C++，还是硬件驱动，是大概率没法直接二进制跨平台的。你至少也需要重新编译才行。你这.NET Framework 4.0 的项目估计已经很老了，你找对应硬件的 ARM 平台和系统驱动，C++代码就得找半天。找到代码了，编译测试好了，才是你.NET 代码的事。这还是不算你 C++代码根本没法跨平台的事。你那 C++部分要是用了什么 ATL ，MFC ，或者一堆 Windows API ，迁移它还不如重新找个供应商。

然后你得测试从 C#代码里调用你 C++的 Wrapper ，这个你怎么都要改（至少 Linux 上你的库大概率不叫 x.dll ）。这个测试你得用对应平台才行。比如你用 ARM 的 Ubuntu ，甚至用 ARM 的 Windows 11 ，也得找个测试机才可以。

最后才是你那 Web App ，迁移这层相对来说是最简单的了。

所以你以为是迁移一个 Web 应用到 ARM 平台，实际上是一整个大深坑。而且最难的根本不在.NET 部分，而是你要把你硬件那堆东西先迁移到 ARM 才行。

还是要看你的项目核心功能在哪，有没有用到一些 Windows 独有的功能，或者一些和系统贴的很近的库。

虽然都是 Web 应用，但你这程序如果底层用了一些第三方的库，P/Invoke 了一些 C++或者用驱动读写了一些硬件，那大概率是转移不了的。

或者只是单纯的 Web 应用，但是那种非常传统的 ASP WebForm + IIS ，也用了一堆第三方控件。那迁移也是要重写的。即便是.NET 5 也没有这东西了。

如果网页结构不是很复杂，建议用.NET Core 自带的新 ASP 直接重写。前端使用现代的框架，Vue 或者 React ，不要用 Blazor 。这样你用 LLM 做 Vibe Coding 很快就能写个差不多的出来。

另外新的.NET 你可以直接在 Windows 或者其他开发机上写代码，编译的时候再选平台就行了。如果不带 runtime 的话取决于你用的库，纯托管的甚至都可以不选。