代码审查

适用场景

1 Pull Request 自动门禁：在合并前自动扫描新增代码，拦截规范、安全和性能问题。

2 遗留系统代码体检：对老旧仓库批量巡检，输出风险清单和修复优先级。

3 安全合规审计：针对支付、用户数据等敏感模块，按OWASP规则做专项漏洞扫描。

4 研发效能度量：统计团队代码问题分布，生成周报驱动规范培训和改进。

核心Prompt（安装配置用）

你是企业级代码审查Agent，职责是对提交的代码进行规范、安全、性能三维度自动审查。

角色设定：你是一名资深技术评审专家，熟悉主流语言规范（Java/Python/Go/JS）、OWASP Top 10、常见性能反模式，输出必须客观、可执行、无误报倾向。

任务描述：接收代码片段或diff，逐项检查：1）代码规范：命名、注释、复杂度、重复代码、异常处理；2）安全漏洞：注入、越权、敏感信息硬编码、不安全依赖、日志泄露；3）性能问题：N+1查询、循环内IO、大对象拷贝、锁粒度、缓存误用。

输出格式：按JSON返回，字段包括 summary（总体结论）、issues（数组，每项含severity: high/medium/low、category、file、line、problem、suggestion、example_fix）、metrics（问题数统计）。

约束条件：1）只审查给定代码，不臆测未提供上下文；2）每条问题必须给出可落地的修复建议和示例；3）严重级别需有依据，避免全部标为high；4）不修改业务逻辑假设，只提改进建议；5）对无法确定的问题标注“需人工确认”；6）输出语言为中文，代码示例保留原语言。

所需工具 / API对接

需对接：Git平台API（代码托管平台/GitLab/Gitee）拉取PR与diff；CI/CD（Jenkins/GitLab CI）触发流水线；静态分析工具（SonarQube、Semgrep、ESLint）作为补充；缺陷系统（Jira/禅道）自动建单；企业IM（钉钉/企微/飞书）推送审查结果；LLM API（ OpenAI/通义/文心）提供推理能力。

安装部署步骤

11. 环境准备：确认服务器Python3.10+、Docker24+、Git可用，命令：python3 --version && docker --version && git --version。

22. 安装依赖：pip install fastapi uvicorn requests pyyaml openai gitpython，或使用Docker镜像 docker pull aiagent/codereview:latest。

33. 配置参数：复制config.example.yaml为config.yaml，填入LLM_API_KEY、GIT_TOKEN、WEBHOOK_SECRET、severity_threshold等。

44. 导入Prompt：将core_prompt写入prompts/codereview.txt，在config.yaml中指定prompt_path: prompts/codereview.txt。

55. 连接工具API：配置Git平台webhook指向 http://your-host:8000/webhook，配置Jira/IM的token和地址，验证连通性：curl -X POST /health。

66. 测试验证：执行 python -m app.test --repo demo --pr 1，检查输出JSON的issues字段和severity分布是否符合预期。

77. 上线部署：docker compose up -d，配置Nginx反代和HTTPS，设置日志轮转与告警。

88. 灰度运行：先对1-2个仓库开启只读模式，观察误报率，再逐步放开拦截。

配置参数

参数名	说明	默认值
`severity_threshold`	触发阻断的最低严重级别	high
`language`	审查代码语言，支持auto自动识别	auto
`max_diff_lines`	单次审查最大diff行数，超出则分批	2000
`enable_security`	是否开启安全漏洞检查	true
`enable_performance`	是否开启性能问题检查	true
`notify_channel`	结果推送渠道，如dingtalk/wecom/feishu	dingtalk

效果示例

输入：PR diff包含Python代码，其中SQL拼接用户输入、循环内调用数据库、变量命名无意义。
输出：{"summary":"发现3个问题，其中1个高危","issues":[{"severity":"high","category":"security","file":"user.py","line":42,"problem":"SQL字符串拼接导致注入风险","suggestion":"使用参数化查询","example_fix":"cursor.execute('SELECT * FROM users WHERE id=%s',(uid,))"},{"severity":"medium","category":"performance","file":"user.py","line":55,"problem":"循环内查询数据库产生N+1","suggestion":"批量查询后内存关联"}],"metrics":{"high":1,"medium":1,"low":1}}

常见问题

Q1：误报太多怎么办？
A：调高severity_threshold，或在config.yaml中增加ignore_rules，对特定规则做白名单，并收集误报样本迭代Prompt。

Q2：支持私有化部署吗？
A：支持。可对接本地化LLM（如Qwen、ChatGLM）和内网Git平台，数据不出域。

Q3：大仓库审查超时如何处理？
A：设置max_diff_lines分批，或用异步任务队列，仅审查增量diff而非全量。

Q4：如何与现有CI集成？
A：在流水线中增加一步调用 /review 接口，返回非0退出码即可阻断合并。

Q5：审查结果能自动修复吗？
A：当前提供修复建议和示例，自动改码需谨慎，建议人工确认后再提交。

企业落地建议

部署方式：推荐Docker Compose单机起步，日审查量大的团队用K8s横向扩展。成本估算：中小团队月成本约300-800元（LLM API+服务器），私有化部署一次性硬件投入约2-5万元。注意事项：先只读灰度，积累误报数据再开拦截；敏感代码建议私有化LLM；建立规则库和例外清单，定期复盘；与现有CI/CD和缺陷系统打通，避免形成信息孤岛。需要我们帮你落地吗？可以试试免费AI诊断→