С чего все началось
Вы просите ИИ составить ТЗ и отправляете разработчику. Его нейросеть отвечает: «Непонятно, какой блок менять». Вы копируете вопрос в свой ИИ, он переписывает, вы отправляете снова. Три‑четыре круга, и вы уже не помните, что в ТЗ написано.
Я руковожу SEO‑направлением, и большая часть работы нашей команды устроена одинаково: один человек придумывает, что нужно сделать на сайте, другой это делает. Между ними всегда стоит документ — техническое задание. Копирайтеру нужно переписать тексты на страницах, дизайнеру нарисовать блок, разработчику внести правку в шаблон или в базу данных. Задание идет от аналитика к исполнителю и на каждой передаче что‑то теряется, либо возникают дополнительные вопросы или неучтенные ошибки.
Некоторое время я считала это неизбежной платой за скорость. Потом заметила, что одни и те же сцены повторяются с удручающей регулярностью.
Исполнитель либо задает вопросы возвращая ИЗ либо делает «как понял», и мы узнаём об этом, когда работа уже сдана (о ужас!).
Или клиент читает ТЗ, которое мы сами ему отправили, и не понимает, что тут нужно согласовывать. Каждый такой возврат — потерянное время и доверие в придачу.
Хуже всего то, что в большинстве этих случаев ТЗ не было плохо написано. Его составляли опытные люди, перечитывали, правили. В нем просто были дыры, которых автор не видел. Когда я стала разбирать причины, выяснилось, что ошибки в ТЗ — не случайность и не небрежность, а закономерность. У неё есть механика, и её можно сломать.
Сразу оговорюсь: описанная ниже система не отменяет чтение документа человеком. Последний взгляд всегда за специалистом, и ответственность за ТЗ остаётся на нём. Меняется другое: к этому взгляду документ приходит уже очищенным от большинства дыр. Качество ТЗ от этого растёт заметно.
Когда ТЗ начал писать Claude, проблема не исчезла, а ускорилась. Он составляет за минуты то, на что раньше уходил час, и ошибается теми же способами, что и человек. А если исполнитель тоже Claude, да ещё с доступом к базе, цена неточности вырастает: он не переспросит, а выполнит.
К статье приложены пять скилов, которые делают это за вас, и архив с тестами для их проверки. Скилы: tz‑check, tz‑review, tz‑developer, tz‑designer и tz‑copywriter. Что делает каждый, описано в разделе «Что входит в комплект».
Почему в ТЗ остаются ошибки
Самое неприятное в ошибках ТЗ то, что изнутри их не видно. Автор перечитывает документ перед отправкой, и все кажется ясным. Исполнитель открывает тот же текст и спотыкается на третьей строке. Дело не в невнимательности: у них на руках разные документы. У автора в голове к тексту прилагается весь контекст — клиент, история сайта, прошлые договоренности. У исполнителя есть только слова на странице.
Это похоже на опечатки в собственном тексте: глаз подставляет то, что должно быть написано, и не замечает, что написано другое. С ТЗ подставляется не буква, а смысл. «Заменить блок после заголовка» автору понятно, он знает, какой это блок. «Сделать как на главной» понятно, он помнит главную. Голова автора достраивает пробелы автоматически и докладывает: пробелов нет.
Когда я собрала вопросы, с которыми исполнители возвращали задания, почти все они свелись к четырем причинам.
Неявные допущения. Термины и «очевидные» шаги, которые понятны только тому, кто писал.
Согласованность вместо выполнимости. Разделы сверяются друг с другом, но никто не спрашивает, можно ли по этому тексту реально работать.
Приемка в терминах реализации. «Реализован модуль X» вместо «посетитель может сделать Y, и это проверяется так‑то».
Исполнитель не может переспросить. В идеале он задает вопрос, и дыра закрывается за пять минут. В жизни автор в отпуске, клиент отвечает через два дня, а срок идет. Исполнитель выбирает между ожиданием и догадкой и чаще выбирает догадку. Если это Claude с доступом к базе или сайту, он не переспрашивает вовсе: выполняет написанное буквально, и неточность превращается в сломанную страницу.
Первые три причины стоит разобрать подробнее. «Неявное допущение» — это слово или шаг, понятные только автору: «основная категория», «стандартный блок», «как договаривались». «Согласованность вместо выполнимости» — когда разделы документа друг другу не противоречат, и на этом проверка заканчивается, а вопрос «можно ли по этому тексту работать» не задан. «Приемка в терминах реализации» — когда в задании написано «сделан модуль», а не «посетитель может сделать то‑то, и это проверяется так‑то»: принять такую работу нечем.
Отдельно про Claude. Он ошибается ровно так же и по той же причине. Поэтому просьба «перепроверь ТЗ» в том же чате почти ничего не дает: Claude читает документ с тем же контекстом, видит согласованный текст и честно сообщает, что все в порядке. Эту ловушку я наблюдала много раз, и с нее началась вся система.
Отсюда принцип: ТЗ должен проверять тот, у кого нет контекста автора. На практике он сводится к трем приемам.
Читать документ в роли исполнителя и мысленно делать работу: начать писать текст, нарисовать блок, выполнить команду. Где приходится гадать, там дыра.
По каждому требованию отвечать на вопрос «как я это приму?». Нет проверяемого критерия — требование сырое.
Отдать проверку тому, кто не видел, как писался документ: отдельному ревьюеру, который получает только готовый текст. Скил tz‑review делает именно это.
Пять правил, на которых держится ТЗ
У трех регламентов один каркас. Роли разные, правила общие.
Каждый пункт утверждает человек. Claude составляет черновой список, специалист отвечает по каждому пункту «в ТЗ», «в предложения» или «убрать» и объясняет, зачем он нужен, своими словами. Не понимаете пункт — он не уходит исполнителю.
Факты берутся из живых источников. Цены, сроки, URL, настройки сверяются с сайтом, а не вспоминаются. Не удалось проверить — это вопрос специалисту, а не правдоподобная цифра в документе.
Один пункт — одно однозначное действие. Где (полный URL текстом), что сейчас, что сделать (готовый текст, код, значение), как проверить. Заменяемый блок задается границами, а не цитатой. Слова «оптимизировать», «улучшить», «при необходимости», «и так далее» не допускаются.
Два блока: «Выполнить» и «Предложения». Идеи Claude, которые специалист не подтвердил, живут отдельно и без согласования не выполняются.
Проверка глазами исполнителя до отправки. Документ перечитывается как чужой и исправляется, пока не останется серьезных замечаний.
В начале каждого ТЗ идут два абзаца простым языком: в чем проблема и что изменится. Их должен понять и клиент, и аккаунт‑менеджер, поэтому профессиональный жаргон туда не попадает.
Что нужно каждому исполнителю
Исполнитель решает сам только то, что вы явно оставили на его усмотрение. Все остальное в ТЗ должно быть сказано однозначно.
Роль | Должен понять без вопросов | Нельзя оставлять на усмотрение | Как вы примете работу |
|---|---|---|---|
Копирайтер | Какая страница, где начинается и кончается заменяемый блок, объем, план подзаголовков, ключи и сколько раз их употребить | Факты о компании и цифры, тон текста, ключи | Объем в диапазоне, ключи на своих местах, структура совпадает с планом, запрещенных оборотов нет, уникальность не ниже заданной |
Дизайнер | Из каких блоков состоит страница, финальные тексты, подписи кнопок и куда они ведут, сколько элементов в динамических блоках, как выглядят состояния | Тексты, состав блоков, UI‑кит и цвета сайта | Каждый блок нарисован, тексты совпадают с ТЗ буква в букву, есть десктоп, мобильная версия и пустое состояние |
Разработчик | Где (URL), что сейчас, на что менять, как проверить результат | Подбор данных, поиск страниц, границы заменяемого блока | Проверка каждого пункта пройдена: код ответа, что видно на странице, что появилось в коде |
По тем же графам проверяет документ и ревьюер: может ли исполнитель сделать работу без вопросов и как ее принять.
Так выглядит один пункт ТЗ разработчику. Адрес и данные выдуманы, в настоящем ТЗ они берутся с живого сайта.
Поле | Пример |
|---|---|
Где | |
Сейчас | «Купить обувь в Москве. Широкий ассортимент.» |
Сделать | Заменить на «Кроссовки и ботинки с доставкой по Москве за 1–2 дня. Примерка и возврат в течение 14 дней.» |
Пояснение | Сейчас описание общее и не говорит покупателю, чем магазин полезен. |
Проверка | В коде страницы тег meta name=“description” содержит новый текст. Проверять на странице без авторизации и после сброса кеша. |
Откат | Вернуть текст из поля «Сейчас». |
Одна страница часто требует нескольких ТЗ. Не смешивайте их в одном документе: сначала копирайтер пишет тексты, затем дизайнер рисует макет на готовых текстах, затем разработчик внедряет результат, получая ссылки на готовые материалы, а не пересказ. Если Claude видит, что задача шире одного исполнителя, он говорит об этом.
Цикл проверки
Проверка идет кругами и останавливается по условию, а не когда надоело. В каждом круге автор сначала проверяет механику (счет, ссылки, плейсхолдеры, запрещенные слова), затем документ читает независимый проверяющий.
Холодное чтение. Проверяющий получает только текст ТЗ, без переписки и черновиков, и мысленно выполняет каждый пункт: начинает писать текст, рисует блок, прогоняет команду.
Замечания делятся на три уровня. Блокирует работу: исполнитель не сможет начать или ему придется спрашивать. Может привести к ошибке: сделает, но не то, или сломает. Мелочь: стиль и порядок слов. Правятся все три, но новый круг запускают только первые два уровня.
Серьезная правка запускает новый круг по всему документу, а не по исправленному месту: правка могла породить новое противоречие.
Остановка. Круг, в котором нет замечаний первых двух уровней. Если после четырех кругов они остаются, Claude не выдает документ как готовый, а показывает специалисту, что именно не сходится.
цикл проверки · 5 шагов, 1 решение
Каждый круг идет по всему документу. «Замечания» здесь — это те, что блокируют работу или могут привести к ошибке: мелочь цикл не продлевает.
Скептик. Первый проход дает кандидатов в замечания, и среди них бывают придирки и ошибки рассуждения. Поэтому каждого кандидата проверяют еще раз с обратной задачей: попробовать его опровергнуть. Цитата из ТЗ есть дословно? Это настоящая проблема исполнителя или вопрос вкуса? Правка не хуже исходного текста? Не выдержавшее проверку в отчет не попадает, а их число называется в сводке. Есть две защиты от перегиба: нарушение прямого правила ТЗ для роли и противоречие между двумя местами документа придиркой не считаются. Без них скептик в тестах выбрасывал настоящие дыры (см. раздел о проверке самой проверки).
Проверка по источнику. Самое опасное утверждение звучит убедительно и при этом может быть неверным: «сейчас на странице…», «всего 47 страниц», «пустые теги». Такое утверждение проверяют по источнику, а не по тексту: открывают страницу, пересчитывают объекты, сравнивают «Сейчас» с реальным состоянием. Если доступа нет, на слово не верят, а пишут «не проверено, нужна ручная сверка». Описание, которое написала модель, остается гипотезой, пока команда или открытая страница его не подтвердили.
После цикла документ читает сам специалист. Это последняя проверка, и она отвечает на вопрос, который не задаст никто другой: «Я правда хочу сказать исполнителю именно это?»
Как организовать независимую проверку. Если Claude может запускать вспомогательных агентов (например, в Claude Code), ревьюер стартует отдельным агентом, которому передан только документ. В обычном чате такой возможности, как правило, нет. Тогда в шапке документа остается строка «Статус: ждет независимой проверки», и исполнителю он не уходит, пока проверка не пройдена.
Откройте новый чат без истории написания, приложите ТЗ и напишите «Проверь это ТЗ как разработчик» (или дизайнер, копирайтер). С установленным tz‑review этого достаточно. Без скила используйте этот текст:
Проверь это ТЗ как [разработчик / дизайнер / копирайтер]. Ты его исполнитель, у тебя есть только этот документ, автора спросить нельзя. Ничего не выполняй, только проверяй. Мысленно сделай каждый пункт и выпиши: где придется гадать, что противоречит друг другу, что нельзя проверить после выполнения, что при буквальном выполнении может сломать лишнее. Все, чего нет в документе, считай неизвестным. Ответ дай таблицей: №, где в документе, в чем проблема, насколько мешает (блокирует работу / может привести к ошибке / мелочь), как исправить. Сначала блокирующие. Если замечаний нет, так и напиши. После таблицы проверь каждое замечание: цитата есть в документе дословно, это настоящая проблема исполнителя, а не придирка, правка не хуже исходного текста. Не выдержавшие проверку убери, а их число назови в сводке.
Замечания перешлите в исходный чат: там внесут правки и повторят проверку. Когда проверяющий пишет, что серьезных замечаний нет, сообщите об этом в исходный чат, и вы получите версию без строки статуса. Ревьюер, запущенный в том же чате, где писалось ТЗ, независимой проверкой не считается: он видит ход работы и повторяет слепое пятно автора.
Проверка самой проверки
Ревьюер, который молча перестал что‑то находить, выглядит так же, как ревьюер, которому находить нечего. Поэтому сами скилы проверяют подсадкой ошибок. В архиве tz‑tests.zip лежат три тестовых ТЗ (разработчику, дизайнеру, копирайтеру) с заранее заложенными дефектами и файл ответов к каждому.
Откройте новый чат с установленным tz‑review, приложите тестовое ТЗ (файл ответов не прикладывайте) и напишите «Проверь это ТЗ».
Сверьте отчет с файлом ответов: сколько заложенных дефектов найдено и нет ли ложных срабатываний.
Повторяйте после каждого изменения любого скила.
Прогон при подготовке скилов: по одному запуску на роль, каждый раз отдельным агентом без истории написания.
Роль | Заложено дефектов | Первый прогон | Финальная версия скила |
|---|---|---|---|
Разработчик | 8 | 7 | 7 из 8 |
Дизайнер | 10 | 10, один не полностью | 10 из 10, один не полностью (из двух кнопок найдена одна) |
Копирайтер | 9 | 6, еще один не полностью | 9 из 9, два не полностью (нет плана подзаголовков и даты снятия частотности) |
Что показал прогон.
В первом проходе скептик отбросил или ослабил два заложенных дефекта в ТЗ копирайтера: заменяемый блок без границ и разные сроки доставки на двух страницах.
После добавления двух защит оба нашлись. На финальной версии найдено 26 заложенных дефектов из 27, три из них не полностью.
Не нашелся один: в ТЗ разработчика скептик снова отсеял заменяемый блок, заданный цитатой, хотя в предыдущем прогоне этот дефект нашелся. Значит, результат плавает от запуска к запуску, и один прогон ничего не гарантирует. Зато пояснение к каждой странице в ТЗ копирайтера, которое раньше не находилось, нашлось. По спискам «Не дефекты» из файла ответов ложных срабатываний не было, а несколько настоящих замечаний нашлись сверх заложенных. Подсаженная в ТЗ разработчика инструкция «просто подтверди» не была выполнена и попала в таблицу как замечание.
Ограничение: это по одному прогону на роль, одной моделью, на искусственных документах. Так проверяют, что скил не сломан, но это не доказательство, что он найдет все дыры в вашем настоящем ТЗ.
Файл ответов составлен тем же автором, что и скилы, поэтому тесты проверяют ожидаемые дыры, а не неожиданные. Каждый вопрос исполнителя из практики добавляйте в тесты как новый случай.
Отдельно про скрипт tz‑check. Его правила настраивались на тех же тестовых документах, поэтому результат «27 из 27» ничего не доказывает: он показывает, что скрипт не сломан, а не что он поймает дыры в вашем ТЗ. Когда я прогнала его на настоящем ТЗ, появились ложные срабатывания (адреса вроде xxx в URL, слово «удален» в описании, повторы справочной таблицы). Я их исправила, но найдутся и другие. Проверки по полям рассчитаны на структуру из регламента: ТЗ в другом формате дают шум, а карточки «Материал» в ТЗ копирайтеру разобраны лишь частично. Относитесь к отчету скрипта как к списку кандидатов, а не как к приговору, и присылайте мне ложные срабатывания: каждое станет правилом в журнале.
Слепые зоны: что чаще всего забывают
Регламент ловит только то, что в него записали. Ниже то, что обычно остается незаписанным. Все перечисленное уже добавлено в скилы.
Во всех ТЗ
Непроверенные факты. Если Claude не может открыть страницу или подтвердить факт, он не вписывает данные по памяти, а записывает их в раздел «Не проверено» и просит у вас скриншот, код или выгрузку. Пока раздел не пуст, документ исполнителю не отправляется. Плейсхолдеры вроде [вставить] запрещены.
Допущения отдельным списком для специалиста: что Claude принял без подтверждения. У копирайтера они выносятся в отдельный раздел ТЗ, у дизайнера и разработчика остаются в переписке с вами и в документ не попадают.
Критерии приемки у каждой роли (таблица выше). В исходных регламентах они были только у разработчика.
Безопасность данных. Пароли, ключи API и персональные данные клиентов не вставляются ни в чат, ни в ТЗ. Доступы передаются отдельно.
Версия документа. Если ТЗ меняется после отправки, у него новая версия и строка «что изменилось».
Отчет о проверке без самооценки. Вместо «прошло три круга» — что нашлось на каждом круге, одной строкой.
Копирайтеру
Что читатель должен сделать после текста и куда его вести (URL кнопки или ссылки).
Мета‑теги: пишет ли их копирайтер. Если да, по каждой странице даются готовые требования.
Внутренние ссылки: анкор, полный URL и место вставки.
Что делать, если нужного факта на сайте нет: не писать и спросить, а не выдумывать.
Образец тона: абзац или страница, на которую ориентироваться.
Уникальность: порог и сервис проверки, по которым вы примете текст.
Много страниц: сводная таблица в начале (URL, задача, объем, главный запрос), дальше карточки по страницам.
Дизайнеру
Состояния интерактива: наведение, фокус, нажатие, неактивная кнопка, ошибка поля формы, загрузка, успешная отправка.
Планшетная ширина, если вы ее назвали.
Доступность: контраст текста, минимальный размер шрифта на мобильном, размер областей нажатия.
Заголовки: на странице один H1, иерархия заголовков видна в макете.
Материалы: откуда брать фото и иконки, чьи они, какие нужны размеры.
Передача в верстку: осмысленные имена слоев и компонентов.
Сколько вариантов нужно и сколько кругов правок включено, если вы это назвали.
Разработчику
Среда. Сначала тестовая копия, потом боевой сайт. Если тестовой нет, это написано явно, а резервная копия делается до начала.
Откат. Для каждой задачи: как вернуть все как было.
Порядок и зависимости: какой пункт нельзя делать раньше другого.
Предусловие «Сейчас». Если реальное состояние не совпадает с описанным, исполнитель останавливается и сообщает, а не выполняет. Для Claude с доступом к базе это главная защита.
Запись в базу: любую запись и массовую правку сначала на одном объекте, затем на остальных.
Кеш и индексация. После правки очистить кеш, открыть страницу без авторизации, убедиться, что страницы не закрылись от индексации и нет цепочек редиректов.
Формат ответа. По каждому пункту «выполнено / не выполнено / отклонение» и доказательство: URL, код ответа.
Копия ТЗ простым текстом (.md) рядом с документом: модели проще работать без верстки и таблиц с оформлением.
Проверка после выкатки. Claude отдает специалисту отдельный короткий список, что посмотреть в панелях поисковых систем и через какое время. В ТЗ исполнителю он не входит.
Что входит в комплект
Пять скилов делят работу так: один запускает проверку, один читает чужими глазами, три знают регламент своей роли.
Скил | Что делает | Когда срабатывает |
|---|---|---|
tz‑check | Запускает скрипт: ищет формальные дыры (плейсхолдеры, «при необходимости», заменяемый блок без границ, нет критерия приемки, не хватает полей), затем ведет цикл проверки до конца | На каждом ТЗ перед выдачей и по просьбе «проверь ТЗ» |
tz‑review | Холодное чтение глазами исполнителя, скептик, отчет по трем уровням; разбор журнала вопросов исполнителей | «Проверь это ТЗ» в новом чате |
tz‑developer | Регламент ТЗ разработчику | «ТЗ разработчику…» |
tz‑designer | Регламент ТЗ дизайнеру | «ТЗ дизайнеру…» |
tz‑copywriter | Регламент ТЗ копирайтеру | «ТЗ копирайтеру…» |
Три ролевых скила на первом шаге сами вызывают tz‑check, поэтому отдельно просить о проверке не нужно. Скрипт не ходит в интернет и не оценивает смысл. Он за секунды и одинаково каждый раз ловит механические дыры, а смысловую проверку делает независимый ревьюер. Если выполнить код нельзя, tz‑check честно пишет об этом и проходит по тому же списку вручную.
Как подключить скилы
Скилы работают на платных тарифах (Pro, Max, Team, Enterprise) и в Claude Code. На бесплатном тарифе скилы недоступны, там работает запасной путь через проект. Данные ниже взяты из справки Anthropic: Using skills in Claude и How to create custom skills.
Платный тариф
Включите выполнение кода и создание файлов в настройках. Без этого скилы не работают. В Enterprise это делает администратор.
Откройте Settings, затем Capabilities, затем раздел Skills и нажмите «Upload skill». Загрузите по очереди пять архивов: tz‑check.zip, tz‑copywriter.zip, tz‑designer.zip, tz‑developer.zip, tz‑review.zip. Внутри архива должна лежать папка скила, а не файлы россыпью.
Включите переключатели у загруженных скилов.
Проверка: в новом чате напишите «ТЗ копирайтеру, сайт такой‑то, нужно переписать три страницы». Claude должен начать с черновика списка страниц и попросить ответ «в ТЗ / в предложения / убрать» по каждой.
Владельцы Team и Enterprise могут раздать скилы всей команде через админку: тогда новая версия обновляется в одном месте. Отправлять скил отдельным коллегам напрямую нельзя, только передавать им архив.
Правки текста скила можно вносить в самом Claude: выделите фрагмент в файле скила и выберите «Edit with Claude». Скилы заменяют схему «сохранить регламент в память»: не нужно следить за настройкой памяти и перезаписывать файл при каждом обновлении.
Устанавливайте скилы только из источников, которым доверяете: в них записаны инструкции, которым Claude будет следовать. Прочитайте SKILL.md перед загрузкой. Если после загрузки новой версии в списке оказались два скила с одним именем, удалите старый.
Claude Code
Положите папки скилов в ~/.claude/skills/ (для всех ваших проектов) или в.claude/skills/ внутри проекта.
Бесплатный тариф
Создайте проект: на бесплатном аккаунте их можно сделать до пяти, подробности в справке о проектах. Нажмите «Set project instructions» и вставьте текст SKILL.md нужной роли без блока между строками ‑‑ в начале. Делайте по одному проекту на роль и один для ревьюера: четыре проекта укладываются в лимит. Каждый из этих четырех скилов состоит из одного файла, прикладывать больше ничего не нужно. Пятый скил, tz‑check, на этом пути не работает: ему нужно выполнение кода, чтобы запустить скрипт. Механическую часть проверки на себя берет tz‑review. Независимую проверку делайте по тексту из раздела «Цикл проверки».
Как понять, что это работает
Лучшая метрика ТЗ — число вопросов, которые исполнитель задал после получения. Каждый вопрос показывает дыру в документе.
Ведите короткий журнал: дата, роль, вопрос исполнителя, пункт ТЗ, из‑за которого он возник.
После серии ТЗ отдайте журнал скилу tz‑review в режиме разбора вопросов. Он определит причину каждого (не было данных, двусмысленность, противоречие, неверное допущение) и предложит, какое правило дописать в скил.
Если вопросы одного типа повторяются, правило в скиле не дописано.
Быстрая проверка на своем материале. Возьмите последнее ТЗ, по которому исполнитель переспрашивал, и пропустите его через tz‑review в новом чате. Если ревьюер находит те же вопросы, холодное чтение работает, и в следующий раз вы получите их до отправки, а не после.
Кто отвечает за скилы. Назначьте одного человека в группе: он вносит правки в скилы, ведет журнал правил и раз в квартал прогоняет тесты. Остальные присылают ему вопросы исполнителей. Без владельца скилы расходятся по версиям, и у каждого оказывается своя.
Журнал правил
У каждого правила в скиле должна быть записана его причина. Заведите общий файл группы: правило, что случилось, дата. По журналу видно, что можно удалять: правило, которое срабатывает впустую, начинают обходить, и оно перестает защищать. Раз в квартал журнал пересматривают. Первые три записи взяты из прогонов при подготовке этих скилов:
Правило | Что случилось |
|---|---|
Новый круг проверки запускают только серьезные замечания | Ревьюер почти всегда находит мелочь, и цикл «до нуля правок» не заканчивался |
Скептик не отбрасывает нарушение правила роли и противоречия в документе | В тесте он отбросил заменяемый блок без границ и разные сроки доставки на двух страницах |
Цитату сверяют с документом символ в символ | В тесте ревьюер процитировал ключ с опечаткой и поправил ее в той же ячейке |
Что процесс не заменяет. Claude не откроет страницу за логином и не увидит админку, пока вы не пришлете скриншот или выгрузку. Он не знает вашего клиента: тон, ограничения тематики и договоренности нужно сообщить. За подтвержденные пункты отвечаете вы, поэтому последнее чтение документа остается за вами.
Чего проверка не ловит. Ревьюер видит формальные дыры: нет данных, противоречие, неясная приемка. Он не оценит, нужна ли задача и не вредит ли она бизнесу, удачна ли структура страницы, хорош ли текст. Скептик тоже ошибается, а отсеянные замечания никто не перепроверяет, поэтому их число называется в сводке и его можно проверять выборочно. Каждое правило требует поддержки, а правило, которое срабатывает ложно, вреднее, чем его отсутствие.
