走进一家老字号餐厅，你想点一道“清蒸鲈鱼”。你不会直接冲进后厨炒菜，而是告诉服务员：几个人吃、有什么忌口、想要什么口味。服务员飞快记下这张点菜单，传给厨师；厨师照着菜谱备料、烹饪、摆盘；成品还要经过传菜口质检员的目光，确认色香味形都达标，才敢端到你面前。 AI生成起诉状，走的正是这条“餐厅流水线”。当事人是客人，陈述案情就像口头点菜；AI是服务员兼厨师，把散乱的话记成结构化点单，再依法律“菜谱”推导出诉讼请求，按法院要求的“摆盘规范”写成文书；最后质检员（校验机制）核对姓名、身份证号、案由、时效等信息，不合格就打回重做。不同案件类型，就像川菜、粤菜各有菜谱——婚姻纠纷、合同纠纷、侵权纠纷各有专属模板。 这篇文章将带你走完这条流水线：从案件事实提取、诉讼请求推导，到格式规范约束、实体信息校验、模板定制，最后聊到模型的训练与部署。读完之后你会发现，让AI写起诉状，本质上就是给法律行业搭一条标准化的“出餐流水线”。

岗位关联

对AI从业者而言，理解法律文书的生成链路，等于掌握了一套“行业知识 + 大模型 + 工程校验”的标准落地范式——这正是AI+法律赛道最值钱的能力组合。

目录
  1. 可视化演示
  2. 事实要素提取
  3. 诉讼请求推导
  4. 文书格式规范
  5. 实体信息校验
  6. 案件模板定制
  7. 生成链路部署
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示从案件事实提取到诉讼请求推导、再到格式校验的生成管线，可切换三种模式观察起诉状如何自动生成并符合立案要求。

本节配有交互动效（进入视口后自动加载，约 3KB）。

案件事实提取 把口语化描述转化为可推理的结构化事实图谱 提取姓名、金额、日期、借还关系等要素 实体置信度 = 抽取质量 提取质量决定后续推理的准确性。

事实要素提取

你去餐厅吃饭，服务员第一件事不是上菜，而是“记单”：几个人、谁请客、有没有忌口、预算多少。这些信息看似琐碎，却是后厨能开火的依据。AI生成起诉状也一样，第一步是把当事人满肚子的委屈和来龙去脉，变成一张结构化的“点菜单”——谁、何时、何地、做了什么、结果如何、有哪些证据。

在自然语言处理领域，这一步叫“信息抽取”。律师过去要人工读卷宗、翻聊天记录、核对转账凭证，现在AI用预训练语言模型对案情描述做序列标注：把“张三”标为人名，“2024年3月1日”标为时间，“借款50万元”标为金额加行为。抽取结果被填入一个结构化事实表，供后续步骤使用。

事实表的设计很关键，它决定了后厨能不能看懂“订单”。以民间借贷纠纷为例，事实表至少需要：原告、被告、借款金额、借款日期、约定利率、还款情况、担保人、证据清单。AI用命名实体识别（NER）抽取人名地名，用时间抽取器整理事件时间线，再用规则库修正模型可能犯的低级错误。

服务员记下的那张点菜单，就是后厨能看懂的“结构化订单”——事实表越规范，后面的菜才越有机会做得地道。

X={x1,x2,…,xn},F={(ej, tj)∣ej∈X,  tj∈T}X=\{x_1,x_2,\dots,x_n\},\qquad F=\{(e_j,\,t_j)\mid e_j\in X,\; t_j\in\mathcal{T}\}
这里的 \(X\) 是你输入的那段案情描述，\(F\) 是AI抽取出的结构化事实表，\((e_j,t_j)\) 表示“从原文中找到一个实体，并给它贴上类型标签”。
  1. 案情分词把原始案情文本切成一串词或字。
    X={x1,x2,…,xn}X=\{x_1,x_2,\dots,x_n\}
  2. 候选实体从分词结果中挑出有法律意义的片段，比如人名、金额、日期。
    ej∈Xe_j\in X
  3. 类型标签给每个实体打上标签，例如“原告”“被告”“金额”“时间”。
    tj∈Tt_j\in\mathcal{T}
  4. 事实集合所有实体-标签配对组成结构化事实表，供后续推导使用。
    F={(ej, tj)∣ej∈X,  tj∈T}F=\{(e_j,\,t_j)\mid e_j\in X,\; t_j\in\mathcal{T}\}

诉讼请求推导

拿到点菜单后，厨师要决定做什么菜：是清蒸还是红烧，配什么料，用什么火候。AI拿到事实表后，也要依据法律规定推导“诉讼请求”——这是起诉状的灵魂，直接决定法院审什么、判什么。

这一步的技术核心叫“请求权基础分析”。所谓请求权基础，就是“我凭什么可以要求你还钱/赔偿/履行合同”的法律依据，比如《民法典》第667条的借款合同条款。AI会根据案由和事实表，在请求权基础知识库中检索匹配的法律条文，然后调用金额计算器算出本息、违约金或赔偿金，最后确定责任主体——是自然人、公司，还是连带责任人。

以最简单的民间借贷为例：借款50万元、年利率10%、借期1年，AI计算得出本息合计55万元，然后生成“请求判令被告偿还原告借款本金50万元及利息5万元”的规范化表述。整个过程，是把“法律推理”拆成了“规则匹配 + 数值计算 + 文本生成”三个可测试的模块。

选菜谱决定了菜的形态——选错请求权基础，诉讼请求就容易站不住脚，甚至被法院驳回。

R∗=arg⁡max⁡r∈R  Score(r∣F)R^*=\arg\max_{r\in\mathcal{R}}\;\text{Score}(r\mid F)
所有可能的诉讼请求放在集合 \(\mathcal{R}\) 里，每个请求都与事实表 \(F\) 算一个匹配分，得分最高的那个请求 \(R^*\) 就是最终写进起诉状的内容。
  1. 候选请求集合AI根据事实表枚举出所有可行的诉讼请求候选。
    R={r1,r2,…,rm}\mathcal{R}=\{r_1,r_2,\dots,r_m\}
  2. 事实条件每个请求都要拿事实表 \(F\) 来检验是否站得住脚。
    Score(r∣F)\text{Score}(r\mid F)
  3. 匹配评分评分函数综合法条匹配度、金额计算、证据支持度给出得分。
    Score(r∣F)=α⋅law(r)+β⋅calc(r)+γ⋅evidence(r)\text{Score}(r\mid F)= \alpha\cdot\text{law}(r)+\beta\cdot\text{calc}(r)+\gamma\cdot\text{evidence}(r)
  4. 最优选择用 \(\arg\max\) 选出得分最高的请求，作为最终诉讼请求。
    R∗=arg⁡max⁡r∈R  Score(r∣F)R^*=\arg\max_{r\in\mathcal{R}}\;\text{Score}(r\mid F)

文书格式规范

米其林评审不只看味道，摆盘、餐具、份量都有严格标准。法院对起诉状同样有硬性格式要求：标题叫“民事起诉状”而不是“告状书”；首部要写清原告被告的姓名、性别、身份证号、住址；正文按“诉讼请求—事实与理由”的顺序展开；尾部要写“此致XX人民法院”，落款签名加日期。任何一个环节出错，立案窗口都可能把材料退回。

AI生成文书时，工程师会先定义一套“文书Schema”——用JSON结构约束模型输出的字段、顺序和格式，像给厨师发了一张标准摆盘图纸。例如日期必须写成“2024年3月1日”，金额必须用阿拉伯数字，“法定代表人”与“法定代理人”不可混用，“委托诉讼代理人”必须有授权委托书支撑。

在技术实现上，通常用“约束解码”或“模板渲染”双重保险：大模型先按JSON schema生成结构化内容，再由渲染引擎套用排版模板输出正式文面。这样做的好处是，模型负责“写什么”，模板负责“怎么写”，各司其职。哪怕模型偶尔用词欠妥，模板的格式约束也能保证文书整体结构合规。

米其林摆盘不能乱，“首部—正文—尾部”就是法律界的摆盘铁律，顺序错了，菜再好吃也上不了桌。

D=(H ⊕ B ⊕ T)D=\big(H\,\oplus\,B\,\oplus\,T\big)
一份起诉状 \(D\) 可以拆成三块：首部 \(H\)（当事人信息）、正文 \(B\)（诉讼请求与事实理由）、尾部 \(T\)（此致法院与落款），按顺序拼接，顺序不能乱。
  1. 文书整体\(D\) 代表一份完整的起诉状，是最终交付物。
    DD
  2. 首部\(H\) 包含法院名称、案由和当事人身份信息。
    H={原告, 被告, 案由}H=\{\text{原告},\ \text{被告},\ \text{案由}\}
  3. 正文\(B\) 是诉状的灵魂，先写诉讼请求，再写事实与理由。
    B={诉讼请求, 事实与理由}B=\{\text{诉讼请求},\ \text{事实与理由}\}
  4. 尾部拼接用拼接符号 \(\oplus\) 表示三段按固定顺序组合，形成完整文书。
    D=H⊕B⊕TD=H\oplus B\oplus T

实体信息校验

餐厅出菜前，传菜口都有质检员把关：菜品颜色不对、缺了配菜、温度不够，一律打回重做。AI生成的起诉状，也必须经过层层“质检”才能提交给法院。这个过程叫实体信息校验，比格式规范更深入一步——它检查的不是排版，而是内容本身的真实性、合法性和时效性。

校验机制通常由“规则引擎 + 权威数据源”构成。规则引擎负责检查身份证号校验位、企业统一社会信用代码的格式；权威数据源则通过API对接公安系统、市场监督管理局数据库，核实当事人身份是否真实存在。此外，还要检查案由是否为法律承认的案由，管辖法院是否有管辖权，诉讼时效是否已经届满。

工程上常把校验做成“检查清单”：每一条规则是清单上的一项，全部打勾才算通过。一旦某项不通过，系统会给出具体的修改建议，例如“被告身份证号校验位错误，请核对第18位”。AI生成的文书草稿永远不会直接被提交，必须先过这一关。

质检员不点头，菜就不能端出厨房；校验不过关，起诉状同样会被法院“退菜”。

Valid(D)=∏k=1m1[ vk(D)=1 ]\text{Valid}(D)=\prod_{k=1}^{m}\mathbb{1}\big[\,v_k(D)=1\,\big]
这是把“质检”写成了数学公式：一共有 \(m\) 条校验规则，每条规则 \(v_k\) 就像质检员的一个检查动作，只有所有规则都判定通过，整份文书才算合格。
  1. 校验规则每一条规则 \(v_k\) 代表一次检查，例如“身份证号校验位正确”。
    vk(D)∈{0,1}v_k(D)\in\{0,1\}
  2. 指示函数\(\mathbb{1}[\cdot]\) 表示条件成立则取值1，不成立则取值0，相当于质检员打勾或打叉。
    1[ vk(D)=1 ]\mathbb{1}[\,v_k(D)=1\,]
  3. 全部通过连乘 \(\prod\) 表示所有规则都必须为1，任一规则失败则整体为0。
    ∏k=1m1[ vk(D)=1 ]\prod_{k=1}^{m}\mathbb{1}[\,v_k(D)=1\,]
  4. 合法性判定\(\text{Valid}(D)\) 输出1则文书通过，输出0则退回修改。
    Valid(D)∈{0,1}\text{Valid}(D)\in\{0,1\}

案件模板定制

川菜厨师和日料师傅的菜谱完全不同：川菜重麻辣，日料重本味。起诉状也分类型，婚姻家庭纠纷、合同纠纷、侵权责任纠纷、劳动争议，各自的要素、请求结构和证据要求差异巨大。给所有案件套同一个模板，就像让川菜师傅做刺身，做出来四不像。

因此，业界会为不同案由定制专属模板。以离婚纠纷为例，模板必须包含“感情是否破裂”这一法定标准，财产分割、子女抚养的请求结构也与合同纠纷截然不同；而劳动争议案件，则必须写明“已经过劳动仲裁前置程序”，否则法院直接不予受理。

工程实现上，模板以“配置化”方式管理：每一个案由模板包含四件套——提示词模板、字段Schema、校验规则、金额计算逻辑。AI先通过案由分类器判断案件类型，再加载对应模板，最后交给生成链路执行。新增一种案由时，只需添加一份模板配置，无需重新训练模型，实现了“开一家新店，只换菜谱不换后厨”。

不同菜系有专属菜谱，不同案由有专属模板——用对模板，生成的起诉状才“入味”。

Dτ=Templateτ(F,  Θτ)D_{\tau}=\text{Template}_{\tau}\big(F,\;\Theta_{\tau}\big)
不同的案件类型 \(\tau\) 对应不同的模板 \(\text{Template}_{\tau}\)，模板里装着该类案件特有的参数 \(\Theta_{\tau}\)（如利率、赔偿计算方式），最终生成符合该案由要求的文书。
  1. 案由类型\(\tau\) 表示案件类型，如“民间借贷纠纷”“离婚纠纷”。
    τ∈{婚姻家庭, 合同纠纷, 侵权, 劳动}\tau\in\{\text{婚姻家庭},\ \text{合同纠纷},\ \text{侵权},\ \text{劳动}\}
  2. 专属模板\(\text{Template}_{\tau}\) 是案件类型 \(\tau\) 定制的文书模板，包含结构、字段和规则。
    Templateτ={Schemaτ, Rulesτ, Calcτ}\text{Template}_{\tau}=\{\text{Schema}_{\tau},\ \text{Rules}_{\tau},\ \text{Calc}_{\tau}\}
  3. 模板参数\(\Theta_{\tau}\) 是该模板特有的参数集，例如借款利率计算方式、抚养费标准。
    Θτ={θ1,θ2,… }\Theta_{\tau}=\{\theta_1,\theta_2,\dots\}
  4. 模板输出输入事实表 \(F\) 和参数 \(\Theta_{\tau}\)，模板输出规范文书 \(D_{\tau}\)。
    Dτ=Templateτ(F,Θτ)D_{\tau}=\text{Template}_{\tau}(F,\Theta_{\tau})

生成链路部署

一家餐厅能稳定出餐，靠的不只是某位厨师的手艺，而是从供应链到灶台、从传菜到反馈的一整套系统。AI起诉状生成要真正落地，同样需要搭建完整的生产链路，从数据到模型再到部署，每个环节都不能掉链子。

标准链路分为四段：第一段是语料构建，收集脱敏后的裁判文书、起诉状样本，清洗去重后构建指令微调数据集；第二段是模型训练，在通用大模型基础上用法律语料做进一步训练，让模型学会法律文书的行文风格；第三段是服务部署，通过API网关对外提供生成服务，配好权限控制、限流和审计日志；第四段是人工校验兜底，由律师对AI生成的文书进行抽检，发现错误后反馈回数据集。

部署上线只是开始，真正让系统越用越好的，是“反馈闭环”机制。律师每修改一次AI生成的文书，系统都会记录差异并沉淀为新训练样本。随着修改数据不断积累，模型定期迭代更新，形成“数据→训练→部署→反馈”的飞轮。这也是AI+法律项目能持续创造价值的根本逻辑。

后厨的系统化运转，才能保证每位客人吃到稳定出品；标准化的生成链路，才能让每一份起诉状都稳定合规。

D=(V∘G∘E)(X)D=\big(V\circ G\circ E\big)(X)
这是整条流水线的端到端公式：原始案情 \(X\) 先经过事实提取 \(E\)，再由文书生成 \(G\) 起草，最后通过校验 \(V\) 放行，箭头方向就是数据流动的方向。
  1. 事实抽取\(E\) 把原始案情文本 \(X\) 整理成结构化事实表。
    F=E(X)F=E(X)
  2. 文书生成\(G\) 基于事实表 \(F\) 和案由模板，生成起诉状草稿。
    Ddraft=G(F)D_{\text{draft}}=G(F)
  3. 校验修正\(V\) 对草稿执行实体校验，不合格则打回或自动修复。
    D=V(Ddraft)D=V(D_{\text{draft}})
  4. 函数复合\(\circ\) 表示从右往左依次执行三个环节，前一步输出是后一步输入。
    D=(V∘G∘E)(X)D=(V\circ G\circ E)(X)

AI 应用场景

律所文书自动化工作流

阶段：事实提取 → 诉讼请求推导 → 文书生成 → 实体校验

解决的问题：传统律所里，年轻律师大量时间花在从聊天记录、转账凭证中整理事实、计算金额、撰写格式文书上，效率低且容易出错。AI接手后，律师只需上传案情描述和证据材料，系统自动生成符合格式的起诉状草稿，律师从“写手”升级为“审核者”。

具体案例：某中型律所接入AI起诉状生成系统，把民间借贷纠纷的文书准备时间从平均3小时压缩到20分钟。律师重点审核案件关键事实和金额计算，其余机械性工作全部交给系统，人均月处理案件量提升到原来的4倍。

互联网法院在线立案

阶段：案件分类 → 模板匹配 → 文书生成 → 管辖校验

解决的问题：在线立案平台每天面对大量当事人提交的起诉材料，格式五花八门，信息缺漏严重。AI在当事人填写案情问卷时实时生成诉状草稿，并用校验机制提示身份证号错误、管辖法院选错等问题，减少立案退件率。

具体案例：某省互联网法院在其在线立案小程序中嵌入诉状生成功能：用户勾选案由、填写纠纷经过，AI自动生成民事起诉状并预填当事人信息，立案材料一次性通过率从62%提升到93%。

法律援助批量诉状生成

阶段：事实提取 → 模板定制 → 批量生成 → 人工复核

解决的问题：法律援助中心常年面对农民工讨薪、劳动仲裁等批量性案件，人手严重不足。传统流程中一位法援律师一天只能写3-5份诉状，AI结合劳动争议专属模板可以批量起草，法援律师只需逐份复核签字。

具体案例：某市法律援助中心利用AI系统为一批涉及87名农民工的集体讨薪案件生成批量起诉状，统一案情、统一被告、统一请求格式，3天内完成全部文书准备工作，而人工方式预计需要3周。

Python 演示

python59 行
# -*- coding: utf-8 -*-"""简易起诉状生成演示:基于规则模板 + 轻量实体提取"""import reimport json  class ComplaintGenerator:    """起诉状生成器(演示版)"""     def __init__(self):        self.rule_map = {            "民间借贷纠纷": {"rate_default": 0.10, "tag": "合同纠纷"},            "离婚纠纷": {"rate_default": 0.00, "tag": "婚姻家庭"},            "劳动争议": {"rate_default": 0.00, "tag": "劳动仲裁前置"}        }     def extract_facts(self, text):        facts = {}        m = re.search(r"(\S{2,4})[向借到](\S{2,4})", text)        if m:            facts["原告"] = m.group(1)            facts["被告"] = m.group(2)        m = re.search(r"借款?(\d+(?:\.\d+)?)万元?", text)        if m:            facts["金额"] = float(m.group(1))        m = re.search(r"(\d{4})年(\d{1,2})月(\d{1,2})日", text)        if m:            facts["日期"] = f"{m.group(1)}年{m.group(2)}月{m.group(3)}日"        return facts     def derive_claims(self, facts, case_type):        claims = []        y = facts["日期"][:4] if "日期" in facts else "2024"        txt_y = y + "年"        if "金额" in facts and "原告" in facts and "被告" in facts:            amount = facts["金额"]            rate = self.rule_map.get(case_type, {}).get("rate_default", 0.0)            interest = round(amount * rate, 2)            claims.append(f"请求判令被告偿还借款本金{amount}万元及利息{interest}万元")        claims.append(f"请求判令被告承担本案全部诉讼费用")        return claims     def format_doc(self, facts, claims):        head = f"原告:{facts.get('原告','未知')} 被告:{facts.get('被告','未知')}"        body_claims = " ".join(f"{i+1}. {c}" for i, c in enumerate(claims))        return f"民事起诉状\n{head}\n诉讼请求:{body_claims}\n事实与理由:{facts.get('日期','')}发生纠纷,详见证据\n此致 人民法院\n具状人:{facts.get('原告','未知')}"     def generate(self, text, case_type="民间借贷纠纷"):        facts = self.extract_facts(text)        claims = self.derive_claims(facts, case_type)        doc = self.format_doc(facts, claims)        return json.dumps({"facts": facts, "claims": claims, "doc": doc}, ensure_ascii=False)  if __name__ == "__main__":    case_text = "张三向李四借款50万元,约定年利率10%,2024年3月1日到期未还"    gen = ComplaintGenerator()    result = gen.generate(case_text, "民间借贷纠纷")    print(result)
目的：用正则规则实现了一个极简起诉状生成器，演示“事实提取→请求推导→文书格式化”三步链路。
  1. self.rule_map不同案由对应的参数配置，相当于餐厅的“菜谱本”。
  2. re.search(r"(\S{2,4})[向借到](\S{2,4})", text)从案情文本中抓出原告和被告，相当于服务员记下谁请客。
  3. facts["金额"] = float(m.group(1))抽出借款金额，供后续计算利息使用。
  4. rate = self.rule_map.get(case_type, {}).get("rate_default", 0.0)查表获得该案由的默认利率。
  5. interest = round(amount * rate, 2)计算利息，模拟“请求推导”中的金额计算器。
  6. return json.dumps({...}, ensure_ascii=False)以结构化JSON返回，方便与前端或下游系统对接。

常见误区

误区很多初学者以为只要把案情丢给大模型，就能生成一份可以直接提交法院的完美起诉状，律师完全不用管。就像觉得有了菜谱，不需要厨师也能做出米其林大餐。

正解AI的定位是“律师的智能助理”，负责把机械性的格式工作和初稿生成做到极致，但法律策略、证据取舍、请求金额的合理范围这些需要法律判断力的环节，仍然依赖专业律师。目前的AI还会产生幻觉，可能编造不存在的法条或错误金额，必须由人工把关。

为何常见：因为大模型生成的自然语言太流畅，输出内容像模像样，初学者很难察觉其中隐藏的法律错误，自然高估了AI的可靠性。

误区认为只要AI生成的文书格式正确、结构完整，这份起诉状就没问题了。就像认为摆盘好看就等于菜好吃。

正解格式只是外壳，请求的合法性和事实的准确性才是内核。一份格式完美的起诉状，如果诉讼请求超过诉讼时效，或者援引的法律依据错误，依然会被法院驳回。真正的质检要穿透到实体内容层面，校验案由、时效、管辖权等实质要素。

为何常见：格式是肉眼可见的，实体错误则要懂法律才能辨别。外行看到格式整齐就以为万事大吉，形成了“表面合规=实质合规”的错觉。

误区既然ChatGPT都能写作文，那写起诉状也只需要一个提示词模板，不需要做专门的模型训练和工程校验。就像拿家常菜谱去做国宴。

正解通用大模型虽然懂一些法律知识，但不懂法院立案的具体格式要求，也不具备实体校验能力。专业落地需要四个环节配合：法律语料微调让模型“懂行”，模板约束让输出“合规”，规则引擎让信息“准确”，人工复核让结果“可靠”。只靠提示词，生成的文书大概率会被立案窗口退回。

为何常见：大模型的通用能力确实强，尤其在写作文、翻译等任务上效果惊艳，容易让人误以为它不需要行业定制就能处理任何专业任务。

误区把不同案由的模板定制理解成“把标题从民间借贷改成离婚纠纷就行”，其他内容照旧生成。

正解真正的模板定制是结构级的差异：离婚案件要审查“感情是否破裂”，合同案件要写“违约事实与违约金计算”，劳动争议要写“仲裁前置经过”。每个模板还要配套不同的校验规则、字段Schema和金额计算逻辑，是一个完整的配置包，而不是简单的字符串替换。

为何常见：因为外行看起诉状，看到的都是“标题+当事人+请求+事实理由”的大致结构，不易察觉不同案由在具体要素上的本质差异。

误区模型训练完、API上线，任务就算结束了，后面不用再更新。就像餐厅开业后再也不管厨师培训。

正解法律条文会修订，法院格式要求会更新，模型也会因为数据分布变化而性能衰减。业界普遍采用“反馈闭环”机制：收集律师修改意见和新增案例，定期增量训练，让模型持续进化。AI应用的长期效果取决于运营迭代，而非一次性上线。

为何常见：传统软件上线后可以稳定运行多年，AI模型却会随环境和数据变化而“生锈”，这种“模型要持续喂养”的运维理念，很多初入行的工程师并不熟悉。

面试题

Q1. 在起诉状生成的流程中，第一步通常做什么？

单选题 · easy

  • A.直接让模型输出完整起诉状
  • B.从案情描述中提取结构化事实← 正确答案
  • C.计算诉讼费用并缴纳
  • D.去法院查询管辖法官

答案：B。起诉状生成的第一步是事实要素提取，就像服务员先记下单，才能让后厨做菜。直接输出完整起诉状容易遗漏关键信息；计算诉讼费用和查询法官都是文书生成之后的事情。

Q2. 以下哪个属于“实体信息校验”要检查的内容？

单选题 · easy

  • A.起诉状字体是否美观
  • B.原告身份证号校验位是否正确← 正确答案
  • C.纸张是否合适合规格
  • D.起诉状标题是否加了粗体

答案：B。实体信息校验关注内容的真实性和合法性，身份证号校验位是典型检查项。字体、纸张、加粗属于排版范畴，格式规范可以管到，但不是实体校验的核心。

Q3. “请求权基础”指的是什么？

单选题 · mid

  • A.原告向法院立案庭提交的申请书
  • B.支持一方当事人提出请求的法律依据← 正确答案
  • C.法院收取诉讼费用的计算标准
  • D.律师代理案件时的收费依据

答案：B。请求权基础是“凭什么可以提出这个请求”的法律依据，比如民间借贷纠纷中的借款合同条款。它不是申请书本身，也不是诉讼费或律师费的计算标准。

Q4. 某AI系统在生成起诉状后，检测到被告的身份证号不符合校验规则，这属于哪一层面的校验？

单选题 · mid

  • A.格式规范校验
  • B.实体信息校验← 正确答案
  • C.排版样式校验
  • D.语言通顺度校验

答案：B。身份证号属于实体信息，其校验规则（如校验位算法）属于实体信息校验。格式规范校验管的是文书结构是否完整，排版和通顺度更不在其列。

Q5. 下列哪些是不同案由定制模板时需要考虑的差异点？

多选题 · mid

  • A.是否要求写明劳动仲裁前置经过程序← 正确答案
  • B.是否审查“感情是否破裂”这一法定标准← 正确答案
  • C.是否使用红色纸张打印文书
  • D.违约金与赔偿金的计算方式← 正确答案

答案：ABD。劳动争议要写明仲裁前置，离婚纠纷要审查感情破裂标准，合同纠纷的违约金计算方式也与侵权赔偿不同，这些都属于模板差异。用纸颜色不是合法规范，纯属误解。

Q6. 在起诉状生成流水线中，公式\(D=(V\circ G\circ E)(X)\)中符号\(\circ\)表示什么意思？

单选题 · mid

  • A.三个环节并行执行互不依赖
  • B.三个环节依次执行，前一步输出是后一步输入← 正确答案
  • C.三个环节随机执行任选其一
  • D.三个环节循环执行直到满足条件

答案：B。函数复合\(\circ\)表示从右往左依次执行：先抽取事实，再生成文书，最后校验，形成一条流水线。就像餐厅先记单、再烹饪、后质检，顺序不能乱。

Q7. 关于AI起诉状生成的“反馈闭环”，下列说法正确的是？

单选题 · hard

  • A.模型上线后无需更新维护
  • B.律师的修改意见应沉淀为新的训练数据← 正确答案
  • C.反馈数据越多，模型效果一定越差
  • D.反馈闭环的目的是减少人工复核人数

答案：B。反馈闭环的核心是把律师修改后的文书视为“黄金标注数据”，定期用于模型迭代，让系统越用越准。模型当然需要持续维护，反馈数据经筛选后通常提升效果，闭环目的也是提升质量而非单纯减人。

Q8. 一份合规的民事起诉状，其标准结构包括哪些部分？

多选题 · mid

  • A.首部（原告、被告身份信息）← 正确答案
  • B.正文（诉讼请求与事实理由）← 正确答案
  • C.尾部（此致法院、签名日期）← 正确答案
  • D.法院内部合议庭评议记录

答案：ABC。起诉状三要素是首部、正文、尾部，如同中餐的“头盘—主菜—甜点”。合议庭评议记录是法院内部文件，绝不可能出现在当事人的起诉状里。

Q9. 案件模板定制中，“模板配置四件套”不包括以下哪项？

单选题 · hard

  • A.提示词模板
  • B.字段Schema
  • C.校验规则与计算逻辑
  • D.案件的证据原件保管方式← 正确答案

答案：D。模板配置四件套是提示词、字段Schema、校验规则、计算逻辑，它们共同决定文书的结构与内容。证据原件由当事人和律师保管，与AI模板配置无关。

Q10. 以下哪些措施能有效降低AI生成起诉状的错误率？

多选题 · hard

  • A.用约束解码确保输出符合JSON Schema← 正确答案
  • B.对接权威数据源校验当事人信息← 正确答案
  • C.生成后由专业律师抽检复核← 正确答案
  • D.故意调高模型温度参数增强创造性

答案：ABC。约束解码保格式，权威数据校验保真实，律师复核保质量，三者共同构成质检体系。调高温度会增强随机性，反而更容易产生事实错误，属于典型的错误做法。