Проверка ТЗ AI трассировочная матрица для новичка 2026

Вы написали ТЗ, 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-инструментам:

Статусов достаточно четыре: выполнено, частично, не выполнено и добавлено лишнее. Последний статус люди чаще всего забывают завести, а именно он ловит ту самую отсебятину, из-за которой потом непонятно откуда в проекте взялась функция.

Какие статусы использовать и что с ними делать дальше?

После заполнения таблицы статус подсказывает следующий шаг: не нужно гадать, что делать с каждой строкой отдельно.

Как написать промпт для агента-ревьюера который проверяет другого агента?

Второй агент без контекста первого не жалеет фичи и не приукрашивает результат. Ему дают ТЗ и результат работы, и он просто сверяет одно с другим, без творчества.

Идея простая: один 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 генерирует что-то по конкретному брифу: код фичи, лендинг, текст статьи, промпт для другого агента. Не подходит для полностью творческих задач без исходного ТЗ, там просто нечего трассировать.

Максим: «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.