企业官网建设流程全解析

简介：面向法律科技与AI算法从业者的一份DeepSeek应用方案，聚焦婚姻家事案件中夫妻共同财产范围自动界定与公平分配计算。方案将DeepSeek的数学推理能力引入财产分割场景，从法律条文结构化建模、财产证明文件解析，到婚前婚后财产语义界定、共同债务识别，再到模型微调、知识蒸馏与不动产价值评估，形成一套完整的技术链路。资源包为单个PDF文档，约13.8MB，共617页、50个大章节，目录支持书签跳转与章节快速定位，阅读检索较为方便。内容涵盖数据标注规范、超参数优化、过拟合抑制、损失函数设计、模型蒸馏与评估等实操性主题，也便于对照不同阶段的建模方法进行拆解学习。已有102人学习，适合正在探索大模型在法律垂直场景落地的算法工程师、法务信息化产品经理及婚姻家事实务研究者参考，可直接借鉴其架构设计、特征工程与模型调优思路。

1. DeepSeek做婚姻家事财产分割计算，关键是把账拆成数学题

婚姻家事案件里最耗人力的往往不是观点交锋，而是账目对不齐。一张银行卡几十笔流水，几套房产买入时间各不相同，再加上股权、公积金、保险与债务，材料全起来能到大几百页。不同的人按不同口径算，结论可以差出十几万。DeepSeek用于这类场景，重点不是让它输出一段自然语言分析，而是发挥数学推理能力，把财产分割拆成适合自动化的计算任务：界定共同财产范围、统一折算口径、生成公平分配方案。这套做法适合做法律科技产品的研发团队、处理批量案件的律师助理，以及想把领域经验沉淀成可测试系统的IT工程人员。它解决的是“算得动”的问题，而不是替代人去判断。

2. 基于数学推理，把分割任务拆成归集、折算、切分三段

2.1 集合筛选、折算与约束求解：三个步骤各司其职

把婚姻家事财产分割看成一个计算问题，可以得到一个稳定的三段结构。第一段做集合筛选：面对几十项资产，先按既定业务规则判断哪些属于可分范围，与这段婚姻无关、或凭证上明确单方所有的项目直接留在池外。第二段做折算：把不同日期的存款余额、不同币种的理财、买入后涨跌明显的房产，折算到同一个评估基准日，全部以人民币净值入池。第三段做切分：把池内资产按配置好的分配比例逐项切分，能直接分割的按净值划转，不能分割的用补偿金拉平差额。

三段各有各的难点。第一段容易漏，第二段容易口径不一，第三段容易在按揭与不可分割资产上出错。DeepSeek这类模型在长上下文里保持多步计算的能力，比普通对话模型要稳，但三个阶段全部交给一次对话不可控。我一般会让模型一次只做一步，每一步输出结构化结果，验证通过后再把结果喂给下一步。即使某一步算错，也能定位到具体环节重试，而不是把全部推理推倒重来。

2.2 用证据数据类固定输入结构，给提示词提供稳定底座

为了让模型看到的输入是同一套口径，项目里通常先把证据表转换成统一的数据结构。我常用dataclass来定字段，之后无论是喂给DeepSeek还是做程序对账，用的都是同一份对象。

from dataclasses import dataclass @dataclass class EvidenceLine: seq: int # 证据行序号, 用于定位原始凭证 holder: str # "夫" / "妻" / "共同", 来源由凭证备注决定 category: str # 资产类别: 存款/理财/房产/车辆/股权/公积金 source_price: float # 凭证原值, 统一单位: 人民币元 eval_price: float # 评估基准日净值, 默认与 source_price 相同 acq_start: str # 取得起算日期, 业务规则判断入池的起点 policy: str # 命中哪一条业务规则, 用于追溯界定依据

每个字段都有明确用途：seq用于出错时定位到第几行凭证；holder决定了是否天然需要做贡献度分析；policy是范围界定的依据编号，模型引用它而不是自己编理由。日期字段用于做存续期窗口判断，这一步放在程序里执行，不放进自然语言里让模型猜。把数据结构先固定下来，后面换模型或改提示词都不会影响整体流程。

2.3 强制JSON输出，让数学推理结果能被程序校验

把范围界定交给模型之后，最怕的是它输出一大段自然语言。字数越多，能校验的点越少。常见做法是第一步就锁死输出结构，要求它只给JSON，再用JSON Schema做后校验。

import jsonschema schema = { "type": "object", "required": ["pool_type", "asset_id", "amount", "reason_code"], "properties": { "pool_type": {"type": "string", "enum": ["in", "out"]}, "asset_id": {"type": "string"}, "amount": {"type": "number"}, "reason_code": {"type": "string"}, }, } jsonschema.validate(output_json, schema)

schema里把amount限定成number，是为了阻挡模型输出“约二十万”这类文本。reason_code对应业务规则编号，而不是自由发挥的解释。jsonschema校验失败时直接重试，并把错误信息附在下一轮prompt里，让模型自我修正。下面是常用的输出字段约束：

3. 夫妻共同财产范围自动界定的规则清单与提示词模板

3.1 入池与剔除边界先写成配置，不写成模型记忆

范围自动界定的第一步，不是把法律条文塞给模型，而是把业务侧确认过的规则做成清单，在每次调用时作为system prompt传入。以下清单是常见做法，具体内容由使用方按项目要求配置，这里只展示规则形态：

这些规则如果只写在文档里，每次做新案件都要人工翻一遍，模型也无法稳定复用。把它们转成编号放进提示词，模型每次只做“对应”和“计算”，不做领域裁量，输出才可能稳定。规则清单本身由业务侧维护，改动后直接替换system prompt，不需要重新训练模型。

3.2 用few-shot提示词模板约束模型按清单执行

SYSTEM_PROMPT = """你只负责财产范围界定。 以下是本次计算使用的业务规则，所有判定都必须引用其中的规则编号： - R1: 婚后取得的工资、劳务报酬与经营收益进入待分池。 - R2: 存续期内产生的公积金、理财收益进入待分池。 - R3: 具有人身属性的赔偿、救助金不进入待分池。 - R4: 凭证明确指定单方的受赠与继承不进入待分池。 输入是一张证据表，输出JSON，不要任何解释。 示例输出格式： {"pool_type": "in", "asset_id": "A-001", "amount": 120000, "reason_code": "R1"}"""

few-shot示例的作用是让模型理解输入列的映射关系，尤其要让它明白holder字段为“共同”且日期落在窗口内的行，是入池的典型形态。提示词里不出现法律术语的展开解释，只让模型做字段对应和规则引用。这样后续如果想排查某一行为什么入池，直接看reason_code就行，不需要再猜测模型的意图。

提示：reason_code不要直接写“R1”，建议写成“R1:婚后工资”，既便于程序解析也便于人工阅读。

3.3 数据清洗和窗口过滤：范围界定前的最后一公里

范围界定出错，很大一部分原因在数据清洗阶段没做干净。OCR识别出的金额经常带中文逗号、币种符号或“约”字，日期格式也不统一。这些脏数据直接喂给模型，会显著拉低数学推理的准确率。

import pandas as pd df = pd.read_excel("evidence.xlsx", dtype={"source_price": str}) df["source_price"] = pd.to_numeric(df["source_price"], errors="coerce") df["eval_price"] = pd.to_numeric(df["eval_price"], errors="coerce") df = df.dropna(subset=["source_price", "eval_price"]) df = df[df["category"].isin(ALLOWED_CATEGORIES)] df = df[(df["acq_start"] >= WINDOW_START) & (df["acq_start"] <= WINDOW_END)]

errors="coerce"会把无法转成数字的脏值变成NaN，随后dropna剔除掉；category白名单过滤防止模型遇到未知类型时自由发挥；日期窗口判断放在程序侧，因为模型对日期区间的比较不如程序稳定。清洗后再把行数、总额、异常行数打印出来，确认数据质量后再进入DeepSeek调用环节。

4. 公平分配方案生成：分配因子、不可分割资产与输出模板

4.1 公平分配的前提是分配因子可配置

“公平”在工程系统里不能被模型自由裁量。同一个案件，不同调解员侧重不同，结果就会不同。所以方案里把所有影响比例的变量都做成因子，由业务侧在每次计算前赋值，DeepSeek拿到的是一个确定的比例，而不是让它判断该给多少比例。

这些因子在每批数据计算前从配置中心读取，与证据表一同传入prompt。模型只负责把因子乘进去并给出每一位的应得金额，不负责解释因子怎么来的。这样当业务规则调整时，改配置即可，不需要动提示词逻辑。

4.2 可分割资产与按揭房的净值分摊算法

可分割资产按净值入池后直接切分，真正容易出错的是不可分割资产。比如唯一住房有未还贷款，股权有锁定期，保险有现金价值但与人身绑定。工程做法是把这类资产单列，计算净权益后，由保留方给对方补偿。

def calc_indivisible(asset): net = max(asset.eval_price - asset.mortgage_balance, 0.0) share = net * RATIO_A compensation_to_b = share if asset.to_who == "A" else 0.0 return {"asset": asset.seq, "net": net, "share": share} def aggregate_split(items): total = sum(x["net"] for x in items) return total

公式很简单，关键是边界处理：净权益小于等于0时，不产生补偿义务；同一套资产只能计算一次补偿，不能既划归一方又参与池内均分。如果有多个不可分割资产，比如一个股票账户里同时有可交易股和锁定期权证，要把锁定部分单独拆出来记录补偿，避免重复计算。

4.3 分配方案输出模板与模型参数设置

{ "items": [ {"asset": "A-001", "owner": "甲", "net": 120000, "ratio": 0.5, "amount": 60000}, {"asset": "A-002", "owner": "乙", "net": 80000, "ratio": 0.5, "amount": 40000} ], "compensations": [ {"from": "甲", "to": "乙", "amount": 15000, "reason": "不可分割房产权衡"} ], "summary": {"total_net": 200000, "final_a": 65000, "final_b": 135000} }

owner字段不允许同一资产双方同时出现；compensations专门记录不可分割资产的对冲关系；summary里的total_net可以由items重算出来，模型给出的只是参考值，真正写入报告的数字以程序重算为准。调用模型时temperature设为0.1或更低，计算场景不需要创造性；如果平台支持结构化输出，就把response_format设为json_object；max_tokens按批量数据量留足，避免长清单被截断。

5. DeepSeek API调用与批量跑批：从单条证据到全案编排

5.1 DeepSeek API如何调用：最小可跑通的Python客户端

import os from openai import OpenAI client = OpenAI( api_key=os.environ["DEEPSEEK_API_KEY"], base_url=os.environ["DEEPSEEK_BASE_URL"], ) response = client.chat.completions.create( model=os.environ["DEEPSEEK_MODEL"], messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"本次待处理证据表：\n{evidence_text}"}, ], temperature=0.1, ) print(response.choices[0].message.content)

DEEPSEEK_API_KEY、DEEPSEEK_BASE_URL和DEEPSEEK_MODEL都由环境变量注入，具体取值以你当前配置的模型服务为准，不要硬编码在仓库里。在VS Code里调试这段脚本时，可以把环境变量放在启动配置里，这样切换接口地址或模型名时不需要改代码。计算场景优先选用带推理能力的模型模式，如果平台提供思维链开关，开启后多步计算的中间过程更容易排错。

5.2 几百页材料分批送入，上下文长度上限的应对

617页这类体量的卷宗，一次调用塞不完。工程做法是把PDF按证据类型切块，每批只放5到20条结构化后的资产行，逐批请求，落地结果后再进入下一批。错误提示里出现“对话达到长度上限，请开启新对话”时，说明消息上下文超额了，不是额度用尽。

for batch in batches(evidence_rows, size=10): result = call_deepseek(SYSTEM_PROMPT, batch) save_result(batch.id, result) time.sleep(0.5)

应对方式是不要在请求里重复拼历史轮次，每批次只带本轮必要输入，中间状态由程序保存。sleep的作用是压低请求频次，避免触发限流；批次结果落盘是后续对账的基础，不要只存在内存里。对于大批量任务，建议先跑一个10条的小批次验证输出结构，再放开全量。

5.3 本地部署DeepSeek与harness编排的落地选型

当案件数据不允许出域，或每天要跑几百件材料时，就轮到本地部署。常见的做法是用vLLM或Ollama这类的推理引擎加载开源权重，端口暴露在内网，供流程调用。

vllm serve <model-name> \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --port 8000

替换成你实际拉取的模型标识，不同引擎对参数叫法有差异，以文档为准。再往上走，是社区里常说的harness编排形态：把API调用包装成一个个step，step之间用文件或消息队列串联。读完证据表先跑范围界定，再跑折算，再跑分配，最后跑对账。每个step的输入输出都可重放，哪个环节的模型输出变化了，能立刻定位是哪一步引起的。这种流水线是把模型从“单次问答”变成“可编排计算”的关键。

6. 验证数学推理结果：对账脚本、回归测试与可追溯快照

6.1 不等模型自证，用独立程序重算一遍

模型输出里的summary字段写得再漂亮，也不能直接信。工程习惯是让DeepSeek在输出里保留每个参与计算的数字，再由独立脚本用同一组数字重新加总。两边结果差超过1元，就判定为失败并重试。

def recalc_expected(items, compensations): total = sum(item["amount"] for item in items) total = total - sum(c["amount"] for c in compensations) return total actual = model_output["summary"]["total_net"] expected = recalc_expected(model_output["items"], model_output["compensations"]) assert abs(actual - expected) < 1.0, f"对账失败: {actual} vs {expected}"

对账脚本与prompt完全无关，它只认数字。这意味着即使模型把推理过程写错，只要对账不过就进不了下一环节，不会把错误一路带到报告里。

6.2 提示词回归测试集：改一次规则就全量回归一次

规则清单和提示词会不断演化，每次改动都可能影响历史案件的重算结果。建议维护一个回归语料库，二三十个典型场景起步，覆盖有贷款房、股权折价、外币存款、混同流水、多笔转账间隔这些常见情况。每次改提示词或换模型后，把整个语料库重放一遍，比对输出JSON的字段结构和程序对账结果。字段结构变化比金额变化更需要警惕，一个字段改名字，下游所有统计都会静默出错。

6.3 导出JSON与Excel双快照，保留计算口径

归档时把模型原始输出、程序对账结果、业务规则清单三样打包，目录名带上规则版本号与运行时间，放在案件编号目录下。同时导出一份Excel便于人工复核，Excel里的分配公式由程序生成，不引用外部数据。原始数字、中间过程、最终结论三份材料始终对应同一份快照，后续再跑回归时直接对比差异。下次换模型或改分配因子时，先在回归集上重跑一遍，确认所有历史快照的数字和结构仍能通过校验，再进入正式批量任务。

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