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）既有未提交改动一并提交
61 lines
3.8 KiB
Markdown
61 lines
3.8 KiB
Markdown
把 `<源码目录/需求输入>` 按目标 `<目标技术栈/需求描述>` 完成分析。
|
||
|
||
> 本提示词覆盖三种场景，按实际情况选一种代入，其余流程（分析维度、向用户确认、生成 spec）通用：
|
||
> 1. **技术栈迁移**：`<源码目录/需求输入>` = 现有源码目录，`<目标技术栈/需求描述>` = 目标技术栈。第一步保持"分析架构"。
|
||
> 2. **全新项目**：`<源码目录/需求输入>` = 需求/设计文档路径，"第一步：分析架构"改为"分析需求与目标功能"。
|
||
> 3. **现有项目重构/迭代开发**：`<源码目录/需求输入>` = 当前项目源码目录本身（技术栈不变），`<目标技术栈/需求描述>` = 本次重构目标或新迭代需求描述。第一步改为"分析现状架构 + 新需求/重构目标"，后续"迁移/实现顺序"理解为"改动/开发顺序"，第二步"技术栈"确认可跳过（已固定），改为确认改动范围与影响面。
|
||
>
|
||
> 占位符取值不要求用户按 key=value 填写：执行者应从用户对需求的自然语言描述（及当前工作目录的实际情况）中自动判断属于哪种场景、自动推断占位符取值；只有关键信息确实缺失（如完全看不出目标是什么）时才反问用户，而不是要求用户先按格式填表。
|
||
|
||
## 你要做的事
|
||
|
||
### 第一步：分析架构
|
||
|
||
1. 通读 `<源码目录>` 下所有源文件，分析 import/依赖关系，画出依赖图
|
||
2. 从依赖图中识别模块边界，按功能拆成独立模块
|
||
3. 分析每个模块的内部结构（核心类、核心函数、对外接口）
|
||
4. 根据依赖关系，从底向上确定迁移/实现顺序
|
||
|
||
**在分析时必须覆盖以下所有维度**（不要遗漏，具体数量和目录名以实际项目为准）：
|
||
|
||
- 源码根目录下的**每一个子目录**都是潜在模块，全部要过一遍
|
||
- 源码根目录下的**每一个顶层源文件**也是潜在模块
|
||
- 源码目录**外部**的功能目录也要纳入分析，包括但不限于：文档、前端/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 中的依赖图精确到"哪个文件的哪个符号被谁依赖"
|
||
|
||
---
|
||
|
||
确认后开始。先分析源码/需求，然后向我提问。
|