Вход Блог
Строительство и ремонт
Репетиторы
Красота
Фрилансеры
Разные специалисты
Тренеры
Уход за животными
Автоинструкторы

Программисты — удалённая работа в Москве

Дата: 2026-01-23
Детали
Регион
Москва
Занятость
дистанционно
Стоимость
договорная
Дата публикации
2026-01-23
Описание
Al-бот-консультант для Fun Pay с базой знаний о товарах. Настройка, доработка существующего продукта. Техническое задание AI-бот-консультант для FunPay с базой знаний о товарах 1. Общая идея проекта Необходимо разработать AI-бота-консультанта для платформы FunPay, который автоматически отвечает на вопросы покупателей на основе базы знаний о товарах (аккаунтах). В отличие от стандартных автоответчиков, бот должен понимать, о каком конкретном товаре идёт речь, и отвечать по реальным характеристикам аккаунта, а не шаблонно. Общение должно выглядеть как диалог с живым продавцом. Основная цель проекта — снизить нагрузку на продавца, повысить доверие покупателей и увеличить конверсию в покупку. --- 2. Проблема, которую решает проект На FunPay описания товаров часто краткие и не содержат всей необходимой информации. Покупатели регулярно задают дополнительные вопросы, такие как: какие скины есть в аккаунте; есть ли привязка к почте или телефону; какой уровень и регион; чем данный аккаунт отличается от других. Без базы знаний бот не располагает этой информацией и вынужден отвечать общими фразами, что снижает качество консультации и вероятность сделки. --- 3. Цель и задачи бота Цель Создать AI-ассистента, который полноценно консультирует покупателей по конкретным товарам и работает в автоматическом режиме 24/7. Задачи: анализировать сообщения клиента; определять, о каком товаре идёт речь; получать данные из базы знаний; формировать короткие, понятные и корректные ответы. --- 4. Функциональные требования 4.1 Консультация по товарам Бот должен уметь отвечать на вопросы следующего типа: «Какие скины есть в этом Valorant аккаунте?» «Есть ли привязка к почте и можно ли перепривязать?» «Какой уровень и регион?» «Какие особенности у этого CS2 аккаунта?» Ответы должны: основываться на данных конкретного товара; не содержать вымышленных фактов; выглядеть как ответы реального продавца. --- 4.2 База знаний о товарах Для каждого товара должна существовать отдельная запись в базе данных. На старте предполагается около 200 товаров. База данных должна быть удобной для: масштабирования; ручного редактирования; обновления информации. Пример структуры записи товара: игра / сервис; уровень аккаунта; регион; наличие и тип привязок; скины и редкие предметы; особенности; ограничения (если есть). --- 4.3 Наполнение базы данных Первичное наполнение базы осуществляется автоматически с помощью AI по заранее заданному шаблону (промту). В дальнейшем должна быть предусмотрена возможность: ручного редактирования данных; точечной доработки популярных товаров. Принцип: один товар — одна отдельная запись и один отдельный промт. --- 4.4 Добавление новых товаров При добавлении нового товара: автоматически создаётся новая запись в базе данных; она наполняется базовой информацией через AI; при необходимости данные корректируются вручную. --- 4.5 Поведение при отсутствии информации Если бот не располагает точной информацией по заданному вопросу, он должен честно сообщить об этом и предложить уточнить данные у владельца аккаунта. --- 5. Технические требования (общее описание) Интеграция с FunPay через систему плагинов. Использование AI-модели для генерации ответов. Возможность работы с бесплатным AI на старте. Возможность подключения платного AI (например, DeepSeek) при увеличении нагрузки. Корректная обработка одновременных запросов от нескольких клиентов. --- 6. Требования к стилю ответов Бот должен: отвечать кратко и по существу; использовать дружелюбный, неофициальный стиль; не придумывать информацию; избегать конфликтных формулировок; при необходимости передавать диалог владельцу. --- 7. Этапы реализации 1. Проектирование структуры базы знаний 2. Реализация логики определения товара 3. Интеграция AI с базой данных 4. Первичное наполнение базы 5. Тестирование диалогов 6. Оптимизация и доработка Минимальный срок реализации — от 7 дней. --- 8. Ожидаемый результат В результате должен быть реализован полноценный AI-бот-консультант для FunPay, способный автоматически и корректно консультировать покупателей по каждому товару. Данный инструмент должен обеспечить: повышение доверия со стороны клиентов; сокращение времени обработки сообщений; конкурентное преимущество на платформе FunPay. -.
Похожие заказы

Программисты

дистанционно
договорная
Разработка мобильных приложений. Разработка с нуля, Тз проверка., тестирование. Приложение: для Android, для iOS. Устройства для масштабирования: смартфоны. Технический здание должен проверить реализовать можно или нет.
Москва Фрилансеры

Внедрение ИИ

дистанционно
договорная
Пожелания и особенности: настройка Claude cowork для обработки файлов управленческого учёта, налоговой и финансовой отчётности.
Санкт-Петербург Фрилансеры

Программисты

дистанционно
договорная
Веб-разработка. Разработка с нуля. Создание программы для регистрации участников.
Санкт-Петербург Фрилансеры

Разработка ботов Telegram

дистанционно
договорная
Задачи чат-бота: финансовые операции. Продукт: сервис. Техзадание есть.
Москва Фрилансеры

Программисты

дистанционно
договорная
Веб-разработка. Разработка с нуля.
Москва Фрилансеры

Программисты

дистанционно
договорная
Системное программирование. Доработка существующего продукта. 1.2.1. Модификация существующих секций информационной системы 1.2.1.1. На вкладке «Сервисные организации» добавить поле для прикрепления фотографии подписи директора. 1.2.1.2. На вкладке «Владелец инфраструктуры» добавить: ● поле «ФИО директора»; ● поле для прикрепления фотографии подписи директора. 1.2.1.3. На вкладке «Инфраструктура» добавить раздел «Собственная информация» с полями: ● «ФИО начальника технического отдела»; ● поле для прикрепления фотографии подписи начальника технического отдела. 1.2.2. Добавление новой вкладки «Паспорт» в Систему со следующими полями и значениями по умолчанию (где указано) 1.2.2.1. Габарит (по умолчанию: 1Т). 1.2.2.2. Длина по осям автосцепок (по умолчанию: 16970 мм). 1.2.2.3. Конструкционная скорость (по умолчанию: 100 км/ч). 1.2.2.4. Скорость в недействующем состоянии (по умолчанию: 80 км/ч). 1.2.2.5. Нагрузка на ось (по умолчанию: 20 тс). 1.2.2.6. Минимальный радиус кривых (по умолчанию: 80 м). 1.2.2.7. Количество секций (по умолчанию: 1). 1.2.2.8. Высота автосцепки (передняя – по умолчанию 1040 мм, задняя – 1042 мм). 1.2.2.9. Плотность тормозной магистрали (по умолчанию: 0,2 кг/см² за 60 сек). 1.2.2.10. Плотность питательной магистрали (по умолчанию: 0,2 кг/см² за 300 сек). 1.2.2.11. Плотность тормозных цилиндров (по умолчанию: 0,2 кг/см² за 60 сек). 1.2.2.12. Производительность компрессора (по умолчанию: 28). 1.2.2.13. Проходимость блокировки (по умолчанию: прочерк «–»). 1.2.3. Добавление вкладки «Склад» в Систему, которая хранит типы оборудования : ● Дизель ● Коленчатый вал ● Генератор ● Турбокомпрессор ● Двухмашинный агрегат ● Электродвигатель ● Тележка ● ТЭД (тяговый электродвигатель) ● Колёсная пара ● Автосцепка ● Компрессор ● Резервуар ● Кран ● Скоростемер (Скоростимер) ● АЛСН ● ЭПК ● Блок Л-116 ● Радиостанция ● Тормозные башмаки , с возможностью добавления/редактирования записей. Для каждого типа оборудования предусмотреть следующие поля с возможностью дальнейшего расширения: ● наименование; ● тип; ● номер; ● год выпуска. Каждая запись может быть привязана только к одному локомотиву. 1.2.4. Реализация функции формирования акта (в формате DOCX) на основе данных из Системы по шаблону Заказчика со следующими правилами заполнения 1.2.4.1. Первый абзац акта заполняется по шаблону с данными из вкладки «Паспорт». 1.2.4.2. Поле «Наименование и реквизиты предприятия владельца транспортного средства»: заполняется наименованием (фиксированное значение). 1.2.4.3. Раздел «Колёсные пары»: заполняется актуальной таблицей осмотра колёсных пар локомотива из вкладки «Колёсные пары». 1.2.4.4. Раздел «Автосцепное устройство»: ● серийный номер передней и задней автосцепки берётся из привязанных к локомотиву устройств во вкладке «Склад»; ● высота автосцепки берётся из вкладки «Паспорт» (передняя умолч. 1040 мм, задняя 1042 мм); ● дата ревизии – указывается с точностью до месяца как ближайшая пройденная дата из таблицы ремонтов (минимальный уровень ремонта – ТР2). 1.2.4.5. Раздел «Устройство контроля параметров движения»: ● наименование, заводской номер, год выпуска берутся из привязанного к локомотиву устройства во вкладке «Склад»; ● дата и место последнего ремонта – берутся как дата ближайшего пройденного ремонта из таблицы ремонтов (минимальный уровень – ТО3); ● дата государственной проверки – дублирует дату последнего ремонта. 1.2.4.6. Раздел «Автоматическая локомотивная сигнализация» – оставляется пустым (место для печати). 1.2.4.7. Раздел «Тормозное оборудование»: ● первая строка формируется из даты ближайшего пройденного ремонта (минимальный уровень – ТО3), наименования «ООО «Ресурс ПРО»», а также юридического названия сервисной организации, закреплённой за локомотивом (субподрядчик); ● далее заполняется текст по образцу (предоставленному Заказчиком); ● таблица в разделе заполняется данными из вкладки «Паспорт»: плотность тормозной магистрали, питательной магистрали, тормозных цилиндров, производительность компрессора, проходимость блокировки. 1.2.4.8. Раздел «Устройство радиосвязи» – оставляется пустым (место для печати). 1.2.4.9. Раздел «Устройства пожаротушения»: ● тип, вид, количество, дата зарядки – заполняются на вкладке «Паспорт»; ● дата перезарядки – рассчитывается как +6 месяцев от даты зарядки. 1.2.4.10. Раздел «Сведения об инвентаре транспортного средства»: ● порядковые номера привязанных тормозных башмаков – из вкладки «Склад», указанных на вкладке «Паспорт»; ● текст «сигнальные принадлежности и инструмент в наличии» – добавляется фиксированной строкой. 1.2.4.11. Раздел с описанием последних ремонтных работ – данные берутся из таблицы ремонтов. 1.2.4.12. Возможность выбора количества подписей при формировании акта: ● вариант на 2 подписи: директор владельца локомотива + начальник технического отдела сервисной организации; ● вариант на 3 подписи: директор владельца локомотива + начальник технического отдела сервисной организации + директор сервисной организации. 1.2.5. ФИО и подписи автоматически подставляются из соответствующих вкладок системы 1.2.6. Сжатие столбцов «8-ми значный номер», «Контрагент», 1.2.7. Интеграция всех добавленных полей и логики в существующую архитектуру Системы (без нарушения работы иных модулей) 1.2.8. Тестирование реализованного функционала (модификации, новой вкладки «Паспорт», вкладки «Склад», формирования акта DOCX) на соответствие требованиям ТЗ 1.2.9. Передача результатов работ с краткой инструкцией по использованию новых функций (в электронном виде).
Москва Фрилансеры

Программисты 1С

договорная
Доработать. Настроить: отчёты 1С. Конфигурация 1С: Управление торговлей. Версия: 8.3. Техническое задание Система: 1С:Управление торговлей (с использованием расширения) ? 1. Общая информация о проекте В системе используется расширение конфигурации, в котором реализована работа с клиентскими заявками. Расширение включает: • создание заявок от клиентов • добавление закупки товаров • тендерную таблицу • таблицу удорожания • дополнительные затраты на закупку Все должно быть четко по формам утвержденным руководством. Основная бизнес-логика уже реализована. Требуется разработка и/или доработка отчетов + их корректная интеграция с текущими процессами. ? 2. Основная задача Необходимо: 1 Проанализировать текущее расширение • разобраться в логике заявок • понять структуру данных • изучить работу предыдущего разработчика (если код читаемый) 2 Реализовать 4 отчёта • либо доработать существующие • либо разработать с нуля (если текущие реализованы некорректно или некачественно) 3 Обеспечить связность данных • отчёты должны корректно подтягивать данные из заявок • все расчёты должны соответствовать бизнес-логике 4 Проверить полный цикл • от создания заявки до финальных расчётов • убедиться, что все точки контроля проходят корректно ? 3. Список отчётов Всего требуется реализовать 4 отчёта: 3.1. Подписанные спецификации • используется для расчёта премий менеджеров (расчет на оснований Таблиц Удорожания, по плановой прибыли) • учитываются только утверждённые / подписанные спецификации в ЭДО ? 3.2. Расчёт процентов (факт) • фактические показатели • расчёт на основе реальных данных по заявкам. Тут сложная система расчетов, расчет производится с первого потраченного рубля по видам затрат, и до последнего полученного рубля от заказчика, с соблюдением сроков по банковским дням. ? 3.3. План-факт анализ • сравнение плановых и фактических показателей • выявление отклонений, при этом, если условия, утвержденные руководством не соблюдены заявкам должен быть присвоен статус: отклонен/ утвержден. ? 3.4. Расчёт премирования (по факту) • итоговый расчёт бонусов менеджеров • базируется на фактических данных ? 4. Источники данных Все отчёты должны использовать данные из: • заявок клиентов • закупок • тендерной таблицы • таблицы удорожания • дополнительных затрат ?? Важно: Для каждого отчёта уже есть инструкции, в которых указано: • какие поля использовать • откуда брать данные • как производить расчёты Задача разработчика — реализовать эти алгоритмы в системе, а не придумывать новые. Отчеты четко по формам. ? 5. Требования к реализации • Использовать расширение, без изменения основной конфигурации • Код должен быть: • читаемым • структурированным • документированным (по ключевым местам) • Отчёты должны: • корректно работать на реальных данных • не ломать текущую логику • учитывать все зависимости ? 6. Проверка и приёмка Работа считается выполненной, если: • ? Все 4 отчёта реализованы • ? Расчёты соответствуют инструкциям • ? Данные корректно подтягиваются из заявок • ? Пройден полный бизнес-процесс: • от создания заявки • до финального расчёта премии ? 7. Ожидаемый результат В итоге система должна: • автоматически формировать все 4 отчёта • корректно рассчитывать показатели • быть полностью синхронизированной с расширением ? 8. Дополнительно (обсуждается на консультации) • оценка текущего кода предыдущего разработчика • целесообразность доработки vs переписывания • сроки реализации • возможность дальнейшей поддержки. Возможен дистанционный формат при определённых условиях.
Москва Фрилансеры