docs: 初始化如愿知识库

02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md

@@ -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_测试培训上线回流]]
+- [[角色职责矩阵]]
+- [[阶段交付物清单]]
+- [[项目检查清单]]

02_项目管理流程/README.md

@@ -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 代码必须治理，不能直接堆进生产。

02_项目管理流程/常见问题FAQ.md

@@ -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_总览]]

02_项目管理流程/角色职责矩阵.md

@@ -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_测试培训上线回流]]

02_项目管理流程/阶段0_项目入口分级.md

@@ -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_总览]]
+- [[角色职责矩阵]]
+- [[阶段交付物清单]]

02_项目管理流程/阶段1_业务需求完整形成.md

@@ -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_高保真模型与业务对象确认]]
+- [[角色职责矩阵]]
+- [[阶段交付物清单]]

02_项目管理流程/阶段2.5_测试提前补漏.md

@@ -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_研发协作与正式开发]]
+- [[项目检查清单]]

02_项目管理流程/阶段2_高保真模型与业务对象确认.md

@@ -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_业务流程/业务对象字典]]
+- [[阶段交付物清单]]

02_项目管理流程/阶段3_研发协作与正式开发.md

@@ -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_测试培训上线回流]]
+- [[阶段交付物清单]]

02_项目管理流程/阶段4_测试培训上线回流.md

@@ -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_研发协作与正式开发]]
+- [[项目检查清单]]
+- [[阶段交付物清单]]

02_项目管理流程/阶段交付物清单.md

@@ -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_总览]]
+- [[项目检查清单]]

02_项目管理流程/项目检查清单.md

@@ -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_总览]]
+- [[阶段交付物清单]]