Ридми. Делал все сам, но дай бог поможет
This commit is contained in:
anker-na-20
@@ -0,0 +1,244 @@
|
|||||||
|
# Вот промпт, который можно уложить в кодекс:
|
||||||
|
Ты — опытный senior full‑stack архитектор и разработчик.
|
||||||
|
Твоя задача — спроектировать и сгенерировать ПОЛНЫЙ каркас проекта
|
||||||
|
(backend + frontend + инфраструктура), который будет использоваться
|
||||||
|
для конвейера PDF→структурированный JSON→DOCX по шаблонам Word.
|
||||||
|
|
||||||
|
ВАЖНО:
|
||||||
|
- Нужен готовый проект с понятной файловой структурой, рабочим билдом
|
||||||
|
и запуском в Docker.
|
||||||
|
- Нужна поддержка git: .gitignore, базовые скрипты, README.
|
||||||
|
- Шаблоны Word создавать НЕ нужно. Нужно предусмотреть каталог,
|
||||||
|
конфигурацию и код для их загрузки/использования, чтобы я мог сам
|
||||||
|
положить .docx и сразу ими пользоваться.
|
||||||
|
- Проект должен быть написан максимально понятно и аккуратно, с
|
||||||
|
комментариями в ключевых местах.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Технологический стек (можешь предлагать улучшения, но по умолчанию так):
|
||||||
|
|
||||||
|
### Общие требования
|
||||||
|
- Ориентируемся на развёртывание в Linux‑среде, запуск через docker-compose.
|
||||||
|
- Backend и frontend запускаются в отдельных контейнерах.
|
||||||
|
- В перспективе backend будет общаться с локальной LLM (Qwen) через
|
||||||
|
OpenAI‑совместимый API на внешнем сервере (например, Ollama),
|
||||||
|
но до развёртывания этой модели мы будем ходить в облачную LLM.
|
||||||
|
- Поэтому нужна конфигурируемая переменная окружения
|
||||||
|
`LLM_BASE_URL` и `LLM_API_KEY`, а логика работы с LLM должна быть
|
||||||
|
изолирована в отдельном слое‑адаптере.
|
||||||
|
|
||||||
|
### Backend
|
||||||
|
- Язык: TypeScript.
|
||||||
|
- Фреймворк: Node.js + NestJS ИЛИ Express + modular architecture
|
||||||
|
(если считаешь, что Nest избыточен, обоснуй в комментариях README).
|
||||||
|
- HTTP API (REST), без GraphQL.
|
||||||
|
- Работа с файлами: загружать PDF, временно хранить их на диске,
|
||||||
|
отдавать готовый DOCX, хранить метаданные задач в БД.
|
||||||
|
- База данных: PostgreSQL (через Prisma или TypeORM — выбери один и
|
||||||
|
задокументируй выбор).
|
||||||
|
- Логирование: простой логгер (winston/pino) с выводом в консоль.
|
||||||
|
- Конфигурация: через .env (используй библиотеку наподобие
|
||||||
|
dotenv / @nestjs/config).
|
||||||
|
- Поддержка CORS для фронтенда.
|
||||||
|
|
||||||
|
### Frontend
|
||||||
|
- Язык: TypeScript.
|
||||||
|
- Фреймворк: React + Vite или Next.js (на твой выбор, но без SSR‑сложностей,
|
||||||
|
достаточно SPA, если берёшь Vite/React).
|
||||||
|
- UI‑задача:
|
||||||
|
- Страница с формой загрузки PDF:
|
||||||
|
- поле выбора файла;
|
||||||
|
- выбор типа документа/шаблона (просто select с dummy‑значениями
|
||||||
|
вроде "ГОСТ‑1", "ГОСТ‑2" — пока они только передаются на backend);
|
||||||
|
- кнопка «Отправить на обработку».
|
||||||
|
- Отображение списка задач:
|
||||||
|
- идентификатор задачи;
|
||||||
|
- имя исходного файла;
|
||||||
|
- статус (QUEUED / PROCESSING / DONE / ERROR);
|
||||||
|
- ссылка для скачивания результата, если есть DOCX.
|
||||||
|
- Простая страница деталей задачи (по id):
|
||||||
|
- метаданные;
|
||||||
|
- простой лог/ошибки, если были.
|
||||||
|
- Верстка может быть минимальной, без сложного дизайна, главное —
|
||||||
|
чистая архитектура и удобство доработки.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Бизнес‑логика, которую нужно учесть
|
||||||
|
|
||||||
|
Цель системы: офисные сотрудники загружают PDF‑файл с технической документацией (ТЗ по ГОСТу и т.п.).
|
||||||
|
Backend:
|
||||||
|
|
||||||
|
1. Принимает PDF и создаёт “задачу обработки” в БД.
|
||||||
|
2. Сохраняет PDF в файловой системе (например, каталог `storage/input`).
|
||||||
|
3. Отправляет PDF в отдельный n8n‑workflow ИЛИ обрабатывает локально
|
||||||
|
цепочкой шагов (сейчас — просто заглушка, позже я подвяжу n8n).
|
||||||
|
4. В перспективе pipeline будет такой:
|
||||||
|
- PDF → парсер (вытаскиваем текст/Markdown);
|
||||||
|
- Markdown → LLM (Qwen) → унифицированный JSON структуры документа;
|
||||||
|
- JSON + Word‑шаблон → генератор DOCX;
|
||||||
|
- результат сохраняем как DOCX в `storage/output`.
|
||||||
|
Но в рамках этого задания тебе нужно:
|
||||||
|
- СДЕЛАТЬ кодовые заготовки для этих шагов (интерфейсы, классы,
|
||||||
|
абстракции, контроллеры, DTO, сервисы),
|
||||||
|
- Реализовать «заглушки» (например, вместо реального вызова LLM и
|
||||||
|
генератора DOCX возвращать фиктивный JSON/файл),
|
||||||
|
- Чётко показать точки интеграции, где я потом подключу реальную
|
||||||
|
обработку.
|
||||||
|
|
||||||
|
5. Backend должен предоставлять API:
|
||||||
|
- `POST /api/jobs` — загрузка PDF:
|
||||||
|
- multipart/form-data, поле `file`, опционально `templateType`.
|
||||||
|
- возвращает объект задачи `{ id, status, fileName, createdAt }`.
|
||||||
|
- `GET /api/jobs` — список задач (с пагинацией, query‑параметры).
|
||||||
|
- `GET /api/jobs/:id` — детальная информация о задаче, включая
|
||||||
|
путь/URL к результату, лог ошибок.
|
||||||
|
- `GET /api/jobs/:id/result` — скачивание готового DOCX.
|
||||||
|
- `GET /api/templates` — список доступных Word‑шаблонов (backend
|
||||||
|
должен сканировать папку `templates/` и возвращать названия файлов /
|
||||||
|
метаданные; сами .docx я положу вручную).
|
||||||
|
- `POST /api/templates/reload` — принудительное перечитывание списка
|
||||||
|
шаблонов (на будущее).
|
||||||
|
|
||||||
|
6. Статусы задач:
|
||||||
|
- QUEUED, PROCESSING, DONE, ERROR.
|
||||||
|
- Нужен enum и таблица/модель `Job` с полями:
|
||||||
|
- id (uuid),
|
||||||
|
- originalFileName,
|
||||||
|
- storedFilePath,
|
||||||
|
- resultFilePath (nullable),
|
||||||
|
- status,
|
||||||
|
- errorMessage (nullable),
|
||||||
|
- templateType (строка),
|
||||||
|
- createdAt, updatedAt.
|
||||||
|
|
||||||
|
7. Адаптер к LLM:
|
||||||
|
- Нужен отдельный сервис/модуль (например, `llm/llmClient.ts`),
|
||||||
|
который:
|
||||||
|
- берёт на вход текст/markdown и возвращает JSON структуры
|
||||||
|
документа (пока можно вернуть фиктивный JSON).
|
||||||
|
- конфигурируется через переменные окружения:
|
||||||
|
- `LLM_BASE_URL` — URL OpenAI‑совместимого API
|
||||||
|
(в будущем это будет адрес локального Qwen на сервере Ollama).
|
||||||
|
- `LLM_API_KEY` — токен для облачной модели (сейчас).
|
||||||
|
- `LLM_MODEL` — имя модели (например, `gpt-4.1-mini` или другое).
|
||||||
|
- Весь остальной код НЕ должен знать детали формата API конкретного
|
||||||
|
поставщика, только использовать этот клиент/адаптер.
|
||||||
|
|
||||||
|
8. Адаптер генерации DOCX:
|
||||||
|
- Отдельный сервис (например, `docx/docxGenerator.ts`), который:
|
||||||
|
- принимает JSON структуры и имя шаблона;
|
||||||
|
- находит шаблон в папке `templates/` (но сам шаблон не создаёт);
|
||||||
|
- создаёт DOCX в `storage/output/<jobId>.docx`.
|
||||||
|
- На этом этапе достаточно сделать заглушку:
|
||||||
|
- например, создать простой текстовый DOCX через любую
|
||||||
|
библиотеку (или даже временно создавать `.txt` файл, но
|
||||||
|
оставить интерфейс и структуру под DOCX).
|
||||||
|
- Важно: предусмотреть удобное место, куда я положу свои .docx
|
||||||
|
шаблоны, и в README описать, как они должны называться
|
||||||
|
и как выбираются.
|
||||||
|
|
||||||
|
***
|
||||||
|
|
||||||
|
## Инфраструктура и структура проекта
|
||||||
|
|
||||||
|
Пожалуйста, СГЕНЕРИРУЙ и ОПИШИ:
|
||||||
|
|
||||||
|
1. Общая структура репозитория (monorepo или два отдельных проекта — opиши выбор).
|
||||||
|
Пример, если это monorepo:
|
||||||
|
- `backend/`
|
||||||
|
- `frontend/`
|
||||||
|
- `docker/` (общие конфиги)
|
||||||
|
- `templates/` (каталог для Word‑шаблонов)
|
||||||
|
- `storage/input/` (исходные PDF, .gitignore внутри)
|
||||||
|
- `storage/output/` (результирующие DOCX, .gitignore внутри)
|
||||||
|
- `README.md`
|
||||||
|
- `.gitignore`
|
||||||
|
- `docker-compose.yml`
|
||||||
|
|
||||||
|
2. Файловая структура backend:
|
||||||
|
- `src/main.ts`, `src/app.module.ts` (для Nest) или аналог для Express.
|
||||||
|
- Модуль/пакет `jobs`:
|
||||||
|
- контроллер для API задач;
|
||||||
|
- сервис работы с задачами;
|
||||||
|
- DTO и entity/модель для БД.
|
||||||
|
- Модуль/пакет `files`:
|
||||||
|
- загрузка файлов;
|
||||||
|
- валидация типов;
|
||||||
|
- работа с путями хранения.
|
||||||
|
- Модуль/пакет `llm`:
|
||||||
|
- клиент для LLM;
|
||||||
|
- интерфейсы типов ответов.
|
||||||
|
- Модуль/пакет `docx`:
|
||||||
|
- генератор DOCX;
|
||||||
|
- адаптер к будущему шаблонизатору Docx (docxtemplater/Pandoc/и т.п.).
|
||||||
|
- Общий модуль `config` для работы с .env.
|
||||||
|
- Конфиг Prisma/TypeORM и миграции для таблицы `Job`.
|
||||||
|
|
||||||
|
3. Файловая структура frontend:
|
||||||
|
- Точка входа и маршрут `/` с формой загрузки и списком задач.
|
||||||
|
- Компоненты:
|
||||||
|
- `UploadForm`
|
||||||
|
- `JobsList`
|
||||||
|
- `JobDetails`
|
||||||
|
- Сервис для общения с backend (например, `api/client.ts`), где:
|
||||||
|
- базовый URL API берётся из env (`VITE_API_BASE_URL` и т.п.).
|
||||||
|
- Простая система типов TypeScript для сущностей Job и Template.
|
||||||
|
|
||||||
|
4. .gitignore:
|
||||||
|
- Исключить:
|
||||||
|
- node_modules,
|
||||||
|
- build‑артефакты,
|
||||||
|
- .env и другие секреты,
|
||||||
|
- `storage/input`, `storage/output`,
|
||||||
|
- временные файлы IDE.
|
||||||
|
|
||||||
|
5. Docker:
|
||||||
|
- `Dockerfile` для backend.
|
||||||
|
- `Dockerfile` для frontend.
|
||||||
|
- `docker-compose.yml`, который поднимает:
|
||||||
|
- `backend` (с зависимостью от `db`);
|
||||||
|
- `frontend`;
|
||||||
|
- `db` (PostgreSQL);
|
||||||
|
- Переменные окружения для docker‑compose с примером (файл `.env.example`).
|
||||||
|
|
||||||
|
6. README:
|
||||||
|
- Пошаговая инструкция:
|
||||||
|
- как установить зависимости;
|
||||||
|
- как запустить проект локально без Docker;
|
||||||
|
- как запустить через `docker-compose up`;
|
||||||
|
- как добавить новый Word‑шаблон (куда положить .docx, как он
|
||||||
|
подхватывается API `/api/templates`).
|
||||||
|
- Пример запроса к API загрузки файла (curl).
|
||||||
|
- Краткое объяснение архитектуры:
|
||||||
|
- где слой LLM‑адаптера;
|
||||||
|
- где слой генерации DOCX;
|
||||||
|
- как в будущем подключить n8n и локальную Qwen.
|
||||||
|
|
||||||
|
***
|
||||||
|
|
||||||
|
## Формат ответа
|
||||||
|
|
||||||
|
Сформируй ответ в три части:
|
||||||
|
|
||||||
|
1. Краткое текстовое объяснение архитектуры (2–3 абзаца).
|
||||||
|
2. Подробная структура файлов/папок в формате дерева с комментариями.
|
||||||
|
3. Основные файлы кода как СНИППЕТЫ:
|
||||||
|
- `docker-compose.yml`;
|
||||||
|
- `backend/Dockerfile`, `frontend/Dockerfile`;
|
||||||
|
- key‑файлы backend (main, контроллер задач, модель Job, LLM‑клиент,
|
||||||
|
заглушка генератора DOCX);
|
||||||
|
- key‑файлы frontend (главная страница, клиент API);
|
||||||
|
- `.gitignore`;
|
||||||
|
- `.env.example`;
|
||||||
|
- выдержки из README с инструкциями.
|
||||||
|
|
||||||
|
Код можно не доводить до идеального продакшена, но он должен быть:
|
||||||
|
- компилируемым,
|
||||||
|
- структурированным,
|
||||||
|
- с понятными комментариями, что и где доработать, чтобы подключить
|
||||||
|
реальную LLM и реальный генератор DOCX по шаблонам Word.
|
||||||
|
|
||||||
|
Не упрощай задачу: сгенерируй именно полноценный каркас проекта,
|
||||||
|
как если бы ты начинал реальный коммерческий проект под эту задачу.
|
||||||
Reference in New Issue
Block a user