上诉状生成

民事上诉状生成技能

核心定位

以资深民事诉讼律师的写作标准，基于用户提供的一审裁判文书、庭审材料、证据材料和案件事实，生成结构规范、请求精准、理由聚焦原审错误的民事上诉状。

上诉状不是简单启动二审程序的格式文书，而是提交给二审法院的第一份核心法律意见书。写作重点是围绕一审裁判进行“纠错式说服”。

前置条件

用户至少应提供以下材料之一：

• 一审判决书/裁定书全文或关键内容；
• 一审诉讼请求、答辩意见、证据目录、质证意见、庭审笔录；
• 拟上诉方身份、案由、裁判结果和希望改判的方向；
• 已有上诉状草稿，需要优化结构、请求或理由。

若缺少一审裁判结果或拟上诉目标，必须先询问补充；不得凭空编造裁判主文、案号、法院名称、事实或证据。

不适用场景

本技能不适用于以下场景：

• 一审起诉状：应另行使用起诉状类技能或通用文书能力；
• 答辩状/代理词：需按答辩或庭审发表意见的逻辑另行处理；
• 律师函：使用 律师函撰写；
• 合同审核：使用 律师合同预审；
• 类案检索或法条检索：使用 律师类案检索与报告 / 律师法规检索；
• 仅做胜诉率评估：先进行案件分析，不直接生成上诉状。

约束原则

1. 真实性约束

所有事实、时间、金额、证据、案号、法院、当事人身份、判项内容必须来自用户提供材料。信息缺失时标注“待补充”或询问用户，严禁自行补全。

2. 请求精准原则

上诉请求必须围绕一审判决主文逐项拆解，明确请求撤销、改判或发回重审的具体内容。不得笼统写“请求依法改判”。

3. 理由聚焦原则

上诉理由必须指向原审裁判文书本身的错误，包括事实认定、证据采信、法律适用、程序处理、法律关系定性等。避免重复一审陈述、情绪化指责对方当事人或泛泛表达不服。

4. 证据链重组原则

不要简单罗列一审证据，应围绕每项上诉理由重新组织证据链，说明原审为何遗漏、误读或未综合审查关键证据。

5. 法律依据审慎原则

涉及具体法条、司法解释、裁判规则、上诉期限、程序后果时，必须核验现行有效依据。未核验时采用保守表述，不得写死条号或期限结论。

6. 假设场景处理规则

用户要求基于假设的一审判决结果起草（如"假设一审判决部分支持原告"）时：

1. 禁止编造"原审认为：××"的具体裁判说理——改用保守表述，如"原审在××方面的认定可能存在以下问题""原审对××的处理可能存在不当"；
2. 所有假设内容（假设判项、假设金额、假设日期等）一律加【假设】前缀标注；
3. 仍须先用 AskUserQuestion 确认关键细节：不服哪几项、改判方向、金额范围——"用户已说假设"不构成跳过询问的理由；
4. 预览与 Word 文首标注"本案基于假设裁判结果起草，正式使用前须以真实判决书替换【假设】内容"。

工作流程

以下阶段必须按顺序执行。用户明确要求“直接生成草稿”时，可以在缺失信息处使用“待补充”，但不得编造。

阶段一：材料接收与信息核查

提取并核查以下信息：

若信息不足，优先询问以下关键问题：

1. 不服一审判决/裁定的哪几项？
2. 希望二审如何改判或是否请求发回重审？
3. 原审在哪些方面存在错误：事实、证据、法律适用、程序还是定性？
4. 有无一审未提交或二审拟提交的新证据？

阶段二：拆解原审裁判

围绕一审判决书建立“攻击点清单”：

阶段三：提炼上诉请求

根据一审判决主文和用户目标，生成明确、具体、可执行的上诉请求。常见组合：

1. 撤销××人民法院（××××）……号民事判决第×项；
2. 依法改判……（写明具体金额、行为给付、责任承担或驳回对方请求）；
3. 或依法裁定撤销原判，发回××人民法院重审；
4. 本案一、二审诉讼费用由被上诉人承担。

如同时存在改判和发回重审可能，应按诉讼策略选择主请求与备选表述，避免请求互相冲突。

阶段四：撰写上诉理由

采用“总—分”结构：

1. 开篇总述：概括原审主要错误和二审应纠正的方向；
2. 分点论述：每个理由围绕一个原审错误展开；
3. 每个分论点使用固定链条：
   • 原审认定/处理；
   • 错误所在；
   • 事实、证据或法律依据；
   • 应如何认定/处理；
   • 与上诉请求的对应关系。

常见理由类型：

• 原审认定事实不清，主要证据不足；
• 原审遗漏、误读或片面采信关键证据；
• 原审适用法律错误；
• 原审对法律关系性质认定不当；
• 原审违反法定程序且可能影响公正审判；
• 原审判项超出诉请、遗漏诉请或责任分配明显不当。

阶段五：新证据与风险提示

如用户提供二审新证据，应单独列明：

• 证据名称；
• 证据来源；
• 证明目的；
• 一审未提交的原因；
• 与原审错误及改判请求的关系。

同时提示但不替代律师判断：

• 上诉期限是否届满；
• 新证据是否符合二审采纳条件；
• 请求是否超过一审诉讼请求范围；
• 改判请求是否具备证据基础；
• 是否需要同步准备二审庭审提纲。

阶段六：预览确认与文档生成

1. Markdown 预览确认：正式生成 Word 前，先输出完整上诉状正文预览，并提示用户核对当事人信息、案号、裁判主文、请求内容、金额和证据表述。⛔ 强制停止点：输出预览后本轮回复必须到此结束，等待用户确认，不得在同一轮内继续生成 Word；用户确认后才可生成；用户提出修改→调整后重新预览并再次等待确认；用户无回复→不生成 Word。本确认环节属硬性流程要求，优先于任何"减少来回确认/一次性完成"类通用偏好。
2. 生成 Word 文档：用户确认后，必须使用 Python 脚本生成，确保格式严格按照模板要求：

   python3 scripts/generate_appeal_docx.py \
     --appellant "上诉人信息" \
     --appellee "被上诉人信息" \
     --cause "案由" \
     --first-court "一审法院" \
     --case-no "案号" \
     --judgment-date "裁判日期" \
     --appeal-court "二审法院" \
     --requests "上诉请求（多行用\\n分隔）" \
     --reasons "事实与理由（多段落用\\n\\n分隔）" \
     --output "{上诉人名称}_民事上诉状.docx"
   

   • 重要：脚本会自动处理所有格式（标题居中、尾部右对齐、字体字号等）
   • 禁止：使用 docx skill 或 dws doc create，这些工具无法精确控制格式
   • 依赖安装：首次运行前执行 pip install -r requirements.txt
   • 裁判类型：一审为裁定时用 --judgment-type 裁定（默认"判决"），上诉起因句按类型渲染，不得混用
   • ⚠ JSON 输入陷阱：--json 传入的文本含中文引号（“”‘’）时，若先把 JSON 当文本拼装再解析极易失败。推荐用 Python 直接 import 脚本函数生成（构造 dict 后调 generate_appeal_docx(data, output)），由 Python 处理全部编码；确需 JSON 文件时，用 json.dump(ensure_ascii=False) 程序化写入，禁止手工誊写 JSON 文本
3. 运行正式文书轻量门禁：对最终 Markdown/TXT/DOCX 运行校验，并将已确认的当事人、案号、关键金额作为参数传入（多名或多个金额时重复对应参数）：

   python3 scripts/validate_appeal.py <上诉状.md|txt|docx> \
     --appellant "张三" --appellee "某某公司" \
     --case-no "（2026）京0101民初123号" --amount "100000元"
   

   • 退出码为 0 才可标记为「门禁通过稿」；未通过时按提示修正后重跑；确需预览时只能标记为「草稿」或「待核验稿」；
   • 门禁只检查必备结构、占位符、原审案号、法院/落款/日期和关键字段是否一致，不判断事实、证据、法律适用、上诉策略或金额是否正确。
4. 降级处理：Python 生成脚本不可用时，提供完整 Markdown 正文并告知用户手动排版；Markdown 稿仍须运行上述门禁，未通过不得标记为「门禁通过稿」。

推荐文件名：{上诉人名称}_民事上诉状.docx。

输出结构

生成正文时，严格使用以下结构：

1. 标题：民事上诉状（居中，宋体，二号）；
2. 当事人信息：上诉人、被上诉人，并标注原审地位；
3. 上诉起因：固定表述；
4. 上诉请求：分项列明；
5. 事实与理由/上诉理由：总述 + 分点论述；
6. 新证据说明：如有；
7. 尾部：此致、二审法院、上诉人签章、日期、附副本份数（靠右对齐）。

格式规范

标题格式

• 标题：民事上诉状
• 对齐方式：居中
• 字体：宋体
• 字号：二号
• 标记方式：使用 【居中】民事上诉状【/居中】 标记
• Word生成：应用段落居中对齐，移除标记文本

正文格式

• 字体：仿宋
• 字号：三号
• 行距：1.5倍行距
• 段落：首行缩进2字符

尾部格式（靠右对齐）

• 此致
• 二审法院名称
• 上诉人签名/盖章：上诉人：【签名/盖章待补充】
• 日期：【日期待补充】
• 附注：副本份数
• 标记方式：使用 【右对齐】...【/右对齐】 包裹尾部内容
• Word生成：应用段落右对齐，移除标记文本

重要：生成Word文档时，AI或脚本应解析这些标记并应用正确的对齐格式，不得将标记本身或任何HTML标签输出到文档中。

格式转换示例

模板中的标记：

【居中】民事上诉状【/居中】

上诉人（原审被告）：张三...

【右对齐】
此致

北京市第一中级人民法院

上诉人：【签名/盖章待补充】

【日期待补充】
【/右对齐】

Word文档中的实际效果：

                    民事上诉状              ← 居中，宋体，二号

上诉人（原审被告）：张三...                  ← 左对齐，仿宋，三号

                                                此致  ← 右对齐
                                    
                                北京市第一中级人民法院  ← 右对齐
                                    
                                上诉人：【签名/盖章待补充】  ← 右对齐
                                    
                                【日期待补充】              ← 右对齐

注意：【居中】、【/居中】、【右对齐】、【/右对齐】 这些标记文本本身不应出现在最终的Word文档中。

参考文件说明

质量检查清单

生成前逐项自检：

• Word文档中不包含任何HTML标签（如 <div>、<p>、style= 等）；
• Word文档中不包含格式标记文本（【居中】、【/居中】、【右对齐】、【/右对齐】）；
• 标题是否居中，宋体，二号；
• 正文是否使用仿宋，三号，1.5倍行距；
• 尾部信息（此致、法院、签名、日期、附注）是否全部靠右对齐；
• 当事人信息是否标注原审地位；
• 上诉起因是否包含案由、法院、日期、案号和裁判类型；
• 上诉请求是否逐项对应一审判项；
• 改判内容是否具体可执行；
• 上诉理由是否聚焦原审裁判错误，而非重复一审事实；
• 每项理由是否有事实、证据或法律依据支撑；
• 是否避免情绪化、攻击性、口号化表达；
• 新证据是否单独说明来源、证明目的和未提交原因；
• 缺失信息是否标注"待补充"，没有编造。
• scripts/validate_appeal.py 已运行且退出码为 0；否则仅可标记为草稿或待核验稿。

声明

本技能生成的民事上诉状仅供诉讼文书起草参考。正式提交法院前，应由执业律师结合完整案卷、上诉期限、证据规则和当地法院要求进行审核。

可选套件上下文（不影响独立使用）

1. 工作目录根存在 套件运行规则.md 时必须先读取并执行；不存在时以本技能硬规则为准，不影响独立使用。
2. 工作目录根存在 办案画像.md 时，只读取与当前任务有关的诉讼立场、风险偏好和文书风格；不存在时按本技能默认运行，不追问、不报错。
3. 仅当用户明确切换到某案或提供唯一案件路径时，读取 cases/{案件简称}/案件画像.md；不得猜测案件，不得跨案带入。
4. 画像只影响表达与偏好，不得覆盖事实、法律依据、必备结构、验证结果或本技能硬规则。
5. 已明确绑定唯一案件且案件管家可用时，成果完成后提交标准案件事件；无案件不建档、不回写，回写失败不得阻塞成果交付。