维基专题:电子游戏/短信/2025-04/访谈

访谈：For Each element In group ... Next、SuperGrey

采访人：HoweyYuan

在本次规则修订中，最引人注目的成果，非可视化工具ACGATool莫属。该插件的应用，让初来乍到的新手们告别了繁杂的项目代码，让兢兢业业的核对者们告别了wikitext。相信各位读者已经感受感受到了优秀的插件对于维基百科社群的重要性。本次访谈，邀请到了专题活跃的代码贡献者For Each element In group ... Next与SuperGrey，聊聊对程序设计和大型语言模型看法和感悟。

1. 问：不知二位是如何了解到程序设计相关知识的？是相关行业的从业者，还是业余爱好者呢？
   • For Each...Next答：我是业余爱好者。最早接触程序设计方面还真就是wikitext，之所以会探索技术方面，当初“魔术字”这个高端名字功不可没😂也感谢wikitext的启蒙，之后我要用到Excel时，上手嵌套公式相当轻松。再之后给Excel写VBA自动化，还有在维基百科上写Lua模块，算正式接触程序编写了。
   • SuperGrey答：我是业者。至于程序设计，最早其实是从C++和C#开始学的。接触到Lua则仰赖一众MediaWiki企划，以前在Fandom和萌娘百科做贡献时，对着前人的源代码和手册一点一点学。此次写的小工具则是以JavaScript为主，虽然对JavaScript稍有涉猎，但在维基百科上写还是经验不足，稍显青涩。
2. 问：是什么促使您投入代码贡献，而不是仅仅编辑条目？
   • For Each...Next答：我大部分时间都在维护与整理格式，而模板是实现目标的重要一环。当时擅长技术且参与专题的编者几乎没有，而我又对写模板有兴趣，就自己动手丰衣足食了。还有此前更新专题访问量时，一直都是手动查询、复制、粘贴，n年后终于不胜其扰。当时正好有个契机，加上我青睐Python强制空白缩进、没有吊尾括号的美学，就开始写Python更新了。
   • SuperGrey答：以前为了给Fandom上某维基的Lua模块添加新功能，故以边学边写的方式掌握了Lua，这算是最早的经历；因而也学会了操作Pywikibot等技能。在中文维基百科上的契机则是2024年初维基百科测试新外观（Vector 2022），导致小跃的voter出现了bug，我就尝试修复了一下，顺便更新了外观。之后也陆续出于各种需要（添加功能、修复bug），制作或改良了一些脚本，对电子游戏专题内的小工具也有参与维护。
3. 问：二位主要负责过哪些工具或功能的开发和维护？
   • For Each...Next答：早期写过一部分模板和模块，近年有PJ:VG/DYK、PJ:VG/HOT之类的半自动更新报告。
   • SuperGrey答：说来惭愧，电子游戏专题内的工具大多为For Each...Next君的贡献。我维护的小工具主要有参考文献整理工具和评选投票器，再来就是这回的ACGATool。
4. 问：您在维基百科贡献代码的过程中，最有成就感的一刻是什么？
   • For Each...Next答：最有成就感的就是实现了之前不敢想的功能。例如，用wikitext很难将en:The English Title转换为{{lang|en|''The English title''}}的效果，但历经千辛万苦用Lua解决后，就感觉很高兴。还有获取专题页面评级清单，以前只能用AWB或者PetScan分等级导出，再合并后调整格式手动更新，等学了Python和SQL，发现自动更新也并非高不可攀。不过现在看当时的代码，就是往事不堪回首了😂
   • SuperGrey答：我主要还是因为自己有了某个需求，为此而编写代码辅助自己。所以最有成就感的时候就是自己先用上了自己的代码的时候。
5. 问：您怎么看待MediaWiki这个软件的？
   • For Each...Next答：支持轻量级的类Markdown标记和强大的HTML，融合了版本控制，还能加入各种扩展。自己搭个服务器，当笔记工具也很不错？
   • SuperGrey答：MediaWiki是强大的“双链”（bi-directional linking）笔记软件，而且还有多人协作功能，比Google Docs神多了。关键这个软件开发的时间还特别早，后来许多新兴笔记软件都借鉴了这个设计。
6. 问：维基百科的代码维护和管理有哪些独特的地方？（如兼容性、社群协作等）
   • For Each...Next答：对程序学习者而言，最需要的就是项目。而维基百科是个很好的平台：从最基础的wikitext，到可以即时生效的HTML/CSS/JS/Lua，再到能写bot的Python/Java，还有真实的数据库可供练习SQL，各方面一应俱全。
   • SuperGrey答：维基百科的版本控制实在是一言难尽（比如日常的“编辑冲突”），Phabricator工单系统更是低效得可怕。幸好维基百科以文本为主，所以大家只需专心写作即可，代码就由MediaWiki维护人员去操心吧。
7. 问：您怎么看待人工智能技术在维基百科式软件开发上的应用？
   • 现今，使用可接受的温和许可的人工智能大语言模型逐渐出现，您认为这些软件适合将部署于维基媒体项目，用于来源搜索、新手引导或其他方面吗？它们有什么其他的潜力？
   • For Each...Next答：不知道专业软件开发者如何使用人工智能。但至少对于我来说，大语言模型比传统搜索引擎友好，能即时且直接地提示我还有哪个方向可以思考。至于给一般读者部署模型，至少就维基百科而言，写条目是在概括，大语言模型也是擅长概括，不确定两者会不会打架😂 PS：顺便说一下条目写作，以前最怕看到游戏评论员说俚语了，传统翻译软件翻不出来，但大语言模型的解释效果就不错。
   • SuperGrey答：AI是现在网络公司的标配，我日常写程序也已经离不开AI。我觉得AI部署到Wikimedia是必经之路，只是还不知道该如何用上。而且实际用上了，还需要人工写作吗？现在AI写稿越来越逼真，不会把我们都给取代了吧
8. 问：小工具目前在电子游戏专题，和中文维基百科社群有什么应用前景？您希望未来维基百科的技术生态朝哪个方向发展？
   • For Each...Next答：全站整体上已经有很多深入人心的小工具，比如TW和链接翻译器。不知道未来小工具会不会逐渐走向领域化、专题化？说起来，全站层面（以及游戏专题层面）可能缺一个快速标记来源可靠性的小工具。至于技术生态，希望能关注一下中文圈的问题，比如各用词的sortkey问题。
   • SuperGrey答：小工具自然很方便，不过中文维基百科的安装器还有点简陋。要是未来真能出现由MediaWiki维护的小工具商店，倒也不错。
9. 问：二位有没有特别想要开发但还没有实现的功能？
   • For Each...Next答：想写个真正稳定的全自动Bot，而不是以半自动名义在PAWS托管，毕竟后者本身也不是用于长期作业的。之前经常有自动停止的现象，不知道是因为平台升级，还是我代码太烂，RAM超过分配限额强行停机了😂
   • SuperGrey答：刚听到For Each...Next君提到的“快速标记来源可靠性”的小工具，其实我一直在用英维开发的CiteUnseen。或许我可以将其迁移到中维，这样就可把中维的来源也加入进去。（更新：CiteUnseen已汉化完成，欢迎使用！）
10. 问：在您设计和开发MediaWiki模板，或是小工具时，总结出什么经验希望与其他开发者分享？
    • For Each...Next答：我认为后勤建设——包括模板和工具制作，也包括制度和方案制作——有个共同点，设计要为实际需求服务，目的也是为了解决实际问题。一方面有了具体需求，设计也会更有动力。另一方面，过早的优化乃万恶之源，如果制作者的出发点只是“越多越好”“英文维基有”或“可能未来有用”，自己却说不出能解决什么问题、怎样解决问题，最后结果可能就是加了删、删了加、加了又删。
    • SuperGrey答：我先回应For Each...Next君说的PAWS停机问题——PAWS是按照作业需求来分配资源的，所以不活跃的作业被停机实属正常，如果要确保一直运行，就只能用自己的服务器了。至于我的经验嘛，最近感触最深的有两条：① 写JavaScript脚本时，如果需要即时结束脚本运行，有两种方式。其一便是装入函数内，这样便可用return来跳出；其二则是直接throw报错，虽然给控制台带来了pollution，但是没事谁看控制台呢？😆 ② MediaWiki开发的OOUI文档既简陋又过时，许多函数细节根本找不到，我看得崩溃死了。幸好有GitHub Copilot帮我借鉴了许多前人的“科研成果”，否则实在是猜不到要怎么写。如果有新手也想蹚这浑水，建议早早用上GitHub Copilot。
11. 问：您会对加入维基百科的技术贡献的新手提出什么建议？
    • For Each...Next答：说不出什么建议，就欢迎加入吧～ 借用我之前的留言：程序很重要，几分钟甚至几秒钟就能完成人做半天还未必能做对的事情，希望有更多的技术贡献者加入维基百科😂
    • SuperGrey答：我觉得编写程序其实有点像作诗。听起来很难，但其实从模仿（抄袭）开始，抄抄改改，很快就能写出像模像样的作品，再然后就可以自己从0开始创作了。至于诗的章法，大概学一下就足够开始写了——诗的门道深着呢，总不能把所有知识都学完再开始创作吧？如果有不会的，还可以让AI教你