Агент пишет требования и протоколы уверенно, и догадки в них выглядят как факты. Выход: требовать к каждому пункту пруф, то есть ссылку на источник, предположения модели и статус «факт или не факт», а источники подключать через MCP, лучше всего из Git. Минорные правки по этим пометкам агент делает сам, мажорные решает человек. Основа подхода описана в статье MCP для ИИ-агента.
Что требовать от агента
Агент пересказывает записи встреч и документы гладко, и по тексту не видно, где факт, а где догадка. Так получается из-за устройства модели: она достраивает правдоподобное продолжение, и пробел в данных заполняется звучащей фразой. Поэтому к каждому пункту требований и протоколов нужны три вещи: пруф (ссылка на источник с цитатой), предположение (что агент додумал сам) и статус (факт, не факт или вопрос к человеку).
На картинке три вида пометок над одним и тем же пунктом. Источник отвечает на вопрос «откуда это взято»: ссылка на файл или цитата из записи встречи со временем. Предположение отвечает на вопрос «что здесь додумала модель»: например, в записи сказано «платим картой», про валюту ни слова, а агент написал «в рублях». Такая догадка должна стоять отдельной строкой, отдельно от фактов. Статус отвечает на вопрос «можно ли на это опираться»: «факт», если пруф есть, «не факт», если пруфа нет, и «вопрос», если решать должен человек.
| Без пометок | С пометками | |
|---|---|---|
| Пункт | «Оплата картой в рублях» | «Оплата картой» |
| Источник | не указан | встреча 12.10, 14:32, «клиент платит картой при заказе» |
| Предположение | спрятано в тексте: «в рублях» | отдельной строкой: «оплата только в рублях» |
| Статус | читается как факт | не факт: про валюту на встрече не говорили |
| Что делает читатель | верит на слово | проверяет предположение или задаёт вопрос |
Правило простое: нет источника — статус «не факт». Так пункт без пруфа не превращается незаметно в требование. Человек видит такие пункты списком и решает, что с ними делать: найти источник, подтвердить на встрече или убрать. Пометки ускоряют проверку: цитата со временем проверяется за секунды, а строка с предположением показывает, где искать ошибку. Откуда брать источники, описано в следующей главе, а что делать, когда пункт меняется, дальше.
Источники через MCP: лучше всего Git
Пометка «источник» работает, только если агент берёт факты из настоящих систем, а не вспоминает их. Для этого агента подключают к системам через MCP: он сам открывает файл, запись встречи или страницу и цитирует нужное место. Но источники надёжны по-разному. Лучше всего подходит Git: требования лежат файлами рядом с кодом, у каждой правки есть автор, дата и причина, а прежние версии видны в истории. Confluence годится только если страницы вылизаны: у каждой есть владелец и дата проверки, а устаревшие убраны в архив. Иначе агент прочитает старую страницу как факт и выдаст галлюцинацию, хотя модель ничего не придумывала сама. Отдельный источник — протоколы встреч: это то, о чём договорились, со ссылкой на запись. Но договорённость и код могут разойтись, поэтому её нужно сверять с тем, что реально лежит в Git: между встречей и кодом бывают рассинхроны.
На картинке справа три вида источников, слева результат. Агент подключается к ним через MCP (провода с разъёмами), берёт факты и пишет требования, у каждого пункта которых есть ссылка и статус. Git стоит первым: это основной источник. Confluence нарисован пунктиром: его подключают только когда страницы актуальны. Записи встреч — отдельный источник: из них агент берёт, о чём договорились, со ссылкой и временем. Договорённость нужно сверять с кодом в Git: между встречей и кодом бывают рассинхроны.
Источники удобно вести реестром: одна строка на источник. В таблице три колонки: ссылка (куда идти), описание (что там лежит и насколько свежо) и тип (Git, запись встречи, Confluence). В колонку «Источник» каждого пункта требований агент ставит ссылку из этого реестра.
| Ссылка | Описание | Тип |
|---|---|---|
| git.example.com/shop/requirements/payments.md | Требование «Оплата картой»; история правок, авторы и причины видны в коммитах | Git: файл |
| git.example.com/shop/requirements/tags | Версии требований: v1.1, v2.0 | Git: теги |
| tldv.io/meeting/12-10 | Запись встречи 12.10: о чём договорились, цитаты со временем; сверять с кодом, возможны рассинхроны | Договорённость: протокол встречи |
| confluence.example.com/pay-rules | Правила платежей; у страницы есть владелец, проверена 01.10 | Confluence, только актуальные страницы |
Как просить в протоколах и требованиях
Скажите агенту
Запрос просит агента разложить запись на пункты, у каждого из которых три пометки. Последняя фраза запроса важна: она запрещает считать пункт фактом, если источника нет. Такой запрос подходит для записи встречи, письма, переписки в чате и любого документа.
Шаблон одного пункта
Требование: Оплата картой
Источник: git.example.com/shop/requirements/payments.md, строка 12; встреча 12.10, 14:32, «клиент платит картой при заказе»
Предположение: оплата только в рублях
Статус: факт | не факт | вопрос
Кто подтвердил: —Как читать шаблон. «Требование» — короткое название пункта. «Источник» — ссылка из реестра и цитата со временем: по ним проверяющий находит место за секунды. «Предположение» — то, чего в источнике нет, но что агент решил сам (валюта, срок, роль). «Статус» — «факт», если источник прямо это говорит, «не факт» при догадке и «вопрос», если нужно решение человека. «Кто подтвердил» заполняет человек: имя и дату проверки. Пока там прочерк, пункт не считается принятым.
Пример ответа агента
Требование: Оплата картой
Источник: встреча 12.10, 14:32, «клиент платит картой при заказе»
Предположение: оплата только в рублях
Статус: не факт
Кто подтвердил: —
Требование: Чек на почту
Источник: встреча 12.10, 15:05, «чек присылаем на почту клиента»
Предположение: нет
Статус: факт
Кто подтвердил: —Первый пункт получил статус «не факт»: валюту на встрече не называли, это предположение агента. Второй пункт сказан на встрече прямо, поэтому «факт». Оба пункта ждут подтверждения человека, и список «не фактов» превращается в повестку следующей встречи.
Мажорные и минорные изменения
Когда агент или человек правит требование, важно понимать, насколько правка серьёзна. Различие простое: у минорной правки пруф можно найти, у мажорной пруфа нет. Минорная правка не меняет поведение системы: пункт работает так же, поменялись только уверенность в нём или слова. Её можно проверить по источнику: найти цитату в записи встречи или увидеть в истории Git, что смысл не менялся. Поэтому минорные правки агент делает сам. Мажорная правка меняет поведение системы, и подтвердить её нечем: в источниках такого решения ещё нет, пруф взять неоткуда. Поэтому мажорные правки нужны человеку: агент готовит перечень затронутых кейсов и черновик, а решает владелец требования. После одобрения само решение (кто, когда и почему) записывается в Git и становится новым источником. Так же устроены номера версий в программах: v1.0 → v1.1 означает мелкое уточнение, v1.0 → v2.0 означает перемену, о которой надо предупредить.
На картинке слева исходная версия v1.0. В середине минорная правка: добавлен маленький блок, смысл прежний, меняется второе число (v1.1). Справа мажорная: добавлен большой блок, поведение изменилось, меняется первое число (v2.0). Под минорной правкой подпись «пруф есть, агент делает сам», под мажорной «пруфа нет, решает человек».
| Вид правки | Что произошло | Пруф | Что делает агент | Что делает человек |
|---|---|---|---|---|
| Минорная | Догадка «оплата только в рублях» подтвердилась записью встречи: статус «не факт» меняется на «факт» | есть: tldv.io/meeting/12-10, 14:32, «платим только в рублях» | делает сам: меняет статус, ставит ссылку и цитату, пишет в историю, версия v1.1 | ничего: при желании просматривает историю |
| Минорная | Уточнили слова: «Оплата картой» стало «Оплата банковской картой» | есть: сравнение версий в Git, git.example.com/shop/requirements/commit/a1b2c3, изменились слова, смысл тот же | делает сам и пишет в историю | ничего |
| Мажорная | Предложили принимать ещё и евро: ни в записях встреч, ни в документах об этом ничего нет | нет: в источниках такого решения нет, взять пруф неоткуда | готовит: пишет, что изменится, перечисляет затронутые кейсы и тесты, составляет черновик v2.0 | решает: владелец требования одобряет или отклоняет, решение записывается в Git |
| Мажорная | Предложили подтверждать платёж кодом из банка: в требованиях этого пока нет | нет: решения нет ни в одном источнике | готовит то же самое | решает: владелец требования одобряет или отклоняет |
Пруф и есть граница между двумя видами правок. Если агент нашёл цитату, файл или коммит, который правку подтверждает, она минорная, и он вносит её сам. Если подтвердить нечем, правка мажорная: агент честно пишет «пруфа нет», готовит перечень затронутых кейсов и передаёт решение человеку. С Git это просто: минорную правку агент коммитит сам, мажорную оформляет запросом на слияние, и слить его может только человек. Одобрение владельца в этом запросе потом становится пруфом для будущих правок.
Кейсы использования
Кейс использования (по определению, структурированное описание поведения системы в ответ на запросы внешних участников) — один сценарий того, как люди пользуются требованием. У требования «Оплата картой» их три: обычная оплата, отказ банка и повторный платёж. Выписывать их нужно потому, что правка обычно задевает один-два сценария, и перепроверять нужно именно их. Здесь связь с главой выше: мажорная правка меняет поведение, поэтому агент перечисляет затронутые кейсы и тесты к ним. Минорная поведение не меняет, и агент лишь подтверждает, что кейсы остались прежними. Так после мелкой правки не приходится заново проверять всё требование.
Картинка показывает это на примере. Слева требование «Оплата картой». Справа три его кейса: обычная оплата (клиент платит с первого раза), отказ банка (ошибка и повтор) и повторный платёж (защита от двойного списания). Восклицательный знак стоит у третьего: допустим, на встрече решили изменить защиту от двойного списания. Это мажорная правка, и она касается только повторного платежа. Агент выписывает именно этот кейс и тесты к нему, а обычная оплата и отказ банка остаются как были.
Пример. На встрече решили, что повторный платёж в течение минуты считается тем же заказом. Это мажорная правка, и она касается только кейса «повтор». Для него агент перечисляет тесты, которые нужно обновить, например «второй платёж за 30 секунд не списывает деньги второй раз». Кейсы «обычный путь» и «ошибка» остаются прежними, их тесты запускают без изменений. Если такого списка нет, о затронутом кейсе узнают уже у пользователей.
С чего начать
Шаг 1. Реестр источников: заведите таблицу из трёх колонок и подключите Git через MCP. Шаг 2. Добавьте три пометки в шаблон пункта и отправьте агенту запрос с одной записью встречи. Шаг 3. Договоритесь о правиле: если у правки есть пруф, агент вносит её сам, если пруфа нет, решает человек. Через час у вас будет один протокол, где каждый пункт помечен, и список «не фактов» для следующей встречи. Если «не фактов» много, это нормально: агент впервые показал, где раньше были догадки.