全自动 PDLC 新功能开发（串联 PRD→设计→TDD→实现→评审→发布）
Scanned 5/27/2026
Install via CLI
Skills Directoryopenskills install kanfu-panda/pdlc-skills---
name: pdlc-feature
description: 全自动 PDLC 新功能开发（串联 PRD→设计→TDD→实现→评审→发布）
argument-hint: <功能描述 | 已有 PRD 路径>
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Task
layer: 1
stage: feature
produces:
- docs/01_requirements/prd/<feature-id>-<feature-name>-prd.md
- docs/02_design/**
- backend/services/*/src/**
- frontend/*/src/**
requires: []
next_step: pdlc-ship
terminal_state: feature_done
---
# 全自动 PDLC 新功能开发
<!-- @include templates/prompts/iron-law.md -->
接收功能描述或已有需求文档，全自动走完 PDLC 所有阶段，直到产出可上线状态，中途不暂停、不询问用户。
## 输入解析（阶段一之前执行）
从 `$ARGUMENTS` 中判断输入类型：
1. **检测是否为文件路径**：如果输入匹配以下模式之一，视为文件输入：
- 以 `/`、`./`、`../`、`~` 开头的路径
- 以 `.md`、`.txt`、`.docx`、`.pdf`、`.doc` 结尾
- 包含 `docs/` 或 `requirements/` 路径片段
- 是一个实际存在的文件路径
2. **文件输入**：读取文件内容，从中提取功能描述、用户故事、验收标准。阶段一基于文件内容结构化生成 PRD（保留原始意图，补充缺失部分），而非从零推断。在 PRD 中标注：`<!-- 来源文档: <原始文件路径> -->`
3. **文本输入**：按原有逻辑，从一句话描述自动推断
4. **已有 PRD 路径**：如果输入指向 `docs/01_requirements/prd/` 下已有的 PRD 文件，则**跳过阶段一**，直接从阶段一-B（任务拆解）或阶段二（技术设计）开始
## 执行规则
- **全程自动**：不在任何阶段暂停等待确认，遇到歧义自行做合理假设并在最终报告中说明
- **严格顺序**：必须按阶段一→二→三→四→五→六顺序执行，不得跳过
- **文档先行**：每阶段先产出文档，再进入下一阶段
- **TDD 强制**：代码实现前测试必须已存在且处于失败状态
- **自查通过才结束**：所有测试通过、评审记录完成后才输出最终报告
- **功能ID贯穿全程**：阶段一分配功能ID后，所有后续文档和产出物统一使用该ID
---
## 功能ID分配（阶段一开始前执行）
1. 获取今日日期，格式 `YYYYMMDD`
2. 扫描 `docs/` 目录下所有文件名，匹配模式 `F<今日日期>-(\d{2})`，提取所有序号
3. 取最大序号 +1（两位补零），无匹配则为 `01`
4. 生成功能ID：`F<YYYYMMDD>-<NN>`（如 `F20260326-01`）
5. 从用户描述中提取功能名关键词（英文小写+连字符，如 `user-auth`）
---
## 阶段一：需求分析（PRD）
1. 根据功能描述，自动推断：功能范围、目标用户、核心用户故事（至少 3 条）、验收标准
2. 在 `docs/01_requirements/prd/` 下创建文件，命名格式：`<功能ID>-<功能名>-prd.md`
3. 使用 `templates/prd-template.md` 作为模板
4. **文档顶部必须包含 PDLC 追溯头**：
```
<!-- PDLC-TRACE -->
<!-- 功能ID: F20260326-01 -->
<!-- 功能名称: user-auth -->
<!-- 阶段: 需求 -->
<!-- 前置文档: 无 -->
<!-- 创建时间: 2026-03-26T10:30:00 -->
```
5. 文档须包含：背景、目标、用户故事、功能清单、验收标准、非功能要求、不在范围内的事项
### 🔍 阶段一质量关卡（PRD 自审，必须执行）
<!-- @include templates/prompts/loop-prevention.md -->
PRD 创建后、任务拆解前，立即执行自审：
- **完整性**：检查背景、目标用户、用户故事（≥3条）、功能清单（有优先级）、验收标准（可度量）、非功能需求、不在范围内 — 缺失的章节自动补充
- **一致性**：用户故事与功能清单一一对应，验收标准覆盖所有 P0 功能
- **可操作性**：验收标准无模糊表述，均可转化为测试用例 — 模糊的自动改写为量化指标
- 修复后在 PRD 末尾追加「自审记录」（含审查时间、问题数、修复明细）
- **自审通过才进入阶段一-B**
## 阶段一-B：任务拆解（紧接 PRD 之后自动执行）
1. 扫描 `docs/06_tasks/` 目录，查找是否已存在该功能的任务文件
2. **若不存在**，立即按 `pdlc-task plan` 的逻辑自动执行任务拆解：
- 读取刚创建的 PRD，提取功能清单与验收标准
- 为每条功能清单项生成任务条目，分配任务ID（格式：`T<YYYYMMDD>-<NN>-<type>`）
- 创建任务文件：`docs/06_tasks/<功能ID>-<功能名>-tasks.md`
- 格式参考 `pdlc-task plan` 的输出规范（每条任务含 ID、标题、类型、状态 `⬜`、前置依赖）
3. 在阶段报告中输出任务文件路径和任务总数
## 阶段一-C：PRD 文档评审（紧接任务拆解后自动执行）
<!-- @include templates/prompts/loop-prevention.md -->
1. 按 `/pdlc-review` 的文档评审段落逻辑，对 PRD 执行正式文档评审（聚焦**格式规范性、模板符合度、交叉引用**）
2. 对照 `templates/prd-template.md` 检查格式规范性
3. 发现问题直接修复原 PRD 文档，修复后仅复查一次，不递归
4. 在 `docs/07_reviews/doc/` 下创建评审记录：`<功能ID>-<功能名>-prd-doc-review.md`
5. 评审通过后进入阶段二
---
## 阶段二：技术设计
根据 PRD 自动判断需要哪些设计文档，按需创建（不需要的跳过）：
**API 设计**（如涉及接口变更）：
- 路径：`docs/02_design/api/<功能ID>-<功能名>-api.md`
- 模板：`templates/api-design-template.md`
- 必须包含：接口列表、请求/响应结构、错误码
**数据库设计**（如涉及数据存储）：
- 路径：`docs/02_design/database/<功能ID>-<功能名>-db.md`
- 模板：`templates/db-design-template.md`
- 必须包含：ER 图、表结构、索引设计、迁移 DDL
**架构设计**（如涉及新服务或重大架构变更）：
- 路径：`docs/02_design/architecture/<功能ID>-<功能名>-arch.md`
- 模板：`templates/arch-design-template.md`
**所有设计文档顶部必须包含 PDLC 追溯头**：
```
<!-- PDLC-TRACE -->
<!-- 功能ID: F20260326-01 -->
<!-- 功能名称: user-auth -->
<!-- 阶段: 设计 -->
<!-- 前置文档: docs/01_requirements/prd/F20260326-01-user-auth-prd.md -->
```
### 🔍 阶段二质量关卡（设计文档自审，必须执行）
每份设计文档创建后立即执行自审：
- **PRD 一致性**：PRD 中每条 P0/P1 功能是否有对应设计覆盖 — 遗漏的自动补充
- **API 检查**：URL 规范、请求/响应完整、统一响应格式、分页参数、鉴权说明
- **DB 检查**：主键、索引、审计字段（created_at/updated_at）、迁移 DDL
- **跨文档一致性**：API 响应字段与 DB 字段对应，查询参数有索引支撑
- 修复后在设计文档末尾追加「自审记录」
- 在 `docs/07_reviews/doc/` 下创建设计评审记录：`<功能ID>-<功能名>-design-doc-review.md`
- 修复后仅复查一次，不递归；复查仍有问题则记录到评审报告
- **自审通过才进入阶段三**
---
## 阶段三：测试先行（TDD 红灯）
1. 在 `docs/04_testing/unit-tests/` 下创建测试计划：`<功能ID>-<功能名>-test-plan.md`
- **文档顶部包含 PDLC 追溯头**（阶段: 测试，前置文档指向设计文档）
2. 在对应服务/应用的测试目录下编写测试代码：
- 后端 Java：`backend/services/<服务名>/src/test/`
- 前端：`frontend/web/<应用名>/src/__tests__/`
3. 测试必须覆盖：正常流程、边界条件、异常场景
4. 单元测试覆盖率目标：>= 80%
5. 运行测试，**确认测试处于失败状态（红灯）**，记录失败输出
6. 同步编写 E2E 测试骨架（可暂时 skip，实现阶段补全）：
- 路径：`docs/04_testing/e2e-tests/<功能ID>-<功能名>-e2e.md`
### 🔍 阶段三质量关卡（测试计划自审，必须执行）
测试代码编写完成、运行前执行自审：
- **验收标准覆盖度**：PRD 每条验收标准至少有一个对应测试用例 — 缺失的自动补充
- **场景完备性**：边界条件（空值/最大值/零值）、异常场景（401/403/404/409）、幂等性
- **测试质量**：方法命名是否描述场景、是否单一断言、测试数据是否有意义
- 修复后在测试计划末尾追加「自审记录」（含验收标准覆盖数、API 接口覆盖数）
- **自审通过才运行测试确认红灯**
---
## 阶段四：编码实现（绿灯）
1. 阅读 `docs/00_standards/coding/` 目录确认编码规范
2. 编写最少量的实现代码使所有单元测试通过
3. 实现过程中不偏离设计文档；若发现设计遗漏，自行补充设计文档后继续
4. 运行测试，**确认全部通过（绿灯）**
5. 在测试通过前提下，重构优化代码结构（不改变行为）
6. 补全 E2E 测试代码并运行验证
### 🔍 阶段四质量关卡（实现自检，必须执行）
代码实现完成、测试全部通过后，执行快速自检：
- **设计偏离检查**：对照设计文档，确认没有遗漏的接口或功能点
- **测试覆盖验证**：确认单元测试覆盖率 >= 80%，不达标则补充测试
- **编码规范快检**：快速运行 lint check，有问题立即 lint fix
- 自检通过才进入阶段五正式评审
---
## 阶段五：自查评审（代码评审 + 自动修复）
<!-- @include templates/prompts/loop-prevention.md -->
按 `/pdlc-review` 增强版逻辑执行全面评审，**发现问题直接修复**：
1. **设计一致性检查**：对照设计文档逐项确认实现完整性
- API URL/方法/参数是否与设计一致
- DB 表结构/字段是否与设计一致
- 响应格式是否统一 — 不一致的直接修复代码
2. **验收标准验证**：对照 PRD 逐条确认验收标准是否满足，未满足的补充实现
3. **代码质量检查与修复**：
- 按 `pdlc-lint check` 运行 lint 工具，存在问题则 `pdlc-lint fix` 自动修复
- 检查命名规范 — 不规范的直接重命名
- 检查错误处理 — 缺失的直接补充
- 检查日志 — 关键操作缺日志的直接添加
4. **安全检查与修复**：
- SQL 注入：字符串拼接 SQL → 自动改写为参数化查询
- XSS：未转义输出 → 自动添加转义
- 权限控制：缺鉴权的接口 → 标记为需人工处理
- 敏感数据：日志中打印敏感字段 → 自动脱敏
5. **性能检查**：N+1 查询、缺失分页、缺失索引 — 能修的直接修复
6. **修复后验证**：重新运行全部测试，确认修复未引入新问题
- 测试失败 → 回滚修复，标记为需人工处理
7. **生成评审报告**：在 `docs/07_reviews/code/` 下创建评审记录：`<功能ID>-<功能名>-review.md`
- 包含 PDLC 追溯头（阶段: 评审，含创建时间）
- 包含：评审总结（问题总数/自动修复数/需人工处理数）、自动修复记录表、需人工处理表、检查项结论
8. 更新对应服务的 `CHANGELOG.md`，在 `[未发布]` 下新增 feat 条目
## 阶段六：最终报告
> ⚠️ **文件落盘验证**：输出最终报告前，必须逐一确认以下文件均已作为实际文件创建到磁盘（不可仅在对话中显示）：
| 产出物 | 路径 | 验证方式 |
|--------|------|---------|
| PRD 文档 | `docs/01_requirements/prd/<功能ID>-*-prd.md` | 确认文件存在 |
| 任务清单 | `docs/06_tasks/<功能ID>-*-tasks.md` | 确认文件存在 |
| PRD 评审记录 | `docs/07_reviews/doc/<功能ID>-*-prd-doc-review.md` | 确认文件存在 |
| 设计文档 | `docs/02_design/` 下对应目录 | 确认文件存在 |
| 设计评审记录 | `docs/07_reviews/doc/<功能ID>-*-design-doc-review.md` | 确认文件存在 |
| 测试计划 | `docs/04_testing/unit-tests/<功能ID>-*-test-plan.md` | 确认文件存在 |
| 测试代码 | 对应服务测试目录 | 确认文件存在 |
| 代码评审记录 | `docs/07_reviews/code/<功能ID>-*-review.md` | 确认文件存在 |
**如有文件缺失，立即补创建，不可跳过。**
所有文件确认到位后，输出一份结构化的完成报告，格式如下：
```
## PDLC 完成报告：<功能名>（<功能ID>）
### 产出物清单
| 类型 | 文件路径 |
|------|----------|
| PRD | docs/01_requirements/prd/<功能ID>-... |
| API 设计 | docs/02_design/api/<功能ID>-... |
| 数据库设计 | docs/02_design/database/<功能ID>-... |
| 测试计划 | docs/04_testing/unit-tests/<功能ID>-... |
| 评审记录 | docs/07_reviews/code/<功能ID>-... |
### 测试结果
- 单元测试：X 个通过 / 0 个失败
- E2E 测试：X 个通过 / 0 个失败
- 覆盖率：XX%
### 任务完成情况
- 任务文件：`docs/06_tasks/<功能ID>-<功能名>-tasks.md`
- 总任务数：X 完成：X 进行中：X 未开始：X
### 验收标准确认
- [x] 验收标准 1
- [x] 验收标准 2
### 假设与决策说明
（记录执行过程中自行做出的关键假设）
### 上线前待办
（如有需要人工处理的事项，如数据库迁移、环境变量配置等）
```
---
## 要求
<!-- @include templates/prompts/output-language.md -->
- 文件名中的功能名使用英文小写+连字符，如 `user-login`
- 日期使用执行当天的实际日期，格式 YYYYMMDD
- 不引入不必要的依赖
- 不过度设计，实现够用即可
功能描述: $ARGUMENTS
<!-- @include templates/prompts/state-update.md -->
<!-- @include templates/prompts/handoff.md -->
No comments yet. Be the first to comment!
