人工智能辅助编程的体会

今年开年，发现确实有点新东西——大语言模型的部署成本终于降到了我可以实践的水平。这个地方已经沉寂了许久，尽管我也写了一些东西，但内容多是关于搜索引擎结果质量下降之类的"技术退步"吐槽，因此都没公开发布。

这次我开了一个名为长石(feldspar)的项目，实现 ssh 本地转发功能。这个项目本身倒是平平无奇，就是希望把两三句长很的 ssh 命令写成一句短点的命令而已，同时实现一些连接的健康检查和重连机制。但我对 ssh 和 golang 的认识并不足以支持我在实现这个项目。所以，让大语言模型生成代码就成了我的最佳选择。当然，因为时间精力有限，开发的过程断断续续，但到今天早上算是把自己预想中的功能都实现了。

初期，我自己尝试过 VSCode 的一些相关的辅助编程插件，但是感觉还是自己写个简单的脚本来交互感觉更心安一些。结果很自然地，这个用来生成代码的 Python 脚本的行数超过了它所生成的代码。最后阶段的主要功能的实现，基本上都是我用这个脚本调用云端的大模型接口生成的代码。

我在这个过程中，还是了解到了一些局限，云端尽管比本地模型效果好，但也是有上限的。像接口能返回的最大长度只有 8192 个 token 。如果使用推理模型，输出会包含推理过程，这个额度就显得捉襟见肘，所以要对输出的提示词等等进行一些调整。大模型输入的限制我目前还没有触及，毕竟这个项目到现在还不到五百行。卡住超时当然也是家常便饭，但经历了上个月的深度求索的那个状态，也还在容忍范围内。还有一点我觉得应该强调一下，如果是我比较熟悉的东西，我直接改远比写指令让大模型改来得快。

有一个观点是大模型用来生成模板之类无聊的代码的是比较好的，但是核心库和架构不行。我倒是觉得这很可能是没有找到合适的指令。也许这个观点还跟目前使用的 Cursor AI 这类工具有关系。至少我使用推理模型来生成代码时，确实在阅读推理过程时得到了几个解决当时问题的关键启发，说明推理大模型这方面的潜力还是有的。当然，如果想要更灵活地调整指令，来应对更复杂的场景，类似 Cursor AI 这样的工具反而会让人困惑。

这篇先到这里。