16 篇博文 含有标签「我和labview」

原计划是每翻译一段，就立即进行人工修正。然而，我后来发现人工校对实在是太耗时了。由于我的闲暇时间有限，若要认真地逐字逐句进行修改，估计整个过程需要一到两年的时间。因此，我决定暂时跳过人工校对这一步，先使用机器将其全部翻译成英文，日后再逐步进行优化。

我主要采用了 ChatGPT 进行翻译工作，并且也试验了其他几种大型语言模型。经过比对，ChatGPT 的翻译效果是最佳的。尽管如此，ChatGPT 也并不完美：阅读几行后，仍然能发现其翻译的内容与真人撰写的有所不同。它最明显的不足之处包括错误地翻译了一些专有名词，例如，LabVIEW 中的许多术语，比如 tool palette 等都被错误翻译了；此外，其用词偏好和写作风格也与真人不同。比如，“instrumental” 这个单词在平常几乎不会使用，但在 ChatGPT 的翻译中却频繁出现。我推测，这可能是因为 LabVIEW 与 “instrument” 高度相关，而 “instrument” 又与 “instrumental” 有关联，所以模型可能误以为 LabVIEW 相关文章就应当多使用 “instrumental”。

但无论如何，ChatGPT 的翻译效果已经远超以往所有的专业翻译模型。在大型语言模型兴起之前，谷歌翻译被认为是效果最佳的翻译工具，即便如此，其翻译内容仍然基本无法直接使用。现在，ChatGPT 已经可以当作一个相当靠谱的翻译工具了。

最近一个多月，我几乎把所有的业余时间都用来写一本 Python 编程书：《Python 秘籍》。

写这本书的初衷，不仅是为了深入学习 Python 本身，也是为了探索大语言模型在学习和写作中的新可能。现在回头看，感触颇深：大语言模型实在太强了。 在它的帮助下，我仅用一个多月，就完成了书稿的初步成型，虽然内容还不够完善，但已经达到了可供分享的阶段。如果没有它的帮助，达到同样的进度可能需要多花两到三倍的时间。

大语言模型极大地提高了我的写作效率。然而，效率的提升也带来了一些新的思考。过去需要三个月才能完成的工作，现在可能只需一个月。那么，从工作价值的角度来看，这种写作的意义是否也随之下降了呢？或许未来，类似的编程书籍对于读者的价值将大幅降低。毕竟，与其阅读一本书，不如直接向大语言模型提问来得便捷高效。

目前来看，可能还是写 LabVIEW 相关书籍的价值稍微更高一些。因为相对 Python 来说，目前大语言模型在生成高质量的 LabVIEW 编程资料方面还有较大局限性，所以，暂时这类书仍有市场空间。

大语言模型目前对我帮助最大的是它对自然语言的处理。我英语水平一般，自从有了大语言模型，无论写什么英语文章，我都会先让它修改润色。它不仅能纠正语法错误，还能帮助提升整体表达效果，达到我个人难以企及的水平。

正因如此，我决定把之前写的 LabVIEW 教程翻译成英文。我早有这个想法，但是因对自己英语水平的不自信而始终未能执行，但现在，我充满信心了（当然，更准确地说，是对大语言模型充满信心）。

最近，我已经开始翻译这本 LabVIEW 教程了：《The LabVIEW Journey》。 翻译时，我采用分步处理的方式：

• 第一步：初步翻译。我先用大语言模型将中文内容翻译成英文。这一步的成果通常语法无误，但由于保留了许多中文句式，英文表达显得生硬、不地道。
• 第二步：优化改写。接着，我用大语言模型对初稿进行改写，确保语言更加流畅自然，符合英语的表达习惯。
• 第三步：人工校对。最后，我逐章检查译文，不仅是为了确保准确性，也借此机会提升自己的英语水平。

虽然生成的英文文本可能仍比不上专业母语作者的写作水平，但它已经远远超越了我的个人能力，语法更准确，用词更丰富。不得不感慨，计算机在写作领域的进步速度超乎想象。

目前，翻译过程中最麻烦的部分是如何将插图中的中文内容转化为英文。这部分工作只能暂时搁置，留待日后有空再处理了。

大语言模型虽然大幅提升了我的工作效率，却也带来了新的挑战。比如，在编程面试中，它的影响尤为显著。我们公司如今采用视频面试，可能是为了节省成本。自从有了 ChatGPT 等工具，明显感觉到应聘者的编程能力普遍“提升”了。

有些应聘者面试时，一边敲几行代码，一边时不时歪头看一眼屏幕。他们的表现让人难免怀疑是不是在“作弊”，但又没有确凿证据，也许这只是他们的编程习惯罢了。更麻烦的是，ChatGPT 不仅会写代码，还能解释代码，这让判断应聘者真正水平变得更难。我目前也没有什么完美的解决方案，只能希望公司能尽快恢复现场面试。

大约去年这个时候，我把《我和 LabVIEW》这本书做成电子书发布在了网站上。当时已经计划每年会做一些更新，今天回顾了一下这一年来的改动，实际上改进的内容比我预估的还更多一些。

刚开始做准备的时候，我担心我的 LabVIEW 编程技术已经忘光了，也担心这十年来 LabVIEW 变化太大，打开之后都不认识了。但后来发现，我开始的预计都有些太悲观了。我的编程技术确实退化了，但基本的方法都还记得，恢复的很快；LabVIEW 也并没有太大变化，基本操作几乎一模一样。

变化比较大的是网上的中文资料。10 年前网上关于 LabVIEW 的中文资料少得可怜。但现在，无论哪一方面都能搜到一大堆资料，而且很多资料的质量也是相当高的。这些年也有不少关于 LabVIEW 的中文书籍出版，网上评价也不错。如果我在国内的话，肯定当时就买来看看了，不过现在人在国外考虑到运费，嗯，还是等下回回国再说吧。

再有，就是近几年视频逐步崛起，成了网上最重要的知识分享方式。但是考虑到我个人还是会继续以文字加图片的方式分享自己的编程经验。这主要是因为视频制作要花费更多的精力，如果我有时间，还是倾向于增添更多的内容。另外，就是我分享的很多东西也不是太成熟的，发布后还会经常改来改去。文字改起来非常容易，视频要改其中部分内容就麻烦多了。

在搜索 LabVIEW 中文内容的过程中，我还特意尝试用了很多国内的搜索引擎，结果大失所望。百度是国内市场占有率最大的搜索引擎了，先不说它垃圾广告的问题，单说搜索质量也是十分差劲。搜索一些技术内容，返回的常常都是灌水文，最后只能换回 Google。

相比起写纸质书，我还是更喜欢这种类似博客的电子书发布方式的。最主要的原因是可以及时和读者交流。从读者的反馈和问题可以直接了解到自己那里写的不清楚，甚至写错了，然后可以及时纠正。除了读者留言，我还使用了网站统计工具来查看这本书被阅读的情况，工具可能并不精确，但大致可以反应读者的分布。

首先让我觉得比较吃惊的是，这本书最大的流量来源是 Google，尽管在国内无法直接访问 Google。这一说明了搜索引擎对一个网站的流量作用极大，可惜的是，国内的一众搜索引擎都不能搜索我的网站，可能是歧视我没钱买关键词吧。唯一一个我发现能搜索我的网站的国产搜索引擎是 https://fsoufsou.com/ 。也试了一下用这个网站搜索技术文章，比百度的结果好太多了。可惜它的用户量太少，几乎可以忽略不计。希望这个搜索引擎能继续坚持做下去。

除了 Google，比较多的来源网站是知乎和微信。知乎上网友的推荐贴给本书带来了不少流量。微信的对话和群都是封闭的，而我又不在任何群里，就无法得知网友们都在讨论啥了。

再有就是发现绝大多数读者关注的还是基础内容，而不是 LabVIEW 一些高级用法。除首页外，访问量前五的章节是《数值和布尔数据》，《Hello World 程序》，《图形化显示数据》，《什么是 LabVIEW》，《数组和循环》。除首页外，Google 点击页面的前五分别是：《图形化显示数据》，《界面设计实例》，《什么是 LabVIEW》，《安装 LabVIEW》，《事件结构和程序界面》。深入一些的内容比如性能优化，面向对象等访问量比起基础内容零头都不到。我想想也是有道理的，那些比较高级的用法，可能并不是看看书就会用的，最好还是要有交流，有个专门的人来指导一下。相反写书的话更适合介绍一些基础知识。所以我也调整了自己的更新维护计划。今年上半年的时候，我重写了整个面向对象一章，也是为了让零基础读者能更容易理解。后来，就把主要时间用来从头更新那些基础章节了。

之前用 LabVIEW 编写了一个黑白棋程序，作为学习 XControl 的示例。那个程序基本完整，但是缺少一个 AI 自动走子的功能。最近抽空尝试训练了一个网络模型，添加到了演示程序中。

所有AI下棋的思路都是非常类似的：根据当前的盘面，给每个可以落子的位置打分，选取分数最高的那个走法。这里的关键就是设计一个最为合理的打分算法。

黑白棋最终判定胜负的标准是看谁的子多，所以最符合直觉的打分方法是：在一个位置落子后，把己方的棋子数目作为这个位置的分数。这个算法有个缺陷，就是当前棋子数最多的走法不见得就能保证将来也棋子数最多。

解决这个缺陷的思路有两条：其一是，不要为当前这一步打分，而是向后预测几步。比如，把双方各下三步棋（也就是总够六步）后的所有可能出现的局面都列出来，然后看那个局面得分最高。考虑的步数越深，棋力也就越高，极端情况，如果预测的足够深，甚至可以找到必胜的下法。这个方法的缺点是预算量非常高，增加预测的深度，计算量会指数级增加。可以通过剪枝做一些优化，但效果有限。

第二条思路是采用更复杂的打分算法，如果只考虑棋子数量还不够好，那么就也同时考虑落子的位置，稳定的棋子的个数，周围空间的个数等等。在这众多的因素中哪些更重要，如何分配权重，对于我这种非专业棋手来说是很难做选择的。不过这部分可以利用机器学习算法，让电脑自己找到最优解。

当然以上两条思路可以结合使用：先找到一个最优的打分算法，再尽量预测到更深的步数。

我尝试训练了一个基于神经网路的打分模型。

我采用的是一个只有一层隐藏层，64节点的全链接神经网络。单隐藏层64节点的神经网络对于解决黑白棋来说，有点太小了。我也不能确定多大才合适，但估计至少也应该采用一个七八层的CNN，才能达到不错的效果。不过，我的目标不是最好的效果，而是只要试验一下可行性。并且，我需要把训练好的模型移植到 LabVIEW 代码上，复杂模型移植起来太麻烦。所以我选择了这个最简单的模型。

模型的输入数据是当前棋盘状态（每个位置棋子的颜色）和一个准备落子的位置，模型输出一个实数表示得分。

训练模型的大致思路是：让模型分别持黑子和白子，自己跟自己下棋，并且记录下每一步的走法。最终胜利一方所有走过的位置都获得正标签，失败一方所有走过的位置都是负标签。用这些标签训练模型，然后重复以上过程。

在训练模型的过程中，我遇到了一些以前从未考虑过的问题。比如，采用何种激活函数。我开始采用的 ReLU 函数，但模型始终无法被训练到预期效果。调试后发现，是 ReLU 的神经元坏死造成的。ReLU 在输入值小于零时，梯度永远为0，这个神经元很可能再也不会被任何数据激活了。这对于目前常见的有着几万乃至几百亿节点的大规模模型来说，根本不是问题。但是对于一个本来就没几个节点的小型模型来说，损失神经元是非常致命的。我把激活函数换成 Sigmoid 之后，效果就好了很多。

我训练模型的方法效率非常低下。在下棋过程中，大多数的步骤可能都不是太重要，不论走这还是走那，对最终结果影响都不大。关键的就那么少数几步，可以决定输赢。但是在训练时候，我也不知道每一步的权重应该有多大，只能假设所有步数都是一样的权重。那些垃圾步不但占用资源，也会影响训练结果。

模型训练好之后，我把它移植到了之前编写好的 LabVIEW 黑白棋 VI 中。棋力算不上很好，但至少是明显优于随机落子。等我空闲的时候，看看还能不能进一步优化下。

程序在： https://github.com/ruanqizhen/labview_book/tree/main/code/%E7%95%8C%E9%9D%A2%E8%AE%BE%E8%AE%A1/Xcontrol/Othello

最近学习了 React，并借助 Docusaurus 重新制作了书籍网页：https://lv.qizhen.xyz/

实际上，Docusaurus 已经帮我做了绝大部分工作，React 技能几乎没派上用场，毕竟书籍的格式还是比较简单固定的，不需要非常炫酷的界面。

之前我使用 Docsify 制作网页，对其简洁的界面和实用的功能一直很满意。然而，Docsify 的最大问题在于它采用客户端渲染，导致搜索引擎无法有效爬取页面内容。在墙外，Google 几乎垄断了搜索市场，但它对客户端渲染页面的支持并不理想。国内的搜索市场竞争虽然激烈，但各大引擎在这方面表现得比 Google 更差。因此，为了提高网页的可见性和 SEO 效果，我决定寻找更适合服务端渲染的工具，最终选择了 Docusaurus。

Docusaurus 确实比 Docsify 更复杂，入门门槛也稍高。Docsify 专注于文档页面，而 Docusaurus 除了文档，还支持个人主页和博客等多种内容形式。因此，Docusaurus 的配置和插件系统更为复杂，但灵活性也更高。Docusaurus 支持服务端渲染，生成静态 HTML 页面，这使得 Google 可以顺利爬取我的网页内容。尽管国内搜索引擎目前依然无效，但问题可能出在我的域名未通过工信部认证，而非 Docusaurus 本身的限制。与 Docsify 的“所见即所得”不同，Docusaurus 需要经过 build 步骤才能生成最终页面，这对初学者来说可能有些不习惯。此外，作为较新的工具，Docusaurus 的中文资料相对较少，但社区活跃，更新速度快。

尽管学习曲线略陡，但 Docusaurus 的整体体验非常令人满意。特别是在 SEO、功能扩展和界面设计上，Docusaurus 显示出强大的潜力和灵活性。

我把书的原稿开源后放到了 GitHub 上，并制作了一个页面方便阅读。制作的网页是一个单页面应用，也就是说书中的所有内容都在同一个页面中：https://lv.qizhen.xyz/。别看每个章节的地址栏都会显示不同的 URL，比如：https://lv.qizhen.xyz/#docs/structure_condition，实际上 # 号后面的部分只是同一页面的不同参数而已。

浏览器展示的内容是 HTML 格式，但 GitHub 的网站并没有存储 HTML 格式的文档。所有文档都以 Markdown（.md）格式保存。GitHub 的网站不会动态地将 Markdown 格式的文件渲染为 HTML 再传给读者的浏览器，而是直接发送 Markdown 数据。最终由浏览器端运行的一段 JavaScript 程序将 Markdown 数据渲染成 HTML。

GitHub 的服务器似乎不支持后台渲染。做成前台渲染的单页面应用对用户体验会更友好，比如页面切换速度较快，还可以动态改变背景配色等。但这种做法对搜索引擎并不友好。

搜索引擎在检索网站时存在两大问题：

1. 它不会尝试访问 URL 中的不同参数，也就是说只会检索 https://lv.qizhen.xyz/ 这个主页；
2. 搜索引擎的爬虫不会运行 JavaScript，因此即便是主页的内容，它也无法看到。

总之，搜索引擎无法读取书中的任何内容，这也就意味着用户不可能通过搜索引擎找到它。

目前我还没有解决这个问题的方案。不过，在 GitHub 上搭建博客有很多其他方法，有些工具可以生成静态 HTML 页面，这种方式应该不会有类似的问题。等有时间再尝试其他工具吧。

此外，GitHub 自带的搜索功能对于中文书籍几乎没有用。它按“词”进行搜索，但 GitHub 定义的“词”是两个空格或符号之间的字符串。对于代码或英文文档来说，这种方式非常适合。然而，由于中文词语之间没有空格，GitHub 搜索中文时只能整句匹配。只有当文章中的某句内容与搜索内容完全一致时，搜索结果才会显示出来。

https://lv.qizhen.xyz/

花了好几天时间，其中一天我甚至请了假专门来整理。虽然目前仍然存在一些排版上的问题，但这些只能慢慢修改完善了。

Markdown 格式在某些功能上还是有局限性的，尤其是处理表格时。最大的问题是它不支持无表头的表格。将 Word 文档转换为 Markdown 格式时，大部分表格不得不直接使用 HTML 标签。这虽然在显示上没有问题，但编辑起来却相当麻烦——满眼都是标签，想要找到需要的内容变得异常困难。

在这里要特别感谢 lhb5883 网友，他最初建议我使用 GitHub 搭建博客。这才让我发现，原来 GitHub 既没有被墙（希望我不是乌鸦嘴），也确实是最适合托管开源项目的平台。唯一让我担心的是，LabVIEW 用户中可能有很多人不熟悉 GitHub 的使用方法。

这堵“墙”给我造成了许多麻烦，更糟的是，它似乎还在变得越来越高。有些人可能认为这堵墙只是为了圈住里面的人，但实际上它是双向的。我在国外访问国内网站也越来越困难了。例如，我已经完全无法使用新浪博客了。最开始还能浏览页面但无法查看评论，后来甚至连正文加载都不正常了。而现在，登录还必须每次通过国内手机接收验证码。

目前，国内用户量较大的网站几乎都要求手机注册和验证。这意味着，我无法再正常使用大多数常用网站。如果只是注册时需要手机号，我还能请国内的亲戚帮忙，但有些网站每次登录都要手机验证，这就彻底把国外用户挡在门外了。

这次把书开源的过程中，我学到了一些网页构建的知识。在此之前，我几乎没有任何网页开发经验。不过，对于是否将博客也迁移到 GitHub，我仍有些犹豫。原因是旧博客的内容非常多，包括大量的图片、链接以及留言等，这些迁移起来的工作量可能远远超过一本书。我还需要进一步研究是否有更高效的迁移方案，争取找到更简单的做法。

感谢许多读者多年来对《我和LabVIEW》这本书的支持和喜爱。随着时间的推移，我觉得出版社应该不会再对这本书进行改版或印刷了。于是，我联系了北航出版社，咨询他们是否同意将书的原稿开源，以便让更多人从中受益。非常感谢北航出版社胡主任的大力支持和肯定答复！

为了让更多技术爱好者能够方便地学习和参考，我在 GitHub 上创建了一个项目，将原稿及相关的示例代码都上传到其中。需要说明的是，我并没有这本书的最终电子版，目前开源的原稿内容与发行版基本一致，主要区别在于少了一些精美的排版，可能还保留了一些未修改的错别字。

为便于大家阅读、检索和讨论，我将原始 Word 文档格式转换成了 Markdown 格式，并上传到了 GitHub。这样不仅更加轻量化，也便于在现代技术社区中共享和改进。

• 项目地址：
  GitHub 仓库 - ruanqizhen/labview_book

• 书籍在线阅读入口：
  https://lv.qizhen.xyz/

接下来，我会逐步把这个博客上所有关于 LabVIEW 的文章也都搬到书籍专用的网站上去。任何关于 LabVIEW 的问题都可以去新的网站进行讨论。希望这个开源版本能继续帮助到对 LabVIEW 感兴趣的朋友，也欢迎大家提出改进意见或参与讨论。再次感谢大家对这本书的支持与喜爱！

我常常会去售书的网站看看读者对自己这本书的评论，最近发现京东，卓越两个网站长期缺货，也不知道为啥。于是想起来去跟编辑打听一下这本书的销售情况。胡主任告诉我，书已经卖出了九千多册了，前两次印刷的一万册很快就会售罄。今天正好是这本书发行两周年的纪念日。

我最初还真没想到一本LabVIEW书会有这么多读者。开始写这本书的时候，我以为中国LabVIEW用户数量不多，这本书能卖出去三四千本我就满足了。现在看来，中国LabVIEW用户还真不少，LabVIEW影响力蛮大呢。

我还是比较关心自己的书的销量的，所以是不是会跟编辑联系一下，问他卖了多少了。不过这个绝对的销量数字对于我来说意义不大，我更希望看到这本书与同类型书籍的比较结果。也许LabVIEW读者的总数并不多，但是如果我的书比其它的LabVIEW书更受欢迎我就心满意足了。

查看印刷数是一个方法，比如打开我的书能够看到它是第二次印刷，印数5000~10000，销售数量肯定也就介于这个数字之间。

更精确一点的可以去看网上书店的用户留言，对同一类书来说，买书者和留言者的比例可能差不多。但也不精确啦，如果一本书特别好或者特别不好，肯定会比那些中规中矩的书吸引到更多的留言数量。

前一阵子，发现当当网给每本书还多设置了一个参数：“喜欢人数”。我一直在琢磨，当当凭什么判定有多少用户喜欢一本书呢？我跟踪观察了一段时间，觉得最有可能的是所谓“喜欢人数”就是这本书的买家数量。这大概是最能体现销量的参数了。