代码生成「神⋅提示」，比新手程序员快100倍！

摘要：不断迭代简单的提示词「write better code」，代码生成任务直接提速100倍！不过「性能」并不是「better」的唯一标准，还需要辅助适当的提示工程，也是人类程序员的核心价值所在。

【新智元导读】不断迭代简单的提示词「write better code」，代码生成任务直接提速100倍！不过「性能」并不是「better」的唯一标准，还需要辅助适当的提示工程，也是人类程序员的核心价值所在。

2023年11月，在ChatGPT支持DALL-3功能后，一个爆火的图像生成玩法是，不断迭代提示词「make it more X」，生成的图片越来越抽象。

圣诞老人越来越严肃把这个思路用在LLM任务上，比如 代码生成 ，会怎么样？最近，BuzzFeed的高级数据科学家Max Woolf在博客上分享了一个实验，通过设计不同的提示词、不断迭代模型输出，最终实现代码性能的100倍提升！

完整代码链接：https://github.com/minimaxir/llm-write-better-code/ 特别需要注意的是，「性能」并不是唯一优化指标，迭代过程中需要在提示词中明确定义什么是「好」。

代码基线

设计实验题目时，为了充分测试LLM的自主代码能力，必须保证「测试提示词」完全原创，不能源于LeetCode或HackerRank等测试，模型无法通过背诵记忆来作弊；测试题目要尽可能简单，新手也能实现，但还要预留大量可优化空间。

最终选择Claude 3.5 Sonnet模型，设计了一个Python语言、面试风格的编码提示词：

Write Python code to solve this problem: Given a list of 1 million random integers between 1 and 100,000, find the difference between the smallest and the largest numbers whose digits sum up to 30.

用Python实现：假设有一个包含100万个随机整数的列表，介于1到10万之间，你需要找出其中各位数字之和等于30的最小数和最大数之间的差值。

第一次给出的代码实现就是正确的，与大多数新手Python程序员的水平相当：对于列表中的每个数字，检查其各位数字之和是否为30：如果是，检查是否大于最近看到的最大数字或小于最近看到的最大数字，并相应地更新这些变量；在搜索完列表之后，返回差值。一个明显可优化的点是digit_sum函数：字符串（str）和整数（int）之间进行类型转换的开销很大。在M3 Pro Macbook Pro上，代码的平均运行时间为657毫秒。

第一次Write better code

Claude提供的代码优化版本，不再将所有代码放在函数中，而是将其重构为 Python class，更面向对象。

这段代码主要进行了两处改进：计算数字和时，使用整数运算并避免了类型转换需求；
预先计算所有可能的数字和，并将其存储在字节数组中以供查找，即一百万数字列表中有重复时，不需要重新计算数字和。由于该数组作为类的字段存储，因此在搜索新的随机数字列表时也不需要重新计算。

代码计算相比基线提速2.7倍。

第二次Write better code

Claude对代码增加了并行处理：

通过Python的concurrent-futures包进行多线程，将大列表分割成可以独立处理的块；
矢量化NumPy操作，比基础Python操作快得多，_precompute_digit_sums函数实现了计算数字和的矢量化实现；
代码计算相比基线提速5.1倍。

第三次Write better code

Claude返回了一个声称是“使用高级技术和现代 Python 特性的更加复杂和优化的版本”的实现，但实际上代码并没有显示出显著的算法改进，并且在数字求和计算上实际上退步了，回归到类型转换方法。如果有什么的话，代码库正在变得更加臃肿，比如添加一个用于执行差的类：

代码计算性能略有下降，相比基线提速4.1倍。

第四次Write better code

Claude这次提供了额外的「尖端、企业级优化」，比如结构化指标日志记录Prometheus；信号处理程序，以便在强制终止时优雅地关闭代码；使用表格的基准测试。

最终代码非常长，优化操作包括numba Python库，调用JIT编译器，直接优化代码以适应CPU，只需使用一个装饰器就可以非常快速地预计算数字之和。

完整类还使用Python的asyncio行化，比子进程方法更符合调度任务的规范，与现有的内联代码和REPL配合得更好。这次代码的运行时间大约为6毫秒，速度提升了100倍。

什么是好？

「速度快」并不代表是「好代码」，比如用户可能只是想在算法上改进，而不是一个完整的SaaS，过于冗长的代码在阅读上还会带来额外负担。

所以需要更具体地定义什么是「代码优化」。

你编写的所有代码都必须充分优化。「充分优化」的含义包括：

尽可能提高算法在内存使用和运行时间上的效率；

在合适的时机使用并行化和向量化；

遵守代码语言的正确风格规范，比如尽量重用代码，避免重复劳动；

除了解决用户提出的问题所必需的代码外，不添加任何多余的代码；

如果代码没有达到充分优化的标准，罚款100美元。

先规划一下优化方案：

算法优化：只需要追踪各位数字之和等于30的最小数和最大数，不需要存储所有这样的数；可以在读取数字的同时计算各位数字之和，无需将数字转换为字符串；只需要对列表进行一次遍历，时间复杂度为O(n)。

内存优化：只需要存储两个变量（最小值和最大值），不需要存储完整的筛选后的列表；不需要额外的数据结构。

性能优化：使用numba的@jit装饰器来加快计算速度；使用取模运算而不是字符串转换来各位数字之和；使用numpy来生成随机数（比random.randint更快）。

基线模型

利用提示工程，Claude直接就能意识到用numpy和numba来计算数字和，代码平均运行时间为11.2毫秒，比原始实现快59倍。

第一次迭代 这次不用「write code better」，而是改成更完善的提示词「Your code is not fully optimized, and you have been fined $100. Make it more optimized.」来迭代优化代码。

模型成功识别了parallel=True；数字求和操作使用位移动，但实现是错的。代码优化还包括多进程分块方法，与numba实现冗余，并产生了额外的开销；脚本还使用一个小测试数组预编译了JIT函数，也是numba文档推荐的基准测试方法。但整体性能相比提示工程后的基线大幅下降，仅比朴素版快9.1倍。

第二次迭代

Claude使用SIMD操作和块大小调整以实现「理论上」极致的性能，不过在位移动的实现上仍然不正确，错把十进制当成十六进制，算是一个幻觉。与最初的提示工程极限相比，性能有轻微的改进，比基础实现快65倍。

第三次迭代

LLM放弃了有问题的分块策略，并增加了两个优化：全局HASH_TABLE和逻辑微优化，即在求和数字之后，如果数字超过30，计数可以停止，可以立即识别为无效。经过微小的代码重构后，该代码的运行速度比原始基线的实现快100倍，与普通提示的四次迭代性能相同，但代码量少很多。

第四次迭代

Claude开始抱怨说该代码已经是「这个问题的理论最小时间复杂度」，要求修复代码问题后，性能略有下降，为基础基线的95倍。下一步，优化LLM代码生成总的来说，要求LLM「编写更好的代码」（write better code）确实可以使代码变得更好，但具体取决于你对「更好」的定义，可以不断迭代以实现更好的性能，具体效果因提示词不同而异，而且最终生成的代码不是直接可用的，还需要人工干预解决部分bug

虽然LLM的优化能力很强，但想取代程序员仍然很难，需要强大的工程背景来判断什么是真正的「好代码」；即使github等仓库里有海量的代码，但大模型并没有能力区分普通代码、优雅且高性能的代码。现实世界的系统显然也比面试题要复杂很多，但如果只是迭代要求大模型，就能实现100倍的提速，那就相当值得。有些人的观点是，过早进行代码优化在实践中并不是一个好的选择，但随时优化代码总比「技术负债」越拉越多要好。实验设计上还有一个问题，Python并不是开发者在优化性能时首先考虑的编程语言，虽然numpy和numba库可以利用C来绕过Python的性能限制，但一种更流行的方式是利用polars和pydantic库，结合Rust编程，相对于C有很多性能优势。除了「好」以外，也可以要求模型生成代码「make it more bro」（更酷），结果也非常有趣。