这篇内容适合谁
如果你需要把一堆音频文件（MP3/WAV/FLAC/AAC/OGG）批量转成统一格式，并把响度标准化到目标 LUFS（例如 -14 LUFS），同时输出每个文件的处理报告、失败重试清单、以及可直接部署上线的 Web 工具，那么下面的 Prompts 可以一次性让 AI 产出完整项目。
Prompt 1：生成可部署的“批量转码 + 响度标准化”在线工具（核心需求版）
你是一名资深全栈工程师。请生成一个“音频批量转码与响度标准化”在线工具的完整可运行项目。
【目标】
- 用户上传一个或多个音频文件（MP3/WAV/FLAC/AAC/OGG），或上传 zip（内含多个音频）
- 选择输出格式（mp3/wav/flac/aac/ogg）与参数：采样率、声道、码率（如适用）
- 选择响度标准化：目标值 LUFS（默认 -14）、True Peak（默认 -1.0dBTP）、LRA（可选），并提供“仅测量/测量+处理”两种模式
- 批量处理并生成：
1) 输出文件（按原文件名 + 后缀）
2) 每个文件的处理日志（含开始/结束时间、输入输出编码参数、响度测量值、是否成功、失败原因）
3) 汇总报告 report.json + report.csv
4) 失败重试列表 retry.txt
- 支持并发队列：可配置并发数（默认 2），前端显示队列进度与每个任务状态
【技术栈硬要求】
- 前端：Next.js (App Router) + Type + Tailwind（或简洁 CSS），提供上传、参数表单、进度列表、结果下载
- 后端：Node.js (Express 或 Next.js Route Handlers) 负责 API；处理音频必须使用系统 ffmpeg（不要用图像生成/渲染相关库）
- 任务队列：使用 BullMQ + Redis（或轻量队列实现，但必须支持并发限制、重试、取消）
- 文件存储：本地磁盘临时目录（按 jobId 隔离）；处理完成可打包为 zip 下载
- 安全：限制单文件大小、限制总大小、只允许白名单扩展名；对 zip 做解压炸弹防护（最大文件数/深度/总解压大小）
【输出物必须包含】
- 完整项目源码（分目录给出），并给出文件树
- 可直接运行命令：
- pnpm install / npm install
- docker compose up（如果使用 Redis）
- pnpm dev / pnpm build && pnpm start
- 部署说明：Dockerfile + docker-compose.yml（含 Redis），以及一份“无 Docker 的本地运行”说明
- 至少 6 条自动化测试（可用 Vitest/Jest/Playwright 任一），覆盖：参数校验、队列并发、失败重试、zip 安全限制、报告输出字段完整性、下载打包
- 给出一份 QA checklist（至少 15 条），覆盖：不同格式输入、长音频、含封面/元数据、静音段、极低响度、异常文件、取消任务、并发压测
【交互细节】
- 进度条：显示总体进度与单文件进度（如果无法精确则用阶段进度：上传/排队/处理/打包/完成）
- 结果页面：提供 report.json/report.csv 单独下载按钮，以及“下载全部(zip)”按钮
【实现提示】
- ffmpeg 建议使用 loudnorm 滤镜（EBU R128），并把关键测量值写入 JSON 报告
- 保留元数据：如果输出格式支持，尽量拷贝 data；若不支持，在报告中标注
请直接给出最终代码与说明，不要输出与本任务无关的解释性长文。
Prompt 2：补齐“命令行模式 + API 模式”双通道与可观测性
在上一版项目基础上继续增强：
1) 增加 CLI 模式（同一套核心逻辑复用）：
- 命令：audio-batch --input ./in --output ./out --format mp3 --lufs -14 --concurrency 2
- 支持读取 config.yml
- 输出与 Web 版一致的 report.json/report.csv
2) API 设计：
- POST /api/jobs 创建任务（multipart 上传或 zip），返回 jobId
- GET /api/jobs/{jobId} 查询状态与进度
- GET /api/jobs/{jobId}/download 下载结果 zip
- GET /api/jobs/{jobId}/report 下载 report
3) 可观测性：
- 结构化日志（JSON），字段至少包含 jobId、fileName、stage、durationMs、status
- 关键指标：队列长度、处理成功率、平均耗时；提供 /api/health 与 /api/metrics（Prometheus 格式也可）
4) 可靠性：
- 任务超时与中止
- 断点续传（可选；若实现不了，请明确说明原因并给出替代方案）
请给出修改后的文件差异点清单与新增/修改的完整代码。
Prompt 3：生成测试用例与 QA 清单（加强版）
请为该“音频批量转码与响度标准化”项目补齐测试与 QA：
- 单元测试：参数校验、zip 安全策略、报告字段完整性
- 集成测试：模拟上传 3 个不同格式文件，验证队列并发=2 且最终生成 zip
- 端到端测试：Playwright 走完整流程（上传->设置参数->开始->等待完成->下载->校验 report.csv 有行）
- 负载与边界：大文件、超长音频、损坏文件、重复文件名、包含特殊字符文件名
同时输出一份 QA checklist（不少于 20 条），按“功能/兼容性/性能/安全/可用性/可恢复性”分组。
使用建议与常见坑（不涉及任何出图/图像生成）
部署在服务器时，建议把 ffmpeg 与 Redis 都放进同一个 docker-compose，给临时目录做磁盘配额与定期清理；对于用户上传的 zip，务必限制解压后的文件数与总大小，避免解压炸弹。响度标准化建议默认 -14 LUFS（适合多数平台），但也要允许用户自定义。
