freedakgmail
60 lines
3.2 KiB
Markdown
60 lines
3.2 KiB
Markdown
---
|
||
inclusion: always
|
||
---
|
||
|
||
# AI Coding 工作流规则
|
||
|
||
本规则定义从需求到交付的标准化协作流程。所有涉及"做一个项目 / 实现一个功能"的请求，均遵循以下五个阶段，逐阶段产出文档并在每个关键节点等待用户确认后再推进。
|
||
|
||
## 命名约定
|
||
|
||
- 项目英文缩写记为 `XXX`（如 IPTV、AVCC），由用户提供或与用户确认。
|
||
- 文档统一命名并置于项目根目录（或用户指定目录）：
|
||
- `0-req-XXX.md` — 需求与目标文档
|
||
- `1-prd-XXX.md` — 产品需求文档（PRD）
|
||
- `2-task-XXX.md` — 开发任务文档
|
||
|
||
## 阶段流程
|
||
|
||
### 阶段 1：接收需求与目标
|
||
- 用户给出需求和目标描述，可以是一段文字，也可以是一份 md 文档。
|
||
- 我先完整读取并理解用户的需求与目标；若有歧义或关键信息缺失，先向用户澄清，不臆测。
|
||
|
||
### 阶段 2：生成 `0-req-XXX.md`（需求文档）
|
||
- 基于用户的需求与目标，生成 `0-req-XXX.md`。
|
||
- 内容应包含：引言、术语表、角色定义、功能性需求（采用 EARS 格式：WHEN/IF/WHILE/WHERE/THE...SHALL）、非功能性需求、关键约束与假设。
|
||
- 生成后**必须请用户检查确认**。未确认前不进入下一阶段。
|
||
- 用户提出修改意见时，更新文档并再次请其确认，直到通过。
|
||
|
||
### 阶段 3：生成 `1-prd-XXX.md`（产品需求文档）
|
||
- 仅在 `0-req-XXX.md` 确认通过后进行。
|
||
- 基于需求文档生成 `1-prd-XXX.md`。
|
||
- 内容应包含：产品概述与定位、目标与成功指标、用户画像与核心场景（每个场景标注"痛点解法"）、功能清单与优先级（MoSCoW，并映射回需求编号）、关键流程、角色权限矩阵、版本规划、非功能性要求、依赖与风险。
|
||
- 生成后**必须请用户检查确认**。未确认前不进入下一阶段。
|
||
|
||
### 阶段 4：生成 `2-task-XXX.md`（开发任务文档）
|
||
- 仅在 `1-prd-XXX.md` 确认通过后进行。
|
||
- 生成 `2-task-XXX.md`，用于指导开发，包含详细的工作任务分解。
|
||
- 任务要求：
|
||
- 以可勾选清单（`- [ ]`）组织，编号清晰，粒度可执行可验证。
|
||
- 每个任务标注：目标、对应的需求/PRD 条目、验收标准、依赖关系。
|
||
- 区分优先级与阶段（如 MVP / 二期 / 三期）。
|
||
- **开发过程中根据实际进度持续更新该文档**（勾选完成项、记录变更、补充新任务）。
|
||
- 生成后**必须请用户确认**。
|
||
|
||
### 阶段 5：按任务文档执行开发
|
||
- 仅在 `2-task-XXX.md` 确认通过后开始编码。
|
||
- 严格按确认的任务文档推进开发工作。
|
||
- 每完成一个任务或一组任务：
|
||
- 进行相应的测试（构建、单元测试、必要时集成测试）。
|
||
- 更新 `2-task-XXX.md` 的任务状态与进度记录。
|
||
- 与用户交互、汇报进展、确认下一步。
|
||
- 持续推进，直至完成全部任务。
|
||
|
||
## 通用约束
|
||
|
||
- 每个阶段的产出都要等待用户确认，不得跨阶段抢跑。
|
||
- 文档之间保持可追溯：PRD 功能映射回需求编号，任务映射回需求/PRD 条目。
|
||
- 当上游文档（需求或 PRD）发生变更时，同步更新下游文档，保持一致。
|
||
- 用户的语言即回复与文档的语言（默认中文）。
|