LLM大模型 写代码靠谱吗？实测 5 种场景后，发现这些坑一定要避开！！！

作者介绍：崔鹏，计算机学博士，专注 AI 与大数据管理领域研究，拥有十五年数据库、操作系统及存储领域实战经验，兼具 ORACLE OCM、MySQL OCP 等国际权威认证，PostgreSQL ACE，运营技术公众号 "CP 的 PostgreSQL 厨房"，持续输出数据库技术洞察与实践经验。作为全球领先专网通信公司核心技术专家，深耕数据库高可用、高性能架构设计，创新探索 AI 在数据库领域的应用落地，其技术方案有效提升企业级数据库系统稳定性与智能化水平。学术层面，已在AI方向发表2篇SCI论文,将理论研究与工程实践深度结合，形成独特的技术研发视角。

随着人工智能技术的飞速发展，LLM 大模型逐渐走进了程序员的工作场景。“只需输入需求，就能生成可用代码”，这样的宣传让不少开发者心动不已。但 LLM 大模型写代码真的靠谱吗？它能否成为程序员的得力助手？带着这些疑问，我们对 5 种常见的编程场景进行了实测，结果发现其中暗藏不少 “坑”，今天就来一一揭晓，帮大家避避雷！

场景一：基础算法实现

在编程学习和日常开发中，基础算法的实现是很常见的需求。我们选取了经典的快速排序算法作为测试对象，分别使用了 GPT - 4、Claude 3、文心一言、讯飞星火、通义千问这几款主流的 LLM 大模型进行测试。

测试时，我们给模型的提示词为 “用 Python 实现快速排序算法，要求考虑数组为空、数组元素相同等边界情况”。

从生成结果来看，几款模型都能很快生成快速排序的代码框架。其中，GPT - 4 和 Claude 3 生成的代码在基本逻辑上是正确的，能够对一般的数组进行排序。但在处理边界情况时，还是出现了一些问题。比如当数组为空时，GPT - 4 生成的代码没有做特殊处理，直接进行了递归调用，导致程序报错；Claude 3 虽然考虑到了数组为空的情况，但对于数组元素全部相同的情况，排序效率较低，没有进行优化。

文心一言、讯飞星火和通义千问生成的代码则存在更多问题。文心一言生成的代码在分区操作时逻辑有误，导致排序结果不正确；讯飞星火生成的代码在处理较大数组时出现了栈溢出的情况；通义千问生成的代码甚至没有实现快速排序的核心思想，更像是一个冒泡排序的变种。

场景二：Web 接口开发

Web 接口开发是后端开发的重要工作之一，我们以一个简单的用户注册接口为例进行测试，要求实现用户信息的接收、验证（包括用户名长度、密码强度等）、存储到数据库（使用 MySQL）以及返回相应的提示信息等功能，同样使用了上述 5 款模型。

测试提示词为 “用 Java 的 Spring Boot 框架实现一个用户注册接口，需要对用户名（长度至少 6 位）、密码（至少 8 位，包含大小写字母和数字）进行验证，将验证通过的用户信息存储到 MySQL 数据库，最后返回注册成功或失败的提示信息，包括失败原因”。

GPT - 4 生成的代码整体框架比较完整，包含了 Controller 层、Service 层、Entity 层和 Mapper 层的基本结构，也实现了简单的参数验证。但在密码强度验证的正则表达式上存在漏洞，无法正确识别包含特殊字符的密码；同时，在与数据库交互时，没有考虑事务的问题，当出现异常时可能导致数据不一致。

Claude 3 生成的代码在参数验证方面做得相对较好，但在数据库连接配置上使用了硬编码的方式，不符合实际开发中的最佳实践；而且没有对可能出现的 SQL 注入问题进行防范。

文心一言生成的代码缺少了 Service 层，直接在 Controller 层进行数据库操作，不符合分层架构的设计原则；同时，返回的提示信息不够详细，无法准确告知用户注册失败的具体原因。

讯飞星火生成的代码存在较多的语法错误，比如注解的使用不规范、方法参数的定义错误等，需要进行大量的修改才能运行。

通义千问生成的代码在逻辑上存在混乱，比如在验证不通过时，仍然会尝试将用户信息存储到数据库，导致不必要的数据库操作。

场景三：数据库操作

数据库操作是开发中频繁涉及的内容，我们以一个复杂的多表查询为例进行测试，假设有学生表（student，包含 id、name、age、class_id 等字段）、班级表（class，包含 id、name、teacher_id 等字段）和教师表（teacher，包含 id、name、subject 等字段），要求查询出年龄大于 15 岁、所在班级的班主任教数学的学生信息，包括学生姓名、年龄、班级名称和班主任姓名，使用 SQL 语言。

测试提示词为 “有学生表 student（id int, name varchar (20), age int, class_id int）、班级表 class（id int, name varchar (20), teacher_id int）、教师表 teacher（id int, name varchar (20), subject varchar (20)），用 SQL 查询年龄大于 15 岁、所在班级的班主任教数学的学生信息，包括学生姓名、年龄、班级名称和班主任姓名”。

在这个场景中，GPT - 4 和 Claude 3 生成的 SQL 语句基本正确，能够实现查询需求。但 GPT - 4 生成的语句没有使用表别名，导致语句显得冗长；Claude 3 生成的语句则在连接条件上存在一个小问题，将 class 表和 teacher 表的连接条件写成了 class.teacher_id = student.id，而正确的应该是 class.teacher_id = teacher.id，不过稍作修改即可使用。

文心一言生成的 SQL 语句存在明显的逻辑错误，没有正确关联三个表，查询结果包含了大量不符合条件的数据。

讯飞星火生成的语句漏写了年龄大于 15 岁这个条件，而且在表连接时使用了错误的关联字段。

通义千问生成的语句甚至没有使用 JOIN 关键字，而是直接进行了多表查询，导致查询结果出现笛卡尔积，数据完全错误。

场景四：移动端 UI 组件

移动端 UI 组件的开发直接影响用户的使用体验，我们以一个简单的登录页面 UI 组件为例进行测试，要求包含用户名输入框、密码输入框（带密码可见 / 不可见切换功能）、登录按钮、忘记密码链接和注册链接，适配不同的手机屏幕尺寸，使用 React Native 框架，同样测试上述 5 款模型。

测试提示词为 “用 React Native 框架实现一个登录页面 UI 组件，包含用户名输入框（有提示文字 “请输入用户名”）、密码输入框（有提示文字 “请输入密码”，带密码可见 / 不可见切换按钮）、登录按钮（点击时有加载状态）、忘记密码链接（点击跳转到忘记密码页面）和注册链接（点击跳转到注册页面），要求适配不同屏幕尺寸”。

GPT - 4 生成的代码实现了基本的 UI 布局和功能，使用了 Flexbox 进行布局，能够在不同屏幕尺寸上有一定的适配性。但在密码可见 / 不可见切换的逻辑上存在问题，切换按钮点击后没有正确改变密码输入框的显示状态；同时，登录按钮的加载状态没有与实际的登录请求关联起来，只是一个静态的效果。

Claude 3 生成的代码在 UI 样式上比较美观，使用了一些动画效果提升用户体验，但在适配小屏幕手机时，部分元素会出现重叠的情况；而且忘记密码和注册链接的跳转逻辑没有实现，只是简单的文本显示。

文心一言生成的代码结构比较混乱，没有使用 React Native 的最佳实践，比如没有将组件进行拆分，导致代码的可维护性较差；同时，存在一些语法错误，无法直接运行。

讯飞星火生成的代码在密码输入框的切换功能上实现正确，但在整体布局上缺乏灵活性，在大屏幕手机上会显得比较紧凑。

通义千问生成的代码功能比较简单，只实现了基本的输入框和按钮，没有密码切换功能和链接跳转功能，适配性也较差。

场景五：复杂业务逻辑处理

复杂业务逻辑处理往往涉及多个模块的交互和多种条件的判断，我们以一个电商平台的订单生成逻辑为例进行测试，该逻辑需要考虑商品库存是否充足、用户是否有优惠券（有则计算优惠后金额）、是否满足包邮条件（满 199 元包邮，否则计算运费 10 元）、生成订单号（规则为年月日时分秒 + 随机 6 位数字）以及更新商品库存等功能，使用 Python 语言，还是用上述 5 款模型。

测试提示词为 “用 Python 实现电商平台的订单生成逻辑：1. 接收商品 id、购买数量、用户 id、优惠券 id（可为空）；2. 根据商品 id 查询商品单价和当前库存，若库存不足则返回 “库存不足”；3. 根据优惠券 id 查询优惠券面额（若有且有效），计算商品总价（单价 * 数量） - 优惠券面额（不小于 0）；4. 若总价 >= 199 元则运费为 0，否则运费 10 元，最终订单金额为总价 + 运费；5. 生成订单号，格式为年月日时分秒（如 20240520153020） + 6 位随机数字；6. 减少对应商品的库存（购买数量）；7. 返回订单号和最终订单金额。”

GPT - 4 生成的代码在整体逻辑上比较清晰，但在处理优惠券时没有考虑优惠券的有效期，不管优惠券是否过期都进行了抵扣；同时，在更新商品库存时没有使用锁机制，在并发情况下可能导致超卖问题。

Claude 3 生成的代码考虑了优惠券的有效期，但在计算优惠后金额时，当优惠券面额大于商品总价时，没有处理为 0 的情况，导致出现负数；而且生成的订单号随机数部分有可能重复，没有保证唯一性。

文心一言生成的代码在逻辑上存在较多漏洞，比如没有查询商品信息的步骤，直接使用了假设的单价和库存；在计算运费时也没有按照满 199 元包邮的规则来，而是固定运费为 10 元。

讯飞星火生成的代码在生成订单号时，日期格式不正确，没有达到时分秒的精度；同时，在减少商品库存时，没有判断库存是否足够就进行了减少，可能导致库存为负数。

通义千问生成的代码整体逻辑混乱，很多步骤都没有实现，比如优惠券的处理、运费的计算等，只是简单地返回了一个固定的订单号和金额。

实测后发现的这些坑一定要避开

逻辑不严谨：在多个场景中，LLM 生成的代码都存在逻辑漏洞，比如基础算法实现中对边界情况的处理不足，复杂业务逻辑处理中对各种条件的考虑不全面等。这些逻辑问题可能导致程序运行出错，甚至造成严重的后果，所以在使用生成的代码时，一定要仔细检查每一个逻辑分支，进行充分的测试。

细节处理不到位：无论是 Web 接口开发中的密码验证正则表达式错误，还是数据库操作中的事务和 SQL 注入问题，都体现了 LLM 在细节处理上的不足。这些细节往往是保证程序稳定性和安全性的关键，开发者需要对生成代码的细节进行逐一排查，不能掉以轻心。

不符合最佳实践：在 Web 接口开发和移动端 UI 组件开发中，部分 LLM 生成的代码不符合相应框架的最佳实践，比如硬编码数据库连接信息、没有进行组件拆分等。这会导致代码的可维护性、可扩展性变差，增加后续开发和维护的成本，所以要按照开发规范对生成的代码进行调整。

安全性考虑不足：在 Web 接口开发和复杂业务逻辑处理中，LLM 生成的代码缺乏对安全性的考虑，比如没有防范 SQL 注入、并发情况下的超卖问题等。这些安全漏洞可能会被黑客利用，造成数据泄露、财产损失等严重后果，必须要加强安全意识，对生成的代码进行安全检测和加固。

过度依赖通用模板：有些 LLM 生成的代码明显是基于通用模板修改的，没有根据具体的需求进行深入的定制，比如通义千问在基础算法实现和移动端 UI 组件开发中生成的代码。这样的代码可能无法满足实际业务需求，需要开发者结合具体情况进行大量的修改，不能盲目使用。

使用 LLM 大模型写代码的建议

作为辅助工具而非替代：LLM 大模型可以帮助开发者快速生成代码框架和一些简单的功能实现，提高开发效率，但不能完全依赖它来完成所有的编程工作，开发者仍需要对代码进行把控和优化。

严格测试不可少：对于 LLM 生成的代码，要进行多维度、全面的测试，包括单元测试、集成测试、性能测试和安全测试等，确保代码的正确性、稳定性和安全性。

结合业务深入修改：LLM 生成的代码往往比较通用，需要开发者结合具体的业务场景进行深入的修改和完善，使其更符合实际需求。

不断学习提升自己：虽然 LLM 能辅助写代码，但开发者自身的编程能力和业务理解能力仍然是关键。要不断学习新的技术和知识，提高自己的开发水平，才能更好地利用 LLM 等工具。

总之，LLM 大模型在写代码方面有一定的辅助作用，但并不完全靠谱，存在诸多需要避开的坑。开发者在使用时要保持理性和谨慎，充分发挥其优势，同时规避其不足，让它真正成为提高开发效率的好帮手。