1. 项目概述当AI成为你的代码审查搭档最近在GitHub上看到一个挺有意思的项目叫keba2503/ai-pr-review-prompts。光看名字你可能会觉得这又是一个关于“如何用AI写代码”的仓库。但点进去仔细琢磨你会发现它的核心价值点完全不同它不教你生成代码而是教你如何与AI协作让它成为一个更聪明、更懂你、更能发现潜在问题的“代码审查员”。我自己在团队里负责过不少项目的代码审查工作深知这活儿有多费时费力。一个大型的Pull RequestPR动辄几百上千行代码你要逐行检查逻辑、风格、安全性、性能还要考虑架构的合理性。很多时候审查者自己也会陷入思维定式或者因为对某个模块不熟悉而遗漏关键问题。这个项目提供的正是一套精心设计的“提示词”Prompts你可以直接喂给像GitHub Copilot Chat、Cursor、Claude或者ChatGPT这类AI助手让它们基于这些提示词从特定角度帮你审查代码提供高质量的反馈。简单来说它把AI从一个“代码生成器”变成了一个“代码质量分析师”。这背后反映了一个趋势AI在软件开发中的角色正从“执行者”向“协作者”和“顾问”演进。这个项目就是为这种新型协作模式提供了一套标准化的“沟通话术”。2. 核心思路拆解从模糊提问到精准审查为什么我们需要专门的“审查提示词”直接问AI“帮我看看这段代码有什么问题”不行吗答案是效果天差地别。一个模糊的问题只会得到一个模糊、笼统甚至错误的回答。而keba2503/ai-pr-review-prompts的核心思路就是通过结构化、场景化的提示词将审查任务“降维分解”引导AI进行深度、定向的分析。2.1 结构化提示词的设计哲学这个项目的提示词设计遵循了几个关键原则这也是我们在日常与AI协作中应该借鉴的第一角色扮演Role-Playing。几乎每一条提示词的开头都会为AI设定一个明确的角色例如“你是一位经验丰富的安全工程师”、“你是一位专注于代码可读性和维护性的高级开发者”。这不仅仅是形式它从根本上框定了AI思考问题的视角和知识库的调用范围。让AI以“安全专家”的身份看代码它会本能地去寻找注入漏洞、不安全的依赖而以“维护性专家”的身份它则会重点关注命名、函数长度、注释和模块耦合度。第二任务分解Task Decomposition。它不要求AI一次性完成所有审查而是将庞大的审查工作拆解成一个个独立的、可执行的子任务。比如有专门审查“代码风格与一致性”的提示词有专门寻找“潜在Bug与边界条件”的提示词还有针对“性能优化”、“安全性”、“架构设计”甚至“测试覆盖率”的独立提示词。你可以根据当前PR的特点选择最相关的几个提示词组合使用。这种“分而治之”的策略让AI的分析更加聚焦和深入。第三输出格式化Output Formatting。好的提示词会明确要求AI以特定的格式输出结果。常见的格式是“问题描述具体代码行号或片段 严重性评级高/中/低 修改建议 修改后的代码示例”。这种格式化的输出极大地方便了审查者快速定位问题、评估优先级并直接将建议转发给提交者沟通效率倍增。第四上下文限定Context Bounding。提示词会明确告诉AI“请仅基于提供的代码变更diff进行分析不要假设或引入外部知识除非是公认的最佳实践或安全准则。” 这一点至关重要它防止了AI“过度脑补”产生一些与当前变更无关的、泛泛而谈的建议保证了反馈的针对性和准确性。2.2 项目内容架构解析浏览仓库你会发现提示词被分门别类地组织起来形成了一个小型“审查知识库”。主要类别通常包括代码质量与风格检查命名规范、函数长度、注释完整性、代码重复度DRY原则、复杂度圈复杂度等。安全审查查找常见的漏洞模式如SQL注入、XSS、不安全的反序列化、硬编码密钥、依赖项漏洞提醒等。性能与优化分析算法复杂度、指出低效的循环或数据库查询、建议使用更合适的数据结构、检查内存泄漏风险等。架构与设计评估模块的职责是否单一、耦合度是否过高、是否符合设计模式如是否误用单例、API设计是否合理等。测试与可靠性检查新增代码是否被测试覆盖、单元测试的断言是否充分、边界条件是否考虑周全、错误处理是否完备等。可维护性与文档确保公共API有文档、变更日志已更新、配置项有说明等。每一类下都有若干条具体的提示词。例如在“安全审查”类别下可能有一条专门用于检测“路径遍历漏洞”的提示词它会引导AI特别关注文件操作函数中用户输入的处理方式。实操心得不要试图一次性使用所有提示词去审查一个PR。这会让AI上下文过载也可能产生大量无关紧要的“噪音”反馈。最佳实践是先人工快速浏览PR判断其核心改动属于哪个领域例如是一个新增的API接口还是一个核心算法优化然后有针对性地选取2-3个最相关的提示词进行深度审查。比如一个涉及数据库查询的PR就优先使用“性能优化”和“安全审查”防SQL注入相关的提示词。3. 核心提示词详解与实战应用理解了设计思路我们来看看如何具体使用这些提示词。这里我挑选几个最具代表性的类别结合模拟的代码片段展示AI在“专业提示词”引导下能产生怎样远超普通问答的审查效果。3.1 代码风格与一致性审查假设我们有一段简单的Python函数提交def process_data(input_list): result [] for i in range(len(input_list)): item input_list[i] if item % 2 0: result.append(item * 2) else: result.append(item * 3) return result如果我们使用项目中一条典型的“代码风格与可读性”提示词AI可能会给出如下反馈问题1使用enumerate替代range(len(...))代码行第3行for i in range(len(input_list)):严重性低建议Pythonic的写法是使用enumerate它可以同时获得索引和值使意图更清晰且不易出错。修改示例for idx, item in enumerate(input_list): # 如果不需要索引直接 for item in input_list: 亦可问题2魔法数字Magic Numbers代码行第5行2 第7行3严重性中建议数字2和3直接出现在逻辑中降低了代码可读性和可维护性。应定义为有意义的常量。修改示例EVEN_MULTIPLIER 2 ODD_MULTIPLIER 3 ... if item % 2 0: result.append(item * EVEN_MULTIPLIER) else: result.append(item * ODD_MULTIPLIER)问题3考虑使用列表推导式代码行整个函数严重性低视情况而定建议对于这种简单的映射逻辑使用列表推导式可以使代码更简洁。但需注意如果逻辑复杂保持循环的可读性更好。修改示例def process_data(input_list): return [item * EVEN_MULTIPLIER if item % 2 0 else item * ODD_MULTIPLIER for item in input_list]你看一条好的提示词能引导AI不仅指出问题还解释了“为什么”这是问题Pythonic、可维护性并给出了具体的、可操作的改进方案。这比单纯说“代码风格不好”要有用得多。3.2 安全性深度审查安全性是AI辅助审查的强项因为它内置了海量的漏洞模式知识。假设有一段处理用户文件上传的Flask代码app.route(/upload, methods[POST]) def upload_file(): file request.files[file] filename file.filename # 危险操作直接使用用户提供的文件名 file.save(os.path.join(/var/www/uploads, filename)) return File uploaded successfully使用“安全审查-文件上传”类提示词后AI的反馈会非常尖锐和具体问题1路径遍历漏洞Path Traversal代码行第5行file.save(os.path.join(/var/www/uploads, filename))严重性高描述直接使用用户控制的filename拼接保存路径是极度危险的。攻击者可以提交类似../../../etc/passwd或../../index.php的文件名导致文件被保存到预期目录之外可能覆盖系统关键文件或导致信息泄露。修复建议净化文件名使用secure_filename函数来自werkzeug.utils去除路径信息。重命名文件使用随机生成的唯一文件名如UUID保存并将原始文件名存储在数据库中。验证文件类型检查文件内容Magic Number而非仅依赖扩展名。修改示例from werkzeug.utils import secure_filename import uuid def allowed_file(filename): return . in filename and filename.rsplit(., 1)[1].lower() in {png, jpg, jpeg} app.route(/upload, methods[POST]) def upload_file(): if file not in request.files: return No file part file request.files[file] if file.filename : return No selected file if file and allowed_file(file.filename): # 1. 净化原始文件名用于展示或记录 original_filename secure_filename(file.filename) # 2. 生成安全的存储文件名 safe_filename str(uuid.uuid4()) os.path.splitext(original_filename)[1] file.save(os.path.join(/var/www/uploads, safe_filename)) # 将 original_filename 和 safe_filename 的映射关系存入数据库 return File uploaded successfully else: return File type not allowed这样的审查反馈直接点出了高危漏洞、解释了攻击原理、并给出了包含多个防御层次的完整修复方案其价值不亚于一次专业的安全审计。3.3 性能与优化建议审查对于数据密集型或算法复杂的代码AI也能在提示词的引导下提供有价值的性能洞察。看下面这段JavaScript代码function findDuplicateTransactions(transactions) { const duplicates []; for (let i 0; i transactions.length; i) { for (let j i 1; j transactions.length; j) { if (JSON.stringify(transactions[i]) JSON.stringify(transactions[j])) { duplicates.push(transactions[i]); break; // 找到一个重复就跳出内层循环 } } } return duplicates; }使用“性能优化”提示词AI可能会指出问题1算法时间复杂度高且JSON.stringify代价昂贵代码行整个双重循环及第5行的比较严重性中取决于transactions数组的大小描述当前算法时间复杂度为O(n²)且每次比较都使用JSON.stringify将对象转换为字符串这在对象较大或结构复杂时非常耗时。JSON.stringify本身是O(n)操作这会使整体复杂度变得更糟。优化建议使用哈希表Map/Set利用Map或Set来存储已“见过”的交易的特征值哈希值将查找时间降至O(1)从而将整体算法优化至O(n)。生成稳定哈希键为每个交易对象生成一个稳定的哈希键而不是每次都进行字符串化。例如可以将关键属性如id, amount, timestamp拼接成一个字符串或者使用更专业的哈希函数。修改示例function findDuplicateTransactions(transactions) { const seen new Set(); const duplicates new Set(); // 使用Set避免重复添加同一重复项 for (const tx of transactions) { // 生成一个稳定的哈希键这里假设交易有唯一id // 更复杂的场景可能需要综合多个属性生成键 const key ${tx.id}-${tx.amount}-${tx.timestamp}; if (seen.has(key)) { duplicates.add(tx); } else { seen.add(key); } } return Array.from(duplicates); }注此示例假设id等属性可唯一标识重复。实际中需根据业务逻辑定义“重复”的精确含义来生成哈希键。AI在这里不仅指出了性能瓶颈还分析了瓶颈的根源O(n²) 昂贵的序列化并提供了利用数据结构进行优化的经典思路这对于不熟悉算法优化的开发者是很好的提醒。4. 如何将AI审查提示词集成到你的工作流拥有好的提示词只是第一步如何将其无缝、高效地融入你和团队的日常开发流程才是产生实际价值的关键。这里分享几种我实践过的方式。4.1 个人本地化使用与编辑器深度集成对于个人开发者最直接的方式是在你的代码编辑器或IDE中使用。以VS Code Cursor或GitHub Copilot Chat为例创建提示词片段库将keba2503/ai-pr-review-prompts中你觉得最有用的提示词保存到你的笔记软件如Notion、Obsidian或一个本地文本文件中并做好分类。在代码审查时调用当你需要审查某段代码时打开AI聊天侧边栏复制对应的提示词然后附上你要审查的代码片段通常可以通过符号或选中代码后右键菜单触发。AI会根据提示词的角色和指令给出审查意见。建立快捷方式一些AI工具支持自定义指令或快捷提示。你可以将最常用的审查提示词如安全检查、代码风格设置为快捷指令一键调用。注意事项直接粘贴大量代码到AI工具时需注意公司政策和个人隐私。确保你使用的AI服务符合公司的数据安全规定对于敏感代码可以考虑使用本地部署的大模型如通过Ollama运行CodeLlama等。4.2 团队协作与GitHub/GitLab集成对于团队项目可以尝试以下两种更自动化的方式方案A人工辅助的标准化流程在团队的PR模板中增加一个“AI辅助审查”的检查项。要求提交者在创建PR后自行使用指定的某几条核心提示词如安全、性能对变更进行预审查并将AI生成的主要建议摘要特别是中高危问题以评论的形式附在PR描述中。这相当于一次“自查”能提前发现很多低级问题减轻正式审查者的负担。方案B探索自动化机器人需谨慎评估这是一个更进阶的方案。可以利用GitHub Actions或GitLab CI/CD在PR创建或更新时触发一个自动化任务。这个任务会获取PR的diff内容。调用大模型API如OpenAI, Anthropic Claude并传入预设的审查提示词和diff内容。将AI的审查结果自动发布为PR评论。重要警告此方案存在显著挑战和风险成本频繁调用商业API审查大型PR成本可能不菲。噪音全自动审查可能产生大量低价值或错误的评论干扰团队。安全与合规将公司代码发送到外部API涉及严格的数据安全和合规审查绝大多数公司可能禁止此行为。效果波动AI输出不稳定可能需要复杂的后处理来过滤和格式化评论。因此如果团队想尝试自动化建议从一个非常保守的起点开始例如只对特定路径如/src/auth/的代码触发单一、高度确定性的审查如“检查是否有硬编码的密码或密钥”并且将评论先发布到内部测试频道供人工复核再决定是否同步到PR。4.3 定制与扩展打造你自己的提示词库keba2503/ai-pr-review-prompts是一个优秀的起点但每个团队、每个项目都有独特的技术栈、代码规范和业务关切。最好的提示词库一定是自己打磨出来的。从复盘开始收集你们团队在过往代码审查中经常出现的问题。是Null指针异常多还是API设计不一致或者是数据库N1查询问题频发将这些常见问题归类。为每类问题设计提示词基于现有模板用你们自己的“行话”和案例来编写提示词。例如如果你们用GraphQL可以写一条“检查GraphQL Resolver是否避免了N1查询问题”的提示词并给出使用DataLoader的最佳实践示例。融入团队规范将团队的编码规范命名约定、注释要求、日志格式等写成提示词。例如“请以我团队Java开发规范审查者的身份检查此代码是否符合我们的规约1. Service类命名以Impl结尾2. 日志必须使用SLF4J并正确区分error/warn/info级别...”持续迭代在使用过程中如果发现某条提示词总是给出无用反馈就调整它如果发现一个新的、反复出现的问题类型就为它新增一条提示词。逐渐形成你们团队的“AI审查知识图谱”。5. 局限性与最佳实践让AI成为助手而非主宰尽管AI辅助审查潜力巨大但我们必须清醒地认识到它的局限性并建立正确的使用预期。5.1 当前的主要局限性上下文长度限制大模型有token限制。一个大型PR的完整diff可能远超其处理能力。虽然可以通过只发送变更文件或分块处理来缓解但这可能破坏AI对代码整体结构的理解。“幻觉”与误报AI可能自信地指出一个根本不存在的“问题”或者给出错误的修复建议。它缺乏对项目完整历史、特定业务逻辑和架构决策的深层理解。缺乏业务洞察AI可以检查代码的“语法”和“通用语义”但无法理解这段代码在你们特定业务场景下的意义。一个看似“冗余”的检查可能是为了满足某个特殊的合规要求一个“复杂”的逻辑可能是为了处理某种罕见的边缘业务案例。创造性设计审查不足AI擅长检查是否符合既有模式但在评估一个全新的架构设计是否优雅、是否具备良好的扩展性方面能力还比较弱。5.2 有效使用AI审查的最佳实践基于以上局限我总结出几条让AI审查价值最大化的“军规”第一人为主AI为辅。AI审查员的意见永远是“建议”最终的判断权和决策权必须在人类开发者手中。特别是对于中高严重性的问题必须由人进行二次确认。第二明确范围分而治之。不要指望AI一次性审查一个巨型PR。对于大PR可以按文件分组审查将修改的文件按模块分组每次提交一组相关文件给AI审查。按审查类型分批先运行“安全审查”提示词再运行“代码风格”提示词最后运行“性能”提示词。第三提供精准上下文。在给AI发送提示词时除了代码diff可以额外提供一点背景信息这能显著提升反馈质量。例如“这是一个用户登录模块的修改新增了第三方OAuth2.0登录的支持。请重点审查OAuth回调URL的安全处理和用户信息合并的逻辑。”第四建立反馈闭环训练你的“专属AI”。当你发现AI给出了一个很棒的建议时可以思考“是什么让它的建议这么到位是我的提示词写得好还是它恰好‘懂’了这个模式” 反之如果它给出了糟糕的建议就调整你的提示词。这个过程本质上是在为你和你的团队“训练”一个更贴合的AI助手。第五结合传统工具。AI审查不应替代传统的静态代码分析工具如SonarQube, ESLint, Pylint、安全扫描工具如Semgrep, Snyk Code和单元测试。它们应该是互补的关系传统工具负责发现确定性的、模式化的低级问题如语法错误、未使用的变量、已知漏洞模式AI则负责提供需要一定“理解”和“推理”的高级反馈如逻辑缺陷、设计异味、可读性建议。将AI审查嵌入到CI/CD流水线中作为传统工具链之后的一层“智能增强”是理想的组合。最终keba2503/ai-pr-review-prompts这个项目提供的不仅仅是一组提示词更是一种方法论。它告诉我们与AI协作的关键在于“如何提问”。通过精心设计、持续优化的提示词我们可以将AI的通用能力精准地引导到软件开发中那些繁琐、耗时而又至关重要的质量保障环节上从而让开发者能更专注于创造性的设计和复杂的业务逻辑实现。这或许就是人机协同编程在未来一段时间内最切实可行的落地方向之一。