huangzd1997
e248b6e43a
- SPA 化：22 个 MPA html 入口与 *-main.ts 合并为 index.html + vue-router（URL 无 .html 后缀）， 页面跳转全部 router-link，/new_web_source/xxx.html 旧路径归一为 /xxx - 任务面板统一：共享 TaskCenterPanel/TaskItemCard/TaskStatCards/HistoryTaskLayer， 16 个工具页右侧统一为统计卡 + 当前任务 + 历史任务弹层（任务ID/开始/结束/状态必展示） - 历史记录支持单条删除 + 批量勾选删除（确认框/全选/失败提示） - Java 7 模块（dedupe/convert/split/productrisk/shopmatch/pricetrack/deletebrand） history 接口补齐任务时间字段（VO+Service，复用 biz_file_task 列） - 图片工作台/API 层（brand/permission/user）既有未提交改动一并提交
3.8 KiB
3.8 KiB
把 <源码目录/需求输入> 按目标 <目标技术栈/需求描述> 完成分析。
本提示词覆盖三种场景，按实际情况选一种代入，其余流程（分析维度、向用户确认、生成 spec）通用：
- 技术栈迁移：
<源码目录/需求输入>= 现有源码目录，<目标技术栈/需求描述>= 目标技术栈。第一步保持"分析架构"。- 全新项目：
<源码目录/需求输入>= 需求/设计文档路径，"第一步：分析架构"改为"分析需求与目标功能"。- 现有项目重构/迭代开发：
<源码目录/需求输入>= 当前项目源码目录本身（技术栈不变），<目标技术栈/需求描述>= 本次重构目标或新迭代需求描述。第一步改为"分析现状架构 + 新需求/重构目标"，后续"迁移/实现顺序"理解为"改动/开发顺序"，第二步"技术栈"确认可跳过（已固定），改为确认改动范围与影响面。占位符取值不要求用户按 key=value 填写：执行者应从用户对需求的自然语言描述（及当前工作目录的实际情况）中自动判断属于哪种场景、自动推断占位符取值；只有关键信息确实缺失（如完全看不出目标是什么）时才反问用户，而不是要求用户先按格式填表。
你要做的事
第一步：分析架构
- 通读
<源码目录>下所有源文件，分析 import/依赖关系，画出依赖图 - 从依赖图中识别模块边界，按功能拆成独立模块
- 分析每个模块的内部结构（核心类、核心函数、对外接口）
- 根据依赖关系，从底向上确定迁移/实现顺序
在分析时必须覆盖以下所有维度（不要遗漏，具体数量和目录名以实际项目为准）：
- 源码根目录下的每一个子目录都是潜在模块，全部要过一遍
- 源码根目录下的每一个顶层源文件也是潜在模块
- 源码目录外部的功能目录也要纳入分析，包括但不限于：文档、前端/UI、插件与扩展、移动端或其他客户端等（视项目实际结构增减）
- 发现新模块时，记录其文件数量、核心职责、被哪些模块依赖
第二步：向用户确认关键决策
分析完架构后，逐一向用户提问确认（每次只问一个问题），包括但不限于：
- 技术栈：分析原实现实际用了哪些库/框架，给出目标技术栈侧的候选及优劣，包括但不限于：核心运行时/SDK、Web 框架、前端框架、CLI 框架、类型系统/Schema 校验、依赖管理与打包、lint 工具、测试框架、E2E 框架、任务队列等（按项目实际需要取舍，不适用的类别跳过）
- 迁移/实现范围：列出分析过程中发现的全部模块清单，逐个询问是否纳入（不要跳过、不要模糊化、不要合并）
- 项目结构：目录结构、命名约定等
不要替用户做决定，给候选 + 优劣分析 + 推荐，让用户选。
第三步：生成 Spec 文件
决策确认后，为每个模块生成独立 spec 文件，输出到 docs/specs/：
docs/specs/
├── 00-overview.md # 总览：技术栈选型、依赖图、模块关系、迁移/实现顺序
├── 01-<模块名>.md
├── 02-<模块名>.md
└── ...
每个 spec 文件必须包含：模块职责、依赖关系、核心接口（原实现 → 目标实现，无原实现则直接描述目标接口）、内部结构、类型映射（如适用）、迁移/实现注意事项。
约束
- 不写代码，只做分析和设计
- spec 是后续 step-2 拆任务的唯一输入
- 每个 spec 文件独立可读
- 每个 spec 只覆盖一个模块（或紧密耦合的一组子模块）
- 00-overview.md 中的依赖图精确到"哪个文件的哪个符号被谁依赖"
确认后开始。先分析源码/需求，然后向我提问。