9.2 Upvalue的逃逸和闭包
2023年11月20日 每日一猜答案：。 答案：ABC。 每日一猜答案分析：
6月26日更新：
感觉很多人对 blazor 很感兴趣，再深入详细讲讲我的看法。
(1) blazor 技术的实质
blazor 的技术实质是使用 html/css 来绘制界面，但是使用 C# 语言来互动操作而并非 js 语言来进行互动操作。C# 语言相对于 js 带巨大的生产力提升，哪怕是相对于 typescript ，生产力的提升也非常大。
因为使用 C# 得有个运行时。运行时放在服务器端的，叫 blazor server。运行时用 wasm 实现的，叫 blazor wasm。运行时扔给 MAUI，是 blazor maui （这个我没实际用过，猜的）。
当然，运行时还可以往 winform，wpf，a【【微信】】 等上放。
(2) blazor server
这是几种 blazor 里我最喜欢的，用之前觉得它很垃圾，越用越喜欢。
它的运行时在服务器端，跟 asp.net 在一起，前端的互动会通过 websocket 发给后端，后端的响应会传递给前端进行 ui 的更新。这里不用过多考虑前后端咋通讯的，微软封装的特别好，使用体验非常棒。
从技术角度来说，blazor server 有两个缺点：
（a）由于UI响应操作是服务器端进行的，网络的延时会影响 UI 体验；
（b）服务器承担了相比传统web程序更多的计算量，服务器端的压力要大一点。
对于缺点（a），如果你的用户跟服务器距离的不远，比如，就是局域网用，或同城用，或者就国内用，体验度还可以，而全球的话，体验就不行了。
对于缺点（b），现在服务器硬件越来越强大，越来越便宜，写的时候稍微注意点，一台服务器也能抗几百人、几千人同时用，更多的就不好说了。也就是说，相同的硬件，抗的人数较传统的技术抗的人数要低。
在能规避这两个缺点的地方，它就是王炸。
它的优点：在所有 web 开发技术中 ，它是生产力最高，出东西最快的。前端拖一个 css ui 框架，【【微信】】 这种，后端用 Lite DB 这样的纯 .net 的文档数据库，生产力简直是狂霸酷帅龙傲天，在座的（其它技术）都是垃圾。生产力的提升不是一倍两部，而是三倍五倍这种。
传统的 web 开发，要考虑 UI，要考虑服务器，要考虑 UI 和服务器的交互，这里 UI 和服务器的交互是两个机器间的交互，可*复杂了。但是 blazor server 里，UI 虽然是在浏览器端展现的，但是 UI 和服务器端交互是在服务器进程里的，直接在内存里开干。
blazor server 的潜力非常大。大家体验过通过远程桌面远程办公没？我放了一台很强的外星人台式机在家里，通过反向代理远程桌面练上去，办公体验已经非常不错了。这种模式，就是应用在远程跑，UI渲染在服务器端，通过视频流传到远程控制端。现在的云电脑，还有云游戏，也都是这种模式。服务器端渲染把画面传到客户端展现。这属于最重的服务器渲染的搞法，而 blazor server 在技术上，可以看作这种模式的轻量级实现，他将渲染指令通过 html 的方式，发送给浏览器来展现，无论响应速度还是对带宽的要求，还是对服务器的压力，都小得多。
随着网络的进一步发展，云电脑、云游戏用的人会越来越多，比这两种技术轻量得多的 blazor server ，也会有一些独特的应用场景。这是一个介于 web 程序和云电脑之间的生态位，这个生态位还没有人占，至于会涌现出什么样的新产品，我*也想不出来，得让子弹飞几年。
我也只有一些想法。比如，要开发在线视频编辑这种应用，完全在 web 端在线编辑视频，受到技术限制体验会很差，用 blazor server，可以突破这个限制。在服务器端进行渲染，web 端只做显示和交互转发。这个要基于 webrtc 来做，还没有封装好的控件。在这个架构下，很多传统的重量级应用可以搬到 web 上了。
抛开上面这种还需要探索的新场景不提，看看现在 blazor server 可以干的事情：
（a）0-1 阶段的新产品开发。新产品开发存在巨大不确定性，需要以最快的速度搞个可以看到东西来消除不确定性。传统搞法是产品经理画原型图，然后就原型图讨论确定做还是不做。做的话，再让开发来搞。就我的体验，中后台型产品，直接用 blazor server + 【【微信】】 + LiteDB 搭一个看着很漂亮，具备真实交互逻辑的原型，它的速度几乎和用 Axure 等工具画原型图一样快。可以非常快的搞个原型出来讨论，讨论通过决定做了，得了，这不已经做出来了嘛 …… 还开发个毛线啊。直接上手用，哪里出现了限制，咱再改。
（b）局域网程序或同城Web应用开发。这种情况下，用户量不多，又都很集中，可以完美避开 blazor server 的缺点。这里提一个小的应用场景，比如，你开发了一个 web 系统，在 linux 下跑，要做内部用的可视化运维工具，blazor server 就非常合适。
（c）桌面程序。.net 程序现在打包非常容易，开发完了直接把 server 打包，用 electron 或者什么的包一下，就是桌面程序了。
现阶段，blazor server 在论证新产品这块，具有非常大的优势。在中小型企业（一半都不跨城吧）、大型企业内部应用领域，具有非常大的优势。在开发桌面程序，具有一定的优势。而在未来，开发类似于云游戏这种服务器渲染的新应用，具备技术优势。它是当前最完美的 baby 阶段产品开发技术。用 blazor server，你能以最快速度开发出产品，这个产品能在 server 端跑，能在桌面上跑。放服务器端跑的话，还*天生带了反破解、反爬虫的特性。一个半吊子懂点产品的C#程序员，可以一个人当三个人用 - 产品经理 + 前端 + 后端。
因为 blazor wasm 和 blazor maui 还没成熟，blazor server 是我现在最提倡的 blazor 使用模式，当然，互联网公司没法用，用户量大，服务全球用户，恰恰踩住了 blazor server 的两个缺点，而互联网程序员的话语权比较大，所以在网上，看不到啥人吹 blazor server 的。
（3）blazor wasm
blazor 将运行时放在 wasm 里，缺点就是尺寸比较大，怎么也有几M。在现阶段来说，还是有些大。目前默认 wasm 下跑的 C# 是以解释的方式跑的，性能较 js 要低得多，AOT 速度块，但是整体还不够成熟。而随着网速越来越快，AOT 成熟后，blazor wasm 的应用场景会增多。blazor wasm 是网上讨论最多的 blazor。它相对于传统的前端后端分离开发来说，解决了 C# 写前端的问题，可以提升前端开发的效率。AOT 成熟后，可以在浏览器端跑部分高性能应用。缺点就是，现在速度还不够快，浏览器要加载运行时，会导致加载时间比较长。
由于 C# 程序员稀缺，以及 js 前端程序员及生态的泛滥，这里的前景，我不是很看好。js 三大框架 + springboot 的生态优势太强大了。而 blazor wasm 现阶段，也没法开发小程序，也会影响采用。
未来可期，未来有多远，还不清楚。
(4) blazor maui
blazor maui 就相当于把 electron 用 maui 替代了，由于 maui 自身就是 C# 程序，它就可以成为 blazor 的宿主，asp.net 那块也没必要要了（没看具体实现，我是这么猜的）。
可以把它看成 maui + blazor，也可以看成 【【微信】】。看成前者的话，blazor 为 maui 提供了 web ui 技术。看成后者的话，maui 为 blazor 提供了寄宿环境，可以直接和本地交互。而 maui 是跨平台的，这一来，一套代码，在桌面端和在移动端都能跑。
blazor maui 等于 blazor server 和 blazor wasm 的演化。对于 blazor server 来说，它等于将运行时从远程给放在本地了。对于 blazor wasm 来说，它等于将解释环境变成了本地编译环境。可以用它来做没 server 的程序，也可以用它来做有 server 的程序。
blazor maui 是我比较看好的。但由于 vs 正式版还没把它集成进来，我没怎么实际用过。上面这些技术细节是推测的，有错误地方，还请指正。
(5) 总结
我看好 blazor server 和 blazor maui。
要采纳一个技术，它必须相比现有技术有不可替代的优势。
blazor wasm 在现阶段很难说服大家去用。
blazor server 在产品 baby 阶段有非常强的生产力优势，成本的投入也较其他技术要低得多。钱少、事急是 baby 阶段重要特征，blazor server 可以解决这两个痛点，并且，为后续发展提供了一个很清晰的演化路径：
（a）使用 blazor server 进行产品论证；
（b）产品论证完了，就放出去可以直接用了，用户不接受，直接 GAME OVER；
（c）用户没意见，掏腰包付钱；
（d）用户需要桌面版程序：现阶段用 electron 之类的包一下发出去；等 blazor maui 成熟后，用 maui 包一下发出去；
（e）产品突然爆火了：将 blazor server 代码，抽离出 【【微信】】 接口出来，如果 blazor wasm 可行，用 blazor wasm 写下前端，如果不可行，用 vue.js 之类的写下前端。后端改动很少。原产品继续跑着，等新产品开发出来后，直接切换升级。
（f）产品要提供原生移动端工具：用 maui 包一下发布。
如果做 Web 产品，当 blazor server 扛不住了：【【微信】】> 前后端分离 -> blazor wasm + asp.net / js + asp.net；
如果做 移动 产品：【【微信】】> blazor maui；
如果做 桌面产品：【【微信】】> blazor + electron / blazor maui;
如果做全制霸的产品，几个路径一起推进。
整个路径很平滑。就算不考虑 C# 强大的生产力，整个技术架构也是有最多的共享代码，最节省人力的。
原回答：
blazor是个极好的东西, 如果微软的 blazor 路线贯彻实施下去，将会是截至目前最优秀的全栈解决方案。
blazor 生态包括 blazor server/【【微信】】aui+blazor。其中，blazor server 是最简单粗暴的，这玩意开发用户量不多的 web 应用速度天下第一快，比第二快的快很多的那种快，能把其他解决方案甩到看不见。搭配一套熟悉的ui框架，开发速度跟*画原型图速度差不多，甚至比画原型图还快。
当有个需求，直接上 blazor server，可以以极快的速度搞个可以跑的东西出来。用户量几百几千都扛得住，套个壳可以搞成桌面程序。这个程序可以抗住需求验证和小规模推广阶段，当有更多需求时，可以考虑拆成前后台，ui 代码大部分可以复用，弄到 blazor wasm，maui+blazor，前台就可以跨浏览器，桌面，移动设备，改动不大。
其实最近好几个发现，都让人意识到LLM的能力有诸多进一步增强的可能性。
1）【反思现象】单个GPT4，回答任何问题，只要你和它说，“再想想，有没有错误”，它就会反思。仅此一项，就可以显著提高答题正确率
2）【2个LLM模型】一个GPT4扮演领导，另外一个GPT4扮演员工。领导负责宏观规划，检查员工工作，员工负责具体的模块实现。这种组合可以显著增强GPT的编程能力
3）【25个LLM模型组成的社区】本文就是做这个的。我高度怀疑，如果把这个社区用于解题，如果允许这个社区“自由讨论”，或者先分组讨论，再集体讨论，是否会进一步增强LLM的解题能力。因为每个LLM都有自由的memory，也有自己的memory的召回的重点，可能得出一个问题的不同视角和观点，经过讨论综合之后，结果很有可能更强。
本文翻译自 项目组的 Ste【【微信】】 的博客，发表于 2019 年 11 月 1 日。Ste【【微信】】 是 Blazor 最早的创造者。这篇文章发布后还有一篇后续，是介绍一个在本文提到的跨平台 webview 概念的落地项目 WebWindow ，我也会接着翻译过来。
我们能否以更少的资源消耗，获得 Electron 的利用 web 技术构建的桌面应用程序的优势?
Electron 在 2014 首次开源，作为一种使用 Web 技术（HTML+CSS+JS）构建桌面应用程序的方式，它迅速流行起来。其设计的核心思想是将可预测的环境*在一起:
- 它*了自己的 Chromium 副本， 因此，你可以确定你的 HTML/CSS 将如何被渲染，不必担心 IE 浏览器（等） 随机的旧版本。
- 它*了自己的 Node.js 副本， 因此，你拥有已知的一个可移植编程平台的版本，它超越了浏览器沙箱，可以直接与本机系统交互。
这些选择在五年前很有价值，但到了 2019 年底，你可能会做出不同的选择。这些选择也是为什么 Electron 对资源极度渴求却也会闻名的关键。默认的空白 Electron 8.0.0 应用程序需要下载 164MB（压缩后 66MB），并作为 4 个单独的进程运行，总共消耗 150MB。
这些数字在您看来完全可以满足您的场景。如果是这样，那太好了！这篇文章并不是要抨击 Electron，它是一个运行良好的项目，人们显然已经成功地使用了它。在这篇文章中，我只是想思考一下我们还有什么其他的选择。
假如...
- ...我们没有绑定 Chromium， 而是使用了操作系统中已经存在的 webview？到了 2019 年，几乎所有的桌面操作系统都将拥有一个足够现代的、通常基于 Chromium 的浏览器可以拿来即用。对于你的应用程序来说，它是上周的 Chromium 还是去年的都不重要。
- ... 我们没有绑定 Node， 而是使用了操作系统中已经存在的编程环境，或者选择引入一个不同的？一个框架相关的 .NET Core 应用程序的大小可以很容易地在 1MB 以下，而一个独立的 .NET Core 应用程序（即绑定了自己的 .NET Core 副本）经链接和压缩后可以减少到约 20MB。
各种 Electron 的轻量替代项目已经如雨后春笋般涌现出来[1]。当然，也包括 PWA，但这不是这篇文章的目的，因为 PWA 不能进行对底层操作系统的本机访问。
我们对使用 Blazor 构建跨平台的桌面应用程序很感兴趣。这并不奇怪：将 C#/.NET 的性能和生产率，与熟悉的 HTML/CSS UI 渲染结合在一起是强大的和有吸引力的。
因此，我们发布了一个示例和一个实验性的包来托管 Electron 上的 Blazor。这里的关键创新之处在于它不是运行在 WebAssembly 上，而是使用普通的跨平台的 .NET Core 运行时来实现完全的原生 .NETb 性能，并在不受任何浏览器沙箱限制的情况下完全访问本机操作系统。
你今天可以试试。但要注意，这只是一个“asplabs”项目，因为我们还没有作出任何承诺，以推出和支持这项技术。
不难想象，一个 Blazor 混合桌面应用程序将如何进一步大幅减小体积。我们可以用一个纯粹的系统原生的 【【微信】】 替换掉 Electron，因为在 2019 年，在你的目标机器上总会有一个足够好的来用的。另外，我们并不需要 Node 作为跨平台的编程环境，因为 .NET Core 已经为我们扮演了这样的角色。
为了验证这一点，我构建了 一项名为 BlazorDesktop 的实验。这与 <【【微信】】Electron 非常相似，实际上大部分代码都是复制粘贴过来的。同样，它运行在原生的 .NET Core 上（所以不是在 WebAssembly 上），但是现在它运行在一个更小的渲染堆栈上，没有任何的 Chromium 或 Node.js 绑定。
这是一个功能齐全的 Blazor 应用程序，你可以在其中添加任何基于 .NET Core 的原生功能，并作为一个非常轻量级的桌面应用程序运行――具体数字见下文。与 PWA 不同，它不局限于浏览器沙箱。
如果您有兴趣尝试一下，请注意这只是一个概念验证，目前仅适用于 Windows。将其扩展为跨平台并不难（我将使用诸如 webview 之类的东西来添加 Mac+Linux 支持），但是我现在还没有在积极地做这件事。如果您感兴趣，请提交一份 PR。
毫不奇怪，这个最小的 Blazor + webview 应用程序比构建在整个 Chromium + Node 技术栈上的应用程序要小得多，也不需要太多内存:
.NET Core 的好处之一是，通过一个简单的开关，您可以控制生成的输出是否绑定了它自己的 .NET Core 运行时副本（也称为独立的），或者它是否假设运行时已经安装在目标 OS 上（也称为依赖于框架）。在上面的第一个图中可以看到这一点，您可以看到它对输出大小有很大的影响，因为 Blazor 库本身非常紧凑。
在企业环境中，如果您知道已经安装了某些软件，那么可以安全地分发与框架相关的小于 1MB 的应用程序，其中相同的二进制文件可以在任何受支持的操作系统上运行。但是对于公共发行版，您很可能会发布一个独立的应用程序――为每个 Windows、Mac 和 Linux 用户分别生成不同的二进制文件。
请注意，上述压缩的 Blazor webview 应用程序大约有 200KB 的大小，其中还包含了 Bootstrap 样式，因此如果您正在使用其他的则可以删除它。
正如我所说的，Blazor Desktop 目前只是一个快速的概念验证，完全是在我从 NDC Sydney 返回的旅途中开发的。要成为可行的产品还有很长的路要走。
它需要：
- 跨平台支持， 例如使用 webview
- Edge (Chromium) 支持，因此，在 Windows 10 上，我们使用的是操作系统自己的基于 Chromium 的浏览器，而不是我的原型中使用的基于 Edge 的 webview。
- 处理找不到合适的 webview 的情况。在极少数情况下，用户的操作系统没有提供可接受的 webview 技术，我们可以提示用户并下载一个独立的 Chromium 发行版（可能通过 CEF）。
- 桌面 API ――一个重大的需求，需要付出高成本地从零开始实现。Electron 不只是使用 Node 作为通用的编程环境;它还提供了一组跨平台的 api，用于与桌面操作系统进行交互，执行诸如复制到剪贴板、更改任务栏或 dock 图标、显示本机下拉菜单、显示本机提示或对话框等任务。.NET Core 本身提供了大量应用程序需要的 API，但是目前它并没有解决很多桌面应用的问题，因为现在还没有任何标准的基于.NET Core 的跨平台 UI 技术。但是任何实际的应用程序都需要这些功能。可以想象，仅仅为了获得这些 API 的跨平台实现而绑定 Node 也是值得的（但仍然不绑定 Chromium）。
- 自动发布和下载更新
我写这篇文章的原因主要是为了更多地了解开发人员社区对这些技术的感受。你有使用 .NET+HTML+CSS 构建混合桌面应用程序的场景吗？你会乐意将 Blazor 与 Electron 一起使用，还是认为有必要更轻量？
多年来，许多人都在考虑制造更轻的 Electron 替代品。现在有各种各样的开源项目，尽管还不清楚是否有关键的真正去大规模采用的动力。其中一些，如 Chromely，移除了 Node，只*了 Chromium。其他的，如 Neutralino，则消除了 Chromium，只将基于 Node 的编程模型与本机操作系统的浏览器技术*在一起。在最基本的方面，webview 只是对 webview 概念的一个抽象：它以构建在主机操作系统中的任何浏览器技术来显示 HTML/CSS，并且不提供任何自己的跨平台编程模型。
本文翻译自：
我正在写一个Ant Design 的Blazor UI组件库，欢迎Star和PR！
自从用了mitsuba3以及他背后的drjit框架，我的低血压彻底治好了（手动开心）
最近在做nerf相关的工作改进，然后看到了Wenzel实验室的几篇做可微的论文：
- Radiati【【微信】】: An Adjoint Method for Lightning-Fast Differentiable Rendering(以及后续path reply等后续工作，以下简称RB)
2. Unbiased In【【微信】】 with Differential Trackers（很好玩的一篇论文，大概是说直接的体渲染的distance sampling方法进行可微的话会出现很大的bias和【【微信】】，导致收敛变慢，作者就进行了一些修改解决了这个问题，看论文中的分析等其实还是很有道理的。）
当时以上的论文都在mitsuba3实现了，毕竟他们mitsuba3是他们实验室开发的，这几个论文也是他们实验室发的。
当时看着RB以及他在m3靠着drjit上的工程实现，感觉速度一定很快吧。然后有个新的无偏体渲染采样方法，说不定能用到nerf上，于是我就开始mitsuba3当做框架继续去做我的idea了。
然后我的高血压生活就开始了：
- 我最早用的12月份的那个m3版本，当时会有个很神奇的bug，感觉似乎是drjit在编译cuda kernel时，有一定概率会报错，然后不会自动尝试重新编写，会程序直接崩掉。找不到原因的我因为这个bug进度一时暂停。最后在1月份后他们更新了这个bug就没了
- 我的核心idea用到了m3他们写好了的一个模块的实现（具体是什么不方便说），然后我一导入这个模块的插件的时候就报错，最后debug了很久发现是他们模块的借口写的有问题，可能是从m2直接拷贝到m3，没有去改接口
- 传统nerf一般使用gird 【【微信】】+ feature 【【微信】】插值 + small mlp 进行实现的。Tutorial给出了一个比单纯的grid 【【微信】】更好的方法就是relu field，但当我想在【【微信】】 后接一个small mlp的时候，试了很多种方法都不行，具体尝试如下：
- 尝试和numpy耦合，虽然他们官网内写了可以numpy 的AD graph 互通，但是他们不能在m3的loop内互通（简要介绍一下m3的loop，大概就是说可以看成Taichi的kernel那种东西，不同平台用drjit直接编译生成代码高效并行的），然后基本的渲染操作只能在这个loop里跑，直接寄
- 尝试使用drjit手搓一个MLP，这个看起来似乎很简单。但我高估了drjit了，他，没有矩阵乘法，对，你没有看错，他不知道矩阵乘法！（除了3x3 4x4的矩阵乘法，这个内置写了的）好吧，但他支持点乘，于是我用点乘手搓了一个矩阵乘法（中间省略一系列因为loop带来的迷惑行为），然后我发现，他不支持对点乘求导。。。手动开心
- 最后放弃了，去找别的框架了。
- 不知处一些特别常见的操作，比如像np.cat ，一些赋值操作等。比如像对于aa[1,2,3]=bb[1,2,4]这种操作，会报错，要手动实现一个cat操作都特别麻烦（它本身没有类似操作），我的解决办法是把他的tensor先转换成numpy，再赋值给他的tenspr
- 速度问题，最近跑了一下最近腾讯的那个论文nerf2mesh，也有训练nerf的过程，差不多获得同样的训练结果，用他的代码训练一个lego的nerf，只需要10分钟。m3训练的是一个它自带的车的场景，所需要的时间大概是3个小时。当然场景不一样，速度也不好说，而且nerf2mesh这种是 feature 【【微信】】插值 + small mlp，而不是m3用的简单的relu field，也不一样
- 2023年3月27日补充：很深的一个坑，直接替换scene的skybox会出现问题。由于emitter在初始化的时候会对skybox做一些padding，如果你直接替换emiiter的skybox，结果会有一点点不对。但是找了很久，不能直接替换scene的emitter类，除非重新读取一次scene，但一般前面都会对scene进行了很多的操作，最后用了很麻烦的方法解决了，不知道之前的nerf结果有些floate
4月无需科学和魔法，注册使用【真】ChatGPT
哔哩哔哩和西瓜视频都没有通过审核…
youtube：
当新鲜事物来临的时候，优先选择接受并尝试的人会进入胜者组，第一时间抗拒的人则会进入败者组…
最可怕的是当新鲜事物普及的时候，原来抗拒的人会慢慢喜欢上它并沉迷于它，最后还会忘记自己曾经抗拒过它。
于是下一次新鲜事物到来时依然选择抗拒，依然是进入败者组。
无数的例子都验证了这一点，当火车刚出现时，当电影刚出现时，当iPhone刚出现时，当比特币刚出现时，当抖音刚出现时…
现在chatGPT已经来了好几个月了，有些人凭借注册卖账号已经进入了小康，有些人开通了plus让自己的生产力大幅度提升，有些自媒体人蹭热度获得了巨大的流量，有些人使用了几下国内的镜像节点浅尝辄止，有些人碰都不碰就嗤之以鼻，想必很多没有接触过的人等国内能轻松使用chatGPT后，又会一边哈哈哈一边真香一边被割韭菜了……
当然很多人出于无法科学上网的原因，没办法去注册使用，从安全的角度来讲，这是合理的，但从胜者组的角度来说，没有成功是从天上掉下来的。只要想，办法总比困难多，今天大海就提供一种思路，无需魔法，照样注册使用纯正的chatGPT，相信我，用过原版就不会再想用什么镜像节点和替代品了。
请跟随我的步骤走起来
目前chatGPT是不对中国大陆还有很多其他地区开放的，例如香港，所以一个海外的环境或者说IP地址就很重要，然而科学上网和魔法又是有点违规的，怎么办呢？我们完全可以购买一个海外的云服务器，地区选日本或者东南亚的一些国家，系统选用Windows server，很多人不知道服务器是啥，没关系，把它当成一个可以远程登录的放到其他国家的电脑就可以，这不就满足我们的注册环境了吗？
这里推荐一个国内的服务商，价格和速度都还不错：
购买他们的服务器需要实名认证，操作简单，是通过支付宝或者微信的认证服务进行的，同时服务商也是备案注册的国内公司，所以安全问题可以很好的保证，chatGPT可以，但其他的类似魔法节点的操作建议还是去看看其他海外的服务商。
★虽然都说香港不提供chatGPT服务，小知识：那是因为IP不对，这家的服务器假如选择香港cn2的非活动版，都能获得广播段的IP，也就是开头192的IP段，是可以chatGPT的，神奇不神奇。或者直接选择日本的机型就可以。
至于服务器系统，假如不会使用Linux系统，建议直接选windows2022，远程登录，简单易用。
想要注册chatGPT，不能使用国内的手机号，这里给大家一个接码平台，可以直接支付宝付款，一般购买一到两次验证码就能注册成功一个。
接码平台：
在这里选择一个国外的号码，接一个验证码即可顺利注册chatGPT。接码手机号优先选择巴西、阿根廷等南美地区，东南亚最近较易封禁。
最近由于openai封禁限制亚洲账户，导致很多国内国外的邮箱都没办法正常注册chatgpt，唯一测试正常的就是注册时使用谷歌账户登录注册，所以我们在注册前还需要先注册一个谷歌账户，国内的手机号是可以注册谷歌账户的，但需要一些特殊设置。注册谷歌账号推荐使用谷歌【【微信】】浏览器，将设置里添加语言英语，并设置为此语言显示界面并重启，接下来就可以使用国内手机号验证注册谷歌账户了。
推荐使用谷歌【【微信】】浏览器，无痕模式，访问官方注册地址，点击sign up
选择使用谷歌账户登录，然后通过sms接码平台接码注册即可成功。
最后和大家谈谈chatGPT如何挣钱，相信很多小伙伴比较关心这个事情，其实有很多比较时髦的玩法。
比如搞个接口，搞个国内镜像网站，利用信息差，每天免费几次或者限制字数，然后收费，很多公众号或者网站都是这么干的；
又或者搞个接口，提供个性化服务，针对某行业的智能客服；
甚至让GPT编程，帮忙搞投资组合套利。但这些都需要有一定的开发经验或者技术门槛，不太符合普通人的变现需求。我总结了下，适合一般人的有这么几个：
1、注册chatGPT账号
按我这个教程，算成本的话，大概一个账号的成本在10元左右，市场上一般chatGPT的账号价格在30到50元不等，你就知道这个利润还是很可观的，只要openai还没放开中国地区，这个买卖就一直能做下去。
2、利用chatGPT做自媒体的内容输出
chatGPT的功能非常强大，可以根据你的一句话来写出一段段像模像样的文字内容，比如写视频脚本，写论文，写小说，写自媒体的文章自然也不在话下，更关键的是第一次写不好，你还可以根据需求让他不断地改进，直到达到满意为止，能听懂你的需求，还能修改，这才是GPT的强大之处，利用chatGPT可以快速的输出大批量的内容，这样能保持自媒体账号的快速高质量更新，自然流量和涨粉都不发愁了。
3、自媒体账号不停地混热度，反复炒饭
其实就是第2点的加强版，自媒体想要火，就要紧跟热点，今年就是chatGPT最火了，不管是相关的什么内容都会带来巨大的流量，把网上的最新内容搞一些，直接发给GPT，让他写总结性的新文章，新文案，那还不是火上加火，流量密码，不然你觉得我为啥写这篇文章，发这个视频呢？
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。chatgptchatGPT注册OpenAI版权声明：除非特别标注原创，其它均来自互联网，转载时请以链接形式注明文章出处。
