Add under-anything knowledge dashboard
This commit is contained in:
123
wishfulfilled-wiki/02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md
Normal file
123
wishfulfilled-wiki/02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md
Normal file
@@ -0,0 +1,123 @@
|
||||
---
|
||||
type: process_overview
|
||||
tags: [项目管理流程, AI驱动开发, ERP, 内部系统]
|
||||
aliases: [AI驱动内部系统开发流程, 内部系统开发流程V3, ERP开发流程]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 内部技术团队
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# AI 驱动内部系统开发流程 V3 总览
|
||||
|
||||
## 版本定位
|
||||
|
||||
本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。
|
||||
|
||||
核心目标不是让流程变复杂,而是解决以下问题:
|
||||
|
||||
- 业务需求说不清。
|
||||
- AI 生成内容不完整。
|
||||
- 前端模型介入太晚。
|
||||
- 后端数据库设计被页面倒逼。
|
||||
- 测试太晚才发现需求漏项。
|
||||
- 项目完成后留下大量重复代码和技术债。
|
||||
|
||||
## 总体阶段
|
||||
|
||||
| 阶段 | 阶段名称 | 核心目标 | 核心负责人 |
|
||||
|---|---|---|---|
|
||||
| 阶段0 | 项目入口分级 | 判断项目是否值得做、走轻流程还是完整流程 | 业务主管 / 技术负责人 |
|
||||
| 阶段1 | 业务需求完整形成 | 业务侧通过 Vibe Coding 跑完整需求 | 业务主管 / 业务人员 |
|
||||
| 阶段2 | 高保真模型与业务对象确认 | 把完整但粗糙的需求收敛成可开发模型 | 前端 / 产品经理 |
|
||||
| 阶段2.5 | 测试提前补漏 | 在开发前用测试视角发现需求漏洞 | 测试 |
|
||||
| 阶段3 | 研发协作与正式开发 | 基于高保真模型进行模块化、安全、可维护开发 | 前端 / 后端 / 算法 |
|
||||
| 阶段4 | 测试、培训、上线、回流 | 完成测试、培训、上线验收和问题回流 | 测试 / 业务主管 |
|
||||
| 阶段5 | 技术债治理与能力沉淀 | 清理 AI 冗余代码并沉淀复用能力 | 技术负责人 |
|
||||
|
||||
## 阶段门禁
|
||||
|
||||
| 门禁 | 通过标准 |
|
||||
|---|---|
|
||||
| Gate 0 | 项目入口通过:确认值得做,确认项目类型。 |
|
||||
| Gate 1 | 需求完整通过:主流程、分支、页面、按钮、字段、状态大致完整。 |
|
||||
| Gate 2 | 高保真模型通过:页面收敛、按钮行为、业务对象、状态、V1/V2 明确。 |
|
||||
| Gate 2.5 | 测试补漏:测试用例初稿发现的阻塞问题已处理。 |
|
||||
| Gate 3 | 开发联调通过:前后端、数据库、权限、安全、主要流程联调完成。 |
|
||||
| Gate 4 | 上线验收通过:测试通过、业务确认、培训完成。 |
|
||||
| Gate 5 | 技术债治理完成:重复代码、组件、接口、数据结构完成治理或进入债务池。 |
|
||||
|
||||
## 完整版文件结构
|
||||
|
||||
- `00_项目入口分级.md`
|
||||
- `01_主流程说明.md`
|
||||
- `02_日常操作页面结构.md`
|
||||
- `03_功能页面按钮盘点表.md`
|
||||
- `04_分支流程_XXX.md`
|
||||
- `05_异常流程_XXX.md`
|
||||
- `06_VibeCoding页面验证记录.md`
|
||||
- `07_高保真模型.html`
|
||||
- `07_高保真模型说明.md`
|
||||
- `08_项目周期与版本确认.md`
|
||||
- `09_前端技术评审.md`
|
||||
- `10_技术预检记录.md`
|
||||
- `10A_统一业务对象模型.md`
|
||||
- `10B_按钮行为矩阵.md`
|
||||
- `11_测试用例初稿与需求补漏.md`
|
||||
- `12_研发任务拆分与协作计划.md`
|
||||
- `13_技术实现对接.md`
|
||||
- `14_代码治理与安全规范.md`
|
||||
- `15_开发问题与联调记录.md`
|
||||
- `16_正式测试报告.md`
|
||||
- `17_内部培训手册.md`
|
||||
- `18_上线验收记录.md`
|
||||
- `19_上线问题与回流需求.md`
|
||||
- `20_技术债清单.md`
|
||||
- `21_业务原子能力沉淀清单.md`
|
||||
- `22_组件库与服务复用清单.md`
|
||||
- `23_AI开发上下文模板更新记录.md`
|
||||
|
||||
## 轻量版文件结构
|
||||
|
||||
小项目可以使用轻量版:
|
||||
|
||||
- `00_项目入口分级.md`
|
||||
- `01_业务需求包.md`
|
||||
- `02_高保真模型包.md`
|
||||
- `03_项目版本与技术预检.md`
|
||||
- `04_测试用例初稿与需求补漏.md`
|
||||
- `05_研发协作与技术实现包.md`
|
||||
- `06_代码治理与安全规范.md`
|
||||
- `07_测试培训上线包.md`
|
||||
- `08_技术债与能力沉淀包.md`
|
||||
|
||||
## 最终核心原则
|
||||
|
||||
- 先分级,再开发。
|
||||
- 阶段1追求需求完整,不追求产品完善。
|
||||
- Vibe Coding 页面只是需求原型,不直接进入生产。
|
||||
- 阶段2追求模型高效,前端必须深度参与。
|
||||
- 高保真模型确认后,才允许正式开发。
|
||||
- 统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。
|
||||
- 性能、安全、权限、并发、日志、可回滚必须提前预检。
|
||||
- 测试提前补漏,不只是上线前找 Bug。
|
||||
- 研发阶段以代码质量、模块化、安全性、可维护性为中心。
|
||||
- AI 代码必须治理,不能直接堆进生产。
|
||||
- 每个项目都要沉淀业务原子能力。
|
||||
- 每完成 3-4 个项目,必须进行技术债治理。
|
||||
|
||||
## 一句话总结
|
||||
|
||||
这套流程不是为了让 AI 替代开发,而是让 AI 帮业务更快形成完整需求,让前端和产品把需求收敛成高保真模型,让研发团队基于模型高质量开发,让测试和技术债治理保障系统长期可用。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[阶段0_项目入口分级]]
|
||||
- [[阶段1_业务需求完整形成]]
|
||||
- [[阶段2_高保真模型与业务对象确认]]
|
||||
- [[阶段2.5_测试提前补漏]]
|
||||
- [[阶段3_研发协作与正式开发]]
|
||||
- [[阶段4_测试培训上线回流]]
|
||||
- [[角色职责矩阵]]
|
||||
- [[阶段交付物清单]]
|
||||
- [[项目检查清单]]
|
||||
34
wishfulfilled-wiki/02_项目管理流程/README.md
Normal file
34
wishfulfilled-wiki/02_项目管理流程/README.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
type: index
|
||||
tags: [项目管理流程, AI驱动开发]
|
||||
aliases: [项目管理流程入口, 开发流程入口]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 内部技术团队
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 项目管理流程
|
||||
|
||||
本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解,用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。
|
||||
|
||||
## 阶段文件
|
||||
|
||||
- [[AI驱动内部系统开发流程_V3_总览]]
|
||||
- [[阶段0_项目入口分级]]
|
||||
- [[阶段1_业务需求完整形成]]
|
||||
- [[阶段2_高保真模型与业务对象确认]]
|
||||
- [[阶段2.5_测试提前补漏]]
|
||||
- [[阶段3_研发协作与正式开发]]
|
||||
- [[阶段4_测试培训上线回流]]
|
||||
|
||||
## 重组索引
|
||||
|
||||
- [[角色职责矩阵]]
|
||||
- [[阶段交付物清单]]
|
||||
- [[项目检查清单]]
|
||||
- [[常见问题FAQ]]
|
||||
|
||||
## 核心原则
|
||||
|
||||
先分级,再开发。阶段1追求需求完整,不追求产品完善。高保真模型确认后,才允许正式开发。测试要提前补漏。AI 代码必须治理,不能直接堆进生产。
|
||||
65
wishfulfilled-wiki/02_项目管理流程/常见问题FAQ.md
Normal file
65
wishfulfilled-wiki/02_项目管理流程/常见问题FAQ.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
type: faq
|
||||
tags: [项目管理流程, FAQ, 问答]
|
||||
aliases: [流程常见问题, 项目管理问答]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 内部技术团队
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 常见问题 FAQ
|
||||
|
||||
## 一个内部系统需求从提出到上线要走哪些阶段?
|
||||
|
||||
通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。
|
||||
|
||||
来源:[[AI驱动内部系统开发流程_V3_总览]]
|
||||
|
||||
## 阶段0项目入口分级由谁负责?
|
||||
|
||||
由业务主管和技术负责人共同负责。业务主管判断业务价值和范围,技术负责人判断技术复杂度和风险。
|
||||
|
||||
来源:[[阶段0_项目入口分级]]、[[角色职责矩阵]]
|
||||
|
||||
## 业务需求完整形成阶段的目标是什么?
|
||||
|
||||
业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整,不追求产品完善。
|
||||
|
||||
来源:[[阶段1_业务需求完整形成]]
|
||||
|
||||
## 阶段2.5测试提前补漏应该在什么时候发生?
|
||||
|
||||
发生在高保真模型确认后、正式开发前。
|
||||
|
||||
来源:[[阶段2.5_测试提前补漏]]
|
||||
|
||||
## 阶段2.5测试提前补漏要产出什么?
|
||||
|
||||
主要产出 `11_测试用例初稿与需求补漏.md`,并形成需求补漏记录、阻塞问题清单和已关闭问题清单。
|
||||
|
||||
来源:[[阶段2.5_测试提前补漏]]、[[阶段交付物清单]]
|
||||
|
||||
## 什么时候需要前端提前参与需求收敛?
|
||||
|
||||
阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用,前端应在需求收敛时提前参与。
|
||||
|
||||
来源:[[阶段2_高保真模型与业务对象确认]]
|
||||
|
||||
## 研发协作与正式开发阶段如何保证模块化、安全和可维护?
|
||||
|
||||
依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理,不能直接堆进生产。
|
||||
|
||||
来源:[[阶段3_研发协作与正式开发]]
|
||||
|
||||
## 上线前需要检查哪些事项?
|
||||
|
||||
至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。
|
||||
|
||||
来源:[[阶段4_测试培训上线回流]]、[[项目检查清单]]
|
||||
|
||||
## Vibe Coding 页面能不能直接进入生产?
|
||||
|
||||
不能。Vibe Coding 页面只是需求原型,不直接进入生产。
|
||||
|
||||
来源:[[阶段1_业务需求完整形成]]、[[AI驱动内部系统开发流程_V3_总览]]
|
||||
84
wishfulfilled-wiki/02_项目管理流程/角色职责矩阵.md
Normal file
84
wishfulfilled-wiki/02_项目管理流程/角色职责矩阵.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
type: responsibility_matrix
|
||||
tags: [项目管理流程, 角色职责, RACI]
|
||||
aliases: [角色职责, 职责矩阵, RACI]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 内部技术团队
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 角色职责矩阵
|
||||
|
||||
## 总览
|
||||
|
||||
| 角色 | 主要负责阶段 | 核心职责 | 典型产出 |
|
||||
|---|---|---|---|
|
||||
| 业务主管 | 阶段0、阶段1、阶段4 | 判断项目价值、明确主流程、确认业务完整性、上线验收 | 项目入口分级、主流程说明、业务验收口径、上线验收记录 |
|
||||
| 业务人员 | 阶段1 | 补充分支流程、提供样本数据、验证真实操作路径 | 分支流程、异常流程、Vibe Coding 页面验证记录 |
|
||||
| 产品经理 | 阶段2 | 收敛需求、组织高保真模型、明确版本范围 | 高保真模型说明、项目周期与版本确认 |
|
||||
| 前端 | 阶段2、阶段3 | 深度参与模型收敛、页面结构、按钮行为、组件复用、前端开发 | 高保真模型、前端技术评审、按钮行为矩阵、前端实现 |
|
||||
| 后端 | 阶段3 | 设计接口、数据库、权限、安全、日志、回滚和服务能力 | 技术实现对接、后端服务、接口和数据库方案 |
|
||||
| 算法 | 阶段3 | 判断是否需要 AI,设计输入输出、置信度、人工审核和风险控制 | 算法适用性判断、算法输入输出说明、置信度规则 |
|
||||
| 测试 | 阶段2.5、阶段4 | 提前写测试用例、发现需求漏洞、正式测试、培训材料、上线反馈 | 测试用例初稿、正式测试报告、内部培训手册、上线问题回流 |
|
||||
| 技术负责人 | 阶段0、阶段5 | 技术分级、风险判断、技术债治理和能力沉淀 | 技术债清单、业务原子能力沉淀清单、组件库与服务复用清单 |
|
||||
|
||||
## 业务主管
|
||||
|
||||
业务主管保证方向正确、主流程清楚、需求不漏大块。
|
||||
|
||||
职责:
|
||||
|
||||
- 判断项目是否值得做。
|
||||
- 定义主流程。
|
||||
- 定义日常操作入口。
|
||||
- 明确业务人员每天先看什么页面。
|
||||
- 拆分分支流程,指定业务人员补充。
|
||||
- 确认异常流程。
|
||||
- 确认业务完整性。
|
||||
- 参与业务验收。
|
||||
|
||||
## 业务人员
|
||||
|
||||
业务人员负责具体分支流程和真实操作细节。
|
||||
|
||||
职责:
|
||||
|
||||
- 补充分支流程。
|
||||
- 提供样本数据,例如 ASIN、订单、评论、用户、表格等真实样本。
|
||||
- 使用 Vibe Coding 跑页面,验证是否符合真实操作。
|
||||
- 补充异常场景。
|
||||
|
||||
## 算法
|
||||
|
||||
算法保证 AI 能力可控、可解释、可人工审核。
|
||||
|
||||
职责:
|
||||
|
||||
- 判断是否需要 AI,避免为了 AI 而 AI。
|
||||
- 设计算法输入,明确模型需要哪些数据。
|
||||
- 设计算法输出,明确 AI 返回什么结果。
|
||||
- 制定置信度规则。
|
||||
- 制定人工审核机制。
|
||||
- 设计风险控制,确保 AI 判断错误时可以回退和纠正。
|
||||
|
||||
## 测试
|
||||
|
||||
测试不只是最后找 Bug,还要提前补漏,并负责内部培训材料。
|
||||
|
||||
职责:
|
||||
|
||||
- 高保真模型出来后先写测试用例。
|
||||
- 用测试视角发现流程、按钮、权限遗漏。
|
||||
- 正式测试主流程、分支流程、权限、异常和数据。
|
||||
- 输出验收报告。
|
||||
- 将测试用例转成业务操作手册。
|
||||
- 记录上线问题并回流需求池。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[AI驱动内部系统开发流程_V3_总览]]
|
||||
- [[阶段0_项目入口分级]]
|
||||
- [[阶段1_业务需求完整形成]]
|
||||
- [[阶段2.5_测试提前补漏]]
|
||||
- [[阶段4_测试培训上线回流]]
|
||||
86
wishfulfilled-wiki/02_项目管理流程/阶段0_项目入口分级.md
Normal file
86
wishfulfilled-wiki/02_项目管理流程/阶段0_项目入口分级.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
type: process_stage
|
||||
tags: [项目管理流程, 阶段0, 项目入口, 分级, 立项]
|
||||
aliases: [项目入口分级, 入口分级, Gate 0, 立项分级]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 业务主管 / 技术负责人
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 阶段0 项目入口分级
|
||||
|
||||
## 核心目标
|
||||
|
||||
不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做,以及走轻流程还是完整流程。
|
||||
|
||||
## 负责人
|
||||
|
||||
- 业务主管
|
||||
- 技术负责人
|
||||
|
||||
## 输入
|
||||
|
||||
- 业务提出的问题或机会。
|
||||
- 现有系统痛点。
|
||||
- 业务收益、风险、范围的初步判断。
|
||||
|
||||
## 项目分类
|
||||
|
||||
| 类型 | 适用场景 | 流程要求 |
|
||||
|---|---|---|
|
||||
| S 类 | 小需求,单页面、小改动、无复杂数据 | 可简化阶段1和阶段2。 |
|
||||
| M 类 | 中等需求,涉及多个页面、多个角色或状态流转 | 建议走完整阶段0-4。 |
|
||||
| L 类 | 大型需求,涉及核心流程、多个部门、复杂权限、数据模型或算法 | 必须走完整流程,并强化技术预检和阶段门禁。 |
|
||||
|
||||
## 关键动作
|
||||
|
||||
- 判断需求是否值得做。
|
||||
- 判断项目影响范围。
|
||||
- 判断是否需要完整流程。
|
||||
- 判断是否涉及复杂数据、权限、算法、外部系统或高风险流程。
|
||||
- 初步指定业务负责人和技术负责人。
|
||||
|
||||
## 输出/交付物
|
||||
|
||||
- `00_项目入口分级.md`
|
||||
- 项目类型:S / M / L。
|
||||
- 是否进入完整流程的结论。
|
||||
- 初步负责人。
|
||||
- 初步范围和风险。
|
||||
|
||||
## 检查清单
|
||||
|
||||
- [ ] 是否确认需求要解决的真实业务问题?
|
||||
- [ ] 是否确认该需求值得做?
|
||||
- [ ] 是否确认项目类型?
|
||||
- [ ] 是否确认走轻流程还是完整流程?
|
||||
- [ ] 是否识别复杂权限、数据、算法、并发、安全或外部系统风险?
|
||||
- [ ] 是否明确业务主管和技术负责人?
|
||||
|
||||
## 风险点
|
||||
|
||||
- 小需求被过度流程化,降低效率。
|
||||
- 大需求被当成小需求处理,后续返工。
|
||||
- 没有识别权限、数据、安全、算法风险。
|
||||
- 没有业务负责人,需求持续漂移。
|
||||
|
||||
## Gate 0 通过标准
|
||||
|
||||
项目入口通过:确认值得做,确认项目类型。
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 阶段0由谁负责?
|
||||
|
||||
由业务主管和技术负责人共同负责。业务主管判断业务价值和业务范围,技术负责人判断技术复杂度和风险。
|
||||
|
||||
### 小需求是否必须走完整流程?
|
||||
|
||||
不一定。S 类小需求可以简化阶段1和阶段2,但仍应保留基本入口判断、测试和上线验收。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[AI驱动内部系统开发流程_V3_总览]]
|
||||
- [[角色职责矩阵]]
|
||||
- [[阶段交付物清单]]
|
||||
83
wishfulfilled-wiki/02_项目管理流程/阶段1_业务需求完整形成.md
Normal file
83
wishfulfilled-wiki/02_项目管理流程/阶段1_业务需求完整形成.md
Normal file
@@ -0,0 +1,83 @@
|
||||
---
|
||||
type: process_stage
|
||||
tags: [项目管理流程, 阶段1, 业务需求, VibeCoding, 需求完整]
|
||||
aliases: [业务需求完整形成, 提需求, 需求梳理, Gate 1]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 业务主管 / 业务人员
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 阶段1 业务需求完整形成
|
||||
|
||||
## 核心目标
|
||||
|
||||
业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整,不追求产品完善。
|
||||
|
||||
## 负责人
|
||||
|
||||
- 业务主管
|
||||
- 业务人员
|
||||
|
||||
## 输入
|
||||
|
||||
- 阶段0入口分级结论。
|
||||
- 业务痛点、业务目标、现有流程。
|
||||
- 业务人员真实操作经验。
|
||||
|
||||
## 关键动作
|
||||
|
||||
- 梳理主流程。
|
||||
- 明确日常操作页面结构。
|
||||
- 盘点功能页面和按钮。
|
||||
- 补充分支流程。
|
||||
- 补充异常流程。
|
||||
- 使用 Vibe Coding 生成或验证需求原型。
|
||||
- 记录页面验证结果。
|
||||
|
||||
## 输出/交付物
|
||||
|
||||
- `01_主流程说明.md`
|
||||
- `02_日常操作页面结构.md`
|
||||
- `03_功能页面按钮盘点表.md`
|
||||
- `04_分支流程_XXX.md`
|
||||
- `05_异常流程_XXX.md`
|
||||
- `06_VibeCoding页面验证记录.md`
|
||||
|
||||
## 检查清单
|
||||
|
||||
- [ ] 主流程是否能从开始走到结束?
|
||||
- [ ] 日常操作入口是否清楚?
|
||||
- [ ] 页面、按钮、字段是否大致完整?
|
||||
- [ ] 分支流程是否由真实业务人员补充?
|
||||
- [ ] 异常流程是否覆盖无负责人、超时、数据缺失等情况?
|
||||
- [ ] Vibe Coding 原型是否经过业务侧走查?
|
||||
- [ ] 是否明确哪些内容只是原型,不可直接进入生产?
|
||||
|
||||
## 风险点
|
||||
|
||||
- 只描述主流程,漏掉分支和异常。
|
||||
- 把 Vibe Coding 页面当成可生产代码。
|
||||
- 业务主管只给方向,没有安排业务人员补充真实操作细节。
|
||||
- 页面、按钮、字段未盘点,导致阶段2和开发阶段返工。
|
||||
|
||||
## Gate 1 通过标准
|
||||
|
||||
需求完整通过:主流程、分支、页面、按钮、字段、状态大致完整。
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 阶段1追求什么?
|
||||
|
||||
追求需求完整,不追求产品完善。页面可以粗糙,但业务流程、分支、异常、按钮、字段不能漏大块。
|
||||
|
||||
### Vibe Coding 页面能不能直接上线?
|
||||
|
||||
不能。Vibe Coding 页面只是需求原型,不直接进入生产。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[阶段0_项目入口分级]]
|
||||
- [[阶段2_高保真模型与业务对象确认]]
|
||||
- [[角色职责矩阵]]
|
||||
- [[阶段交付物清单]]
|
||||
79
wishfulfilled-wiki/02_项目管理流程/阶段2.5_测试提前补漏.md
Normal file
79
wishfulfilled-wiki/02_项目管理流程/阶段2.5_测试提前补漏.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
type: process_stage
|
||||
tags: [项目管理流程, 阶段2.5, 测试, 需求补漏, 测试用例]
|
||||
aliases: [测试提前补漏, 开发前测试, Gate 2.5, 测试用例初稿]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 测试
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 阶段2.5 测试提前补漏
|
||||
|
||||
## 核心目标
|
||||
|
||||
在开发前用测试视角发现需求漏洞。测试提前补漏,不只是上线前找 Bug。
|
||||
|
||||
## 负责人
|
||||
|
||||
- 测试
|
||||
|
||||
## 输入
|
||||
|
||||
- 高保真模型。
|
||||
- 高保真模型说明。
|
||||
- 统一业务对象模型。
|
||||
- 按钮行为矩阵。
|
||||
- 项目周期与版本确认。
|
||||
|
||||
## 关键动作
|
||||
|
||||
- 基于高保真模型先写测试用例初稿。
|
||||
- 从主流程、分支流程、权限、异常、数据、按钮行为视角检查遗漏。
|
||||
- 标记阻塞开发的问题。
|
||||
- 将需求漏洞回流给业务、产品、前端补齐。
|
||||
- 确认阻塞问题处理后再进入正式开发。
|
||||
|
||||
## 输出/交付物
|
||||
|
||||
- `11_测试用例初稿与需求补漏.md`
|
||||
- 需求补漏记录。
|
||||
- 阻塞问题清单。
|
||||
- 已关闭问题清单。
|
||||
|
||||
## 检查清单
|
||||
|
||||
- [ ] 是否已基于高保真模型编写测试用例初稿?
|
||||
- [ ] 是否覆盖主流程?
|
||||
- [ ] 是否覆盖分支流程?
|
||||
- [ ] 是否覆盖权限?
|
||||
- [ ] 是否覆盖异常场景?
|
||||
- [ ] 是否覆盖关键数据和状态?
|
||||
- [ ] 是否覆盖按钮行为?
|
||||
- [ ] 测试发现的阻塞问题是否已关闭?
|
||||
|
||||
## 风险点
|
||||
|
||||
- 测试只在上线前介入,导致需求漏洞在开发后才暴露。
|
||||
- 测试用例只覆盖主流程,漏掉权限、异常、分支和数据边界。
|
||||
- 阻塞问题没有关闭就进入开发。
|
||||
|
||||
## Gate 2.5 通过标准
|
||||
|
||||
测试补漏:测试用例初稿发现的阻塞问题已处理。
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 阶段2.5应该在什么时候发生?
|
||||
|
||||
发生在高保真模型确认后、正式开发前。
|
||||
|
||||
### 阶段2.5要产出什么?
|
||||
|
||||
主要产出 `11_测试用例初稿与需求补漏.md`,并形成需求补漏记录、阻塞问题清单和已关闭问题清单。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[阶段2_高保真模型与业务对象确认]]
|
||||
- [[阶段3_研发协作与正式开发]]
|
||||
- [[项目检查清单]]
|
||||
81
wishfulfilled-wiki/02_项目管理流程/阶段2_高保真模型与业务对象确认.md
Normal file
81
wishfulfilled-wiki/02_项目管理流程/阶段2_高保真模型与业务对象确认.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
type: process_stage
|
||||
tags: [项目管理流程, 阶段2, 高保真模型, 业务对象, 前端, 产品]
|
||||
aliases: [高保真模型确认, 业务对象确认, Gate 2, 统一业务对象模型]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 前端 / 产品经理
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 阶段2 高保真模型与业务对象确认
|
||||
|
||||
## 核心目标
|
||||
|
||||
把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效,前端必须深度参与。
|
||||
|
||||
## 负责人
|
||||
|
||||
- 前端
|
||||
- 产品经理
|
||||
|
||||
## 输入
|
||||
|
||||
- 阶段1形成的主流程、页面结构、按钮盘点、分支流程、异常流程和 Vibe Coding 验证记录。
|
||||
|
||||
## 关键动作
|
||||
|
||||
- 将业务原型收敛为高保真模型。
|
||||
- 明确页面结构、交互、按钮行为和状态变化。
|
||||
- 确认业务对象、字段、状态和对象关系。
|
||||
- 明确 V1/V2 范围和项目周期。
|
||||
- 进行前端技术评审和技术预检。
|
||||
- 识别性能、安全、权限、并发、日志、可回滚等风险。
|
||||
|
||||
## 输出/交付物
|
||||
|
||||
- `07_高保真模型.html`
|
||||
- `07_高保真模型说明.md`
|
||||
- `08_项目周期与版本确认.md`
|
||||
- `09_前端技术评审.md`
|
||||
- `10_技术预检记录.md`
|
||||
- `10A_统一业务对象模型.md`
|
||||
- `10B_按钮行为矩阵.md`
|
||||
|
||||
## 检查清单
|
||||
|
||||
- [ ] 页面是否已经从粗糙原型收敛成可开发模型?
|
||||
- [ ] 按钮行为是否明确?
|
||||
- [ ] 业务对象、字段、状态、对象关系是否明确?
|
||||
- [ ] V1/V2 范围是否明确?
|
||||
- [ ] 是否完成前端技术评审?
|
||||
- [ ] 是否完成性能、安全、权限、并发、日志、可回滚预检?
|
||||
- [ ] 是否明确高保真模型确认后才允许正式开发?
|
||||
|
||||
## 风险点
|
||||
|
||||
- 前端介入太晚,导致页面、接口、数据库互相倒逼。
|
||||
- 高保真模型只画页面,没有确认业务对象和状态。
|
||||
- 没有按钮行为矩阵,开发和测试无法对齐。
|
||||
- 未提前识别性能、安全、权限、并发、日志、回滚风险。
|
||||
|
||||
## Gate 2 通过标准
|
||||
|
||||
高保真模型通过:页面收敛、按钮行为、业务对象、状态、V1/V2 明确。
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 什么时候需要前端提前参与?
|
||||
|
||||
阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用,前端应在需求收敛时提前参与。
|
||||
|
||||
### 统一业务对象模型为什么重要?
|
||||
|
||||
统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[阶段1_业务需求完整形成]]
|
||||
- [[阶段2.5_测试提前补漏]]
|
||||
- [[../01_业务流程/业务对象字典]]
|
||||
- [[阶段交付物清单]]
|
||||
77
wishfulfilled-wiki/02_项目管理流程/阶段3_研发协作与正式开发.md
Normal file
77
wishfulfilled-wiki/02_项目管理流程/阶段3_研发协作与正式开发.md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
type: process_stage
|
||||
tags: [项目管理流程, 阶段3, 研发协作, 正式开发, 代码治理, 安全]
|
||||
aliases: [研发协作, 正式开发, Gate 3, 开发联调]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 前端 / 后端 / 算法
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 阶段3 研发协作与正式开发
|
||||
|
||||
## 核心目标
|
||||
|
||||
基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。
|
||||
|
||||
## 负责人
|
||||
|
||||
- 前端
|
||||
- 后端
|
||||
- 算法
|
||||
|
||||
## 输入
|
||||
|
||||
- 高保真模型。
|
||||
- 统一业务对象模型。
|
||||
- 按钮行为矩阵。
|
||||
- 测试用例初稿与需求补漏结果。
|
||||
- 技术预检记录。
|
||||
|
||||
## 关键动作
|
||||
|
||||
- 拆分研发任务与协作计划。
|
||||
- 进行前端、后端、算法技术实现对接。
|
||||
- 明确接口、数据库、权限、安全、日志和回滚方案。
|
||||
- 按代码治理与安全规范开发。
|
||||
- 记录开发问题与联调结果。
|
||||
- 治理 AI 生成代码,不能直接堆进生产。
|
||||
|
||||
## 输出/交付物
|
||||
|
||||
- `12_研发任务拆分与协作计划.md`
|
||||
- `13_技术实现对接.md`
|
||||
- `14_代码治理与安全规范.md`
|
||||
- `15_开发问题与联调记录.md`
|
||||
|
||||
## 检查清单
|
||||
|
||||
- [ ] 研发任务是否已拆分?
|
||||
- [ ] 前后端、数据库、权限、安全、主要流程是否联调完成?
|
||||
- [ ] 是否按统一业务对象模型设计接口和数据库?
|
||||
- [ ] 是否处理权限、安全、日志、可回滚?
|
||||
- [ ] AI 生成代码是否经过人工审查和治理?
|
||||
- [ ] 是否避免重复代码和不可维护堆叠?
|
||||
|
||||
## 风险点
|
||||
|
||||
- 开发直接从 Vibe Coding 原型开始,跳过高保真模型。
|
||||
- AI 生成代码未经治理直接进入生产。
|
||||
- 缺少模块边界、权限、安全、日志和回滚方案。
|
||||
- 前后端、数据库、测试使用的业务对象不一致。
|
||||
|
||||
## Gate 3 通过标准
|
||||
|
||||
开发联调通过:前后端、数据库、权限、安全、主要流程联调完成。
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 阶段3如何保证模块化、安全和可维护?
|
||||
|
||||
依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理,不能直接堆进生产。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[阶段2.5_测试提前补漏]]
|
||||
- [[阶段4_测试培训上线回流]]
|
||||
- [[阶段交付物清单]]
|
||||
77
wishfulfilled-wiki/02_项目管理流程/阶段4_测试培训上线回流.md
Normal file
77
wishfulfilled-wiki/02_项目管理流程/阶段4_测试培训上线回流.md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
type: process_stage
|
||||
tags: [项目管理流程, 阶段4, 测试, 培训, 上线, 回流]
|
||||
aliases: [测试培训上线回流, 上线验收, Gate 4]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 测试 / 业务主管
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 阶段4 测试培训上线回流
|
||||
|
||||
## 核心目标
|
||||
|
||||
完成测试、培训、上线验收和问题回流。测试保证系统真实可用,并帮助业务人员正确使用。
|
||||
|
||||
## 负责人
|
||||
|
||||
- 测试
|
||||
- 业务主管
|
||||
|
||||
## 输入
|
||||
|
||||
- 开发联调完成的系统。
|
||||
- 测试用例。
|
||||
- 高保真模型和业务对象模型。
|
||||
- 开发问题与联调记录。
|
||||
|
||||
## 关键动作
|
||||
|
||||
- 进行正式测试。
|
||||
- 验证主流程、分支流程、权限、异常和数据。
|
||||
- 输出正式测试报告。
|
||||
- 将测试用例转成业务操作手册或内部培训材料。
|
||||
- 组织业务确认和上线验收。
|
||||
- 记录上线问题并回流需求池。
|
||||
|
||||
## 输出/交付物
|
||||
|
||||
- `16_正式测试报告.md`
|
||||
- `17_内部培训手册.md`
|
||||
- `18_上线验收记录.md`
|
||||
- `19_上线问题与回流需求.md`
|
||||
|
||||
## 检查清单
|
||||
|
||||
- [ ] 正式测试是否通过?
|
||||
- [ ] 主流程是否验证通过?
|
||||
- [ ] 分支流程是否验证通过?
|
||||
- [ ] 权限是否验证通过?
|
||||
- [ ] 异常和数据边界是否验证通过?
|
||||
- [ ] 内部培训手册是否完成?
|
||||
- [ ] 业务主管是否完成上线确认?
|
||||
- [ ] 上线问题是否记录并回流?
|
||||
|
||||
## 风险点
|
||||
|
||||
- 只测功能,不测权限、异常、数据和实际操作路径。
|
||||
- 没有培训材料,业务人员不会用。
|
||||
- 上线问题没有进入回流需求池。
|
||||
- 业务主管未验收就上线。
|
||||
|
||||
## Gate 4 通过标准
|
||||
|
||||
上线验收通过:测试通过、业务确认、培训完成。
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 上线前需要检查哪些事项?
|
||||
|
||||
至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[阶段3_研发协作与正式开发]]
|
||||
- [[项目检查清单]]
|
||||
- [[阶段交付物清单]]
|
||||
42
wishfulfilled-wiki/02_项目管理流程/阶段交付物清单.md
Normal file
42
wishfulfilled-wiki/02_项目管理流程/阶段交付物清单.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
type: deliverable_index
|
||||
tags: [项目管理流程, 交付物, 文件清单]
|
||||
aliases: [交付物清单, 文件结构, 产出物]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 内部技术团队
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 阶段交付物清单
|
||||
|
||||
## 完整版交付物
|
||||
|
||||
| 阶段 | 交付物 |
|
||||
|---|---|
|
||||
| 阶段0 | `00_项目入口分级.md` |
|
||||
| 阶段1 | `01_主流程说明.md`、`02_日常操作页面结构.md`、`03_功能页面按钮盘点表.md`、`04_分支流程_XXX.md`、`05_异常流程_XXX.md`、`06_VibeCoding页面验证记录.md` |
|
||||
| 阶段2 | `07_高保真模型.html`、`07_高保真模型说明.md`、`08_项目周期与版本确认.md`、`09_前端技术评审.md`、`10_技术预检记录.md`、`10A_统一业务对象模型.md`、`10B_按钮行为矩阵.md` |
|
||||
| 阶段2.5 | `11_测试用例初稿与需求补漏.md` |
|
||||
| 阶段3 | `12_研发任务拆分与协作计划.md`、`13_技术实现对接.md`、`14_代码治理与安全规范.md`、`15_开发问题与联调记录.md` |
|
||||
| 阶段4 | `16_正式测试报告.md`、`17_内部培训手册.md`、`18_上线验收记录.md`、`19_上线问题与回流需求.md` |
|
||||
| 阶段5 | `20_技术债清单.md`、`21_业务原子能力沉淀清单.md`、`22_组件库与服务复用清单.md`、`23_AI开发上下文模板更新记录.md` |
|
||||
|
||||
## 轻量版交付物
|
||||
|
||||
| 阶段包 | 交付物 |
|
||||
|---|---|
|
||||
| 入口 | `00_项目入口分级.md` |
|
||||
| 需求 | `01_业务需求包.md` |
|
||||
| 模型 | `02_高保真模型包.md` |
|
||||
| 预检 | `03_项目版本与技术预检.md` |
|
||||
| 测试补漏 | `04_测试用例初稿与需求补漏.md` |
|
||||
| 研发 | `05_研发协作与技术实现包.md` |
|
||||
| 治理 | `06_代码治理与安全规范.md` |
|
||||
| 上线 | `07_测试培训上线包.md` |
|
||||
| 沉淀 | `08_技术债与能力沉淀包.md` |
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[AI驱动内部系统开发流程_V3_总览]]
|
||||
- [[项目检查清单]]
|
||||
70
wishfulfilled-wiki/02_项目管理流程/项目检查清单.md
Normal file
70
wishfulfilled-wiki/02_项目管理流程/项目检查清单.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
type: checklist
|
||||
tags: [项目管理流程, 检查清单, 门禁]
|
||||
aliases: [项目门禁检查, 上线检查, 流程检查]
|
||||
source: AI_驱动_内部系统开发流程_V3.docx
|
||||
status: active
|
||||
owner: 内部技术团队
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 项目检查清单
|
||||
|
||||
## Gate 0 项目入口
|
||||
|
||||
- [ ] 确认项目值得做。
|
||||
- [ ] 确认项目类型:S / M / L。
|
||||
- [ ] 确认走轻流程还是完整流程。
|
||||
- [ ] 确认业务主管和技术负责人。
|
||||
|
||||
## Gate 1 需求完整
|
||||
|
||||
- [ ] 主流程完整。
|
||||
- [ ] 分支流程完整。
|
||||
- [ ] 页面、按钮、字段大致完整。
|
||||
- [ ] 状态大致完整。
|
||||
- [ ] Vibe Coding 页面已验证。
|
||||
|
||||
## Gate 2 高保真模型
|
||||
|
||||
- [ ] 页面已经收敛。
|
||||
- [ ] 按钮行为明确。
|
||||
- [ ] 业务对象明确。
|
||||
- [ ] 状态明确。
|
||||
- [ ] V1/V2 明确。
|
||||
- [ ] 性能、安全、权限、并发、日志、可回滚已预检。
|
||||
|
||||
## Gate 2.5 测试补漏
|
||||
|
||||
- [ ] 测试用例初稿已完成。
|
||||
- [ ] 主流程、分支、权限、异常、数据、按钮行为已检查。
|
||||
- [ ] 阻塞开发的问题已处理。
|
||||
|
||||
## Gate 3 开发联调
|
||||
|
||||
- [ ] 前后端联调完成。
|
||||
- [ ] 数据库联调完成。
|
||||
- [ ] 权限和安全联调完成。
|
||||
- [ ] 主要流程联调完成。
|
||||
- [ ] AI 代码已治理。
|
||||
|
||||
## Gate 4 上线验收
|
||||
|
||||
- [ ] 正式测试通过。
|
||||
- [ ] 业务确认完成。
|
||||
- [ ] 培训完成。
|
||||
- [ ] 上线问题回流机制明确。
|
||||
|
||||
## Gate 5 技术债治理
|
||||
|
||||
- [ ] 技术债已分类。
|
||||
- [ ] 必须立即处理的已处理。
|
||||
- [ ] 可延后的进入技术债池。
|
||||
- [ ] 可复用组件已沉淀。
|
||||
- [ ] 可复用后端服务已沉淀。
|
||||
- [ ] AI 开发上下文模板已更新。
|
||||
|
||||
## 关联条目
|
||||
|
||||
- [[AI驱动内部系统开发流程_V3_总览]]
|
||||
- [[阶段交付物清单]]
|
||||
Reference in New Issue
Block a user