去年我接手一个遗留Python项目代码量八万行。接手前我担心要先花两周做代码审查结果同事丢给我一句话用Trae写一套审查提示词让AI先扫一遍再人工复核。半信半疑试了一下从此就回不去了——现在每次合并代码前我的例行流程都是先让AI过一遍再处理真正需要人判断的问题。这篇文章是我在Trae提示词开发实战系列里的第十一篇不聊虚的直接拆解AI辅助代码审查这个场景。标题说效率提升10倍有人觉得夸张但如果你做大范围代码走查10倍这个数字一点都不浮夸。我会把这个过程拆成几块设计思路、提示词模板、真实操作和避坑心得。不管你正被代码审查搞得焦头烂额还是刚接触Trae想找个落地场景这篇文章都应该能帮到你。1. 先理清思路AI代码审查到底审什么1.1 为什么审查比写代码更适合AI先说一个容易被忽视的事实AI写代码是发散性任务审查代码是收敛性任务。开放式生成经常让AI自由发挥写到后面越来越飘但审查不一样它的目标非常明确——找出问题、给出修复建议。这种任务AI反而比人类更有优势因为它的知识面广、阅读速度快、不累不烦躁而且不会因为代码量太大而跳过细节。我刚接触提示词工程的时候总想着让AI一步到位把功能写完。结果发现模型越到后面越容易跑偏真正稳定落地的场景反而是代码审查、代码解释、测试用例生成这类结构清晰的任务。审查的本质是拿标准去套代码标准是固定的代码是输入输出是问题清单。这正好是AI最擅长的工作方式。另外一个关键点是代码审查的产出可以结构化。一条审查意见包含问题描述、所在位置、严重程度、修复建议。只要提示词里把输出格式约束好AI返回的结果就能直接对照处理不需要二次加工。这一点对后续落地到团队流程非常重要。1.2 审查的五个维度比你想的要多得多很多人以为代码审查就是看看有没有bug这是最大的误区。我自己的经验是一份合格的审查报告至少要覆盖五个方面缺一个都可能出事。审查维度关注点Python里常见的坑正确性逻辑错误、边界条件、异常处理、并发安全动态类型导致运行时类型错误、except Exception裸捕获、整数除法和浮点除法的混用安全性注入攻击、敏感信息泄漏、不安全的反序列化、危险函数调用用 f-string 拼接 SQL、把密码哈希返回给前端、pickle.loads处理不可信数据、eval执行外部输入性能时间复杂度、数据库访问次数、内存占用、资源释放循环内查询数据库N1问题、大列表做无谓拷贝、文件或连接没有关闭可维护性命名是否清晰、函数是否过长、代码重复、魔法数字变量名只有一个字母、单函数上百行、同一个常量到处硬编码可测试性是否方便Mock、依赖注入是否合理、全局状态函数内直接get_db()连数据库、随机数或时间戳写在业务逻辑里导致不可重复测试我见过太多团队做审查只看前两项结果线上故障大部分确实由正确性问题引起但真正让后续开发速度变慢的是可维护性和可测试性的问题。AI的强项在于它能同时覆盖所有维度不会因为人的注意力有限而漏掉细节。1.3 为什么是Trae你不该开着网页去审查既然AI能审查代码那直接用ChatGPT网页版把代码粘贴过去不就行了可以但体验差很多。Trae这类AI IDE的优势是代码就在编辑器里选中即分析上下文天然充足。Trae有几个具体好处第一它能直接读取项目结构给AI提供的不只是一段孤立的代码而是整个上下文第二它在编辑器侧边栏常驻审查完立刻就能改不用来回切换窗口第三Trae对中文场景和国内网络环境做得比较友好这对我这种要天天用的人来说很关键。单独的网页对话工具适合临时提问但如果要把审查变成日常流程一个集成在IDE里的AI助手才是正确选择。2. 提示词模板把资深工程师的审查经验写下来2.1 能用和好用的提示词差别到底在哪同样是让AI审查代码有人输入的是检查一下这段代码有人输入的是接近一页纸的结构化提示词。前者AI也能给你回话但结果多半是一堆正确的废话这段代码整体质量良好但有一些可以改进的地方例如考虑使用异常处理。这种回答你看了等于没看。我打个比方。提示词就像你给临时工布置任务。你跟他说打扫一下屋子他可能只把客厅擦了擦你要是跟他说把客厅、厨房、卫生间各擦一遍垃圾倒掉物品归位最后拍照给我看结果完全不一样。AI也是这样它不会主动揣摩你的潜台词你给它多大的边界它就干多大的活。好用的审查提示词必须包含五块内容角色设定、审查范围、审查维度、输出格式、代码上下文。角色设定让AI知道调取哪类知识库审查范围告诉它看哪里维度是检查清单输出格式决定了结果能不能直接干活上下文则是让它结合项目实际情况而不是空谈。2.2 一个可以复制就能用的Python审查提示词模板下面这个模板就是我平时在Trae里用的保留了核心结构你复制过去改成自己的项目描述就能用。这一段看起来很长的提示词其实就是把资深工程师的审查习惯固化下来。你是资深Python代码审查专家精通Python 3.10熟悉FastAPI、Flask、Django、 SQLAlchemy、async/await并发编程了解PEP8和Google Python Style Guide。 项目背景这是一个使用FastAPI SQLAlchemy PostgreSQL开发的后端服务 代码风格遵循PEP8但未强制使用类型注解。请基于这个背景审查代码。 请从以下维度审查这段代码 1. 正确性逻辑是否有漏洞边界条件是否处理异常分支是否缺漏 2. 安全性是否存在注入、敏感信息泄漏、危险函数调用、权限绕过风险 3. 性能是否存在不必要的重复计算、N1查询、资源未释放等问题 4. 可维护性命名、函数长度、重复代码、魔法数字、过度耦合 5. 可测试性是否方便单元测试外部依赖是否能轻松Mock 输出要求 - 按严重程度分为三档严重必须修复、建议建议优化、提示可选 - 每个问题必须包含问题描述、对应代码片段或行号、具体修复建议 - 如果某个维度没有问题请明确写未发现明显问题不要为了凑数而硬挑错 - 最终给出一句话总结这里我特别要解释两个容易被忽略的设计。第一是如果某个维度没有问题请明确写未发现明显问题不要为了凑数而硬挑错。这一句非常关键。大模型有很强的讨好倾向你不做限制它会想尽办法给你找几个毛病哪怕那个写法根本没问题反而干扰了你的判断。加了这句话之后审查报告会清爽很多。第二是项目背景这一部分。你告诉AI这是一个FastAPISQLAlchemy项目它就会用web服务的标准来审查你不说它可能拿一个数据科学脚本的标准来判断结果给出的建议完全对不上号。上下文对审查准确性影响极大后面我还会细说。2.3 提示词里必须写清楚的三件事除了上面模板里的内容还有三个小细节我建议一定写进去否则后续处理起来会非常痛苦。一是要求给出行号或代码片段。AI审查完之后你要能快速定位。如果它只说这个函数存在问题你还得自己去翻代码效率凭空少了一半。所以我在输出要求的第二条明确写了对应代码片段或行号。二是要求区分严重级别。没有分级的话AI会把变量命名可以更清晰和SQL注入漏洞放在同一个优先级里你会被噪音淹没。分三级以后先处理严重项再批量看建议项节奏就舒服多了。三是明确输出内容的边界。很多人忽略如果某个维度没问题请明确说没有这句话。AI在默认情况下有报喜不报忧的反面——它倾向于显得自己工作认真因此会强行挑刺。加上这句话以后报告里的每一条意见分量都会更足。3. 实操演示用Trae审查一个真实Python模块3.1 我准备的一个问题代码示例文档里讲一百遍不如实操一遍。我准备了一段典型的带病Python代码里面埋了多种问题我们直接拿它来走一遍完整流程。这是我在模拟一个用户服务模块时写的函数不多但该踩的坑都踩了。# user_service.py import sqlite3 import hashlib def get_db(): conn sqlite3.connect(app.db) return conn def login(username, password): db get_db() cursor db.cursor() query SELECT * FROM users WHERE username username AND password password cursor.execute(query) result cursor.fetchone() db.close() if result: return {id: result[0], username: result[1]} return None def transfer(from_account, to_account, amount): db get_db() cursor db.cursor() cursor.execute(UPDATE accounts SET balance balance - ? WHERE acc_id ?, (amount, from_account)) cursor.execute(UPDATE accounts SET balance balance ? WHERE acc_id ?, (amount, to_account)) db.commit() db.close() return True这段代码是我故意按照新手常犯的错误来写的但说实话我在真实项目里见过更严重的版本。它至少有四类典型问题登录函数直接拼接SQL这是教科书级的SQL注入漏洞密码用明文拼接进数据库查询既没加密也没有用参数化查询转账函数没有在事务中对两条UPDATE做一致性判断前面成功后面失败会导致账目不平amount字段没有任何合法性校验负数、零值都能传进来。3.2 在Trae里发起审查的完整操作步骤打开Trae创建或打开一个Python项目把上面的代码放进去。接下来按这几个步骤走在编辑器中打开user_service.py用鼠标选中整个文件内容或者把光标停在文件内让AI知道你要分析的对象是这个文件。调出Trae的AI对话框一般就是侧边栏那个AI助手按钮把上面那份审查提示词粘贴进去。在提示词末尾补充一句请审查以下代码然后把选中的代码粘贴进去如果是用CtrlA全选某些情况下Trae会直接把选区作为上下文不需要重复粘贴。回车发送。等待AI输出审查报告。这个流程我建议养成肌肉记忆因为它是另一个场景——AI写代码、AI解释代码、AI补测试用例——的共同底座。你会在Trae里反复使用选中代码→发指令→收结果→修改这个循环所以第一步分子式动作一定要熟练。3.3 审查输出长什么样以及怎么变成修改清单这里我根据多次实测总结一个典型的AI审查报告结构当然实际输出会有差异但框架是差不多的。AI给这份代码返回的问题通常包括严重程度问题修复建议严重SQL注入username和password直接拼接查询语句可被输入 OR 11 --绕过使用参数化查询cursor.execute(SELECT * FROM users WHERE username ? AND password ?, (username, password))严重明文密码比对数据库存明文密码等于没有认证使用bcrypt或argon2存储密码哈希登录时对输入做哈希再比对严重转账逻辑没有事务保证两条UPDATE之间如果发生异常会导致账目不平衡在try/except中包裹事务失败时rollback建议amount没有做合法性校验负数、零值可以正常转账增加if amount 0: raise ValueError提示get_db()每次新建连接未使用连接池使用连接池或SQLAlchemy engine来管理连接提示函数无类型注解维护困难增加参数与返回值类型注解拿到这份清单以后我的处理流程是先把严重级别的问题逐条改掉改完看diff然后把建议级别的问题批量过一遍能改的顺手改提示级别的先放着攒到一定数量再统一处理。这样一来审查报告直接变成了一张待办清单落地的效率比手动从零开始看代码高太多了。这里还有一个小技巧你可以让AI把每个问题对应的修复代码直接写出来不只是给建议。把提示词里具体修复建议改成对每个问题给出可直接替换的修复代码AI通常就会给出before/after对照。再配合Trae里AI修改功能的预览确认基本上所有机械性的修改都能一键完成。4. 常见问题与避坑指南4.1 AI误报怎么处理它说有问题就一定有吗我遇到过很多次AI信誓旦旦地说这个代码有问题实际检查下来要么是它没看懂上下文导致误判要么是它拿一个不适用于当前场景的最佳实践硬套。比如它曾经警告我某个FastAPI路由函数没有设置超时时间但实际上网关已经全局处理了超时这个警告没有意义。另外有的版本里AI会坚持认为if __name__ __main__:必须存在于每个文件里其实这完全看场景。处理误报的基本原则是严重级别越高越要人工复核。特别是安全问题AI说存在SQL注入一定要自己确认一下数据流确认后再修不要闭眼直接改。对于建议和提示级别的问题如果AI的建议和你的代码上下文冲突以你的上下文为准。AI是辅助工具不是权威本身。4.2 超大项目怎么审一次丢一万行代码进去AI根本扛不住很多人在我第一次推荐AI审查时会把整个项目几万个文件丢给AI然后抱怨AI回复得乱七八糟或者只分析了其中一小部分。这是对上下文窗口的误解。AI不是无限的即使支持很长的上下文输出质量和专注度也会随着长度下降。正确做法是分而治之。把一个大模块拆成文件级别审查文件太长的再按函数或类审查。我通常一个提示词只审一个文件最多加几个紧密相关的函数。另外有一个非常实用的策略增量审查。如果有git diff直接把diff内容发给AI让它只审变更的部分这比全量审查效率高得多也是代码审查的标准姿势。你还可以给AI提供足够的上下文。比如审查一个FastAPI项目在提示词里写上这个文件属于app/api/v1模块依赖services层配置在settings.py里AI的判断就会更符合实际。它知道当前代码的地位就不会随便把工厂模式之类的多余建议塞给你。4.3 怎么让AI记住团队规范把规范写进提示词而不是指望它自觉每个团队都有自己的一套代码规范有人强制类型注解有人不强制有人用black格式化有人坚持某一种缩进风格有人要求所有数据库查询走ORM有人允许部分场景用原生SQL。这些规范AI不可能自己知道但不告诉它它就按照训练语料里的通用习惯来这未必符合你的团队。解决方式很简单在审查提示词里加一段团队约束条件。比如团队约定 - 强制使用类型注解 - 禁止在业务代码中直接使用原生SQL必须通过SQLAlchemy ORM - 所有新增函数必须附带docstring - 外部API访问必须经过services层不直接在routes层写业务逻辑加完之后AI就能根据这些规则做针对性审查而不是泛泛而谈。我建议每个团队维护一份这样的团队审查提示词作为代码评审的标配工具。Trae里可以把它保存成一个固定文件或常用短语每次粘贴即可非常省事。4.4 效率提升的量化10倍是怎么算出来的标题说效率提升10倍这里我把账算清楚免得有人觉得是营销话术。我自己测过的数据是人工审查一个800行的Python文件仔细一点需要40到60分钟用AI辅助走一遍AI出报告5分钟我逐条复核和修复大约15分钟合计20分钟以内。这是2到3倍的提升还不算10倍。10倍发生在什么场景呢是全量代码走查或者新人熟悉项目的时候。八万行的老项目一个人从头到尾人工审不加班的话至少4到6个工作日我用AI按文件批量过一遍同时把严重问题列成清单再针对清单做人工确认一天到一天半就能完成全部走查。这就是10倍的由来。需要泼一盆冷水的是这个场景不是万能的。如果代码高度敏感、完全不能离开内网或者项目里全是那种没有任何注释、几千行一个文件的老旧模块AI审查效果会打折扣。它擅长的是规则明确、上下文完整的审查而不是一团乱麻里抽丝剥茧的考古工作。另外我建议不要只把AI审查用在提交前这一步它完全可以前置到开发过程中。我在Trae里写完一个函数经常顺手选中它让它快速过一遍有没有低级错误然后再提交。单个函数只有几行审查对话来回不到一分钟但能避免很多低级错误流到集成测试阶段。日常高频小剂量使用比月底集中大扫除更有价值。5. 结语让AI审查从能用变成靠谱的心得最后说几点我自己这几年反复调整提示词后沉淀下来的体会希望能让你少走点弯路。第一提示词要持续迭代。我前面给的模板不是一次成型的最开始我的提示词只有帮我审查代码六个字后来逐步加上维度、输出格式、项目背景、团队规范经过四五次调优才变成现在这个样子。每次发现AI在某类问题上判断不准我就把它加进上下文或约束条件里它下次就很少再犯。第二不要把AI的输出当成最终结论。AI的审查报告是一张高质量的问题清单但哪些要改、哪些不用改、怎么改、改完怎么验证这些决策必须由人来完成。越是严重的问题越要人工确认存在性后动手。我踩过最大的坑就是有一次想当然按AI建议改了一个严重性能问题结果那其实是一个特殊业务逻辑的故意实现改完之后反而引入了缺陷。从那以后我就养成了习惯AI的严重级别我要亲自看代码确认才肯动手。第三AI审查最难以替代的价值是教学。对于刚开始接触Python的新人AI给出的审查意见比很多文档都直观生动它会告诉你为什么这里不安全、那里会泄漏连接。我团队里新来的同事第一次看完AI的审查报告脱口而出原来代码里会有这么多隐藏问题。这个价值虽然不在效率数字里但长期来看比提高10倍效率更重要。如果你看完也想把AI审查接入自己的工作流我的建议是别急着搞复杂的东西。先从一个小文件开始复制一份上面的提示词模板把你手头最想清理的那个Python文件丢给Trae看看返回的审查报告再亲手把里面的严重问题修掉。跑完一次你就知道下一步该怎么做了。 AI代码审查实战：用Trae提示词实现10倍效率提升
去年我接手一个遗留Python项目代码量八万行。接手前我担心要先花两周做代码审查结果同事丢给我一句话用Trae写一套审查提示词让AI先扫一遍再人工复核。半信半疑试了一下从此就回不去了——现在每次合并代码前我的例行流程都是先让AI过一遍再处理真正需要人判断的问题。这篇文章是我在Trae提示词开发实战系列里的第十一篇不聊虚的直接拆解AI辅助代码审查这个场景。标题说效率提升10倍有人觉得夸张但如果你做大范围代码走查10倍这个数字一点都不浮夸。我会把这个过程拆成几块设计思路、提示词模板、真实操作和避坑心得。不管你正被代码审查搞得焦头烂额还是刚接触Trae想找个落地场景这篇文章都应该能帮到你。1. 先理清思路AI代码审查到底审什么1.1 为什么审查比写代码更适合AI先说一个容易被忽视的事实AI写代码是发散性任务审查代码是收敛性任务。开放式生成经常让AI自由发挥写到后面越来越飘但审查不一样它的目标非常明确——找出问题、给出修复建议。这种任务AI反而比人类更有优势因为它的知识面广、阅读速度快、不累不烦躁而且不会因为代码量太大而跳过细节。我刚接触提示词工程的时候总想着让AI一步到位把功能写完。结果发现模型越到后面越容易跑偏真正稳定落地的场景反而是代码审查、代码解释、测试用例生成这类结构清晰的任务。审查的本质是拿标准去套代码标准是固定的代码是输入输出是问题清单。这正好是AI最擅长的工作方式。另外一个关键点是代码审查的产出可以结构化。一条审查意见包含问题描述、所在位置、严重程度、修复建议。只要提示词里把输出格式约束好AI返回的结果就能直接对照处理不需要二次加工。这一点对后续落地到团队流程非常重要。1.2 审查的五个维度比你想的要多得多很多人以为代码审查就是看看有没有bug这是最大的误区。我自己的经验是一份合格的审查报告至少要覆盖五个方面缺一个都可能出事。审查维度关注点Python里常见的坑正确性逻辑错误、边界条件、异常处理、并发安全动态类型导致运行时类型错误、except Exception裸捕获、整数除法和浮点除法的混用安全性注入攻击、敏感信息泄漏、不安全的反序列化、危险函数调用用 f-string 拼接 SQL、把密码哈希返回给前端、pickle.loads处理不可信数据、eval执行外部输入性能时间复杂度、数据库访问次数、内存占用、资源释放循环内查询数据库N1问题、大列表做无谓拷贝、文件或连接没有关闭可维护性命名是否清晰、函数是否过长、代码重复、魔法数字变量名只有一个字母、单函数上百行、同一个常量到处硬编码可测试性是否方便Mock、依赖注入是否合理、全局状态函数内直接get_db()连数据库、随机数或时间戳写在业务逻辑里导致不可重复测试我见过太多团队做审查只看前两项结果线上故障大部分确实由正确性问题引起但真正让后续开发速度变慢的是可维护性和可测试性的问题。AI的强项在于它能同时覆盖所有维度不会因为人的注意力有限而漏掉细节。1.3 为什么是Trae你不该开着网页去审查既然AI能审查代码那直接用ChatGPT网页版把代码粘贴过去不就行了可以但体验差很多。Trae这类AI IDE的优势是代码就在编辑器里选中即分析上下文天然充足。Trae有几个具体好处第一它能直接读取项目结构给AI提供的不只是一段孤立的代码而是整个上下文第二它在编辑器侧边栏常驻审查完立刻就能改不用来回切换窗口第三Trae对中文场景和国内网络环境做得比较友好这对我这种要天天用的人来说很关键。单独的网页对话工具适合临时提问但如果要把审查变成日常流程一个集成在IDE里的AI助手才是正确选择。2. 提示词模板把资深工程师的审查经验写下来2.1 能用和好用的提示词差别到底在哪同样是让AI审查代码有人输入的是检查一下这段代码有人输入的是接近一页纸的结构化提示词。前者AI也能给你回话但结果多半是一堆正确的废话这段代码整体质量良好但有一些可以改进的地方例如考虑使用异常处理。这种回答你看了等于没看。我打个比方。提示词就像你给临时工布置任务。你跟他说打扫一下屋子他可能只把客厅擦了擦你要是跟他说把客厅、厨房、卫生间各擦一遍垃圾倒掉物品归位最后拍照给我看结果完全不一样。AI也是这样它不会主动揣摩你的潜台词你给它多大的边界它就干多大的活。好用的审查提示词必须包含五块内容角色设定、审查范围、审查维度、输出格式、代码上下文。角色设定让AI知道调取哪类知识库审查范围告诉它看哪里维度是检查清单输出格式决定了结果能不能直接干活上下文则是让它结合项目实际情况而不是空谈。2.2 一个可以复制就能用的Python审查提示词模板下面这个模板就是我平时在Trae里用的保留了核心结构你复制过去改成自己的项目描述就能用。这一段看起来很长的提示词其实就是把资深工程师的审查习惯固化下来。你是资深Python代码审查专家精通Python 3.10熟悉FastAPI、Flask、Django、 SQLAlchemy、async/await并发编程了解PEP8和Google Python Style Guide。 项目背景这是一个使用FastAPI SQLAlchemy PostgreSQL开发的后端服务 代码风格遵循PEP8但未强制使用类型注解。请基于这个背景审查代码。 请从以下维度审查这段代码 1. 正确性逻辑是否有漏洞边界条件是否处理异常分支是否缺漏 2. 安全性是否存在注入、敏感信息泄漏、危险函数调用、权限绕过风险 3. 性能是否存在不必要的重复计算、N1查询、资源未释放等问题 4. 可维护性命名、函数长度、重复代码、魔法数字、过度耦合 5. 可测试性是否方便单元测试外部依赖是否能轻松Mock 输出要求 - 按严重程度分为三档严重必须修复、建议建议优化、提示可选 - 每个问题必须包含问题描述、对应代码片段或行号、具体修复建议 - 如果某个维度没有问题请明确写未发现明显问题不要为了凑数而硬挑错 - 最终给出一句话总结这里我特别要解释两个容易被忽略的设计。第一是如果某个维度没有问题请明确写未发现明显问题不要为了凑数而硬挑错。这一句非常关键。大模型有很强的讨好倾向你不做限制它会想尽办法给你找几个毛病哪怕那个写法根本没问题反而干扰了你的判断。加了这句话之后审查报告会清爽很多。第二是项目背景这一部分。你告诉AI这是一个FastAPISQLAlchemy项目它就会用web服务的标准来审查你不说它可能拿一个数据科学脚本的标准来判断结果给出的建议完全对不上号。上下文对审查准确性影响极大后面我还会细说。2.3 提示词里必须写清楚的三件事除了上面模板里的内容还有三个小细节我建议一定写进去否则后续处理起来会非常痛苦。一是要求给出行号或代码片段。AI审查完之后你要能快速定位。如果它只说这个函数存在问题你还得自己去翻代码效率凭空少了一半。所以我在输出要求的第二条明确写了对应代码片段或行号。二是要求区分严重级别。没有分级的话AI会把变量命名可以更清晰和SQL注入漏洞放在同一个优先级里你会被噪音淹没。分三级以后先处理严重项再批量看建议项节奏就舒服多了。三是明确输出内容的边界。很多人忽略如果某个维度没问题请明确说没有这句话。AI在默认情况下有报喜不报忧的反面——它倾向于显得自己工作认真因此会强行挑刺。加上这句话以后报告里的每一条意见分量都会更足。3. 实操演示用Trae审查一个真实Python模块3.1 我准备的一个问题代码示例文档里讲一百遍不如实操一遍。我准备了一段典型的带病Python代码里面埋了多种问题我们直接拿它来走一遍完整流程。这是我在模拟一个用户服务模块时写的函数不多但该踩的坑都踩了。# user_service.py import sqlite3 import hashlib def get_db(): conn sqlite3.connect(app.db) return conn def login(username, password): db get_db() cursor db.cursor() query SELECT * FROM users WHERE username username AND password password cursor.execute(query) result cursor.fetchone() db.close() if result: return {id: result[0], username: result[1]} return None def transfer(from_account, to_account, amount): db get_db() cursor db.cursor() cursor.execute(UPDATE accounts SET balance balance - ? WHERE acc_id ?, (amount, from_account)) cursor.execute(UPDATE accounts SET balance balance ? WHERE acc_id ?, (amount, to_account)) db.commit() db.close() return True这段代码是我故意按照新手常犯的错误来写的但说实话我在真实项目里见过更严重的版本。它至少有四类典型问题登录函数直接拼接SQL这是教科书级的SQL注入漏洞密码用明文拼接进数据库查询既没加密也没有用参数化查询转账函数没有在事务中对两条UPDATE做一致性判断前面成功后面失败会导致账目不平amount字段没有任何合法性校验负数、零值都能传进来。3.2 在Trae里发起审查的完整操作步骤打开Trae创建或打开一个Python项目把上面的代码放进去。接下来按这几个步骤走在编辑器中打开user_service.py用鼠标选中整个文件内容或者把光标停在文件内让AI知道你要分析的对象是这个文件。调出Trae的AI对话框一般就是侧边栏那个AI助手按钮把上面那份审查提示词粘贴进去。在提示词末尾补充一句请审查以下代码然后把选中的代码粘贴进去如果是用CtrlA全选某些情况下Trae会直接把选区作为上下文不需要重复粘贴。回车发送。等待AI输出审查报告。这个流程我建议养成肌肉记忆因为它是另一个场景——AI写代码、AI解释代码、AI补测试用例——的共同底座。你会在Trae里反复使用选中代码→发指令→收结果→修改这个循环所以第一步分子式动作一定要熟练。3.3 审查输出长什么样以及怎么变成修改清单这里我根据多次实测总结一个典型的AI审查报告结构当然实际输出会有差异但框架是差不多的。AI给这份代码返回的问题通常包括严重程度问题修复建议严重SQL注入username和password直接拼接查询语句可被输入 OR 11 --绕过使用参数化查询cursor.execute(SELECT * FROM users WHERE username ? AND password ?, (username, password))严重明文密码比对数据库存明文密码等于没有认证使用bcrypt或argon2存储密码哈希登录时对输入做哈希再比对严重转账逻辑没有事务保证两条UPDATE之间如果发生异常会导致账目不平衡在try/except中包裹事务失败时rollback建议amount没有做合法性校验负数、零值可以正常转账增加if amount 0: raise ValueError提示get_db()每次新建连接未使用连接池使用连接池或SQLAlchemy engine来管理连接提示函数无类型注解维护困难增加参数与返回值类型注解拿到这份清单以后我的处理流程是先把严重级别的问题逐条改掉改完看diff然后把建议级别的问题批量过一遍能改的顺手改提示级别的先放着攒到一定数量再统一处理。这样一来审查报告直接变成了一张待办清单落地的效率比手动从零开始看代码高太多了。这里还有一个小技巧你可以让AI把每个问题对应的修复代码直接写出来不只是给建议。把提示词里具体修复建议改成对每个问题给出可直接替换的修复代码AI通常就会给出before/after对照。再配合Trae里AI修改功能的预览确认基本上所有机械性的修改都能一键完成。4. 常见问题与避坑指南4.1 AI误报怎么处理它说有问题就一定有吗我遇到过很多次AI信誓旦旦地说这个代码有问题实际检查下来要么是它没看懂上下文导致误判要么是它拿一个不适用于当前场景的最佳实践硬套。比如它曾经警告我某个FastAPI路由函数没有设置超时时间但实际上网关已经全局处理了超时这个警告没有意义。另外有的版本里AI会坚持认为if __name__ __main__:必须存在于每个文件里其实这完全看场景。处理误报的基本原则是严重级别越高越要人工复核。特别是安全问题AI说存在SQL注入一定要自己确认一下数据流确认后再修不要闭眼直接改。对于建议和提示级别的问题如果AI的建议和你的代码上下文冲突以你的上下文为准。AI是辅助工具不是权威本身。4.2 超大项目怎么审一次丢一万行代码进去AI根本扛不住很多人在我第一次推荐AI审查时会把整个项目几万个文件丢给AI然后抱怨AI回复得乱七八糟或者只分析了其中一小部分。这是对上下文窗口的误解。AI不是无限的即使支持很长的上下文输出质量和专注度也会随着长度下降。正确做法是分而治之。把一个大模块拆成文件级别审查文件太长的再按函数或类审查。我通常一个提示词只审一个文件最多加几个紧密相关的函数。另外有一个非常实用的策略增量审查。如果有git diff直接把diff内容发给AI让它只审变更的部分这比全量审查效率高得多也是代码审查的标准姿势。你还可以给AI提供足够的上下文。比如审查一个FastAPI项目在提示词里写上这个文件属于app/api/v1模块依赖services层配置在settings.py里AI的判断就会更符合实际。它知道当前代码的地位就不会随便把工厂模式之类的多余建议塞给你。4.3 怎么让AI记住团队规范把规范写进提示词而不是指望它自觉每个团队都有自己的一套代码规范有人强制类型注解有人不强制有人用black格式化有人坚持某一种缩进风格有人要求所有数据库查询走ORM有人允许部分场景用原生SQL。这些规范AI不可能自己知道但不告诉它它就按照训练语料里的通用习惯来这未必符合你的团队。解决方式很简单在审查提示词里加一段团队约束条件。比如团队约定 - 强制使用类型注解 - 禁止在业务代码中直接使用原生SQL必须通过SQLAlchemy ORM - 所有新增函数必须附带docstring - 外部API访问必须经过services层不直接在routes层写业务逻辑加完之后AI就能根据这些规则做针对性审查而不是泛泛而谈。我建议每个团队维护一份这样的团队审查提示词作为代码评审的标配工具。Trae里可以把它保存成一个固定文件或常用短语每次粘贴即可非常省事。4.4 效率提升的量化10倍是怎么算出来的标题说效率提升10倍这里我把账算清楚免得有人觉得是营销话术。我自己测过的数据是人工审查一个800行的Python文件仔细一点需要40到60分钟用AI辅助走一遍AI出报告5分钟我逐条复核和修复大约15分钟合计20分钟以内。这是2到3倍的提升还不算10倍。10倍发生在什么场景呢是全量代码走查或者新人熟悉项目的时候。八万行的老项目一个人从头到尾人工审不加班的话至少4到6个工作日我用AI按文件批量过一遍同时把严重问题列成清单再针对清单做人工确认一天到一天半就能完成全部走查。这就是10倍的由来。需要泼一盆冷水的是这个场景不是万能的。如果代码高度敏感、完全不能离开内网或者项目里全是那种没有任何注释、几千行一个文件的老旧模块AI审查效果会打折扣。它擅长的是规则明确、上下文完整的审查而不是一团乱麻里抽丝剥茧的考古工作。另外我建议不要只把AI审查用在提交前这一步它完全可以前置到开发过程中。我在Trae里写完一个函数经常顺手选中它让它快速过一遍有没有低级错误然后再提交。单个函数只有几行审查对话来回不到一分钟但能避免很多低级错误流到集成测试阶段。日常高频小剂量使用比月底集中大扫除更有价值。5. 结语让AI审查从能用变成靠谱的心得最后说几点我自己这几年反复调整提示词后沉淀下来的体会希望能让你少走点弯路。第一提示词要持续迭代。我前面给的模板不是一次成型的最开始我的提示词只有帮我审查代码六个字后来逐步加上维度、输出格式、项目背景、团队规范经过四五次调优才变成现在这个样子。每次发现AI在某类问题上判断不准我就把它加进上下文或约束条件里它下次就很少再犯。第二不要把AI的输出当成最终结论。AI的审查报告是一张高质量的问题清单但哪些要改、哪些不用改、怎么改、改完怎么验证这些决策必须由人来完成。越是严重的问题越要人工确认存在性后动手。我踩过最大的坑就是有一次想当然按AI建议改了一个严重性能问题结果那其实是一个特殊业务逻辑的故意实现改完之后反而引入了缺陷。从那以后我就养成了习惯AI的严重级别我要亲自看代码确认才肯动手。第三AI审查最难以替代的价值是教学。对于刚开始接触Python的新人AI给出的审查意见比很多文档都直观生动它会告诉你为什么这里不安全、那里会泄漏连接。我团队里新来的同事第一次看完AI的审查报告脱口而出原来代码里会有这么多隐藏问题。这个价值虽然不在效率数字里但长期来看比提高10倍效率更重要。如果你看完也想把AI审查接入自己的工作流我的建议是别急着搞复杂的东西。先从一个小文件开始复制一份上面的提示词模板把你手头最想清理的那个Python文件丢给Trae看看返回的审查报告再亲手把里面的严重问题修掉。跑完一次你就知道下一步该怎么做了。