用途：让 AI 代理对源文件、目录、拉取请求 URL、diff 或补丁文本执行结构化代码审查，逐行给出可执行反馈，覆盖正确性、安全、性能、可读性与可维护性。
工作流程：解析输入并建立上下文，判断是单文件、目录还是 PR diff；若是 PR，则获取 diff 并确定基线分支，只审查变更行，同时读取相关配置文件（linter 配置、风格指南、类型定义）以对齐项目标准。随后理解变更意图（读提交信息、PR 描述与周边代码），先一句话概括变更，再依次检查正确性与缺陷、安全性、性能与可扩展性、可读性与可维护性。
审查清单类别：Bugs（空引用、越界、逻辑错误、未处理异常）、Security（注入、XSS、硬编码密钥、缺失鉴权、不安全依赖）、Performance（O(n²) 循环、N+1 查询、不必要分配、阻塞 I/O）、Readability（命名不清、函数过长、缺文档、格式不一致）、DRY（复制粘贴、应抽取的重复逻辑）、错误处理（吞异常、缺重试、错误信息不清）、Testing（新逻辑缺测试、既有测试损坏、未覆盖边界）。
使用方式：提供以下输入之一——文件路径；目录路径（审查目录内所有源文件）；拉取请求 URL（如 https://github.com/user/repo/pull/42，只审查上下文中的变更行）；直接粘贴的原始 unified diff 或补丁文本；可选焦点区域，如“focus on security”或“check performance only”。
严重级别：Critical / Warning / Info，便于作者区分必须修复项与建议项。
最佳实践：审查 diff 而非整文件；明确标注严重级别；给出具体修复代码而非笼统评价；每轮聚焦影响最大的 5–7 个问题；肯定良好模式；代码与测试一并检查。
边界情况：代码生成器或 vendor 目录产物默认跳过；超过 1000 行的大 diff 会提示拆分并优先审查高风险文件；根据检测到的语言调整对惯用法的期望；缺少完整仓库上下文时会明确标注假设；纯格式或重命名变更会确认无语义差异后给出简短通过而非完整报告。
限制：资料未提供安装命令、收费、价格、平台或效果数据。