Merge pull request '新增gitlink-dev-full-cycle技能' (#269) from wdgde/gitlink-cli:feature/skill into master

This commit is contained in:
wbtiger 2026-07-14 22:29:21 +08:00
commit ad80f8bb68
3 changed files with 767 additions and 0 deletions

View File

@ -0,0 +1,322 @@
---
name: gitlink-dev-full-cycle
description: "需求开发测试发布全流程。触发词新需求开发、全流程推进、从需求到上线、启动需求、开发测试发布、feature全流程、需求落地、需求闭环、从0到1交付、从零开始开发、新建项目开发。6阶段项目初始化→需求分析→技术设计→编码开发→测试验证→发布上线。集成gitlink-cli分支三分支模型master主分支/feature-xxx开发分支/release-xxx发布分支每阶段输出标准文档。"
agent_created: true
---
# gitlink-dev-full-cycle — 需求开发测试发布全流程
## 触发词
新需求开发、全流程推进、从需求到上线、启动需求、开发测试发布、feature全流程、需求落地、需求闭环、从0到1交付、从零开始开发、新建项目开发
---
## ⚠ 核心规则:必须使用 gitlink-cli
本 Skill 与 GitLink 平台的所有交互**必须通过 `gitlink-cli` 命令完成**,禁止绕过 gitlink-cli 直接使用 GitLink Web 界面或 API。**禁止使用 `gitlink-cli api` 命令**(该命令用于发送原始 API 请求,容易误操作,所有操作应使用对应的专用子命令)。
### 🔴 执行 gitlink-cli 命令前,必须先查询 --help 确认正确格式!
gitlink-cli 的部分子命令使用 `+` 前缀(如 `+create`、`+merge`、`+run`),部分不需要(如 `auth status`、`auth login`)。**执行任何 gitlink-cli 命令前,必须先通过 `--help` 查询子命令列表,确认准确的命令格式后再执行。**
**查询方式:**
```bash
# 查看某模块下有哪些子命令(注意哪些带 + 哪些不带)
gitlink-cli repo --help
gitlink-cli branch --help
gitlink-cli pr --help
# 查看某子命令的详细参数
gitlink-cli repo +create --help
gitlink-cli pr +merge --help
```
**常见错误AI agent 执行时丢掉 `+` 前缀,导致命令失败。**
```
❌ gitlink-cli repo create -n "项目名" # 丢掉了 +,会失败
✅ gitlink-cli repo +create -n "项目名" # 保留 +,正确
❌ gitlink-cli branch protect -n master # 丢掉了 +
✅ gitlink-cli branch +protect -n master # 保留 +
❌ gitlink-cli pr merge -i 123 # 丢掉了 +
✅ gitlink-cli pr +merge -i 123 # 保留 +
```
> **规则:不确定子命令格式时,先执行 `gitlink-cli <模块> --help` 查看可用子命令列表,照抄列表中的格式(含 `+` 或不含 `+`),禁止凭猜测省略或添加 `+`。**
**必须使用 gitlink-cli 的操作:**
- 创建代码仓库 → `gitlink-cli repo +create / +info`
- 创建/保护分支 → `gitlink-cli branch +create / +protect`
- 创建 PR / Review / 合并 → `gitlink-cli pr +create / +review / +merge`
- 触发流水线 / 查看构建 → `gitlink-cli pipeline +run / +runs`、`gitlink-cli ci +builds / +logs`
- 创建 Release → `gitlink-cli release +create`
- AI Code Review → `gitlink-cli workflow +pr-summary`
- 仓库健康检查 → `gitlink-cli workflow +health / +repo-report`
**本地 Git 操作使用原生 git** `git add`、`git commit`、`git push`、`git pull`、`git checkout`、`git merge`、`git clone` 等。若 `git push` / `git pull` 需要认证,向用户询问账号密码或 Token不使用 gitlink-cli auth。
---
## 分支策略
```
master ──────────────────────── 主分支(受保护,严禁直接提交或推送,存放最新稳定代码)
│ ↑
├──→ feature-xxx ──→PR──→ release-xxx ──→ 发版后合并回 master
└──→ feature-yyy ──→PR──→ release-zzz ──→ ...
```
**3 种分支说明:**
| 分支 | 命名规范 | 从哪拉 | 说明 |
|------|----------|--------|------|
| `master` | 固定 | — | 主分支,存放最新发布的稳定代码,**严禁直接提交代码或修改内容** |
| `release-xxx` | `release-<版本号或日期>` | `master` | 发布分支,用于版本发布准备,发版后保留所有版本,不删除 |
| `feature-xxx` | `feature-<功能描述>` | `master` | 开发分支,团队日常开发的基准分支,存放最新开发进度代码 |
**分支流转规则(严格遵守):**
1. 每次开发时从 `master` 拉取 `feature-xxx` 分支进行功能开发和缺陷修复
2. 开发自测完成后,提交 PR 将 `feature-xxx` 合并到 `release-xxx`(发布分支)
3. 发版后将 `release-xxx` 合并回 `master` 分支
**禁止的行为:**
- ❌ 直接向 `master` 提交代码或 `git push origin master`
- ❌ `feature-xxx` 直接向 `master` 发 PR必须先合入 `release-xxx`,再由 `release-xxx` 合回 `master`
- ❌ 不同 `feature-xxx` 分支之间相互合并
---
## 前置步骤:认证检查
在执行任何阶段之前,**必须先确认 gitlink-cli 认证状态**
```bash
gitlink-cli auth status # 检查认证状态
```
- 若已认证 → 继续执行阶段零
- 若未认证 → 执行 `gitlink-cli auth login` 登录,登录成功后再继续
---
## ⚠ 阶段零:项目初始化(必须第一个执行!)
> **本阶段是后续所有阶段的前提,必须第一个完成!未完成阶段零,禁止进入阶段一及后续任何阶段。** 只有当项目已有远程仓库且本地已克隆时,才可跳过本阶段(需向用户确认)。
1. 确认项目信息仓库名、owner、公开/私有、技术栈
2. **先在 GitLink 远程创建仓库:**
```bash
gitlink-cli repo +create -n "项目名" -d "描述" --private "true"
gitlink-cli repo +info --owner "org" --repo "项目名" # 确认远程仓库创建成功
```
3. **再克隆到本地并初始化项目骨架:**
```bash
git clone <仓库URL> && cd <项目名>
# 按技术栈初始化项目骨架vite / fastapi / express / go mod init ...
git add . && git commit -m "init" && git push origin master
```
4. **保护 master 分支(严禁直接推送):**
```bash
gitlink-cli branch +protect --owner "org" --repo "项目名" -n master
gitlink-cli workflow +health --owner "org" --repo "项目名"
```
5. **输出文档:** 项目根目录下写入以下基础文档:
- `README.md` — 项目简介、技术栈、本地开发启动步骤、目录结构说明
- `.gitignore` — 根据技术栈生成标准忽略规则
- `docs/` 目录 — 创建文档目录,后续各阶段文档统一存放于此
---
## 阶段一:需求分析
1. 向用户确认需求背景、核心功能点、验收标准AC、优先级
2. 输出结构化需求:用户故事 + 功能清单 + ACGiven/When/Then+ Out-of-scope
3. **输出文档 `docs/requirements.md`** 按模板写入完整需求文档含背景、目标用户、用户故事、功能清单、验收标准、Out-of-scope、依赖与风险
4. 用户确认需求文档后进入下一阶段
---
## 阶段二:技术设计
1. 分析技术选型:技术栈、数据模型、接口契约、第三方集成
2. 识别风险与难点,给出解法
3. **输出文档 `docs/design.md`** 按模板写入完整设计文档含技术栈选型表、系统架构图、数据模型DDL、接口契约、关键实现思路、风险与缓解措施
4. 用户确认设计文档后进入下一阶段
---
## 阶段三:编码开发
1. **从 master 创建 feature 开发分支:**
```bash
gitlink-cli branch +create -n "feature-<功能描述>" -f master
git fetch origin && git checkout feature-<功能描述>
```
2. 用 TaskCreate 拆分开发子任务,逐任务实现(先 Happy Path 再边界)
3. 遵守编码规范:函数职责单一、关键逻辑注释、无硬编码、类型注解
4. **输出文档:**
- **代码注释** — 公共函数/类必须有 docstring 或 JSDoc说明用途、参数、返回值
- **`docs/api.md`**(如有 HTTP API— 列出所有新增接口的路径、方法、参数、响应、错误码
- **配置文件说明** — 新增配置项需在文档中注明用途和默认值
5. 完成后提交推送:
```bash
git add . && git commit -m "feat: XXX" && git push origin feature-<功能描述>
```
---
## 阶段四:测试验证
### 单元测试 + Lint
编写单元测试覆盖核心逻辑、边界、异常;运行 Lint 修复 Error。
### 创建发布分支release-xxx并集成 feature
```bash
# 若 release-xxx 尚未存在,从 master 创建
gitlink-cli branch +create -n "release-<版本号>" -f master
# 将 feature 分支合并到 release 分支
git checkout release-<版本号> && git merge feature-<功能描述> && git push origin release-<版本号>
```
### 触发流水线,验证集成结果
```bash
gitlink-cli pipeline +run -w <ci-workflow> -r release-<版本号>
gitlink-cli pipeline +runs -r release-<版本号> # 查看运行状态
gitlink-cli ci +builds && gitlink-cli ci +logs # 查看构建详情
```
冒烟测试:逐条验证 AC。
### Code ReviewPR: feature-xxx → release-xxx
```bash
gitlink-cli pr +create -t "feat: XXX" --head "feature-<功能描述>" --base "release-<版本号>"
gitlink-cli workflow +pr-summary -n <pr-number> # AI Review
gitlink-cli pr +diff -i <pr-number>
gitlink-cli pr +review -i <pr-number> -s approved -c "LGTM"
gitlink-cli pr +merge -i <pr-number> -m merge
```
### **输出文档 `docs/test-report.md`**
按模板写入测试报告含测试范围、测试环境、AC逐条验证结果、单元测试覆盖率、遗留问题清单
---
## ⚠ 阶段五:发布上线(必须严格按顺序执行,禁止跳步!)
> **🔴 发布上线阶段的所有步骤必须严格按下方顺序逐步执行,禁止跳过任何步骤、禁止调换顺序、禁止自行发明其他发布方式。**
>
> **禁止的行为:**
> - ❌ feature-xxx 直接向 master 发 PR必须经过 release-xxx
> - ❌ 未经用户确认就触发生产流水线或执行 release-xxx 合并回 master
> - ❌ 直接 `git push origin master`master 受保护,只能通过 PR 合入)
> - ❌ 合并 PR 后不创建 Release
> - ❌ 用 `git merge` 直接操作 master 绕过 PR 流程
### 第 1 步:发布前确认(全部满足才能继续)
- [ ] 所有测试通过
- [ ] PR Review 通过feature-xxx 已合并到 release-xxx
- [ ] 配置已更新
- [ ] 回滚方案已确认
- [ ] **用户明确确认"可以发布"**
### 第 2 步:触发生产流水线,执行发布
```bash
gitlink-cli pipeline +run -w <prod-workflow> -r release-<版本号> # ⚠ 需用户确认
gitlink-cli ci +builds && gitlink-cli ci +logs # 监控构建
```
生产冒烟验证 + 监控指标检查。
### 第 3 步release-xxx 合并回 master⚠ 不可逆,需用户确认)
```bash
gitlink-cli pr +create -t "release-<版本号> 合并回 master" --head "release-<版本号>" --base "master"
gitlink-cli pr +merge -i <pr-number> -m merge # ⚠ 需用户确认
```
> **保留所有 release-xxx 分支,不删除。**
### 第 4 步:输出文档
- **`CHANGELOG.md`** — 在文件顶部追加本次版本条目Added / Changed / Fixed / Breaking Changes
- **`docs/release-notes.md`** — 按模板写入发布通知(版本号、上线时间、更新内容、验证方式、回滚方案)
### 第 5 步:创建 Release
```bash
gitlink-cli release +create -t "v1.x.0" -n "v1.x.0-需求名" --target master --prerelease false
```
> **所有 feature-xxx 和 release-xxx 分支均保留,不删除。**
---
## 文档清单总览
| 阶段 | 输出文档 | 存放位置 |
|------|----------|----------|
| 阶段零 | README.md、.gitignore | 项目根目录 |
| 阶段一 | requirements.md | `docs/` |
| 阶段二 | design.md | `docs/` |
| 阶段三 | api.md如有API、代码注释 | `docs/` + 源码 |
| 阶段四 | test-report.md | `docs/` |
| 阶段五 | CHANGELOG.md、release-notes.md | 项目根目录 + `docs/` |
> 所有文档模板见 `references/templates.md`,按模板格式写入,确保结构统一。
---
## 进度追踪
执行时用 TaskCreate 建立任务列表:
```
[ ] 阶段零:项目初始化 → README.md + .gitignore
[ ] 阶段一:需求分析 → docs/requirements.md
[ ] 阶段二:技术设计 → docs/design.md
[ ] 阶段三:编码开发 → feature-xxx 分支 + api.md + 代码注释
[ ] 阶段四:测试验证 → docs/test-report.md + PR Reviewfeature-xxx → release-xxx
[ ] 阶段五:发布上线 → CHANGELOG.md + release-notes.md + release-xxx合并回master + Release
```
---
## 注意事项
- **阶段零必须第一个执行,未完成禁止进入后续阶段**(已有仓库需用户确认后方可跳过)
- 小需求可裁剪阶段一至五,但阶段零不可裁剪
- **所有平台操作必须使用 `gitlink-cli`,禁止绕过直接使用 Web 界面或 API**
- **禁止使用 `gitlink-cli api` 命令**(原始 API 请求易误操作,应使用对应的专用子命令)
- **执行 gitlink-cli 命令前,先通过 `--help` 查询确认子命令格式(部分子命令有 `+` 前缀,部分没有),禁止凭猜测省略或添加 `+`**
- **分支规则feature-xxx 从 master 拉;开发完 PR 合到 release-xxx发版后 release-xxx 合回 mastermaster 严禁直接提交**
- **发布上线阶段必须严格按照第1步→第5步顺序执行禁止跳步、禁止调换顺序、禁止自行发明其他发布方式**
- 不可逆操作release-xxx 合并回 master、触发生产流水线执行前必须获得用户确认
- `git push` / `git pull` 需认证时向用户询问,不使用 gitlink-cli auth
- 每阶段输出文档后才算阶段完成,文档需用户确认后才能推进
- `--owner` / `--repo` 在 Git 仓库目录下可自动探测
- 项目已有规范时优先遵循,不覆盖
---
## 参考资源
- `references/checklist.md` — 各阶段检查清单
- `references/templates.md` — 需求文档、设计文档、测试报告、Changelog 等模板

View File

@ -0,0 +1,111 @@
# 各阶段检查清单
> **核心规则:所有 GitLink 平台操作必须使用 `gitlink-cli` 命令,禁止绕过直接使用 Web 界面或 API。**
> **禁止使用 `gitlink-cli api` 命令**(原始 API 请求易误操作,应使用对应的专用子命令)。
> **推送/拉取代码使用原生 `git` 命令,若需认证则向用户询问账号密码或 Token。**
> **🔴 执行 gitlink-cli 命令前,必须先通过 `--help` 查询确认子命令格式!部分子命令有 `+` 前缀(如 `repo +create`),部分没有(如 `auth status`)。不确定时先查 `gitlink-cli <模块> --help`,照抄列表中的格式,禁止凭猜测省略或添加 `+`。**
>
> **分支规则master 严禁直接提交feature-xxx 从 master 拉,开发完 PR 合到 release-xxx发版后 release-xxx PR 合回 master。**
## 前置步骤:认证检查
- [ ] `gitlink-cli auth status` 认证状态已确认
- [ ] 若未认证 → `gitlink-cli auth login` 已完成登录
## ⚠ 阶段零:项目初始化(必须第一个执行!)
> **未完成阶段零,禁止进入后续任何阶段。** 只有项目已有远程仓库且本地已克隆时,经用户确认后方可跳过。
- [ ] 项目信息已确认仓库名、owner、公开/私有、技术栈)
- [ ] `gitlink-cli repo +create` 仓库已在 GitLink 远程创建
- [ ] `gitlink-cli repo +info` 已确认仓库信息正确
- [ ] 本地已克隆并初始化项目骨架,`npm run dev`/`python main.py` 可运行
- [ ] 初始代码已推送 `git push origin master`
- [ ] `gitlink-cli branch +protect -n master` master 已保护(严禁直接推送)
- [ ] `gitlink-cli workflow +health` 健康评分已检查
- [ ] **`README.md`** 已写入(项目简介、技术栈、启动步骤、目录结构)
- [ ] **`.gitignore`** 已生成(匹配当前技术栈)
- [ ] **`docs/`** 目录已创建
---
## 阶段一:需求分析
- [ ] 需求背景、核心功能点、验收标准AC已确认
- [ ] 结构化需求已输出:用户故事 + 功能清单 + AC + Out-of-scope
- [ ] **`docs/requirements.md`** 已按模板写入含背景、目标用户、用户故事、功能清单、验收标准、Out-of-scope、依赖与风险
- [ ] 用户已确认需求文档
---
## 阶段二:技术设计
- [ ] 技术栈、数据模型、接口契约、部署方案已确定
- [ ] 技术风险已识别,有解法或备选
- [ ] **`docs/design.md`** 已按模板写入含技术栈选型表、架构图、数据模型DDL、接口契约、关键实现思路、风险与缓解措施
- [ ] 用户已确认设计文档
---
## 阶段三:编码开发
- [ ] `gitlink-cli branch +create -n "feature-<功能描述>" -f master` feature 开发分支已从 master 创建
- [ ] 本地已 checkout feature 分支
- [ ] 功能模块已拆分任务TaskCreate逐任务完成
- [ ] **代码注释** 已补全(公共函数/类有 docstring/JSDoc用途、参数、返回值
- [ ] **`docs/api.md`** 已写入(如有 HTTP API路径、方法、参数、响应、错误码
- [ ] 配置项新增已文档化
- [ ] 代码已提交推送至 feature 分支
---
## 阶段四:测试验证
- [ ] 单元测试编写并通过Lint 无 Error
- [ ] release-xxx 分支已从 master 创建(`gitlink-cli branch +create -n "release-<版本号>" -f master`
- [ ] feature 已合并到 release-xxx`git merge feature-<功能描述>`
- [ ] CI 流水线已触发(`gitlink-cli pipeline +run`)并运行成功
- [ ] 集成测试通过AC 逐项验证通过
- [ ] `gitlink-cli pr +create --head "feature-<功能描述>" --base "release-<版本号>"` PR 已创建
- [ ] `gitlink-cli workflow +pr-summary -n <pr-number>` AI Review 已生成
- [ ] `gitlink-cli pr +review` Review 已提交approved
- [ ] `gitlink-cli pr +merge` PR 已合并feature-xxx → release-xxx
- [ ] 确认未出现 feature-xxx 直接向 master 发 PR违反分支规则
- [ ] **`docs/test-report.md`** 已按模板写入含测试范围、环境、AC逐条结果、覆盖率、遗留问题
---
## ⚠ 阶段五:发布上线(必须严格按顺序执行,禁止跳步!)
> 🔴 **必须按 第1步→第5步 顺序逐步执行,禁止跳过任何步骤、禁止调换顺序。**
### 第 1 步:发布前确认
- [ ] 所有测试通过 + PR Review 通过feature 已合入 release-xxx
- [ ] 配置已更新,回滚方案已确认
- [ ] **用户明确确认"可以发布"**
### 第 2 步:触发生产流水线,执行发布
- [ ] 生产流水线已触发(`gitlink-cli pipeline +run -w <prod-workflow> -r release-<版本号>`)⚠ 需用户确认
- [ ] 生产流水线运行成功,冒烟测试通过,监控指标正常
### 第 3 步release-xxx 合并回 master⚠ 不可逆,需用户确认)
- [ ] `gitlink-cli pr +create --head "release-<版本号>" --base "master"` PR 已创建
- [ ] **用户已确认**`gitlink-cli pr +merge` PR 已合并
- [ ] release-xxx 分支已保留(不删除,保留最近一个版本)
### 第 4 步:输出文档
- [ ] **`CHANGELOG.md`** 已追加本次版本条目Added/Changed/Fixed/Breaking Changes
- [ ] **`docs/release-notes.md`** 已按模板写入(版本号、上线时间、更新内容、验证方式、回滚方案)
### 第 5 步:创建 Release 并清理
- [ ] `gitlink-cli release +create` Release 已创建(基于 master
- [ ] feature 分支已删除(本地 + 远程)(**release 分支保留,不删除**
- [ ] 相关方已通知
### ❌ 禁止的行为
- [ ] 确认未出现 feature-xxx 直接向 master 发 PR必须经过 release-xxx
- [ ] 确认未经用户确认就触发生产流水线或执行 release → master 合并
- [ ] 确认未直接 `git push origin master`
- [ ] 确认未用 `git merge` 直接操作 master 绕过 PR 流程
- [ ] 确认合并 PR 后已创建 Release
- [ ] 确认创建 Release 后已清理 feature 分支release 保留)

View File

@ -0,0 +1,334 @@
# 标准文档模板
## README.md 模板
```markdown
# <项目名称>
> <一句话项目简介>
## 技术栈
| 层次 | 技术 |
|------|------|
| 前端 | ... |
| 后端 | ... |
| 数据库 | ... |
## 本地开发启动
```bash
# 安装依赖
npm install / pip install -r requirements.txt / go mod tidy
# 启动开发服务
npm run dev / python main.py / go run main.go
# 运行测试
npm test / pytest / go test ./...
```
## 目录结构
```
src/ 源代码
docs/ 项目文档(需求、设计、测试报告等)
tests/ 测试代码
config/ 配置文件
```
## 相关文档
- [需求文档](docs/requirements.md)
- [技术设计](docs/design.md)
- [API 文档](docs/api.md)
- [测试报告](docs/test-report.md)
- [CHANGELOG](CHANGELOG.md)
```
---
## 需求文档模板docs/requirements.md
```markdown
# 需求文档:<需求名称>
**版本:** v1.0
**日期:** YYYY-MM-DD
**作者:** <姓名>
**状态:** 草稿 / 评审中 / 已确认
---
## 背景
<描述业务背景为什么要做这个需求>
## 目标用户
<描述主要使用该功能的用户群体>
## 用户故事
| # | 用户故事 |
|---|---------|
| US-1 | As a <角色>, I want to <行为>, so that <价值> |
| US-2 | ... |
## 功能清单
1. **功能 A**<详细描述>
2. **功能 B**<详细描述>
3. ...
## 验收标准AC
### AC-1<功能 A 的验收>
- **Given**<前置条件>
- **When**<用户操作>
- **Then**<期望结果>
### AC-2<功能 B 的验收>
- **Given**...
- **When**...
- **Then**...
## Out of Scope不做的内容
- <明确排除项 1>
- <明确排除项 2>
## 依赖与风险
- <依赖项 / 外部风险>
```
---
## 技术设计文档模板docs/design.md
```markdown
# 技术设计:<需求名称>
**版本:** v1.0
**日期:** YYYY-MM-DD
**作者:** <姓名>
---
## 技术栈
| 层次 | 技术选型 | 理由 |
|------|---------|------|
| 前端 | React + TypeScript | ... |
| 后端 | FastAPI (Python) | ... |
| 数据库 | PostgreSQL | ... |
## 系统架构
< Mermaid Excalidraw 画架构图说明模块间调用关系>
```mermaid
graph TD
A[用户] --> B[前端]
B --> C[后端 API]
C --> D[数据库]
```
## 数据模型
```sql
CREATE TABLE example (
id SERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
## 接口契约
### POST /api/v1/example
**请求:**
```json
{
"name": "string"
}
```
**响应200**
```json
{
"id": 1,
"name": "string",
"created_at": "2026-01-01T00:00:00Z"
}
```
**错误码:**
| 状态码 | 含义 |
|--------|------|
| 400 | 参数校验失败 |
| 500 | 服务器内部错误 |
## 关键实现思路
<描述核心算法复杂逻辑的实现方式>
## 风险与缓解措施
| 风险 | 影响 | 缓解措施 |
|------|------|---------|
| ... | ... | ... |
```
---
## API 文档模板docs/api.md
```markdown
# API 文档:<项目名称>
**版本:** v1.0
**更新日期:** YYYY-MM-DD
---
## 接口列表
| 方法 | 路径 | 说明 | 认证 |
|------|------|------|------|
| POST | /api/v1/xxx | 创建XXX | 需要 |
| GET | /api/v1/xxx | 查询XXX | 需要 |
| PUT | /api/v1/xxx/:id | 更新XXX | 需要 |
| DELETE | /api/v1/xxx/:id | 删除XXX | 需要 |
---
## 接口详情
### POST /api/v1/xxx
**请求参数:**
| 字段 | 类型 | 必填 | 说明 |
|------|------|------|------|
| name | string | 是 | 名称 |
| type | int | 否 | 类型默认0 |
**响应200**
```json
{
"code": 0,
"data": { ... },
"message": "success"
}
```
**错误码:**
| 状态码 | code | 说明 |
|--------|------|------|
| 400 | 10001 | 参数校验失败 |
| 401 | 10002 | 未认证 |
| 500 | 20001 | 服务器内部错误 |
```
---
## 测试报告模板docs/test-report.md
```markdown
# 测试报告:<需求名称>
**版本:** v1.0
**日期:** YYYY-MM-DD
**测试环境:** release_daily / release_pre
---
## 测试范围
<描述本次测试覆盖的功能模块>
## 测试环境
| 项目 | 配置 |
|------|------|
| 环境 | daily / pre |
| 分支 | release_daily / release_pre |
| 数据库 | ... |
## AC 验证结果
| AC编号 | 验收标准 | 结果 | 备注 |
|--------|---------|------|------|
| AC-1 | <描述> | ✅ 通过 | |
| AC-2 | <描述> | ❌ 未通过 | <原因与修复计划> |
## 单元测试
| 模块 | 测试数 | 通过 | 失败 | 覆盖率 |
|------|--------|------|------|--------|
| 模块A | 15 | 15 | 0 | 85% |
| 模块B | 10 | 9 | 1 | 72% |
## 遗留问题
| # | 问题 | 严重程度 | 计划处理方式 |
|---|------|---------|-------------|
| 1 | <描述> | 高/中/低 | 下一版本修复 / 本次忽略 |
```
---
## CHANGELOG 条目模板
```markdown
## [1.2.0] - YYYY-MM-DD
### Added
- 新增 <功能名称><一句话描述>
### Changed
- 优化 <模块名称><改动描述>
### Fixed
- 修复 <Bug 描述>
### Breaking Changes
- <如有不兼容变更在此说明>
```
---
## 发布通知模板docs/release-notes.md
```markdown
# 发布通知:<需求名称>
**版本:** v1.2.0
**上线时间:** YYYY-MM-DD HH:MM
**环境:** 生产环境
---
## 更新内容
1. <功能 A><简要描述>
2. <功能 B><简要描述>
## 验证方式
<简要描述如何验证功能正常>
## 回滚方案
<如需回滚执行 xxx 命令或回滚到 v1.1.0>
## 注意事项
- <需要关注的事项如数据迁移配置变更等>
## 联系人
<负责人>
```