인터페이스는 현지화되어 있으며, Skill 소개와 설명 문서는 선택한 언어로 AI가 자동 번역합니다. 코드·명령어·경로·전문 용어는 원문을 유지하며 원작자 문서가 우선합니다.
Skills 둘러보기
문서 및 사무 · SKILL.md

mqc-legal-relation-master

mqc-legal-relation-master

法律关系图大师。把一批案件材料推成一张法律关系图:谁与谁、就哪份合同或哪段工程、发生了什么关系。主体与客体并存,使用者指定的要害以深红标出。布局与走线由索引表查出、判据回读产物验过,出 SVG / PNG / PPTX / VSDX / drawio 五种可继续编辑的源文件,三种风格(奇川风 / 白描 / 歸藏风)每次只出所选的一种。适用于诉前梳理、起诉与答辩的事实部分、庭前准备与向当事人汇报。

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill 문서

GitHub

name: mqc-legal-relation-master description: 法律关系图大师。把一批案件材料推成一张法律关系图:谁与谁、就哪份合同或哪段工程、发生了什么关系。主体与客体并存,使用者指定的要害以深红标出。布局与走线由索引表查出、判据回读产物验过,出 SVG / PNG / PPTX / VSDX / drawio 五种可继续编辑的源文件,三种风格(奇川风 / 白描 / 歸藏风)每次只出所选的一种。适用于诉前梳理、起诉与答辩的事实部分、庭前准备与向当事人汇报。 tags: [法律, 诉讼可视化, 律师, 法律关系, 制图, 庭前三大法宝] metadata: version: 1.0.0

法律关系图大师

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

一、这张图画什么

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

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

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

二、怎么跑

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

运行时不做推导。索引是离线跑出来的,运行时只查不算。 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、格位上预估交叉与实际负相关、双核的平面画法在端口约束下不成立。

저장한 Skills