docs: test reports + knowledge iteration design + PRDs
提交 OTP/RBAC/Tier0/Tier1/P0+P2 测试报告、方案A E2E 验证、知识库迭代设计(PRD/mermaid/html 原型)、项目状态看板更新; 根配置 docker-compose.yml/mkdocs.yml。
This commit is contained in:
Simon
@@ -51,6 +51,7 @@
|
||||
20. [邀请功能设计 — 多人会话协作](#20-邀请功能设计--多人会话协作)
|
||||
21. [应急降级页设计 — BC/DR 业务连续性保障](#21-应急降级页设计--bcdr-业务连续性保障)
|
||||
22. [阶段5 自动化闭环需求](#22-阶段5-自动化闭环需求)
|
||||
23. [开发协作规范](#23-开发协作规范精简版)
|
||||
|
||||
---
|
||||
|
||||
@@ -74,12 +75,20 @@
|
||||
|
||||
### 1.1 产品愿景
|
||||
|
||||
**一句话描述**：打造基于企业微信生态的**免费开源企业级IT服务台**，让IT支持像发微信一样简单。
|
||||
**一句话描述**：以 **Neo4j 知识图谱为真相源**、以**「服务即训练」闭环**为核心机制的企微 IT 智能服务台——让 IT 支持像发微信一样简单，并在每次对话中自动沉淀可遍历的知识网络。
|
||||
|
||||
**核心价值主张**：
|
||||
- **员工视角**：IT问题"像发微信一样简单"——AI先答、人工无缝衔接、不用切换窗口
|
||||
- **IT管理者视角**：低成本、高效率、可量化——坐席减负70%、AI解决80%、数据驱动决策
|
||||
- **CTO/IT负责人视角**：自主可控、安全合规——私有化部署、国产大模型集成、终端安全一体化
|
||||
- **差异化壁垒**：Neo4j 知识图谱（关系推理+路径规划+跨会话关联）——区别于通用 FAQ SaaS，本质是"会越用越聪明、能在对话中完成知识沉淀"的系统
|
||||
|
||||
**产品形态概要**（2026-07-07 对齐）：
|
||||
- **三角色互动**：员工 ⇄ AI Wingman ⇄ 坐席，AI 训练师在训练闭环中把关
|
||||
- **服务即训练闭环**：会话 → 知识迭代建议 → 内联审批 → 回灌 Wingman
|
||||
- **分诊式交互**：置顶悬浮卡片（是/否/概率选择题）、自适应澄清、专家模式开关、坐席代答
|
||||
- **多模态输入**：截图 → 本地千问视觉（Qwen-VL）理解回填
|
||||
- **三条输入通道**：A 会话→Dify / B 训练师手动 / C 文档→RAGFlow 预处理
|
||||
|
||||
### 1.2 产品定位
|
||||
|
||||
@@ -87,9 +96,11 @@
|
||||
|------|------|
|
||||
| **产品类型** | 企业级ITSM（IT服务管理） |
|
||||
| **目标客户** | 3000-10000人中型企业，使用企业微信 |
|
||||
| **核心差异** | 企微原生集成 + 终端安全（火绒+联软）+ AI混合策略 |
|
||||
| **核心差异** | 企微原生集成 + 终端安全（火绒+联软）+ **Neo4j 知识图谱（graph-native）** + AI 混合策略（Dify 生成+RAGFlow 预处理） |
|
||||
| **商业模式** | 社区版免费，专业版定制收费 |
|
||||
|
||||
> **2026-07-07 更新**：核心差异化已从「企微原生+终端安全」扩展为「**Neo4j 知识图谱**（关系推理/路径规划/跨会话关联），直接写图（解读2 合一），让知识迭代产出可遍历的知识网络」。见 §23 技术方向决策。
|
||||
|
||||
### 1.3 产品目标
|
||||
|
||||
1. **效率目标**：AI首答解决率≥80%，人工坐席响应时间≤60秒
|
||||
@@ -110,6 +121,7 @@
|
||||
| **VIP员工**（总监及以上） | "我的VPN怎么连不上" | 不想排队等待、要求优先处理 | 优先响应、专属通道 |
|
||||
| **IT坐席** | "每天处理50个重复问题" | 重复回答、手工录入、低效沟通 | 智能辅助、快捷回复 |
|
||||
| **IT主管** | "如何提升团队效率" | 缺乏数据、难以量化、经验流失 | 数据看板、绩效分析 |
|
||||
| **AI训练师** | "如何让知识库更智能" | 手写KB低效、与坐席工作重叠、知识无法沉淀 | 服务即训练闭环、内联审批、知识迭代自动提案 |
|
||||
| **系统管理员** | "配置新功能上线" | 操作复杂、风险难控、权限混乱 | 简单配置、权限明晰 |
|
||||
|
||||
### 1.4.2 典型用户场景
|
||||
@@ -1431,6 +1443,28 @@ ALTER TABLE agents ADD COLUMN mfa_bound_at TIMESTAMP;
|
||||
| 开发者 | 宋献，IT支持组组长，开发零基础，通过学习+AI辅助完成开发 | ✅ 持续进行 |
|
||||
| 企微设备管理 | 企微设备管理API | ❌ 付费功能，公司未购买 |
|
||||
|
||||
### 11.1 技术方向决策（2026-07-07 知识库迭代锁定）
|
||||
|
||||
> **状态**: 正式决策 | **见**: [增量PRD](../增量PRD-知识库迭代与痛点缓解-20260707.md)（注：增量PRD在 02-需求分析 目录）、[技术方案-复杂场景重构](../../03-技术架构/02-技术方案/技术方案-复杂场景重构.md)
|
||||
|
||||
| 决策 | 锁定结果 |
|
||||
|------|---------|
|
||||
| **D1 存储边界** | 解读2 合一 — **直接写 Neo4j 图**，图即真相源，非 flat KB 存储替换。这是核心差异化价值点。 |
|
||||
| **D2 AI 后端** | Dify 生成（复用 WingmanService 范式）+ RAGFlow 上游 ingestion/ETL 预处理；互补非二选一。 |
|
||||
| **D3 置信门控** | 全局阈值 <0.7，低于时渲染「转人工」入口 + 上下文。 |
|
||||
| **D4 一次一问** | 分诊卡片自适应 + 专家模式开关。 |
|
||||
| **D5 vision** | 本地化千问视觉 Qwen-VL，经 Dify 后端。 |
|
||||
| **D6 截图隐私** | 仅保留接口，待与 DLP 整合（敏感词维持 WARN）。 |
|
||||
| **D7 训练师审批** | 聊天内联审批 + 未处理转独立队列 + 默认待审。 |
|
||||
| **D8 audience** | 按来源会话类型自动标 + 坐席可改。 |
|
||||
| **D9 坐席代答** | 仅排除错误项 + 用户最终确认 + 手动推荐标记。 |
|
||||
|
||||
**三条知识输入通道**：A 会话→Dify（自动）/ B 训练师手动 / C 文档→RAGFlow 预处理。
|
||||
|
||||
**graph-native 重心**：直接对齐 [技术方案-复杂场景重构](../../03-技术架构/02-技术方案/技术方案-复杂场景重构.md) 的 TeliChat 白盒图模型；图承载关系推理、路径规划、跨会话关联、相似合并去重；上层能力消费图结构，不可退化为"仅把 Neo4j 当存储替换"。
|
||||
|
||||
**不在范围**：敏感词 BLOCK 升级（WARN）、复杂场景引擎、DLP 实质整合。
|
||||
|
||||
---
|
||||
|
||||
## 12. 数据模型核心设计
|
||||
@@ -2997,6 +3031,45 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## 23. 开发协作规范（精简版）
|
||||
|
||||
> **来源**: 原独立文档 SOP-06（2026-07-07 固化），内容精简并入此处。完整 SOP 流程见 `docs/10-项目管理/SOPs-标准流程/` 系列。
|
||||
|
||||
### 23.1 团队角色与协作铁律
|
||||
|
||||
| 角色 | Agent ID | 职责 |
|
||||
|------|-----------|------|
|
||||
| 主理人/交付总监 | —（编排者） | 创建团队、调度成员、中转消息、汇总交付；不代写任何专业产出 |
|
||||
| 产品经理 | `software-product-manager` | PRD、市场竞品研究 |
|
||||
| 架构师 | `software-architect` | 系统架构设计 + 任务分解 |
|
||||
| 工程师 | `software-engineer` | 代码实现 + IS_PASS 全局一致性审查 |
|
||||
| QA工程师 | `software-qa-engineer` | 测试验证 + 智能路由判定 |
|
||||
|
||||
**四条铁律**：
|
||||
1. 团队只能主理人创建（TeamCreate），严禁委派成员自建
|
||||
2. 成员产出经主理人中转，禁止互连
|
||||
3. 专业产出（PRD/架构/代码/测试）由对应成员输出，主理人只汇编
|
||||
4. 严禁代写成员产出、跳过前序阶段
|
||||
|
||||
### 23.2 工作流路由
|
||||
|
||||
| 场景 | 工作流 |
|
||||
|------|--------|
|
||||
| 单页应用/小游戏/≤10 源文件 | ⚡ 快速模式：TeamCreate → 工程师 → QA |
|
||||
| 明确 Bug（非新功能） | 🔧 BugFix：TeamCreate → 工程师定位修复 → QA 回归 |
|
||||
| 中大型需求（>10 源文件） | 🏗️ 标准 SOP：PM(PRD) → 架构师(设计+任务) → 工程师(IS_PASS) → QA(智能路由) |
|
||||
| 增量变更 | 标准 SOP 增量：PRD(仅变更部分) → 架构(增量设计) → 工程(最小变更) → QA(全量回归) |
|
||||
|
||||
### 23.3 质量关卡
|
||||
|
||||
- 工程师完成全部文件后必须 IS_PASS: YES（最多 2 轮审查）
|
||||
- QA 每轮测试后智能路由判定（源码Bug→回工程 / 测试Bug→自修 / 全过→成功）
|
||||
- 最多 2 轮测试，仍不过输出报告标注遗留问题
|
||||
|
||||
### 23.4 子任务命名（必记）
|
||||
|
||||
调度成员时 `name` 和 `subagent_type` 必须为同一 Agent ID：`software-product-manager` / `software-architect` / `software-engineer` / `software-qa-engineer`。
|
||||
|
||||
## 附录 A: 术语表
|
||||
|
||||
| 术语 | 说明 |
|
||||
|
||||
Reference in New Issue
Block a user