本页目录 · 9 节
第 20 章 论文写作要点
科目 3｜120 分钟｜4 选 1｜2000～3000 字｜满分 75，及格 45｜优先级 ★★★★★
读法：这一章不背知识，只背「模板 + 素材」。考前必须完成三件事：默写 1 份摘要、备好 2 个项目、写成 3 篇成稿。下面每一节都能直接在考场上用。
一、先看清评分逻辑
阅卷怎么进行
论文由两位专家独立评阅，分差超过阈值进入三评。单篇平均阅卷时间只有 3～5 分钟，因此阅卷人是这样读你的卷子的：
- 先看字数——不足 2000 字直接降档；
- 再看摘要——30 秒内判断你是否切题、是否真做过项目；
- 扫小标题——判断结构是否完整、是否回答了题目的三个小问；
- 精读实施段——这是唯一给高分的地方，看技术细节与决策理由。
结论：摘要决定你能不能及格，实施段决定你能拿多少分。
四类评分档
| 档位 | 分数 | 典型特征 |
|---|---|---|
| 优良 | 60～75 | 切题、结构完整、有真实项目细节、有量化效果、有反思 |
| 合格 | 45～59 | 切题、结构完整，但细节空泛、效果无数据、通篇像教材 |
| 偏下 | 30～44 | 部分跑题、结构残缺、背景与主题脱节 |
| 不及格 | 45 以下 | 跑题、字数不足、无项目、模板痕迹明显 |
六种必然不及格
- 正文不足 2000 字（机考有字数统计，别赌）。
- 通篇理论，没有一句「我们做了什么」。
- 答非所问：题目问可修改性，你写项目管理。
- 摘要与正文矛盾，或摘要写成目录（「本文首先……其次……最后……」）。
- 项目参数自相矛盾：40 人团队做 3 个月上线 20 个系统。
- 题目给了三个小问，你只答了两个。
三条隐性规则
- 按问给分：论文题通常有 3 个小问，正文必须逐条回应，最好用小标题显式对应。
- 差异化靠细节：80% 的考生写同样的微服务、同样的 Redis，能拉开差距的只有你的项目参数、踩过的坑、量化结果。
- 不追求文采：阅卷人要看的是架构决策能力，不是散文。
二、论文标准结构（背这张表）
| 部分 | 字数 | 写什么 | 评分点 |
|---|---|---|---|
| 摘要 | 280～330 | 背景 + 角色 + 问题 + 方案 + 效果 | 30 秒内判断切题与真实性 |
| 正文一 项目背景 | 400～500 | 行业、规模、时间、角色、技术栈 | 可信度 |
| 正文二 问题与选型 | 400～500 | 三个痛点 + 方案对比 + 选型判据 | 专业深度 |
| 正文三 实施过程 | 800～1000 | 2～3 个措施，每个含做法、细节、难点 | 主体得分区 |
| 正文四 效果与不足 | 300～400 | 三个量化指标 + 两条不足 + 改进 | 真实感与反思 |
| 结尾 | 100～150 | 收获、沉淀、展望 | 收束完整 |
字数分配三原则
- 实施段必须占全文 35%～40%，低于 30% 基本与优良档无缘。
- 背景段不超过 500 字，写多了显得没内容可写。
- 全文控制在 2400～2700 字最稳：够 2000 下限，又不会因超时写不完。
三、摘要模板（可直接套）
完整范文（约 320 字，考场按 300 字控制）
2024 年 3 月，我作为系统架构设计师，参与了某省医疗保障信息平台二期工程的建设。平台覆盖全省 11 个地市、4800 万参保人，日均结算 800 万笔，峰值并发 1.2 万 TPS，团队 40 人，建设周期 14 个月。原有系统采用集中式架构，存在三个问题：单库容量接近上限，高峰期结算响应超过 3 秒；省市数据不一致，日终对账差错率高；政策上线需停机发布，每次约 4 小时。本文以高可用架构设计为核心，论述了我在架构设计阶段的实践。我们采用单元化架构，按地市划分 8 个单元独立部署；通过 Kafka 异步复制与 TCC 加对账保证最终一致；建立同城双活与灰度发布机制。系统上线后，结算平均响应由 3.2 秒降至 800 毫秒，可用性达 99.99%，政策上线停机降为零。实践表明，单元化架构能有效支撑省级事务系统的扩展与容灾；方案在跨单元联合查询上仍有损耗，后续将通过预计算优化。
六句骨架（换项目只换词，不换句式）
| 句序 | 作用 | 句式 |
|---|---|---|
| 1 | 时间与角色 | 20XX 年 X 月，我作为……，参与了……的建设 |
| 2 | 规模参数 | 该系统覆盖……，日均……，团队……人，周期……个月 |
| 3 | 三个问题 | 原有系统存在三个问题：一是……；二是……；三是…… |
| 4 | 主题与方案 | 本文以……为核心，采用……，重点解决了…… |
| 5 | 量化效果 | 上线后，……由……降至……，……达到…… |
| 6 | 反思收尾 | 实践表明……；方案在……仍有不足，后续将…… |
摘要三条硬规则
- 必须出现 3 个以上数字（规模、性能、效果各一个），没有数字的摘要一律被判「空泛」。
- 不写「本文首先……其次……最后……」，那是目录不是摘要。
- 不写「将会」「计划」「预计」，摘要只写已经发生的事实。
填空版（背这一版即可）
20XX 年 X 月，我作为【角色】，参与了【某省/某集团】【系统名称】的建设。
该系统覆盖【范围】、【用户数】，日均【业务量】，峰值【并发/TPS】，
团队【N】人，周期【N】个月。原有系统存在三个问题：一是【问题1+数据】；
二是【问题2+数据】；三是【问题3+数据】。本文以【论文主题】为核心，
采用【架构/方法】，重点解决了【三个子问题】。上线后，【指标1】由【X】
降至【Y】，【指标2】达到【Z】，【指标3】提升【N%】。实践表明，
【结论】；方案在【不足】方面仍有欠缺，后续将通过【改进】优化。四、正文四段模板
段一 项目背景（400～500 字）
目标：让阅卷人相信你真做过。写清五要素——行业、规模、时间、角色、技术栈。
句式骨架：
「【单位】是【性质与职责】的【机构/企业】，【系统】承担【业务职能】。系统覆盖【范围】，服务【用户数】，日均处理【业务量】，峰值【并发】，数据量【TB/PB】。项目于 20XX 年 X 月启动，20XX 年 X 月上线，周期【N】个月，团队【N】人（开发 N、测试 N、运维 N），我担任系统架构设计师，负责【总体架构/技术选型/核心模块设计】。系统采用【技术栈】，部署在【机房/云】环境，【双活/多活】。」
三个可信项目模板（挑两个背下来）
| 要素 | 省级医保平台 | 城商行核心系统 |
|---|---|---|
| 规模 | 4800 万参保人、日均 800 万笔、峰值 1.2 万 TPS | 600 万客户、日均 300 万笔、账务零差错 |
| 团队与周期 | 40 人、14 个月 | 60 人、18 个月 |
| 技术栈 | Spring Cloud、K8s、Oracle、Redis、Kafka | 分布式核心、OceanBase、单元化、Service Mesh |
| 我的角色 | 架构设计师，负责总体架构与关键选型 | 架构师，负责核心账务与数据迁移 |
写作禁忌：不写真实公司名（用「某省」「某大型城商行」）；不写「我公司」；参数必须自洽——人数、周期、系统数量、TPS 要能对上。
段二 问题与选型（400～500 字）
目标：证明你懂业务、会做取舍。结构固定为三个痛点 → 两个备选 → 一个判据。
句式骨架：
「原有系统采用【现状架构】，随着【业务变化】，暴露出三个问题：第一，【问题】，表现为【数据】；第二，【问题】，导致【后果】；第三，【问题】，影响【指标】。针对上述问题，我们对比了【方案 A】与【方案 B】：A 的优点是【…】，但【…】；B 的优点是【…】，但【…】。综合考虑【业务约束/数据量/团队能力/成本】，最终选择【方案】，原因是【两条判据】。」
关键动作：一定要写「为什么不选另一个」。只写「我们选了微服务」是 45 分，写出「单体无法支撑 8 个团队并行发布，而微服务带来的运维复杂度由平台团队承接」才是 60 分以上。
段三 实施过程（800～1000 字，主体）
目标：拿分主战场。写 2～3 个措施，每个措施固定四句话：做什么 → 怎么做 → 遇到什么难点 → 怎么解决。
单个措施的句式骨架：
「措施一：【措施名称】。我们采用【技术/方法】，具体做法是【步骤与参数】，例如【一个具体配置或数字】。实施中遇到【难点】，表现为【现象】。为此我们【解决办法】，最终【结果】。」
措施卡模板（考前把三个故事填进去）
| 措施 | 技术细节（要具体） | 难点与解决 |
|---|---|---|
| 数据库拆分 | 按地市分 8 个单元，每单元 8 库 64 表，热点账户合并记账 | 跨单元转账一致性 → TCC + 日终对账 |
| 高可用 | 同城双活，K8s 多可用区，探针 3 秒、摘除 10 秒 | 脑裂 → 仲裁节点 + 半数投票 |
| 性能优化 | 三级缓存，本地 Caffeine + Redis 集群，命中率 98% | 缓存击穿 → 互斥重建 + 逻辑过期 |
| 灰度发布 | 按参保人 ID 取模分流，1%→10%→50%→100% | 数据兼容 → 双写 + 开关回滚 |
三条写法纪律
- 写决策不写配置：不要罗列 YAML，要写「为什么是 8 个单元而不是 16 个」。
- 每段至少 1 个具体参数：64 库 256 表、超时 800 毫秒、副本 3 个、命中率 98%。
- 措施之间要有逻辑：按架构分层排，或按质量属性排，不要并列堆砌。
段四 效果与不足（300～400 字）
目标：证明结果真实、你有反思能力。三个量化效果 + 两条不足 + 两条改进。
句式骨架：
「系统于 20XX 年 X 月上线，已稳定运行【N】个月，支撑【业务量】。上线后，【指标1】由【X】降至【Y】，【指标2】由【X】提升至【Y】，【指标3】下降【N%】。但方案仍存在两点不足：一是【不足1】，原因是【客观原因】；二是【不足2】。后续计划通过【改进1】与【改进2】逐步解决。」
不足怎么写才安全：写客观受限或有明确代价的不足，不写致命缺陷。推荐三类：跨单元/跨地域的联合查询有性能损耗；灰度发布对长事务支持不足；历史数据迁移期间存在双写复杂度。避免写「系统偶尔宕机」「安全防护不足」。
五、四类论文题的破题方法
| 题型 | 识别关键词 | 必写内容 | 最大失分点 |
|---|---|---|---|
| 架构风格类 | 论分层架构、微服务、事件驱动、管道-过滤器 | 风格三要素（构件/连接件/约束）、与备选风格对比、落地措施 | 只讲风格概念，不讲项目 |
| 质量属性类 | 论高可用、高性能、安全性、可修改性设计 | 六要素场景、具体战术、度量验证结果 | 战术罗列，没有场景与数据 |
| 新技术类 | 论云原生、大数据、Serverless、AI 应用 | 技术原理一句话、选型理由、迁移路径、踩坑 | 写成产品说明书 |
| 系统设计类 | 论某系统的架构设计、需求分析、数据库设计 | 业务建模、关键取舍、详细设计、上线效果 | 写成需求文档或功能清单 |
四类写法的差异
- 架构风格类：重心在「为什么是这个风格」。先给 2 个备选风格各一句优缺点，再用项目约束（团队规模、发布频率、性能要求）做判据。实施段写「怎么划分构件、怎么定义连接件、加了什么约束」。
- 质量属性类：重心在「场景 + 战术 + 度量」。开篇就写一个六要素齐全的场景（刺激源、刺激、环境、制品、响应、响应度量），然后逐条讲战术，最后用数据证明达标。
- 新技术类：重心在「选型与落地」。技术原理只写一句，把篇幅留给「我们为什么引入、分几步迁移、遇到什么问题、怎么回退」。切忌大段介绍产品功能。
- 系统设计类：重心在「取舍」。业务建模简明，重点写关键设计决策与备选方案对比，实施段给详细设计（表结构、接口、部署），最后落到效果。
通用破题三步：圈出题目的 3 个小问 → 把 3 个小问变成正文的 3 个小标题 → 每个小标题下先给结论再给论据。
六、素材库怎么搭（这是决定成败的一步）
最小配置：2 个项目 × 3 个故事 = 6 张卡，足以覆盖 80% 的题目。一个主项目（写得最熟，考场默认用），一个备用项目（题目偏金融/制造时切换）。
第一步：写两张项目卡
| 字段 | 主项目：省级医保平台 | 备用项目：城商行核心 |
|---|---|---|
| 行业与规模 | 政务民生，4800 万人，日均 800 万笔 | 金融，600 万客户，日均 300 万笔 |
| 我的角色 | 架构设计师，总体架构与选型 | 架构师，核心账务与迁移 |
| 技术栈 | Spring Cloud、K8s、Oracle、Kafka | 分布式核心、OceanBase、单元化 |
| 三个故事 | 高可用、性能、数据一致性 | 微服务拆分、安全、容灾 |
| 量化指标 | 99.99%、800 毫秒、停机为零 | 99.995%、T+0 清算、差错率为零 |
第二步：写六张故事卡（每张 150 字，含技术细节与数字）
| 故事 | 问题与方案 | 效果 |
|---|---|---|
| 高可用 | 单机房故障导致全省停机 → 同城双活 + 单元化 + 探针摘除 | 可用性 99.99%，切换 30 秒 |
| 性能 | 高峰结算 3.2 秒 → 三级缓存 + 分库分表 + 异步化 | 响应 800 毫秒，TPS 提升 4 倍 |
| 一致性 | 省市数据不一致 → Kafka 异步复制 + TCC + 日终对账 | 对账差错率降至 0.001% |
| 微服务拆分 | 单体 8 个团队排队发布 → 按领域拆 12 个服务 | 发布频率由月到周 |
| 安全 | 越权访问与数据泄露风险 → 统一认证 + 字段级加密 + 审计 | 拦截率 100%，通过等保三级 |
| 容灾 | 数据只在本城 → 异地异步复制 + 定期演练 | RPO 小于 1 分钟，RTO 30 分钟 |
第三步：建复用一个矩阵
| 题目主题 | 用哪个故事 | 一句话切入 |
|---|---|---|
| 高可用 / 容灾 | 高可用 + 容灾 | 「单机房故障会造成全省结算中断，因此必须做单元化与双活」 |
| 高性能 | 性能 | 「瓶颈在数据库连接与热点账户，不在应用层」 |
| 微服务 / SOA | 微服务拆分 | 「拆分不是目的，解决 8 个团队的发布阻塞才是」 |
| 大数据 / Lambda | 性能 + 一致性 | 「离线报表与实时大屏口径不一致，是我们引入批流架构的直接原因」 |
| 安全架构 | 安全 | 「医保数据涉及个人隐私，等保三级是硬约束」 |
三条搭建纪律
- 参数自洽：人数 × 周期 × 系统数 × TPS 要能对上，考官会算。
- 只用自己讲得清的技术：不确定的技术点一律不写，写错一个术语比少写一个得分点更致命。
- 一材多用：同一套素材至少写 3 篇不同主题的成稿，练的是「换题不换料」的迁移能力。
七、常见扣分点清单
| 扣分点 | 典型表现 | 怎么避 |
|---|---|---|
| 字数不足 | 正文 1800 字，草草结尾 | 考前默写，给每段设字数下限 |
| 跑题 | 题目问可修改性，通篇写高性能 | 开题圈出 3 个小问，每段回扣一次 |
| 无项目 | 「微服务具有以下优点……」 | 每段至少一句「我们/我」的动作 |
| 摘要空洞 | 「本文论述了系统架构设计」 | 摘要必含规模数字与效果数字 |
| 结构失衡 | 背景写 1200 字，实施写 300 字 | 按字数表分配，实施段占 35% 以上 |
| 技术错误 | 「Kafka 保证全局消息有序」 | 只写确定的技术点，不确定就换说法 |
| 效果无量化 | 「性能大幅提升」 | 每个效果带数字与对比基准 |
| 不足写成优点 | 「本系统没有任何不足」 | 固定写两条客观不足 |
| 术语堆砌 | 一段出现 20 个名词 | 每个术语后跟一句「我们怎么用」 |
| 不分段 | 机考一大段两千字 | 每 200～300 字一个小标题 |
八、120 分钟时间分配
| 分钟 | 动作 | 产出 |
|---|---|---|
| 0～8 | 读 4 道题，选最有素材的一道，圈出 3 个小问 | 选题结论 |
| 8～15 | 列提纲：摘要关键词、4 段标题、每段 3 个要点 | 一页提纲 |
| 15～30 | 写摘要，一次定稿，之后不再改 | 300 字摘要 |
| 30～55 | 写项目背景 + 问题与选型 | 900 字 |
| 55～95 | 写实施过程（2～3 个措施） | 1000 字 |
| 95～110 | 写效果与不足 + 结尾 | 450 字 |
| 110～118 | 通读检查（见下方清单） | 修改稿 |
| 118～120 | 提交 | — |
速度账：2500 字 ÷ 90 分钟 ≈ 28 字/分钟。考前测一次打字速度，低于 25 字/分钟必须先练打字，否则模板再好也写不完。
交卷前 8 项检查
- 字数是否达到 2000 以上（看系统统计）。
- 三个小问是否都有对应小标题。
- 摘要里的数字与正文是否一致。
- 实施段是否占 35% 以上。
- 每段是否有「我们做了什么」，而不是纯理论。
- 是否有三个量化效果、两条不足。
- 项目参数是否自洽（人数、周期、TPS、数据量）。
- 是否有明显错别字与技术术语错误。
九、考前自测
- 默写摘要：不看资料，15 分钟内写出 300 字摘要，必须含 3 个数字。写完对照第三节骨架逐句检查。
- 限时写段：用主项目素材，分别针对「高可用」「微服务」「大数据」三个题目，各写一段 450 字的「问题与选型」。
- 参数自查：把你的项目卡读给一个不懂技术的朋友听，问他「这个项目可信吗」，找出所有对不上的数字。
- 故事盘点：合上书，能否说出 6 个「问题-方案-效果」故事？每个故事是否有 1 个技术细节和 1 个数字？说不出的回去补卡。
- 打字测试：计时 10 分钟，看能打多少字。低于 250 字，考前每天练 20 分钟。
- 成稿检验：考前至少完成 3 篇完整成稿，找一位同行按第七节清单逐条打分。
一句话总结：论文不是考写作，是考你有没有真做过、能不能把决策讲清楚。模板解决结构，素材解决分数，量化解决可信度。