听写助手对话记录：文档关联关系图分架构拆分¶
记录编号：DLG-20260804-15 日期：2026-08-04 智能体：听写（DT） 参与方：项目发起人（用户）、听写 沟通渠道：AI 助手对话 主题：agents.md 文档关联关系图拆分为「业务设计架构」和「项目管理架构」两个独立 Mermaid 图
一、用户需求¶
用户反馈 V6.0 的「文档关联关系图」节点和关系线太多太杂，要求拆分：
- 业务设计架构图：包含 RQD、CPT、QMD、TND 全部文档以及关联线条
- 项目管理架构图：包含剩余的 PMG、GLY、ARC、WLG、PJM 全部文件以及关系线条
- 这样看起来更容易些
二、工作过程记录¶
步骤 1：设计拆分策略与跨架构边界¶
原单图 16 个文档节点 × 24 条关系线 × 12 条全局虚线，拆分后：
| 架构 | 节点数 | 主关系线 | 跨架构连接数 | 核心归属 |
|---|---|---|---|---|
| 项目管理架构（PM） | 5 个 | R1/R3/R4/R5/R7（5 条） | 2 出 + 2 全局 | PMG、PJM、GLY、WLG、ARC |
| 业务设计架构（BIZ） | 11 个 | R8~R24（17 条） | 2 入 + 2 全局 | RQD（4）+ QSV/CPT（5）+ TND（2） |
跨架构连接不重复画，统一规则：
- 管理架构侧：用虚线菱形占位锚点 + ★跨架构 标注 → 标明"到业务架构哪里"
- 业务架构侧：用虚线菱形占位锚点 + ★跨架构入←管理架构 标注 → 标明"从管理架构哪条关系来"
- 避免同一条关系线被绘制两次
步骤 2：跨架构连接映射表¶
| 关系编号 | 管理架构侧（出） | 业务架构侧（入） | 说明 |
|---|---|---|---|
| R2 | PMG -.→ BIZ_RQD ★跨架构 |
MG_R2 ★跨架构入 -.→ RQD |
PMG 入口 → 业务需求目录 |
| R6 | PJM -.→ BIZ_RQDO ★跨架构 |
MG_R6 ★跨架构入 -.→ RQD-O |
PJM RACI 角色 → 执行级需求干系方 |
| GLY 全局 | GLY -.→ BIZ_ALL ★跨架构→业务全部 |
MG_GLY ★跨架构入 -.→ 6 个 BIZ 节点 |
术语支撑所有业务文档 |
| WLG 全局 | WLG -.→ BIZ_ALL ★跨架构→业务 |
MG_WLG ★跨架构入 -.→ 3 个 BIZ 节点 |
变更记录追溯业务文档 |
步骤 3：拆分后两个 Mermaid 图写入 agents.md¶
图 1 - 项目管理架构（PM） 特色： - 节点 5 个（PMG ★入口 / GLY ★全局术语源 / WLG ★全局过程追溯 标识高亮） - 着色：浅沙金（品牌辅色） - 跨架构锚点：虚线菱形边框 + 浅背景，视觉上区分于真节点 - GLY/WLG 分别分两边：「管理内支撑」和「跨架构→业务全局」各一条路径
图 2 - 业务设计架构（BIZ） 特色： - 4 层分区配色：深墨绿（需求）→ 青绿（服务）→ 蓝色（技术），符合阅读流 - 顶部跨架构入边 4 个锚点，菱形虚线框 - R21（CPT-D → QSV-D/QMD）加粗，突出核心数据闭环反哺 - 17 条业务实线（R8~R24）清晰呈现「目录→子文档」+「战略→业务→执行」+「需求驱动→服务内部→技术落地」全链路
步骤 4：关系详情表扩展新增「所属架构」列¶
原表 5 列（关系编号/源文档/→目标文档/关系类型/详细说明） → 扩展为 7 列：
1. 关系编号
2. 所属架构（新增列）：管理架构 / 业务架构 / 跨架构（管→业） / 跨架构（全局）
3. 源文档
4. →（独立方向列，保证源/目标严格分列，不再出现 "PMG ← GLY" 合并写法）
5. 目标文档
6. 关系类型
7. 详细说明
同步修正原表 3 处双向关系方向一致性问题： - R3 「PMG ← GLY」 统一方向 → 「GLY → PMG」，说明中标注「双向语义」 - R4 「PMG ← WLG」 统一方向 → 「WLG → PMG」，说明中标注「双向语义」 - R7 「ARC ← WLG」 统一方向 → 「WLG → ARC」，说明中标注
步骤 5：版本、快速上手、修订记录同步¶
- agents.md 头部版本：V6.0 → V6.1
- 快速上手步骤 3：原单个「文档关联关系图」链接 → 拆为 「项目管理架构图」+「业务设计架构图」+「详情表」 三个锚点链接
- 修订记录新增 V6.1 条目，四项修改点
三、结论与产出¶
本次对话产出物清单¶
| 序号 | 产出物 | 位置 | 版本变更 |
|---|---|---|---|
| 1 | agents.md：项目管理架构 Mermaid 图（5 节点） | agents.md §架构一 | V6.0 → V6.1 |
| 2 | agents.md：业务设计架构 Mermaid 图（11 节点） | agents.md §架构二 | V6.0 → V6.1 |
| 3 | 文档关系详情表：新增「所属架构」列 + 源/目标分列规范化 | agents.md §详情表 | V6.0 → V6.1 |
修改前后对比¶
| 维度 | 修改前（V6.0 单图） | 修改后（V6.1 双架构图） |
|---|---|---|
| 图数量 | 1 张 | 2 张独立 Mermaid |
| 最大节点数 | 16 个（含管理+业务+技术） | 管理侧 5 个 / 业务侧 11 个，各图更聚焦 |
| 跨架构线处理 | 直接实线穿越两个区域，视觉混淆 | 菱形锚点 + ★跨架构 虚线标注，边界清晰 |
| 关系表架构归属 | 无归属，需阅读者脑补 | 新增「所属架构」列，6 种分类一目了然 |
| 关系方向 | R3/R4/R7 用「X ← Y」合并写法，方向不统一 | 全部改为「源 → 目标」单列，双向在说明中注明 |
四、关键决策与说明¶
- 为什么不把 R2/R6 完全删除？：即使跨架构，也必须在两端都有视觉暗示，否则会让单看一张图的读者疑惑"RQD 怎么来的？RQD-O 的 RACI 哪里定义的？"
- 为什么拆分为 PM/BIZ 而不是 DOC-A/DOC-P 分类？：用户明确要求按"业务设计/项目管理"语义拆分——管理类文档支撑流程，业务设计类文档支撑产品服务，PM/BIZ 名称更贴近团队角色视角
- GLY 版本号统一 V4.1：管理架构图中 GLY 节点版本从原 V3.0 更正为实际文档头 V4.1（同步前次 GLY 补充 ARC 后的版本）
- 全局支撑仍保留但收敛：原 GLY/WLG 各画 6+5 条虚线到所有业务节点 → 现在用 1 条「BIZ_ALL 锚点」简化管理侧，业务侧仍保留关键入边，不缺失视觉联系
五、待办事项¶
- 下次里程碑归档（ARV-V1.1 起），同步新版分架构的 agents.md
- 如果后续新增第 3 类架构（如代码开发架构 Dev），沿用「跨架构锚点」规范
六、修订记录¶
| 版本 | 日期 | 修订人 | 修订内容 |
|---|---|---|---|
| V1.0 | 2026-08-04 | DT | 创建 |
本记录由听写根据对话全过程整理。