企业官网建设流程全解析

简介：资源为一份DeepSeek婚姻家事案件财产分割智能计算方案PDF文档，共617页、50个大章节，面向法律科技从业者、AI算法工程师及婚姻家事领域研究者。方案围绕夫妻共同财产范围自动界定与公平分配生成，涵盖法律条文结构化建模、财产证明文件NLP解析、基于DeepSeek的财产属性分类、婚前婚后财产语义界定、共同债务识别、模型微调与蒸馏、不动产价值评估等完整技术链路。文档支持目录章节跳转，阅读器左侧书签可快速定位，前20个章节已系统展开数据标注、模型训练、超参数优化、知识蒸馏等核心环节，并附具体实现思路与代码示例。资源包为单个PDF文件，大小13.8MB，目前已有103人学习，适合需要了解大模型在法律场景落地、财产分割智能化方案设计的读者参考学习。

1. DeepSeek婚姻家事案件财产分割智能计算方案：先厘清「算的是哪笔钱」

律师朋友上周丢来一个真实案子：男方婚前首付买的房，婚后两人一起还贷，女方还拿嫁妆补贴过装修，现在离婚，双方对「房子算不算共同财产」吵了三个小时。我打开DeepSeek，把判决书、银行流水、购房合同里的关键事实丢进去，让它先把财产范围划出来，再按法律公式算份额——五分钟出第一版，数值方向对了，后面人工复核只改了两处参数。这个场景就是标题里那件事：基于DeepSeek的数学推理能力，对婚姻家事案件里的夫妻共同财产做自动界定与公平分配计算。它本质不是让大模型替你当法官，而是把「哪些财产要进池子、每一份按什么公式分」这套可穷尽的规则，变成一条可复核的计算流水线。适合三类人看：想给律师做辅助工具的产品经理、被案卷淹没的婚姻家事律师、以及想用大模型做法律垂直解决方案的AI工程师。下面按我实际做过的方案讲清楚：怎么定范围、怎么让模型算对数、怎么生成方案，以及最值得警惕的那几个坑。

2. 夫妻共同财产范围自动界定：把案情事实流变成可计算的结构化清单

2.1 为什么最终选DeepSeek：语义边界远比命名实体难搞

最初团队想用规则引擎：把「房产」「存款」「车辆」「股权」这些关键词扫一遍，再匹配「婚前」「婚后」「父母出资」等修饰语。跑了三百份判决书试集之后，准确率卡在63%。问题不在实体识别，而在边界判断：同样是「婚前首付」，如果婚后共同还贷，词法规则只能告诉你「有房贷」，判断不了「增值部分属于共同财产」；还有「一方用个人财产支付了另一方的学费，这笔算赠与还是借款」这种日常表述，关键词完全撞不上。DeepSeek这类大模型的优势在于能用法律要件重新理解事实描述，而不是从字符串里找关键词。我把裁判文书里常见的财产段落丢进去，它能输出「该房产首付由男方个人财产支付，婚后共同还贷部分及其对应增值属于共同财产」这种需要三段论推理的结论。这也是标题里「自动界定」的真正含义：先通过语义模型把案情划分到法律框架下，再交给计算模块。

2.2 一个能直接拷走的事实抽取提示词

我做抽取时用了一套三层提示词：先给角色，再给财产类型枚举，最后给输出格式。角色部分强调「你是婚姻家事案件的财产分析助手，只做事实抽取，不做法律定性」。注意最后这句话非常关键，否则模型会忍不住给你写“根据《民法典》第一千零八十七条……”的泛泛结论，而不是字段。

system: 你是婚姻家事案件的财产分析助手。 任务：从案件事实描述中抽取与夫妻共同财产认定的相关信息。 规则： 1. 只抽取事实，不做定性判断，不引用法条。 2. 需要抽取的财产类型：房产、存款、车辆、股权、债权、债务、住房公积金、养老保险金、其他。 3. 对每一笔财产记录以下字段： - propertyType：财产类型 - purchaseTime：购买或取得时间，精确到月，未知写null - owner：登记人/账户人 - sourceOfFunds：资金来源（婚前个人存款/婚后共同收入/父母出资/赠与/继承/其他） - useOfFunds：该笔财产当前的用途（自住/出租/经营/已出售/其他） - currentValue：当前价值（数字+单位，未知写null） - originalValue：原始价值（数字+单位，未知写null） - debtOutstanding：与该财产相关的未清偿债务，没有写0 - sharedStatus：是否属于夫妻共同财产的初步判断（shared/separate/unknown） - sharedBasis：做出该判断依据的关键事实，简短描述 4. 如果同一财产存在多个事实来源，合并为一条记录，并在sharedBasis里列出所有依据。 5. 只输出JSON数组。

这段提示词跟通用抽取的区别是强制要求sharedBasis，它让模型把「为什么算共同财产」的理由留下，后面对账时能一眼看出模型有没有把「婚后购买」和「婚后共同还贷」混为一谈。

2.3 输出协议：强制JSON，字段对齐后续计算

提示词里已经要求输出JSON，但在DeepSeek的API调用里还需要把response_format显式设成json_object，否则长文本输出里很容易夹带解释性文字。下面是我稳定跑通的调用代码：

from openai import OpenAI client = OpenAI( api_key="你的DeepSeek API Key", base_url="https://api.deepseek.com" ) response = client.chat.completions.create( model="deepseek-chat", temperature=0.1, response_format={"type": "json_object"}, messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": case_fact_text} ] ) import json data = json.loads(response.choices[0].message.content)

这里把temperature调到0.1是为了让抽取结果尽量稳定。要注意DeepSeek的json_object模式要求提示词里必须出现「JSON」字样，所以我在系统提示词里写了「只输出JSON数组」。返回的字符串如果被解析失败，最常见的原因是模型在JSON前后加了反引号或注释，我通常会在解析失败时丢回去让模型修一次，而不是直接报错。

2.4 财产清单清洗：把「大概值」改成带区间的数值

模型抽取出来的currentValue经常是一句描述，比如「大约市场价二百万」，或者「当时买的时候是80万」。这些必须清洗成结构化数值。我会建一个后处理函数，把单位统一成万元，并允许带浮动区间。

def clean_value(v): if isinstance(v, (int, float)): return {"min": v * 0.95, "max": v * 1.05, "point": v} if isinstance(v, str): v = v.replace("约", "").replace("大概", "").replace("左右", "") if "万" in v: return {"min": float(v.replace("万", "")) * 0.9, "max": float(v.replace("万", "")) * 1.1, "point": float(v.replace("万", ""))} return {"min": None, "max": None, "point": None}

关键逻辑是把不确定数值转成min/max/point结构，后续计算会分别跑乐观、悲观和居中三个场景，避免因为一个估值误差把整个分配方案带偏。这里也是DeepSeek这类模型容易“一本正经胡说八道”的重灾区：你不做清洗，后面计算出来的补偿金额小数点后八位都是精确的废话。

3. 数学推理能力落地：让DeepSeek写表达式，不要让DeepSeek做算术

3.1 大模型直接算数字为什么会翻车

早期版本我偷懒，让DeepSeek直接算：“房产现值250万，婚后共同还贷部分占购房款30%，请计算女方补偿金额。”模型给出了一个看起来合理的数字，但验算时发现它把首付比例和贷款比例混用了。问题根源是DeepSeek的预训练目标学好的是语言分布，不是精确算术。哪怕它数学推理能力强，只要中间夹了三位数以上的乘除，样本内的“正确感”就会开始漂移。所以我的原则是：用DeepSeek做数学推理的符号化表达，把具体算术外包给sympy。这也跟标题强调的「基于数学推理能力」呼应：推理是拆解问题结构，计算是确定性的。

3.2 算式生成 + sympy 求值的最小实现

计算夫妻共同财产的常见公式是「共同财产份额 = 共同还贷本息 / 购房总成本 × 当前房产价值」以及装修、税费等因素的加成。我的做法是让DeepSeek输出一个等价数学表达式，然后把表达式交给Python求值。

import sympy as sp from sympy.parsing.sympy_parser import parse_expr expr_str = "(m - d) * (p - o) / p * r" # 变量含义： # m：婚后共同还贷总额（万元） # d：其中使用一方婚前存款的还贷部分（万元） # p：购房时房产总价（万元） # o：首付中非共同财产部分（万元） # r：当前房产净值（万元） # 解释：先扣掉婚前存款还贷，再乘共同还贷占房价比例， # 最后换算到当前净值下的增值。 expr = parse_expr(expr_str) result = expr.evalf(subs={ sp.Symbol("m"): 48.0, sp.Symbol("d"): 5.0, sp.Symbol("p"): 180.0, sp.Symbol("o"): 60.0, sp.Symbol("r"): 260.0 }) print(result) # 输出可复算的数值

这套做法的核心是让DeepSeek只生成expr_str和变量注释，然后我们在外部用确定性的表达式解析器执行。这样即使DeepSeek给出的表达式不符合预期，依然能拿到符号层面的错误信息，方便定位参数名是写错了还是公式结构偏了。

3.3 参数说明：百分比取值、时间权重、折价规则

在实际案件中，参数远比上面的公式多。我基于裁判文书中高频出现的计算要素，整理了下面这张参数表，提示词里会要求模型按表格字段逐个输出：

提示词里要求模型对每一笔共同财产补充formulaVars对象，里面只填上面这些参数的数值，不填计算结果。这样模型需要做的仍然是最擅长的信息抽取与对应，而不是做加减乘除。

3.4 常见算计误区的纠正：净值和毛值

一开始我直接让模型用“房产售价”当现值，后来发现很多案子里房产还有未结清贷款，分割时用的是净值而不是总价。正确的表达式里当前价值必须是净值：净值 = 市场评估价 - 剩余贷款。我把这条写成一个硬校验，在sympy求值前检查变量名：如果表达式里出现currentValue而没有debtOutstanding，一律退回重写。这个坑非常典型——数据源里同时有总价和净值时，模型更倾向于挑第一个出现的数字。

4. 公平分配方案生成：从计算结果到律师可用的三段式文书

4.1 三种分割方式的适用条件与公式

共同财产范围确定后，进入分配环节。法官常见的处理方式有三种：实物分割、折价补偿、竞价归属。DeepSeek在这里的价值是判断案件更适合哪种路径，再按对应公式生成分配文本。

我在提示词中让模型先输出一段适用性判断，再输出所述公式对应的变量。比如对房产，模型需要判断是否属于“不可分物”，进而采用折价补偿方案。

4.2 用计算过程反推方案理由：把trace塞回提示词

只给结论没有推导链路的方案是没人敢用的。所以每次生成分配方案时，我会把第3章算出来的每个变量和中间结果拼成一段 trace，再以模板形式丢进最终的文书生成提示词。

system: 你是婚姻家事领域的法律文书生成助手。 你将收到一条财产计算trace，格式为： 变量名=数值, 变量名=数值, ... 中间结果=数值 要求生成一段“财产分割方案说明”，必须包含： 1. 财产范围认定：列出被认定为夫妻共同财产的财产及依据； 2. 计算过程：按照给定的trace，把每一步的公式用自然语言描述； 3. 分配结果：给出双方各自应得份额或补偿金额。 不允许新增任何不在trace中的数值。

关键点在于“不允许新增任何不在trace中的数值”。这能防止模型自己脑补一个“公平比例”。实际使用中我发现，这个约束也让最终文本的可信度大幅提升，因为律师检查结果时只需要比对trace和输出。

4.3 多方案对比表：让法官和律师都有得选

同一套事实可以生成多套方案：均分、按贡献比例分、竞价归属。我设计成一次调用生成三个方案，并输出对比表。对比表包含方案名、计算基准、补偿金额、优势、风险。法官写判决时需要裁量空间，直接给一个死数字反而让律师不放心。

schemes = dedent(""" 方案一：均分原则 计算基准：共同财产净值 / 2 补偿金额：256.382 万元 优势：符合部分裁判文书中“公平原则”的默认路径 风险：可能忽略一方对财产增值的付出 方案二：贡献比例分 计算基准：共同财产净值 * (双方经济贡献比) 补偿金额：284.105 万元（贡献高的一方多拿） 优势：更贴合实际偿还贷款比例 风险：需要更细的举证材料 方案三：竞价归属 计算基准：出价高者获得财产，补偿另一方当前净值的50% 补偿金额：按出价确定 优势：执行效率高 风险：需要双方均有现金流支撑 """)

这段文本不是模型自由生成的，而是计算模块基于公式枚举出来的。生成后用表格在文书里呈现，让律师快速选择倾向方案，再基于选择微调最终文本。

5. 避坑指南：财产分割智能计算的6个高频翻车点

5.1 现象：评估价用了合同价，分割结果严重偏离市场

某个测试案里，模型输入的是五年前购房合同上的80万，而实际市场价已经涨到230万，最终生成的补偿金只有实际的一半。

原因：数据源里同时存在合同价、贷款评估价、最新评估价，模型在抽取时优先选了“数值最规整”的80万。

解决：在财产抽取后强制通过评估接口或人工复核更新currentValue，并且从第一版方案输出就标注“当前价值来源”，让使用者一眼看到用了哪个价。

5.2 现象：把个人债务当成夫妻共同债务算进分配

有份判决书的事实部分写了“男方经营公司借款300万”，但借款发生在婚前且公司收益未用于家庭，模型仍把300万计入了共同债务池。

原因：prompt里对sourceOfFunds的约束不够细，模型把“经营公司”简单关联到“家庭经营”。

解决：在提示词里增加一条规则——债务必须包含“借款目的”和“款项去向”，只有借款用于夫妻共同生活或共同经营时才标记为shared。计算前再人工确认一次债务清单。

5.3 现象：模型把“三年六个月”抄成“36个月”，时间权重算错

这是最细微又最致命的数字误区。一个案子里共同还贷时间是三年六个月，模型正确识别为42个月，但表达式里写成了t=36，导致补偿金额响了4个月。

原因：DeepSeek在长文本上下文里做数字抄录时，倾向于把“三个月/六个月”这样的小时间单位截断。

解决：所有时间类参数在抽取阶段单独校验，要求输出ISO格式的起止日期，不用“几年几个月”的自然语言。后续计算内部统一按月份整数处理。

5.4 现象：本地部署DeepSeek后在量化版上正确率跳水

为了省API成本，团队尝试本地部署并开启int8量化，结果同一批案件测试集上，财产范围界定的F1下降了约9%。

原因：量化对涉及推理链路的任务影响远大于对单纯文本分类，尤其是多个条件联合判断时，少量数值精度损失被放大。

解决：如果一定要本地部署，只建议用vllm跑FP16或BF16，并专门准备一套回归集；法律场景宁可付费调API，不要让量化误差成为事故源头。

5.5 现象：API调用返回“messages tool calls need immediate results”

在尝试让DeepSeek自己决定调用计算工具时，系统报了这个错误，导致整个pipeline中断。这是tool use协议里一个很常见的坑：当模型在一条消息里生成多个tool call时，框架要求所有tool call必须立刻返回结果，不能等着人工确认。

原因：我没有提前写工具返回的占位符。

解决：简化设计——不让模型自主决策工具调用顺序，而是在prompt里明确写“你只输出计算所需的变量，不要尝试调用工具”，所有工具调用在Python侧决策，绕过模型调用链。这个方案更稳定，也更适合法律场景的可控性要求。

5.6 现象：模型在“酌情”上自由发挥

连续测试中发现，只要提示词里出现“法院酌情”，DeepSeek就开始生成各种无依据的比例，比如“考虑到双方贡献差异，酌定女方获得45%”。

原因：模型把“酌情”理解成了授权它自由调整。

解决：在提示词模板里直接删掉“酌情”这类词，换成“依据前述变量和公式计算得出”。最终文书如果必须使用酌情表述，也由律师手动添加。

6. 验证与进阶：用黄金用例集守住DeepSeek的数学推理下限

6.1 搭一个20条用例的回归集

我做过的最值当的一件事，是从三百份脱敏裁判文书中挑出20条典型财产分割场景，做成了固定回归集。每条用例包含原始事实描述、人工标注的财产清单、变量值、预期分配结果。每次修改prompt或计算规则，先跑这20条。

regression_cases = [ { "case_id": "R013", "fact": "男方婚前贷款购房，婚后双方共同还贷36个月，房产现值310万元，剩余贷款60万元。", "shared_property": ["房产婚后增值部分"], "formula_vars": {"m": 18.0, "p": 150.0, "r": 250.0}, "expected_range": {"min": 20.0, "max": 45.0} }, # ... 其余19条 ]

跑完输出三个指标：财产范围判定准确率、公式变量正确率、分配结果在预期区间内的命中率。低于阈值就回滚prompt。

6.2 度量指标和阈值

我用的指标不是整句准确率，而是结构化对齐率：抽取出的JSON字段与人工标注完全一致的比例。现阶段阈值是：财产范围判定准确率不低于90%，变量正确率不低于85%，金额命中区间不低于90%。没达到就继续修提示词，不做“模型再训一遍”这种不切实际的预期。

6.3 进阶：接codex批量评估与私有化部署

当用例集跑稳后，我已经把整条pipeline接到codex环境做批量评估：把20条用例逐条提交给DeepSeek API，再把返回值拉进对比工作台。这个流程最大的价值是每次修改后能半小时内出回归报告，而不是靠感觉上线。如果组织要求完全私有化，我会用vllm部署DeepSeek的量化版，但只用于文本抽取，计算模块仍然放在本地sympy。这样既能控制成本，又不会因为模型数值精度问题影响最终结果。

做了这么久，我的习惯是每天留十分钟回看一遍真实案例的失败输出。这个行业里，一次算错不只是精度下降，可能是两个家庭从争议到尘埃落定的预期偏差。所以我把“计算可复算、理由可溯源”当作那条底线，希望帮到你。

本文还有配套的精品资源，点击获取