Legal Visualization

Legal Visualization

面向法律业务场景的法律图解与图表生成技能。覆盖案件、非诉项目、合规管理、客户协作、团队办案、客户汇报和法律服务方案，生成可直接提交、汇报或嵌入文档的法律图表。对外英文名使用 Legal Visualization，中文可称“法律可视化”；Skill 标识和目录名统一为 legal-visualization。draw.io / diagrams.net 是默认可编辑底层格式，不是对外定位的边界。

硬约束

1. 缺失事实必须显式标注：材料中未见的主体、时间、金额、合同、证据，不得出现在图中；必须显式写"待补充/待核/一方主张"，禁止补全或推断。 2. 业务条线优先于图型：先识别"诉讼/公司/合规/知产/争议/合同/客户/服务"等业务条线，再选图型。 3. VizSpec.routing 必填：未填 routing.primary_scene 与 routing.selection_reason 禁止写 drawio。 4. 一图一观点：超过 1 个核心观点必须拆主图+附图，禁止堆叠。

默认目标

• 默认交付三件套：.drawio 源文件、.svg 矢量图、.png 高清预览图；SVG 和 PNG 都从 .drawio 通过 draw.io / diagrams.net 导出。
• 用户要求庭审、报告、PPT 或归档时，按需追加 PDF。
• PNG 默认按 2 倍倍率导出；如用于打印、大屏汇报或高清插图，可通过 --png-scale 3 或 --png-scale 4 提高清晰度。
• 默认追求一步到位出图；只有在导出工具不可用或材料关键事实缺失时，才把 draw.io 手工编辑作为兜底。
• 图表必须服务一个核心观点或一个清晰的信息任务，不把所有材料堆进一张图。
• 自动导出的 .drawio、图片和报告默认进入 archive/<timestamp>/，避免污染 templates/ 或源文件目录。

依赖

开箱即用

• 生成 .drawio XML、读取参考文件、执行 scripts/validate_drawio.py 仅需 Python 3 标准库。
• 没有 draw.io CLI 时，仍可交付 .drawio 源文件，并在最终说明中标明图片导出未完成。

可选依赖

工作流

1. 提取制图任务：从材料中提取受众、案件/项目类型、核心问题、主体、时间、金额、标的物、流程、证据、风险、客户动作、团队动作和用户立场。缺少非关键事实时先合理标注“待补充”，不要停下等待。 2. 确定受众：给法官的图保持客观、克制、可核对；给客户的图突出策略、风险和可能结果；给业务团队的图突出流程、责任和交付物；给律师团队的图可以保留更多细节和证据索引。 3. 路由场景：先读 references/scene-routing-guide.md，按受众、任务动词、材料阶段和信息形态筛出 1-3 个候选场景；再读 references/scene-library.md 中对应章节定主场景。不要直接在完整场景库中凭关键词跳选。scene_id 选定后，从 references/chart-decision-tree.md 选图型变体与节点布局；该决策树是路由的下游，不替代路由。 4. 解决冲突：如果多个场景都能命中，按“用户指定 > 受众匹配 > 更窄业务领域 > 当前材料阶段 > 通用场景”选择主图；未选场景只作为附图候选。 5. 确定内容：按“全面罗列 -> 逻辑整合 -> 精简内容”处理材料。复杂案件先做细节图，再按核心主体、核心时间线或核心法律关系组合。 6. 生成 VizSpec：按 references/vizspec-schema.md 先写结构化制图规格，明确路由结论、场景 ID、主图观点、节点、连线、分区、注释和待核事实。 7. 编排图面：按 references/visual-composition-rules.md 和 references/scene-composition-playbook.md 控制图表逻辑、配色、线条、注释和重点表达；复杂案件、制度路径、背景趋势、票据回路和工期延误类图表还要读 references/advanced-case-patterns.md。颜色、字体、起始坐标、节点尺寸等视觉常量全部按 references/legal-visual-constants.md 取值，禁止在图中硬编码。节点命名按 references/naming-conventions.md 规范。 8. 生成 draw.io：按 references/xml-reference.md 写 .drawio XML；templates/ 仅作为可打开的 draw.io 模板起点，XML 写法示例见 references/xml-example-*.md。 9. 导出图片：按 references/output-workflow.md 导出 SVG/PNG/PDF，并保留 .drawio。导出后检查图片非空、文字不截断、主体不拥挤。 10. 质检交付：按 references/quality-checklist.md 自查后，再向用户说明输出文件、使用场景和未能验证的环节。

场景路由速查

关键原则

• 一张图只表达一个主观点；多个观点拆成多张图或多页图。
• 颜色必须有含义：同主体同色，同类型关系同线型，争议/风险/违约用强调色，辅助事实用灰色。
• 避免线条交叉和长距离绕行；连接多的主体放在中心或靠近相关节点。
• 图表主体只放短标签；长事实、证据编号、条文依据放侧栏、底注或附表。
• 对法官提交的图，不夸张表达，不把争议事实画成既定事实；争议或待证事实用虚线、问号、标注或灰色处理。

输出格式

• [图名].drawio：源文件，必须随图片一起交付，便于用户继续编辑。
• [图名].svg：从 .drawio 导出的矢量图，适合 Word、PPT、网页和继续缩放。
• [图名].png：从 .drawio 导出的高清预览图，适合微信、飞书、邮件正文、普通预览。
• [图名].pdf：适合归档、打印或正式附件。
• archive/<timestamp>/export-report.json：批量导出报告，记录 .drawio 源文件、导出工具、输出文件和轻量检查结果。

参考文件

• references/scene-library.md：法律图表场景索引和路由规则。
• references/scene-routing-guide.md：大场景库下的选择规则、评分法和冲突处理。
• references/scene-routing-evals.md：场景路由测试集，用于检查误选和冲突。
• references/scene-composition-playbook.md：场景编排手册，说明各类场景怎么取舍和布局。
• references/vizspec-schema.md：结构化制图规格，用来稳定生成图表。
• references/visual-composition-rules.md：法律图表编排规则。
• references/advanced-case-patterns.md：复杂案件和高阶论证图的编排套路。
• references/output-workflow.md：一步到位生成 .drawio 与图片的操作流程。
• references/quality-checklist.md：交付前检查清单。
• references/xml-reference.md：draw.io XML 结构、样式、连线和容器规则。
• references/chart-decision-tree.md：scene_id 选定后选图型变体与节点布局。
• references/legal-visual-constants.md：视觉常量（页面、字体、调色板、线型）。
• references/naming-conventions.md：法律节点中文命名规范。
• references/template-guide.md：模板目录结构、模板清单和新增模板规则。
• references/xml-example-*.md：XML 语法示例，不放入模板目录。
• templates/：只存放可直接打开的 .drawio 模板，按英文业务目录组织。

实现提示

• XML 校验：python scripts/validate_drawio.py path/to/file.drawio，与 quality-checklist.md 第 32-38 行自检项对位。
• 批量导出：python scripts/export_drawio.py path/to/file.drawio 默认生成 .drawio + .svg + .png 三件套，并写入 archive/<timestamp>/export-report.json；PNG 默认 2 倍导出，需要更高清可加 --png-scale 3，如需旧行为可加 --in-place。
• 命名规范检查：python scripts/normalize_naming.py path/to/file.drawio path/to/spec.yaml，对照 naming-conventions.md 输出偏差清单。

Changelog

[0.6.14] - 2026-06-12

修复

• 修复 templates/litigation/three-line-flow.drawio 导出后连线标签与线条、节点边界重叠的问题。
• 保留三线关系的直连表达，将 edge 上的长标签改为独立文本块，避免导出 PNG/SVG 后文字重叠。

改进

• 在 references/visual-composition-rules.md 和 references/quality-checklist.md 增加连线标签避让规则，避免后续模板继续把长标签压在线上。

技术优化

• 重新导出三件套抽检，确认 .drawio、.svg、.png 均能生成，PNG 视觉检查未见文字重叠。

[0.6.13] - 2026-06-12

新增

• 新增 references/advanced-case-patterns.md，沉淀复杂案件、高阶论证图和图表化证据目录的编排套路。
• 新增 9 个 .drawio 模板，覆盖三线流向、统一入口流程、争点-证据矩阵、制度路径对比、工期延误进度、股权变动前后、项目平面标注、服务路线图和范围-交付物矩阵。

改进

• 在 references/visual-composition-rules.md 显性化 3S 精简原则，强化“简单、直接、服务策略”的取舍标准。
• 更新 references/template-guide.md、references/chart-decision-tree.md 和 references/scene-composition-playbook.md，让新增模板进入模板索引、图型选择和模板优先级表。
• 修正新增模板中的主体称谓和争议/待补充状态标签，使其通过命名规范抽查。

技术优化

• 运行脚本编译、全量 draw.io XML 校验、命名规范抽查和三件套导出抽检，确认 .drawio + .svg + .png 默认交付链路可用。

[0.6.12] - 2026-06-12

改进

• 明确默认交付为 .drawio + .svg + .png 三件套：.drawio 是可编辑源文件，SVG 和 PNG 均由 draw.io / diagrams.net 从源文件导出。
• SKILL.md、references/output-workflow.md 和 references/template-guide.md 同步改为三件套表述。
• scripts/export_drawio.py 的帮助文本明确 --format 只控制图片格式，.drawio 源文件始终保留。

技术优化

• 增加默认导出抽检，确认未指定 --format 时输出目录包含 .drawio、.svg、.png 和 export-report.json。

[0.6.11] - 2026-06-12

改进

• scripts/export_drawio.py 默认将 .drawio 源文件与 PNG/SVG/PDF 一起写入输出目录，确保用户拿到图片后也能继续编辑源文件。
• 即使未检测到 draw.io CLI，导出流程也会尽量保留 .drawio 源文件，并在报告中说明图片未能自动导出。
• SKILL.md 和 references/output-workflow.md 明确要求交付目录必须包含 .drawio 源文件。

技术优化

• 导出报告新增 source_drawio 字段，记录源文件保存路径、大小和是否复制到归档目录。

[0.6.10] - 2026-06-12

改进

• 移除 Skill 内部关于特定外部来源的表述，不再在主入口、任务记录、变更记录或决策记录中引用该来源。
• 将 SKILL.md 定位改为“面向法律业务场景的法律图解与图表生成技能”。
• 保留 Legal Visualization / “法律可视化”作为现行名称。

文档完善

• 更新技能级记录，并完成全文检索确认。

[0.6.9] - 2026-06-12

改进

• 将 Skill 目录从 legal-viz 迁移为 legal-visualization，让技术标识与对外英文名一致。
• 将 SKILL.md frontmatter name 调整为 legal-visualization，避免继续使用 Viz 缩写。
• 更新脚本帮助文本中的默认归档路径说明。

文档完善

• 更新 TASKS.md 和 DECISIONS.md 记录本轮内部标识迁移；历史记录中的旧名保留用于追溯。

[0.6.8] - 2026-06-12

改进

• 将对外英文名从中英混排的 Legal 可视化 调整为完整英文 Legal Visualization。
• 从现行 SKILL.md description 中移除 Legal Viz 缩写，避免继续使用用户不喜欢的缩写表达。
• 保留“法律可视化”作为中文触发词，并保留法律业务场景定位。

文档完善

• 更新脚本帮助文本和现行参考文件中的名称表述，历史记录中的旧称保留用于追溯。

[0.6.7] - 2026-06-12

改进

• 将对外展示名从“法律图表助手”调整为 Legal 可视化，强化法律可视化的名称体系。
• 在 SKILL.md description 中补充法律业务场景定位。
• 保留“法律图解与图表生成助手”作为中文功能说明，兼顾品牌延续和新用户理解。

文档完善

• 更新现行说明文件和脚本帮助文本中的名称表述，历史版本记录保留旧称用于追溯。

[0.6.6] - 2026-06-12

改进

• 删除根目录 CLAUDE.md，避免 Skill 内部保留平台专用说明文件。
• 保留 SKILL.md 作为唯一主入口，模板说明继续放在 references/template-guide.md，工作记录继续放在 CHANGELOG.md、DECISIONS.md 和 TASKS.md。

文档完善

• 更新 SKILL.md 版本号为 0.6.6，记录本轮结构清理。

[0.6.5] - 2026-06-12

改进

• 将对外展示名调整为“法律图表助手”，降低“法律可视化 / Legal Viz”对普通使用者的理解门槛。
• 优化 SKILL.md 触发描述，突出“把法律材料整理成关系图、流程图、时间轴、证据链、风险图、路线图”等具体任务。
• 保留 legal-viz、Legal Viz 和“法律可视化”作为兼容别名，不改动目录名和内部标识。

文档完善

• 更新 CLAUDE.md 和 TASKS.md，明确内部标识与对外名称的关系。

[0.6.4] - 2026-06-12

改进

• 整理 templates/ 目录：只保留可直接打开的 .drawio 模板，不再放置 Markdown 说明文件。
• 将业务条线目录改为英文命名：litigation/、corporate/、compliance/、contract/、intellectual-property/。
• 将 6 个 XML 语法示例从 templates/ 移入 references/，统一命名为 xml-example-*.md。
• 将原 templates/README.md 迁移为 references/template-guide.md，作为模板目录指南。

技术优化

• 更新 SKILL.md 和 CLAUDE.md，明确模板目录只存放 .drawio 文件，XML 示例和说明性文档统一放在 references/。

[0.6.3] - 2026-06-12

改进

• scripts/export_drawio.py 新增 --png-scale 参数，PNG 默认按 2 倍倍率导出，降低聊天分享、文档插图和汇报场景中的模糊感。
• 导出报告新增 png_scale 字段，便于追溯 PNG 清晰度设置。
• SKILL.md、references/output-workflow.md、CLAUDE.md 和 templates/README.md 同步补充高清 PNG 导出说明。

技术优化

• PNG 清晰度参数仅作用于 PNG，不改变 SVG/PDF 的默认输出逻辑。

[0.6.2] - 2026-06-12

新增

• 新增 archive/ 运行产物归档目录，使用目录内 .gitignore 忽略导出图片和报告，仅保留 .gitkeep。
• scripts/export_drawio.py 默认将 SVG/PNG/PDF 与 export-report.json 写入 archive/<timestamp>/。

改进

• scripts/export_drawio.py 增加 --output-dir、--archive-dir 和 --in-place 参数，支持指定归档目录或恢复旧的同目录导出行为。
• references/output-workflow.md 增加“归档机制”说明，明确运行产物不进入版本库。
• SKILL.md 和 CLAUDE.md 同步说明默认归档输出路径。

技术优化

• 导出文件名按 Skill 内相对路径生成，批量导出多目录模板时避免同名文件覆盖。

[0.6.1] - 2026-06-12

修复

• 修正 CLAUDE.md 中滞留的 0.5.1 状态、旧模板数量和旧目录结构说明。
• 修正 templates/诉讼/layered-timeline.drawio 中“对方”等口语化身份词，统一改为“原告/被告”。
• 修正 scripts/normalize_naming.py 对“证据目录”“证据初步梳理”等泛称的误报，避免把材料名称当成证据编号错误。

改进

• SKILL.md 新增“依赖”章节，明确开箱即用能力、可选 PyYAML 功能和 draw.io CLI 导出能力。
• scripts/export_drawio.py 调整为明确检测本机 draw.io / diagrams.net CLI，并增加 SVG viewBox、PNG/PDF 文件头等轻量导出检查字段。
• references/output-workflow.md 区分 CLI 自动导出、MCP/浏览器/桌面手动导出和无导出环境三类路径，避免脚本能力边界不清。

技术优化

• 增加常见 macOS draw.io / diagrams.net 应用路径检测，降低用户未配置命令行别名时的导出失败概率。

[0.6.0] - 2026-06-07

新增

• 新增 references/chart-decision-tree.md：在 scene-routing-guide.md 之后给出"业务条线→图型变体→关键考虑"决策表，是路由的下游不替代路由。
• 新增 references/naming-conventions.md：法律节点中文命名规范（程序身份、文书材料、证据编号、关系状态标签前缀、主体分组）。
• 新增 references/legal-visual-constants.md：把 output-workflow.md 第 37-39 行的硬编码常量（页面、字体、调色板、线型、节点尺寸）沉淀为单一事实源。
• 新增 scripts/validate_drawio.py：XML 自检脚本，对位 quality-checklist.md 第 32-38 行的 drawio XML 自检项。
• 新增 scripts/export_drawio.py：drawio 批量导出脚本，对位 output-workflow.md 第 47-49 行的导出策略；检测 drawio CLI/MCP，输出 export-report.json。
• 新增 scripts/normalize_naming.py：节点命名偏差检查，对照 naming-conventions.md 输出偏差清单。
• 新增 9 个业务条线 drawio 模板：templates/诉讼/{multi-party-relation,layered-timeline,litigation-route}.drawio、templates/公司/{equity-structure,transaction-architecture}.drawio、templates/合规/{compliance-risk-map,approval-matrix}.drawio、templates/合同/contract-review-swim.drawio、templates/知产/infringement-compare.drawio。

改进

• SKILL.md 顶部新增"硬约束"段（4 条）：缺失事实显式标注、业务条线优先于图型、VizSpec.routing 必填、一图一观点。
• SKILL.md 工作流第 3 步路由后追加 chart-decision-tree 引用；第 7 步编排图面后追加 visual-constants 与 naming-conventions 引用。
• SKILL.md 参考文件段新增 3 个 references；尾部新增"实现提示"段列出 3 个 scripts 的入口。
• references/output-workflow.md 把硬编码的 x=60, y=80、12-16px 字号、20-28px 标题改为引用 legal-visual-constants.md；导出策略段引用 scripts/export_drawio.py。
• references/visual-composition-rules.md 第 2 步末加 chart-decision-tree 引用，避免原则散落。
• references/quality-checklist.md 顶部"事实与法律表达"段引用 SKILL.md 硬约束；"draw.io XML"段引用 scripts/validate_drawio.py。
• references/vizspec-schema.md 字段说明表增加 entities[].role 与 status 的引用；关系状态样式段引用 legal-visual-constants.md。
• templates/README.md 重写为按业务条线子目录组织，并增加 scripts/常量/命名规范的引用段。

不变

• 对外契约（默认输出 .drawio+SVG/PNG/PDF、受众=律师、drawio 单引擎、触发描述）未变。
• 路由层（scene-routing-guide.md + scene-library.md）未变。
• 现有 6 份 XML 语法教程 .md 保留，仅作为"如何写 drawio XML"参考。

待办事项

• 沉淀剩余 6 个 P0 场景模板：法律关系图、分层时间轴、三线流向图、统一入口流程图、争点-证据矩阵、服务路线图。
• 补 5 个真实案例测试输入，验证 VizSpec→validate→normalize→export 全链路。
• 扩 scene-routing-evals.md 5 个高冲突用例，覆盖新业务条线。
• 跨平台适配：检测 macOS / Windows / Linux 下的 drawio CLI 路径差异。

[0.5.1] - 2026-06-02

新增

• 新增 scene-routing-guide.md，提供大场景库下的评分法、冲突处理和主图/附图选择规则。
• 新增 scene-routing-evals.md，提供 20 个高冲突测试用例，用于检查场景误选。

改进

• 更新 SKILL.md，将场景选择流程调整为先路由、再查场景库、再生成 VizSpec。
• 更新 vizspec-schema.md，增加 routing 字段，要求记录主场景、备选场景和未选原因。
• 更新 quality-checklist.md，增加场景路由与备选场景检查项。

待办事项

• 后续新增场景时同步补充高冲突路由测试用例，避免场景库膨胀后误选。

[0.5.0] - 2026-06-02

新增

• 新增法律全流程场景库，覆盖客户全生命周期、案件办理全流程、证据工作全生命周期、法律文书生产流程、企业经营全周期、争议解决路径全景和律师团队协作与项目管理。
• 在 scene-composition-playbook.md 中新增法律全流程场景编排规则，补充主图候选、必要字段和编排策略。

改进

• 更新 SKILL.md 触发描述和场景路由，使 Legal Viz 覆盖客户协作、团队办案、证据组织、文书生产和争议路径选择。
• 更新模板优先级，将客户生命周期路线图、案件办理路线图、证据生命周期图、文书生产流程图和争议路径选择图纳入 P0。

待办事项

• 后续增加法律全流程测试输入，验证客户生命周期、证据生命周期、案件办理路线和文书生产的一键出图质量。
• 将新增 P0 全流程图表沉淀为可复用 draw.io XML 片段。

[0.4.0] - 2026-06-01

新增

• 扩充法律业务场景库，新增法律服务方案、客户汇报、合同流程、企业合规、投融资并购、劳动人事、知识产权、数据合规、债务化解、家族财富和行政监管场景。
• 在 scene-composition-playbook.md 中新增法律业务场景编排规则，覆盖主图候选、必要字段和编排策略。

改进

• 更新 SKILL.md 触发描述和工作流表述，使 Legal Viz 覆盖案件、非诉项目、合规管理、客户汇报和服务方案。
• 更新模板优先级，将服务路线图、范围-交付物矩阵、合同审查泳道、合规风险地图和交易架构图纳入 P0。

待办事项

• 后续将新增 P0 业务图表沉淀为可复用 draw.io XML 片段。
• 增加客户服务方案类测试输入，验证非诉项目一键出图质量。

[0.3.0] - 2026-06-01

新增

• 新增 scene-composition-playbook.md，把场景索引扩展为可执行的图表编排手册。
• 新增 vizspec-schema.md，提供 Legal Viz 的结构化制图规格，提升一键出图稳定性。
• 新增 templates/README.md，说明现有模板定位和后续高频模板开发优先级。

改进

• 更新 SKILL.md 工作流，要求先生成 VizSpec，再按场景编排手册生成 draw.io。
• 将 scene-library.md 明确为场景索引，避免把索引误认为完整模板库。

[0.2.2] - 2026-06-01

改进

• 移除内部文件中的非产品化表述。
• 将方法文件改名为 visual-composition-rules.md，统一为自有法律图表编排规则。
• 将描述调整为“法律可视化”“法律图表”“案件图表”等中性表达。

文档完善

• 更新 SKILL.md、CLAUDE.md、TASKS.md、DECISIONS.md 和场景库说明。

[0.2.1] - 2026-06-01

改进

• 将 Skill name 从 legal-drawio 调整为 legal-viz，降低对 draw.io 工具名的传播依赖。
• 将对外展示名调整为 Legal Viz，中文定位保持“法律可视化”。
• 更新主入口描述，强调法律可视化场景优先，draw.io 作为默认可编辑源格式保留。

文档完善

• 更新 CLAUDE.md、TASKS.md、DECISIONS.md 中的命名和决策记录。

[0.2.0] - 2026-06-01

新增

• 新增首批法律图表场景库，覆盖通用图表、借款、票据、建设工程、土地与房地产、国际货物买卖、公司股权、证据和复合案件。
• 新增法律图表编排规则引用文件，沉淀受众、图表类型、内容筛选和表达规则。
• 新增一步到位输出流程，明确 .drawio、SVG、PNG、PDF 的默认交付策略。
• 新增质量检查清单，覆盖事实表达、场景选择、视觉版面、draw.io XML 和导出图片检查。
• 新增 CC-BY-NC 许可证文件。

改进

• 将技能主入口从 6 类图表模板扩展为以场景路由驱动的一键出图流程。
• 将默认交付从“生成 XML/按需导出”调整为“默认导出可用图片并保留 draw.io 源文件”。
• 更新 frontmatter，增加版本、许可证、作者和主页信息。

文档完善

• 新增 TASKS.md 记录当前升级与后续模板化任务。
• 新增 DECISIONS.md 记录 draw.io 源文件加默认图片交付的技术路线决策。

高级案例套路

本文件用于复杂案件和高阶论证图。scene-library.md 解决“选什么场景”，scene-composition-playbook.md 解决“基础怎么画”，本文件解决“如何把复杂材料压缩成有说服力的主图”。

适用条件

遇到以下情形时读取本文件：

• 案件材料跨越多年、多主体、多法律关系，一张普通关系图无法承载。
• 争点不是单一事实，而是不同制度路径、不同法律性质或不同处理结果的比较。
• 需要把市场背景、政策变化、工程进度、票据回路、股权变动等外部线索和案内事实叠加。
• 已有事实很多，但图表真正要表达的是责任归属、损失范围、主观意图或因果关系。

通用拆解顺序

1. 先做细节图：按合同、资金、票据、股权、工程节点、工商登记、程序节点分别拆开。 2. 找连接点：优先找共同主体、共同账户、同一票据、同一项目、同一合同、同一时间节点。 3. 确定主线：如果争点是取得时间、迟延期间或期限，选时间主线；如果争点是谁对谁承担权利义务，选法律关系主线；如果争点是不同规则导致不同结果，选制度路径主线。 4. 先组合后删减：组合总图后，用 3S 原则删去无关支线，保留能直接支撑主观点的节点。 5. 主图加附图：主图只回答一个问题，明细台账、证据目录、分支关系放附图。

七类高阶套路

1. 工期延误责任图

适用：多楼栋、多工序、多延误原因的建设工程案件。

编排方法：

• 先按楼栋或施工模块拆成若干时间轴。
• 再抽取共同延误逻辑，形成主图。
• 上半部分放计划进度，下半部分放实际进度。
• 关键延误区间用强调色，责任主体用分层或色块区分。
• 如果某一工序构成主要延误原因，单独放大该工序，标出延误天数和占比。

避免事项：

• 不把每个施工节点都塞进主图。
• 不只画总工期，必须标出关键工序、责任主体和证据来源。

2. 制度路径对比图

适用：同一事实在两种法律规则、政策路径或处理机制下产生不同结果。

编排方法：

• 左右两栏分别放路径 A 与路径 B。
• 起点保持一致，末端显示权利、资金、责任或程序结果差异。
• 中间节点只保留导致结果分叉的关键规则。
• 结果栏用同一指标表达，便于比较。

避免事项：

• 不把法律论证全文写进流程节点。
• 不把路径差异画成事实差异；事实相同、规则不同要明确分层。

3. 背景趋势叠加图

适用：当事人行为受市场、政策、价格、行业周期影响，需要证明行为动机或商业合理性。

编排方法：

• 上层用折线图表达背景趋势，如价格指数、材料价格、市场景气、监管节奏。
• 下层用时间轴表达案内关键行为。
• 用竖向参考线把背景变化和案内行为对齐。
• 结论栏写明背景变化如何解释行为选择。

避免事项：

• 外部数据必须标注来源和口径。
• 背景趋势只能辅助解释，不能替代证据证明。

4. 两张票据/两条资金路径对比图

适用：票据案件中存在多张票据、返还回路、损失抵扣或责任范围区分。

编排方法：

• 将两张票据拆成上下两条路径或左右两栏。
• 票面记载、实际流转、资金流向分别使用不同线型。
• 返还或抵扣款项只连接到对应票据，不跨线混用。
• 右侧统一计算损失差额和责任范围。

避免事项：

• 不把票面流转和实际流转混成一条线。
• 不让返还路径同时指向多个损失来源。

5. 真实意思/行为动机图

适用：需要透过表面行为解释当事人真实目的、商业动机或履约态度。

编排方法：

• 底层仍以可核对事实为主，不直接画心理推测。
• 将背景趋势、合同履行节点、关键函件、资金投入/撤出等行为对齐。
• 用“可能解释/推断依据”侧栏表达观点，不把推断写成确定事实。
• 对方解释和本方解释可左右对比。

避免事项：

• 不用图表直接断言主观状态。
• 不把公开背景数据和案内证据混为同一证明等级。

6. 长周期房地产复合关系图

适用：合作开发、项目置换、股权变更、工商变更、第三方接盘同时出现。

编排方法：

• 先拆三张细节图：合作关系、项目权益流转、股权/工商变更。
• 用核心项目和核心主体作为连接点。
• 不同法律关系使用不同分区和颜色。
• 主图只展示影响合同是否继续履行、主体资格和权益归属的关系。

避免事项：

• 不把每一次工商变更都画进主图。
• 不把项目空间争议和资金/股权关系混在同一平面图里。

7. 图表化证据目录

适用：图中每个节点都需要直接支撑证据，或案件需要用图表重排证据目录。

编排方法：

• 给主图节点编号，如 F01、F02、R01。
• 附图或侧栏列证据编号、页码、证明目的、争议状态。
• 对证据缺口使用灰色或“待补强”标注。
• 主图和证据目录保持一一对应，避免读者在卷宗中反复寻找。

避免事项：

• 不在主图主体节点内塞长证据摘录。
• 不把无证据支撑的事实画成确定事实。

选择建议

输出要求

• 高阶图仍遵守“一图一观点”：主图必须能用一句话概括。
• 主图最多承载 2 类信息形态；第 3 类信息应放附图或侧栏。
• 所有外部背景、推断、争议事实都要降低证明等级并显式标注。
• 使用模板时优先从 templates/ 中复制 .drawio，再替换文字、节点和线条。

图表决策树

本文件在 scene-routing-guide.md 选出主场景 scene_id 之后，给出"该场景下用哪种图型变体与节点布局"的决策表。决策树是路由的下游，不替代 scene-routing-guide.md 的"受众→场景"逻辑。

与 scene-routing-guide 的边界

决策表

按业务条线组织。表头四列：业务条线 / 推荐图型 / 备选 / 关键考虑。

通用（与 G-01~G-17 联动）

诉讼/案件办理

房地产/项目空间

公司/股权

合同/履约

合规/治理

知产

客户/服务/团队

证据与争议

决策步骤

1. 先有 scene_id：从 scene-routing-guide.md 拿到 1-3 个候选。 2. 再查本决策表：按业务条线行找到对应推荐图型。 3. 再读 `scene-composition-playbook.md`：获取该图型的具体编排思路（坐标、分区、节点尺寸）。 4. 再写 VizSpec：main_chart_type 与 layout.direction 来自本决策表与 playbook。

关键考虑优先级

当多张图型都可用时，按下表优先级选择：

1. 用户明确指定图型 2. 一图一观点（争议复杂的优先拆细节图） 3. 受众阅读习惯（法官优先客观关系图，客户优先路径/方案图） 4. 材料阶段（前期/草稿阶段优先简单图，定稿阶段可复杂） 5. 模板可复用性（已有 P0 模板的场景优先）

新增场景时的同步规则

后续新增场景时，必须同步在本文件加 1 行；否则 scene_id 与图型选择脱节。

法律视觉常量

本文件沉淀 Legal Visualization 的视觉系统常量。所有 .drawio 模板与 scripts/*.py 必须按本文件取值；如需变更，先改本文件再传播。

设计原则

• 一图一观点：每张图服务一个核心观点。节点颜色、线型、强调色必须服务该观点。
• 颜色含义优先：所有颜色都是语义符号，不是装饰。同主体同色，同状态同型，争议/风险用强调色，缺失用灰色。
• 强调色不超 3 个：主色 + 决策橙 + 争议/缺失红灰。本文件只定义 4 个色板值。

页面与画布

page:
  paper: A4
  orientation: portrait
  margin_cm: { top: 2.54, bottom: 2.54, left: 3.18, right: 3.18 }
  usable_width_cm: 14.64
  dpi: 260
  grid_unit_px: 10
  origin: { x: 60, y: 80 }
  grid_step: 60

• 节点坐标从 x=60, y=80 开始画，避免 SVG viewBox 偏移（与 xml-reference.md 行 155 一致）。
• 节点间最小水平/垂直间距 60px；同层级节点尺寸一致。

字体

font:
  family: "Microsoft YaHei, SimHei, PingFang SC, sans-serif"
  size_title_pt: 24       # 图表主标题
  size_subtitle_pt: 14    # 副标题、结论栏
  size_node_pt: 14        # 节点正文
  size_caption_pt: 12     # 注释、证据编号
  size_legend_pt: 10      # 图例、技术标注
  weight_bold: 1          # drawio fontStyle: 1=粗体, 2=斜体, 4=下划线

调色板

palette:
  primary:        "#1f77b4"  # 主色：同主体、合同主线、确认事实
  primary_light:  "#E3F2FD"  # 主色浅底：节点填充
  accent_decision: "#FF8C00"  # 强调-决策：菱形/判断节点
  accent_decision_light: "#FFF3E0"
  accent_dispute: "#C0392B"  # 强调-争议：争议事实、违约、风险
  accent_dispute_light: "#FDECEA"
  grey_missing:   "#9E9E9E"  # 缺失/待补充/未提及
  grey_missing_light: "#F5F5F5"
  line_solid:     "#333333"  # 已证关系实线
  line_dashed:    "#666666"  # 主张/推定虚线
  line_dotted:    "#9E9E9E"  # 推定/待证点线
  text_primary:   "#1a1a2e"  # 主文字色
  text_caption:   "#757575"  # 注释/小字色
  frame:          "#BDBDBD"  # 容器/泳道边框
  frame_bg:       "#F5F5F5"  # 容器/泳道底色

线型与状态绑定

relations.status 与线型/颜色必须严格对应（与 vizspec-schema.md 行 103-111 一致）：

节点样式映射

节点尺寸参考

继承 xml-reference.md 行 161-165 的自动布局参数，叠加中文宽度修正（行 168-172）：

中文节点宽度 = 字符数 × 16px，最小宽度 × 1.3，最大不超过 350px。

复用入口

• references/output-workflow.md：draw.io 生成规则引用本文件代替硬编码。
• references/quality-checklist.md：颜色含义检查引用本文件。
• references/vizspec-schema.md：关系状态样式引用本文件。
• references/xml-reference.md：节点样式属性引用本文件。
• scripts/validate_drawio.py：不校验颜色值（语义层），只校验 XML 结构。
• scripts/normalize_naming.py：引用本文件 + naming-conventions.md。

修改记录

节点命名规范

本文件规定 Legal Visualization 在 VizSpec YAML、drawio XML 标签、annotations.text 三处的统一命名。scripts/normalize_naming.py 按本文件做偏差检查。

总体规则

1. 程序身份严格用术语：节点标签使用法定身份词，不替换为"对方/我方/客户"等口语化表达。 2. 案由用法律标准名："民间借贷纠纷"而非"借款"、"买卖合同纠纷"而非"买卖"。 3. 诉讼请求用数字编号稳定引用：诉讼请求 1、诉讼请求 2 …… 编号在 VizSpec、drawio 标签、附注中必须一致。 4. 证据编号格式 `证据 X-Y`：X=证据组号，Y=组内序号，如"证据 2-3 表示第二组第 3 份"。 5. 争议/待证/推定不与"事实"混用：节点标签只用"争议 X""待证 Y""推定 Z"，不写"事实（争议）"。

程序身份映射

法律文书与材料

关系状态标签前缀

relations.status 标签在 drawio 节点上按下表加前缀，便于肉眼识别：

主体分组

entities[].group 用以下标准名：

• 原告方 / 被告方 / 第三人
• 公司 / 股东 / 实际控制人 / 关联方
• 银行 / 承兑行 / 贴现行
• 发包人 / 承包人 / 分包人 / 实际施工人
• 客户 / 客户决策层 / 客户业务部门 / 客户财务 / 客户法务
• 团队 / 主办律师 / 协办律师 / 辅助人员

一致性约束

• 同一主体在 VizSpec entities 与 drawio 节点标签中必须用同一字符串。
• 同一证据在 events[].evidence_ref 与 annotations[].text 中编号必须一致。
• 同一诉讼请求在 relations[].label 与 annotations[].id 中编号必须一致。

偏差检查

scripts/normalize_naming.py 读 VizSpec YAML + drawio XML，按本文件检查并输出三类偏差：

1. 程序身份偏差：标签使用了"我方/对方/客户"等口语化表达。 2. 诉讼请求编号不一致：同一编号在不同字段指代不同对象。 3. 证据编号格式不符：未使用"证据 X-Y"格式。

一步到位输出流程

Legal Visualization 的默认目标是一次交付 .drawio + .svg + .png 三件套。

文件组合

每次出图默认输出三件套：

• [图名].drawio：源文件，可在 draw.io / diagrams.net 打开编辑。
• [图名].svg：由 draw.io / diagrams.net 从 .drawio 导出的矢量图，文字清晰，可缩放，适合 Word/PPT/网页。
• [图名].png：由 draw.io / diagrams.net 从 .drawio 导出的高清预览和分享格式；自动导出默认使用 2 倍倍率，降低微信、飞书、文档插图中的模糊感。
• [图名].pdf：用户要求正式附件、打印或归档时生成。

如果只能生成一种图片，优先 SVG。如果导出工具不可用，仍应交付 .drawio，并明确说明未能导出图片的原因。

归档机制

自动导出的 .drawio、SVG、PNG 和报告默认写入 archive/<timestamp>/。archive/ 只保留 .gitignore 与 .gitkeep，目录内运行产物不进入版本库，适合保存本次导出的 .drawio、SVG/PNG/PDF 与 export-report.json。

需要把图片放回 .drawio 同目录时，使用：

python scripts/export_drawio.py path/to/file.drawio --format svg,png --in-place

需要指定归档目录时，使用 --output-dir。

需要更高清 PNG 时，使用：

python scripts/export_drawio.py path/to/file.drawio --format png --png-scale 3

输入抽取

生成图表前，先从材料中整理以下信息：

draw.io 生成规则

• 使用完整 mxGraphModel，保留 id="0" 和 id="1"。
• 所有 edge 必须包含 <mxGeometry relative="1" as="geometry" />。
• 节点坐标、字号、字体、颜色、节点尺寸等视觉常量全部按 references/legal-visual-constants.md 取值（页面 origin、字体、调色板、线型绑定、节点尺寸参考）。
• 节点命名按 references/naming-conventions.md 规范。
• 文字过长时增加节点宽度、换行或使用脚注，不缩到不可读。
• 图例、注释、证据来源放在右侧或底部。
• 复杂案件、高阶论证图、制度路径对比和背景趋势叠加图，先按 references/advanced-case-patterns.md 选套路，再写 draw.io。

导出策略

优先使用当前环境中可用的方式导出：

1. draw.io / diagrams.net CLI：直接从 .drawio 导出 SVG、PNG、PDF，并把 .drawio 源文件复制到输出目录。可执行版见 scripts/export_drawio.py，脚本会检测常见 CLI 命令和 macOS 应用路径；默认生成 .drawio + .svg + .png 三件套并输出到 archive/<timestamp>/。 2. draw.io MCP、浏览器或桌面应用：按当前环境能力打开 .drawio 后导出，适合需要人工确认的复杂图。 3. 无导出环境：只生成 .drawio，并给出明确说明。

scripts/export_drawio.py 的报告会记录 source_drawio，并只对图片做轻量文件检查：文件大小、空白风险、SVG viewBox、PNG/PDF 文件头。文字截断、箭头丢失、布局拥挤等图面质量仍按下方图片自检人工确认。

PNG 导出报告会记录 png_scale。默认 2.0 适合普通文档和聊天分享；打印、大屏投影或需要裁剪放大的图片可用 3.0 或 4.0。

导出 SVG 时，优先嵌入 diagram 数据，使 SVG 仍可回到 draw.io 编辑。导出 PNG 时，确认分辨率足够用于文档或演示。

图片自检

导出后至少检查：

• 图片不是空白，画面主体完整。
• SVG 的 viewBox 没有裁切内容。
• 文字没有超出节点边界，没有被边框遮挡。
• 线条方向清楚，箭头没有丢失。
• 图例与图中颜色、线型一一对应。
• 主图无需口头解释即可理解核心结构。

交付说明

最终回复用户时，说明：

• 生成了哪些文件。
• 主图采用了哪个场景和为什么。
• 是否完成图片导出和自检。
• 哪些事实被标为待补充或争议事实。

质量检查清单

出图前后均使用本清单。不能通过的项目，要先修正再交付；确实无法验证的项目，应在最终说明中写明。

事实与法律表达

• [ ] 图表只使用材料中已有事实，或明确标注“待补充/待核/一方主张”。
• [ ] 争议事实没有被画成确定事实。
• [ ] 法律结论与事实节点分开，结论放标题、副标题、右上角结论栏或说明栏。
• [ ] 给法官的图保持客观克制；给客户的图可以突出策略和风险。
• [ ] 每张图只有一个核心观点。

完整硬约束（4 条）见 SKILL.md 顶部"硬约束"段。

场景选择

• [ ] 已按 scene-routing-guide.md 先缩小候选场景，再按 scene-library.md 选择场景 ID。
• [ ] VizSpec 中已记录主场景、备选场景和未选原因。
• [ ] 图表类型与核心争点匹配：时间、关系、数据、流程、空间或证据。
• [ ] 复杂案件已先拆细节图，再合成主图。
• [ ] 不把三类以上信息强行塞入一张图。

版面与视觉

• [ ] 同一主体使用同一颜色。
• [ ] 同一类型关系使用同一线型。
• [ ] 强调色有明确含义，不超过 3 个主要强调色。
• [ ] 线条没有明显交叉；没有长线条绕行。
• [ ] 连线标签没有互相重叠，没有压住箭头或节点边界；长标签已移到独立文本块、侧栏或图例。
• [ ] 连接多的主体位于中心或靠近相关节点。
• [ ] 图表主体文字短；长说明放脚注、侧栏或附表。
• [ ] 节点对齐，间距充足，图面不拥挤。
• [ ] 有必要的标题、图例、注释和证据来源。

draw.io XML

• [ ] XML 包含 mxGraphModel、root、id="0"、id="1"。
• [ ] 每个 edge 都有 mxGeometry relative="1" 子元素。
• [ ] 所有顶层元素 parent="1"，容器内元素使用相对坐标。
• [ ] 节点有明确宽高，中文不被截断。
• [ ] 注释中没有可能破坏 XML 的字符组合。

自动化自检脚本见 scripts/validate_drawio.py，可作为质量门禁的预检环节。

导出文件

• [ ] 已保存 .drawio 源文件。
• [ ] 已导出 SVG 或 PNG；用户要求时导出 PDF。
• [ ] 图片打开后非空白。
• [ ] 画布边界没有裁切主体或图例。
• [ ] 文字、箭头、虚线、颜色在导出图片中可见。
• [ ] 文件名能反映案件或图表用途。

交付前说明

• [ ] 说明输出文件路径。
• [ ] 说明采用的场景和主图逻辑。
• [ ] 说明未能验证或无法导出的环节。
• [ ] 提醒用户核对未脱敏材料和隐私信息。

场景编排手册

本手册解决“怎么画”。scene-library.md 负责选场景，本文件负责把场景变成可交付图表。

通用图表模式

时间图

适用：先后顺序、期间届满、程序推进、履约迟延、工期延误。

必备字段：日期、行为主体、行为内容、法律效果、证据来源、是否争议。

编排套路：

• 简单事实用单轴；复杂事实用多泳道。
• 双方履约对比时，一方放轴上方，一方放轴下方。
• 司法程序和当事人行为并行时，法院/仲裁机构单独设泳道。
• 期间用括号、箭头或色段表达，不用大段文字解释。
• 时间跨度很长时，只保留关键节点，细节放附图或侧栏。

强调方式：

• 关键违约、期限届满、恢复受理、解除通知等节点使用强调色。
• 起止日期必须清楚，期间计算写在节点旁或结论栏。
• 对方原因导致的迟延与己方行为用不同色系。

常见失败：

• 所有事件平铺，读者看不出争点。
• 期间和节点混在一起，没有起止边界。
• 把争议日期画成确定日期。

关系图

适用：多主体、多合同、多层权益、名义与实际不一致、资金/货物/票据/股权流转。

必备字段：主体、身份、合同或行为、标的、金额、流向、关系状态。

编排套路：

• 核心主体放中心或左中位置，次要主体围绕布置。
• 名义关系与实际关系分线表达：名义用虚线或浅色，实际用实线或强调色。
• 合同关系、资金流、标的物流、票据流、股权控制链分别用不同线型。
• 同一阵营或利益共同体用框架包围。
• 多个法律关系并存时，用分区而不是让线条互相穿插。

强调方式：

• 主张成立的关系可以用框架圈定，但争议关系必须标注“待证/主张”。
• 关键资金账户、关键票据、关键项目可作为连接点放中心。
• 对比两种法律性质时，左右分别画“对方理解”和“本方理解”。

常见失败：

• 只画主体，不画行为和法律效果。
• 所有线条同色同型，读者分不清合同、资金、标的。
• 连接最多的主体放角落，造成长线绕行。

数据图

适用：多笔借还款、工程价款、注册资本、股权比例、费用对比、市场趋势。

必备字段：指标、时间点、金额/比例、类别、计算口径、争议项。

编排套路：

• 多笔明细先用表格；只需突出差异时用柱状或条形图。
• 趋势和时间关系强时用折线图，并叠加争议期间。
• 股权比例少且扁平时可用饼图；层级复杂时改树状图。
• 对比不同口径时，把合同口径、实际口径、诉讼主张分列。

强调方式：

• 关键差额、恢复到某金额、异常增长、责任范围用强调色。
• 不重要的数字灰化，避免数字淹没观点。
• 计算结论放在表格右侧或图表右上角。

常见失败：

• 把所有数字都放进图里，没有结论。
• 不说明计算口径，导致读者无法核验。
• 数据图和法律关系混在一张图里。

流程图

适用：诉讼救济路径、审批流程、招拍挂、商检报关、贴现业务、交易操作。

必备字段：入口、步骤、判断条件、分支、输出结果、时限、责任主体。

编排套路：

• 多路径救济必须统一入口，再按条件分支。
• 多主体业务流程用泳道，不要只画单线。
• 正常流程与本案流程可左右对比，缺失或异常步骤标红。
• 每个判断节点必须能回答“是/否”或“条件 A/条件 B”。

强调方式：

• 异常步骤、缺失手续、错过期限、责任节点用强调色。
• 介绍性流程保持简洁；争议性流程突出断点和后果。

常见失败：

• 入口不统一，读者不知道从哪里开始。
• 分支条件写成长句，无法快速判断。
• 只有步骤，没有主体或法律后果。

空间图

适用：房地产项目、工程现场、争议范围、路线、土地/房屋位置、现场还原。

必备字段：空间对象、位置关系、编号、权属/责任/争议状态、照片或图纸来源。

编排套路：

• 平面图做底图，法律信息用编号和图例覆盖。
• 多栋建筑或多个区域用同一编号系统。
• 争议范围、已完工范围、未完工范围、各方主张范围用不同填充。
• 不确定比例时标注“示意”，不要画成精确测绘图。

强调方式：

• 争议区域用边框或半透明填充。
• 重要路径用箭头，关键节点用编号说明。

常见失败：

• 画得像地图但缺少法律含义。
• 信息直接塞进楼栋里，文字不可读。
• 未说明比例或来源，容易被误解为精确图。

典型案由编排

借款合同

主图候选：

• 主体不一致：关系图。
• 特殊方式还款：关系图叠加资金/票据流。
• 多笔借还款：台账表，必要时附资金流图。

必要字段：合同主体、付款主体、收款主体、实际用款人、借款金额、还款金额、利息、指令付款、担保、证据。

编排策略：

• 先区分“签约关系”和“履行关系”。
• 付款给第三人时，不直接把第三人画成合同主体。
• 以物抵债、债权转让、票据还款等特殊还款方式，另设一组关系并与借款关系连接。
• 多笔款项以表格为主，关系图只说明主体结构。

票据纠纷

主图候选：

• 单张票据：票据基本关系图。
• 票面与实际不一致：三线图。
• 贴现责任：贴现流程图+资金流向图。
• 损失范围：两张票据或两条资金路径对比图。

必要字段：出票人、收款人、承兑行、背书人、被背书人、实际持票人、贴现申请人、贴现银行、贴现款账户、票据金额、关键日期。

编排策略：

• 票面记载、实际流转、资金流向必须分线。
• 背书连续性放在一条水平链上。
• 实际控制人、经办人、资金最终受益人不要省略。
• 多张票据不要强塞一张图，优先上下对比。

建设工程

主图候选：

• 合同效力：挂靠/分包/转包关系图。
• 质量验收：流程图。
• 工期延误：分层时间轴或进度对比图。
• 工程价款：对比表或趋势图。
• 优先权：关系图+期限图。

必要字段：发包人、承包人、分包人、实际施工人、监理、工程范围、开竣工日期、验收节点、付款节点、签证/会议纪要/鉴定材料。

编排策略：

• 工期案件不要只画总工期，必须标出关键工序和责任主体。
• 多楼栋案件先每栋拆图，再抽出共同延误逻辑做主图。
• 工程价款争议先表格化口径，再突出关键差异。
• 挂靠/转包图要区分书面关系和实际履行。

土地与房地产

主图候选：

• 出让/转让履约：时间轴。
• 程序瑕疵：正常流程与本案流程对比。
• 一地二卖：法律关系图。
• 合作开发：权益关系图或项目平面图。
• 长周期复杂案：细节图组合成总关系图。

必要字段：土地/项目名称、合同、付款、交付、登记、置换、开发进度、楼栋/区域、投资比例、利润分配、行政流程。

编排策略：

• 交地义务和付款义务用上下对比。
• 程序性瑕疵通过流程断点表达。
• 项目平面图只承载空间争议，不同时承载复杂资金关系。
• 合作开发优先把“土地、资金、项目权益、分红”分层。

国际贸易与进出口代理

主图候选：

• 专业流程说明：泳道流程图。
• 异常节点：正常流程与异常流程对比。
• 代理与借贷性质争议：双图对比。
• 信用证或多方贸易：关系图。

必要字段：买方、卖方、代理方、境外客户、货代/承运人、银行、货物、单据、清关/商检/报关、付款、退税、预付款。

编排策略：

• 先画正常流程，再标出本案异常节点。
• 买卖双方义务分泳道，避免单线流程掩盖责任主体。
• 代理与借贷对比时，必须把代理方对第三方承担的义务画出来。
• 货物流、单据流、资金流分线。

公司与股权

主图候选：

• 股东身份：证据组合图或时间证据图。
• 隐名股东：公示关系与实际关系对比图。
• 单公司股权：表格/饼图/树状图。
• 多公司架构：分区树状图或矩阵图。
• 股权变动：前后对比图或时间+最终结构图。
• 交叉持股：中心节点关系图。

必要字段：公司、股东、名义股东、实际出资人、出资金额、持股比例、工商登记、章程/决议、分红、管理参与、转让/增资/减资时间。

编排策略：

• 股东少时不要过度复杂化，表格或饼图即可。
• 层级多时必须树状化，并在结论栏写控制比例。
• 股权变动多次时，不要每次都画完整树；保留时间线和最终结果。
• 交叉持股的共同公司放中心，减少线条交叉。

法律业务场景编排

法律服务方案与客户汇报

主图候选：

• 初次沟通：客户问题诊断图。
• 服务建议：服务目标-路径-成果图。
• 项目执行：法律服务路线图或服务阶段里程碑图。
• 报价和边界：工作范围与交付物矩阵。
• 多方案选择：方案路径对比图或客户决策树。

必要字段：客户目标、业务背景、核心问题、服务范围、不包含事项、交付物、时间节点、客户配合事项、费用口径、风险等级。

编排策略：

• 客户方案不要从法律概念开始，先从客户目标和业务问题开始。
• 一页方案图优先使用“三段式”：问题诊断、服务路径、交付成果。
• 报价图必须把费用和产出对应起来，避免只画价格。
• 客户需要做决定时，把方案做成路径对比或决策树，不要堆文字。
• 客户配合事项单独成列，避免交付延误责任不清。

合同与交易流程

主图候选：

• 合同管理：合同生命周期图。
• 审查协同：合同审查泳道图。
• 条款风险：条款风险热力图。
• 履约监控：义务履行台账图。
• 违约处理：违约处置预案流程图。
• 模板建设：标准合同体系架构图。

必要字段：合同类型、交易背景、签约主体、审查责任人、关键条款、履约节点、付款条件、验收标准、解除条件、留痕材料。

编排策略：

• 合同流程图必须同时展示业务动作和法律控制点。
• 审查泳道要区分“谁提交、谁审核、谁批准、谁归档”。
• 条款风险图只保留影响决策的条款，不把整份合同搬进图里。
• 履约台账要把“义务、期限、证据、状态”绑在一起。
• 违约预案要从证据固定开始，不能直接跳到起诉或索赔。

企业合规与公司治理

主图候选：

• 合规体检：合规风险地图。
• 授权管理：组织权限与审批矩阵。
• 制度建设：制度体系架构图。
• 监管义务：监管义务矩阵。
• 违规处理：事件处置/内部调查流程。
• 整改落地：整改路线图。

必要字段：业务模块、风险事项、责任部门、控制措施、审批权限、制度文件、监管要求、整改期限、验证材料、汇报对象。

编排策略：

• 合规图要落到业务动作、责任部门和留痕材料，避免只列抽象风险。
• 风险地图使用颜色表达优先级，但每种颜色必须有含义。
• 审批矩阵适合密集信息，流程图适合说明动作先后，不要混用。
• 整改路线图按短期、中期、长期分层，末端必须有验证结果。
• 公司治理结构图应同时表达组织层级和职权边界。

投融资并购与资产交易

主图候选：

• 方案说明：交易架构图。
• 项目推进：交易流程图或项目工作流泳道图。
• 尽调汇报：尽调问题地图。
• 文件管理：交易文件关系图。
• 交割判断：交割条件清单图。
• 投后安排：投后治理安排图。

必要字段：交易主体、标的、对价、资金来源、股权比例、资产负担、审批条件、交割条件、文件清单、尽调问题、税费承担、投后权利。

编排策略：

• 交易架构图优先分层表达“主体、标的、资金、控制权”。
• 尽调问题地图按模块分区，并用颜色区分重大、中等、提示性问题。
• 交割条件图要显示责任方和状态，不能只是条件列表。
• 交易前后结构对比要保持同主体同色，便于客户一眼看出变化。
• 对赌、补偿、回购等条款适合画触发路径，不适合只做条款摘要。

劳动人事

主图候选：

• 制度建设：员工全生命周期合规图。
• 日常管理：入职/调岗/离职流程图。
• 解除判断：解除/裁员决策树。
• 工时工资：工时/加班/休假台账图。
• 竞业限制：竞业限制履行证据图。
• 灵活用工：劳动关系主体判断图。

必要字段：员工类型、岗位、合同、规章制度、考勤、工资、绩效、审批、送达、协商记录、离职文件、竞业补偿。

编排策略：

• 劳动人事图必须强调“程序动作 + 证据留痕”。
• 解除/裁员图使用判断树，避免把不同解除理由混在一起。
• 员工生命周期图适合制度建设，具体争议仍要拆成时间轴或证据图。
• 工时工资类优先表格化，关键差额再用图表强调。

知识产权、数据与科技业务

主图候选：

• 权属证明：知识产权权属链图。
• 研发管理：研发成果归属矩阵。
• 权利布局：商标/专利组合地图。
• 侵权判断：侵权比对矩阵。
• 数据合规：数据流转地图或个人信息处理活动图。
• 出境判断：数据出境评估路径图。

必要字段：作品/技术/商标、创作或研发主体、合同约定、登记状态、许可转让、产品线、数据类别、处理目的、接收方、保存期限、安全措施。

编排策略：

• 权属链图要从“产生”开始，再画转让、许可、登记和使用。
• 侵权比对矩阵按权利特征组织，不按证据材料顺序组织。
• 数据流转图要把系统、人员、第三方和出境路径分开。
• 科技业务图常有专业术语，主体标签要短，解释放侧栏。

债务化解、破产重整与执行

主图候选：

• 债务盘点：债务结构图。
• 程序说明：债权申报与审查流程图。
• 分配说明：清偿顺位瀑布图。
• 资产处置：资产处置路径图。
• 重整方案：重整方案结构图。
• 执行推进：执行财产线索地图。

必要字段：债务人、债权人、债权金额、担保方式、资产类型、查封状态、清偿顺位、分配比例、投资人、重整条件、追偿路径。

编排策略：

• 债务结构图先画主债务，再画担保和追偿，不要一次画成网状。
• 清偿顺位适合瀑布图，突出“谁先、谁后、预计能拿多少”。
• 执行线索地图要按财产类型分区，并标注查询或控制状态。
• 重整方案图要同时让债权人和投资人看懂各自权益变化。

家族财富、婚姻家事与继承

主图候选：

• 资产盘点：家族关系与财产结构图。
• 继承沟通：遗产范围与继承份额图。
• 财产归属：财产变化时间轴。
• 传承安排：信托/保险/持股架构图。
• 方案沟通：财产分割方案对比图。

必要字段：家庭成员、婚姻时间、出资来源、登记信息、资产清单、债务、遗嘱、受益人、保险/信托安排、分割方案。

编排策略：

• 家事图要区分身份关系、财产关系和控制关系，避免混成一层。
• 财产变化适合时间轴，财产现状适合结构图。
• 方案对比图要展示执行难度、税费和争议风险。
• 涉及隐私时，默认使用角色或代称，避免不必要展示完整身份信息。

行政监管与政府事务

主图候选：

• 资质办理：行政许可流程图。
• 处罚应对：行政处罚应对流程图。
• 检查整改：监管检查整改闭环图。
• 救济选择：复议/诉讼路径选择图。
• 新业务评估：行业准入条件矩阵或政策适用判断树。

必要字段：主管机关、许可事项、申请条件、材料清单、期限、处罚节点、申辩听证、整改要求、复议/起诉期限、政策适用条件。

编排策略：

• 监管图必须突出期限和提交材料，避免只画抽象程序。
• 行政处罚图把“事实认定、程序权利、处罚结果、救济路径”分层。
• 政策适用判断树要使用可回答的问题作为节点。
• 整改闭环要落到责任部门、完成证据和复查结果。

法律全流程场景编排

客户全生命周期

主图候选：

• 初次沟通：初次咨询信息地图。
• 接案管理：冲突检索与委托准入流程。
• 签约前沟通：客户转化漏斗图或委托事项边界图。
• 项目推进：材料收集与客户配合清单图、服务进度看板图。
• 结案续约：结案交付与归档图、结案复盘与续约价值图。

必要字段：客户名称或代称、需求来源、目标、服务范围、冲突检索结论、报价状态、委托状态、材料清单、客户配合事项、交付物、续约机会。

编排策略：

• 客户图要突出客户下一步动作，不要只写律师内部流程。
• 委托边界图必须同时列“包含”和“不包含”，防止预期错位。
• 服务进度图用状态列而不是长时间轴，便于一眼看到阻塞事项。
• 复盘和续约图要把已交付成果与后续风险对应，不只列工作量。

案件办理全流程

主图候选：

• 接案评估：诉前评估总览图。
• 起诉准备：诉讼请求形成图、管辖与程序选择图、起诉准备清单图。
• 庭前庭审：庭前会议准备图、庭审攻防路线图。
• 调解判后：调解策略图、判后决策图。
• 执行和监督：执行推进路线图、再审/抗诉路径图。

必要字段：客户目标、诉讼请求、事实基础、法律依据、证据状态、对方财产、管辖依据、费用预算、关键期限、庭审争点、执行线索。

编排策略：

• 案件办理图要区分“对客户说明”和“内部项目管理”：前者突出路径和风险，后者保留负责人和截止日。
• 庭审攻防图以争点为主轴，不按材料出现顺序排列。
• 判后决策图要同时呈现上诉利益、执行可能性和成本。
• 执行推进图不要只画程序，要画财产线索、控制状态和恢复执行触发点。

证据工作全生命周期

主图候选：

• 初期排查：证据发现地图。
• 收集安排：证据收集路线图。
• 固定保全：证据固定流程图、电子数据链路图。
• 证明组织：证明责任分配图、证据缺口补强图。
• 庭审准备：证据三性审查矩阵、质证攻防图。
• 归档复用：证据归档索引图。

必要字段：待证事实、证明责任、证据来源、原始载体、获取方式、固定方式、责任人、截止日、证明目的、三性问题、页码、提交轮次。

编排策略：

• 证据生命周期图要围绕待证事实组织，不围绕文件夹顺序组织。
• 电子数据图必须画清楚原始载体、导出过程、固定方式和备份位置。
• 证据缺口图要给出替代路径，不能只列“缺证据”。
• 质证攻防图把对方证据、攻击点、反证和追问问题放在同一行。

法律文书生产流程

主图候选：

• 诉讼文书：起诉状生成路径图、答辩状结构图、代理意见结构图。
• 业务文书：合同审查意见生产图、法律意见书结构图。
• 项目报告：尽调报告生产流程图。
• 质量管理：文书版本演变图、文书质量检查清单图、文书复用模板库图。

必要字段：文书类型、目标读者、核心观点、事实来源、证据编号、法律依据、版本、修改人、复核人、提交期限、适用限制。

编排策略：

• 文书生产图要从“读者要做什么决定”倒推结构。
• 起诉状和答辩状图必须把请求、事实、证据和依据一一对应。
• 法律意见书图要保留限制条件和事实假设，避免结论被过度使用。
• 版本演变图只标核心变化和确认节点，不展示全文修改痕迹。

客户决策与沟通

主图候选：

• 多方案选择：方案路径对比图、客户决策树。
• 成本说明：争议成本-周期-结果图、费用结构与价值交付图。
• 协作说明：客户沟通闭环图、材料收集与客户配合清单图。

必要字段：客户目标、可选方案、成本、周期、风险、成功概率、客户决策点、客户配合事项、确认方式、后续动作。

编排策略：

• 客户决策图优先用少量分支，不把所有法律分析塞进节点。
• 方案对比必须统一口径，避免每列比较的维度不同。
• 成本-周期-结果图适合客户汇报，注意标注估算口径和不确定因素。
• 沟通闭环图要把“客户确认”画成节点，避免口头沟通没有落点。

企业经营全周期法律地图

主图候选：

• 总览规划：企业成长阶段法律地图、企业法律风险全景图。
• 初创阶段：初创企业法律基础图。
• 日常经营：业务线法律支持地图、业务部门法律协作图。
• 年度顾问：年度法律顾问工作地图。
• 扩张退出：业务扩张法律评估图、企业退出与清算路径图。

必要字段：企业阶段、业务线、部门、法律事项、风险等级、责任人、制度/合同/资质文件、年度节点、预算、后续专项。

编排策略：

• 企业全景图按阶段或业务线组织，不按法律部门内部分类组织。
• 年度顾问图要展示“周期性工作 + 突发事项 + 专项项目”三类内容。
• 业务扩张图要把上线前检查项和上线后监测项分开。
• 企业退出图必须突出债权通知、税务、员工安置和注销节点。

争议解决路径全景

主图候选：

• 路径选择：争议解决路径选择图。
• 联动推进：谈判-诉讼联动图。
• 专门程序：商事仲裁流程图、刑民交叉处理路径图、执行转破产路径图。
• 比较说明：争议成本-周期-结果图。

必要字段：争议目标、证据强弱、关系维护需求、保密需求、时间要求、成本预算、执行可能性、程序入口、关键期限、并行程序。

编排策略：

• 路径选择图从客户目标开始，而不是从法律程序开始。
• 并行程序用泳道，互相影响的节点用依赖线连接。
• 刑民交叉图要区分追责目标、追偿目标和程序限制。
• 成本-周期-结果图只做决策支持，不画成确定承诺。

律师团队协作与项目管理

主图候选：

• 分工安排：案件任务分工图。
• 材料管理：材料流转图。
• 庭审准备：庭审准备甘特图。
• 风险跟踪：项目风险看板图。
• 复盘沉淀：团队复盘图、知识沉淀地图。
• 多人协同：多代理协作图、内部质量复核流程图。

必要字段：任务、负责人、复核人、输入材料、输出物、截止日、依赖关系、阻塞事项、质量标准、知识标签、复盘结论。

编排策略：

• 团队协作图可以比客户图更细，但每个节点必须有负责人或输出物。
• 甘特图只保留关键任务和依赖关系，避免变成日程流水账。
• 质量复核图要把自查、主办复核、合伙人复核和客户确认分开。
• 知识沉淀图要连接到模板、案例、证据清单和复盘标签。

复合案件拆解

复杂案件不要从总图开始，按以下顺序处理：

1. 拆细节图：合同关系、资金流、票据流、股权结构、工商变更、项目空间、程序节点。 2. 找连接点：共同主体、同一账户、同一票据、同一项目、同一合同、同一时间节点。 3. 分区整合：不同法律关系用不同色块区域。 4. 精简主图：主图只保留与核心观点有关的信息。 5. 附图承接：证据目录、明细数据、分支关系放附图。

主图应回答一个问题：读者看完后，能否立刻知道“本案最重要的结构是什么”。

模板优先级

优先沉淀以下可复用模板：

场景路由测试集

本测试集用于检查大场景库下的误选和冲突。每个用例只要求选出主场景；附图可在实际出图时追加。

测试结论

• 当前高风险冲突集中在：SP/CX、LP/RP、LP/EV、EV/G-14/G-15、WD/LP、WD/CT、CT/MA、CG/BC、CX/TM。
• 引入 scene-routing-guide.md 后，以下 20 个测试输入均可得到唯一主场景。
• 评测目标不是覆盖所有 241 个场景，而是覆盖最容易误选的边界场景。

测试用例

判定标准

一个路由结果通过测试，应同时满足：

1. 主场景能回答用户最直接的问题。 2. 未选场景有明确排除理由。 3. 主场景不会强行引入材料中不存在的事实。 4. 主场景的受众匹配输出对象。 5. 如需附图，附图不抢主图位置。

场景路由规则

本文件用于在大场景库中做第一轮筛选。先用本文件选出 1-3 个候选场景，再读取 scene-library.md 中对应章节，最后按 scene-composition-playbook.md 编排图面。

路由顺序

1. 先看用户明确指定：用户点名“时间轴、法律关系图、服务路线图、证据矩阵、交易架构图”等图形时，优先尊重指定图形；只有明显不适合材料时才调整。 2. 再看受众：法官/仲裁庭优先案件事实、争点、证据、法律关系；客户优先路径、风险、方案、成本、配合事项；业务部门优先流程、责任、交付物；律师团队优先任务、证据、文书、复核。 3. 再看任务动词：说明、汇报、选择、推进、证明、反驳、审查、整改、交付、复盘分别指向不同场景组。 4. 再看材料阶段：咨询/报价/委托、办案/庭审/执行、证据/文书、交易/合规、归档/复盘分别进入不同章节。 5. 最后看信息形态：时间、关系、流程、数据、证据、空间、决策、看板决定具体图表形态。

评分法

候选场景按 10 分制快速评分：

扣分规则：

• 场景需要材料中没有的关键事实：-2。
• 场景过于泛化，无法突出主问题：-2。
• 场景会把客户沟通图画成律师内部流程，或反向混淆：-2。
• 场景会把争议事实画成确定事实：-2。

若最高分并列，优先级为：用户指定 > 受众匹配 > 更窄业务领域 > 更接近当前材料阶段 > 通用场景。

冲突处理

主图与附图

• 只选一张主图：当用户要求“一步到位”“一张图”“给客户看”时，主图必须回答一个问题。
• 主图 + 附图：当材料同时涉及关系、时间、证据、金额、流程时，主图只保留核心路径，附图承接细节。
• 不要为了覆盖场景库而多出图；多图只在读者需要不同层级信息时使用。

输出路由说明

生成 VizSpec 前，先写一个简短路由结论：

routing:
  audience: "客户/法官/业务团队/律师团队"
  task: "说明/证明/选择/推进/管理/交付"
  primary_scene: "场景 ID - 场景名"
  alternatives_considered:
    - "场景 ID - 未选原因"
  reason: "一句话说明为什么选主图"

如果用户只要最终图片，不需要把路由结论展示给用户；但仍应在内部用它稳定选择。

模板目录指南

templates/ 只存放可直接在 draw.io / diagrams.net 打开的 .drawio 模板。说明性 Markdown、XML 语法教程和开发规则统一放在 references/，避免模板目录混杂。

目录结构

templates/
├── litigation/                 # 诉讼、仲裁、执行、程序推进
├── corporate/                  # 公司治理、股权、交易架构
├── compliance/                 # 合规治理、审批矩阵、风险地图
├── contract/                   # 合同审查、合同履约、合同流程
├── intellectual-property/      # 知识产权侵权、权利要求、权属对比
├── real-estate/                # 房地产项目、空间标注、项目平面
└── service/                    # 法律服务方案、客户汇报、交付边界

模板文件

XML 示例

以下文件是 XML 写法示例，不是可直接打开的 .drawio 模板：

工具入口

• XML 自检：python scripts/validate_drawio.py templates/litigation/litigation-route.drawio
• 批量导出：python scripts/export_drawio.py templates/ --recursive，输出目录会同时包含 .drawio、.svg 和 .png
• 高清 PNG：python scripts/export_drawio.py templates/litigation/litigation-route.drawio --format png --png-scale 3
• 命名规范检查：python scripts/normalize_naming.py templates/litigation/litigation-route.drawio

新模板规则

新增 .drawio 模板时：

1. 使用英文目录名和英文文件名。 2. 按业务条线放入现有目录；确需新增目录时使用小写英文和连字符。 3. 在 .drawio 文件顶部 XML 注释中写明：适用场景 ID、必要输入字段、默认布局、可变参数。 4. 同步更新 references/chart-decision-tree.md 和本文件的模板列表。 5. 运行 XML 自检、命名规范检查和一次导出抽检。

法律图表编排规则

本文件整理 Legal Visualization 的图表决策与编排规则。使用时不要机械套模板，先判断图表要解决的信息任务。

四步流程

1. 明确对象

先判断图表给谁看。受众不同，是否作图、作什么图、保留多少细节都不同。

给法官的图优先做“案件事实图”“法律关系图”“证据链图”；给客户的图可以更明确展示己方策略、风险区间和不同路径结果。

2. 选择图表类型

案件中的核心要素通常落在五类。

当时间和关系都重要时，不要默认塞进一张图。先判断核心争点：如果争点是“先后顺序或期间”，用时间图；如果争点是“谁和谁形成何种关系”，用关系图；如果二者都必须呈现，使用分层时间轴或先细节图后组合图。

具体图型变体与节点布局的选择细节见 chart-decision-tree.md。

3. 确定内容

采用“三段式”筛选。

1. 全面罗列：先把主体、时间、金额、标的、行为、证据列齐，必要时先做多张细节草图。 2. 逻辑整合：按核心主体、核心时间线、核心法律关系、核心争点或证据链条重新组合。 3. 精简内容：删除与主观点无关的主体、支线、重复节点和长文字；保留对事实判断或法律判断有决定意义的信息。

复杂案件的通用做法是：先拆成细节图，再找连接点，再合成总图。连接点通常是核心主体、共同资金账户、同一票据、同一项目、同一合同或同一时间节点。

3S 精简原则

精简不是越少越好，而是让图表只保留最有效的信息。筛选图中内容时，按以下三项同时判断：

使用 3S 时要避免两种偏差：一是把所有细节都删掉，导致图表无法核验；二是只追求形式简洁，反而删掉决定案件走向的具体日期、金额、合同条款或证据编号。

4. 更好表达

图表的视觉设计服务于论证，不是装饰。

• 颜色：同一主体或同类关系保持一致；强调色只用于争议、违约、风险、关键路径或己方主张。
• 线条：实线表示确定事实或正式关系；虚线表示主张、推定、争议事实、名义关系或间接关系；粗线表示核心路径。
• 框架：用来表达阵营、法律关系范围、利益共同体、项目范围、阶段或制度路径。
• 文字：图表主体放短词；长说明、证据编号、法律依据放底注或侧栏。
• 布局：避免线条交叉；连接多的节点靠中心；同层级节点对齐；同类节点大小一致。
• 连线标签：不要让长标签直接压在线上或贴住节点边界。流向图可以保持直连，但标签优先做成独立短文本，放在线条上方、下方、侧边或图例中，避免导出图片后文字互相覆盖。

一图一观点

每张图先写一句“本图要证明/说明什么”。生成图表时，把这句话落实为标题、副标题或右上角结论栏。若一句话写不清，说明图表任务还没有收敛。

客观与立场

诉讼图表可以有立场，但不能改变事实。处理争议事实时：

• 已有材料直接支持的事实，用实线和常规颜色。
• 只有一方陈述或待证事实，用虚线、浅色、问号或“待证”标注。
• 对方主张与己方主张并列时，使用左右对比、上下对比或不同线型，不把己方主张画成唯一事实。
• 法律结论用“观点栏”或“结论栏”表达，不混入事实节点。

VizSpec 制图规格

VizSpec 是 Legal Visualization 的中间结构。先生成 VizSpec，再转 draw.io XML。这样可以降低随机发挥，稳定实现一步到位出图。

必填结构

vizspec_version: "1.0"
title: ""
audience: "court | client | team | public"
purpose: ""
case_type: ""
routing:
  task: "explain | prove | choose | advance | manage | deliver"
  material_stage: "consultation | service | litigation | evidence | drafting | transaction | compliance | execution | review"
  primary_scene: ""
  alternatives_considered:
    - scene_id: ""
      reason_not_selected: ""
  selection_reason: ""
scene_ids: []
main_chart_type: "timeline | relation | data | process | spatial | evidence | composite"
stance: "neutral | claimant | respondent | internal"
core_message: ""
output:
  source: ".drawio"
  images: ["svg", "png"]
  optional: ["pdf"]
facts:
  confirmed: []
  disputed: []
  missing: []
entities:
  - id: ""
    label: ""
    role: ""
    group: ""
    style_key: ""
events:
  - id: ""
    date: ""
    label: ""
    actor: ""
    legal_effect: ""
    evidence_ref: ""
amounts:
  - id: ""
    label: ""
    value: ""
    unit: ""
    category: ""
relations:
  - id: ""
    source: ""
    target: ""
    label: ""
    relation_type: "contract | payment | delivery | bill | equity | procedure | evidence | claim"
    status: "confirmed | disputed | asserted | inferred | missing"
    style_key: ""
sections:
  - id: ""
    label: ""
    purpose: ""
    contains: []
annotations:
  - id: ""
    text: ""
    anchor: ""
    type: "note | conclusion | evidence | risk | legend"
layout:
  direction: "left-to-right | top-down | center-out | matrix | lanes | map"
  lanes: []
  emphasis: []
  avoid: []
quality_checks:
  - ""

字段说明

生成顺序

1. 先写 title、audience、purpose、core_message。 2. 按 scene-routing-guide.md 先填 routing，再填 scene_ids 和 main_chart_type。 3. 提取实体、事件、金额、关系和证据。 4. 标出确定事实、争议事实、缺失事实。 5. 设计分区、泳道、图例和注释。 6. 将 VizSpec 转成 draw.io XML。 7. 导出图片并按质量清单检查。

关系状态样式

具体颜色常量与线型绑定规则见 references/legal-visual-constants.md "线型与状态绑定" 段。

输出前自问

• 这张图是不是只讲一个主观点？
• 主场景是否比备选场景更贴近受众、任务和材料阶段？
• 读者不听讲解能否看出主体、关系和结论？
• 哪些事实是争议或待补充，是否已经视觉区分？
• 是否需要拆出附图，避免主图拥挤？
• .drawio 能否继续编辑，SVG/PNG 是否能直接交付？

案件时间轴 XML 示例

用途

展示案件的关键时间节点，包括：侵权行为发生时间、权利人发现时间、起诉时间、法院审理时间轴等。清晰展示时效分析和程序推进。

布局

从左到右 的水平时间轴，或从上到下的垂直时间轴。

XML 结构示例

<!-- 标题 -->
<mxCell id="title" value="案件时间轴"
  style="text;fontSize=24;fontStyle=1;align=center;fillColor=none;strokeColor=none;"
  vertex="1" parent="1">
  <mxGeometry x="200" y="20" width="400" height="40" as="geometry"/>
</mxCell>

<!-- 时间轴基线 -->
<mxCell id="timeline" value="" style="endArrow=none;strokeWidth=3;strokeColor=#78909C;" edge="1" parent="1">
  <mxGeometry relative="1" as="geometry">
    <mxPoint x="60" y="180" as="sourcePoint"/>
    <mxPoint x="740" y="180" as="targetPoint"/>
  </mxGeometry>
</mxCell>

<!-- 时间点1：侵权行为 -->
<mxCell id="t1_dot" value="" style="ellipse;fillColor=#C62828;strokeColor=#C62828;strokeWidth=2;" vertex="1" parent="1">
  <mxGeometry x="80" y="165" width="30" height="30" as="geometry"/>
</mxCell>
<mxCell id="t1_label" value="2023-01-15&#xa;侵权行为发生"
  style="text;fontSize=12;fontColor=#C62828;align=center;fillColor=none;strokeColor=none;"
  vertex="1" parent="1">
  <mxGeometry x="55" y="200" width="80" height="40" as="geometry"/>
</mxCell>
<mxCell id="t1_marker" value="侵权日" style="rounded=1;whiteSpace=wrap;fillColor=#FFEBEE;strokeColor=#C62828;strokeWidth=2;fontSize=10;" vertex="1" parent="1">
  <mxGeometry x="55" y="135" width="80" height="25" as="geometry"/>
</mxCell>

<!-- 时间点2：发现侵权 -->
<mxCell id="t2_dot" value="" style="ellipse;fillColor=#EF6C00;strokeColor=#EF6C00;strokeWidth=2;" vertex="1" parent="1">
  <mxGeometry x="220" y="165" width="30" height="30" as="geometry"/>
</mxCell>
<mxCell id="t2_label" value="2023-06-20&#xa;权利人发现"
  style="text;fontSize=12;fontColor=#EF6C00;align=center;fillColor=none;strokeColor=none;"
  vertex="1" parent="1">
  <mxGeometry x="195" y="200" width="80" height="40" as="geometry"/>
</mxCell>
<mxCell id="t2_marker" value="发现日" style="rounded=1;whiteSpace=wrap;fillColor=#FFF3E0;strokeColor=#EF6C00;strokeWidth=2;fontSize=10;" vertex="1" parent="1">
  <mxGeometry x="195" y="135" width="80" height="25" as="geometry"/>
</mxCell>

<!-- 时间点3：起诉 -->
<mxCell id="t3_dot" value="" style="ellipse;fillColor=#1976D2;strokeColor=#1976D2;strokeWidth=2;" vertex="1" parent="1">
  <mxGeometry x="400" y="165" width="30" height="30" as="geometry"/>
</mxCell>
<mxCell id="t3_label" value="2023-09-01&#xa;起诉立案"
  style="text;fontSize=12;fontColor=#1976D2;align=center;fillColor=none;strokeColor=none;"
  vertex="1" parent="1">
  <mxGeometry x="375" y="200" width="80" height="40" as="geometry"/>
</mxCell>
<mxCell id="t3_marker" value="起诉日" style="rounded=1;whiteSpace=wrap;fillColor=#E3F2FD;strokeColor=#1976D2;strokeWidth=2;fontSize=10;" vertex="1" parent="1">
  <mxGeometry x="375" y="135" width="80" height="25" as="geometry"/>
</mxCell>

<!-- 时间点4：判决 -->
<mxCell id="t4_dot" value="" style="ellipse;fillColor=#43A047;strokeColor=#43A047;strokeWidth=2;" vertex="1" parent="1">
  <mxGeometry x="580" y="165" width="30" height="30" as="geometry"/>
</mxCell>
<mxCell id="t4_label" value="2024-03-15&#xa;一审判决"
  style="text;fontSize=12;fontColor=#43A047;align=center;fillColor=none;strokeColor=none;"
  vertex="1" parent="1">
  <mxGeometry x="555" y="200" width="80" height="40" as="geometry"/>
</mxCell>
<mxCell id="t4_marker" value="判决日" style="rounded=1;whiteSpace=wrap;fillColor=#E8F5E9;strokeColor=#43A047;strokeWidth=2;fontSize=10;" vertex="1" parent="1">
  <mxGeometry x="555" y="135" width="80" height="25" as="geometry"/>
</mxCell>

<!-- 时间点5：生效 -->
<mxCell id="t5_dot" value="" style="ellipse;fillColor=#7B1FA2;strokeColor=#7B1FA2;strokeWidth=2;" vertex="1" parent="1">
  <mxGeometry x="700" y="165" width="30" height="30" as="geometry"/>
</mxCell>
<mxCell id="t5_label" value="2024-04-01&#xa;判决生效"
  style="text;fontSize=12;fontColor=#7B1FA2;align=center;fillColor=none;strokeColor=none;"
  vertex="1" parent="1">
  <mxGeometry x="675" y="200" width="80" height="40" as="geometry"/>
</mxCell>

<!-- 时效标注（虚线区域） -->
<mxCell id="statute_bar" value="3年诉讼时效&#xa;(2026-01-15届满)"
  style="rounded=1;whiteSpace=wrap;fillColor=#FFF8E1;strokeColor=#F9A825;strokeWidth=2;dashed=1;fontSize=11;"
  vertex="1" parent="1">
  <mxGeometry x="80" y="250" width="200" height="50" as="geometry"/>
</mxCell>
<mxCell id="e_statute" value="" style="endArrow=none;dashed=1;strokeWidth=1;strokeColor=#F9A825;exitX=0.5;exitY=0;entryX=0.5;entryY=0;edgeStyle=orthogonalEdgeStyle;" edge="1" source="statute_bar" target="timeline" parent="1">
  <mxGeometry relative="1" as="geometry"/>
</mxCell>

触发词

• "案件时间轴"
• "timeline"
• "时间节点"
• "案件经过"
• "时效分析"

关键时间点类型

布局建议

• 时间轴用水平实线，两端带箭头
• 时间点用圆形节点标记在轴上
• 时间点上方/下方交替放置日期和事件描述
• 时效期间用虚线框或阴影区域表示
• 时间点间距根据时间跨度和重要性调整

合同结构图 XML 示例

用途

展示合同的章节结构、条款层级关系，以及合同各方之间的权利义务关系。

布局

树状结构 或 层级图：

• 顶部：合同名称/主体
• 中间：章节/条款
• 底部：具体权利义务

XML 结构示例

<!-- 标题 -->
<mxCell id="title" value="合同结构图"
  style="text;fontSize=24;fontStyle=1;align=center;fillColor=none;strokeColor=none;"
  vertex="1" parent="1">
  <mxGeometry x="200" y="20" width="400" height="40" as="geometry"/>
</mxCell>

<!-- 合同主体（顶部） -->
<mxCell id="contract" value="《合同名称》"
  style="rounded=1;whiteSpace=wrap;fillColor=#E3F2FD;strokeColor=#1976D2;strokeWidth=3;fontSize=16;fontStyle=1;"
  vertex="1" parent="1">
  <mxGeometry x="200" y="80" width="200" height="60" as="geometry"/>
</mxCell>

<!-- 章节容器 -->
<mxCell id="chapters" value="" style="group;" vertex="1" parent="1">
  <mxGeometry x="60" y="160" width="480" height="200" as="geometry"/>
</mxCell>

<!-- 第一章 -->
<mxCell id="ch1" value="第一章 总则"
  style="rounded=1;whiteSpace=wrap;fillColor=#E8F5E9;strokeColor=#43A047;strokeWidth=2;fontSize=13;fontStyle=1;"
  vertex="1" parent="chapters">
  <mxGeometry x="0" y="0" width="140" height="80" as="geometry"/>
</mxCell>
<mxCell id="ch1_art1" value="第一条 目的" style="rounded=1;whiteSpace=wrap;fillColor=#FFFFFF;strokeColor=#43A047;" vertex="1" parent="chapters">
  <mxGeometry x="10" y="35" width="120" height="35" as="geometry"/>
</mxCell>
<mxCell id="ch1_art2" value="第二条 原则" style="rounded=1;whiteSpace=wrap;fillColor=#FFFFFF;strokeColor=#43A047;" vertex="1" parent="chapters">
  <mxGeometry x="10" y="75" width="120" height="35" as="geometry"/>
</mxCell>

<!-- 第二章 -->
<mxCell id="ch2" value="第二章 各方权利义务"
  style="rounded=1;whiteSpace=wrap;fillColor=#FFF3E0;strokeColor=#EF6C00;strokeWidth=2;fontSize=13;fontStyle=1;"
  vertex="1" parent="chapters">
  <mxGeometry x="170" y="0" width="140" height="80" as="geometry"/>
</mxCell>
<mxCell id="ch2_art3" value="甲方权利义务" style="rounded=1;whiteSpace=wrap;fillColor=#FFFFFF;strokeColor=#EF6C00;" vertex="1" parent="chapters">
  <mxGeometry x="180" y="35" width="120" height="35" as="geometry"/>
</mxCell>
<mxCell id="ch2_art4" value="乙方权利义务" style="rounded=1;whiteSpace=wrap;fillColor=#FFFFFF;strokeColor=#EF6C00;" vertex="1" parent="chapters">
  <mxGeometry x="180" y="75" width="120" height="35" as="geometry"/>
</mxCell>

<!-- 第三章 -->
<mxCell id="ch3" value="第三章 违约责任"
  style="rounded=1;whiteSpace=wrap;fillColor=#FFEBEE;strokeColor=#C62828;strokeWidth=2;fontSize=13;fontStyle=1;"
  vertex="1" parent="chapters">
  <mxGeometry x="340" y="0" width="140" height="80" as="geometry"/>
</mxCell>
<mxCell id="ch3_art5" value="违约情形" style="rounded=1;whiteSpace=wrap;fillColor=#FFFFFF;strokeColor=#C62828;" vertex="1" parent="chapters">
  <mxGeometry x="350" y="35" width="120" height="35" as="geometry"/>
</mxCell>
<mxCell id="ch3_art6" value="违约责任" style="rounded=1;whiteSpace=wrap;fillColor=#FFFFFF;strokeColor=#C62828;" vertex="1" parent="chapters">
  <mxGeometry x="350" y="75" width="120" height="35" as="geometry"/>
</mxCell>

<!-- 合同 → 各章 连线 -->
<mxCell id="e1" value="" style="endArrow=classic;strokeWidth=2;strokeColor=#78909C;exitX=0.5;exitY=1;entryX=0.2;entryY=0;edgeStyle=orthogonalEdgeStyle;" edge="1" source="contract" target="ch1" parent="1">
  <mxGeometry relative="1" as="geometry"/>
</mxCell>
<mxCell id="e2" value="" style="endArrow=classic;strokeWidth=2;strokeColor=#78909C;exitX=0.5;exitY=1;entryX=0.5;entryY=0;edgeStyle=orthogonalEdgeStyle;" edge="1" source="contract" target="ch2" parent="1">
  <mxGeometry relative="1" as="geometry"/>
</mxCell>
<mxCell id="e3" value="" style="endArrow=classic;strokeWidth=2;strokeColor=#78909C;exitX=0.5;exitY=1;entryX=0.8;entryY=0;edgeStyle=orthogonalEdgeStyle;" edge="1" source="contract" target="ch3" parent="1">
  <mxGeometry relative="1" as="geometry"/>
</mxCell>

触发词

• "合同结构"
• "合同条款"
• "合同章节"
• "contract structure"
• "contract outline"

配色方案

布局建议

• 用树状布局展示层级关系
• 章节用大矩形，条款用小矩形嵌套在内
• 各方权利义务可用泳道分隔
• 关键条款（违约金、保密等）用醒目颜色
• 条款编号和名称同时显示