Аудит кода с Claude Opus 5.5: как проверить каждую находку до слияния
Практический процесс для длительного аудита кода с Claude Opus 5.5: базовый прогон, воспроизведение дефектов, оценка риска, разбор архитектуры и регрессионные тесты.
Содержание
Вы запускаете Claude Opus 5.5 на несколько часов, а в ответ получаете десятки «критичных» замечаний и большой патч. Главная задача начинается после этого: понять, какие дефекты существуют на самом деле, какие предложения не ломают исходную архитектуру и что можно безопасно отправить в основную ветку.
Ниже модель рассматривается не как арбитр, а как инструмент поиска гипотез. Каждая принятая находка должна пройти шесть ворот: исходный прогон, воспроизведение, оценку риска, проверку архитектурного замысла, изолированное исправление и полный регресс.
Opus 5.5 подходит для широкого аудита, но не заменяет приёмку
Используйте модель, чтобы расширить охват проверки, а не чтобы автоматически одобрять изменения. В анонсе от 22 сентября 2026 года Anthropic отдельно называет миграции и аудит больших кодовых баз среди сильных сторон Opus 5.5 и приводит результаты внутренних испытаний и ранних пользователей. Это данные поставщика и отдельных тестировщиков, а не гарантия для вашего репозитория. Анонс Claude Opus 5.5.
Kent C. Dodds опубликовал запрос на аудит безопасности, производительности, доступности, поддерживаемости, масштабируемости, архитектуры, документации, тестов и автоматизации. По его словам, Opus 5.5 обнаружил серьёзную проблему безопасности, которую пропустили другие модели. Но в публикации нет описания уязвимости, шагов воспроизведения и контролируемого сравнения. Это повод проверить модель на своём проекте, а не основание принимать её вывод без доказательств. Публичная запись.
Правильная цель звучит так: получить как можно больше воспроизводимых, ранжированных и независимо проверяемых находок, а не максимальное число предупреждений.
До запуска зафиксируйте базовое состояние командами
Без чистого базового прогона нельзя отделить старые сбои от регрессий, появившихся во время работы модели. Сохраните SHA коммита, версии среды и зависимостей, точные команды и коды завершения.
Подставьте реальные команды проекта. Если проверка неприменима, так и отметьте — не придумывайте формальную команду ради списка.
git status --short
<install-command>
<lint-command>
<type-check-command>
<unit-test-command>
<integration-test-command>
<build-command>В базовой записи должны быть:
- SHA коммита, версия runtime, менеджер пакетов и важные версии зависимостей;
- команда, рабочий каталог, код завершения и краткий фрагмент ошибки;
- известные падения, нестабильные тесты и временные исключения;
- разрешённые каталоги и файлы, которые нельзя менять: сгенерированный код, старые миграции, lock-файлы, vendored-зависимости;
- критичные пути: аутентификация, авторизация, биллинг, миграции данных и внешние API-контракты.
Если исходный прогон уже красный, сначала зарегистрируйте проблему, изолируйте её или исправьте. Иначе модель может представить старый сбой как своё новое открытие.
На первом проходе запретите менять файлы
Поиск проблем и их исправление должны быть разными фазами. Когда модель одновременно исследует и редактирует, источник следующего сбоя становится неясен: исходный код, первый патч или взаимодействие нескольких патчей.
Начните с такого задания и дополните его правилами своего репозитория:
Проведи длительный аудит этого репозитория. На текущем этапе только исследуй и составляй отчёт; файлы не изменяй.
Область: <каталоги, сервисы, языки, критичные бизнес-процессы>
Исключения: <сгенерированные файлы, сторонний код, старые миграции, недоступные системы>
База: <выполненные команды, коды завершения, известные сбои>
Проверь:
1. безопасность и границы полномочий;
2. корректность, конкурентность, транзакции и обработку ошибок;
3. производительность и расход ресурсов;
4. доступность интерфейса, если применимо;
5. поддерживаемость и масштабируемость;
6. архитектуру и границы модулей;
7. пробелы в документации, тестах и автоматизации.
Для каждой находки укажи:
- уникальный ID и короткое название;
- уровень риска и объяснение влияния;
- файлы, символы и точные строки;
- условие запуска, ожидаемое и фактическое поведение;
- воспроизводимую команду или минимальный тест;
- краткий вывод команды и код завершения;
- возможное объяснение ложного срабатывания;
- минимальное направление исправления;
- проверки после исправления;
- уверенность: высокая, средняя или низкая.
Правила:
- Команду, которую ты не запускал, помечай «НЕ ЗАПУЩЕНА».
- Невоспроизводимую находку помечай «НЕ ПОДТВЕРЖДЕНО».
- Не удаляй, не пропускай и не ослабляй тесты ради зелёного результата.
- При нехватке ключей, сервисов или зависимостей остановись и перечисли, чего не хватает.
- После каждой фазы обновляй таблицу состояния и жди проверки.Сам текст задания не гарантирует дисциплину. Проверяйте терминальную историю, diff и фактический вывод тестов. Шаблон лишь делает обязательные поля явными и не даёт расплывчатому «здесь что-то не так» сразу попасть в очередь исправлений.
Разбейте длительную работу на четыре контролируемые фазы
Долгий запуск не должен означать неограниченные права и область. После каждой фазы останавливайте работу и проверяйте доказательства.
Фаза 1: карта системы
Модель читает код, конфигурацию, тесты и архитектурные документы. Результат — точки входа, границы доверия, потоки данных, внешние зависимости и критичные участки. Исправлять код и гнаться за количеством багов нельзя.
Фаза 2: кандидаты
Каждое замечание должно ссылаться на конкретный код и условие запуска. Общий совет без места и сценария отправляется в список улучшений, но не считается дефектом.
Фаза 3: воспроизведение по одному пункту
Сначала проверяйте потенциально серьёзные и дешёвые в проверке пункты. Один эксперимент — одна гипотеза. Сохраняйте необработанный вывод и параметры среды.
Фаза 4: план исправлений
В план попадают только воспроизведённые дефекты. Для каждого нужны минимальное изменение, влияние на совместимость, риск миграции, способ отката и список обязательных проверок. Архитектурные споры сначала решает владелец кода.
Состояние удобно вести в audit-plan.md:
| ID | Статус | Риск | Доказательство | Решение по архитектуре | Ветка | Принимающий |
|---|---|---|---|---|---|---|
| AUD-001 | Ждёт воспроизведения | Высокий | Пока нет | Не рассмотрено | — | — |
Разрешите только явный путь: кандидат → ждёт воспроизведения → воспроизведён → архитектура проверена → исправлен → принят. Уверенный тон модели не переводит запись на следующий этап.
Ворота риска: не смешивайте серьёзность и уверенность
Серьёзность показывает возможный ущерб, уверенность — качество доказательств. Возможный обход авторизации может быть высокорисковым, но пока иметь низкую уверенность. Стабильно воспроизводимая опечатка в логе — наоборот.
| Уровень | Когда применять | Минимум до исправления |
|---|---|---|
| Критичный | Возможны массовое повышение прав, утечка чувствительных данных, необратимая порча или отказ ядра | Контролируемое воспроизведение, границы влияния, немедленная проверка владельцем |
| Высокий | Затронут ключевой процесс или реалистичный ввод стабильно вызывает сбой | Минимальный тест, вывод команды, подтверждение владельца |
| Средний | Влияние ограничено, есть обход или нужны редкие условия | Повторяемое доказательство и решение о приоритете |
| Низкий | Локальное качество, документация, поддерживаемость или некритичная производительность | Конкретное место в коде и польза выше риска регрессии |
Модель может проследить путь выполнения, но не знает автоматически чувствительность данных, обязательства перед клиентами и допустимое время простоя. Эти параметры задаёт ответственный человек.
Ворота воспроизведения: превратите замечание в падающую проверку
Подозрительного фрагмента недостаточно. До исправления проверка должна падать, после — проходить. Для каждой находки зафиксируйте:
- коммит и среду, где она проявляется;
- минимальный вход;
- источник ожидаемого поведения — тест, спецификацию, контракт или бизнес-правило;
- фактический результат и необработанный вывод;
- причину, по которой существующие тесты не сработали;
- возможное законное объяснение текущего поведения.
Лучшее доказательство — минимальный регрессионный тест. Если автоматизация невозможна, нужны детерминированные ручные шаги, ожидаемые наблюдения и способ вернуть среду в исходное состояние. Проверяйте безопасность только в принадлежащей вам или разрешённой среде — локальной, изолированной либо тестовой.
Фраза «команда прошла» ничего не доказывает без самой команды, рабочего каталога, кода завершения и существенного вывода.
Ворота архитектуры: выясните, почему старый код устроен именно так
Более красивое решение может нарушить совместимость, порядок развёртывания или намеренную границу. До крупной правки изучите ADR, дизайн-документы, API-контракты, ограничения миграций и историю изменений.
Если история Git доступна, используйте:
git log -- <path>
git blame -L <start>,<end> <file>
git show <commit> -- <path>Попросите модель ответить:
- какое ограничение сохраняет текущая конструкция;
- какие клиенты, форматы данных и шаги развёртывания от неё зависят;
- исправляет ли предложение дефект или меняет поведение продукта;
- можно ли решить проблему меньшей локальной правкой;
- для отката потребуется вернуть код, конфигурацию или данные.
История даёт зацепки, но не гарантирует понимание намерения. Если основание не найдено, отметьте «архитектурный замысел неизвестен» и привлеките сопровождающего.
Ворота исправления: одна подтверждённая проблема — один небольшой патч
Не принимайте огромный diff с десятком несвязанных исправлений. Сначала добавьте тест, который стабильно падает на старом коде, затем внесите минимальное изменение.
| Ворота | Требование | Что делать при сбое |
|---|---|---|
| Область | Diff касается только согласованной находки | Отделить посторонние изменения |
| Регрессионный тест | Падает до исправления, проходит после | Исправить тест или пересмотреть вывод |
| Статика | Формат, lint и типы проходят | Не скрывать ошибки общим исключением |
| Тесты проекта | Нужные unit, integration и build проходят | Разобрать первый новый сбой до следующего патча |
| Архитектура | Владелец подтверждает границы и совместимость | Уменьшить изменение или вынести дизайн-ревью |
| Ручной review | Проверены права, ошибки, данные и удаления | Объяснить каждый подозрительный участок |
Запрещайте ложные «исправления»: удаление assert, skip тестов, проглатывание исключений, ослабление валидации, увеличение retry для маскировки гонки и рефакторинг, после которого исходный дефект невозможно проследить.
Ворота регрессии: запускайте проверки проекта, а не удобный набор модели
Итоговый прогон должен задаваться существующими скриптами или CI. Модель естественно выбирает проверки рядом со своим изменением, но этого недостаточно для слияния.
Сравните исходный и итоговый полный прогон; убедитесь, что новый тест падает на версии без исправления; проверьте lock-файлы, миграции, публичные API и значения конфигурации. Любое утверждение об ускорении сравнивайте в одинаковой среде и на одинаковом входе.
Нестабильный тест нельзя просто перезапускать до зелёного. Запишите картину падений, найдите источник недетерминизма и выясните, не усилил ли патч нестабильность.
Откажитесь от результата при любом из этих признаков
Находка не должна двигаться к слиянию, если:
- нет точного места, условия запуска или проверяемого доказательства;
- незапущенная команда объявлена успешной;
- риск выражен только прилагательным без пути влияния;
- патч вышел за согласованную область или незаметно меняет архитектуру;
- тесты удалены, пропущены или ослаблены, а ошибки проглатываются;
- изменение противоречит ADR, контракту или политике миграций без одобрения;
- доступно только итоговое резюме без команд и diff;
- безопасность подтверждается лишь тем, что другая модель согласилась.
Вторая модель полезна для поиска контрпримеров, но согласие моделей не является независимым доказательством. Независимая проверка — это тесты, вывод исполнения, история, спецификация и решение ответственного человека.
Финальный список перед слиянием
- Область, исключения и базовый коммит зафиксированы.
- Сохранены команды базового прогона и коды завершения.
- У каждой принятой находки есть ID и точное место в коде.
- Серьёзность и уверенность записаны отдельно.
- Дефект воспроизведён тестом или детерминированной процедурой.
- Проверены архитектурный замысел, совместимость и откат.
- Каждой находке соответствует небольшой проверяемый патч.
- Регрессионный тест падает до исправления и проходит после.
- Полные ворота проекта запущены через существующие скрипты или CI.
- Владелец кода проверил итоговый diff и явно одобрил его.
Публичные данные делают Opus 5.5 убедительным кандидатом для широкого и длительного аудита, но не отменяют проверку. Первый практический шаг — сохранить чистую базу и дать модели задачу «только аудит, без изменений», а не сразу разрешать ей переписывать код.
