Как создать словарь данных с ясным смыслом каждого поля.
Словарь данных должен описывать смысл, а не только тип. Включите единицы измерения, допустимые значения и способ представления отсутствующей информации.
Адаптируйте процесс под свою задачу.
Для каждого столбца документируйте бизнес-смысл, тип данных, единицы измерения, допустимые значения, правила представления пропусков и источник. Укажите связи с другими полями и нерешённые вопросы. Проверяйте определения по примерам, а не выводите всё из короткого заголовка.
- Что вы предоставляете
- Схема, примеры значений и бизнес-определения.
- Что вы получите
- Определения столбцов, типы и допустимые значения.
Посмотрите входные данные и результат.
Иллюстративные входные и выходные данные · учебный пример, а не реальный запуск WebAct
Полей ввода: Пример
Document lead_time_days. Confirmed facts: integer; expected calendar days from order acceptance to delivery; nonnegative; blank means estimate unavailable; source is supplier estimate.
Готовый пример
Field: lead_time_days Meaning: estimated calendar days from accepted order to delivery. Type: integer. Unit: calendar days. Allowed values: 0 or greater. Missing value: blank = estimate unavailable. Source: supplier estimate. Example: 7 means an estimated seven calendar days, not seven working days.
Добавьте эти данные в промпт и скопируйте его в WebAct, чтобы попробовать задачу. Ваш результат может отличаться от примера.
Решения и устранение проблем.
Должен ли словарь указывать, измеряется ли срок выполнения в рабочих днях?
Да. Единицы и календарные правила влияют на интерпретацию и относятся к определению поля.
Почему две команды по-разному понимают одно поле статуса?
Допустимые значения или смысл переходов могут быть не документированы. Уточните их с владельцем данных и запишите согласованные определения.
Попробуйте на собственном источнике.
Замените пример своим материалом в промпте. Сохраните нужные требования и скопируйте задачу в WebAct.
Настроить и скопировать задачу ↑