批处理 Jupyter Notebook 依赖提取与环境重建脚本生成 AI 提示词 (Prompts)

适用场景

你手里有很多 Jupyter Notebook（.ipynb），来自不同作者与不同时间点：有人用 pip，有人用 conda；有人在 notebook 里临时 pip install；有人导入了本地模块；结果就是“能跑但不可复现”。本篇给你一条可直接丢给 AI 的 Prompt：让 AI 生成一个可部署的在线工具，上传 ipynb 后自动做依赖提取、环境重建脚本生成、风险审计与可复现性检查。

交付物清单

该 Prompt 要求 AI 输出：完整项目源码（前后端）、清晰文件树、可运行命令、Docker/云端部署说明、以及测试用例或 QA checklist。工具目标是“可构建/可部署/可验收”，不是演示脚本。

功能范围

单一类别：批处理。工具只聚焦 ipynb 的依赖与环境复现，不混入图片生成、渲染图、海报或任何出图导向。允许做内容检查、预览、转换、提取与报告导出。

Prompt 使用方式

把下面灰底 Prompt 原样复制到你的 AI（建议选择擅长代码与工程化输出的模型）。按 Prompt 要求，在最终答案里一次性给出可直接运行的项目。

Prompt（复制到 AI）

你是资深全栈工程师与构建系统专家。请为我生成一个【可部署的在线工具】完整项目，工具类别：批处理。

工具名称：Notebook 依赖提取与环境重建工作台
目标用户：需要把多个 .ipynb 变成“可复现、可审计、可移交”的项目环境的人。

一、输入与输出（硬约束）
- 输入：用户在网页上传 1 个或多个 .ipynb 文件（最大 50MB/文件，可配置），可选再上传一个 zip（可选，包含可能的本地 python 包/模块）。
- 输出（必须全部提供，且可下载）：
  1) requirements.txt（pip）
  2) environment.yml（conda，可选但建议生成）
  3) uv.lock 或 poetry.lock（任选其一，建议 uv.lock；若生成 lock，请同时给出 pyproject.toml）
  4) Dockerfile + docker-compose.yml（可一键启动）
  5) 一份审计报告 report.json + report.md（包含：依赖列表、版本来源、风险提示、不可复现点、建议修复）
  6) 一键重建脚本： s/rebuild.sh 与  s/rebuild.ps1

二、核心功能（必须实现）
1) 依赖提取（多策略合并）
- 解析 ipynb 的 code cells，静态分析 import 语句（含 from x import y、import x as y），并识别常见别名。
- 解析 notebook 中出现的 pip/conda 安装命令（如 !pip install、%pip install、!conda install、mamba install），提取包名与版本约束。
- 识别可能的本地模块导入（相对导入、同名文件夹、用户上传 zip 中的包），将其标记为“本地依赖”。
- 生成一个统一依赖清单：合并、去重、冲突检测（同包不同约束），并按“必须/可选/疑似”分级。

2) 版本解析与补全
- 若用户未给版本约束：给出合理默认策略（例如：优先使用最新稳定版，但对 numpy/pandas/torch 等可设置上限策略），并把策略写入报告。
- 提供一个“离线可复现”模式：允许用户粘贴 pip freeze 或 conda list（文本输入），用于覆盖/校准版本。

3) 可复现性检查
- 检查：是否存在未声明的系统依赖（如 ffmpeg、poppler、tesseract、libgl、cuda 等）并给出 Docker 安装建议。
- 检查：是否存在从本地路径读取数据/模型的代码（如 /Users/...、C:\...、/mnt/...），把这些路径收集到报告里。
- 检查：是否存在需要密钥/环境变量（如 OPENAI_API_KEY、AWS_...），将其列为“需要配置项”。

4) 安全与合规提示
- 依赖漏洞提示：集成一个可选的 npm/pip 安全扫描（本地规则即可，不强制联网；提供 stub 接口，后续可接入真实漏洞库）。
- 命令注入与危险操作提示：在报告中标注 notebook 里可能存在的危险 shell 命令（rm、curl | sh、chmod 777 等）。

5) Web UI 与交互
- 页面：上传区、配置区（Python 版本、是否生成 conda/lock、最大并发、报告详略）、任务列表、结果下载。
- 每个任务显示状态：排队/处理中/成功/失败，失败要有可读错误信息。

三、技术选型（建议但可替换，需说明理由）
- 后端：Node.js + Type （或 Python FastAPI，但二选一并给出完整工程）。
- 任务队列：BullMQ/Redis（可选）；若不用 Redis，使用本地队列也可以，但要说明并保证并发安全。
- 前端：React + Vite + Type （简洁 UI）。
- 解析：使用成熟库读取 ipynb（JSON），静态分析 Python 可用 tree-sitter 或 python AST（若后端是 Node，可用 tree-sitter-python；若后端是 Python，用 ast 模块）。

四、项目输出格式（硬约束）
- 先给出项目文件树（tree）。
- 再逐文件给出完整代码（不要省略）。
- 给出本地运行命令：安装、开发启动、生产构建、运行。
- 给出 Docker 运行命令。
- 给出部署说明：最少包含 Nginx 反代/HTTPS、以及云平台（例如 Docker 部署到一台 VPS）的步骤。

五、测试与验收（硬约束）
- 提供最少 6 条自动化测试（单元或集成均可），覆盖：import 解析、安装命令解析、依赖合并冲突、报告生成、文件下载、错误处理。
- 提供 QA checklist（至少 15 条），涵盖：上传边界、并发、失败重试、跨平台脚本、输出可用性、报告字段完整性。

六、细节要求（强约束）
- 所有输出必须可直接复制落地运行；不要写“略”。
- 任何需要用户自填的配置（端口、Redis、Python 版本等）要给默认值。
- 不要引导生成图片/渲染图/海报/插画，不要提 Midjourney/Stable Diffusion。

请开始输出完整项目。