84 lines
2.8 KiB
Markdown
84 lines
2.8 KiB
Markdown
# 提问模板（团队可直接复制）
|
||
|
||
以下模板用于稳定触发 `frontend-project-standards`，并确保输出符合本规范的交付结构。
|
||
|
||
## 模板 1：新页面开发（标准版）
|
||
|
||
```text
|
||
请按 frontend-project-standards 开发新页面：<页面路径或模块名>。
|
||
要求：
|
||
1) 页面按 container + components + hooks + service 分层；
|
||
2) 接口统一走 src/service/*.ts，禁止在 .vue/hook 里直接 request；
|
||
3) 补齐 loading/error/empty 状态与错误处理；
|
||
4) 不新增宽泛 any；
|
||
5) 命名遵循 naming-conventions.md（历史可保留，新增/改动必须新规范）；
|
||
6) 不要把单一页面过度拆成很多 component，只有复用、复杂交互或清晰业务边界时才拆。
|
||
|
||
交付时请输出：
|
||
- 分层说明
|
||
- hooks 变更
|
||
- API 变更与类型
|
||
- 错误处理覆盖
|
||
- 维护性收益
|
||
- 自检结果
|
||
```
|
||
|
||
## 模板 2：重构大文件（如 mediaContentInfo）
|
||
|
||
```text
|
||
请按 frontend-project-standards 重构：<目标文件路径>。
|
||
当前文件职责混杂，请拆分为多个单一职责 hook，并保持原有行为不回退。
|
||
要求重点：
|
||
1) 分离分页、权限/付费、埋点上报、路由同步等业务域；
|
||
2) 保持 service 层接口边界清晰并补齐类型；
|
||
3) 异步流程加上失败兜底与状态恢复；
|
||
4) 组件拆分保持克制，避免把页面按视觉小块切成大量一次性 component；
|
||
5) 完成后给出迁移说明（旧逻辑 -> 新结构映射）。
|
||
```
|
||
|
||
## 模板 3：新增接口并接入页面
|
||
|
||
```text
|
||
请按 frontend-project-standards 完成接口接入：
|
||
- 新增接口：<接口描述>
|
||
- 接入页面：<页面路径>
|
||
|
||
要求：
|
||
1) 在 src/service/<domain>.ts 新增 typed 方法（params/response）；
|
||
2) 页面只通过 hook 使用 service；
|
||
3) 禁止组件层直接请求；
|
||
4) 输出本次 API contract（字段说明 + 类型）。
|
||
```
|
||
|
||
## 模板 4：问题修复（带规范化）
|
||
|
||
```text
|
||
请按 frontend-project-standards 修复问题：<问题描述>。
|
||
除修复 bug 外，还要完成最小必要规范化：
|
||
1) 抽离与 bug 相关的混杂逻辑到 hook；
|
||
2) 补齐错误处理分支，避免静默失败；
|
||
3) 确保不新增 any，不绕过 service；
|
||
4) 给出回归风险点和验证步骤。
|
||
```
|
||
|
||
## 模板 5：仅做规范审查（不大改代码）
|
||
|
||
```text
|
||
请按 frontend-project-standards 对以下改动做规范审查并给出修正建议：
|
||
<文件路径或 diff 范围>
|
||
|
||
请按严重程度输出：
|
||
1) 违反分层/hook/API/错误处理规范的问题；
|
||
2) 每个问题的最小修复方案；
|
||
3) 可选优化项；
|
||
4) 最后给出 PR 自检清单通过情况。
|
||
```
|
||
|
||
## 建议补充信息（提高一次成功率）
|
||
|
||
- 目标文件路径
|
||
- 是否允许拆文件/重命名
|
||
- 行为兼容要求（必须保持 / 可调整）
|
||
- 优先级（性能、可维护性、上线速度）
|
||
- 是否需要同时补测试
|