Вы написали ТЗ, AI отчитался «готово», а по факту половина пунктов пропущена, зато появилась кнопка, которую никто не заказывал. Знакомая ситуация для любого вайбкодера. Трассировочная матрица решает эту проблему: это таблица, в которой каждый пункт ТЗ сверяется с тем, что реально появилось в проекте. Ниже разберем упрощенную версию метода для новичков, готовый промпт для агента-ревьюера и разбор реального кейса проверки AI-кода.
В статье: что такое трассировочная матрица простыми словами, как собрать ее за 10 минут без Excel-курсов, готовый промпт для агента который проверяет другого агента, и разбор частых ошибок новичков.
Что такое трассировочная матрица простыми словами?
Трассировочная матрица - это таблица, где каждому пункту ТЗ соответствует то, что реально сделал AI, и статус выполнения. Один взгляд на таблицу - и видно, что пропущено.
Трассировочная матрица (Requirements Traceability Matrix, RTM) - это документ, который связывает три вещи: что вы просили, что должно было получиться и что получилось на самом деле. В QA ее используют десятилетиями для проверки, что каждое требование реально протестировано, а не потерялось где-то между брифом и релизом.
Для вайбкодинга полную QA-версию RTM тащить не нужно. Там есть forward traceability, backward traceability, привязка к WBS и с десяток колонок, которые нужны только большим командам с аудитом и регуляторами. Новичку хватает пяти колонок: номер требования, само требование, что сделал AI, статус и короткий комментарий. Смысл метода не в бюрократии, а в одном простом вопросе к каждому пункту ТЗ: это правда есть в проекте или нет.
Почему AI сделал не то что вы просили?
AI не врет специально. Модель достраивает пробелы в ТЗ своими предположениями, и часто эти предположения не совпадают с тем, что вы держали в голове, но не написали словами.
Языковая модель отвечает на запрос целиком, а не построчно по пунктам. Если в ТЗ пять требований и три из них расписаны подробно, а два - одной фразой, модель добавит к скудным пунктам собственную трактовку. Иногда трактовка удачная, иногда нет. Отдельная проблема - скоуп-крип наоборот: AI не убирает лишнее, а добавляет "для полноты" функции, о которых вы не просили.
В обзоре ревью AI-кода из практики разработчика, который признает, что генерирует AI-кодом свыше 90% строк, есть конкретная деталь: даже подробный контекст в файле для агента не спасает от того, что модель может пропустить вопросы безопасности, например открытый публичный доступ к файлам, которые должны быть закрыты. Разработчик замечает это не потому, что AI плохой, а потому что сам целенаправленно ищет такие вещи при ревью. Без сверки по пунктам ТЗ это легко пропустить.
Как сделать упрощенную трассировочную матрицу для проверки AI?
Берете ТЗ, нумеруете каждый пункт, и для каждого номера фиксируете три вещи: что должно быть, что есть по факту, статус. Пять минут работы экономят часы на подкрутке в проде.
Разбейте ТЗ на атомарные требования. Не "сделай личный кабинет", а отдельно: "форма логина", "смена пароля", "просмотр истории заказов". Каждому пункту присвойте короткий ID, например ЛК-01, ЛК-02. Дальше AI генерирует код или отвечает на задачу, а вы построчно сверяете результат с этой нумерацией.
Вот минимальный шаблон, который реально работает без Excel и без обучения QA-инструментам:
| ID | Требование из ТЗ | Что сделал AI | Статус | Комментарий |
|---|---|---|---|---|
| 01 | Форма логина по email и паролю | Форма есть, работает | Выполнено | - |
| 02 | Восстановление пароля по ссылке | Кнопка есть, письмо не отправляется | Частично | Нет интеграции с почтой |
| 03 | Rate limiting на попытки входа | Не найдено в коде | Не выполнено | Нужно доуточнить в промпте |
| 04 | Двухфакторная аутентификация | Появилась в интерфейсе | Добавлено лишнее | Не просили, уточнить зачем |
Статусов достаточно четыре: выполнено, частично, не выполнено и добавлено лишнее. Последний статус люди чаще всего забывают завести, а именно он ловит ту самую отсебятину, из-за которой потом непонятно откуда в проекте взялась функция.
Какие статусы использовать и что с ними делать дальше?
После заполнения таблицы статус подсказывает следующий шаг: не нужно гадать, что делать с каждой строкой отдельно.
| Статус | Что означает | Следующий шаг |
|---|---|---|
| Выполнено | Совпадает с ТЗ | Ничего не делать |
| Частично | Есть, но не полностью | Уточняющий промпт с конкретной деталью |
| Не выполнено | Отсутствует | Повторить требование явно, отдельным промптом |
| Добавлено лишнее | Не было в ТЗ | Спросить у AI зачем, решить: оставить или удалить |
Как написать промпт для агента-ревьюера который проверяет другого агента?
Второй агент без контекста первого не жалеет фичи и не приукрашивает результат. Ему дают ТЗ и результат работы, и он просто сверяет одно с другим, без творчества.
Идея простая: один AI пишет код или текст, второй его проверяет. У ревьюера нет эмоциональной привязанности к своему же коду, поэтому он честнее находит расхождения. Ниже рабочий промпт, который можно вставлять как есть.
Ты - агент-ревьюер. Твоя единственная задача - сверить результат работы
другого агента с исходным ТЗ. Ничего не переписывай и не улучшай.
Вот ТЗ по пунктам:
[вставить пронумерованные требования]
Вот что сделал агент:
[вставить код, диф, PR или текстовый ответ]
Для каждого пункта ТЗ верни строку трассировочной матрицы:
| ID | Требование | Статус (Выполнено/Частично/Не выполнено/Добавлено лишнее) | Комментарий одним предложением |
В конце отдельно перечисли:
1. Что агент добавил сверх ТЗ без запроса.
2. Какие пункты остались без изменений в коде или тексте.
3. Один главный риск, если это отправить в прод как есть.
Не хвали и не критикуй общими словами. Только факты и статус.Что делает: превращает свободный ответ агента в структурированную таблицу без вашего ручного труда. Когда использовать: после каждой значимой фичи или PR от основного агента, до того как показывать результат заказчику или пользователям. Почему работает: ревьюер получает только ТЗ и результат, у него нет истории переписки с первым агентом и его "логики", поэтому он не достраивает оправдания задним числом.
Лайфхак: для роли ревьюера не нужна самая дорогая модель. Задача чисто сверочная, а не творческая, поэтому подойдет бюджетная модель вроде Claude Haiku 4.5 по цене 1 доллар за миллион входных токенов, она держит лучший показатель цены за качество среди моделей своего класса. Дорогую модель тратьте на генерацию, дешевую - на проверку.
Как это работает на практике на реальном кейсе?
В разборе ревью AI-кода на примере ATS-системы автор находит расхождения не через магию, а через методичный проход по фронтенду, API, бэкенду и авторизации отдельно.
Показательный кейс: разработчик собрал ATS-систему (Applicant Tracking System) почти полностью через AI. Функция включала список вакансий, форму отклика, загрузку резюме в PDF и админку для просмотра кандидатов. Вместо того чтобы просто пролистать pull request и нажать "approve", он прошел код по слоям: сначала фронтенд, затем API, затем бэкенд, отдельно - аутентификацию.
На каждом слое находились расхождения с изначальной идеей: где-то была лишняя публичность файлов, где-то отсутствовала проверка прав администратора. По описанию рабочего процесса у Anthropic для их встроенного ревью-агента в Claude Code, похожий принцип используется уже на уровне продукта: система дробит проверку на несколько специализированных агентов, каждый ищет свой класс проблем - логические ошибки, граничные случаи, работу с правами доступа, и только потом сводит находки в один список с оценкой серьезности.
Разница с трассировочной матрицей новичка только в масштабе. У Anthropic это несколько параллельных агентов на каждый pull request с проверкой около 20 минут на одну проверку. У вайбкодера-новичка это одна таблица на пять требований и один промпт агенту-ревьюеру. Принцип один и тот же: не доверять целиком, сверять по частям.
Какие ошибки чаще всего допускают новички при проверке ТЗ?
Самая частая ошибка - смотреть на результат целиком и оценивать "похоже, работает", вместо того чтобы пройти каждый пункт ТЗ отдельно.
Три повторяющихся паттерна ломают проверку еще до того, как она началась. Разберем каждый.
Первая ошибка: слишком общее ТЗ. Если пункт звучит как "сделай удобную корзину", проверить его нечем, там нет атомарных требований. Разбивайте на конкретику: лимит товаров, расчет скидки, поведение при нуле товаров.
Вторая ошибка: доверие красивому описанию PR. AI умеет писать подробные и убедительные описания изменений, но подробность описания не равна точности реализации. Сверяйте код, а не текст о коде.
Третья ошибка: игнорирование статуса "добавлено лишнее". Новички радуются, когда AI сделал больше, чем просили, и не проверяют зачем. А там и живет скоуп-крип, который потом aукается лишними полями в базе, неиспользуемым кодом и лишними точками для багов.
Сильные и слабые стороны метода трассировочной матрицы
Метод дешево ловит расхождения на раннем этапе, но не заменяет ручное тестирование сложной логики и требует дисциплины вести таблицу каждый раз, а не время от времени.
Сильная сторона - скорость. Пять строк таблицы занимают меньше времени, чем повторный полный обзор фичи глазами. Вторая сильная сторона - она снимает эффект "туннельного зрения", когда смотришь на весь результат целиком и не замечаешь, что один пункт вообще пропущен. Третья - метод одинаково работает и для кода, и для текста, и для промптов: суть всегда одна, пункт против пункта.
Слабая сторона - таблица не проверяет качество реализации внутри пункта. Статус "выполнено" не значит "без багов", он значит только "требование присутствует". Вторая слабая сторона - метод требует, чтобы ТЗ изначально было разбито на атомарные пункты, а если бриф написан одним абзацем, придется сначала переформулировать его самому. Честно: без этой подготовительной работы трассировочная матрица превращается в формальность для галочки.
Кому подходит трассировочная матрица и когда ее использовать?
Метод подходит там, где AI генерирует что-то по конкретному брифу: код фичи, лендинг, текст статьи, промпт для другого агента. Не подходит для полностью творческих задач без исходного ТЗ, там просто нечего трассировать.
| Сценарий | Нужна трассировочная матрица | Комментарий |
|---|---|---|
| AI пишет фичу по ТЗ | Да | Базовый случай применения |
| AI генерирует SEO-текст по брифу | Да | Проверить каждый обязательный блок |
| AI переписывает существующий код без нового ТЗ | Частично | Сначала зафиксировать, что нельзя менять |
| Свободный брейншторм идей | Нет | Нечего сверять, задачи нет изначально |
Максим: «GoBanana собрали за 3 часа после выхода новой модели. Уже эти 3 часа работы принесли 12 миллионов рублей выручки без рубля на рекламу. Каждый раз, когда AI генерирует фичу, я сверяю результат с тем, что просил в ТЗ. Не потому что не доверяю модели, а потому что она иногда додумывает то, о чем ее не спрашивали.»
Для полноценных QA-команд с аудитом, банковскими или медицинскими регуляциями упрощенная версия не подойдет: там нужна полная RTM с привязкой к тест-кейсам, дефектам и WBS. Для вайбкодера, который выпускает фичи каждую неделю, пяти колонок достаточно с запасом.
Глоссарий
- ТЗ. Техническое задание, список того, что должно получиться в проекте.
- Трассировочная матрица (RTM). Таблица, которая связывает требования с результатом и статусом их выполнения.
- Требование. Один атомарный пункт ТЗ, который можно проверить отдельно от других.
- Агент-ревьюер. Отдельный AI-запуск, задача которого - только сверка результата с ТЗ, без генерации нового кода.
- Скоуп-крип. Разрастание проекта функциями, которые изначально не заказывали.
- Pull request (PR). Запрос на слияние изменений кода, где виден весь диф перед тем как его принять в проект.
- Отсебятина. Разговорное - то, что AI добавил от себя, без явного запроса в ТЗ.
Частые вопросы
Нужен ли Excel для трассировочной матрицы?
Нет. Обычной markdown-таблицы в текстовом файле или прямо в чате с AI достаточно. Excel нужен только большим QA-командам с десятками требований и привязкой к тест-кейсам.
Сколько времени занимает проверка по трассировочной матрице?
Для фичи из 5-7 требований - около 10-15 минут на первую сверку. С опытом время сокращается, потому что появляется привычка сразу нумеровать пункты ТЗ.
Можно ли доверить всю проверку агенту-ревьюеру без своего участия?
Можно для рутинных фичей, но финальную строку про главный риск стоит читать самому перед деплоем. Агент хорошо ловит расхождения с ТЗ, но не всегда понимает бизнес-контекст, почему конкретный риск критичен именно для вашего продукта.
Чем трассировочная матрица отличается от обычного код-ревью?
Код-ревью смотрит на качество кода: чистоту, паттерны, потенциальные баги. Трассировочная матрица смотрит только на соответствие ТЗ: сделано или нет. Это разные вопросы, и лучше проверять оба отдельно.
Что делать если AI постоянно добавляет лишние функции?
Уточните в системном промпте или CLAUDE.md явное правило: реализовывать строго по списку требований, а о дополнительных идеях сообщать текстом, не кодом. Это снижает количество строк со статусом "добавлено лишнее".
Подходит ли метод для проверки не только кода, но и текстов?
Да. Для SEO-статьи атомарные требования - это, например, наличие FAQ, таблицы, цитаты, ключевых слов в H2. Принцип сверки тот же самый.
Нужно ли вести трассировочную матрицу для каждой мелкой правки?
Нет, для мелких правок это избыточно. Метод оправдан для фичей, PR или текстов, где больше трех-четырех требований одновременно.
Собрать привычку проверять AI по трассировочной матрице проще всего внутри агентной среды, где можно сразу прогнать промпт ревьюера на диф. В каталоге AI-инструментов VibeCoderz собраны обзоры Claude Code, Cursor и GitHub Copilot с честными плюсами и минусами именно для таких рабочих процессов. Если нужен готовый агент под конкретную профессию или задачу, загляните в каталог AI-агентов VibeCoderz - там 297 ниш и штука пригодится не только для проверки кода.
Если нужна помощь выстроить процесс проверки AI под ваш проект, напишите Максиму напрямую: t.me/maxnagovitsyn.
Обновлено: июль 2026.