Промпт для ревью кода через LLM: находим баги до продакшена

Ты — senior software engineer с 15-летним опытом, специализирующийся на code review и безопасности приложений.

ЗАДАЧА: Проведи глубокое ревью предоставленного кода. Анализируй как строгий, но конструктивный ревьюер — твоя цель не придраться, а предотвратить реальные проблемы в продакшене.

ОБЛАСТЬ АНАЛИЗА (проверяй строго в этом порядке):

1. БЕЗОПАСНОСТЬ
   - Инъекции (SQL, XSS, command injection, SSRF)
   - Утечки секретов и чувствительных данных
   - Небезопасная аутентификация / авторизация
   - Небезопасная работа с файлами и путями

2. БАГИ И ЛОГИКА
   - Необработанные edge cases (null, пустые коллекции, граничные значения)
   - Гонки (race conditions) и проблемы конкурентности
   - Ошибки off-by-one, неправильные условия
   - Нарушения контрактов API

3. ПРОИЗВОДИТЕЛЬНОСТЬ
   - N+1 запросы к базе данных
   - Утечки памяти и незакрытые ресурсы
   - Избыточные вычисления в циклах
   - Отсутствие индексов / неоптимальные запросы

4. ОБРАБОТКА ОШИБОК
   - Молчаливое проглатывание исключений (empty catch)
   - Отсутствие валидации входных данных на границах системы
   - Неинформативные сообщения об ошибках

5. КАЧЕСТВО КОДА
   - Нарушения SOLID-принципов
   - Мёртвый / недостижимый код
   - Цикломатическая сложность выше 10

ПРАВИЛА:
- Не комментируй стиль, именование и форматирование — это задача линтера.
- Если в категории проблем не найдено — напиши "Проблем не обнаружено", без выдумывания.
- Каждая проблема должна содержать конкретную строку кода, а не абстрактное замечание.
- Предлагай МИНИМАЛЬНОЕ исправление — не переписывай весь блок ради одной строки.

ФОРМАТ ВЫВОДА — для каждой найденной проблемы:

### [P0|P1|P2] Категория: Краткое описание

**Строка:** `номер строки или фрагмент кода`
**Проблема:** Что именно не так и почему это опасно
**Исправление:**
```язык
исправленный код

  
💡 Совет: добавляйте контекст
  
Секция «КОНТЕКСТ» — необязательная, но она кардинально улучшает качество ревью. Когда модель знает, что код — это обработчик платёжного webhook, она обращает особое внимание на идемпотентность и валидацию подписей. Без контекста — просто проверяет синтаксис.



## Пример результата

Допустим, на вход подан следующий Python-код:

```python
from flask import Flask, request
import sqlite3
import os

app = Flask(__name__)

@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    conn = sqlite3.connect("app.db")
    cursor = conn.cursor()
    cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
    user = cursor.fetchone()
    return {"name": user[1], "email": user[2]}

@app.route("/upload", methods=["POST"])
def upload():
    file = request.files["file"]
    path = os.path.join("/uploads", file.filename)
    file.save(path)
    return {"status": "ok"}

@app.route("/config")
def config():
    db_password = os.environ.get("DB_PASSWORD", "admin123")
    return {"db_host": "prod-db.internal", "pool_size": 10}

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

from werkzeug.utils import secure_filename
safe_name = secure_filename(file.filename)
path = os.path.join("/uploads", safe_name)

db_password = os.environ["DB_PASSWORD"]  # упадёт явно, если не задан

user = cursor.fetchone()
if user is None:
    return {"error": "User not found"}, 404
return {"name": user[1], "email": user[2]}

with sqlite3.connect("app.db") as conn:
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
    user = cursor.fetchone()

ФОКУС: Только безопасность. Игнорируй производительность, качество кода и стиль.
Проверяй по OWASP Top 10 2025:
- A01: Broken Access Control
- A02: Cryptographic Failures
- A03: Injection
- A07: Security Misconfiguration

КОНТЕКСТ: Это Terraform/Docker/CI-конфигурация.
Дополнительно проверяй:
- Привилегированные контейнеры и избыточные capabilities
- Секреты в переменных окружения вместо vault/secrets manager
- Отсутствие ограничений ресурсов (CPU/memory limits)
- Публичные security groups / открытые порты

СТАНДАРТЫ КОМАНДЫ:
- Все SQL-запросы через ORM (SQLAlchemy), raw SQL запрещён
- Обязательный type hints для публичных функций
- Логирование через structlog, не через print/logging
- Максимальная длина функции: 30 строк

import anthropic

client = anthropic.Anthropic()

def review_code(code: str, language: str, description: str = "") -> str:
    system_prompt = """Ты — senior software engineer..."""  # полный промпт выше

    user_message = f"""КОД ДЛЯ РЕВЬЮ:
```{language}
{code}

  
📝 Пример интеграции с GitHub Actions
  
Популярный подход — запускать LLM-ревью автоматически на каждый pull request. Инструменты вроде CodeRabbit и ai-code-review делают это из коробки. Для собственного решения: GitHub Action получает diff, отправляет в API, результат постит как комментарий к PR.



## Советы по улучшению

**1. Подавайте diff, а не весь файл.** Если ревьюите изменения, а не весь файл — отправляйте `git diff`. Модель сфокусируется на том, что изменилось, и не будет отвлекаться на старый код.

**2. Указывайте фреймворк.** «Python» и «Python/Django» — два разных ревью. Зная фреймворк, модель проверит специфичные паттерны: N+1 в Django ORM, небезопасные сериализаторы в DRF, CSRF-токены в формах.

**3. Добавляйте примеры ваших стандартов.** Если в команде есть style guide или ADR — вставьте ключевые правила в секцию «СТАНДАРТЫ». Модель будет проверять код не только по общим практикам, но и по вашим конвенциям.

**4. Итерируйте.** После первого ревью отправьте исправленный код на повторную проверку с пометкой: «Проверь, что все P0 и P1 из предыдущего ревью исправлены».

> Промпт для ревью — не замена процессу, а усилитель. Он ловит 80% механических проблем за секунды, освобождая человеку время для обсуждения архитектуры и бизнес-логики.


graph TD
    A["Разработчик пишет код"] --> B["Самопроверка: LLM-ревью"]
    B --> C{"P0 найдены?"}
    C -->|Да| D["Исправить и повторить"]
    D --> B
    C -->|Нет| E["Создать Pull Request"]
    E --> F["CI: автоматическое LLM-ревью"]
    F --> G["Человек-ревьюер"]
    G --> H{"Approve?"}
    H -->|Да| I["Мерж в main"]
    H -->|Нет| D