简介这份PDF文档面向婚姻家事律师、法律科技从业者及对DeepSeek应用感兴趣的技术人员聚焦婚姻家事案件中财产分割的智能化计算难题尝试用大模型的数学推理能力自动界定夫妻共同财产范围并生成公平分配方案。全文共617页、50个大章节支持目录跳转与阅读器左侧书签大纲快速定位内容完整、图表与目录显示正常。文档从法律条文结构化建模、财产证明文件解析、婚前婚后财产语义界定到模型训练、微调、蒸馏与不动产价值评估等环节层层展开并配有数据标注规范、超参数优化对比、评估指标设计等实操细节可帮助读者系统理解法律规则与深度学习结合的技术路径获取可迁移的建模思路与方案框架。资源包为1个PDF文件约13.8MB已有104人学习参考适合作为法律智能计算方向的学习资料查阅使用。1. 婚姻家事案件里的财产分割为什么“算得清”比“讲得清”更难婚姻家事案件里财产分割是当事人最关心、法官最头疼、律师最容易翻车的环节。一套房产、几笔理财、一方婚前首付婚后共同还贷、另一方父母出资装修再加上股权、保险、公积金、养老金光是把“哪些属于夫妻共同财产”界定清楚就足以让一个执业五年的律师熬到凌晨。传统做法靠人工逐项比对银行流水、购房合同、出资凭证效率低、口径不统一同一个案子换个人算结果可能差出几十万。DeepSeek 这类具备数学推理能力的大模型出现后事情有了新解法把财产清单、出资时间线、还贷记录结构化输入让模型按《民法典》第1062条、第1063条及相关司法解释的规则做逐步推理自动界定共同财产范围并生成分配方案。这套方案适合家事律师、法院调解员、法律科技产品经理以及想用大模型做垂直领域落地的工程师。核心不是让模型“写法律意见”而是让它“算账”——把自然语言描述的财产事实转成可验证的数学推理链每一步都有法条依据和计算过程。617页的方案文档听起来吓人但真正落地时你只需要抓住三个东西财产类型分类表、出资时间线、分配规则引擎。2. 从自然语言到可计算结构财产事实的抽取与建模2.1 为什么不能直接把判决书丢给模型很多人第一反应是把起诉状和证据材料直接塞进 DeepSeek让它输出分割方案。我试过翻车率极高。原因在于判决书和证据材料里充斥着“大约”“部分”“若干”这类模糊表述还有大量与财产无关的程序性描述。模型在长文本里做数学推理时注意力会被稀释算错首付比例、漏掉某笔还贷是常事。正确的做法是先做一层“财产事实抽取”把非结构化文本转成结构化 JSON再让模型在结构化数据上做推理。这一步用 DeepSeek 的 API 就能完成关键是设计好抽取模板和校验规则。import json from openai import OpenAI client OpenAI( api_keyyour-deepseek-api-key, base_urlhttps://api.deepseek.com/v1 # DeepSeek 开放平台标准接入点 ) # 财产事实抽取模板强制模型按固定字段输出 EXTRACT_PROMPT 你是一个婚姻家事案件财产事实抽取助手。请从以下文本中提取财产信息 严格按 JSON 格式输出不要输出任何解释性文字。 字段定义 - asset_type: 财产类型枚举值[房产, 存款, 理财, 股权, 保险, 公积金, 养老金, 车辆, 其他] - acquisition_date: 取得时间格式 YYYY-MM-DD无法确定填 null - registered_owner: 登记权利人 - payment_records: 出资记录列表每条包含 {date, amount, payer, source} - loan_records: 贷款记录列表每条包含 {loan_date, loan_amount, monthly_payment, repayment_period} - current_value: 当前估值单位万元 - notes: 其他需要说明的事实 待抽取文本 {raw_text} def extract_asset_facts(raw_text: str) - dict: response client.chat.completions.create( modeldeepseek-reasoner, # 用推理模型做结构化抽取更稳 messages[ {role: system, content: 你只输出合法 JSON不输出其他内容。}, {role: user, content: EXTRACT_PROMPT.format(raw_textraw_text)} ], temperature0.0, # 抽取任务必须零温度 response_format{type: json_object} ) return json.loads(response.choices[0].message.content) # 调用示例 raw 男方婚前首付80万购买某小区房产登记在男方名下婚后双方共同还贷60个月每月1.2万现估值320万。 facts extract_asset_facts(raw) print(json.dumps(facts, ensure_asciiFalse, indent2))这段代码的逻辑是用deepseek-reasoner模型做零温度结构化抽取response_format强制 JSON 输出避免模型自由发挥。参数上temperature0.0是硬性要求任何大于 0 的值都会让抽取结果不稳定model选deepseek-reasoner而不是deepseek-chat因为推理模型在理解“婚前首付、婚后共同还贷”这类时间逻辑时更少出错。抽取完成后必须做一轮校验payment_records里的金额之和是否等于首付加还贷总额acquisition_date是否早于loan_date这些规则用几行 Python 就能写。2.2 财产类型分类表与共同财产判定规则抽取出来的 JSON 只是原料真正决定“算得对不对”的是分类和判定规则。我一般会维护一张财产类型分类表把《民法典》第1062条、第1063条和常见司法解释拆成可执行的判定条件。这张表是整个方案的核心模型只是执行者规则才是裁判。财产类型共同财产判定条件个人财产例外关键法条房产婚后购买或婚前购买但婚后共同还贷部分及增值婚前全款且登记在个人名下民法典1062、1063婚姻家庭编解释一第78条存款婚姻关系存续期间取得的工资、奖金、劳务报酬婚前存款能证明来源且未混同民法典1062理财/股票婚后用共同财产投资收益为共同财产婚前本金对应部分民法典1062股权婚后取得的股权及分红婚前股权本身但婚后增值可能共同婚姻家庭编解释一第73条保险婚后用共同财产缴纳的保费及对应现金价值婚前购买且婚后未用共同财产缴费民法典1062公积金/养老金婚姻关系存续期间实际取得或应当取得的部分婚前缴存部分婚姻家庭编解释一第80条有了这张表模型在推理时就有了明确的“锚点”。比如房产分割模型需要先判断购买时间再判断还贷资金来源最后按“共同还贷部分占总房款比例 × 当前估值 ÷ 2”计算补偿额。这个公式看起来简单但实操中首付比例、还贷起止时间、增值计算方式都会影响结果。我通常会让模型输出完整的计算步骤而不是只给最终数字这样律师可以逐项核对法官也更容易采信。2.3 用 DeepSeek 做逐步数学推理的提示词设计结构化数据准备好之后下一步是让 DeepSeek 按规则做逐步推理。这里的关键是提示词要“逼”模型展示计算过程而不是直接给结论。我常用的提示词结构是先给法条依据再给计算公式最后要求模型按“事实认定 → 法律适用 → 计算过程 → 分配结论”四段式输出。REASONING_PROMPT 你是一个婚姻家事财产分割计算引擎。请根据以下结构化财产事实和判定规则 逐步推理并生成分配方案。必须展示每一步计算过程。 判定规则 1. 婚前首付部分属于个人财产不参与分割。 2. 婚后共同还贷部分及其对应增值属于共同财产按50%比例分割。 3. 增值计算方式共同还贷部分 ÷ 总房款 × (当前估值 - 购买时总价)。 4. 共同还贷部分 月供 × 还贷月数。 5. 总房款 首付 贷款总额。 财产事实 {asset_json} 请按以下格式输出 【事实认定】... 【法律适用】... 【计算过程】... 【分配结论】... def generate_division_plan(asset_json: dict) - str: response client.chat.completions.create( modeldeepseek-reasoner, messages[ {role: system, content: 你是一个严谨的法律计算引擎只依据给定规则推理。}, {role: user, content: REASONING_PROMPT.format( asset_jsonjson.dumps(asset_json, ensure_asciiFalse) )} ], temperature0.0, max_tokens4096 ) return response.choices[0].message.content这段提示词的设计要点第一把规则写死在提示词里不让模型自己“回忆”法条避免版本混淆第二要求四段式输出强制模型展示推理链方便人工复核第三max_tokens给到 4096因为复杂的房产加股权案子推理过程可能超过 2000 token。实际跑下来deepseek-reasoner在数学计算上的准确率明显高于普通对话模型但前提是输入的结构化数据必须干净。如果抽取阶段漏了一笔还贷记录后面算出来的补偿额就是错的而且模型不会主动告诉你“数据可能不全”。3. 分配方案生成从计算结果到可执行文档3.1 多财产类型的合并计算与优先级处理真实案件里很少只有一套房产往往是房产、存款、理财、股权混在一起。这时候不能逐个算完再简单相加因为不同财产类型的分割逻辑不同而且存在“补偿抵扣”关系。比如房产判给一方另一方拿补偿款这笔补偿款可能从存款里扣。我一般会设计一个“财产池”模型先把所有财产按类型分组每组独立计算共同财产份额然后汇总成一张“应得补偿表”最后做抵扣平衡。def merge_division_results(asset_list: list) - dict: 合并多财产分割结果计算最终补偿方案。 asset_list: 每个元素是单财产的分割结果字典包含 {asset_type, total_value, common_share, personal_share, owner} pool {共同财产总额: 0, 个人财产总额: 0, 补偿明细: []} for asset in asset_list: pool[共同财产总额] asset[common_share] pool[个人财产总额] asset[personal_share] pool[补偿明细].append({ 财产类型: asset[asset_type], 当前估值: asset[total_value], 共同财产份额: asset[common_share], 归属方: asset[owner] }) # 计算双方应得补偿共同财产总额的50%减去已归属方的共同份额 half_common pool[共同财产总额] / 2 for item in pool[补偿明细]: if item[归属方] 男方: item[男方应补偿女方] item[共同财产份额] - half_common else: item[女方应补偿男方] item[共同财产份额] - half_common return pool这段代码的核心是“共同财产总额除以二”这个基准线。每项财产判给谁谁就多占了共同财产份额需要向对方补偿差额。参数上common_share和personal_share必须来自上一步的推理结果不能手工填。实际使用时我会把补偿明细渲染成一张表格让律师一眼看出哪项财产补偿金额异常。比如某套房产的补偿额突然比同类房产高出一大截大概率是增值计算时把婚前首付也算进去了需要回查。3.2 生成可复核的分配方案文档算完之后输出不能只是一堆数字。律师需要一份能直接放进案卷的分配方案文档包含财产清单、计算依据、分配结论和异议提示。我通常用 DeepSeek 把结构化结果转成自然语言文档但会加一道“数字校验”工序让模型在生成文档时把每个数字的来源标注清楚比如“根据2020年3月至2025年2月共60期还贷记录月供1.2万元共同还贷总额72万元”。DOC_PROMPT 请根据以下分割计算结果生成一份正式的财产分割方案文档。 要求 1. 每个数字必须标注来源如“根据XX记录”。 2. 计算过程用文字复述一遍不要只给结果。 3. 末尾列出3条可能被对方异议的点并给出应对建议。 4. 语言正式适合提交法院调解使用。 计算结果 {result_json} def generate_document(result_json: dict) - str: response client.chat.completions.create( modeldeepseek-chat, # 文档生成用对话模型即可成本更低 messages[ {role: system, content: 你是一个法律文书生成助手输出正式、可复核的文档。}, {role: user, content: DOC_PROMPT.format( result_jsonjson.dumps(result_json, ensure_asciiFalse) )} ], temperature0.3, # 文档生成允许少量灵活性 max_tokens3000 ) return response.choices[0].message.content这里temperature0.3是权衡后的选择完全零温度会让文档读起来像机器翻译稍微放开一点能让语言更自然但不会影响数字准确性因为数字来自结构化输入。model换成deepseek-chat是因为文档生成不需要复杂推理用推理模型反而慢且贵。生成后的文档必须人工过一遍重点看“异议点”部分是否合理——模型有时会提出一些过于理论化的异议比如“对方可能主张婚前首付增值也应分割”这种在实务中很少被支持需要律师自行删减。3.3 批量案件处理的性能与成本控制如果是法院调解中心或大型律所一天可能要处理几十个案子。这时候单次 API 调用的延迟和成本就变得敏感。我的经验是抽取阶段用deepseek-reasoner因为准确性优先推理阶段也用deepseek-reasoner因为数学计算不能错文档生成阶段用deepseek-chat因为可以容忍轻微的语言波动。成本上一个中等复杂度的案子3类财产、10条出资记录大约消耗 8000 输入 token 和 3000 输出 token按 DeepSeek 开放平台的定价单案成本在可接受范围内。如果要做批量处理建议加一个本地缓存层把已经抽取过的财产事实存下来避免重复调用。import hashlib import json import os CACHE_DIR ./asset_cache def cached_extract(raw_text: str) - dict: 带缓存的抽取函数相同文本不重复调用 API text_hash hashlib.md5(raw_text.encode()).hexdigest() cache_path os.path.join(CACHE_DIR, f{text_hash}.json) if os.path.exists(cache_path): with open(cache_path, r, encodingutf-8) as f: return json.load(f) result extract_asset_facts(raw_text) os.makedirs(CACHE_DIR, exist_okTrue) with open(cache_path, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) return result缓存键用文本的 MD5简单有效。注意CACHE_DIR要放在内网服务器上如果律所有数据合规要求缓存文件需要加密存储。批量处理时建议用异步请求并发调用但并发数不要超过 5否则容易触发 API 限流。我一般用asyncio加semaphore控制并发这里不展开核心思路是“抽取和推理可以并发文档生成串行”。4. 避坑与排查财产分割智能计算里最容易翻车的五件事4.1 现象模型把婚前首付算进了共同财产原因抽取阶段acquisition_date和payment_records里的首付日期没有正确关联模型在推理时默认“所有出资都是婚后的”。解决在抽取模板里强制要求payment_records每条记录必须带source字段枚举值为婚前个人、婚后共同、父母出资并在推理提示词里加一条“首付来源为婚前个人的不计入共同财产”。4.2 现象共同还贷月数算错多算或少算几个月原因还贷起止时间来自不同证据材料格式不统一模型在解析日期时把“2020.3”和“2020年3月”当成两个不同时间。解决抽取后加一道日期归一化处理统一转成YYYY-MM-DD再用relativedelta计算月数。不要依赖模型做日期减法用 Python 的dateutil库算。4.3 现象房产增值计算时用了错误的“总房款”原因总房款应该是“首付 贷款总额”但模型有时会把“首付 已还贷款”当成总房款导致增值比例算大。解决在提示词里明确定义总房款 首付 贷款总额并要求模型在计算过程中显式写出这个加法。如果模型输出里没有这一步直接判为不合格。4.4 现象多财产合并时补偿方向搞反原因merge_division_results里判断“归属方”时如果某财产判给女方但代码里写的是if item[归属方] 男方就会把补偿方向弄反。解决在合并前先做一轮单元测试用两个简单案例验证房产判给男方、存款判给女方看最终补偿方向是否符合直觉。这个 bug 我踩过血泪经验是“方向判断一定要写测试”。4.5 现象API 调用超时或返回空结果原因deepseek-reasoner在复杂推理时响应时间可能超过 60 秒如果客户端没设超时请求会被中断。解决把timeout设到 120 秒并加一次重试。如果重试仍失败降级到deepseek-chat做简化推理但要在输出里标注“降级处理建议人工复核”。另外max_tokens不要设太小复杂案子推理过程可能超过 3000 token设 4096 比较稳妥。5. 进阶技巧用“计算链校验”把错误率压到最低5.1 让模型自己检查每一步的数学一致性模型算错的时候往往不是不会算而是中间某一步抄错了数字。我后来加了一个“计算链校验”环节把模型的推理过程拆成若干步骤每一步提取出输入数字和输出数字然后用 Python 重新算一遍比对是否一致。不一致就标红让律师重点看那一步。import re def verify_calculation_chain(reasoning_text: str) - list: 从推理文本中提取计算步骤校验数学一致性。 返回不一致的步骤列表。 errors [] # 匹配形如 共同还贷总额 1.2万 × 60 72万 的等式 pattern r([\d.])\s*[×*]\s*([\d.])\s*\s*([\d.]) matches re.findall(pattern, reasoning_text) for a, b, result in matches: expected float(a) * float(b) if abs(expected - float(result)) 0.01: errors.append({ 表达式: f{a} × {b} {result}, 正确结果: expected, 偏差: abs(expected - float(result)) }) return errors # 使用示例 reasoning 共同还贷总额 1.2 × 60 72万增值 72 ÷ 320 × 240 54万 errors verify_calculation_chain(reasoning) print(errors) # 输出偏差项这个校验函数只能抓乘法错误实际使用中还要加加法、减法、除法的正则。更稳妥的做法是让模型输出 JSON 格式的计算步骤每个步骤带operands和result字段然后用代码逐项验算。这样虽然多花一点 token但能把数学错误率压到接近零。我现在的习惯是任何涉及金额的计算模型输出后必须过一遍校验脚本不过脚本不签字。5.2 用“反事实测试”验证分配方案的鲁棒性分配方案生成后我会做一组反事实测试把某个关键参数微调一下看结果是否合理。比如把还贷月数从 60 改成 61补偿额应该增加大约“月供 ÷ 2”把当前估值从 320 万改成 350 万补偿额应该按比例增加。如果模型输出对参数变化不敏感或者变化方向反了说明推理链有问题。这个测试不需要额外调用 API直接用本地脚本跑几组参数人工看趋势即可。测试项参数变化预期结果实际结果是否通过还贷月数 160 → 61补偿额增加约 0.6 万待填待填当前估值 30 万320 → 350补偿额增加约 5.6 万待填待填首付比例 10%80 → 88 万共同财产份额减少待填待填这张表我一般会附在方案文档后面作为“计算可靠性说明”。法官看到你有反事实测试对方案的信任度会明显提高。这也是这套方案和“直接问模型”最大的区别前者是可验证的计算系统后者是黑匣子。5.3 把常用规则固化成配置文件最后说一个省时间的技巧把财产类型判定规则、计算公式、提示词模板全部抽成 YAML 配置文件不要硬编码在 Python 里。这样遇到新类型财产比如虚拟货币、NFT时改配置就行不用动代码。配置文件还能版本管理每次法条更新或司法解释调整改一版配置所有案子自动生效。# rules/asset_rules.yaml house: common_condition: 婚后购买 or (婚前购买 and 婚后共同还贷) formula: (共同还贷总额 / 总房款) * (当前估值 - 购买时总价) / 2 exceptions: - 婚前全款且登记在个人名下 - 父母全额出资且明确赠与一方 deposit: common_condition: 婚姻关系存续期间取得 formula: 共同存款总额 / 2 exceptions: - 婚前存款能证明来源且未混同配置文件加载后推理提示词动态拼接规则模型每次拿到的都是最新规则。这个做法在多个律所协作时特别有用大家共用一套规则库口径统一减少扯皮。我自己的习惯是每接一个新案子先看规则库有没有覆盖没有就加一条加完跑一遍回归测试。这套流程跑了半年财产分割计算的返工率从最初的 30% 降到了 5% 以下。希望帮到你。本文还有配套的精品资源点击获取