从手写代码转向AI辅助工程

# 再见，VSCode 🍻

好吧，我想是时候正式和 VSCode 说再见了 🍻

在与 AI 协作的过程中，我一直努力对自己保持诚实，不断判断哪些是旧习惯和自我意识在作怪，哪些才是真正有价值的付出。

我已经好几个月没有手写代码了，而且在开发工作的大部分时间里，我也开始逐渐摆脱阅读代码的习惯。直到最新一代模型出现，这件事才真正成为可能。

我所处理的问题会生成极其密集的计算函数，这些函数本来就不容易阅读。我做计算编程已有 15 年，可以告诉你：用代码实现算法真的很痛苦。

漏掉一个括号、用错一个变量、搞错一个符号，都太容易发生了。五年前我写 OpenFracture——我为 Unity 开发的网格破碎库——时，光是修复所有的索引和三角形绕向问题就花了好几个星期。

现在回头看那段经历，就像 C 程序员回望写汇编语言一样——"感谢上天，我再也不用那样做了！"

别误会，我非常热爱手写代码。我喜欢那种工艺感，喜欢辨别好坏设计背后的科学与直觉，喜欢那种代码就是自我延伸的感觉。

但这并不是我的身份标签，也不是我作为工程师所能提供的价值所在——我的价值在于解决难题。有了 AI，我现在可以着手处理那些以前对我来说遥不可及的有趣问题。

"那么 Dan，如果你既不写代码也不读代码，你怎么知道它生成的内容是否正确？"

问得好！

1. 在图形编程中，你仍然需要了解硬件如何执行代码、内存使用情况、纹理精度、内存共享方式以及热点路径所在。我会运用自己的工程知识提出有针对性的问题，并获取详细的反馈报告。我最喜欢的一点是，对于我不理解的概念，我可以反复追问，直到真正弄懂为止。

2. 测试、测试、再测试。测试着色器很困难，但 AI 让创建这些测试变得容易。评估着色器代码片段、用测试数据填充缓冲区、执行代码、读回缓冲区并进行评估——这些都轻而易举。

3. 详细的性能指标。使用 WebGPU，我可以插入计时查询，并获得每段代码性能表现的详细报告卡。我发现这在定位热点、确定优化重点时极具价值。如果你感兴趣，我写了一篇关于如何操作的博客文章。（https://threejsroadmap.com/blog/profiling-webgpu）

4. 技术报告。这是我最喜欢做的事情之一。比如我想优化某个区域的性能，或者想更好地理解代码某个部分的工作方式。我会提示 AI 为我生成一份带有图表和表格的 HTML 报告。这样一来，我不必费力解读代码，而是拥有一份美观、易于阅读的文档。

当然，我是否会因此错过一些原本可能发现的问题？有可能。但我从不是纯粹主义者，也从未自称是。我强烈反对过早优化。就像你或许可以通过用汇编代替 C 来榨取更多性能一样。

我相信自己在一段时间内仍会继续审阅代码，但我会持续将精力转移到构建工具和报告上，因为它们能提供更有用、更具可操作性的信息。