Mithril

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