软考高级架构师论文写不出来，先盘点能解释清楚的项目决策

准备系统架构设计师论文时，写完项目背景就停住了，可以先放下完整范文，回到自己参与过的项目：当时遇到了什么问题，比较过哪些方案，为什么这样选，后来又怎样验证？把这些问题答清楚，通常比继续扩写系统功能更容易找到可用的论述材料。

一条值得整理论文素材的项目决策，应当能讲清约束、选择理由、实施过程和验证结果，也能说明本人承担的工作。

一、为什么记得技术名称，却写不出项目论述？

“项目用了缓存、消息队列和微服务。”这句话交代了技术配置，但读者仍然不知道：哪个业务问题促成了选择？有没有成本更低的做法？方案实施后，原来的问题解决到什么程度？

继续补充组件名称，很容易把正文写成技术清单。更有用的起点是找出一个具体时刻：一次评审改变了原方案，一次故障暴露了设计缺口，或者一次测试让团队放弃了某种实现。

这里的“项目决策”，指的是在业务目标、技术条件和资源限制下，对系统结构或实现方式作出的选择。例如，报表查询是否与交易处理分开，服务是否拆分，某项数据是否允许延迟更新。

软件工程中有一种相近做法，叫架构决策记录，用简短文档记录重要决策的背景、决定、状态和后果，并保留被后续方案替代的记录。它有助于后来者理解当初为什么这样做。

备考时可以借用这种记录思路，再补上本人工作和验证依据。

二、从哪里找出能写清楚的项目决策？

先选一个自己熟悉的项目，写下业务用途、参与阶段和实际职责。项目规模暂时放在一边，重点看自己能否解释其中的技术取舍。

回忆时可以沿着工作中的几类问题往下找：

表格只是帮助回忆，不要求每一类都写。一次数据库访问方式的调整，只要涉及明确的约束和可说明的取舍，也可以成为素材候选；它是否适合某道论文题，还要看题目要求。

材料缺失时，可以先按记忆记录，但要标注“待核对”。某个数字只是印象，就先空着。整理过程中留下空白，后续才知道该查什么。

三、怎样判断一条决策是否值得展开？

先用几分钟口述一次当时的讨论。讲到“为了提升性能”“考虑到业务需要”就停住，往往说明理由还不够具体。

试着把问题继续问下去：哪个接口慢？在什么负载下慢？业务能接受多长时间的延迟？为什么先改这里？当时还有哪种可行方案？

一条素材能否进入正文，可以用下面四个问题自查：

1.能否描述一个具体问题，并说明工期、预算、历史系统或团队能力等限制？

2.能否解释已选方案相对于备选方案的取舍，包括付出的代价？

3.能否说清本人做过什么，以及方案如何落实到接口、数据、部署或测试中？

4.能否提供验证依据，并交代仍未解决的问题？

这些问题没有分值。四项都能回答，就有了展开论述的基础；某一项答不上来，就回到资料里补那一项。

项目当年没有正式比较过多个方案，也可以在备考复盘中补做分析，但应注明“事后复盘”。把今天的分析写成当年的评审过程，会让经历失真。

四、用一张决策卡，把零散记忆整理成素材

每张卡只记录一个主要选择。开始时写短句，等事实清楚后再连成段落。

真实项目资料可以用于核对，但公开表达时应隐去客户名称、账号、内部地址等敏感信息。对企业内部资料，还要遵守所在单位的使用要求。材料可追溯，不等于需要把原始截图贴进文章。

五、如何把决策卡组织成论文段落？

先看具体题目要求，再选素材。把试题中的问题逐条列出，在旁边标注哪张决策卡能支持回答。没有对应材料的部分，需要补充知识或更换素材。

同一张卡可能支持不同角度的讨论。例如，异步通知可以讨论系统间的依赖，也可以讨论故障恢复。但论述可靠性时，应展开失败处理和验证；论述系统结构时，应解释职责划分与交互方式。项目事实保持一致，展开重点随问题改变。

正文可以从问题发生的场景写起，接着解释选择理由，再落到本人工作、实施细节和结果。技术概念放在需要解释的地方。读者看完一段，应能回答“这个项目为什么这样做”。

项目背景只交代支撑后文所需的信息。例如，后文要讨论旧系统改造，就说明旧系统的依赖与迁移限制；要讨论数据访问控制，就交代角色和数据范围。与论点无关的模块介绍可以删去。

这套方法用于准备素材和练习论述。正式作答的题目范围、结构与其他要求，应以当次试题及官方要求为准。

六、几个容易卡住的问题

1.没担任过架构师，能整理决策素材吗？

可以先整理真实参与的部分。例如，参与方案评审、负责接口实现、设计异常测试，都能帮助还原技术选择。写清“我负责验证重复请求的处理结果”，比把团队全部设计归到自己名下更具体。这只是素材整理建议，不构成对任何具体试题适配性的判断。

2.没有性能提升百分比，结果怎么写？

有数据时，注明测试环境、负载、统计口径和时间范围。没有完整的前后对比，可以写已经核实的现象，如某类故障用例是否通过、某项操作是否可恢复，并说明观察范围。一次测试通过，支持的是该测试条件下的结论。

3.一个普通项目，是否值得准备？

先看它能否支撑题目。规模有限的系统也有访问控制、数据管理、发布和维护方面的选择。材料不足时，继续补充真实实践和复盘记录；虚构客户、并发量或主导经历，会使后面的技术解释更难自洽。

想不起当年为什么这样选，怎么办？

查找旧版设计、评审纪要和缺陷记录，必要时向当时的参与者核对。仍然无法确定的理由，保留“原因待核实”；自己现在的判断另写为复盘分析。记忆、记录和事后分析分开，文章才有可靠的事实基础。