Как проверить спецификацию, написанную ИИ:чек-лист до начала работы агента.
ИИ-агент за минуту пишет уверенную, аккуратную спецификацию. В этом и опасность: она хорошо читается, даже когда ошибочна. Этот чек-лист показывает, на что смотреть, прежде чем сказать агенту начинать.
macOS 14 или новее. Чтение бесплатно; редактирование и ревью оплачиваются один раз.
Коротко
Проверяйте спецификацию, написанную ИИ, так же, как pull request: убедитесь, что она решает ту проблему, затем ищите, чего не хватает. Пройдите по объёму и не-целям, пограничным случаям, данным и миграциям, тестам и откату и оставьте комментарий к каждому месту, которое хотите изменить, до того как агент напишет код.
- [ ] Scope matches what I asked for
- [ ] Non-goals are listed
- [ ] Edge cases and errors are covered
- [ ] Data and migrations are explicit
- [ ] Tests prove each requirement
- [ ] There is a rollback
·
Почему спецификациям от ИИ нужна другая проверка
Человек, пишущий спецификацию, обычно оставляет пробелы там, где не уверен. Модель пишет гладкий текст обо всём, включая то, что она угадала. Поэтому привычных признаков слабой спецификации, расплывчатых формулировок и очевидных дыр, нет, а проблемы спрятаны в уверенных предложениях. Проверяйте то, о чём спросил бы хороший автор.
Чек-лист
-
Объём: решает ли она то, о чём вы просили?
Сравните первый абзац со своим запросом. Ищите решение другой задачи и функции, о которых никто не просил.
-
Не-цели: чего она делать не будет?
У спецификации без не-целей нет границ. Добавьте лишнее, чего вы не хотите.
-
Допущения: что она угадала?
Ищите «предположительно», «вероятно» и всё, что подано как факт о коде или данных, которых она могла не читать. Попросите указать файлы.
-
Пограничные случаи: что будет, если что-то пойдёт не так?
Пустой ввод, очень большой ввод, нет прав, нет сети, два пользователя одновременно, то же действие дважды.
-
Данные: что сохраняется, меняется или удаляется?
Поля, форматы, кто может их читать и что будет с существующими записями.
-
Миграции: как переносятся старые данные?
Изменению схемы нужны порядок шагов, план на случай сбоя на полпути и возможность безопасно запустить его дважды.
-
Интерфейсы: что ещё затрагивается?
API, экраны, задачи, чужой код. Всё, что спецификация меняет, но не перечисляет, потом станет сюрпризом.
-
Безопасность и приватность: кто что может делать?
Новые права, новые данные, уходящие из системы, секреты в логах.
-
Тесты: как вы узнаете, что это работает?
Каждому требованию должна соответствовать проверка. Если требование нельзя протестировать, перепишите его.
-
Выкатка и откат: как это отменить?
Флаг, поэтапный выпуск, путь назад. «Исправим вперёд» — не план.
-
Открытые вопросы: кто их решает?
Честная спецификация перечисляет, чего не знает. Если вопросов нет, будьте подозрительны.
Комментарий, который работает
Расплывчатая обратная связь даёт расплывчатую переделку. Хороший комментарий ревью указывает на одно место, говорит, что не так и что вы хотите вместо этого:
> The export runs when the user taps Export.
Missing: what happens with a 2 GB file? Add a limit (R4) and an
error message, and say whether the export can be cancelled.
Храните комментарии отдельно от текста спецификации, чтобы файл оставался чистым, и собирайте их пакетом: сначала прочитайте всю спецификацию, потом комментируйте, чтобы агент переписал её один раз, а не десять.
Цикл ревью
-
Сначала прочитайте от начала до конца
Прежде чем комментировать, убедитесь, что понимаете весь план.
-
Комментируйте точные места
Одна проблема — один комментарий.
-
Пусть агент исправит
Он исправляет каждый комментарий и выдаёт новую версию.
-
Смотрите, что изменилось, а не весь документ
Читайте различия. Исправление может сломать то, что было в порядке.
-
Одобряйте, только когда чек-лист чист
Тогда пусть строит, опираясь на пронумерованные требования.
Тот же чек-лист работает, когда один агент проверяет спецификацию другого. Попросите ревьюера отвечать на каждый пункт цитатой из спецификации.
Как это сделать в DotMD
Всё это можно сделать прямо на странице. В DotMD вы выделяете место и пишете к нему комментарий; комментарии хранятся в DotMD, а не в файле. Агент их исправляет и присылает документ снова, а просмотр изменений показывает старый текст красным и новый зелёным, чтобы вы принимали их по одному. Настройка описана в статье ревью ИИ-спецификаций. Чтение бесплатно; о ревью см. цены.
Частые ошибки
- Проверка стиля, а не сути. Аккуратная спецификация всё равно может быть неверной.
- Одобрение за объём. Длина — не охват.
- Пропуск не-целей и отката, двух разделов, которые модели чаще всего пишут скупо.
- Правка кода вместо спецификации. Если план неверен, сначала исправьте его.
- Нет второго взгляда. После правок агента проверьте diff.
Вопросы о проверке спецификаций, написанных ИИ
Как проверить спецификацию, написанную ИИ?
Убедитесь, что она решает ту проблему, затем ищите, чего не хватает: не-целей, пограничных случаев, данных и миграций, тестов и отката. Прокомментируйте каждое место и пусть агент исправит текст до того, как напишет код.
Что должен включать чек-лист ревью спецификации?
Объём, не-цели, допущения, пограничные случаи, данные, миграции, интерфейсы, безопасность, тесты, выкатку и откат, открытые вопросы.
Может ли один ИИ-агент проверять спецификацию другого?
Да. Дайте ревьюеру чек-лист и попросите отвечать на каждый пункт цитатой из спецификации. Что принимать, решаете всё равно вы.
Почему бы просто не читать код?
К тому времени решения уже приняты, и менять их дорого. Неверное допущение дешевле всего исправить в спецификации.