Day40-04｜20.4 常见问题及解决办法：论文从能写到得分

对应教材：第20章《系统架构设计师论文写作要点》20.4 常见问题及解决办法

一、问题一：没有项目，只会背概念

解决办法是先建立一个综合项目，不必追求真实规模惊人，但必须有业务、约束、角色、方案、结果和反思。项目可以来自工作、课程或综合案例，关键是保持事实一致。遇到不同题目时，调整架构决策，不要硬把所有知识塞进同一篇文章。

二、问题二：项目很长，题目很窄

很多考生把项目说明书复制到论文中，背景和功能介绍占去大半篇幅。解决办法是先写“题目相关性声明”：本文重点讨论什么，其他内容只作背景。例如题目是数据库高可用，业务流程只需说明数据重要性，不必逐个介绍页面功能。

三、问题三：只有技术名称，没有设计理由

技术名词必须回答三个问题：它解决了什么问题，为什么在此处选择它，使用后带来什么代价。把“使用缓存”改成“由于热点读请求占比高、主库连接逼近上限，因此采用多级缓存；通过版本失效和短TTL控制一致性风险，代价是缓存治理复杂度增加”。

四、问题四：把架构风格和架构模式混为一谈

架构风格是系统组织方式，如分层、事件驱动、管道过滤器、客户机/服务器；架构模式是解决特定问题的可复用方案，如MVC、微服务、发布订阅、服务注册表。技术实现又是具体平台和组件。论文中最好分层表达：总体采用什么风格，关键问题使用什么模式，如何通过技术实现。

五、问题五：只写设计，不写实施

高级考试重视实践。实施内容可以包括需求澄清、质量属性场景、架构评审、原型验证、接口契约、数据迁移、自动化测试、灰度发布、监控告警、故障演练和组织协作。写“我组织评审并根据风险清单调整方案”，比写“经过多次讨论后上线”更具体。

六、问题六：只写成功，不写权衡

任何架构都有代价。微服务提升独立交付能力，却增加分布式事务和运维复杂度；缓存降低数据库压力，却引入一致性问题；多活提高可用性，却增加数据冲突和成本；安全控制提高防护能力，却可能影响性能和用户体验。写出权衡并给出控制措施，是架构师的重要能力。

七、问题七：指标虚假或互相矛盾

指标应与系统规模、方案和结果相匹配。不要随意写“千万并发”和“零故障”。可以使用相对保守、可解释的指标，如P99、故障恢复时间、发布时长、错误率、数据库QPS、队列积压、备份恢复窗口。写指标时说明场景和测量方式，避免把容量上限当成真实业务流量。

八、问题八：不会处理题目变化

准备“可迁移素材”，而不是固定范文。一个订单平台可以分别写微服务、性能、高可用、云原生、数据一致性和安全，但每次都要改变主线：题目要求什么，就把对应质量属性放在架构中心，其余内容作为支撑。

九、问题九：论文结构失控

常见表现是开头写得很慢，中间大量补充技术，后面没有结论。解决办法是考场先列时间预算和段落提纲，给每段设边界；至少预留时间完成结果和总结。发现某个知识点不会，不要停笔查找，而应使用熟悉的概念和工程语言继续推进。

十、问题十：图表画得漂亮但没有作用

图只画与题目相关的结构。高可用图需要标故障域和备用路径，安全图需要标信任边界和控制点，数据架构图需要标数据流、批流处理和存储层。图之后必须有一句“该图体现了什么”，否则图只是装饰。

十一、问题十一：参考答案照抄，缺乏个人判断

教材和课程只能提供概念、方法和案例，论文必须完成二次加工。将“服务注册表模式”转化为项目中的实例健康、版本路由、失效剔除和治理责任；将“ATAM”转化为质量属性场景、敏感点、权衡点和风险记录。这样才能体现理解。

十二、考场最终检查

题目是否贯穿全文？
摘要与正文是否一致？
本人职责是否具体？
架构是否有边界和数据流？
关键方案是否说明原因、机制、验证和代价？
是否有结果指标和反思？
是否写完并回扣题目？

十三、综合案例

某制造企业建设工业互联网平台，要求采集设备数据、处理告警、提供报表并支持远程运维。旧系统存在协议不统一、设备断网数据丢失、告警延迟和权限粗放问题。针对该案例，可以采用边缘网关和消息队列完成采集解耦，使用时间序列存储承接指标数据，实时流处理识别告警，数据湖保留历史数据，统一身份和细粒度授权保护远程操作，并通过断点续传、离线缓存、重试和审计提高可靠性与安全性。

若题目是大数据，重点写采集、实时/离线、Lambda/Kappa和数据质量；若题目是安全，重点写设备身份、网络分区、访问控制、密钥和审计；若题目是云原生，重点写容器平台、弹性、交付和观测。同一案例可以迁移，但论证中心不能不变。

十四、今日练习

列出你最容易犯的三个论文问题及改进动作。
以“论架构评估”为题，写出四个必须出现的理论点和四个实践点。
用100字说明为什么架构论文必须写代价。

参考：架构评估理论点可包括质量属性、场景、利益相关者、敏感点、权衡点、风险；实践点可包括评估准备、工作坊、方案比较、问题记录、改进验证。写代价是因为架构决策本质是权衡，不可能只有收益。

十六、建立个人错误档案

每次练习后把错误写成“表现—原因—改法—验证题”四栏。例如表现是“写了微服务但没有一致性”，原因是只记住拆分而忽略跨服务事务；改法是补充幂等、事件、补偿和对账；验证题是“支付成功而订单服务超时如何处理”。错误档案比重复阅读范文更能提高得分，因为它直接针对个人薄弱环节。

十七、面对陌生题目的应急方法

陌生题目先抽象成业务、约束、质量属性和架构决策。即使不熟悉题目中的新技术，也可以写边界、数据流、接口、故障、权限、监控、测试和演进。不要为了显得专业编造产品特性，使用职责和机制表达更安全。例如不知道某平台的具体命令，也可以说明其负责调度、扩缩容、健康检查和发布。

十八、最终自评题

请分别回答：为什么架构论文必须有项目背景？为什么必须写本人职责？为什么必须写结果指标？为什么必须写代价？参考答案是：背景提供约束，职责证明个人参与，指标验证方案，代价体现权衡和高级架构判断。四者缺一，文章容易退化为教材摘要或技术宣传稿。

十九、Day40收束

论文写作的所有技巧最终都指向一个目标：把架构知识转化成可信、切题、可验证的实践叙事。后续综合训练应反复执行“审题—建模—决策—验证—反思”，直到能够在限定时间内稳定输出。

二十、最后的检查动作

交卷前先看题目关键词，再看摘要和每段第一句；随后检查是否出现本人职责、项目指标、关键方案、实施过程、结果和不足。最后检查术语、数字、段落和结尾，不要在已经完整的段落上反复润色而忽略未完成部分。

十五、Day40总结

论文不是文学创作，而是受题目约束的工程论证。解决常见问题的总方法是：用项目承载理论，用因果链解释方案，用指标验证结果，用权衡体现判断，用摘要和正文保持一致。到这里，第20章的基础写作方法已经完成，接下来进入专项模拟与综合冲刺阶段。

如果发现某个段落与题目关系很弱，优先删除背景和产品介绍，把篇幅留给架构决策、实施验证和结果反思；论文的高级性来自判断和证据，而不是字数堆砌。