Ruankao Essay Writing | 软考论文写作

SKILL.md

---
name: ruankao-essay-writing
description: 覆盖软考系统架构设计师论文写作全流程（项目准备→试题分析→提纲撰写→摘要撰写→正文填充→检查校对），提供 SCQA 框架、金字塔原理、素材库建设等专业指导。当用户提到"帮我写论文""论文指导""如何准备论文""改论文""论文提纲""论文模板"等涉及论文写作的需求时触发。不适用于论文评分（那是 ruankao-essay-scoring 的职责）。
---

# 软考论文写作指导

辅助用户完成软考系统架构设计师考试的论文写作，提供从项目准备到成文校对的全流程指导，确保论文符合阅卷标准、避免常见失分点。

## 工作方式

论文写作遵循以下步骤：

0. **项目准备与素材库建设** — 考前选定项目、收集资料、建立可复用素材库
1. **分析论文试题** — 精读试题，圈出要点，确保每个子问题不遗漏
2. **撰写提纲** — 按模板列提纲，明确结构、逻辑链条和论证要点
3. **摘要撰写** — 按模板写 300-400 字摘要
4. **正文撰写（填充内容）** — 按提纲填充，运用 SCQA、金字塔原理、5W2H
5. **检查校对** — 逐项检查，确保完整回应试题、结构严谨、逻辑自洽

根据用户所处阶段灵活切入：
- 需要帮助准备项目素材 → 从 Phase 0 开始
- 只给了题目 → 从 Phase 1 开始
- 已有草稿 → 直接进入 Phase 5 自查

---

## Phase 0：项目准备与素材库建设

> 此阶段为**考前准备**，在考试前完成。考试当天直接调用素材库，无需现场构思项目。

项目对于写好论文至关重要——解决方案必须依托实际项目，脱离项目就成了"空中楼阁"，所有分析和论证都将失去立足点和说服力。

### 项目选择

一个合适的项目应同时满足以下条件：

| 条件 | 说明 |
|------|------|
| **熟悉度** | 优先选择自己亲身参与或非常熟悉的项目，能提供真实、详细的案例分析 |
| **时效性** | 优先选择最近两三年内的项目，确保反映当前技术趋势和行业发展状况 |
| **符合潮流** | 体现数字化转型、智能化升级、AI应用、大数据、5G、区块链等热门方向 |
| **复杂度** | 具备业务复杂度和技术复杂度，能体现架构设计的难点和专业水准 |

**业务复杂度**体现为：涉及多部门/多角色/多业务流程协作、较深专业领域知识、业务场景多样性、需求变更频繁。

**技术复杂度**体现为：微服务引入的服务治理与分布式事务、多质量属性间的权衡取舍等。技术选型中"怎么权衡取舍"依赖架构师的经验和对业务的理解，没有放之四海而皆准的标准答案。

#### 避免选择的项目类型

- ❌ **小型系统**：功能单一、规模小，难以展示深度和广度
- ❌ **过时技术项目**：不利于展示技术视野和对行业趋势的把握
- ❌ **纯硬件项目**：难以体现信息系统整体架构和解决方案
- ❌ **纯技术项目**：缺乏业务背景和应用场景，难以展示系统如何服务业务需求

### 项目准备

确定项目后，从以下三方面深入准备：

#### 1. 收集项目文档

| 文档类型 | 作用 | 论文用途 |
|----------|------|----------|
| **需求文档** | 明确功能性/非功能性需求 | 问题背景和解决方案价值的依据 |
| **设计文档** | 了解架构、技术选型、数据模型、接口规范 | 论证"为什么这样设计" |
| **测试报告** | 了解质量状况、性能数据 | 方案评估的有力支撑 |
| **用户反馈** | 了解实际使用效果和满意度 | 方案价值的佐证和改进方向 |
| **故障报告** | 发现潜在改进点 | 完善解决方案的素材 |

#### 2. 梳理项目背景

以下内容将成为论文"项目背景"部分的核心素材，特别要注意项目中的**痛点和难点**：

- **项目名称**：见名知意
- **项目发起方 / 承建方**：谁发起、谁承建
- **项目建设目的**：一两句话说明解决什么问题
- **我的角色及职责**：架构师或核心设计角色
- **项目起止时间及关键里程碑**：精确到年月，分期任务
- **项目建设内容**：功能模块/子系统及其职责和功能
- **业务架构**：业务目标与战略、核心业务流程、业务能力模型、业务规则、组织结构
- **应用架构**：子系统/模块职责及交互关系
- **数据架构**：数据存储、加工、流动与管理策略（数据模型、OLAP/OLTP、读写分离、数据分片、治理机制等）
- **技术架构**：使用的技术及每种技术解决的问题
- **项目成果**：解决的问题、带来的收益
- **关键数据指标**：用户量、数据量、QPS/TPS、响应时间、用户满意度等

#### 3. 项目难点与挑战

从两个维度梳理，这是最能体现专业能力和解决问题能力的关键内容：

**业务难点**：
- 业务流程复杂性（复杂决策点、特殊规则、例外处理）
- 跨部门协作难题及协作机制建设
- 需求变更管理（需求管理流程、敏捷方法、灵活架构设计）
- 业务创新（缺乏成熟经验时的探索）

**技术难点**：
- 技术选型挑战（权衡因素和决策过程）
- 性能优化（高并发、大数据量、低延迟的瓶颈及优化措施）
- 安全保障（安全架构设计和防护措施）
- 系统集成（与遗留系统/第三方系统集成的挑战和解决方法）
- 技术创新（创新技术或自研组件及解决的关键问题）

> 难点不要求是"世界级难题"，只要是"现状与期望目标之间的矛盾"即可。

### 建立素材库

以有限的素材应对无限的考察范围，达到**以少胜多、以不变应万变**的效果。

**方法**：

1. 选择 **3-7 个核心业务场景**，不管遇到什么主题都写这些业务场景
2. 针对每个业务场景，按**软件工程生命周期**梳理：
   - 每个阶段的任务
   - 面临的问题和挑战
   - 采用了哪些工具/方法/手段/步骤来解决问题
   - 解决过程中遇到的问题和解决方案
   - 最终效果、做得好的地方及待改进之处
3. 按**金字塔原理 + SCQA 结构**组织每个素材，用 **5W2H** 补充细节增强真实性

每个素材 = 一个完整的具体事例/案例，可独立使用。

读取 `references/project-preparation.md` 获取素材库示例及更详细的指导。

---

## Phase 1：分析论文试题

> 考试当天第一步，拿到试题后**必须先分析再动笔**。

### 逐题精读，圈出要点

走题是最常见的致命问题。**不要看到熟悉主题就默写准备好的论文**，必须：

1. **逐一阅读每个子问题**，特别是第二个子问题
2. **圈出每个要点**，写作时一定不能遗漏任何一个要点
3. **以试题的子问题为论文的核心段落/部分**

### 分析要点

- 同一主题，问题不同则考查侧重点完全不同
- 第二个子问题通常是理论+实践的核心考查点，**必须每个要点都回答到位**，避免不必要的丢分
- 将试题问题映射到素材库中的素材，确定使用哪些业务场景来支撑论述

---

## Phase 2：撰写提纲

> 很多人跳过这一步，结果写着写着思维混乱、结构松散，不得不返工重写。**提纲让写作变成"填空题"**。

### 提纲的作用

1. **明确论文结构**：预先设计整体结构，确保各部分清晰、重点突出
2. **梳理逻辑链条**：论点之间的逻辑关系环环相扣，避免跳跃或断裂
3. **提高写作效率**：按提纲逐一展开，不必反复思考"下一步该写什么"
4. **避免遗漏要点**：确保试题中的每个要点都得到回应

### 推荐提纲模板

读取 `references/outline-template.md` 获取完整提纲模板及填写指导。

核心结构概览：

```
## 摘要
项目时间 + 发起方 + 建设方 + 项目名称 + 角色和职责
+ 项目建设内容（概括）+ 中心论点（概括）+ 方案效果 + 项目成果

## 正文

### 项目背景
项目时间 + 发起方 + 建设方 + 项目名称 + 角色和职责
+ 项目建设内容（详细）+ 技术架构（详细）

### {与主题相关的标题}
1. 通过SCQA，引出论文主题
2. 回答子题目2中的理论问题：{要点1} {要点2} {要点3}
3. 简要概括中心论点：我们在项目中是如何做的？

### 分论点1
S： / C： / Q： / A：
举的例子：例子1

### 分论点2
S： / C： / Q： / A：
举的例子：例子2

### 分论点3
S： / C： / Q： / A：
举的例子：例子3

### 总结与感悟
1. 概括解决方案取得的效果
2. 概括项目取得的成果
3. 项目成功交付上线
4. 不足与改进 / 对主题的深刻理解（架构权衡、敬畏之心、沟通技巧等）
5. 未来展望
```

---

## Phase 3：摘要撰写

### 核心要求

| 要求 | 标准 |
|------|------|
| 字数 | 300-400 字（不少于 120 字，否则直接不及格；少于 300 字扣 5-10 分） |
| 内容 | 概括正文全貌，含实质性内容，不要只谈大道理 |
| 帽子 | 一般不加"帽子"性语句；字数不够时可加 50 字左右 |

### 摘要模板

读取 `references/abstract-templates.md` 获取 4 种摘要模板及示例。选择与项目素材最匹配的模板，填充具体内容。

### 写作顺序建议

- **写作速度快的考生**：先写正文，后写摘要——正文正常发挥，摘要水到渠成。风险：时间不够则无摘要，损失大。
- **写作速度慢的考生**：先写摘要，后写正文——摘要指导正文方向。风险：可能限制正文发挥。

> 注意：正文不是摘要的延伸，而是摘要的扩展。摘要不是正文的部分，而是正文的抽象。不要把正文"接"着摘要写。

---

## Phase 4：正文撰写（填充内容）

### 正文字数要求

目标 2500-3000 字，不少于 2000 字（显得无内容），不超过 4000 字（时间不够写不完）。

正文完成后，直接对文本计算字数：提取"一、×××"到"结束语/总结"之间的内容，统计中文字符数（`len([c for c in body if '\u4e00' <= c <= '\u9fff'])`），目标 2500-3000 字。

### 内容填充方法

按照提纲逐部分填充，运用以下三个框架：

- **金字塔原理**：结论先行，以上统下，归类分组，逻辑递进
- **SCQA 框架**：Situation（情境）→ Complication（冲突）→ Question（问题）→ Answer（回答）——每个分论点的基本结构
- **5W2H**：Who、What、When、Where、Why、How、How much——补充必要细节，增强真实性

### 六大写作原则

#### 1. 以自我为中心

论文考核的是考生做了什么，不是项目多牛。必须清楚说明：
- 针对具体项目，自己所做事情的**由来**
- 遇到的**问题**
- **解决方法**和**实施效果**

具体要求：
- 体现实际经验，不罗列课本内容
- 条理性地说明实际经验
- 写明项目开发体制和规模
- 明确"我"的工作任务和所起的作用
- 以"我"在项目中的贡献为重点
- 以"我"的努力（怎样做出贡献的）为中心

> 注意：虽然强调"以我为中心"，但不要到处都是"我"。稍大的项目是集体劳动，建议适当用"我们"替代部分"我"。

#### 2. 站在架构师角度

从全局角度把握：
- 架构的优点及缺点
- 架构设计的方法和过程
- 各层次之间的接口设计
- 而非专注于某个具体的实现细节

#### 3. 忠实于论点

- 仔细阅读试题要求，正确理解题意
- 根据试题问题提取论点加以阐述
- 阐述时绝对服从论点，就试题问题展开
- 不要节外生枝，不要偏离论点

#### 4. 条理清晰，开门见山

- 选定题目后，迅速整理素材，列出提纲
- 提纲不要求全面，关键列出**自己做过的工作**
- 项目概述要精练——背景、意义、规模、开发过程、自己的角色
- 每个自然段不超过 8 行，避免阅卷疲劳

#### 5. 标新立异，要有主见

- 不要刻意追求新奇，但要有自己的见解
- 让阅卷专家有耳目一新的感觉

#### 6. 表达书面化，段落转承自然

论文是正式书面文体，必须使用规范的技术写作语言。

**书面化表达要点**：
- 使用完整句式，避免过于口语化的短句堆砌
- 以名词化结构替代动词短语，例如"我们对系统进行了重构"优于"我们重构了系统"
- 使用技术术语和行业惯用语，体现专业水准
- 避免"然后""所以""就是说"等口语化连接词
- 避免感叹号、省略号等非正式标点
- 引入概念时使用"所谓""是指""即"等书面引导词

**段落转承技巧**：
- 段落之间使用过渡句承上启下，如"解决了上述问题后，另一个挑战随之而来""在确定了总体架构后，接下来需要关注模块间的接口设计"
- 每个段落开头先用一句话点明本段主旨，再展开论述
- 转折关系使用"然而""但与此同时""值得注意的是"
- 递进关系使用"在此基础上""更进一步""不仅如此"
- 因果关系使用"基于此""鉴于此""正是出于这样的考虑"
- 总结关系使用"综上所述""总的来看""从上述实践可以看出"

> 好的段落转承让文章读起来流畅自然，阅卷专家不会感到"跳跃感"。过渡句不需要华丽，关键在于逻辑顺畅。

### 技术深度要求

选择 **5-6 个**有特色的技术/方法进行深入展开，以便考试时根据时间和篇幅动态删减至 2-3 个最终呈现。每个措施要：
- 紧密结合主题项目
- 以主题项目中的具体内容为例
- 说明"如何做的"而非"是什么"

> 实践部分重点描述理论知识要点在项目中的应用，而不是介绍项目本身功能。

### 交付说明

每次生成论文正文后，按字数统计方法计算正文字数并向用户展示。同时提醒用户：

> **考试论文正文在 2500 字左右即可。在实际誊抄时，对论点进行适当精简，重点说明 2~3 个分论点即可，不必全部堆砌。**

---

## Phase 5：检查校对

完成初稿后，逐项检查。这是确保文章质量的关键一步，不可因时间紧迫而忽略。读取 `references/common-issues.md` 获取完整 17 项检查清单及每条问题的修正建议。按字数统计方法确认字数达标。

检查完成后，可调用 **ruankao-essay-scoring** 技能对论文进行逐维度评分，获取量化反馈与提分建议。

---

## 工作流示例

### 示例 1：用户需要考前准备项目素材

用户："我还没准备论文项目，该怎么开始？"

从 **Phase 0** 开始，引导用户选定项目、梳理项目背景、建立素材库。完成后建议用户保存素材供考试使用。

### 示例 2：用户给出论题，从零开始写论文

用户："帮我写一篇论层次式架构设计的论文"

1. **Phase 1**：分析试题，圈出子问题要点，映射素材库
2. **Phase 2**：按提纲模板（见 outline-template.md）列出完整提纲
3. **Phase 3**：选择摘要模板（见 abstract-templates.md）撰写摘要
4. **Phase 4**：按 SCQA 框架填充正文，准备 5-6 个技术点深入展开后动态删减
5. **Phase 5**：逐项检查（见 common-issues.md），修正问题后交付
6. 建议调用 **ruankao-essay-scoring** 技能获取量化评分诊断

### 示例 3：用户已有草稿，需要修改

用户："帮我检查一下这篇论文"

1. 跳到 **Phase 5**：对照 `common-issues.md` 逐项排查问题
2. 标注问题及修改建议
3. 用户确认后修改并交付
4. 推荐调用 **ruankao-essay-scoring** 技能复查