个人理解，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

虽说也推荐你用 uv ，但你这个环境和要求，光靠 uv 是没法彻底解决的。你要考虑的是依赖的可信与供应链管理，而不简单的一个 lock 。

正常做法是，内网搭建 pip 的镜像服务，并且配置多个 pip 仓库。至少三个，dev ，integration ，release 。只有 dev 是联通外网的 mirror ，其他两个是本地库。

然后你开发的时候 pip 指向 dev 库，发版的时候，QA 和测试用 integration 库。这时候把你需要的指定版本的所有依赖从 dev 提升复制到 integration 库内。

当 QA 和测试完成，再次把这些依赖到 release 库内。作为最终 release 的二进制依赖，同时对依赖进行漏洞检查和制做 SBOM 。

当然你可以根据你们的要求自己调整一下，可能也用不到这么严格的流程。但本质上为了避免 FOSS 的供应链风险，你应该自己保留所有依赖的二进制及其代码以供审查，并且可以完全从本地构建你的产品。

别忘了之前 npm 下毒的事。

@quicksandznzn 北大口腔的号，只要你不盯着总院。一二分院都还可以。就算是最难的牙体科，早上顶着时间打电话进去，基本也都能挂上。电话挂号优先级高，而且可以往后面几周排，等就是了。

牙冠好像是修复科，那个更好挂，基本没人，随便挂就行。

我做的进口的陶瓷，5K 。

1. 可以。我在北大口腔做的，这两个是不同的科，分别挂号。牙体科做根管，另一个科做牙冠。

2. 根管还是看技术，特别是后面几颗磨牙，这些牙即使在北大口腔这种带教医院都不会给实习生做的。容易断器械，取的时候更麻烦。

所以你如果是后面几颗牙要做，那还是建议挂个三甲。
其他的牙倒是还好，没那么难。

另外牙冠在哪做都行，杀好菌套在做了根管的牙上基本不容易发炎。

哈希算法是给你“验证”用的，不是拿来做“唯一标识”用的。因为它存在碰撞的可能。

简而言之，哈希值一样，不代表原始值就一样。而哈希值不同，则肯定原始值不同。

这就是为什么科班教学很重要。

你这个需求就应该使用 uuid ，你用 SHA1 也避免不了碰撞。

没记错的话，Go 的 io.copy 在 Linux 上用的应该是 epoll ，单纯比较极限性能，Windows 上的 IOCP 应该和它差不多，甚至稍好一些。

如果是比较 Windows 和 Linux 的网络性能的话，最好是直接用系统原生的 API ，在物理网卡上跑。

但其实绝大多数情况你压根用不着这么极限的网络性能，有那时间和精力压榨这么点性能不如直接升级硬件。

@museyicangbai 这个不太清楚了，我看的是纸质的。


@RedisMasterNode 是，陈老师早就去世了。不过对于成年人来说，这书拿来当消遣，填补一下技术书籍以外的时间还是没问题的。就当百科全书看了。