# Paper Er Workflow

> paper er workflow workflow.

- Skill: `kyrie66nb/paper-er-workflow` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add kyrie66nb/paper-er-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kyrie66nb/paper-er-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: kyrie66nb (https://skillmd.com/u/kyrie66nb)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kyrie66nb/paper-er-workflow

---


# Paper ER Workflow

## Overview

固定毕业论文写作流程：先统一目录，再统一ER与数据库表描述，再执行验收。

目标：让论文从”经验写作”变成”可检查交付”。

## When to Use

- 用户要求”按几篇论文目录统一写法”
- 用户要求”ER图怎么画、怎么优化美观”
- 用户要求”固定到Claude/Codex全局流程”
- 用户要求”补充论文内容”、”内容太少”、”工作量不足”

## Standard 7-Chapter Outline

1. 绪论
2. 相关技术与开发环境
3. 系统分析
4. 系统设计（含数据库设计）
5. 系统实现
6. 系统测试
7. 总结与展望

详情模板：`templates/outline-template.md`

## Content Density Requirements (内容密度要求)

### 页面填充标准
- **每页文字量**: 至少800-1000字/页（不含图表）
- **段落密度**: 每个小节至少3-5个自然段
- **小节间距**: 控制在1-2行，避免大片空白
- **图表配比**: 文字:图表 = 7:3 或 6:4

### 内容充实原则
1. **理论阐述要深入**
   - 不能只有定义，要有原理分析
   - 引用权威文献支撑观点
   - 结合实际案例说明应用

2. **技术介绍要详细**
   - 技术特点、优势、适用场景
   - 与其他技术的对比分析
   - 在本系统中的具体应用

3. **设计说明要具体**
   - 设计思路、设计原则
   - 详细的设计方案描述
   - 设计决策的理由说明

4. **实现过程要完整**
   - 关键代码片段及解释
   - 实现难点及解决方案
   - 功能实现的详细步骤

5. **测试内容要充分**
   - 测试用例设计思路
   - 详细的测试步骤
   - 测试结果分析与总结

### 避免的问题
- ❌ 每个小节只有1-2行文字
- ❌ 小节之间空隙过大（超过3行）
- ❌ 只有标题和简单定义，没有展开
- ❌ 缺少具体案例和数据支撑
- ❌ 图表过多，文字说明不足

### 合格标准
- ✓ 每页至少800字纯文字内容
- ✓ 每个小节至少200-300字
- ✓ 段落之间逻辑连贯，过渡自然
- ✓ 理论与实践相结合
- ✓ 有数据、图表、代码等支撑材料

## Content Expansion Templates (内容扩展模板)

### 技术介绍章节扩展模板
```
### X.X.X 技术名称

#### 技术概述
[技术名称]是[技术类型]，主要用于[应用场景]。该技术由[组织/个人]于[年份]提出，
目前已广泛应用于[应用领域]。

#### 核心原理
[技术名称]的核心原理是[原理描述]。其工作流程如下：
1. [步骤1描述]
2. [步骤2描述]
3. [步骤3描述]

从技术实现角度看，[技术名称]采用[实现方式]，通过[关键机制]实现[核心功能]。
相比传统的[对比技术]，该技术具有[优势1]、[优势2]等显著优势。

#### 技术特点
[技术名称]具有以下主要特点：

1. **[特点1]**：[详细说明]。例如，在[具体场景]中，该特点使得[具体效果]。

2. **[特点2]**：[详细说明]。研究表明[引用数据/文献]，该特点能够[具体效果]。

3. **[特点3]**：[详细说明]。与[对比对象]相比，[具体对比数据]。

#### 应用场景
[技术名称]主要应用于以下场景：

- **[场景1]**：在[场景描述]中，该技术可以[解决问题/实现功能]。典型案例包括[案例1]、[案例2]等。

- **[场景2]**：针对[场景描述]，该技术通过[技术手段]实现[目标效果]。

#### 在本系统中的应用
本系统采用[技术名称]实现[具体功能]。选择该技术的主要原因包括：

1. [原因1]：本系统需要[需求描述]，而[技术名称]能够[满足方式]。

2. [原因2]：考虑到[考虑因素]，[技术名称]相比[其他方案]更加[优势描述]。

3. [原因3]：从[角度]来看，[技术名称]具有[具体优势]，能够保证[质量指标]。

在具体实现中，本系统[实现描述]，实现了[功能列表]等核心功能。
```

### 需求分析章节扩展模板
```
### X.X 需求类型

#### 需求背景
[需求背景描述]。当前[现状描述]，存在[问题1]、[问题2]等问题。为了[目标描述]，
需要[需求概述]。

#### 需求调研
通过对[调研对象]的调研分析，发现[发现1]、[发现2]。具体表现为：

1. **[表现1]**：[详细描述]。调研数据显示，[数据描述]。

2. **[表现2]**：[详细描述]。用户反馈表明，[反馈内容]。

3. **[表现3]**：[详细描述]。市场分析表明，[分析结果]。

#### 功能需求
基于以上分析，系统需要实现以下功能：

**FR-X.1 [功能名称]**
- **功能描述**：系统应当能够[功能描述]，支持[支持内容]。
- **输入**：[输入描述]
- **处理**：[处理逻辑]
- **输出**：[输出描述]
- **优先级**：高/中/低

**FR-X.2 [功能名称]**
[同上格式]

#### 非功能需求
**性能需求**
- 响应时间：[具体指标]
- 并发用户数：[具体指标]
- 数据处理能力：[具体指标]

**安全需求**
- 数据加密：[具体要求]
- 访问控制：[具体要求]
- 日志审计：[具体要求]

**可靠性需求**
- 系统可用性：[具体指标]
- 故障恢复时间：[具体指标]
- 数据备份：[具体要求]
```

### 系统设计章节扩展模板
```
### X.X 设计模块

#### 设计目标
本模块的设计目标是[目标描述]。为实现该目标，需要满足以下要求：
1. [要求1]
2. [要求2]
3. [要求3]

#### 设计原则
在设计过程中，遵循以下原则：

1. **[原则1]**：[原则说明]。这样设计的好处是[好处描述]。

2. **[原则2]**：[原则说明]。通过[实现方式]，确保[质量目标]。

3. **[原则3]**：[原则说明]。参考[参考标准/最佳实践]，采用[设计方法]。

#### 总体设计
[模块名称]采用[架构模式]，整体分为[层次1]、[层次2]、[层次3]。

**[层次1]**：负责[职责描述]。该层包含[组件列表]，通过[交互方式]实现[功能描述]。

**[层次2]**：负责[职责描述]。该层采用[技术方案]，实现[功能列表]。

**[层次3]**：负责[职责描述]。该层通过[实现方式]，保证[质量指标]。

#### 详细设计
**[子模块1]设计**

功能描述：[功能描述]

设计思路：[设计思路描述]。考虑到[考虑因素]，采用[设计方案]。

主要类/接口：
- `[类名1]`：[职责描述]
  - 属性：[属性列表]
  - 方法：[方法列表]

- `[类名2]`：[职责描述]
  - 属性：[属性列表]
  - 方法：[方法列表]

交互流程：
1. [步骤1]
2. [步骤2]
3. [步骤3]

**[子模块2]设计**
[同上格式]
```

### 系统实现章节扩展模板
```
### X.X 功能实现

#### 实现概述
[功能名称]的实现基于[技术栈]，采用[实现方式]。本节详细介绍该功能的实现过程。

#### 技术选型
在实现该功能时，对比了多种技术方案：

| 方案 | 优点 | 缺点 | 适用性 |
|------|------|------|--------|
| [方案1] | [优点] | [缺点] | [适用性] |
| [方案2] | [优点] | [缺点] | [适用性] |
| [方案3] | [优点] | [缺点] | [适用性] |

综合考虑[考虑因素]，最终选择[选定方案]。

#### 核心代码实现
**[功能点1]实现**

```[语言]
// 代码片段
[关键代码]
```

代码说明：
- 第X行：[说明]
- 第Y行：[说明]
- 第Z行：[说明]

该实现的关键在于[关键点描述]。通过[技术手段]，实现了[功能效果]。

**[功能点2]实现**
[同上格式]

#### 实现难点及解决方案
**难点1：[难点描述]**

问题描述：在实现过程中遇到[问题描述]。具体表现为[具体表现]。

解决方案：经过分析，问题的根源在于[原因分析]。采用[解决方法]，通过[实现步骤]，
最终解决了该问题。

效果验证：[验证方法]表明，该方案[效果描述]。

**难点2：[难点描述]**
[同上格式]

#### 功能测试
对实现的功能进行了测试，测试结果如下：

| 测试项 | 测试方法 | 预期结果 | 实际结果 | 状态 |
|--------|----------|----------|----------|------|
| [测试项1] | [方法] | [预期] | [实际] | ✓ |
| [测试项2] | [方法] | [预期] | [实际] | ✓ |

测试表明，该功能[测试结论]。
```

## Writing Guidelines (写作指南)

### 文字密度控制
- 每个三级标题（X.X.X）下至少300字
- 每个二级标题（X.X）下至少800字
- 避免连续出现多个只有1-2行的小节

### 段落组织
- 每段3-5句话，每句15-30字
- 段落之间有逻辑关联词（因此、所以、此外、同时等）
- 避免单句成段

### 内容充实技巧
1. **定义+原理+应用**：不只说是什么，还要说为什么、怎么用
2. **对比分析**：与其他方案对比，突出优势
3. **数据支撑**：引用具体数据、案例、文献
4. **图文并茂**：文字描述+图表展示
5. **理论实践结合**：理论阐述+本系统应用

### 常用扩展方法
- 技术介绍：概述→原理→特点→应用→本系统应用
- 需求分析：背景→调研→功能需求→非功能需求
- 系统设计：目标→原则→总体设计→详细设计
- 系统实现：概述→技术选型→代码实现→难点解决
- 系统测试：测试环境→测试用例→测试结果→结果分析

## ER Quality Gate (DoD)

每条关系必须有：关系名、基数、参与约束、外键。  
每张表必须有：主键、外键、唯一约束、非空、索引、默认值。

检查清单：`templates/er-dod-checklist.md`

## Visual Improvement Rules

- 一张总图 + 多张子图（按业务模块拆分）
- 减少交叉线，统一 90° 折线风格
- 字段命名统一（`id`、`xxx_id`）
- 图题统一（`图4-x 系统ER图` / `图4-x 模块ER图`）

## Claude + Codex Collaboration

Claude负责：提纲、ER矩阵、验收标准。  
Codex负责：正文落地、结构补齐、编号术语统一。  
Claude终审：只退回未过DoD项。

交接模板：`templates/claude-codex-handoff.md`

## Quick Extraction Command

```bash
python3 scripts/extract_paper_outline.py /path/to/papers --output /path/to/summary.md
```