简介这份资源面向婚姻家事律师、法律科技从业者及对AI司法应用感兴趣的技术人员聚焦夫妻共同财产范围界定与公平分配方案生成这一实务难题借助DeepSeek的数学推理能力构建智能化计算方案。文档共617页、50个大章节以1个PDF文件交付压缩包约13.8MB支持目录章节跳转、阅读器左侧书签大纲显示与章节快速定位查阅体验完整流畅。内容从法律条文结构化建模、财产证明文件解析、婚前婚后财产语义界定到财产来源追溯、共同债务识别、模型训练微调与知识蒸馏再到不动产价值评估及增值部分共同财产比例计算形成完整技术链路。已有104人学习适合希望系统掌握法律AI建模思路、对照目录按模块精读的读者参考文档仅供学习使用。1. 当婚姻家事案件遇上数学推理财产分割智能计算到底在算什么离婚案件里最耗神的从来不是感情破裂的认定而是财产清单拉出来之后那一堆剪不断理还乱的账。一套房婚前首付婚后还贷、一方父母出资登记在双方名下、股权分红混同了工资卡、公积金和养老金账户各有各的缴存规则——这些场景下法官和律师要做的本质工作是把自然语言描述的家庭财产事实翻译成可计算的法律规则再输出一个双方都能接受的分配比例。DeepSeek 这类具备数学推理能力的大模型出现后婚姻家事案件财产分割智能计算方案开始被认真讨论能不能让模型自动界定夫妻共同财产范围再生成一份带计算过程的公平分配方案。这件事的核心难点不在生成文字而在推理链条不能断——共同财产认定、个人财产排除、增值部分折算、债务抵扣每一步都是数学题错一步结果就翻车。这套方案适合家事律师、法院调解人员、法律科技产品经理以及想用大模型做垂直领域推理落地的工程师。2. 财产分割的数学推理链路从法律条文到可计算变量2.1 为什么通用大模型直接算会出错把一份离婚财产清单丢给通用大模型让它直接输出分配方案十次有八次会在中间步骤翻车。原因不是模型不懂法律而是它把「推理」和「生成」混在一起了。财产分割的计算链路其实很长先做财产性质认定婚前/婚后/混同再做范围界定共同财产/个人财产/家庭共有然后做价值评估原值/现值/增值接着做贡献度分析出资比例/还贷贡献/家务劳动补偿最后才是比例分配和债务抵扣。通用模型在生成答案时会跳过中间变量直接给结论导致同一个案子换个问法结果就不一样。我一般会把这条链路拆成显式的中间变量让模型每一步只做一件事。常见做法是设计一个「事实抽取 → 性质标注 → 数值计算 → 方案生成」的四段式 prompt 结构每段之间用结构化 JSON 传递数据而不是让模型自由发挥。这样做的另一个好处是可审计——法官看到的不只是一个比例而是每一步的计算依据。2.2 共同财产范围界定的三个判定维度夫妻共同财产范围自动界定落到可计算层面就是三个维度的判定。第一个维度是时间维度财产取得时间是否在婚姻关系存续期间。第二个维度是资金来源维度购置资金是个人财产、共同财产还是混合来源。第三个维度是登记维度不动产和特殊动产的登记状态是否影响权属认定。这三个维度组合起来会形成一张判定表。比如婚前一方首付、婚后共同还贷的房产时间维度上首付部分属于婚前资金来源维度上还贷部分属于共同登记维度上如果登记在首付方名下则房屋所有权归首付方但共同还贷及对应增值部分需要补偿。这张判定表就是后续数学推理的规则底座。# 财产性质判定规则引擎简化版 # 输入财产事实字典输出性质标签和计算路径 def classify_property(fact): fact 包含字段 - acquire_time: before_marriage | during_marriage - fund_source: personal | joint | mixed - registration: individual | joint | third_party - asset_type: real_estate | equity | deposit | pension # 规则1婚后取得且资金共同来源直接认定为共同财产 if fact[acquire_time] during_marriage and fact[fund_source] joint: return {label: joint, calc_path: direct_split} # 规则2婚前取得但婚后共同还贷/增值需拆分计算 if fact[acquire_time] before_marriage and fact[fund_source] mixed: return {label: mixed, calc_path: split_appreciation} # 规则3婚前个人财产婚后自然增值仍属个人 if fact[acquire_time] before_marriage and fact[fund_source] personal: return {label: personal, calc_path: exclude} # 规则4登记在第三人名下的财产需先做权属确认 if fact[registration] third_party: return {label: pending, calc_path: ownership_confirm} return {label: unknown, calc_path: manual_review}这段代码的逻辑是把法律规则翻译成条件分支。参数说明acquire_time决定时间维度fund_source决定资金来源维度registration决定登记维度。实际落地时mixed分支需要进一步拆解首付比例、还贷总额、增值倍数三个数值才能进入下一步计算。注意pending分支不能直接跳过必须挂起等待权属确认否则后续所有计算都是空中楼阁。2.3 增值部分折算的数学公式与参数设定增值部分折算是整个链路里最容易出玄学的地方。房产增值、股权增值、基金增值计算逻辑各不相同。房产相对简单共同还贷部分占总房款的比例乘以当前增值总额就是应补偿的增值部分。公式是补偿额 (共同还贷额 / 总购房成本) × (当前市值 - 总购房成本) × 50%。这里的 50% 是默认均等分割如果有贡献度差异需要调整这个系数。股权增值复杂得多因为涉及公司净资产变化、分红再投资、股权稀释等因素。我一般会建议在方案里明确标注「股权增值按评估基准日净资产计算」避免用市场估值导致争议。参数设定上总购房成本要包含首付、贷款本金、利息、税费不能只算首付。当前市值要注明评估时点因为房价波动会直接影响结果。# 房产增值补偿计算 def calc_real_estate_compensation(total_price, loan_principal, loan_interest, joint_repayment, current_value, split_ratio0.5): total_price: 购房总价含税费 loan_principal: 贷款本金 loan_interest: 贷款总利息 joint_repayment: 婚后共同还贷总额含本息 current_value: 当前评估市值 split_ratio: 分割比例默认均等 total_cost total_price loan_interest # 总购房成本 appreciation current_value - total_cost # 增值总额 joint_ratio joint_repayment / total_cost # 共同还贷占比 compensation joint_ratio * appreciation * split_ratio return round(compensation, 2)参数说明total_cost把利息计入成本是关键很多人只算首付和本金导致增值被高估。joint_ratio的分母用总成本而非贷款额是因为首付部分也参与了增值分配。split_ratio默认 0.5但如果一方能证明对方存在隐藏、转移财产行为可以主张调整。3. 用 DeepSeek 搭建财产分割计算管线的完整步骤3.1 环境准备与 API 调用最小示例先把环境跑通。DeepSeek 开放平台的 API 兼容 OpenAI 格式调用方式不复杂。本地部署的话vLLM 是常见选择但婚姻家事案件涉及大量个人隐私数据我强烈建议走本地化部署路线不要用公有云 API 处理真实案件。如果只是做原型验证可以用 API 快速跑通逻辑。# 安装依赖 pip install openai pandas pydantic # 设置环境变量本地部署时替换为本地地址 export DEEPSEEK_API_KEYyour_key_here export DEEPSEEK_BASE_URLhttps://api.deepseek.com/v1from openai import OpenAI import json client OpenAI( api_keyyour_key_here, base_urlhttps://api.deepseek.com/v1 ) def extract_property_facts(case_text): 从案件描述中抽取财产事实输出结构化 JSON prompt f你是一个婚姻家事案件财产事实抽取助手。 请从以下案件描述中抽取所有财产条目每条输出 - asset_type: 房产/股权/存款/公积金/养老金/其他 - acquire_time: before_marriage/during_marriage - fund_source: personal/joint/mixed - registration: individual/joint/third_party - value: 数值元 - notes: 补充说明 案件描述 {case_text} 只输出 JSON 数组不要输出其他内容。 response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0.1 # 低温度保证抽取稳定性 ) return json.loads(response.choices[0].message.content)逻辑说明temperature0.1是为了让抽取结果稳定财产事实抽取不需要创造性。model参数根据实际部署的模型名称调整本地部署时换成对应模型名。注意 prompt 里明确要求「只输出 JSON」否则模型可能加解释文字导致解析失败。3.2 事实抽取到性质标注的 prompt 链设计单次抽取只能拿到事实性质标注需要第二轮推理。这里的关键是把法律规则显式写进 prompt而不是让模型自己回忆法条。我一般会把判定规则整理成表格作为 system prompt 的一部分。SYSTEM_PROMPT 你是婚姻家事财产分割计算助手。你的任务是根据给定的财产事实 按照以下规则标注财产性质 规则表 | 取得时间 | 资金来源 | 登记状态 | 性质标签 | 计算路径 | |---------|---------|---------|---------|---------| | 婚后 | 共同 | 任意 | 共同财产 | 直接分割 | | 婚后 | 个人 | 个人 | 个人财产 | 排除 | | 婚前 | 共同 | 共同 | 混合 | 拆分增值 | | 婚前 | 个人 | 个人 | 个人财产 | 排除 | | 婚前 | 混合 | 任意 | 混合 | 拆分增值 | | 任意 | 任意 | 第三人 | 待确认 | 权属确认 | 输出格式对每条财产输出 {asset_id, label, calc_path, reasoning}。 reasoning 字段用一句话说明判定依据。 def annotate_properties(facts_json): response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: json.dumps(facts_json, ensure_asciiFalse)} ], temperature0.1 ) return json.loads(response.choices[0].message.content)参数说明reasoning字段是给后续人工复核用的不能省。实际跑的时候会发现模型偶尔会把「婚前混合」误判成「共同财产」这时候需要在 prompt 里加 few-shot 示例来纠正。我一般会准备 3 到 5 个典型判例作为示例塞进 system prompt准确率能明显提升。3.3 数值计算与方案生成的分离式实现到了计算环节不要再让模型做算术。把上一步输出的calc_path作为路由键用确定性代码完成计算模型只负责生成方案文字。这样做的好处是计算结果可复现不会因为模型版本变化导致同一案件算出不同结果。def compute_split(annotated_properties, current_values): annotated_properties: 标注后的财产列表 current_values: 当前估值字典 {asset_id: value} results [] for prop in annotated_properties: aid prop[asset_id] path prop[calc_path] if path direct_split: # 共同财产直接均分 results.append({ asset_id: aid, total: current_values[aid], share_a: current_values[aid] / 2, share_b: current_values[aid] / 2, method: 均等分割 }) elif path split_appreciation: # 混合财产需拆分这里简化处理 # 实际需传入首付、还贷等明细 results.append({ asset_id: aid, total: current_values[aid], share_a: None, # 待填充 share_b: None, method: 拆分增值需补充还贷明细 }) elif path exclude: results.append({ asset_id: aid, total: current_values[aid], share_a: 0, share_b: current_values[aid], method: 个人财产排除 }) return results逻辑说明direct_split和exclude可以直接算split_appreciation必须挂起等待补充数据。这个设计是故意的——宁可让流程卡住也不让模型猜一个数字出来。实际落地时split_appreciation分支会触发一个数据补全表单让律师或当事人填写首付金额、还贷起止时间、每月还贷额等参数。4. 避坑指南财产分割智能计算落地时最容易翻车的五个地方4.1 现象同一案件两次运行结果不一致原因模型 temperature 设太高或者 prompt 里没有锁定输出格式。财产分割计算需要的是确定性不是创造性。解决把 temperature 压到 0.1 以下所有输出强制 JSON 格式并在 prompt 里加「不要输出任何解释性文字」的约束。如果本地部署检查是否开启了随机采样。4.2 现象共同财产被误判为个人财产原因prompt 里的规则表覆盖不全模型遇到规则表外的组合时自由发挥。比如「婚前一方出资但登记在双方名下」这种情形规则表里没有对应行模型就可能判错。解决规则表要穷举所有时间、资金、登记的组合宁可多写几行「待人工确认」也不要留空白让模型猜。4.3 现象增值计算把利息漏掉导致补偿额虚高原因计算总购房成本时只算了首付和本金没算贷款利息。房产增值补偿的分母应该是总成本利息是实打实付出的钱。解决在事实抽取阶段就要求提取「贷款总利息」字段如果案件描述里没有标记为待补充不要默认按零处理。4.4 现象模型把「家务劳动补偿」和「财产分割」混在一起算原因这两个是独立的法律请求家务劳动补偿是在财产分割之外单独主张的。模型看到「一方全职照顾家庭」的描述容易直接在分割比例上倾斜而不是单独列一项补偿。解决在 prompt 里明确区分「分割比例调整」和「家务劳动补偿」两个输出字段不要让模型合并处理。4.5 现象本地部署时模型输出乱码或截断原因显存不足导致推理中断或者 max_tokens 设太小。财产分割方案生成需要较长输出尤其是带计算过程的方案。解决max_tokens 至少设 4096本地部署时监控显存占用必要时用量化版本。如果输出截断检查是否触发了模型的上下文长度限制。5. 让计算过程可审计方案输出模板与人工复核技巧方案生成不是让模型写一篇散文而是输出一份可审计的计算报告。我一般会设计一个固定模板包含「财产清单」「性质认定」「计算过程」「分配结果」「待确认事项」五个部分。模型只负责填充内容模板结构由代码控制。REPORT_TEMPLATE # 财产分割计算报告 ## 一、财产清单 {asset_list} ## 二、性质认定 {nature_annotation} ## 三、计算过程 {calculation_steps} ## 四、分配结果 {distribution_result} ## 五、待确认事项 {pending_items} def generate_report(assets, annotations, calculations, pending): return REPORT_TEMPLATE.format( asset_listformat_assets(assets), nature_annotationformat_annotations(annotations), calculation_stepsformat_calculations(calculations), distribution_resultformat_distribution(calculations), pending_itemsformat_pending(pending) )这个模板的价值在于法官或对方律师可以逐项核对。待确认事项部分尤其重要它把模型不确定的地方显式暴露出来而不是藏在文字里蒙混过关。我自己的习惯是任何calc_path为split_appreciation或ownership_confirm的条目都必须出现在待确认事项里并且标注需要补充的具体材料。人工复核时重点看三个地方一是性质认定和计算路径是否匹配二是数值计算的输入参数是否和案件事实一致三是分配比例调整是否有明确依据。如果模型在reasoning字段里写了「根据公平原则」这种模糊表述直接打回重做——公平原则不是数学推理不能作为计算依据。还有一个实用技巧把每次运行的输入事实、中间标注、最终报告都存成 JSON 文件版本化管理。这样当模型升级或 prompt 调整后可以用历史案件做回归测试看哪些案件的结论发生了变化。我吃过这个亏一次 prompt 微调导致一批案件的增值计算逻辑变了因为没有回归测试直到客户反馈才发现。希望帮到你。本文还有配套的精品资源点击获取