AI 写代码到底靠不靠谱？我在真实项目里试了半年，说点实话

做开发这行十来年，我对新工具的接受度一直算高的。但去年底AI编程工具一下子火起来的时候，我其实挺抵触的——补全个变量名、生成个模板函数，这种程度的“智能”我十年前就用过，没什么稀奇的。后来一个长期合作的项目方找到我，说要做一个数据采集加可视化的内部系统，工期压得很紧，人手又不够。我那天晚上坐在电脑前想了想，决定赌一把：接下来半年，所有能用AI写的代码，我全让AI来写，看它到底能帮我省多少事、挖多少坑。

这半年我基本把主流AI编程工具都试了一遍，包括对话式的、IDE内嵌的、自动补全的、能跑测试的。结论先说：AI写代码在真实项目里不是“行不行”的问题，而是“怎么用”的问题。用对了，效率翻倍；用错了，翻车现场一个接一个。这篇就把我这半年的实测过程，包括工具选型、工作流改造、翻车案例、排查思路，全部摊开来讲。想用AI提升开发效率但不知道怎么下手的，或者已经用了但总觉得不靠谱的，这篇应该能帮你省不少摸索时间。

1. 半年实测的整体思路与初始判断

1.1 先搞清楚AI写代码的本质

在开始之前，我花了两天时间做了一件事——把市面上主流的AI编程工具注册了个遍，逐个跑了一些我手头的历史项目代码，看它们到底擅长什么、不擅长什么。这个过程看起来是浪费时间，后来证明非常值。

我的核心判断是这样的：AI写代码本质上是一个“超级熟练但不懂业务的初级工程师”。它的知识面非常广，几乎没有它没见过的语法和框架，但它对你项目的业务逻辑、数据流向、历史包袱一无所知。它生成的代码，语法层面大概率是好的，但设计层面得靠你来兜底。

这个类比非常重要。你不会把一个刚毕业的新人直接扔去改核心交易系统的支付逻辑，但你完全可以让他去写单元测试、写简单的CRUD接口、做数据格式转换。AI也是这样——你要给它划定边界，而不是让它自由发挥。

我当时做的第一件事，就是把我手头项目的代码结构、技术栈、目录规范整理成一份说明文档，每次让AI写东西之前，先把这份文档的关键部分粘贴给它。有点麻烦，但效果立竿见影。很多用AI写代码翻车的人，问题就出在上下文给得太少。

1.2 我的测试场景与判断标准

我选取的测试项目是一个典型的业务管理系统：后端是常见的Web框架，前端是组件化的单页应用，数据库是关系型数据库，另外还涉及定时任务、文件上传、第三方接口对接这些常规模块。整体代码量大概在两万行左右，工作量适中，复杂度也刚好能覆盖大多数日常开发场景。

我给自己定了几条判断标准，半年后回过头看，这几条标准非常重要：

• 代码可运行性：生成的代码能否直接跑起来，而不是光看着像那么回事。
• 代码可维护性：一周之后你再看这段代码，能不能快速看懂、能不能改。
• 与现有项目的契合度：是否符合当前项目的分层方式、命名规范、异常处理习惯。
• 返工成本：AI生成的代码需要你人工改多少地方才能用。
• 时间账：从写提示词到调试通过的总耗时，和纯手工写相比是不是真的更省时间。

这些标准不是一开始就定好的，是踩了几个坑之后总结出来的。最开始我只关心“能不能跑”，后来发现“能跑但改不动”比“不能跑”更让人崩溃。

2. 核心场景拆解：AI到底擅长干什么

2.1 让AI做“体力活”的正确姿势

半年的实测下来，我发现AI最适合干的活有一个共同特点：目标明确、边界清晰、重复性高。这类活通常是项目里最消耗时间但最没技术含量的部分。

以我项目里的一个实际需求为例：我需要对几十张数据表做统一的审计日志记录，每张表在新增、修改、删除时都要把操作人和操作内容记录下来。这个需求用纯手写的方式来做，需要为每张表单独写一套逻辑，虽然不是很难，但就是量大、枯燥。

AI在这种场景下简直是神兵利器。我把其中一张表的完整代码贴给AI，然后说“按照同样的模式，为剩下的这些表各生成一套审计逻辑，字段映射关系参考表结构文档”。生成的代码基本能用，只需要处理几个边界情况。这个需求如果手工写，我估计得花两到三天的工夫，用AI只花了一个上午。

我还发现一个规律：给AI的示例代码质量越高，生成的代码质量越好。这跟带新人是一样的——你给新人一个烂代码当模板，他大概率给你写出更烂的代码。所以我会在项目里维护一份“最佳实践示例”目录，专门放那些经过验证的、写法规范的功能模块。交给AI任务时，先从里面挑一个最接近的当参考。这个习惯让AI生成代码的返工率下降得非常明显。

2.2 辅助调试与代码解释的实际表现

AI的另一个让我比较惊喜的能力是调试辅助。传统调试流程是：报错信息、搜索引擎、翻文档、试错。有了AI之后，这个流程被大幅压缩了。

遇到报错时，直接把错误堆栈和出错的代码块扔给AI，它通常能快速定位问题。尤其在以下几种情况里表现很好：空指针和未定义这类运行时错误、类型不匹配问题、常见的并发问题、环境配置导致的依赖冲突。这些问题的共同特点是“网上答案很多但都比较分散”，AI相当于帮我把这些答案汇总并结合我的具体代码给出了针对性方案。

更让我意外的是AI在“解读老代码”上的能力。项目里有一块业务逻辑，是几年前的一个同事写的，结构很绕，注释也少。我把这段代码贴给AI，让它给我讲讲这段代码到底在做什么、数据是怎么流转的。AI不仅讲清楚了，还指出了其中几个可能存在的逻辑边界问题。在真实项目里，接手别人留下的代码是常有的事，这个能力帮我省了不少脑细胞。

2.3 不擅长与不能碰的领域

和上面的“体力活”相比，有些场景我是试过之后坚决不让AI碰的。

最容易翻车的是跨模块的复杂业务逻辑。比如你有一个订单系统，里面涉及库存锁定、优惠计算、支付回调、积分变动，这些模块之间有先后顺序和状态流转。我尝试让AI写这种逻辑，结果就是它把每个环节的代码都写出来了，但环节之间的状态同步和异常回滚处理完全对不上。业务耦合度越高，AI越容易犯错，因为它的训练数据里并不包含你项目的业务规则。

另一个不能碰的是任何涉及历史数据兼容的逻辑。老项目里总有那么几个表，字段语义跟今天已经完全不一样了，或者存了一些历史脏数据。这种带“历史包袱”的代码，AI是理解不了的。我做过一次让AI改一段数据清洗逻辑，指令是“兼容历史数据”，结果它生成了一堆在理想数据假设下才成立的代码，跑在老数据上直接炸了。

我的个人经验是：核心业务模型、资金相关逻辑、权限控制这三类，永远不要交给AI自由发挥。最多让AI生成个雏形，剩余的边界条件、异常路径、安全校验，必须一个分支一个分支地人工确认。

3. 踩过的坑与翻车现场实录

3.1 “图上看起来没问题”的幻觉代码

AI编程最坑的地方不是代码写错，而是写错的时候看起来完全没错。它会在你没注意到的细节上犯一些特别基础的错误，比如调用了一个根本不存在的方法、传参顺序反了、对象属性名和实际定义对不上。代码缩进、换行、语法的高亮都正常，你扫一眼根本发现不了问题，一运行就报错。

这有点像AI在“一本正经地胡说八道”，而我得像个侦探一样去验证它每一句话的真实性。有一个案例让我印象特别深刻：我让AI写一个文件批量重命名的脚本，它生成了一段看起来非常简洁的代码。第一次运行没问题，我以为稳了。到第二周这个脚本用到一批特定格式的文件名时突然报错，排查了半天发现是AI用了一个“看起来像标准库但实际不存在”的辅助函数。当时我第一反应是“我X，还有这种操作？”

吃过几次亏之后，我总结出一个原则：AI生成代码的第一版，必须默认它是错的。每一处关键调用都要去查官方文档确认，每一个边界条件都要自己补测试用例。这个过程熟练之后会快很多——我不是每行都去查，而是把注意力集中在那些不熟悉的库、不常见的写法上。

3.2 上下文爆炸与“夹带私货”

另一个大坑是AI的“上下文遗忘”和“自作主张”。

我在一个功能迭代里，前前后后让AI改了同一个函数四五次。前面几次对话它还记着需求，到后面它就“忘”了你最初设定的限制条件，开始按它自己的理解发挥。有一次它甚至在一个支付回调里，自作主张地加了一个重试逻辑，理由是“考虑到网络不稳定”。单看这个逻辑没毛病，但它没有做幂等处理，差点造成重复入账。如果没在代码评审时发现这个问题，上线后果会很严重。

这让我养成一个习惯：每次让AI改代码，都在提示词里重新完整描述一遍上下文，核心约束条件更是一字不变地反复强调。提示词长一点没关系，总比它自己脑补要安全得多。

还有一个连带问题：AI特别容易在改动一个地方的时候，“顺手”把相邻的代码也改了。它不会主动告诉你它动了额外的部分。所以我现在每次拿到AI的产出，第一件事就是用代码对比工具看一下，它到底改了什么，是不是只有我要求的那些改动。出现额外改动，先问清楚为什么要改，如果给不出有说服力的理由，一律回退。

3.3 代码风格与“知识老化”问题

AI的训练数据虽然量大，但存在明显的时效性问题。我们项目用的技术栈，在AI的训练数据里属于“主流但不算最新”的那种，所以问题还不太大。但有一次我尝试让它写一个基于新版本框架的模块，它生成代码的过程很流畅，但用的API是两三个版本之前的老写法——在新版本里已经标记为废弃了。

更麻烦的是，这些“老写法”不会报错，只是运行效率变差，或者在新版本里行为变得不同。也就是说，表面看代码没问题，实际上是靠兼容层在硬撑着，这会埋下技术债。现在我的处理方式是：让AI工作之前，先给它技术栈的具体版本号，并明令它只用官方文档中当前版本的API。

关于代码风格，我还发现一个有意思的现象。同一个AI工具，你放不同风格的代码给它参考，它生成的代码风格会偏向你给它看的东西。也就是说，如果你的项目里既有老代码又有新代码、既有驼峰命名又有下划线命名，AI生成的代码风格就会随机漂移。要解决这个问题，除了给它规范和示例，更省事的做法是：小组统一用一个自动格式化工具，生成完直接格式化。风格问题比逻辑问题好解决多了。

4. 工具选型和整体开发流程改造

4.1 如何挑选适合自己的AI编程工具

选工具这件事，我在半年里换过好几轮。市面上的AI编程工具看起来大同小异，实际用起来差别很大。我给它们分了几类，每类的适用场景不太一样：

对话生成型：适合一次生成整块代码、快速验证想法的时候用。把需求描述清楚，它给你一整段代码，你复制粘贴进项目里再修改。这类工具的缺点是交互成本高，每次对话都要重新描述一遍上下文。

IDE内嵌型：直接在编辑器里用，能感知你当前打开的代码文件、光标位置、项目结构，做补全和局部修改。这类工具用得好了，效率提升最明显——它的建议是跟着你的代码上下文走的，不用你额外解释。

批量处理型：可以直接把需求丢给它，它在后台整合多轮对话和代码修改后，把最终改动直接应用到多个文件里。这类工具效率最高，但也是我觉得“失控感”最强的——你得花额外的精力去确认它没动不该动的东西。

我的建议是：主力工具选IDE内嵌型，辅助工具选对话生成型，批量处理型要谨慎使用。这个组合兼顾了效率和可控性。另外还有一个很重要的选型标准——看它生成代码的风格是否容易融入你的项目。有的工具生成代码喜欢加很多注释、写得很冗长，有的工具生成代码比较精简但可读性差，这需要你在项目里实际跑一段时间才能感受到，光看宣传是看不出来的。

4.2 人机协作的开发工作流设计

半年测试下来，现在的我已经形成了一套比较成熟的人机协作工作流。核心思路是：AI负责写“零件”，我负责拼“整机”。

第一步，我会把任务拆到很细的粒度，控制在AI能“一口吃下”的范围。一个函数、一个组件、一个配置文件，这种粒度刚好合适。如果你把一个完整的业务流程丢给AI一次生成，后面调试的时间会远超自己写的时间。

第二步，写好提示词再开始。有模板化的东西，AI是“初稿生成器”，不是“功能实现器”。我永远假设第一版是不可用或不够好的，同时也知道接下来的迭代修改会一次比一次快。刚开始很多新人写代码有完美主义倾向，希望AI一次生成就能直接提交。实测告诉你，不要有这种期待——把生成和修改当成两件事，速度反而最快。

以我实际项目里的一个接口为例：需求是接收前端上传的Excel文件，解析里面的数据做校验，把不符合规则的数据生成错误报告。整个过程AI参与了文件接收的框架代码生成、解析逻辑的完善、校验规则的实现，以及错误报告Excel的导出。每一次AI只负责一个小模块，我来负责它们之间的衔接、异常处理和整体的数据流转。最终，这个两天工作量的需求，我只花了半天就完成了。让我印象最深的不是AI写得有多好，而是沟通成本在逐次对话中不断降低。

5. 效率量化：半年实测的数据结果

5.1 不同任务的耗时对比

半年下来，我养成了一个习惯：每次都粗略记录一下某个需求如果用纯手写和用AI辅助，分别需要多长时间。数据虽然不是特别严谨，但样本量足够大之后，还是有参考价值的。

以我之前提到的那个数据采集与分析项目为例，一个月内处理了十几个大小需求，我把它们分成了几类做了对比：

从表里可以看得很清楚：越是“CRUD + 格式转换 + 数据处理”这类标准化的活，AI的提升越明显；越是涉及业务规则、历史包袱、跨模块协同的活，AI越帮不上忙。我测试项目的整体效率提升大概在两倍左右，低于很多宣传中“效率提升十倍”的说法。宣传里的十倍，多半是用纯模板化的Demo项目测出来的，真实项目里很难达到。

5.2 返工率与代码质量统计

除了效率，我也统计了返工率。所谓“返工”，是AI生成的代码需要我修改后才能满足需求、通过测试的情况。这个数据非常能说明问题。

在我测试的前两个月，AI生成代码的一次通过率大约只有30%。也就是说，十次里有七次会出问题，要么是编译不过，要么是业务逻辑不对，要么是和现有代码风格差异太大。到后面三四个月，我把提示词写得更规范、给AI的参考示例更充分之后。一次通过率提高到了50%左右，加上小修小改能用的大概占到70%，剩下30%需要较大幅度的返工。

还有一个容易被忽视的指标是“理解成本”——就是拿到AI代码后，花多长时间读懂它。很多AI生成的代码虽然能跑，但写得绕、变量名没有语义、逻辑藏得太深，我读起来比读懂同事的代码还费劲。后来我强制要求自己写提示词时带上代码风格指南，比如“变量名要语义化”“每个函数不超过30行”“不许过度封装”，这种情况才明显好转。

5.3 真正划算的使用场景是哪些

综合这些数据，我得出一个务实结论：AI写代码最划算的场景是“低复杂度、高确定性、标准化程度高”的任务。

以下是我个人使用频率最高、体验最稳定的场景，排在前面的是：样板代码与项目脚手架；对象与数据库之间的映射代码；单元测试用例；正则表达式与字符串处理；基础的数据结构转换；代码注释与文档生成；简单页面的布局构建；将长函数拆成小函数的重构；常见中间件的基础配置；把一种编程语言的代码翻译成另一种。

我不推荐用AI做这些事：复杂的并发多线程处理（尤其涉及共享资源、锁竞争、异步时序）；高精度的数学计算与算法规约；涉及资金、权限、合规性判断的核心模块初稿；性能敏感的底层代码与内存管理；高复杂度分布式系统的问题定位与修复。

以上很多场景我都有翻车亲身经历。拿并发来说，AI生成的多线程代码，在低并发测试环境下跑得好好的，一到高并发就出现死锁或数据不一致。因为并发的坑往往不在代码表面，而在你对底层调度、内存模型的理解——AI不知道这些上下文。

6. 常见问题排查与避坑速查

6.1 高频问题的诊断清单

半年里我积攒了一大堆问题记录，这里整理成一份速查表。当项目里用AI遇到问题时，可以照这个顺序排查，能省不少事。

需要特别说明的是“功能对但效率极慢”这类问题。AI往往用最容易理解的方式生成第一个代码版本，不会主动考虑数据规模变大的情形。上周它还跑得飞快，数据量一上来就明显卡顿。所以我在让AI写涉及循环遍历、批量处理的代码时，都会提前叮嘱它考虑大数据量场景，并要求它给出算法复杂度的说明。

6.2 三个让我印象最深的真实翻车场景

挑三个影响最大、最有代表性的翻车记录，展开讲讲。

第一个是支付回调幂等。前面提过的场景——我在写一笔订单的支付回调逻辑时，AI在回调里加了一个失败自动重试的功能。这个重试逻辑从代码层面看没问题，但它忽略了一个关键点：回调接口被第三方支付平台多次调用是常态，不是异常场景。如果不做幂等控制，一次支付成功可能触发多次入账操作。这个问题是在代码审查时发现的，当时我盯着那段代码看了很久，越想越后怕。从那以后，我给自己定了一条铁律：涉及资金、状态变更的操作，AI只允许生成雏形，关键的幂等、校验、防重逻辑必须我来写。

第二个是并发环境下的缓存失效。当时有一个需求，要把频繁读取的配置数据从数据库搬到内存缓存里，以提升接口响应速度。AI生成的代码在单机环境下测试正常。一上生产环境，多个服务实例同时启动，每个实例各自维护了一份缓存，数据更新时只更新了当前实例的缓存，其他实例的缓存全部是旧的。这个问题的排查花了我大半天时间，最后发现根源在于AI生成的缓存逻辑完全没有考虑分布式环境下的数据一致性。

第三个是数据校验逻辑的缺失。一个文件导入功能，AI生成的解析逻辑把重点放在了“如何正确解析”上，完全忽略了“如果数据本身不合规怎么办”。比如Excel里有一列金额填的是负数、有学号重复、有关键字段为空，这些情况AI一个都没有处理，导致大批脏数据直接进了数据库。从那以后，凡是有数据入口的场景，我都会在提示词里明确列出需要校验的字段和规则，并且加一句“对不符合规则的数据，记录到错误清单中并跳过，而不是终止整个导入流程”。这句话几乎成了我的模板。

6.3 记一次跨模块代码返工全记录

最后分享一次比较典型的“AI翻车后再救回来”的全过程，能还原真实项目里我们是怎么排查、怎么返工的。那是一个跨模块的需求——用户提交一个申请单，系统需要同时更新申请单状态、扣减库存、记录操作日志，并且在第三步操作失败时回滚前两步的改动。

当时我觉得这个需求边界挺清晰的，就描述给AI让它生成第一版。生成的结果从代码结构上看起来非常合理：一个服务类，三个方法，按顺序调用。我第一眼还觉得挺满意。但跑测试的时候就出问题了：第三步操作失败时，回滚逻辑没有生效，库存被扣了但申请单状态没改回去。然后我开始引导AI补充事务机制，它给出的方案是在三个方法上一层一个大事务。表面上问题解决了，但我让AI多想了几种情况之后，又出现了新问题：这个事务把日志记录也包含进去了，日志没记成功时整个业务也回滚了，这显然不符合“日志失败不影响主流程”的需求。

来来回回改了三四轮，每次改动都会出现新的遗漏点。最后我放弃了让它自己调整的方案，自己定义了事务边界：主流程内的更新操作统一纳入一个事务，操作日志的写入作为独立事务在业务完成后执行，两个部分之间的衔接代码由我手工完成。AI全程只贡献了三个方法内部的基础逻辑。这次经历让我明确了一个边界：跨模块的事务、状态流转、异常链路设计，必须由人来统筹，AI在全局设计上靠不住——它没有“全局观”，只有“局部正确”。

事后我把这个项目的处理逻辑整理成了一份“事务边界设计规范”，放进项目的开发文档里。之后每次给AI派活，都会附带这份规范。这个习惯帮我在后续项目中减少了很多类似的沟通成本。因为AI生成代码翻车，往往不是它能力不够，而是它真的不知道项目里的这些约定和边界——你明确告诉它了，它就能给你省下大把时间。

7. 我的个人总结与思考

写了这么多，我自己最大的感受是：AI写代码基本上靠谱，但前提是你得靠谱。这年头真正的门槛已经不是“能不能用AI”，而是“会不会用AI”——你的领域经验、项目判断力、代码审美，决定了AI是帮手还是麻烦制造者。

我最常用的一句内部口头禅是：“把AI当实习生，不把AI当大神。” 给它拆解过的任务，它基本能又快又稳地交回来；给它一个含糊的整体目标，它照做的过程就得时刻盯紧。而我们的价值，在于知道哪些任务能拆分给它，哪些必须自己拿着。

回看这半年，我最大的收获不是“我会用AI写代码了”，而是我对“什么才是好代码”这件事有了更清晰的认知。你只有清楚地知道代码应该长什么样，才能指挥AI写出接近那样的代码，才能一眼识别出AI补出来的私货。技术工具永远在迭代，可编程这件事的核心——分析问题、拆解步骤、定义边界——永远是最值钱的能力。AI只是把“打字”这部分变快了，把“想”这部分的压力，反而更加凸显了出来。