AI编程代码审查指南：识别幻觉API与边界条件陷阱

1. 内容整体设计与思路拆解1.1 AI 写代码的“正确性幻觉”到底怎么来的先定义一下问题什么叫“看着对其实错”就是AI生成的代码语法完全正常缩进规整变量命名像模像样逻辑链路看起来严丝合缝结果一跑就报错或者更隐蔽——能跑出来结果只有少数边界场景会翻车甚至结果算出来就是错的但你短时间发现不了。我大概是2022年底开始大规模把AI编程助手接入日常开发流程的到现在用了两年多一个很直观的感受是AI写代码的出错模式跟我们人完全是两回事。人写错代码通常是理解错了需求、变量名拼错、逻辑分支没想全。AI写错代码更离谱——它能把一个不存在的API拼得有模有样参数类型对不上也能给你圆回去甚至编造一个看起来完全合理的报错信息。这背后有个根本原因大模型生成代码的机制不是“理解后推导”而是“根据上下文逐词预测”。它不像人脑那样在脑子里跑一遍逻辑它看到你前面的代码就按统计概率把最可能的后续token吐出来。所以它追求的是“像正确的代码”而不是“正确的代码”。这一点必须先讲清楚不然你后面所有的排查方向都是错的。很多程序员第一次用AI写代码遇到问题会习惯性地像debug同事代码一样去追逻辑结果追了半天发现逻辑“看起来”没问题问题出在AI调了一个不存在的接口。你永远不能用“代码是否像人写的”来判断AI代码是否正确你要用运行时行为来判断。让我用两个真实的case开场。第一个case是我用一个AI编程助手生成一段从S3读取文件并解析JSON的Python代码。AI给出的版本大概是这样import boto3 import json from urllib.parse import unquote_plus def lambda_handler(event, context): bucket event[Records][0][s3][bucket][name] key unquote_plus(event[Records][0][s3][object][key]) s3 boto3.client(s3) response s3.get_object(Bucketbucket, Keykey) content response[Body].read().decode(utf-8) data json.loads(content) return { statusCode: 200, body: json.dumps(data) }这段代码语法没问题AWS Lambda的触发事件结构也对read().decode()和json.loads()的调用链也是对的。我第一次看的时候真的觉得可以直接用了。但等到测试的时候遇到一个接近900MB的大文件直接把Lambda的内存打爆了。问题出在response[Body].read()——它会把整个文件读进内存而这个操作对大数据量的场景是不可接受的。AI给我写了一段在小文件场景下绝对正确的代码但它不会因为你传了一个900MB的文件就切换到流式读取方案。它并不知道你的真实数据规模。第二个case更有意思。我让AI写一个C函数判断一个整数是不是质数。它给出了一个用试除法的版本逻辑完全没错。但我追问了一句“你确定没有性能问题吗”它立刻换成了Miller-Rabin概率性素性测试代码量翻了三倍引入了随机数生成和模幂运算。问题是我根本不需要那么高性能的版本我的调用频率是每秒一次试除法完全够用。AI的问题不是“能力不足”而是“缺少现实约束条件时它会默认选择统计上最热门的实现方式”。它没法感知你的业务场景、数据规模、性能要求、部署环境。这两个case串起来其实就是AI编程的核心悖论它能比绝大多数程序员更快地写出“语法正确的代码”但它并不了解你的“具体问题”你的上下文才是决定代码好坏的关键。而你作为程序员唯一的生存之道就是永远保持审查、验证和质疑。这不是信不信任AI的问题这是统计学上的必然——一个基于概率生成文本的系统必然存在概率性的错误。1.2 为什么“跑通了”不等于“做对了”另一个我想要拆掉的概念是“能跑通”和“逻辑正确”之间隔着一整个检查清单。AI生成代码最迷惑人的地方就是绝大多数时候它能跑通。人都有一种惯性看到程序有输出第一反应就是“成了”。但程序有输出和程序输出正确是两码事。我给你举一个我踩了三小时的坑。有个需求是要把一批用户数据按日期分组统计每天的活跃用户数。我让AI写一个Python脚本处理CSV文件它给出了类似这样的实现from collections import defaultdict import csv from datetime import datetime def count_daily_active_users(csv_path): daily defaultdict(set) with open(csv_path, r) as f: reader csv.DictReader(f) for row in reader: date_str row[timestamp][:10] daily[date_str].add(row[user_id]) return {date: len(users) for date, users in daily.items()}逻辑对吧用set去重按日期分组数量统计每一步都标准。我拿测试数据一跑输出结果也合理。直到后来我拿真实数据集跑发现每天的活跃用户数比产品后台的报表少了大概百分之五。排查了很久最后发现问题出在row[timestamp][:10]——真实数据里的timestamp字段有些是毫秒级时间戳的数字字符串比如1704067200000前10位是1704067200转成日期完全对不上。测试数据里刚好都是ISO格式的时间字符串所以没暴露。这个bug属于典型的数据处理假设错误AI默认了字段格式统一但真实世界的脏数据教做人。这类问题有个共同特征代码的逻辑内部是自洽的但它对外部世界的假设不成立。AI没有见过你的生产数据它只能根据你的描述和你贴的几行样例来推断数据长什么样。所以“跑通了”只说明代码在给定输入下没有异常退出绝不代表它对所有预期输入都产生正确输出。这也是为什么我一直跟团队说AI生成代码的直接跑通率其实挺高的但直接正确率要打个对折。你可能会问那不是跟人写代码一样吗人也可能对数据格式理解错误啊。对但区别在于人写代码时脑子里通常有一个对真实数据的心智模型这个模型来自他过去处理过的数据、踩过的坑、看过的文档AI的心智模型来自训练语料它见过所有类型的数据但不知道你的数据属于哪一种。所以它对数据格式的假设往往是“最常见的哪种”而不是“你实际有的哪种”。2. 核心细节解析与实操要点2.1 四类最坑的 AI 代码错误模式按照我个人的观察和团队里其他同事的使用反馈AI生成代码的错误可以归类为四种高频模式。知道了这些模式你审查代码的时候就有了一个checklist能高效锁定风险点。第一类幻觉API——AI生成了一个看起来合理但实际上不存在的函数、类、参数、方法。这类错误在SDK快速迭代的领域特别严重。比如AWS的Python SDKboto3每年更新那么多次AI训练数据里装的可能是两年前的版本它不知道已经有新接口了就给你编一个。去年我们有个项目里AI生成了一个wait_until_running()方法看起来完全可以读boto3的EC2实例对象确实有wait_until_running()它没编错但用在一个旧的SDK版本里这个方法不存在一跑就AttributeError。遇到幻觉API靠读代码是发现不了的你只能靠IDE的类型提示、运行时报错、或者查官方文档来甄别。第二类语义沉默错误——代码能跑但结果不符合期望或者有隐含问题。前面讲的三种案例都属于这一类大文件读进内存、时间格式假设、默认参数不符合场景。这类错误最隐蔽因为单元测试可能都能过要等真实场景或者数据量上来才暴露。这类错误AI自己也无法察觉因为它在生成代码时没有程序执行能力它看不到内存峰值看不到CPU占用看不到数据分布。第三类逻辑浅层正确、深层错误——比如你让它写一个DFS遍历树的函数它写得对但如果你让它写一个非递归版本并且要求用栈实现、并且要处理环的问题它经常会漏掉visited集合因为树的DFS不需要visited图的DFS才需要而它在长上下文里可能忘了你最开始说这是个图。这种错误的原因是AI对长上下文的跟踪不够稳定对话越长、约束条件越多它越可能忘记前面的某条关键约束。第四类安全与健壮性问题——AI写的代码很少考虑try-catch、输入校验、SQL注入、XSS防护、资源释放。不是它不会而是用户没提这些要求时它默认不生成。我做过一个小实验让AI写一个简单的登录接口直接把用户输入的密码拼进SQL查询AI毫不犹豫地给出了WHERE username ... AND password ...的拼接版本。一旦我补充“用参数化查询”它立刻能改对。AI它不是一个安全意识差的程序员它是一个被动满足需求的程序——你没要求它安全它就不安全。这四种模式之间没有清晰边界同一个代码里可能混合多种问题。重要的是你拿到AI代码后要形成一个条件反射先用模式匹配扫描一遍四大风险再谈逻辑审查。2.2 AI 代码审查的检查清单基于上面四类错误模式我整理了一个自己的审查清单每次合并AI生成的代码到主干分支之前都会过一遍。第一个检查点是API真实性。所有的import、函数调用、方法名、参数名都要经过IDE的类型检查或运行时验证。这个检查你靠肉眼看是低效的最好的方式是让编译器/解释器说真话。Python的mypy类型检查、TypeScript的tsc、Java的javac先用它们过一遍。静态检查过的代码不一定没有API幻觉问题但至少能把最常见的拼写级幻觉拦住。第二个检查点是边界条件。AI生成代码时最容易忽视空列表、None值、零除、超大数、负数、时间边界跨年、闰年、超大文件。我通常会把AI生成的代码里的所有循环和条件复制出来手动推演一个空输入、一个满输入、一个边界输入。比如它写了一个找最大值的函数我马上就会想“如果列表为空它会返回什么”AI大概率会返回None或者-1但你的业务逻辑可能期望抛异常或者返回0。第三个检查点是资源生命周期。文件有没有close数据库连接有没有释放线程有没有joinGPU显存有没有释放临时文件有没有清理。AI生成代码时天然不关心资源管理因为它没有“长时间运行”的概念。写脚本跑完就退跟写服务长期挂着资源管理的代码完全是两种写法AI默认倾向于前者。第四个检查点是异常处理。AI生成代码倾向于“快乐路径”它假设所有外部依赖都正常工作、所有数据都是理想的。但真实世界的HTTP请求会超时数据库会断连文件会被占用Redis会OOM。AI不会自己加retry、circuit breaker、fallback、timeout这些必须由你在prompt里明确要求或者在审查时代码里手动补上。第五个检查点是性能风险。看AI代码时需要问自己三个问题这段代码的时间复杂度够不够空间复杂度够不够有没有明显的重复计算AI写代码经常为求简单而使用嵌套循环数据量小的时候没问题数据量上万就能卡成PPT。但这里有一个反向的坑让AI优化性能时它可能过度优化把简单逻辑改成缓存多线程异步反而引入了无谓的复杂度。性能优化的推进应该遵循“先度量再优化”的原则不要盲目接受AI的性能优化建议。把这些检查点落实成行动我通常会做两件事跑一轮静态分析工具SonarQube、ESLint、pylint这类的然后写一组单元测试覆盖边界场景。前一步拦幻觉API后一步拦逻辑浅层正确。这两步做完AI代码的错误率能降一个量级。3. 实操过程与核心环节实现3.1 从问题描述到可验证代码的完整链路我平时用AI写代码的流程不是简单地把需求丢给它就完事而是有一套自己的操作链路确保后期不需要大改。这里完整拆一遍。第一步是写清楚需求文档级别的prompt。不是一句话需求而是包含输入是什么类型、输出是什么类型、边界情况怎么处理、性能要求、依赖库版本、运行环境。我发现很多人用AI写代码prompt里就一句话“写一个函数算日期差”然后AI给一个能用的版本就谢天谢地了。这种用法可以应付tooling类的小代码片段但一旦要接入现有项目不写清楚上下文AI就是在碰运气。举个例子我最近让AI帮我写一个Python函数从一批日志文件中提取指定时间范围内的错误日志。我写的prompt是写一个Python函数extract_errors(log_dir, start_time, end_time)。 - log_dir下有多按天切割的.log文件文件名格式是app-YYYY-MM-DD.log - 每行日志格式2024-01-15 14:23:45,123 ERROR - 消息内容 - 返回一个list元素是(datetime, str)元组按时间排序 - 只返回start_time 日志时间 end_time的记录 - 如果log_dir不存在直接抛FileNotFoundError - 文件很大你按行读不要全部load进内存这个prompt比只说“写一个从日志提取错误的函数”信息量大得多。AI拿到这个prompt能明确文件名格式、行格式、返回结构、时间比较方式、异常处理需求、内存限制生成代码的准确率会高很多。AI不是神它是个很听话的实习生你把需求讲清楚它才能把你想要的东西做出来。第二步是让AI生成单元测试。这一点我强烈推荐因为让AI测自己生成的代码比让AI自己“复查”代码靠谱得多。原因是AI的复查本质上是“根据上下文重新生成一次”它的错误模式会复现而让AI生成测试用例是看代码行为是否正确它能发现一些自审发现不了的问题。第三步是构造独立验证数据集。AI生成的代码你至少要准备三组输入标准用例数据结构和格式正常、边界用例空输入、最大值、最小值、特殊字符、恶意用例格式不对、字段缺失、类型错乱。这个验证数据集最好在提交AI写代码之前就准备好因为数据驱动你才知道AI生成的代码好不好用。第四步是跑起来看运行时行为。这一步千万不要省哪怕AI给的代码一眼看上去完美无缺你也要跑一遍。因为AI代码最大的问题不是逻辑错误而是运行时的行为偏离你的预期且运行时不会直接报错。我拿一个实际的例子带大家走一遍这个链路。需求写一个函数把用户输入的信用卡卡号做掩码只保留后四位其他用星号替换。第一步我给AI的prompt写一个Python函数mask_credit_card(card_number: str) - str。 - 输入可能包含空格和连字符需要先清理它们 - 只保留数字字符如果清理后长度不等于16抛出ValueError - 保留后四位前面12位用*替换 - 输出格式****-****-****-1234AI给的代码import re def mask_credit_card(card_number: str) - str: cleaned re.sub(r[\s-], , card_number) if not cleaned.isdigit() or len(cleaned) ! 16: raise ValueError(卡号必须为16位数字) return f****-****-****-{cleaned[-4:]}第二步让AI生成单元测试import pytest from mask_credit_card import mask_credit_card def test_normal(): assert mask_credit_card(1234 5678 9012 3456) ****-****-****-3456 assert mask_credit_card(1234-5678-9012-3456) ****-****-****-3456 assert mask_credit_card(1234567890123456) ****-****-****-3456 def test_invalid(): with pytest.raises(ValueError): mask_credit_card(1234) with pytest.raises(ValueError): mask_credit_card(1234 5678 9012 345a) def test_edge(): # 16位但是以0开头 assert mask_credit_card(0123456789012345) ****-****-****-2345 # 前后有特殊字符 with pytest.raises(ValueError): mask_credit_card( 1234 5678 9012 3456 )注意第三个边界用例其实是让我发现了一个隐藏问题我prompt里说的是“清理空格和连字符”但AI的re.sub(r[\s-], , card_number)把制表符、换行符也清理掉了这本身没问题。但是如果输入是 1234 5678 9012 3456 这样的字符串清理后是16位数字程序不会抛异常而是正常输出了。我原本以为前后多出的空格应该视为输入格式非法但它被当成可清理的空白了。这是需求定义时的一个模糊点不是AI的错但AI代码把这种模糊性落地成了“可清理”如果你没仔细看这个行为就会被带进生产环境。这个流程走完AI生成的代码才算是“初步可用”。后面还有审查、集成测试、性能评估但对于单个函数级别的代码前面4步已经能拦住绝大多数坑。3.2 实际项目中“让AI写代码”和“自己写代码”的边界划分两年多的AI辅助编程实践下来我形成了一个比较稳定的工作划分原则分享出来供大家参考。适合完全交给AI生成的代码工具类函数日期处理、字符串处理、文件解析、格式转换、样板代码CRUD接口、DTO定义、配置加载、可测试性强的算法实现排序、搜索、动态规划经典题、测试用例生成。这些代码有一个共同特征需求边界清晰输入输出可以严格定义有明确的正确性判据。AI在这些场景里的准确率高得惊人我估摸着能到90%以上。适合让AI生成初稿、人工改写的代码业务逻辑订单状态流转、计费计算、权限判断、涉及状态管理的代码多线程、协程、事务、需要深度理解领域模型的代码。这类代码AI能生成一个跑通的主路径版本但分支逻辑、异常处理、状态一致性这些需要人来把控。我通常的做法是先让AI写一个初版然后我自己重构一遍核心逻辑把AI生成的代码当作“可执行的伪代码”来用。不建议让AI单独完成的代码涉及安全认证的代码权限校验、加密解密、支付签名、底层系统代码内存管理、锁竞争、高性能网络IO、需要严格规范要求的代码医疗、金融、航空等领域。这些领域AI的错误会带来严重后果人力审查的成本比AI省下的时间高得多。我知道有些朋友会问这不是跟不用AI差不多了吗其实差别很大。我上面说的“不适合”是说不能“单独交给AI”合理的用法是让AI生成初稿、做知识检索、提供多方案对比人来决策。就拿支付签名逻辑来说我会让AI帮我整理OpenSSL里各种签名算法的区别让它写一个粗略的签名验证流程框架但最终的签名实现和校验逻辑必须是我自己写、自己review的。边界划分的本质是根据错误的代价来分配责任。AI辅助编程这件事不是看AI帮你做了多少而是看错误风险控制在什么水平。高风险高代价的代码哪怕AI能写也要人来把关低风险高重复的代码AI做就好了。4. 常见问题与排查技巧实录4.1 典型翻车场景与定位方法这一节是实战记录把我自己遇到的AI代码问题整理成一个速查表每个案例都附上定位方法和修复建议。这些案例不是编出来的都是我这两年在真实开发里踩过的坑具有一定的普遍性贴出来给大家参考。先说第一个翻车案例AI幻觉一个回调函数参数。之前我用一个Node.js项目需要对接Redis的发布订阅。我让AI写一段订阅消息的代码它给出了类似这样的实现const redis require(redis); const client redis.createClient(); client.on(message, (channel, message) { console.log(Received message: ${message}); }); client.subscribe(news);问题出在client.on(message, ...)——node-redis v4版本里事件监听方式跟v3不同v4的方式是client.subscribe(news, (message, channel) {...})v3才是client.on(message, ...)。AI默认用了最经典的v3写法因为它的训练数据里v3的代码示例数量远超v4的。定位这个问题费了点时间因为代码不会启动就报错只有当真的往频道里发消息时才发现回调没有被触发。后来我查了node_modules里实际安装的redis版本是v4.6.x然后把订阅逻辑改成client.subscribe(news, (message, channel) { console.log(Received message: ${message} from ${channel}); });这个案例的教训是AI生成的代码依赖库版本可能跟你项目锁定的版本不一致尤其是流行库在高版本里改API时AI的响应常常滞后。所以接手AI代码时第一件事就是确认你项目里实际安装的依赖版本对照官方文档核对API。第二个案例AI把整个循环体放进了异常捕获里吞掉了关键错误。当时我给一个数据同步任务加增量更新逻辑AI写的代码大概是def sync_data(items): for item in items: try: # 处理每条item process(item) except Exception: pass代码跑完控制台安安静静没有报错但是数据一条都没同步。因为process(item)里恰好有个字段类型错误异常一抛就被except Exception: pass吞了然后继续处理下一条。我一开始根本没怀疑这个try-catch因为AI写代码加异常捕获看起来是“很负责任”的行为可它把异常直接抛弃了这在数据同步场景里是致命的——你以为同步成功了其实一半数据都没进去。定位方式也简单加日志。我把pass改成logger.exception(...)再跑一遍发现那个字段类型错误修复后同步正常。这个教训是AI倾向于帮你“处理”异常但它不会衡量异常的严重性。某些场景下异常应该直接中断任务而不是静默吞掉。你在审查AI代码时凡是有except Exception这种宽泛捕获的都要停下来问一下“这里是否应该让程序继续跑下去”。第三个案例AI用递归实现一个深度不断增长的嵌套结构展开。当时要解析一个深层嵌套的JSON配置文件AI写了个递归函数来处理。测试数据层级大概10层跑得好好的。上线之后用户传了一个300多层的嵌套结构直接RecursionError。这种情况的修复方式有两种要么把递归改成迭代显式栈要么调大Python的递归深度限制但调大递归深度限制对3000层的结构可能还不够用。实际改成了迭代版本用栈模拟递归过程问题就解决了。这个案例说明AI对数据规模没有感知它倾向于写“正确”而不是“稳健”的代码。如果你的数据规模可能突破AI没见过的情况需要主动设计防御机制。第四个案例AI滥用全局状态。有一个多线程的场景AI生成了一段用全局变量做计数累计的代码。单线程跑没问题多线程一跑计数对不上。定位的过程花了挺久因为不是每次都错而是概率性出错最后用threading.Lock()加锁解决。这类问题在并发场景里非常典型AI生成代码时不会主动考虑线程安全除非你真的把“多线程”三个字写在prompt里并且明确写出需要加锁。更麻烦的是如果AI在长长的上下文里已经生成了很多代码你再要求它“改成线程安全”它可能只改局部其他地方的共享变量依然裸奔。这种时候与其让AI自己改不如你手动定位所有共享状态统一封装成线程安全的类。4.2 如何让AI帮你排查AI自己的代码还有一个场景值得单独聊聊——如何用AI排查AI生成的代码。听起来有点套娃但实际操作非常有效因为大模型对已有代码的审查能力比从零生成代码要强不少。我遇到AI生成代码出问题时通常会做这样的事先把出错的代码和报错信息贴回给AI然后问它几个很具体的问题这段代码是AI生成的现在运行报错错误信息是[贴报错]。请先检查 1. 代码里是否有不存在的API或方法 2. 是否有参数类型不匹配 3. 有哪些边界条件可能导致这个错误 4. 给出修复后的完整代码这样做的原理是当你给AI一个明确的报错信息、一段具体的代码它其实是在做“代码审查”任务这类任务在它的训练数据里有大量类似示例效果远好于“从零写代码”。但这里也有个关键就是你必须把报错信息原封不动地贴完整而不是自己概括。AI对模糊的错误描述很敏感你概括得越精确它的回答越有价值你要是只说“这段代码有问题帮我看看”它只会泛泛而谈。有一次一个同事让我帮忙看一段AI生成的Go代码报错是undefined: context。我看了一下代码里用了context.Context但是import列表里没有context包。这个错误非常低级IDE一般当场就标红了但同事是在没有IDE插件的环境里调试的。我帮他做了个演示——把这个报错贴给AIAI不仅能指出缺了import还顺手把整个函数的其他潜在问题也列了出来。这说明AI在“修bug”模式下比“从零写代码”模式下靠谱得多。但我要提醒一个坑AI给你修复代码时有可能引入新的错误特别是让你“整段重写”的时候。我的建议是修复请求一定要限定范围尽量让AI做局部修改而不是整段重写。比如你可以说保留原有的函数签名和整体逻辑只修复错误信息中提到的context未定义问题不要重写整个文件。这个限定条件能大大降低AI“顺手重构”带来的风险。我遇到过太多次AI修复一个问题时顺手优化了其他代码结果引入新bug的情况。4.3 建立AI代码的质量门禁前面说了这么多问题最后从管理者的角度聊聊怎么把AI生成的代码质量管起来。我的观点是AI代码能否安全落地不在于AI本身有多强而在于你的代码库有没有一套质量门禁。第一道门禁是静态检查。ESLint、pylint、SonarQube这些工具要打开并且配置要严格。AI生成的代码多半能过较宽松的静态检查但如果你把规则调严格比如强制异常不能吞掉、强制类型注解立刻能拦截一批问题。我见过很多团队用SonarQube只盯着“代码覆盖率”和“重复代码率”看其实更应该关注的是那些容易出事的规则比如空catch块、日志遗漏、危险函数使用。第二道门禁是单元测试覆盖率。不是看覆盖率数字高低而是看关键业务逻辑的测试能不能覆盖边界场景。AI生成的代码如果关键分支没有测试覆盖CI里跑再多测试也白搭。第三道门禁是代码评审。AI代码不能靠单人review至少要两人以上。而且review的时候不要只关注“逻辑对不对”更要关注**“这段代码的上下文假设是什么”**。前面反复提到AI代码的很多问题来自对外部世界的错误假设。reviewer要在代码里寻找“AI默默做出的假设”——数据格式、接口行为、资源边界这些都是review的核心。第四道门禁是渐进式上线。如果AI生成的是一个新模块不要一次性把流量全切进去先灰度、先跑一段时间监控观察有没有隐藏的边界问题。尤其要关注是否出现CPU使用率异常、内存泄漏、慢查询这类运维层面才能发现的问题。这四道门禁的顺序不能乱。静态检查跑在前面把语法级、API级的问题拦住单元测试跑在中间把逻辑级的问题拦住代码评审跑在后面把设计级、语义级的问题拦住渐进式上线放在最后把运维级的问题拦住。每道门禁都能拦住一类AI特有的错误类型但如果顺序颠倒了后面的门禁会被前面漏掉的问题淹没反而降低效率。5. 经验与教训总结5.1 我对AI编程的整体判断经过这两年的实践我的整体判断是AI编程不会取代程序员但它会重新定义程序员的日常工作。以前写代码80%的时间在思考数据和流程20%的时间在敲键盘。现在反过来了敲键盘的时间被AI压缩到了极低的水平但你思考的时间一点没减少反而增加了——你要思考需求边界、思考AI代码的行为假设、思考异常路径怎么走。有人可能会觉得这是把活变多了但我不这么看。AI压缩的是“把想法翻译成代码”的时间但你作为工程师最值钱的能力其实是“定义一个正确的问题”。prompt写得越清晰AI生成代码的质量越高这个规律随着我写的prompt越多越明显。反过来如果你连问题都界定不清楚AI只会给你一个看着能跑、实则充满假设的破东西跟没做没什么区别。我在实践里收获最大的一招是给AI写代码前先自己用自然语言把输入、输出、边界、异常、性能这五个维度想一遍再把这些信息填进prompt。这个过程本身就是在梳理需求和架构即便AI什么都不帮你做你的设计也受益了AI只是把你理顺了的思路快速翻译成代码而已。5.2 给刚入坑AI编程朋友的操作建议最后给刚开始用AI编程的朋友几条具体的、可以直接上手的建议。一是从小的、独立的任务开始。别一上来就让AI写一个完整的微服务或者一个复杂的业务模块让AI先写一个日期格式转换函数、一个JSON解析器、一个文件去重脚本。小任务的错误暴露快、排查成本低你可以快速积累AI生成代码的“经验值”学会辨识哪些地方容易出坑。二是永远保留“人审代码”的环节。哪怕AI告诉你它已经“仔细检查过了”AI的检查标准和你想要的行为可能完全不同。去看代码看不懂的让AI解释解释不清楚的那大概率是它自己也没想清楚。三是把AI当成“需要审查的初级工程师”来管理。你给初级工程师派活你不会只丢一句话让他自己发挥你会告诉他需求文档在哪、验收标准是什么、什么时候交付。对AI也应如此prompt要具体交回来的代码要审查不合格就返工。关键在于你不能预设它“懂你”它真的不懂它只是有一肚子大概率的知识等待你校准方向。四是持续积累自己的“AI安全代码库”。每次AI帮你生成代码后把那些你审查过、修正过、测试通过的代码片段保存下来。随着你的安全代码库越来越大你会发现AI生成代码的质量也在提升因为你给它的上下文越来越丰富它越来越了解你的代码风格和业务约束。我自己的体会是AI编程这个工具有一个特别神奇的地方它让我重新关注起了那些被我忽略的基础问题——数据的边界在哪、异常应该怎么处理、资源的生命周期怎么管理。这些问题我以前做的时候是凭直觉现在为了让AI写出更好的代码我反而会把这些直觉显式化、文档化这对我自己的工程设计能力也是个大提升。所以别怕AI写错代码该怕的是我们没有一套体系去约束它、审查它、验证它。有了这套体系AI就是你手里最锋利的刀之一。