Язык руководителя

– Как правильно составить запрос?

1. Введение

Создавая лекцию для Claude Code, я генерировал, модифицировал и тестировал различные исходные коды в учебных целях. В доискусственном интеллекте я тратил значительное количество времени на размышления и корректировки, чтобы создать код для практики, но теперь всего лишь с помощью нескольких слов в запросе я могу генерировать необходимый код, функциональный код и код, который проходит тесты, все сразу за считанные минуты. Каждый раз я чувствовал, что перешел от создания кода к его проверке.
Более того, я понял, что крайне важно проверять сгенерированный код с разных точек зрения в сотрудничестве с ИИ, и я вновь обратился к универсальным соображениям о том, о чем следует думать и как формулировать запросы при создании первоначального кода.
Конфигурируя пример доски объявлений, я сделал следующий запрос.

“게시글에 댓글 기능을 추가해줘.”

Результаты появились в течение нескольких минут. Была создана сущность Comment, и были построены Service, Controller и JPA-репозиторий, а также отображение списка комментариев на экране, созданном с помощью React. Однако, просматривая экран результатов и исходный код, возникло множество вопросов из-за неосмысленных запросов.
‘Возможно ли отвечать на комментарии?’
‘Удаление мягкое или жесткое?’
‘Может ли удалить только автор? А как насчет администратора?’
‘Как работает постраничный режим?’
Хотя возникло много вопросов, ИИ не задавал ни одного из них во время выполнения задач. На размышление, мой запрос был на уровне подсказок, а не требований, что и привело к полученным результатам. Через подобные опыты я начал размышлять о том, что на самом деле означает 'точный запрос', какие элементы его отличают и как его можно сделать повторяемой процедурой.

2. Рассмотрение запросов как спецификаций требований

Неоднозначные требования создают неоднозначные системы. В инженерии требований качество требований оценивается на основе четкости, полноты, проверяемости и согласованности. Эти четыре критерия напрямую относятся и к запросам. Сам запрос передает наши требования ИИ.

Разница заключается в скорости. Когда неполные требования передаются человеку, возникают естественные вопросы, такие как «Необходимо ли отвечать на комментарии?» или «Какой метод следует использовать для удаления?» Этот процесс является именно уточнением требований. Однако ИИ не задает вопросы. Вместо этого он заполняет наиболее вероятные значения по умолчанию и выдает немедленные результаты. Невопросы эквивалентны скрытию пробелов в требованиях.

Чтобы минимизировать процесс вопросов, возникающий из-за неоднозначных запросов, мы должны перенести этот процесс вопросов на стадию написания запросов. При делегировании пробелов, которые были заполнены в ходе бесед с коллегами-разработчиками, ИИ, они должны быть заполнены заранее на момент запроса. Именно поэтому запросы следует рассматривать не просто как инструкции, а как спецификации требований.

4. Четыре соображения для точного задания запросов

Я организовал четыре соображения для точного задания запросов. Каждый пункт не является независимым и дополняет друг друга.

• Граница вывода
  Первое, что нужно уточнить, это то, что следует создавать, а что не следует. Команда 'функция комментариев' может включать различные значения, такие как ответы, лайки, отчеты, варианты сортировки и интеграция уведомлений. Если границы не установлены, AI установит их самостоятельно, обычно следуя самым распространенным случаям реализации. Эти границы устанавливаются независимо от контекста проекта и, вероятно, будут отличаться от фактических требований.
  Уточнение границ не уменьшает функциональности. Это касается разделения области этого запроса от следующего. Это различие также проясняет обзор вывода.

• Связь с существующими системами
  Второе соображение — уточнить, как эта функция соотносится с структурой существующих программ. Это включает такие аспекты, как метод аутентификации этого проекта доски объявлений, структура сущности поста и формат ответа существующих API. AI способен индексировать весь проект и автономно находить и анализировать соответствующие файлы, но эта способность ограничивается лишь пониманием того, как код связан. Он не может выводить проектные намерения за программой.
  Следовательно, описание связи с существующими системами в запросе не касается расширения сферы исследования AI, а скорее предотвращения генерации результатов на основе неверных предположений.

• Критерии делегирования
  Третье соображение — различать области, в которых AI может самостоятельно принимать решения, и области, которые разработчики должны явно указывать. Например, четкое различие в делегировании полномочий, такое как 'установить политику удаления на мягкое удаление и предложить метод разбивки страниц самостоятельно.'
  Это различие имеет решающее значение, поскольку оно непосредственно связано с когнитивным долгом и долгом намерений, обсуждаемыми в предыдущих записях. Если разработчик делегирует решение, которое должно быть определено (например, политика удаления и диапазоны полномочий, которые тесно связаны с бизнес-правилами) AI, основание для этого решения остается только в коде без какой-либо документации. Напротив, если разработчик указывает области, где AI может принимать решения (например, стиль реализации, внутреннее разделение методов), это приведет к тому, что потребуется много времени для создания запросов. Установление критериев делегирования в конечном итоге определяет, где заканчиваются решения руководителя и начинается усмотрение исполнителя.

• Методы проверки
  Наконец, последний пункт — определить, как проверить результаты на этапе запроса. Запрашивая 'Пожалуйста, также создайте тест, чтобы проверить, возвращается ли 403, когда пользователь пытается удалить, а не автор,' AI структурирует критерии проверки одновременно с реализацией. Определение метода проверки на этапе постпродакшена по сравнению с этапом запроса приводит к совершенно разным результатам.

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

4. Процесс редизайна запросов

Вот различия при переработке неоднозначного запроса.

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

5. Контрольный список проектирования подсказок

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

• Каковы возможные точки отказа этого запроса?
  (Предугадывая проблемы, которые могут возникнуть после получения результатов.)

• Какие части ИИ может решить самостоятельно, а какие части необходимо определить мне?
  (Аспекты, связанные с бизнес-правилами, не делегируются.)

• Организовал ли я, как новая функциональность будет соответствовать существующей структуре?
  (Уточняя взаимосвязи, такие как аутентификация и модели данных.)

• Рассмотрел ли я, как проверять результаты и включил это в запрос?
  (Критерии проверки будут доступны вместе с результатом.)

6. Наконец

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

Jin