法律关系图大师

SkillDev tools

Legal relationship diagram master. Distills a batch of case materials into a single legal relationship diagram: who and whom, and regarding which contract or which section of a project, what relationships arose. Subjects and objects appear side by side, with critical points specified by the user hig

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the 法律关系图大师 skill

What this skill tells your AI

The instructions your AI receives, as published by miaoqichuan/new-litigation-visualization in plugins/mqc-nlv/skills/mqc-legal-relation-master/SKILL.md and read by ahel’s review.

庭前三大法宝之一。前两件是大事记表大师(时间线)与庭审对抗图大师 (争点攻防),这一件回答的是结构:谁与谁、就哪份合同或哪段工程、 发生了什么法律关系。

一、这张图画什么

主体与客体并存。只画当事人是不完整的——法律关系要靠客体串起来: 「总承包人与发包人就哪一份合同」「那份合同指向哪一段工程」。 缺了合同与工程,那些线只能标在两个当事人之间,依据与指向全丢了。

主体 当事人:原告、被告、第三人、担保人、案外人……
客体 合同、工程、标的物、款项……

两者同为模块,靠底色深浅区分,形状一律圆角(奇川风不许直角边)。

二、怎么跑

数主体数、算最大度、认结构
  ↓
查索引表拿到全部决定(能不能画、用哪档模块、候选网格、各项参数)
  ↓
布局 → 端口规划 → 走线 → 标签
  ↓
渲染 → 判据回读产物 → 不过就换候选
  ↓
所选的一种风格 × 五格式 → 导出物回读

运行时不做推导。索引是离线跑出来的,运行时只查不算。 1 到 6 个主体查到的是结果(143 张图全部穷举过),直接取布局, 0.1 到 0.2 秒出图;7 到 9 查度序列特征组;10 到 16 查结构分档。

模型要做的只有三步

1 读材料,写 relations.json            格式见 references/relations-guide.md
2 python scripts/make.py relations.json --plan-only      规模判断,一秒内返回
3 两轮提问(见下)拿到 choice.json,然后
   python scripts/make.py relations.json --out 目录 --choice choice.json

第 3 步一条命令做完:布局、渲染、所选风格、五种格式、路线判据、 导出物判据、出处索引、交付说明。不要读 scripts 里的源码,不要另写生成脚本。 第一次运行前可以跑一次 make.py --check 查环境(PNG 渲染器等)。

布局是唯一耗时的环节,结果缓存在输出目录的 layout.json。主体与关系不变时, 改标题、改备注、换风格、导出失败后重来,都直接复用、不再重跑布局。 只有改了主体或关系才会重新布局。

references 目录里除 relations-guide.md 之外都是研发记录,出图时不需要读。

二之〇、模块不超过 9 个

写 relations.json 时就只取要紧的,模块尽量不超过 9 个。 超过 9 个,布局难度与耗时成倍上升:15 个模块在 Windows 上实测半小时以上, 线也明显更乱。同一个股权案,15 个模块时交叉 14 处;精简到 9 个模块、 12 条关系,6 秒出图、交叉 0 处。关系条数的影响同样大:同样 9 个模块, 17 条关系要 31 秒、交叉 12 处,所以关系也只取要紧的。

万一整理出来超过上限,make.py 会停下(退出码 4),先走第〇轮:

python scripts/ask.py trim relations.json                               打印问题,照抄给使用者
python scripts/ask.py trim relations.json --keep 编号 --out r9.json       定模块(超过 9 个时)
python scripts/ask.py trim r9.json --keep-edges 编号 --out r9.json        定关系(超过 12 条时)

先定模块,再定关系,每一步都只在超限时才问。

模块清单:★ 标出建议保留的,先保当事人,再从相连的里面按关系多少补齐, 保证留下的图连通。关系清单:★ 先保每个模块至少挂一条,其余按 relations.json 里的先后补满(所以关系要按重要性从高到低写)。

同一方向、同一对模块之间的多条关系先自动合并成一条,关系名用「;」 连起来、一个字不删,合并后常常就不超限了。

使用者报编号;不回答就按 ★;回答「全部」则不删,照出但会很慢。 留下的某个模块若一条关系都没有,脚本直接报错,不出孤立的模块。 没留下的模块与关系写进出处索引的「未入图」一节,不会凭空消失。

二之一、交互:第〇轮(仅超限时)加两轮

**先问,再出图。风格没定之前不渲染任何一种。**不问就动手, 模型会把三种风格全出一遍,额度直接翻三倍,这是实测出来的问题。

问题的措辞由脚本打印,照抄给使用者,不要自己改写:

python scripts/ask.py round1                      第一轮
python scripts/ask.py round2 relations.json       第二轮
python scripts/ask.py resolve relations.json --style 编号 --mark 编号

**第一轮:交付给谁。**交付对象与风格放在同一个问题里,报一个编号:

1 法官(开庭、提交法院、打印)→ 白描
2 当事人与客户(当面讲、微信发)→ 奇川风
3 同行、讲课、公众号(线上展示)→ 歸藏风
4 让我定(按奇川风出,接着问重点)

不回答就按奇川风。每次只出所选的一种风格, 使用者没有另外开口要,就不出另外两种。

第二轮:强调标在哪里。选奇川风时才问。 主体、客体、关系一起编号列出,使用者报至多两个编号,0 为不标。 不回答就一处都不标。本 skill 把强调的选择放在奇川风里:选白描或歸藏风时 不设第二轮,按选入制视同使用者未指定,图上不标强调。

resolve 会把回答变成确定的选择,越界一律报错、不猜: 多选风格、白描或歸藏风却带了强调、强调超过两处、编号不在清单里。 出口处还有一道:export_all 收到白描或歸藏风的 SVG 却带着强调标记 或深红,直接拒绝导出。

其余的一律不问:模块大小、网格、走线、分页,那些是算出来的。

二之二、照录原文,不替当事人改写

这是 V1 定下的铁则,三大法宝一体适用:主体名与关系名照录源文件, 只准断行与调整视觉层次,不准改写、缩写、归纳。 「北京某某科技发展有限公司」不能自作主张写成「某某公司」—— 当事人的准确名称本身就是法律事实的一部分。

放不下就换行、就加大模块,不靠删字解决。实在放不下的, 写进 provenance 交由人工在渲染前确认,不要静默截断。

强调是选入制,这是 V1 定下的规矩。要害由使用者指定,全图至多两处, 节点与关系都算;使用者跳过、说「直接出图」或没回答,这张图就一处都不标, 不得由模型自行挑一个来填空。强调在奇川风里是深红实底;本 skill 只在奇川风里 提供指定强调的机会,选白描或歸藏风即视同未指定。

三、画不出来的情形要先说

拿到案件先算最大度。关系最多的那个主体超过 12 条就画不出来—— 单个模块的端口容量是 12(高档模块)或 10(矮档)。这时应当告诉使用者 需要拆图或把几条关系合并表述,而不是硬画一张读不懂的。

超过 16 个主体同理:超出已验证范围,建议按争点拆成两张。

四、判据必须回读产物

索引只保证交叉与拐弯的指标,不保证不穿主体、不贴边、箭头到位—— 那些必须读最终 SVG 的坐标才知道。十三条判据(scripts/route_guard.py) 在出图之后跑一遍,不过就换下一个候选网格。

判据本身也踩过坑,记在 references/INDEX-README.md: 判据说「有问题」的时候,先确认它查的是不是该查的东西。

五、三风格

风格用途要点
奇川风彩色母版深红实底标要害,全图至多两处
白描法庭与打印黑线白底;不提供强调选项,按选入制不标
歸藏风线上与讲课浅灰点阵底、无衬线、大字轻标题;不提供强调选项,按选入制不标

后两种是对奇川风产物的确定性变换,位置、尺寸、走线一字不差。 详见 references/label-spec.md

六、五种格式

svg     母版,可继续编辑
png     交付与插图,规范指定用 Noto Serif CJK SC 栅格化
pptx    每个元素都是原生形状,不是图片,颜色大小位置文字都能改
vsdx    ProcessOn / Visio / WPS 导入编辑
drawio  可在 draw.io 里继续编辑,走线逐点照搬 SVG,配色跟随所选风格

一次出齐用 exports.export_all(svg, base, style=所选风格);要看导出物判据明细,加 return_guard=True

PPT 的字体档默认 safe(宋体 / 微软雅黑 / Consolas), 交付给律师的文件要在他自己的机器上直接能开。

**导出物也要回读。**三种可编辑格式都从同一份最终 SVG 取几何, 导出后由 scripts/export_guard.py 逐个拆开读回、与 SVG 对照: 条数一致(E1)、横平竖直(E2)、拐点逐点对上(E3)、 虚实与箭头一致(E4)、主体块位置尺寸一致(E5)、文字齐全(E6)。

交付规则:pptx 与 vsdx 两者都过判据才交;任一未过, 两者一起撤下,只交 svg、png、drawio,并在交付说明里写明未交付的原因。 drawio 未过同样撤下。不拿一份歪线的文件糊弄过去。

改动之后跑三套自检,全过才算没改坏:

python tests/export_checks.py      导出物判据、改坏验证、交互边界
python tests/make_checks.py        一条命令出图、缓存、拒绝错误输入、长名称、第〇轮
python tests/layout_regression.py  17 个 6 到 9 主体的案例,与改动前的原版逐例比,不许有一例更差

踩过的坑:本 skill 的 SVG 拐角是圆弧(A 命令)、虚线属性用单引号, 而 V1 的解析器只认 M / L / Q 与双引号,直接交过去会让每个拐角 歪成斜线、虚线全成实线。所以交给 V1 之前先经 svg_geom.normalize 规整, V1 本身不动。

六之二、交付说明

每次交付都按同一格式写明,由 scripts/delivery.py 生成:

交付:svg、png、pptx、vsdx、drawio
风格:奇川风
强调:无(使用者未指定)
规模:9 个主体 11 条关系
判据:全部通过

四行按重要性排,不写寒暄、不写过程。强调那一行不能省—— 使用者没指定要害时要明说「无」,这是红色选入制的落实处: 写了「无」,就等于承认这张图一处红都没有,而不是悄悄挑了一个。

七、参考

references/relations-guide.md  relations.json 的写法(出图时唯一需要读的参考)
references/INDEX-README.md   索引的分段、归并依据与踩过的坑
references/label-spec.md     标注机制:字号、字体、标题、标签、强调
references/scale-table.md    5 到 16 主体、四种结构的基准实测
references/route-plan.md     生成路径的成本结构与参数依据
references/layout-study.md   布局目标函数的研究(含若干负面结论)
references/feasibility.md    索引能做到什么程度的数学边界

负面结论也写进去了,省得以后重走:布局目标函数对交叉的相关系数只有 +0.36、格位上预估交叉与实际负相关、双核的平面画法在端口约束下不成立。

Signals

GitHub stars
56
Forks
9
Last commit
Sep 2026

ahel review

  • K1binfo
    installs-packages (in scripts/make.py)

Automated review, not a security audit. Ruleset v1+k2.

Advanced
Catalog kind
skill
Gateway key
mqc-legal-relation-master
Source
github.com/miaoqichuan/new-litigation-visualization