Lawd Civil Appeal Petition Generator

---
name: 上诉状生成
name_en: lawd-civil-appeal-petition-generator
displayName: 上诉状生成
description_en: "Civil appeal petition generation skill: generates or refines a professional civil appeal petition based on the user-provided first-instance judgment, trial materials, evidence catalog, cross-examination opinions, and case facts, with requests and reasons focused on errors in fact-finding, evidence assessment, legal application, or procedure. Triggered when users mention keywords such as appeal, second instance, or dissatisfaction with the first-instance judgment, ask to draft, revise, or polish an appeal petition, or provide a judgment and want appeal requests and reasons extracted. Output: Word appeal petition."
argument-hint: "一审判决书要点与上诉目标"
description: '民事上诉状生成技能。根据用户提供的一审判决书、庭审材料、证据目录、质证意见及案件事实，生成或优化专业民事上诉状。TRIGGER when: (1) 用户提及"上诉状"、"民事上诉"、"二审上诉"、"不服一审判决"、"改判"、"发回重审"等关键词，(2) 用户要求起草/修改/润色上诉状，(3) 用户提供一审裁判文书并希望提炼上诉请求和上诉理由，(4) 用户需要将事实认定、证据采信、法律适用或程序问题转化为二审上诉理由。IMPORTANT: 上诉状应聚焦原审裁判错误，请求必须明确具体可执行，理由必须围绕事实认定、证据审查、法律适用、程序处理等裁判错误展开，严禁编造事实、证据、案号、法院、法律依据或上诉期限。NOT for: 一审起诉状、答辩状、律师函、合同审查、类案检索报告、单纯法律咨询。'
version: "1.0.0"
categories: ["法律", "诉讼文书", "民事二审", "文档起草"]
tags: ["上诉状", "民事上诉", "二审", "改判", "发回重审", "诉讼文书"]
icon: "⚖️"
---

# 民事上诉状生成技能

## 核心定位

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

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

## 前置条件

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

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

## 不适用场景

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

## 约束原则

### 1. 真实性约束

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

### 2. 请求精准原则

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

### 3. 理由聚焦原则

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

### 4. 证据链重组原则

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

### 5. 法律依据审慎原则

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

### 6. 假设场景处理规则

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

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

## 工作流程

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

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

提取并核查以下信息：

| 信息项 | 要求 |
|--------|------|
| 上诉人信息 | 姓名/名称、原审地位、联系方式、住所地等 |
| 被上诉人信息 | 姓名/名称、原审地位、联系方式、住所地等 |
| 一审法院 | 法院名称 |
| 一审案号 | 完整案号 |
| 裁判日期 | 判决/裁定作出日期 |
| 案由 | 与原审一致 |
| 裁判结果 | 逐项拆解一审判决主文 |
| 上诉目标 | 全部改判、部分改判、发回重审、撤销某项等 |
| 关键证据 | 支撑上诉理由的证据及其证明目的 |
| 上诉期限 | 判决15日、裁定10日等需提示核验 |

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

### 阶段二：拆解原审裁判

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

| 原审内容 | 可能错误 | 支撑材料 | 上诉方向 |
|----------|----------|----------|----------|
| 原审认定的关键事实 | 事实不清/证据不足/遗漏事实 | 证据名称、页码或来源 | 请求重新认定事实 |
| 原审采信或未采信证据 | 证据链断裂/未综合审查/采信错误 | 证据目录、质证意见 | 请求纠正证据评价 |
| 原审法律适用 | 法律关系定性错误/法条适用错误 | 合同文本、法律依据 | 请求改判 |
| 原审程序处理 | 剥夺辩论权/遗漏诉请/程序违法 | 庭审笔录、裁定 | 请求撤销或发回 |

### 阶段三：提炼上诉请求

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

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

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

### 阶段四：撰写上诉理由

采用“总—分”结构：

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

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

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

如用户提供二审新证据，应单独列明：
- 证据名称；
- 证据来源；
- 证明目的；
- 一审未提交的原因；
- 与原审错误及改判请求的关系。

同时提示但不替代律师判断：
- 上诉期限是否届满；
- 新证据是否符合二审采纳条件；
- 请求是否超过一审诉讼请求范围；
- 改判请求是否具备证据基础；
- 是否需要同步准备二审庭审提纲。

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

1. **Markdown 预览确认**：正式生成 Word 前，先输出完整上诉状正文预览，并提示用户核对当事人信息、案号、裁判主文、请求内容、金额和证据表述。⛔ **强制停止点**：输出预览后**本轮回复必须到此结束，等待用户确认，不得在同一轮内继续生成 Word**；用户确认后才可生成；用户提出修改→调整后重新预览并再次等待确认；用户无回复→不生成 Word。本确认环节属硬性流程要求，优先于任何"减少来回确认/一次性完成"类通用偏好。
2. **生成 Word 文档**：用户确认后，**必须使用 Python 脚本生成**，确保格式严格按照模板要求：
   ```bash
   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 运行校验，并将已确认的当事人、案号、关键金额作为参数传入（多名或多个金额时重复对应参数）：
   ```bash
   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文档中**。

## 参考文件说明

| 文件 | 用途 | 何时使用 |
|------|------|----------|
| [references/appeal-template.md](references/appeal-template.md) | 民事上诉状标准模板 | 生成 Markdown 预览时参考格式 |
| [references/writing-guidelines.md](references/writing-guidelines.md) | 上诉请求与理由写作指南 | 提炼请求、组织理由、质量检查时参考 |
| [scripts/generate_appeal_docx.py](scripts/generate_appeal_docx.py) | Word 文档生成脚本 | 生成 .docx 文件时**必须使用** |
| [scripts/validate_appeal.py](scripts/validate_appeal.py) | 正式文书轻量门禁 | 最终稿标记为「门禁通过稿」前必须运行 |
| [requirements.txt](requirements.txt) | Python 依赖 | 首次运行前执行 `pip install -r requirements.txt` |

## 质量检查清单

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

## 声明

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

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

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