Хотя, как было построено в прошлом AutoDev из AutoCRUD、Точныйтест Та же функция,наснамеренно построитьодининдивидуальный完全автоматическийизменятьиз API Разработать агента。Но все жеиз,Мы столкнемся с некоторыми проблемами:

• Проектирование API требует участия человека.,Потому что здесь нужно учитывать бизнес-логику, структуру данных и т. д.
• Документация API является контекстной и бизнес-контекстной.
• Генерировать большое количество API хранилище кодасуществовать Многоизриск безопасности。
• ИИ генерирует большой объем кода, требуя участия человека в проверке кода.
• Многие изтесты могут быть улучшены API изкачество,Но охват тестами, точность тестов и т.д.,Все требует человеческого участия.
• ……

Поэтому,существоватьтекущий этап,Мы ожидали, что из одинагентов станет 10+ агентов.,Уменьшить умственную нагрузку на людей. Поэтому,Начнем с трех вопросов:

• В прошлом процессе ИИ В каких аспектах я могу участвовать?
• каксуществовать AI Баланс между автоматизацией и участием человека?
• какубеждатьсягенерироватьиз API и документация соответствует высоким стандартам качества?

Отсюда и формируется содержание данной статьи.

Обзор: процесс разработки классического API

Здание API В настоящее время у нас обычно есть два этапа: этап бизнес-стратегии и этап внедрения технологии. На этапе разработки бизнес-стратегии мы принимаем во внимание API из Бизнес-ценность, API из Бизнес-модель и так далее. существующие Технологииэтап реализацию, мы рассмотрим API из Дизайн, API из Документация, API итест и так далее.

На этапе технической реализации нам предстоят следующие шаги:

• этап проектирования：
  • Разработка контрактов API для восходящих и нисходящих потоков：Конечно API из формата ввода и вывода используйте open API Спецификации (такие как Swagger/OpenAPI) определяют контракты, чтобы обеспечить понятные и согласованные интерфейсы.
  • Написание документации по API：Написано так, чтобы было легко понятьиздокумент,Содержит примеры использования, коды ошибок и информацию о сертификации.,Заставьте пользователей быстро приступить к работе.
• этап реализации：
  • Кодирование API：в соответствии сдизайндокументруководитькодирование,Следуйте стандартам и лучшим практикам кодирования,Обратите внимание на обработку и протоколирование ошибок.
  • Ручное тестирование разработчика：Предварительныйтест API Базовые функции гарантируют, что интерфейс может нормально реагировать на запросы и возвращать правильные данные.
  • Модульное тестирование API：пишущий блоктестпроверять API Корректность каждого компонента обеспечивает стабильность и надежность кода в различных ситуациях.
• Этап интеграции и совместной отладки：
  • Интеграция между приложениями：убеждаться API Способен эффективно интегрироваться с другими системами или системами, руководить потоком данных сквозной проверки и взаимодействие в норме.
  • Совместная отладка внешнего и внутреннего интерфейса：развивать Команда, работающая с фронтенд-инженерами,руководить совместной отладкой интерфейса,Убедитесь, что внешний интерфейс может правильно вызывать API.
• этап тестирования：
  • Функциональное тестирование API：проверять API Работает ли каждая функция нормально в соответствии с требованиями дизайна и гарантируется ли правильная логика интерфейса.
  • Тестирование производительности API：тест API существоватьпод высокой нагрузкойиз Время отклика и стабильность,Включая тест на давление и тест на нагрузку,Обязательно идите навстречу бизнесу нуждаться.
  • Тестирование безопасности API：руководить Проверка безопасности итест,Обнаружение потенциальных уязвимостей безопасности,Такие как аутентификация, авторизация, шифрование данных и т. д.,Убедитесь, что API не уязвим для атак.
• стадия релиза：
  • Релизы API и обновления документации：существоватьтест После прохождения,Подготовить API из Развертывание и обновление производственной среды API Документация, обеспечивающая доступ соответствующих сторон к последней информации об использовании.
  • Мониторинг и обратная связь：Непрерывный мониторинг после выхода в Интернет API Использование и производительность, непрерывные итерации и оптимизация на основе отзывов пользователей и анализа журналов. API。

Это очень идеально API Процесс развития, но в реальном развитии мы столкнемся с множеством проблем. Ведь после того, как вы в течение дня пообщались с различным вышестоящим и нижестоящим персоналом, до выхода с работы у вас остается всего полчаса, а может и Вечером самое время написать код.существовать после того, как вы отработали сверхурочно и закончили работу.,Вы закончили писать код,Но документ еще не закончен,тест не закончен,Даже ты закончили писать код,Или, возможно, ваш код не соответствует спецификациям.

Так может ли ИИ?

Эксперимент: более 10 нативных агентов, разработанных API

Недавно мы были Shire развитый в языке API развитие, связанное с пакетом агентов для поддержки улучшенных сборок API. В этом процессе мы объединяем стандартные API усовершенствовать процесс и AI Возможности интеллектуального агента для обеспечения лучшего развития AI Вспомогательный API Опыт разработки.

мы создали 10+ агенты по поддержке API развивать различные этапы, такие как анализ потребности, API Дизайн, API Генерация документов, API Генерация кода, API Тестирование и многое другое. Разумеется, для совместной отладки, У нас пока нет хорошего дизайн-проекта, кроме существованиястадии. релиза, пока не нужен AI из Участвовать.

Этап проектирования: 3 агента

Фаза проектирования в основном состоит из трех агентов: агента удаленных требований (Dify), локальной генерации Swagger и генерации Mock-кода.

• нуждаться Агент: Использование из удаленно Dify Приходите к Вспомогательныйнуждаться анализу, то есть в сочетании с внутренней изнуждаться информацией, генерируемой API требуемый дизайн из информации.
• Swagger Генерировать: Генерировать на основе информации о нуждах. Swagger API документ.
• Mock Код, сгенерированный с помощью Служить: на основе Swagger API документировать,генерировать WireMock Код и Служить。

существоватьздесь,фактически,нас Все еще не хватаетодининдивидуальныйдизайн：Объединить внутренниеиз API Спецификация документации и существующий дизайн базы кода. мы Shire введено в mock функция для прямого запуска Mock Служить, Пример: mock("docs/mock_v0-stubs.json")。

Стадия разработки: 3 агента

развивать Этапы в основном состоят из трехагентыкомпозиция：объединитьнуждатьсяизкодгенерировать,развиватьтест API Код, API Тестирование кода.

• В сочетании с генерацией кода «зависимость»: существует то же самое, что и использование. Dify Информация в изнуждаться имеет более высокую степень детализации и будет автоматически изменяться. Controller и Service код.
• развиватьтест API Код: этап разработки, который мы часто используем Postman Приходитьтест,исуществовать IDE , мы можем использовать Http Client Приходите тестировать.Итак, наш агент сгенерирует Http Client Вручную или автоматическийруководитьтест для проверки. API из Корректность.
• API Генерация тестового кода: на основе Mock API документировать, генерировать REST Assured тесткод.

По этой причине мы по-прежнему execute В функции поддерживается оригинал из Gradle режиме задач, т.е. через execute(":bootRun") Можно запустить напрямую Spring Boot проект. Конечно, мы также поддерживаем commit、 push функция поддержки Git действовать.

Фаза тестирования: 2 агента

существоватьэтап тестирования, мы в основном объединяем четыре различных среды тестирования для поддержки API изтест：ab Тестирование, Питон Язык из Locust Тестирование, JavaScript Язык из K6 Тест, Драматург тест.

• ab тест тест: использовать Apache Benchmark руководить API производительностьтест.
• Locust тест тест: использовать Python Язык из Locust руководить API производительностьтест.
• Grafana k6 нагрузочный тест тест: использовать JavaScript Язык из K6 руководить API производительностьтест.
• Playwright тест тест: использовать Playwright руководить API Функциональный тест.

Хотя термин «агенты» здесь немного преувеличен, на самом деле это всего лишь два шага в процессе API.

Генерация устаревших документов: 2 агента

Для приложений, в которых отсутствует документация Swagger API, мы создали четыре агента для решения этой проблемы:

• SpringDoc OpenAPI Способ
  • добавить в SpringDoc OpenAPI полагаться, принять patch способ добавить Gradle полагаться.
  • существовать Controller Добавить средней порцией Spring REST Docs аннотация.
• Spring REST Docs Способ
  • добавить в Spring REST Docs Зависимость, в том числе, принимает patch способ добавить Gradle полагаться.
  • существоватьтест Добавить средней порцией Spring REST Docs аннотация.

мы Shire добавлено в batch функция для облегчения пакетного добавления Spring RestDocs аннотация,Пример: batch("add-annotation-to-controller-test.shire) Скрипт.

Экспериментальные мысли и резюме

объединитьнаспрошлоесуществовать Вспомогательныйнуждатьсяи AutoDev изразвиватьопыт,нас Подвести итог получил три мысли, чтобы построить лучшее существование в будущем из AI Программные агенты:

• Объедините контекст уточнения процесса, чтобы получить максимальное удобство использования и потенциал.
• В прошлом узкие места все еще существовали, просто превращаясь в точки принятия решений.
• Проведите несколько раундов автоматизированных проверок для обеспечения качества.

Мысль 1: Объедините контекст уточнения процесса, чтобы получить максимальное удобство использования и потенциал

AI Два режима исследований и разработок в «Вспомогательный»: улучшение существующих и создание новых парадигм. существующийтекущий Генеративный AI Если он недостаточно мощный, мы можем улучшить существующий API развивать процесс, чтобы улучшить нашу эффективность и качество.

Генеративный AI Определенно не предложение: пожалуйста, сгенерируйте его. xxx из API. Вместо этого объедините:

• спецификация дизайна, гарантирующая, что будет созданодизайн Соответствуют спецификациям
• Бизнес-контекст для справочной информации
• развиватьспецификация,Убедиться, что сгенерированный код соответствует требованиям качества.

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

Мысль 2: Точки блокировки в прошлом все еще существуют, просто превратились в точки принятия решений.

В разработке API На этот раз мы разделим его по этапам. Причина в том, что каждый этап требует общения с людьми с разными ролями, поэтому он станет точкой блокировки. Даже если есть AI из участия, эти блокирующие пункты продолжают существовать, Но некоторые из них можно преобразовать в точки принятия решений, а некоторые всё ещё остаются блокирующими:

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

AI Что нам может помочь, так это предоставить больше информации для поддержки принятия решений. Однако ИИ Оно не может помочь нам принимать решения, поскольку принятие решений требует участия человека.

Мысль 3: Организуйте несколько раундов автоматизированной проверки для обеспечения качества

существующаябольшая часть команды,Вам нужно только реализовать бизнес-код,Нет необходимости реализовывать тестовый код и т. д. но,существоватьобъединить Генеративный AI В контексте кода генерировать бизнес-код может быть неправильно. Чтобы избежать проблем с качеством, Для переделок и других проблем лучший способ: несколько раундов автоматизированных проверок для обеспечения качества.。

• API проверка дизайна: совмещенная с внутренней API спецификация дизайна, гарантирующая, что будет создано API Соответствовать спецификациям. Например, мы использовали из ArchGuard поддерживает этот метод проверки.
• проверка дизайна: объединить WireMock генерировать Mock Служить, чтобы гарантировать, что Swagger API Документация соответствует.
• автоматический API тестовый тест: сгенерировать IDEA серединаиз HttpClient (аналогично PostMan） Кодируйте и запускайте и проверяйте.
• API Входная и выходная проверка: генерировать Rest Assured код теста и т. д., чтобы гарантировать API из Ввод и вывод правильные.

Помимо этого,Мы можем состоять из множества разных моделей, состоящих из двух разных кодов.,Приходите и проверьте друг друга. Например: модель генерирует код для теста.,Другая модель генерирует код для производства.

Подвести итог

существовать AI Вспомогательные исследования и разработки сегодня актуальны, классика – API интеллектуальный режим по-прежнему незаменимиз —— AI Оно не может помочь вам создать идеальный образ. API не может помочь вам взять на себя вину. Однако мы можем использовать AI из возможностей повысить нашу эффективность, улучшить наше качество и опыт. разработки.

PS：Shire Связанный API Проектирование и разработка AI О реализации интеллектуального агента см.:

• от Shire IDE Плагин Shire Marketplace Загрузите и используйте API пакет агента «дизайн, генерация и документация», вы можете его испытать.
• Прочтите пример кода на GitHub: https://github.com/shire-lang/shire-spring-java-demo.