与ai协同工作（Working With Ai）

简单说一下今年的打算。

按照我的设想，今年是人工智能应用大爆发的一年。这不是理论上的突破，而是应用上极大的丰富，谁也不知道明天会出现什么样的应用。

所以，我打算把翻译的工作放缓一些，将工作的重心放在人工智能的应用上。主要解决的问题是如何与人工智能协同工作，搭建比较合理的工作流程，满足我自己的日常工作需要。

这几天服务器迁移的过程，实际上是一个初步的尝试。今天和David在湖边散步，他不停地讲述自己玩fortnite的经历，而我也得空给他讲了一点我这几天熬夜迁移服务器的过程。自然，我们的讲述都是在总结经验，整合知识。大体而言，讲述的过程中实现了费曼学习法的最后一步。

不知道未来会如何。但今年是我的人工智能应用尝试年。我的目标很简单，理顺工作流程，知道人脑和电脑如何配合，才能最高效的工作。或者说，知道何时使用ChatGPT作为知识库，何时使用git-co-pilot作为编码解决方案，何时使用google Gemini 1.5作为知识的补充，并熟练使用整个流程，完成我手中需要做到的一个"近视预防公益项目"。

在ai使用的这个阶段，似乎不应该过分关注神学和哲学的深度，至少在我看来，在没有完全理解ai在工作上的潜力以及应用的程度之前，我不大肯轻易讨论其中的伦理和神学问题。也许我过一阵子就要用copilot来写讲章了，但即使如此，也不过是像使用logos.com软件来写讲章，或者使用电子版圣经那样的手段和工具运用而已，作为工具使用主体的人，似乎还是在场。

当然，我也理解那些暂时无法使用ChatGPT的人。其实，如果没有应用场景，或者无法建立一个稳定的使用流程来提升效率，ai的使用往往是令人失望和心烦意乱的。若有人利用信息差牟利，或者贩卖ai焦虑，就必被藐视（雅歌 8:7d）。

关于重新做回程序员的体会

从2011年关闭我和Eric的"E&E"的游戏工作室之后，我就离开了IT行业，最多做过吉祥物而已。按照从前的经验，我这样年过50，12年没有写过代码的老人，早就被嫌弃了。我自己也没有想过重新做回程序员。但半年之前Eric重新找到我，说有一个近视预防的公益项目，必须我来继续做"吉祥物"才行。所以我就抽了一天时间来做数据分析，用matlab做了一个数据预测模型。

我用最新的数据建模工具箱跑了一遍数据，发现matlab已经会自己将所有可能的建模手段自己跑一遍，然后告诉我最佳的模型是什么。而它推荐的模型是一个我没有弄明白的高斯过程回归模型，用到的是核函数一类的分析工具，与我从前略知一二的神经元网络或者信度网是大大的不同。

因为matlab无法构成应用的后端服务，我需要用python重写代码。但python是从来没有学过的，我似乎只会一点php、c++和java。所以我就告诉Eric，我只能继续做吉祥物，具体的代码实现还是需要另外找人来做。 我们就这样耽搁了几周，最后的判断是，在目前的项目条件下，找不到在数学、ai、编程和英语文献阅读上都合格的程序员。所以我想，也许可以自己来做吧。

这种尝试，也是因为chatGPT的出现以及github-copilot的效果，让我觉得也许值得一试。我看了一个哈佛CS50的课程，某位一线大厂程序员说，目前编程已经离不开copilot，而且因为ai的出现，将来的程序员工作将会和现在全然不同。他还说，因为copilot的出现，程序员的效率大概已经提升了1000倍（？）。

于是，有一天我就去了办公室，让一位完全不懂编程的统计学博士坐在我的边上，我们两人根据copilot的指示，将高斯过程回归用python重写了一遍，生成了几张图片，让她做了一个ppt，过了几天去讲给一群眼科专家们听。那天正好是周日，所以我甚至都没有出席会议，只是晚上去吃了一点蛋糕而已。

所以，看起来效率提高1000倍虽然不一定，但chatGPT和copilot可以帮助我这样的老人家重新写一点自己看不懂、但是能够工作的代码，大概是不错的。既然找不到合适的程序员，我就自己来做吧。

Eddyemma.com的流浪过程（Workflow of Website Migration）

本来计划春节期间就开始写代码，但在大年初四，我的服务器就坏了。

这事是这样的：

2007年开始，我就不再使用QQ空间、新浪博客之类。理由自然是很复杂的。那时wordpress正是热门的应用，所以我就开始在bluehost上做我的个人博客，eddyemma.com 。后来陆续有些朋友也想要建站，所以我们有了若干个域名，什么xia-hai.net, flywow.net, timcaro.net之类，非常好玩。不过他们后来大多数都玩不下去了，也就没有再续费。

但自从google退出中国市场之后，我就有些担心数据安全问题，于是在一个廉价服务器提供商那里租了一台服务器，将网站迁移过去。从成本上看，这样也节约不少，因为bluehost是对每个网站收费的，几个网站加起来的钱，已经可以自己租用服务器了。这一台服务器一直稳定运行，直到去年我突然想到，也许经过10年，按照摩尔定理，硬件价格应该降了几个数量级了吧，或许现在用同样的价格，可以升级一台更好的服务器。正好晓天从上海给我寄来一点因为疫情关门留下的二手硬件，我觉得也许这事应该处理一下了，毕竟10多年不升级服务器，还是有点对不起时代。

果然，现在我只需要多付1美元，就可以将服务器从4核变为8核，内存从8G-DDR2变为16G-DDR3，硬盘从256G变为120G-SSD

• 2 * 1T SATA，网口从100M变为1G……

所以我就小心翼翼地迁移了服务器，特地选择了两个1T的硬盘来做raid-1镜像冗余。这台服务器的速度显然快多了，硬盘也大，我就将所有的网站全部迁移过去，并将我的邮件服务器和nextcloud云端存储也迁移过去，做了数据归集，取消了另外几个冗余的vps，总体成本节约了不少。

总而言之，还是贫穷限制了我的想象力吧。一切高大上的服务都是昂贵的，而我离开IT的时间越长，就越发把自己当作"吉祥物"看待，不想亲自写代码或脚本。渐渐的，我真的就觉得自己是一个职业翻译工作者了。

我唯一还继续跟进的只有所谓"网络安全"，也就是保证自己可以流畅而安全获取信息，不至于陷入"信息茧房"的问题。这里就不多说了。

网站的崩溃（Website Crash）

贫穷限制了我的想象力，也增加了我的数据风险和工作量。

— “Eddy”

过年的时候，一切都似乎不顺。我先花了一天时间来配置黑五抢来的vps，将所有的配置都重做了一遍。对了，我使用了“甬哥脚本”，但这事放在另一篇文章里再说吧。

到了第二天，我想起自己除了vps，不是还有这台独立服务器吗，于是就去升级服务器。在升级的时候，服务器就无法登录了。这事从前也出现过一次，只是没有引起重视。我只是提交了一张工单，请服务器管理员重启了服务器就作罢了。但这一次，管理员说，不知道怎么回事，系统自动调整了启动顺序，将启动放在了2号盘上。事件已经很灵异了，但我已经习惯了"吉祥物"身份，大概也无法挽回了。

很快，两块盘就都坏了，甚至我来不及将数据全部导出。在用rescure dvd启动进入的时候，我只来得及用smartctl命令查看了一下，看到当时还能进去的那块硬盘是一个已经上线9年多的二手盘，一切都都消失了。我努力了一整天，最后只能放弃恢复数据了。

感觉到危险，我决定不再使用这样高配、高危的二手服务器了。

恢复（Recovery）

一个从2005年的qq空间开始，直到2024年的eddyemma.com ，里面大约存着3百万字的记录。但这些文字的数量并不太大，我的数据库（备份所有文字和配置）只有77M而已，按照utf-8计算，差不多就3千万个字符。但我的网站上有差不多5万张积年图片，都是这些年wordpress的各种图片优化插件做的——每次上传一张图片，wordpress都会将图片优化为8种不同的分辨率，后来又调制为webp格式，但从来不会好好地清理一下无用的图片。所以，我的整个网站数据大概在7G左右。为了备份，我使用过google drive，后来换成dropbox，但免费的空间都不足以容纳另外几个朋友的网站备份了。我只能提醒他们自己要备份，并为他们做了本地服务器的备份。曾经有一次我在安装邮件服务器时将系统弄坏了，就是通过本地恢复的所有数据。不过这一次因为是硬盘坏，我也没有办法了。

但我还保留着一台没有使用的服务器，从前运行的邮件服务和nextcloud，以及calibre图书馆。本来打算在新的服务器上线之后就不租，可以节约一笔钱，只是因为当时Thomas说要用，我就留下来了。这台服务器配置很低，intel i-3，8G DDR2，SATA硬盘。现在我只能将数据复制到这里。但我已经没有什么动力优化wordpress，php—fpm, 内存对象缓存之类了。感受了一下网站的速度，我自己都不想使用。

于是我终于下定决心，要重新开始写代码了。

迁移到hugo（Migrate to Hugo）

我用了三天时间来迁移数据，将网站从动态的wordpress迁移到静态的hugo。当然，里面有很多深坑，比如文章标签的迁移，封面图片的对应，内部链接的一致性检查等等。

我使用了所有的插件，比如wordpress-to-hugo-exporter，jekyll-exporter，wp2hugo，效果都差不多。最后我似乎是用jekyll作为中介，在jekyll生成的markdown上做了调整，将所有的文件都放到了content/post目录下。

但除此之外，我还要求ChatGPT写了一个脚本，将一切暂时不在文章内用到的图片全部删除了。我的5万张图片变成了不到2千张，hugo编译时间在那台破旧i3上可以维持在20秒之内（作为对照，在我的i9笔记本上，hugo的编译时间是7秒）。

与ChatGPT协作（Collaboration with ChatGPT）

如果没有ChatGPT，我自己大概也能做这个迁移，但时间要花上数倍。我现在的工作流程是这样的：

1. 向ChatGPT提出需求，要求给我一个脚本。

2. 简单编辑和运行脚本。向ChatGPT反馈错误信息。

3. ChatGPT解释错误，修改脚本，跳转流程2。

也就是说，我只是将错误信息反馈给ChatGPT，等待它进一步回应而已。我唯一做过的有建设性的事件，就是有一次告诉它我使用了snap包，可能是造成hugo无法调用asciidoctor的原因，其他的时候，我都只是简单地复制和粘贴信息而已。

我使用的脚本包括：fix-broken-frontmatter.py, fix-cross-link.py, fix-slug.py, remove-tail-md.py, replace-image.py, set-cover.py, scan-unused-image.sh，check-baseurl.py之类，含义都是自明的。

当然，实际上这个迁移过程是在验证，经过10多年的中断之后，我的编程效率可以在ChatGPT的帮助之下得到一定程度的恢复。或者说，今后的程序员应该都不再需要过分注重语言的细节，甚至无须知道如何编码，如何调试，如何解读错误，只要精确定义需求，知道如何prompt就可以完成大部分工作。

朝飞看到我用ChatGPT写的代码，曾经对我说，这并不是最佳实践，我们现在已经不这样编码。但如果编码的目的是解决问题，而不是为了人工来维护和测试，这样用过就丢弃的脚本，似乎由ChatGPT来做是做合适不过。

github-co-pilot

经过两天的时间，我总算将网站迁移到了hugo上，所有代码也上传到了github。昨天，我终于决定尝试用hugo的本地开发模式来提高开发速度。

这事也是提问ChatGPT来完成的。比如安装go语言，安装ruby和asciidoctor以及各种插件，如何配置github的项目，如何修改windows上文件的小字节优先编码等问题。于是，我就开始同步使用ChatGPT和github-co-pilot来写代码了。

git-co-pilot甚至可以帮助我写作，或者提供格式设置，在vs-code上要比chatGPT更方便。但ChatGPT在理解问题，回应的准确性上似乎更胜一筹。为了节约提问，我也使用google Gemini 1.0，暂时还没有付费订阅1.5版本。

看起来，我可以解决绝大多数的编程问题，至少在我的项目开发初期，是不再需要另一个程序员来帮助了。

明天要继续正常的工作了。这个年就算过完，该折腾的事情也差不多告一段落。总的来说，如果没有服务器断裂这样的大事件发生，我大概没有动力熬夜来研究技术了。这就睡觉去了。