Content Site Analizer - План развития.
Отличный выбор, мой друг! Поэтапное внедрение — самый надежный способ развивать приложение. Вот предлагаемый план, разбитый на фазы с учетом приоритетов и зависимостей:
План внедрения новых фишек Content Site Analyzer
Цель: Расширить возможности программы по вводу данных и глубине анализа текста, сохраняя модульность и UX.
Фаза 1: Прямой ввод текста (без файлов) и подготовительная работа
Приоритет: Высокий (базовая функциональность, не зависящая от внешних библиотек для парсинга файлов).
Описание: Добавим возможность напрямую вставлять текст в поле ввода для анализа, минуя URL-загрузку. Это сразу решит проблемы с CORS для прямого анализа.
Шаг 1.1: Обновление ContentExtractor для прямого текста.
Что делаем: Добавляем в ContentExtractor новый статический метод, например, processDirectText(text: string), который будет принимать чистый текст и возвращать его же, имитируя процесс очистки.
Затронутые файлы: services/ContentExtractor.ts
Ожидаемый результат: ProcessingPipeline сможет принимать текст не только из URL, но и напрямую.
Шаг 1.2: Изменение UI на панели управления (Dashboard) для выбора типа ввода.
Что делаем: В разделе "Pipeline Input" добавим третью кнопку "Direct Text" (или "Прямой ввод текста") рядом с "Direct URLs" и "Sitemap".
При выборе "Direct Text" вместо textarea для URL/Sitemap будет отображаться большая textarea для вставки произвольного текста.
Затронутые файлы: App.tsx
Ожидаемый результат: Пользователь сможет переключаться между вводом URL/Sitemap и прямой вставкой текста, при этом соответствующее поле ввода будет меняться.
Шаг 1.3: Адаптация логики запуска анализа в App.tsx.
Что делаем: Метод handleStartProcess будет изменен, чтобы в зависимости от выбранного типа ввода (URL, Sitemap, Direct Text) использовать соответствующий метод из ContentExtractor и правильно передавать данные в runPipeline.
Затронутые файлы: App.tsx
Ожидаемый результат: При нажатии "Start Pipeline" текст из textarea будет отправляться на анализ. Пользователи смогут анализировать любой текст, не беспокоясь о CORS.
Фаза 2: Загрузка TXT-файлов и новые модули анализа (Sentiment, Readability)
Приоритет: Средний (Расширяет ввод файлов, добавляет две важные метрики, активно использует Gemini API для Sentiment).
Описание: Введем возможность загрузки простых текстовых файлов (.txt). Добавим два новых модуля: один для анализа тональности текста (на базе Gemini), другой для оценки его читабельности (алгоритмический).
Шаг 2.1: Реализация загрузки TXT-файлов.
Что делаем: На панели управления, если выбран "Direct Text" (или новый режим "File Upload"), добавим кнопку "Upload .TXT file".
Используем FileReader для чтения содержимого .txt файла на стороне клиента и автоматически заполняем им текстовое поле для прямого ввода.
Затронутые файлы: App.tsx (новый UI-элемент и логика FileReader)
Ожидаемый результат: Пользователи смогут загружать текстовые файлы, и их содержимое будет готово для анализа.
Шаг 2.2: Создание модуля анализа тональности (SentimentModule).
Что делаем:
Определяем новый интерфейс SentimentResult в types.ts.
Создаем новый файл modules/SentimentModule.ts, который будет наследоваться от ContentModule.
Внутри run метода SentimentModule будем отправлять context.cleanText в Gemini API с соответствующим промптом для анализа тональности и получения структурированного JSON-ответа (e.g., overall_sentiment: "positive", "neutral", "negative" и, возможно, confidence_scores).
Затронутые файлы: types.ts, modules/SentimentModule.ts, App.tsx (импорт, добавление в пайплайн), ProcessingPipeline.ts (добавление модуля).
Ожидаемый результат: В результаты анализа каждой страницы будет добавляться информация о тональности.
Шаг 2.3: Создание модуля оценки читабельности (ReadabilityModule).
Что делаем:
Определяем новый интерфейс ReadabilityResult в types.ts (с полями для Flesch-Kincaid, Gunning-Fog и т.д.).
Создаем новый файл modules/ReadabilityModule.ts, который будет наследоваться от ContentModule.
Внутри run метода ReadabilityModule реализуем алгоритмы подсчета читабельности (например, считаем слова, предложения, слоги для индекса Флеша-Кинкейда). Это можно сделать полностью на стороне клиента без вызова Gemini.
Затронутые файлы: types.ts, modules/ReadabilityModule.ts, App.tsx (импорт, добавление в пайплайн), ProcessingPipeline.ts (добавление модуля).
Ожидаемый результат: В результаты анализа каждой страницы будет добавляться информация о её читабельности.
Шаг 2.4: Отображение новых результатов на дашборде.
Что делаем: В App.tsx (в секции viewMode === 'dashboard'), в блоке отображения currentResult, добавим новые карточки или текстовые поля для вывода результатов SentimentModule и ReadabilityModule (например, "Overall Sentiment: Positive", "Readability Score: 75 (Easy)").
Затронутые файлы: App.tsx
Ожидаемый результат: Пользователи видят новые метрики анализа для каждой страницы.
Фаза 3: Расширенная загрузка файлов (DOCX, PDF) и Сравнительный анализ
Приоритет: Средний/Низкий (требует внешних JS-библиотек, сравнительный анализ — более сложный тип отчета).
Описание: Добавим поддержку загрузки DOCX и PDF файлов. Реализуем новый режим "Сравнительный анализ" для сопоставления метрик нескольких страниц.
Шаг 3.1: Реализация загрузки DOCX и PDF файлов.
Что делаем:
На панели управления расширяем функционал загрузки файлов, добавив кнопки "Upload .DOCX file" и "Upload .PDF file".
Интегрируем сторонние JavaScript-библиотеки (например, mammoth.js для DOCX и pdf-parse или аналогичные для PDF) для извлечения чистого текста из этих форматов.
Извлеченный текст будем передавать в ProcessingPipeline так же, как и прямой ввод текста.
Затронутые файлы: index.html (импорт библиотек), App.tsx (новый UI-элемент, логика обработки файлов), services/ContentExtractor.ts (возможно, добавить методы-обертки для парсинга).
Ожидаемый результат: Полная поддержка популярных форматов документов для анализа.
Шаг 3.2: Разработка пользовательского интерфейса для сравнительного анализа.
Что делаем:
На панели управления (viewMode === 'dashboard'), если обработано несколько страниц, добавим опцию "Comparative Analysis" (или "Сравнительный анализ").
При выборе этой опции будет показан новый интерфейс: возможно, таблица, где по строкам будут URL, а по столбцам — ключевые метрики (уникальность, грамматические ошибки, тональность, читабельность), а также, возможно, визуальные элементы (мини-графики, цветовые индикаторы).
Добавим возможность выбора страниц из списка results для включения в сравнение.
Затронутые файлы: App.tsx (новый viewMode или секция, новый компонент ComparativeAnalysisView.tsx), types.ts (возможно, для нового типа данных для таблиц сравнения).
Ожидаемый результат: Интерактивный инструмент для сопоставления эффективности контента на разных страницах.
Шаг 3.3: Реализация логики сравнительного анализа.
Что делаем: Основная логика будет располагаться на фронтенде. Новый компонент ComparativeAnalysisView.tsx будет принимать массив PipelineExecutionResult[] и формировать данные для таблицы/графиков сравнения, вычисляя средние значения, разницу и т.п.
Затронутые файлы: App.tsx, components/ComparativeAnalysisView.tsx (новый файл).
Ожидаемый результат: Генерация агрегированных и сравнительных отчетов по нескольким страницам.
Этот план позволит нам планомерно расширять функциональность, предоставляя пользователям все более мощные инструменты для работы с контентом.
Комментарии
Отправить комментарий