Если вы открываете гпт чат на русском для подготовки словаря данных, сначала соберите определения и примеры у владельца процесса. Покажем учебную заявку из четырёх полей: где сохранить написание, что согласовать и как не превратить предложение в требование. Перед началом проверьте актуальные условия выбранного сервиса.
Что должен объяснять словарь
Словарь полей начните с смысла каждого значения, а затем добавьте имя, формат, обязательность, пример и открытые правила. Не превращайте описание в готовую схему системы до согласования с владельцем процесса. Отдельно фиксируйте, кто заполняет поле и как оно проверяется.
Для одинаковых названий уточняйте единицы и контекст. Поле «сумма» без валюты и правила округления оставляет вопросы, даже если его удобно показать числом. Идентификатор может состоять из цифр, но это ещё не причина превращать его в величину для арифметики.
Сделайте явными пустое значение, отсутствие поля и значение по умолчанию. Для учебного словаря ниже значения по умолчанию не назначены. Если правила пока нет, запись «требует согласования» точнее, чем правдоподобное решение, которое никто не принимал.
Четыре поля учебной заявки
Вымышленная заявка содержит четыре поля. Это авторский набор для обсуждения требований, а не снимок действующей системы.
| Поле | Смысл | Пример | Предлагаемый тип | Обязательность |
|---|---|---|---|---|
| request_id | Идентификатор заявки | 0007 | Строка | Да |
| received_at | Момент поступления | 2026-10-20T10:15:00+03:00 | Строка даты и времени со смещением | Да |
| amount | Сумма из заявки | 1250.00 | Десятичное значение | Нет |
| currency | Валюта суммы | Не задана | Строка | Нет |
Время в примере уже содержит смещение. Имена полей не переводите при подготовке словаря, а русское объяснение храните рядом. Правило отрицательной суммы, справочник валют и создатель идентификатора неизвестны.
Число обязательных полей равно двум из четырёх. Не делайте из этой доли показатель качества процесса: это просто свойство заданного учебного набора.
Промпт без выдуманных требований
Попросите отделить полученное описание от предлагаемых решений. Вопросы разработчику нужны отдельным списком, чтобы новая рекомендация не выглядела уже принятой настройкой.
По четырём полям составь черновой словарь: имя, смысл, формат, обязательность, пример, проверка и открытый вопрос. Сохрани request_id как строку «0007» с ведущими нулями. Не добавляй поля, валюту по умолчанию, предельные суммы, часовой пояс системы и правила округления. Предложения помечай словами «нужно согласовать». Отдельно посчитай поля и обязательные поля. Составь три спорных входа для обсуждения, не объявляй их результатами фактического теста.
После запроса вставьте таблицу и перечень неизвестного. Если черновик всё-таки подставил рубли по умолчанию, верните его к исходнику: валюты там нет. Привычная для автора практика не заменяет правило данного процесса.
Образец словаря и вопросов
Вручную подготовленный образец записи: «request_id: строка, обязательное поле; пример 0007; хранить и передавать без удаления ведущих нулей. Кто создаёт значение и допускаются ли повторения, требуется согласовать».
Для received_at: «Момент поступления с указанным смещением; пример сохраняется целиком. Допустимые форматы и порядок обработки неверной даты нужно согласовать». Не объявляйте один пример исчерпывающим стандартом приёма всех дат.
Для amount: «Необязательное десятичное значение; пример 1250.00. Пустота, допустимый знак, точность и округление требуют решения». Для currency: «Необязательная строка; пример отсутствует. Справочник и зависимость от amount открыты».
Итог: четыре поля, два обязательных. Возможное правило «если сумма заполнена, нужна валюта» вынесено на согласование. Оно не принято учебной карточкой и не должно появиться в колонке обязательности как действующее.
Сверка типов и пустых значений
Проверяйте словарь по одному полю, сравнивая не только имена, но и смысл. У request_id пример должен остаться 0007, не 7. Для передаваемого идентификатора изменение написания может изменить ожидаемое соответствие; поэтому здесь исходная строка закреплена явно.
У received_at проверьте дату, часы и смещение. Не заменяйте строку только календарной датой и не переводите время в другой пояс без поручения. У amount не дописывайте валютный знак. У currency не создавайте справочник из памяти.
Сверьте число строк: четыре имени без повторов, обязательны request_id и received_at. Проверьте все формулировки «по умолчанию», «всегда», «не допускается». Для каждой должно быть решение в исходнике либо пометка о необходимости согласования. Красиво оформленная таблица не устраняет незаданные правила.
Как проверить словарь на спорных строках
Подготовьте спорные входы как сценарии разговора. Первый: идентификатор 0007 передан числом 7. Вопрос: должен ли приёмник отклонить такой вход или источник обязан прислать исходную строку? В учебном описании закреплён строковый пример, а реализация реакции пока не задана.
Второй: сумма заполнена, валюта отсутствует. Не приписывайте строке отказ или успешный приём без согласованного правила. Запишите варианты и владельца решения. Третий: дата пришла без смещения; уточните, допустим ли такой формат и откуда брать недостающее значение.
После обсуждения перенесите принятое решение в словарь и добавьте проверочный пример с ожидаемым результатом. Реальный запуск автоматизации потребует отдельной среды и реализации. Этот материал готовит требования, а не утверждает, что программа уже обработала входы.
Версия словаря и согласование
Сохраните словарь с номером редакции и датой согласования. Изменение смысла поля, обязательности или формата отмечайте отдельно от исправления опечатки. Передайте разработчику и владельцу процесса одну и ту же редакцию вместе с открытыми вопросами.
Если принято новое поле, добавьте его в исходную карточку и пересчитайте число строк. Если изменился пример, проверьте все места его использования: таблицу, сценарии и образец передачи. Не оставляйте ведущие нули в одном документе и числовую запись в другом.
Для приёмки подготовьте конкретный список: каждое имя объяснено, единицы определены либо открыты, неизвестное отмечено, предлагаемые правила отделены от действующих. Подпись согласующего фиксирует решение по требованиям; она сама по себе не подтверждает корректность будущей реализации.
Вопросы о полях автоматизации
Достаточно ли одного примера значения?
Для обсуждения поля он полезен, но не описывает все допустимые входы. Отдельно согласуйте границы, пустые значения и ошибки формата.
Нужно ли выбирать базу данных на этом этапе?
Для учебного словаря достаточно описать смысл и ожидаемое представление. Привязку к конкретной платформе решайте после требований, сохраняя её отдельно от исходного значения.
Можно ли сразу сделать currency обязательным?
Только как согласованное изменение требований. В исходной карточке оно необязательное, а зависимость от суммы остаётся открытой.
Почему не исправить 0007 на 7 для удобства?
Здесь это идентификатор с заданным написанием. Сначала согласуйте изменение с владельцем данных и проверьте соответствия, не меняйте его автоматически.