schedule4 мин чтения

Почему именование важнее промптов при работе с ИИ

Ваши имена переменных — лучший промпт. Как конкретные идентификаторы не дают ИИ генерировать неправильный код, и почему 'data' — худшее, что можно назвать.

Дмитрий БолотовQuotyAI
translate
Доступно на:
infoЭта статья переведена с помощью ИИ

Когда вы кодите с ИИ, ваши имена переменных — лучший промпт. Не системный промпт. Не инструкции. А имена, которые вы даёте функциям, параметрам и переменным.

Вот почему: ИИ читает ваш код токен за токеном. Каждое имя, которое он встречает, ограничивает то, что он генерирует дальше. Функция handleData() не даёт ИИ никаких ограничений. Функция dispatchWebRTCOmnichannelUIEvent() почти не оставляет ему пространства для ошибки.

Я строю системы агентного ИИ этим подходом, и разница в качестве вывода огромна.

Проблема общих имён

Большинство разработчиков ленятся при именовании. data, temp, result, id, msg. В традиционном кодировании это плохая практика, но терпимо — у вас есть автодополнение IDE, документация команды и собственная память.

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

Проведите эксперимент: попросите ИИ «реализовать обработчик уведомлений» без контекста. Затем попросите снова, но назовите функцию dispatchWebRTCOmnichannelUIEvent(). Первый вариант даст что-то общее и скорее неправильное. Второй — код с WebSockets и обработкой событий с низкой задержкой, потому что имя точно сказало, что нужно построить.

Как именование ограничивает генерацию ИИ

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

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

Это не теория. Так работают архитектуры трансформеров.

Реальные примеры из QuotyAI

Сравнение результатов общих и конкретных имён переменных

В нашем коде нет общих имён. Каждое имя функции несёт семантическую нагрузку:

  • Техническая инфраструктура: dispatchWebRTCOmnichannelUIEvent() говорит ИИ, что это клиентское событие в реальном времени с низкой задержкой. Не пакетная задача. Не электронное письмо. Событие WebSocket. MDN WebSockets API становится очевидной справочником.

  • Бизнес-логика: postNewOrderToManagementChannel(paidOrderId, platform) заставляет ИИ генерировать код интеграции — вызовы Slack SDK, webhook payloads, маршрутизацию каналов. Не лог в консоль. Не вставку в базу данных.

  • Аналитика: triggerTenantProvisioningEmailCampaign(tenantDetails) помещает ИИ чётко в область автоматизации электронной почты. Цепочки drip, онбординг-флоу, рендеринг шаблонов.

Закономерность: чем конкретнее имя, тем меньше ИИ приходится угадывать.

Тестов недостаточно

Зелёные тесты не означают, что код правильный

Распространённый подход: написать тесты сначала, пусть ИИ заставит их пройти. Тесты проходят, значит, код хороший.

Неправильно. Тесты проверяют, что ваш код делает то, что говорят тесты. Если тесты расплывчатые — expect(result).toBeDefined() — ИИ сгенерирует код, который проходит тест, но ничего полезного не делает. У вас зелёная полоса и сломанный код.

Тесты предотвращают结构性 крах. Именование определяет, чем на самом деле становится код.

Когда вы переименовываете handleStuff() в calculateMonthlyRecurringRevenue(subscriptionId, billingCycle), ИИ внезапно понимает, что нужно: найти подписку, определить биллинг-цикл, рассчитать MRR и вернуть число. Тест может тогда проверять реальную бизнес-логику, а не просто «что-то вернулось».

Тест grep

Общие имена делают grep бесполезным

Попробуйте это в кодовой базе с общими именами:

grep -r "notify" .

Вы получите 400 результатов. Ни один из них не тот, который вам нужен. Вы читаете каждый, пытаясь разобраться, какой notify обрабатывает Slack, а какой — электронную почту, push или webhook.

А теперь попробуйте с конкретными именами:

grep -r "dispatchWebRTCOmnichannelUIEvent" .

Три результата. Определение, место вызова и тест. Вот и всё.

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

Приём с рефакторингом

Вот самый практичный трюк: когда ИИ генерирует неправильный код, не переписывайте промпт. Переименуйте переменные.

Если ИИ генерирует функцию, которая путает токены аутентификации с идентификаторами сессий, переименуйте userId в firebaseAuthUid, а sessionId — в livekitWebRTCToken. Часто ИИ исправится сам при следующей генерации — новые имена ограничат его вывод правильной областью.

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

export class CrossTenantAnalyticalEventNotificationService {
  private readonly logger = getLogger(CrossTenantAnalyticalEventNotificationService.name);

  constructor(
    private readonly telegramSdkService: TelegramSdkService,
    private readonly facebookSdkService: FacebookSdkService
  ) {}
  
  // The class name alone tells the AI this handles cross-tenant notifications
  // via Telegram and Facebook. No further context needed.
}

Три правила именования для совместимости с ИИ

  1. Будьте конкретны, но не изобретательны: calculateMonthlyRecurringRevenue() лучше calcMRR() и убивает calculateStuff(). ИИ нужны полные слова для понимания намерений.

  2. Используйте термины предметной области, а не инфраструктуры: orderCreatedSlackNotification() лучше sendAlert(). ИИ знает, что у Slack есть конкретный SDK, конкретные форматы сообщений, конкретные лимиты API. alert может означать что угодно.

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


Часто задаваемые вопросы

Почему мой ИИ-ассистент генерирует неправильные функции? ИИ плохо работает, когда имена переменных слишком общие. Имена вроде id или data не дают никакого контекста, и ИИ начинает угадывать. Конкретные имена вроде firebaseUserId или incomingOmnichannelChatMessage точно говорят ИИ, чем является данные, снижая количество ошибочных предположений.

Как остановить ИИ от генерации галлюцинаторного кода? Замените общие параметры на конкретные. Вместо передачи (userId), передавайте (firebaseUserId, webrtcSessionId). Конкретные имена ограничивают то, что генерирует ИИ — он не будет путать идентификаторы аутентификации с токенами сессий.

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

Было полезно? Поделитесь.

Похожие статьи

Исполняемые навыки для агентов лучше документации

Документация создавалась для людей. Теперь её читают AI-агенты. Им не нужен текст — им нужен исполняемый код. Почему навыки побеждают документацию.

Читать статьюarrow_forward

Spec-Driven vs Code-First vs Chat-to-Code: Три философии обучения ИИ вашего бизнесу

Три подхода к построению знаний ИИ-агентов — разработка на основе спецификаций, документация на основе кода и генерация кода через чат. Сравнение Spec Kit, OpenWiki, Mintlify и QuotyAI с реальными подводными камнями, продуктами и сигналами конвергенции.

Читать статьюarrow_forward

OpenWiki vs QuotyAI: два проекта на LangChain DeepAgents, две архитектуры

OpenWiki использует LangChain DeepAgents для генерации документации к кодовым базам. QuotyAI использует тот же API createDeepAgent для генерации исполняемой бизнес-логики на TypeScript. Техническое сравнение архитектуры агентов, паттернов субагентов и исполнения кода.

Читать статьюarrow_forward
Спасибо за чтение!
Читать другие статьи