从简陋QuickQR的脱离

QuickQR Enhanced，终于完成了。

说起原来的QuickQR，外观简陋，功能只是把文本转换成二维码，简直是"能用就行"精神的化身般的工具。

但这次，随着网站改版的流程，“既然如此就把外观弄漂亮，功能也扩展一下”——以轻松的心情着手，结果成了噩梦的开始。

结果，搭载了WiFi设置、联系人、事件、位置信息、批处理、预设管理、历史管理、相机读取、打印功能，成了远超当初设想的高功能工具。

与AI讨论让功能增殖

“如果能做WiFi设置的二维码就方便了” “也想对应联系人的vCard” “位置信息二维码应该很有趣” “如果能批处理就高效了”

与AI讨论时，想法不断涌现，不知不觉功能就增殖了。

生成AI不断提议"这样的功能怎么样？"，我就不由得说"那也不错！"。简直是功能的通货膨胀状态。

1000行的壁垒 - 感受到AI极限的瞬间

最初500行左右很顺利。AI输出的代码几乎一次就能运行，我想"这很轻松啊"。

但是超过1000行后情况就完全变了。

  • 代码输出耗时异常（能泡好一碗方便面的程度）
  • 输出的代码无法运行
  • 请求微调却破坏了别的部分
  • 交流增多，修正的修正的修正…

“啊，这是AI的极限”——感受到的瞬间。

大规模代码库时，AI也无法完全掌握整体。就像人类一样，撞上了复杂性的墙。

AI时代设计阶段的革命 - 看到的新方法论

这次经验让我再次感受到设计阶段的重要性。不，不仅仅是重要性。是生死攸关的程度。

传统开发中，“先做出能动的东西，之后重构"的方法也可以。但对AI就不行。

准备八分，AI一二分？

自古有"准备八分"的说法，但AI开发时代可能已经是**“准备九分”**了。

从这次经验中看到的，是需要以更高的分辨率描绘到达开发完成目标的剧本。

具体来说：

❌ 不好的例子："添加WiFi功能"
⭕ 好的例子："用WiFiForm类管理SSID/密码/安全设置，
          向QRGenerator类传递字符串，以WIFI:T:WPA;S:...格式生成"

对AI说"添加WiFi功能”，它会迷失在如何嵌入现有代码的哪里。但如果事先明确接口和责任范围，AI就能毫不迷茫地实现。

依赖关系的可视化是生命线

特别是松耦合的设计。需要减少功能和代码的依赖，构建一个变更不会影响其他部分的结构。

这次深刻体会到，AI不擅长把握依赖关系。人类能直觉地知道"啊，改了这里会影响那里"，但AI看不到。

最终，切换到了分割文件、逐步固化能确实运行的部分的策略：

  • core_utils.js - 基本工具（不依赖其他）
  • ui_manager.js - UI相关（仅依赖core_utils）
  • data_manager.js - 数据管理（仅依赖core_utils）
  • qr_generator.js - 二维码生成逻辑（完全独立）

就像这样。让各个部分独立运行，明确接口。正是松耦合的方法。

AI共存的新方法论

这方面从这次经验中隐约看到了一些东西，但今后需要确立好的方法。

这大概会成为在代码生成AI共存中新诞生的方法论。

在传统设计手法之外：

  • AI容易理解的模块边界设计
  • 考虑上下文量的功能分割
  • 掌握AI能保持输出质量的代码规模
  • 人类最后能保证质量的粒度设计

虽然还在摸索，但能确定的是**“AI变聪明了所以设计可以随便"是大错特错**。

反而相反，正因为与AI协作，更需要精密的设计。

1000行的教训 - 与AI上下文限制的相处之道

“AI不是万能的"虽然脑子知道，但通过1000行的壁垒亲身体会了。

人类也有一次能掌握的信息量的极限。AI也一样。不，某种意义上比人类限制更严格。

因此，将问题分解为AI一次能处理的粒度的技术变得重要。这与传统的"关注点分离"稍有不同，可以称为**“AI上下文分离”**的新观点。

关于这方面的发现和方法论，想在别的机会详细谈谈。AI时代的工程，还有大量未开拓的领域。

名为坚持的时间小偷

最终完成了令人比较满意的东西，就"算了"吧。

但回顾起来，一旦开始坚持就总是适得其反的性格。

打印功能，说实话是"谁会用啊？“级别的功能却花了最多时间。因为是休息日，就在没人用的功能上热情投入的愚蠢者。

// 创建打印用HTML文档
const printHTML = `
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>二维码打印</title>
    <style>
        @page {
            margin: 2cm;
            size: A4;
        }
        // ... 延绵不断的CSS

但是，偶尔这样认真制作的时间也很重要吧。平时都是效率优先快速制作，但有时也需要坚持到满意为止的时间。

对二维码的感谢和尊重

这次重做QuickQR时，再次实感到二维码技术的出色。

二维码是1994年由日本汽车零件制造商电装（现电装波）的原昌宏先生及其团队发明的。

从电装现场诞生的技术

开发的契机是电装制造现场的迫切要求。

当时，为了部件管理要并排读取10个左右的条形码，作业效率非常差，现场作业人员提出"太累了"“不能读取得更快吗？“的不满和要求。

原昌宏先生从1992年开始从事条形码扫描仪和光学字符识别（OCR）装置的开发，但接到现场的呼声后，着手开发"能容纳比条形码更多信息的码”。

来自围棋棋子的灵感

有趣的是，二维码的位置检测图案（那个方形标记）的想法来自围棋的棋子。

原先生在午休时下围棋，发现"黑白比率为1:1:3:1:1的图案在自然界几乎不存在”，并将其应用于位置检测。

正是从玩心和观察力诞生的发明。

专利无偿开放的英明决断

而且最出色的是，电装将二维码的专利无偿开放了。

通常使用他人的专利需要许可，但电装波明言"对于规格化的二维码不行使权利”。

根据原先生的说法，这个决定的理由是：

“即使做出再好的码，如果周边设备等基础设施没有整备，也无法自由安心地使用。通过开放专利让其他公司也推进基础设施整备，考虑尽快普及二维码”

“希望更多人使用二维码”

开发者这种纯粹的想法，实现了二维码的全球普及。

世界性评价和获奖

这一功绩也得到了世界认可，2014年获得欧洲发明家奖的"Popular Prize”，2023年也获得了日本学士院赏·恩赐赏。

现在，二维码在全世界使用，特别是随着智能手机的普及，在支付、信息共享、认证等各种场合被活用。

原先生说"在支付中使用是意料之外的”，但技术超越设想发展，也是因为开放了专利。

作为工程师的感谢

这次制作QuickQR Enhanced时，再次感受到二维码这项技术的恩惠。

  • 能轻松共享WiFi设置
  • 联系人交换变得顺畅
  • 能瞬间传达位置信息
  • 不需要手动输入URL

这一切都是由30年前在日本诞生的技术，以及将其无偿提供给世界的工程师的志向实现的。

想向原昌宏先生和电装团队的各位致以衷心的感谢和尊重。

总结 - 对技术的爱与传承

通过QuickQR Enhanced的开发，实感到技术进步是许多人的积累。

有二维码这样出色的基础技术，有无偿提供它的前辈，现在的我们才能制作新工具。

虽然有时会过于坚持而花费太多时间，但那也许是对技术的爱的体现。

而且最重要的是，即使在AI时代，工程师的设计能力和洞察力也不可或缺，这一点我切身学到了。

不过是二维码生成工具，但也是二维码生成工具。

即使是小小的工具，也蕴含着技术历史和许多人的想法。

QuickQR Enhanced: https://aoiroinc.com/zh/tools/quick-qr/

参考文献·出处

关于二维码的历史·开发经纬：