--- title: "AutoFix" id: "351" type: "page" slug: "autofix" published_at: "2026-05-19T11:30:47+00:00" modified_at: "2026-06-13T00:52:52+00:00" url: "https://pastukhov.com/code/docs/autofix" markdown_url: "https://pastukhov.com/code/docs/autofix.md" excerpt: "AutoFix — это мост между вашими сборками и ИИ-моделью. Когда он включён, он отслеживает результаты…" --- # AutoFix [https://pastukhov.com/code/docs/autofix.md](https://pastukhov.com/code/docs/autofix.md) AutoFix — это мост между вашими [сборками](/code/docs/build-deploy) и ИИ-моделью. Когда он включён, он отслеживает результаты сборок на наличие ошибок и предупреждений, оборачивает их в сообщения чата и отправляет в ИИ для исправления. Это создаёт автоматизированный цикл обратной связи: модель вносит изменения, сборки их проверяют, ошибки возвращаются обратно, и цикл повторяется, пока всё не пройдёт успешно. Это означает, что вам нужно только вручную проверить результаты *после* завершения всего автоматизированного тестирования и исправлений — это экономит огромное количество времени и сил. При реализации крупной функции может потребоваться 30-60 минут, чтобы дождаться завершения AutoFix, но всё это время полностью ваше: вы можете работать над другими проектами или просто отдохнуть. Это также снижает ментальное давление, потому что вам не нужно видеть и реагировать на все эти незначительные ошибки компиляции, линтинга и тестирования — вы возвращаетесь только тогда, когда код полностью чистый, рефакторенный, протестированный и полностью функциональный. ## Включение и отключение AutoFix Найдите **переключатель AutoFix** в области ввода чата. Он работает как простой переключатель вкл/выкл: ![Переключатель AutoFix в области ввода сообщений чата](https://pastukhov.com/wp-content/uploads/2026/06/autofix-toggle.png) - **Включить** — AutoFix периодически опрашивает сборки. Когда он находит ошибки или предупреждения, он внедряет их как сообщения чата, чтобы ИИ-модель могла их исправить - **Отключить** — AutoFix прекращает мониторинг. Ошибки сборки появляются в [панели сборки](/code/docs/build-deploy) , и вы обрабатываете их вручную — либо исправляя их сами, либо спрашивая ИИ в чате, либо нажимая кнопку Send в диалоге вывода сборки Включайте и выключайте AutoFix в любое время. Включайте его, когда хотите автоматизированную обработку ошибок во время разработки с помощью ИИ, и отключайте, когда предпочитаете просматривать и устранять ошибки самостоятельно. ## Как работает AutoFix AutoFix работает как фоновая служба, которая периодически опрашивает ваши сборки. Вот что именно происходит: 1. **Опрос сборок** — AutoFix проверяет все сборки в порядке зависимостей. Он ищет первую сборку, которая завершилась с ошибками или предупреждениями, убеждаясь, что все зависимые сборки также завершены перед продолжением 2. **Приоритет ошибок** — Если несколько сборок имеют проблемы, AutoFix выбирает ошибки вместо предупреждений. Он отправляет все ошибки или все предупреждения из текущей сборки одновременно, позволяя модели вносить массовые исправления 3. **Проверка дубликатов** — Перед отправкой чего-либо AutoFix проверяет последние 10 пользовательских сообщений в текущем чате. Если то же самое содержание ошибки уже было отправлено недавно, он пропускает его, чтобы избежать бесконечных циклов 4. **Внедрение как сообщение чата** — Разобранные ошибки оборачиваются в блок кода markdown с именем файла `build.log` и отправляются как пользовательское сообщение. Для предупреждений добавляется “fix warnings, don’t ignore them”. Сообщение попадает в последнюю активную сессию чата 5. **ИИ исправляет код** — Модель получает контекст ошибки, анализирует проблему, читает соответствующие исходные файлы и вносит изменения в код для решения проблемы 6. **Перезапуск сборок** — Изменения файлов от исправления автоматически запускают соответствующие [сборки](/code/docs/build-deploy) . Парсер сборки извлекает ошибки и предупреждения из нового вывода 7. **Цикл повторяется или завершается успешно** — Если сборка прошла успешно, цикл заканчивается и [развёртывание](/code/docs/build-deploy) перезапускается автоматически с исправленным кодом. Если ошибки остаются, AutoFix подхватывает их при следующем опросе, и цикл продолжается AutoFix обрабатывает только тогда, когда нет активной ИИ-сессии. Он ждёт, пока модель простаивает и все поставленные в очередь пользователем сообщения отправлены и обработаны, прежде чем внедрять сообщения об ошибках. Это предотвращает конфликты между ручной работой в чате и автоматическими исправлениями. [Prompt builds](/code/docs/validation/prompt-builds) всегда отправляются только после успешного прохождения автоматических сборок, обеспечивая чистое состояние перед тяжёлыми ИИ-задачами. ## Обработка ошибок и предупреждений AutoFix по-разному обрабатывает ошибки и предупреждения: - **Ошибки** — Отправляются в ИИ как есть. Модель видит разобранный вывод ошибок и пытается исправить основную проблему - **Предупреждения** — Отправляются с добавлением “fix warnings, don’t ignore them”. Эта инструкция предотвращает игнорирование предупреждений моделью как некритических и побуждает её надлежащим образом устранить их Когда существуют и ошибки, и предупреждения, AutoFix приоритизирует ошибки. Он не будет отправлять предупреждения, пока все ошибки сборки не будут устранены. Это гарантирует, что сначала решаются самые критические проблемы. Содержание ошибок и предупреждений поступает от [парсера сборки](/code/docs/build-deploy) — того же разобранного вывода, который вы видите в диалоге вывода сборки. Это означает, что AutoFix пользуется каждым шаблоном парсера, который вы добавляете: чем больше инструментов охватывают ваши сборки, тем больше типов ошибок AutoFix может автоматически исправить. ## Ручная отправка ошибок Вам не нужно включать AutoFix, чтобы отправлять ошибки сборки в ИИ. В каждом диалоге вывода сборки есть кнопка **Send**, которая работает так же: - Откройте диалог вывода сборки (нажмите имя сборки в [панели сборки](/code/docs/build-deploy) ) - Переключитесь на вкладку Errors или Warnings - Нажмите **Send** — содержимое оборачивается в блок кода `build.log` и отправляется в текущий чат как пользовательское сообщение Это полезно, когда AutoFix отключён, но вы всё ещё хотите, чтобы ИИ посмотрел на конкретные ошибки, или когда вы хотите выборочно определить, какие ошибки отправлять, вместо того чтобы позволить AutoFix автоматически обрабатывать их все. Есть также более быстрый способ исправить проблемы парсера напрямую: выберите любой текст в областях вывода сборки, развёртывания или скриптов (как в панелях, так и в диалогах), и появляется плавающая кнопка **Fix parser**. Нажатие на неё отправляет выбранный текст в ИИ с подсказкой, нацеленной на соответствующий файл парсера (`build.parser`, `deploy.parser` или `output.parser`), чтобы ИИ мог добавить недостающие шаблоны без ввода с вашей стороны. ## Мониторинг AutoFix AutoFix работает в фоновом режиме, но вы всегда можете отслеживать, что он делает: - **История чата** — Автоматически созданные сообщения появляются в последнем активном чате. Откройте его, чтобы увидеть контекст ошибки, который был отправлен, а также ответ ИИ и изменения в коде - **Панель сборки** — Наблюдайте за запуском, выполнением и завершением сборок в реальном времени. Смотрите, как счётчики ошибок меняются с красного на зелёный по мере того, как AutoFix их устраняет. Нажмите на значки ошибок, чтобы просмотреть конкретные проблемы - **Панель развёртывания** — После успешного прохождения всех сборок наблюдайте за автоматическим перезапуском вашего приложения с исправленным кодом - **Панель Git** — После успешного цикла исправлений просмотрите изменения в [панели Git](/code/docs/git) перед коммитом или пушем Просмотр работы AutoFix — это хорошая практика. Хотя он хорошо обрабатывает большинство рутинных ошибок, иногда он может вносить изменения, которые не совсем подходят для вашего конкретного случая использования. Быстрая проверка diff гарантирует, что всё выглядит правильно перед коммитом. *Совет: Если вы заметили, что модель повторяет одну и ту же ошибку при исправлении кода, попросите её обновить [CLAUDE.md](/code/docs/claudemd) или её [навыки](/code/docs/skills) , чтобы предотвратить это в будущем.* ## Лучшие результаты с большим количеством сборок Эффективность AutoFix напрямую зависит от того, сколько [сборок](/code/docs/build-deploy) вы настроили. Каждая сборка — это независимая проверка качества, которая выдаёт структурированный вывод ошибок — и AutoFix может исправить всё, что может обнаружить парсер. Проект только с компиляторной сборкой даёт AutoFix один источник обратной связи об ошибках. Добавьте сборку линтера, сборку проверщика типов и сборку запуска тестов, и вдруг у AutoFix есть четыре независимых сигнала. Каждый улавливает разные категории проблем — синтаксические ошибки, проблемы качества кода, несоответствия типов, логические сбои — которые другие могут пропустить. Раздел [Creative Builds](/code/docs/build-deploy) на странице Build & Deploy показывает примеры валидаторов, которые вы можете добавить: линтеры (eslint, ruff), проверщики типов (tsc), запуски тестов (dotnet test), сканеры безопасности (npm audit) и пользовательские валидаторы проекта. Каждый добавленный делает AutoFix более эффективным в поддержании правильности вашего кода. Чтобы настроить новые сборки, вам не нужно вручную редактировать файлы конфигурации. В `.pastukhov/README.md` задокументированы полные форматы `build.yml` и `build.parser` — просто попросите ИИ-модель добавить нужные сборки и обновить шаблоны парсера для вывода ваших инструментов. ## Ограничения AutoFix мощен, но у него есть некоторые ограничения: - **Последовательная обработка** — AutoFix обрабатывает одну сборку за раз. Он выбирает первую сборку с проблемами и отправляет все её ошибки или предупреждения перед переходом к следующей - **Ошибки перед предупреждениями** — AutoFix не будет отправлять предупреждения в ИИ, пока сначала не будут устранены все ошибки сборки - **Обнаружение дубликатов** — AutoFix проверяет последние 10 сообщений на идентичное содержание. Если те же ошибки продолжают появляться после неудачной попытки исправления, он не будет отправлять их повторно, предотвращая бесконечные циклы. Но это также означает, что устойчивые ошибки, которые модель не может исправить, в конечном итоге перестанут сообщаться - **Лимит concurrency** — AutoFix соблюдает лимит concurrency, чтобы не перегрузить систему одновременными сессиями исправления - **Ожидание простоя** — AutoFix обрабатывает только тогда, когда нет активной ИИ-сессии. Во время продолжающегося разговора опрос ошибок приостанавливается - **Не все ошибки исправимы** — Некоторые ошибки требуют вашего ввода, проектных решений или контекста, который можете предоставить только вы. Сложные архитектурные проблемы, ошибки, охватывающие несколько взаимосвязанных модулей, или проблемы, зависящие от решений бизнес-логики, могут превысить возможности AutoFix Когда AutoFix не может устранить ошибку, сессия чата остаётся в вашей истории. Вы можете открыть её, просмотреть, что пытался сделать ИИ, и предоставить дополнительные рекомендации, чтобы помочь ему добиться успеха при следующей попытке. ## Когда использовать AutoFix ### AutoFix хорошо работает для: - Рутинных ошибок сборки от недавних изменений кода - Проблем линтинга и простых синтаксических ошибок - Ошибок типов, имеющих чёткое решение - Распространённых ошибок конфигурации - Сбоев тестов с простыми исправлениями ### AutoFix может испытывать трудности с: - Ошибками, требующими решений бизнес-логики или ваших знаний предметной области - Сложными архитектурными изменениями, охватывающими несколько модулей - Ситуациями, когда “исправление” зависит от специфических требований вашего проекта - Ошибками от инструментов, вывод которых [парсер сборки](/code/docs/build-deploy) не распознаёт — в этом случае попросите ИИ добавить соответствующие шаблоны парсера **[← Аналитика](/code/docs/analytics)** **[Мобильная версия →](/code/docs/mobile)**