zfc ac0f086821 feat(init): 完成 Phase 1 基础架构搭建
- 完成 T-001A: 前端项目初始化 (Next.js 14 + TypeScript + Tailwind CSS)
- 完成 T-001B: 后端项目初始化 (FastAPI + SQLAlchemy + asyncpg)
- 完成 T-002: 数据库配置 (KolVideo 模型 + 索引 + 测试)
- 完成 T-003: 基础 UI 框架 (Header/Footer 组件 + 品牌色系)
- 完成 T-004: 环境变量配置 (前后端环境变量)

Co-Authored-By: Claude <noreply@anthropic.com>
2026-01-28 14:26:46 +08:00

112 lines
2.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
name: rr
description: 评审 RequirementsDoc.md检查需求文档的完整性、清晰度和可执行性输出结构化评审报告。
---
# Review RequirementsDoc
当用户调用 `/rr` 时,执行以下步骤:
## 1. 读取目标文档
读取 `doc/RequirementsDoc.md` 文件。
如果文件不存在,提示用户:
> RequirementsDoc.md 不存在,请先创建需求文档。
## 2. 评审维度
RequirementsDoc 是文档链的源头,没有上游依赖。重点检查以下维度:
### 2.1 完整性
- [ ] 产品概述是否清晰(定位、目标用户、核心价值)
- [ ] 功能需求是否完整列出
- [ ] 非功能需求是否涵盖(性能、安全、兼容性)
- [ ] 数据规范是否明确(输入输出格式、字段定义)
- [ ] 边界条件和异常情况是否考虑
### 2.2 清晰度
- [ ] 术语定义是否一致,无歧义
- [ ] 用例描述是否具体可理解
- [ ] 优先级是否明确标注
- [ ] 是否有模糊表述("等"、"可能"、"应该"等)
### 2.3 可执行性
- [ ] 需求是否可被验证(有明确的验收标准)
- [ ] 技术约束是否合理
- [ ] 依赖项是否明确
### 2.4 结构规范
- [ ] 文档结构是否清晰(章节划分合理)
- [ ] 格式是否统一(表格、列表、标题层级)
## 3. 生成评审报告
按以下格式输出评审报告:
```markdown
# RequirementsDoc 评审报告
## 概要
| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:mm} |
| 目标文档 | doc/RequirementsDoc.md |
| 问题统计 | {critical} 个严重 / {major} 个一般 / {minor} 个建议 |
## 问题清单
### 严重问题 (Critical)
> 必须修复,否则影响后续文档生成
1. **[位置: 第X节/第Y行]** 问题描述
- 现状:...
- 建议:...
### 一般问题 (Major)
> 建议修复,可提升文档质量
1. **[位置]** 问题描述
- 建议:...
### 改进建议 (Minor)
> 可选优化项
1. **[位置]** 建议内容
## 评审结论
{通过 / 需修改后通过 / 不通过}
### 下一步行动
- [ ] 行动项1
- [ ] 行动项2
```
## 4. 保存报告
将评审报告保存到 `doc/review-RequirementsDoc-claude.md`
如果文件已存在,覆盖原文件(历史版本通过 git 追溯)。
## 5. 输出摘要
向用户展示评审摘要:
- 发现的问题数量(按严重程度分类)
- 评审结论
- 报告文件路径
---
## 注意事项
- 评审时保持客观,聚焦于文档质量而非业务判断
- 问题描述要具体,给出明确的位置引用
- 建议要可操作,避免模糊表述
- 不要修改原文档,只输出评审报告