我通过自行发明“Brilliant”代码，凭借AI的观点超越了AI

Source: Dev.to

Background

我先描述了一个简单的 API 客户端，然后开始尝试使用 mixin。我想创建自己的 mixin 库，使其速度快于 ts-mixer。在设置基准测试后，我厌倦了数小时的测试，转而求助于大型语言模型（LLM）。

Experiment with AI

我让 AI 尽可能快地实现代码，并设置了完善的测试和基准，以便 AI 能“抢走我的工作”。当我去买面包时，模型在代码上不断迭代。它的确提升了性能，但也建议牺牲一些规格和正确性——这是我无法接受的。

反复尝试后发现，AI 在几个相似实现之间循环，忽视我的备注，并且不断引入错误再修复。最终我放弃了 AI，自己继续工作，花了更多时间，却没有多买到面包。

My Own Implementation

第二天以全新的思路，我在仅 40 行代码中构建了一个 CompositeMap，速度极快。该映射对键的顺序有特殊处理：[A, B] 不等于 [B, A]。已有的库以及 TC39 的复合键提案都存在，但它们的速度不足以满足我的需求。

How It Works

• 为每个对象分配递增的 ID。
• 所有键都被哈希为位掩码，使查找超快且不受顺序影响。
• 位掩码技术在标志处理和游戏开发中很常见。
• 如果 mixin 的数量超过标准整数的 32 位，则实现会升级为 BigInt，仍然比其他库更快。
• 实际上，超过 32 种 mixin 变体的情况很少见，因此该方案对大多数情况都适用。

源码可在此处获取：

Reflections on AI

AI 称最终代码为“brilliant”，并称其为“Performance Masterclass”，但它本身并不能生成该方案。这说明 AI 只是在过去人类工作上进行训练，无法发明真正没有文档记录的全新方法。

• 你能比 AI 更好吗？ 能——人类的创造力和深度理解仍然超越当前 LLM 能产出的水平。
• 编码技能可以被取代吗？ 只有当你在不依赖 LLM 的情况下无法编码时，才会变得可替代。
• 我使用 LLM 节省了时间吗？ 在本例中没有。提示模型需要长时间且耗神的会话，我本可以直接编码更快得到结果。

Conclusion

虽然 AI 能在增量改进上提供帮助，但突破性的性能提升仍然常常需要人类洞察。将实际实验与一点幽默（表情包）相结合，可以让这些“严肃”话题更具吸引力。