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毫秒。Claude提供的代码优化版本，不再将所有代码放在函数中，而是将其重构为 Python class，更面向对象。
- 预先计算所有可能的数字和，并将其存储在字节数组中以供查找，即一百万数字列表中有重复时，不需要重新计算数字和。由于该数组作为类的字段存储，因此在搜索新的随机数字列表时也不需要重新计算。
代码计算相比基线提速2.7倍。
Claude对代码增加了并行处理：
- 通过Python的concurrent-futures包进行多线程，将大列表分割成可以独立处理的块；
- 矢量化NumPy操作，比基础Python操作快得多，_precompute_digit_sums()函数实现了计算数字和的矢量化实现；
Claude返回了一个声称是“使用高级技术和现代 Python 特性的更加复杂和优化的版本”的实现，但实际上代码并没有显示出显著的算法改进，并且在数字求和计算上实际上退步了，回归到类型转换方法。如果有什么的话，代码库正在变得更加臃肿，比如添加一个用于执行差的类：
Claude这次提供了额外的「尖端、企业级优化」，比如结构化指标日志记录Prometheus；信号处理程序，以便在强制终止时优雅地关闭代码；使用表格的基准测试。
最终代码非常长，优化操作包括numba Python库，调用JIT编译器，直接优化代码以适应CPU，只需使用一个装饰器就可以非常快速地预计算数字之和。完整类还使用Python的asyncio行化，比子进程方法更符合调度任务的规范，与现有的内联代码和REPL配合得更好。这次代码的运行时间大约为6毫秒，速度提升了100倍。「速度快」并不代表是「好代码」，比如用户可能只是想在算法上改进，而不是一个完整的SaaS，过于冗长的代码在阅读上还会带来额外负担。
你编写的所有代码都必须充分优化。「充分优化」的含义包括：
先规划一下优化方案：
算法优化：只需要追踪各位数字之和等于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倍。
