@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 的话取决于你用的库，纯托管的甚至都可以不选。

chunk ，或者说 RAG 这些手段都只是为了解决 LLM 上下文长度有限的问题。你只要想办法把相关文档找出来就行了。

比如你觉得 embedding+chunk 效果可以，那就可以在文档分割成 chunk 的时候自己存个关联，命中 chunk 后带着同文档上下文相关的 chunk 就可以了。

或者更简单的，如果你每次输入的查询都很短，而且都是比较准确的，不需要语义相关性。那还不如直接做关键词查找。或者两者结合分配个权重。

首先，不要用 Word 。哪怕你最终需要输出成 Word 格式，也不要用它保存中间结果。

其次，你要确定你的“题目”都是什么东西。简而言之，对你这个在项目中算是核心的模型进行建模。确定它是只包括文字，还是要图文混编，或者需要支持 LaTax 一类的公式以及渲染。要不要支持混排图文的各种定位方式，或者填空题这种如何进行标记等等。都要考虑清楚。这是最重要且麻烦的一步。

确定了“题目”的建模以后，在考虑它的保存，检索以及展示方式。如果只是图文混编的话，最好还是直接定义一个 JSON 结构，然后使用 HTML 方式渲染。

标签，算是系统中最简单的一部分了。只要你把题目存到数据库，那无论如何你都能实现，可以暂时不考虑它。

试试 Whisper

https://github.com/openai/whisper