Что агент видит: контекст в редакторе

Откуда берётся контекст

Всё, что агент делает, он делает по тому, что видит. Видит он не проект целиком — окно не бесконечно, — а отобранный кусок: часть отбирается сама, часть отбираете вы.

Приходит само — открытый файл, выделенный кусок, найденное поиском по проекту, предыдущие шаги разговора. Это удобно и это же источник большинства недоразумений: вы не видите, что именно попало, и естественно предполагаете, что попало нужное.

Добавляете вы — указанный файл или папка, правила проекта, то, что вы описали словами. Это единственная часть, про которую вы знаете точно.

Отсюда первая привычка, которая экономит больше всего времени: перед поручением посмотреть, что открыто. Не из дисциплины — из того же соображения, из какого перед разговором с человеком показывают нужную бумагу, а не всю папку.

Теперь про поиск по проекту, потому что он и полезнее, и коварнее всего остального.

Редактор умеет находить в проекте места, похожие на то, о чём вы спросили, и класть их в окно. Это выглядит как «он знает мой проект» и работает в большинстве случаев. Но ищет он по похожести слов, а не по смыслу вашей задачи.

Второе свойство поиска, о котором стоит знать: он находит то, что есть, и молчит о том, чего нет. Если нужного места в проекте не оказалось — потому что оно в другом репозитории, в настройках или в голове у коллеги, — агент этого не скажет. Он построит ответ из найденного, и ответ будет выглядеть уверенно.

Отсюда вторая привычка: спрашивать, на что он опирался. Вопрос «перечисли файлы, которые ты смотрел» стоит десять секунд и отвечает на большинство «почему получилось не то» раньше, чем вы начали читать код.

И третье свойство, которое стоит назвать, потому что оно объясняет странности: контекст собирается заново на каждом шаге. Это не память, которая накапливается, а отбор, который делается каждый раз. Открыли другой файл между двумя поручениями — второе поручение получило другой контекст, хотя вы ничего не меняли в словах.

Практически это означает, что воспроизвести удачный заход не всегда просто: сработавшая вчера фраза сегодня может дать другой результат, потому что у вас открыто другое. Обвинять в этом модель бесполезно; полезно заметить, что отбор зависит от рабочего места, и привести рабочее место в то же состояние.

Окно не бесконечно

Теперь точнее: что помещается и что происходит, когда не помещается.

Окно — это то, сколько текста модель видит за один раз. Оно большое, но конечное, и проект в него не влезает. Значит, в окно попадает отобранное, а отбор делает либо редактор, либо вы.

Что происходит, когда отобранного слишком много, — важнее, чем кажется. Ответ не «оно обрезается с конца», а «качество падает постепенно»: чем больше в окне лишнего, тем хуже модель держит важное.

Дальше — что именно стоит класть в окно. Список короткий, потому что длинный не работает.

Вторая строка — самая недооценённая. «Сделай так же, как в этом файле» работает лучше любого описания стиля: агент читает образец и повторяет его, включая то, что вы не сумели бы сформулировать словами.

Теперь о том, что в окно не кладут, и почему.

Весь проект целиком. Он не влезет, а то, что влезет, будет отобрано случайно. Это ровно противоположно тому, ради чего вы это делали.

Длинную историю разговора. Двадцатый шаг одного разговора тащит за собой девятнадцать предыдущих, половина которых — тупиковые попытки. Новый разговор с коротким точным описанием почти всегда работает лучше двадцатого шага старого.

И ещё одно, о чём стоит знать заранее: вложенные файлы не пересматриваются сами. Если вы приложили файл, а потом его поправили, агент может продолжать опираться на прежнюю версию. В длинном разговоре это выглядит как «он не видит моих правок» — и лечится тем же способом: новым разговором.

Как управлять контекстом

Теперь практическая часть: как управлять контекстом, не превращая это в отдельную работу.

Порядок из четырёх шагов, и занимает он полминуты.

Первый шаг непривычен и потому пропускается. Двадцать открытых вкладок — обычное состояние рабочего дня, и в редакторе без агента они ничего не стоят. Здесь они стоят: часть из них попадёт в окно и потеснит нужное.

Третий шаг — тот, ради которого написана вся глава. Одна строка в поручении заменяет собой половину неудачных заходов: «учти, что курс и программа обучения у нас одно и то же», «числа берём из представления v_totals, а не из таблицы», «этот формат читает выгрузка в бухгалтерию».

Теперь про длину поручения, потому что тут два противоположных перекоса.

Слишком коротко — «почини отчёт». Агент додумает, какой отчёт, что в нём сломано и что считать починкой, и все три догадки будут разумными и, скорее всего, не вашими.

Слишком длинно — три абзаца, в которых условие, история вопроса, ваши сомнения и просьба быть внимательным. Важное в них тонет так же, как в забитом окне, и результат становится хуже, а не лучше.

Рабочая длина — две-четыре строки: что сделать, где, чего не делать, как проверить. Всё, что длиннее, обычно означает, что задача не разбита.

И последний приём главы, который стоит всех прочих: сначала спросить, потом поручать. «Где в проекте считается стоимость?» — вопрос на десять секунд, ответ на который вы проверите взглядом. Получив его, вы поручаете правку, уже зная место, — и агент тоже знает, потому что сам его назвал шагом раньше.

Этот порядок — «вопрос, потом поручение» — работает почти всегда и особенно в чужом проекте. Он превращает одно рискованное действие в два дешёвых, и первое из них проверяется за минуту.

Признаки, что контекста не хватило

Последняя глава — про распознавание. Почти все жалобы на «модель глупая» на деле означают одно: она не видела нужного. Признаков четыре, и все четыре узнаются с одного взгляда.

Выдумал функцию, которой нет. Классический признак: в ответе вызывается formatMoney(), а такой функции в проекте не существует. Значит, поиск не нашёл вашу — она называется иначе, — и агент собрал разумное имя из общего опыта.

Сделал по-своему, а не как в проекте. Свой способ работы с датами, своя обработка ошибок, своя структура. Значит, он не видел ни одного примера того, как у вас принято.

Поправил одно место из трёх. Значит, двух других он просто не нашёл: они называются другими словами или лежат там, куда поиск не дошёл.

Спорит с тем, что вы уже говорили. Значит, разговор слишком длинный, и ранние указания потеряли вес.

Как проверить догадку за десять секунд: спросить, на что он опирался. «Перечисли файлы, которые ты смотрел» — и в ответе видно всё: не тот файл, половина нужных, или вовсе ничего похожего на ваше место.

Отдельно стоит сказать про случай, который выглядит как тот же, но им не является.

Во втором случае работает другое: сказать недостающее словами и, если оно повторяется, записать в правила проекта. Это тема шестого урока, и она вырастает ровно отсюда.

Стоит назвать и пятый признак, который выглядит совсем иначе и потому редко связывается с контекстом: ответ вообще не про ваш проект. Вместо вашего кода — учебный пример из документации, с чужими именами и чужой структурой. Это крайний случай того же самого: он не нашёл ничего подходящего и построил ответ из общего опыта.

Отличить его легко по именам: если в ответе User, Item и doSomething(), а в вашем проекте таких сущностей нет вовсе, значит поиск вернул пустоту. Чаще всего это означает, что вы спросили про то, чего в проекте ещё нет, — и тогда ответ по-своему честен: он предлагает, а не находит.

И последнее — привычка, которая стоит всей главы. После неудачного ответа не переписывайте вопрос сразу. Сначала десять секунд на «на что ты опирался». В половине случаев ответ снимает вопрос целиком, а в другой половине показывает, чего именно не хватало, — и это дешевле, чем три захода с переформулировками.