# full-cycle-dev-test

**Repository Path**: Yan_dy/full-cycle-dev-test

## Basic Information

- **Project Name**: full-cycle-dev-test
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-05-11
- **Last Updated**: 2026-05-12

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

<div align="center">

# full-cycle-dev-test

**面向 Codex 的软件项目全流程开发与灰盒测试 Skill**

从一个想法开始，按阶段完成需求、选型、计划、开发、自检、灰盒测试、缺陷修复和最终交付。

`需求澄清` · `技术选型` · `开发计划` · `代码实现` · `灰盒测试` · `测试报告` · `回归验证`

![workflow](https://img.shields.io/badge/workflow-staged%20delivery-blue)
![testing](https://img.shields.io/badge/testing-gray--box-green)
![reports](https://img.shields.io/badge/output-test%20reports-orange)

</div>

---

## 📌 快速理解

`full-cycle-dev-test` 不是一个简单的“让 AI 写代码”的提示词集合，而是一套项目交付工作流。

它解决的问题是：

| 常见问题 | 这个 skill 的做法 |
| --- | --- |
| 只有一个想法，不知道怎么落成项目 | 先澄清需求，再生成需求文档和开发计划 |
| AI 直接改代码，容易偏离目标 | 开发必须跟随已确认的需求和计划 |
| 做完功能但没有测试依据 | 引入开发者自检、灰盒测试和测试报告 |
| 缺陷修复后不知道有没有影响其他功能 | 要求做 focused regression，也就是针对性回归测试 |
| 聊天里输出太多、重复扫描项目 | 每阶段只读取必要上下文，长报告按用户选择写入文件 |

一句话概括：

> 让 Codex 像一个谨慎的软件开发与测试代理，而不是只会一次性生成代码。

## 🎯 适用场景

这个 skill 适合下面几类任务：

| 场景 | 示例 |
| --- | --- |
| 课程设计 / 毕设 / 实训项目 | 学生管理系统、电影收藏系统、图书管理系统 |
| 后台管理系统 | Spring Boot、Django、FastAPI、NestJS 项目 |
| 从 0 到 1 的小型应用 | 从想法开始补齐需求、选型、计划和实现 |
| 已有项目继续开发 | 先理解现有结构，再按阶段修改和验证 |
| 需要测试报告的项目 | 生成灰盒测试计划、执行记录和测试报告 |

## 🧭 工作流总览

```text
想法 / 现有项目
      │
      ▼
需求澄清 ──> 技术选型 ──> 需求文档 ──> 开发计划
      │                                      │
      ▼                                      ▼
   开发实现 ──> 自检验证 ──> 灰盒测试设计 ──> 灰盒测试执行
                                                     │
                                                     ▼
                    缺陷修复与回归测试 <── 测试报告生成
                                                     │
                                                     ▼
                                                最终交付说明
```

## ⚙️ 两种执行模式

| 模式 | 推荐给谁 | 行为 |
| --- | --- | --- |
| 手动分阶段执行 | 想严格控制每一步的人 | 每完成一个阶段就暂停、汇报，并询问是否进入下一阶段 |
| 自动执行 | 想快速推进完整流程的人 | 连续推进各阶段，只在关键决策、安装工具、危险操作、凭据或范围变更时暂停 |

如果你不确定选哪个：

- 想稳一点：选手动分阶段执行。
- 想快一点：选自动执行。

## 📝 文档生成选择

使用这个 skill 时，Codex 会在生成或更新项目文档前询问用户需要哪些文档，避免默认写出过多文件。用户可以选择预设文档包，也可以自己新增、删除、合并或重命名文档。

| 文档包 | 包含内容 | 适合场景 |
| --- | --- | --- |
| Lean delivery | 需求文档、开发计划、最终交付说明 | 小型作业、快速交付 |
| Standard delivery | 需求文档、开发计划、灰盒测试计划、灰盒测试报告、最终交付说明 | 正式课程作业、需要测试依据 |
| Full delivery | 需求、选型、开发计划、测试计划、测试执行结果、测试报告、必要时的缺陷报告、最终交付说明 | 实训、毕设、需要完整过程材料 |
| Custom | 用户指定要创建、跳过、合并、重命名或新增的文档 | 老师或团队有固定模板要求 |

如果用户已经在对话里明确了文档要求，skill 会直接按要求执行，不再重复询问。

## 🧩 11 个阶段

| 阶段 | 名称 | 主要产出 |
| --- | --- | --- |
| 1 | 想法捕获与需求澄清 | 项目目标、用户、核心流程、数据对象、验收标准 |
| 2 | 技术选型 | 语言、框架、数据库、测试工具和推荐方案 |
| 3 | 需求文档生成 | 范围、非范围、角色、模块、接口/UI、验收标准 |
| 4 | 技术方案与开发计划 | 架构、数据流、页面/API、验证规则、实施顺序 |
| 5 | 开发实现 | 按计划完成代码和必要文档变更 |
| 6 | 开发者自检与基线验证 | 构建、测试、启动、核心路径检查结果 |
| 7 | 灰盒测试设计 | 测试范围、测试类别、用例和风险点 |
| 8 | 灰盒测试执行 | Pass / Fail / Blocked / Not tested 结果和缺陷列表 |
| 9 | 测试报告生成 | 测试报告、缺陷统计、关键风险和结论 |
| 10 | 缺陷修复与回归测试 | 缺陷修复记录和回归验证结果 |
| 11 | 最终交付说明 | 功能总结、运行方式、测试方式、已知限制、文档路径 |

## 🔍 灰盒测试怎么做

灰盒测试会同时检查“外部表现”和“内部实现”。

| 检查方向 | 会看的内容 |
| --- | --- |
| 需求一致性 | 需求文档、开发计划、已实现模块、字段、页面/API |
| 代码结构 | 控制器、服务层、数据模型、组件、命名和职责划分 |
| 功能路径 | 新增、查询、编辑、删除、搜索、筛选、导航或接口响应 |
| 异常路径 | 必填缺失、非法 ID、空数据、重复数据、依赖失败 |
| 回归风险 | 已修复缺陷、相邻模块、启动和构建结果 |

缺陷记录格式统一，重复问题会按根因合并，避免测试报告里堆积重复条目。

## 🚀 快速开始

克隆到 Codex skills 目录：

```powershell
cd C:\Users\Yanyan_\.codex\skills
git clone https://gitee.com/Yan_dy/full-cycle-dev-test.git
```

如果已经安装过，更新即可：

```powershell
cd C:\Users\Yanyan_\.codex\skills\full-cycle-dev-test
git pull
```

## 💬 使用示例

从想法开始完整推进：

```text
使用 full-cycle-dev-test，帮我把一个电影收藏系统从需求到开发、灰盒测试和交付说明完整做一遍。
```

使用自动模式：

```text
请用 full-cycle-dev-test 的自动执行模式，基于当前项目继续开发，文档选择 Lean delivery。
```

使用手动模式：

```text
请用 full-cycle-dev-test 的手动分阶段模式，先帮我梳理需求和技术选型，暂时不要写代码。
```

只做测试和报告：

```text
请使用 full-cycle-dev-test，对当前项目做灰盒测试设计、执行测试，并生成测试报告。
```

自定义文档：

```text
请使用 full-cycle-dev-test 自动执行，只保留需求文档、测试报告和交付说明，不要生成单独的测试执行结果文档。
```

## 📁 目录结构

```text
full-cycle-dev-test/
├── SKILL.md
├── README.md
├── agents/
│   └── openai.yaml
└── references/
    ├── development-plan-template.md
    ├── graybox-test-template.md
    ├── issue-report-template.md
    ├── phase-summary-template.md
    ├── phase-workflow.md
    ├── requirements-from-idea.md
    ├── technology-selection.md
    └── test-report-template.md
```

## 📚 文件说明

| 文件 | 作用 |
| --- | --- |
| `SKILL.md` | skill 的核心触发描述和执行规则 |
| `agents/openai.yaml` | 面向界面的展示名称、简介和默认提示词 |
| `references/phase-workflow.md` | 11 个阶段的完整流程说明 |
| `references/requirements-from-idea.md` | 从想法生成需求时的问题和总结模板 |
| `references/technology-selection.md` | 不同项目类型的技术选型建议 |
| `references/development-plan-template.md` | 开发计划模板 |
| `references/graybox-test-template.md` | 灰盒测试设计和执行模板 |
| `references/test-report-template.md` | 测试报告模板 |
| `references/issue-report-template.md` | 缺陷报告模板 |
| `references/phase-summary-template.md` | 阶段总结模板 |

## 🛡️ 设计原则

| 原则 | 含义 |
| --- | --- |
| 先确认，再开发 | 需求、技术栈、计划未明确前，不急着写代码 |
| 少读但读准 | 每个阶段只读取完成当前任务必要的信息 |
| 不随意扩范围 | 影响数据模型、接口、主要 UI 或测试标准的变更需要先说明风险 |
| 使用现有工具 | 优先使用项目已有的 Maven、Gradle、npm、pytest、Playwright 等工具 |
| 报告写入文件 | 长测试报告写到项目文档目录，聊天里只给结论和路径 |
| 文档先选择 | 生成文档前先确认文档包，允许用户自定义新增、删除或合并 |

## 🧰 维护与发布

维护这个 skill 时，建议重点检查三类内容：

| 维护项 | 检查重点 |
| --- | --- |
| `SKILL.md` | 触发描述是否准确，执行规则是否清晰 |
| `references/` | 阶段模板是否完整，是否存在重复或过时内容 |
| `README.md` | 是否能让新用户快速理解用途、安装方式和使用示例 |

发布到远程仓库前，建议确认：

- README 能正常显示中文，没有乱码。
- `SKILL.md` 的 frontmatter 中 `name` 和 `description` 保持有效。
- 模板文件只保留对工作流有帮助的内容，避免堆积重复说明。
- 本地工作区没有无关文件或临时文件。

## 🔗 远程仓库

```text
https://gitee.com/Yan_dy/full-cycle-dev-test.git
```