Как сравнивать ответы API и оценивать совместимость.
Отделяйте структурные изменения от изменения значений. Новое значение в примере не обязательно нарушает контракт API, а удалённое поле может быть значимо.
Адаптируйте процесс под свою задачу.
Сравнивайте структуры и значения отдельно, сохраняя путь к каждому изменению. Отличайте удалённые или переименованные поля от изменения примерных значений, затем оценивайте совместимость по реальным требованиям потребителей.
- Что вы предоставляете
- Два примера ответов и правила сравнения.
- Что вы получите
- Изменения схемы и значений с рисками совместимости.
Посмотрите входные данные и результат.
Иллюстративные входные и выходные данные · учебный пример, а не реальный запуск WebAct
Полей ввода: Пример
Compare response field sets. Old: {"id":"A1","name":"Ada"}. New: {"id":"A1","display_name":"Ada"}. No API compatibility contract supplied.Готовый пример
Unchanged field: id. Removed field: name. Added field: display_name. Potential impact: clients reading name may fail or lose displayed text. A rename is plausible, but the samples alone do not prove semantic equivalence or the full compatibility policy.
Добавьте эти данные в промпт и скопируйте его в WebAct, чтобы попробовать задачу. Ваш результат может отличаться от примера.
Решения и устранение проблем.
Автоматически ли изменение значения в примере нарушает контракт API?
Нет. Значение может меняться правомерно. Значимость определяют схема, смысл и допущения потребителей.
Почему переименование поля выглядит как несвязанные удаление и добавление?
Структурное сравнение не доказывает намерение. Отметьте возможное переименование и подтвердите его по документации изменений и использованию потребителями.
Попробуйте на собственном источнике.
Замените пример своим материалом в промпте. Сохраните нужные требования и скопируйте задачу в WebAct.
Настроить и скопировать задачу ↑