做Python开发这几年我发现自己最不耐烦的活儿不是写新功能而是给别人的代码做Review。尤其是那种几百行、横跨三四个模块的改动逐行看下来又累又容易看漏。直到我把Trae接进代码审查这条流水线才真正体会到什么叫“AI不是来替代你审的是来帮你把低价值环节全部干掉的”。这篇是Trae提示词开发实战系列的第11篇我直接把两个月来沉淀下来的AI辅助代码审查提示词方案摊开讲怎么设计、怎么调优、怎么在Trae里落地以及实际跑下来能省多少时间。这套方案的核心思路其实很简单——把“提示词”当成一个可复用的审查标准让AI先做全量初筛把明显的规范问题、边界漏洞、安全隐患全部扫出来人只负责深层次逻辑和业务判断。如果你是Python开发者天天绕不开代码审查或者正在研究AI编程提示词怎么真正用起来这篇应该能给你一套能直接抄作业的完整打法。1. 为什么用AI做代码审查以及它到底能省多少事1.1 传统代码审查的四个老大难先说说我自己的体感。以前在团队里做代码审查最烦的不是代码本身有多难而是四件事叠加在一起让人越审越疲惫。第一时间成本高得离谱。一个800行左右的PR认真review下来普遍要花40到60分钟。这个时间对写代码的人来说特别尴尬——你说它长吧好像也没什么特别复杂的逻辑你说它短吧又不能不看。第二审查标准完全随人走。同一个PRA同事审和B同事审结果经常是两个方向。有人死磕命名和函数长度有人只关心性能和并发结果就是代码质量完全取决于今天轮到谁值班。第三也是最容易忽略的一点浅层问题占了大头。缩进、命名、重复代码、魔法数字、异常吞噬……这些问题的确存在但真的不值得让一个高薪工程师花半小时去逐行扫描。第四反馈周期长。排队等review等reviewer有空等reviewer看完一来一回一个迭代就过去了。我做过一次很不严谨的统计团队里一个800行上下的PRreview平均耗时40到60分钟其中真正发现有价值逻辑问题的部分通常集中在最后10到15分钟——前面大部分时间都在做“机械扫描”。这个问题不解决代码审查就会一直处于“所有人都在做但所有人都不想做”的状态。1.2 AI代码审查能干什么、不能干什么AI在代码审查这件事上边界一定要划清楚否则期望值一旦放错位置后面全是失望。现阶段AI真正擅长的事有几类语法和规范扫描排第一这东西大模型见过的代码比我们多几个数量级PEP 8、命名习惯、明显的重复代码一眼就能挑出来。第二是常见缺陷模式识别比如空值危险、边界条件漏判、SQL拼接注入、文件资源没关闭、异常被静默吞掉这些“教科书级错误”是模型训练语料里最充足的部分。第三是性能优化建议比如循环里重复做同一件事、把整个列表加载进内存再过滤、频繁调I/O但可以合并这些一眼能看出来的性能问题AI判断得很准。第四是生成修复代码指出问题之后直接让AI给修复版本通常比人手动改还快。但AI也有明确的短板。它看不懂产品业务上下文——为什么这个规则要这么定、这段代码是给哪个客户用的、这个接口为什么不能改签名AI全都不懂。它也没法做跨模块的全局影响判断一个改动牵扯到另外三个服务AI只能看到你贴给它的这一堆文件。还有团队里约定俗成的架构决策、历史包袱、隐性的编码约定AI完全不知道。所以这套方案的核心指导思想是AI负责初筛和证据收集人负责裁决和深层次判断。AI干的活不是替代reviewer而是把reviewer从“扫描仪”变成“审判者”。1.3 为什么选Trae而不是别的方案我也试过拿别的工具做类似的事情比如直接在ChatGPT里贴代码用静态检查工具跑规则最后又切回Trae原因有三点。第一Trae本身就是AI编程IDE对话式交互的门槛低到几乎为零。打开Trae左边是代码右边是对话框把代码选中丢进去就能审不需要额外搭环境、配脚本、搞插件。第二提示词方案灵活度高。静态检查工具比如pylint、flake8只能按内置规则查查完给个编号要改还得自己看文档。而我在Trae里写提示词审查粒度可以任意调整——今天想重点查安全问题就把安全维度的权重拉高明天想查性能就让AI只扫性能问题。这种灵活性是固定规则工具给不了的。第三中文支持好也关键。团队里的review意见、提示词模板、修复建议都用中文AI输出可以直接贴到评论里大家看着不费劲。综合下来Trae在我这边的定位就是“AI代码审查的操作台”。2. AI代码审查提示词的设计思路与维度拆解2.1 提示词设计的总原则给AI两个“上下文”很多人写代码审查提示词上来就一句“请帮我审查这段代码”。这种提示词不是不能用而是输出质量非常不稳定——AI不知道该按什么标准审、该输出什么格式、该重点看什么。要稳定就得把两个上下文给足。第一个是角色上下文。让AI扮演什么角色直接决定了它的判断倾向和语言风格。我通常让AI扮演“有10年以上经验的高级Python代码审查专家”同时要求它精通PEP 8、性能优化、安全编码和软件架构。角色设定不是玄学而是让大模型从泛泛的“助手模式”切换到“专家模式”输出会更结构化也更敢下判断。第二个是任务上下文。这一步要非常具体地说清楚审查什么代码、按哪几个维度审、每个维度的优先级多高、最后输出什么格式、如果没问题怎么说。任务上下文越细AI的输出越贴近你要的格式。另外还有一个很重要的补充原则在提示词末尾加一句“如果有不确定的先标记为待确认不要臆断”。这一句能显著减少AI不切实际的猜测因为代码审查最怕的不是漏报而是瞎报——明明没问题的代码被说成有严重bug反而浪费人去核对。2.2 审查维度的优先级排序一份代码审查提示词维度不是随便堆几个关键词就完事而是要排优先级。我的排序是正确性 安全 性能 健壮性 可维护性 代码规范。这个优先级是有讲究的。代码审查的第一目标是防止缺陷进主干所以正确性问题必须排最前面——包括逻辑错误、边界条件遗漏、并发问题、数据一致性风险。这些东西一旦进了生产环境成本最高。排第二的是安全隐患SQL注入、路径遍历、敏感信息泄露、不安全的反序列化这些不一定每次都能遇到但只要出现一次就是事故。性能问题排第三因为多数性能问题不会直接挂但会影响体验和资源成本。再往后是健壮性、可维护性和规范这些虽然重要但不会造成线上事故属于质量管理范畴。为什么特别强调让AI按这个优先级输出因为reviewer的注意力是稀缺资源。如果AI先列10条空格问题再翻到第11条才说这里有SQL注入看的人很容易疲劳甚至会漏掉最重要的那条。把严重问题排在最前面等于让AI帮人类分配注意力。2.3 输出格式的重要性代码审查提示词还有一个经常被忽略的设计点输出格式。我的要求是每一个问题都必须包含四个部分问题描述、问题代码位置、问题原因分析、修改建议带示例代码。这样设计的原因很简单输出格式决定了下游的可用性。如果AI只说“第15行有SQL注入风险”你拿到手还要自己翻代码、想怎么改。但如果AI直接给出一段“before/after”的示例代码你几乎不用思考就能照搬。结构化的输出还有一个好处可以直接把AI的审查结果贴进团队的PR评论里甚至喂给后续的自动化流程比如自动生成待办事项。另外我要求AI在所有问题列完之后给出一个总体评价包括代码质量评分1到10分和最重要的3个改进点。这一步乍看像废话但其实很有用——评分可以帮你快速判断这个PR是“能直接合”还是“得返工”三个改进点还能直接变成给开发者的行动清单。3. 实战一套可复用的Python代码审查提示词3.1 核心提示词模板粘贴可用下面是我目前在Trae里直接使用的核心提示词模板你可以整体抄走按自己团队的情况微调你是一位拥有10年以上经验的高级Python代码审查专家精通PEP 8规范、代码性能优化、安全编码实践和软件架构设计。请对下面的Python代码进行严格审查。 项目背景选填有就填没有就忽略 - Python版本3.11 - 框架Flask SQLite - 团队规范函数必须有类型注解错误信息统一用英文 审查维度按优先级排序 1. 正确性缺陷逻辑错误、边界条件遗漏、并发问题、数据一致性风险 2. 安全隐患SQL注入、路径遍历、敏感信息泄露、不安全的反序列化、命令执行风险 3. 性能瓶颈O(n^2)复杂度的循环、重复计算、不必要的I/O操作、内存泄漏风险 4. 健壮性异常处理缺失、空值风险、资源未关闭、过度吞噬异常 5. 可维护性函数过长、复杂度超标、命名混乱、重复代码、魔法数字 6. 代码规范PEP 8规范、Pythonic写法如用enumerate代替range(len())、用with语句管理资源、缺失类型注解 输出要求 - 按严重程度从高到低排列问题严重程度分为[严重]/[警告]/[建议] - 每个问题依次包含问题描述、问题代码位置函数名/行号、问题原因分析、修改建议带示例代码 - 审查完毕后在末尾给出一段总体评价包括代码质量评分1-10分和最重要的3个改进点 - 如果代码没有问题请直接说明未发现明显问题并给出2-3条继续保持的注意事项 - 所有判断必须基于贴出的代码如果有不确定的地方先标记为[待确认]不要臆断 以下是待审查的代码 [代码粘贴区域]这个模板看起来长但每一部分都有存在的意义。有些朋友喜欢精简提示词觉得写长了浪费token但代码审查这个场景里模板的投入产出比非常高——一份模板能反复用几十次每次省下的是几十分钟的注意力。3.2 提示词各模块的设计意图逐条说下上面模板里容易被忽视的设计点。角色设定那句不是废话它决定了AI后续的判断基准。比如普通模式下AI对“函数没有类型注解”可能只字不提但在这个角色设定下它会把这个问题当作规范项记录下来因为“精通PEP 8规范的专家”天然会关注这些。项目背景这个区块是最值得动态调整的。如果你把项目的Python版本、框架、团队规范写进去AI的审查结果会贴合实际。比如你写了“函数必须有类型注解”AI就会专门检查这一点你写了“错误信息统一用英文”AI提建议时就会用英文错误信息不会跑偏。审查维度的优先级顺序直接决定了输出里哪个问题排在前面。我在1.2节说过AI需要被明确告知“先看什么再看什么”否则它会把所有问题混在一起输出跟倒垃圾一样。排序之后就清晰了先严重后轻微先事故后规范一眼找到重点。输出要求最后那句“如果有不确定的地方先标记为[待确认]不要臆断”是我踩过很多次坑之后才加上的。没有这句的时候AI经常会拿着一些模糊证据直接下结论。比如看到某个变量名带password就警告“可能导致敏感数据泄露”其实那只是个普通字典的key。加上这句之后AI遇到不确定的情况会用“待确认”的语气标注而不是言之凿凿地制造噪音。3.3 审查结果的长什么样拿一个故意写了几个问题的Python代码片段来演示看AI在设定好的提示词下会输出什么。下面这段代码是典型的“看起来能跑但全是雷”的示例import sqlite3 from flask import Flask, request app Flask(__name__) def get_user(username): conn sqlite3.connect(users.db) cursor conn.cursor() sql SELECT * FROM users WHERE username username cursor.execute(sql) result cursor.fetchone() conn.close() if result: return {username: result[0], email: result[1]} return None def total_price(items): total 0 for i in range(len(items)): price items[i][price] * items[i][quantity] if price 0: continue total price return total在Trae里用上面的提示词审查之后AI给出的关键结果大致长这样[严重] SQL注入风险 位置get_user() 第7行 问题原因使用字符串拼接构造SQL语句username参数可被恶意注入 修改建议 sql SELECT * FROM users WHERE username ? cursor.execute(sql, (username,)) [警告] 数据库连接未使用上下文管理器 位置get_user() 第5行 问题原因如果cursor.execute或conn.close之间发生异常连接会泄漏 修改建议 with sqlite3.connect(users.db) as conn: cursor conn.cursor() ... [警告] total_price() 中负价格检查逻辑有误 位置total_price() 第15行 问题原因代码先计算price再判断price 0但如果quantity为负数price也会为负这里会漏掉单价为负、数量为正的情况 修改建议 先单独判断items[i][price] 0再计算乘积 [建议] 循环中建议使用enumerate 位置total_price() 第14行 修改建议 for idx, item in enumerate(items):这个输出格式基本就是可以直接贴到PR评论里的状态。严重问题在最上面警告居中建议垫底每个问题都有位置、原因、修复方式。人reviewer拿到这个结果只需要确认第1、2、3条是不是真的而不用从头扫到尾找雷。4. Trae里的落地实操与优化迭代4.1 把提示词变成你的固定审查模板方案设计得再好用不起来也是白搭。在Trae里落地的第一步是把提示词模板变成一个固定文件而不是每次现敲。我的做法是在项目根目录建一个docs/文件夹放入code_review_prompt.md里面存放提示词模板。每次要做代码审查打开Trae把这个文件的内容复制到对话框然后把待审查代码贴到“代码粘贴区域”的位置回车完事。这个操作熟练之后不到一分钟。为什么用文件存而不是每次现写两个原因。第一是统一的模板才能保证输出格式稳定如果每个人每次写的审查维度都不一样结果没法比较。第二是方便团队共享和演化——我在上一篇文章里也提过提示词应该像代码一样被版控、被review、被迭代存进项目仓库里是最自然的方式。4.2 用真实代码跑一遍完整流程完整跑一遍的步骤大概是这样。假设你现在拿到一个PR改动集中在user_service.py执行流程如下第一步打开Trae把code_review_prompt.md里的提示词复制到对话框。第二步把user_service.py的完整代码粘贴到代码区域发送。第三步AI按提示词的输出格式返回审查结果。第四步如果结果里有“严重”和“警告”级别的问题直接追问一句“把以上所有严重和警告问题修复后的完整代码给我”。AI会生成一份修改后的新代码。第五步人工复核把AI改过的代码和新代码diff一眼确认改得对、不影响业务逻辑然后贴到PR评论区。这里有个关键细节不要让AI直接改你本地文件而是让AI先把结果输出你再决定要不要应用。原因很简单——AI改代码有时候会改过头比如为了修复SQL注入把整个函数的行数都重构了看起来很好但测试可能全挂。所以一定要人复核之后再合入。整个流程跑下来我实测的一个800行左右的PR从开始审查到拿到结论大概3到5分钟。这个速度在人肉审查时代完全不敢想。4.3 迭代优化提示词的关键技巧提示词不是写一次就完事的它需要随团队情况不断迭代。我总结下来有三个技巧。第一个是反馈循环。每次审查结果不满意的时候不要默默改提示词然后重试而是把“为什么不满意”直接告诉AI“刚才审查里第2条是错误的其实这是团队约定的一部分不算问题。以后审查时如果遇到类似情况请忽略。”AI会记住这次对话后续在这个会话里表现更贴合你的需求。把这些反馈沉淀到模板里提示词会越来越准。第二个是案例补充。团队里如果已经发生过经典错误比如某次事故是由于浮点数比较导致的那就在提示词的审查维度里专门加一条“特别关注浮点数精确比较问题历史案例见xxx”。AI不需要理解全部业务背景但只要这个规则在它就会照着检查。第三个是限定范围。如果这段代码改动很大但核心改动只涉及一个模块就在提示词里加一句“只关注xxx模块相关代码其他部分忽略”。这样可以避免AI把不相关的历史遗留问题全部抖出来把注意力聚焦在这次改动上。实测下来限定范围的审查质量和速度都有明显提升。4.4 进阶玩法把AI审查接入日常开发流用熟了之后你会发现这个提示词方案不仅能审PR还能横向扩展到日常开发流的其他环节。比如每次commit之前先让AI快速审查自己的diff。以前自己写完代码后习惯自己先看一遍diff但人看自己的代码有个最大的问题——自动忽略已知缺陷。AI没有这个成分它会把你代码里的低级错误原封不动指出来。我现在的习惯是写完一个功能先让AI快速审一遍再提交4.2节里的“严重”问题有很大一部分是在这个阶段被拦下来的。再比如把审查提示词从“给整段代码做审查”改成“给diff做审查”。做法很简单在提示词里加一句“以下是本次改动的diff请只审查diff里面新增和修改的行”然后把git diff的输出贴进去。这样一次能审几百行diff而且不会因为上下文过大导致AI注意力涣散。还有一个进阶玩法是把提示词升级成团队规范检查器。把团队编码规范、commit规范、文档要求全部写进提示词让AI在审查代码的同时检查文档是否同步更新、测试是否覆盖、命名是否符合约定。这一步等于把代码审查从“查bug”升级成了“查质量”。5. 常见问题与排查技巧实录5.1 假阳性报告太多怎么办AI审查最常见的问题就是假阳性——明明没问题的代码被说成有问题。第一次跑模板的时候可能10条结果里有4条是不成立的看着就很泄气。排查方向有三个。第一是在提示词里加强约束把“不要臆断”“所有判断必须基于贴出的代码”这句话的位置往前挪并且加一句“宁缺毋滥只报告确定存在的问题”。第二是把审查维度收窄比如第一次只审安全正确性不要六个维度全开减少AI为了“凑维度”而硬凑问题的概率。第三是要求AI在每条问题后面标注置信度比如“确定”或“存疑”存疑的问题自动沉底不占用首页注意力。5.2 提示词忘记了项目上下文怎么办AI对项目背景了解不够深是导致审查结果“很专业但不对路”的主要原因。比如不知道项目用的是Flask还是Django、不知道数据库用的SQLite还是PostgreSQL给出的优化建议就会跑偏。解法是主动喂上下文。最简单的是在提示词的“项目背景”区域把requirements.txt或pyproject.toml的核心内容贴进去再把项目里约定成俗成的架构规则比如“所有数据库操作放dao层”“服务层不允许写SQL”写进去。这样AI的审查基准就从“通用Python专家”变成了“懂你这个项目的Python专家”。5.3 审查结果不稳定、时好时坏同一个提示词早上跑和晚上跑结果差别很大这在大模型场景里很常见但有一些方法能大幅降低波动。第一个方法是在提示词里加一个“审查前准备”步骤要求AI先列出它准备检查的问题清单再逐项回答。这一步本质上是让AI把审查过程显式化而不是一次性输出一个黑盒结果。实测下来显式化之后的结果稳定度高很多。第二个方法是进行few-shot示范在提示词里放一条你认为审得特别好的输出样例告诉AI“请参考这个格式和深度”。有了参照物AI的输出会被明显拉回正轨。第三个方法比较玄学但有效同一个会话里尽量不要切换话题固定在一个session里连续做审查让AI保持“代码审查专家”的状态。5.4 大文件/长函数处理不动代码文件太大一次性贴给AI要么输出变慢要么审查精度下降。这个问题在小项目里不明显在遗留系统里几乎天天遇到。我的处理方式有三种。第一是按函数拆开审先把整个文件给AI告诉它“先只看函数A和函数B”一次聚焦一个函数精度高很多。第二是先概览后深入先让AI做“架构级概览”比如让AI总结这个文件的职责、核心链路、风险点然后再针对风险点重点审查。第三是贴diff而不是整份文件如果这次改动只涉及几个函数那就只贴这几个函数的改动diff不要整个文件全贴进去。这三种方式本质上是同一个思路——控制上下文宽度让AI的注意力集中在要紧的地方。最后再分享一个我个人的实操体会这套方案我用了两个多月最大的感受不是“AI把代码审查变得完美了”而是“我不用再从第一行扫到第一百行了”。以前审一个PR前半小时很容易被空格、命名、显而易见的边界问题消耗掉现在这个环节完全交给AI我的时间全部花在AI标记的“严重”和“警告”项上这才是人该干的活。如果你也想尝试我建议不要一上来就追求完美先用这批提示词模板跑两个真实的PR把你不满意的输出反馈给AI迭代三五次它就会变成你真正顺手的审查搭档。