系统架构设计师到底难在哪：把三科拆成可自测的能力

系统架构设计师的难，集中在三种能力之间的转换：综合知识要辨清概念，案例分析要结合条件作判断，论文要把设计过程和取舍写清楚。刷题时能选对，换成一道开放问题却写不出来，这正是值得检查的地方。

一、综合知识：你能解释为什么选它吗？

这一科的难点是知识面广，概念之间又容易混淆。工作中熟悉某种开发框架，未必能顺手答出数据库、操作系统或架构评估的问题。看解析时觉得懂了，也可能只是记住了答案。

1.拿一组有可靠解析、自己尚未做过的练习题，闭卷完成。对每道题再追问一句：题干中的哪个条件，让我排除了其他选项？讲不清的题，即使选对，也单独标出来。

2.用“系统出故障后还能否继续服务”和“某项功能执行得有多快”做一次概念区分练习，再回教材核对可用性与性能的含义。随后换个业务场景，看自己是否仍能分清。

3.自测时分别记录“答对”和“能解释”，不要只看正确率。前者高、后者低，下一步就补概念对照和错项分析；两项都低，则回到对应章节重新学习。

二、案例分析：你能把条件写进答案吗？

案例分析需要从材料里找依据，再组织答案。只写“采用微服务，提高扩展性”，读者仍然不知道这个方案为什么适合题目中的系统。

1.试做一个假设场景：某订单系统促销时请求激增，库存数据要求准确，运维人员又少。给自己20分钟，写出需要优先解决的问题、一个备选方案，以及采用它的代价。

2.这道练习不预设唯一架构。检查答案时，看每个建议能否对应材料中的条件，是否回应了库存准确性要求，是否考虑团队维护能力。遇到信息不足的地方，写明还需要了解什么。

3.如果方案换到任何系统里都能照抄，答案就还缺少场景依据。补练时可把“材料条件—设计措施—理由与代价”写在同一行，再请同伴追问：这项措施具体解决了哪个问题？

三、论文：你能把一次设计决定讲完整吗？

论文容易写成技术名词介绍：背景占了很长篇幅，到了为什么选、怎么实施、效果如何，反而只剩几句话。这里要练的是围绕题目要求展开论述。

1.选一个自己参与过、能够核实细节的项目，围绕某个架构主题写一页提纲：业务目标是什么，自己负责什么，遇到了哪些约束，比较过什么方案，最终如何实施和验证。

2.接着只展开一个设计决定。写清采用它的原因、放弃另一方案的理由，以及实施后仍存在的问题。效果数据要有依据；没有测量记录，就如实说明观察结果和验证局限。

3.检查时把提纲逐项对应到题目要求，再看正文能否支撑提纲。有项目经历但写不清，可以先口述再整理；缺少素材，可以用公开案例或实验项目练分析，并注明性质，避免写成自己的真实履历。整篇练习还应加入计时和键盘输入训练。

测完以后，先补哪一科？

把结果记成三个具体问题：哪些概念解释不清，哪些建议缺少题干依据，哪些论文段落缺少设计细节。优先补反复出现的问题，每周换一组材料复测，避免把记住旧答案当成进步。

同一个知识点也可以连续练：先解释含义，再放进案例作判断，最后写成论文中的一段理由。这样更容易发现自己卡在理解、应用还是表达，也能据此安排下一周的复习。