文章目录
20.1 写作注意事项
系统架构设计师的论文题目对于考生来说，是相对较难的题目。一方面，考生需要掌握论文题目中的系统架构设计的专业知识;另一方面，论文的撰写需要结合考生自身的项目经历。 因此，如何将自己的项目经历和专业知识有机地结合，将专业知识和工程实践相结合，做好论文的撰写工作，是一项需要前期积累和提前做好准备的工作。
20.1.1 做好准备工作
论文试题是系统架构设计师考试的重要组成部分，论文试题既不是考知识点，也不是考一般的分析和解决问题的能力，而是考查考生在系统架构设计方面的经验和综合能力，以及表达能力。根据考试大纲，论文试题的目的如下:
- (1)
检查考生是否具有参加系统架构设计工作的实践经验。原则上，完全不具备实践经验的人是很难胜任系统架构设计师的工作的，更何谈取得系统架构师的资格认定。 - (2)
检查考生分析问题与解决问题的能力，特别是考生的独立工作能力。在实际工作中， 由于情况千变万化，作为系统架构设计师，应能把握系统的关键因素，发现和分析问题，根据 系统的实际情况提出架构设计方案。 - (3)
检查考生的表达能力。由于文档是信息系统的重要组成部分，并且在信息系统开发过程中还要编写不少工作文档和报告，文档的编写能力很重要。系统架构设计师作为项目组的技术骨干，要善于表达自己的思想。在这方面要注意抓住要点，重点突出，用词准确，使论文内容易读，易理解。
1.加强学习
根据自身经验的多少，可以采取不同的学习方法。
- (1)
经验丰富的应考人员。主要是将自己的经验进行整理，从技术、管理、经济方面等多个角度对自己做过的项目进行归纳、剖析、抽象和升华，在总结的基础上，结合专业知识和关键技术进行分类和梳理。 - (2)
经验欠缺的在职开发人员。可以通过阅读、学习、整理单位现有的文档、案例，同时参考历届考题进行学习。培养自己站在系统架构设计师角度考虑问题，同时可以采取临摹的方式提高自己的写作能力和思考能力。这类人员学习的重心应放在自己欠缺的方面，力求全面把握。 - (3)
学生。学生的特点是有充足的时间用于学习，但缺点是实践经验相对较少，对于这类考生来说，考试的难度比较大。从撰写的论文分析，学生在系统架构师的考试中，论文的内容容易空洞而不切实际。因此，作为学生考生，要想更好地完成论文题目，就需要大量地阅读相关文章和论文范文，学习别人的经验，站在更多人的肩膀上，并进行强化练习。
2.平时积累
与其他考试不同，软考中的高级资格考试靠考前突击是行不通的。实践经验丰富的考生还应该对以前做过的项目进行一次盘点，对每个项目中采用的方法与技术、架构设计手段等进行总结。这样，临场才可以将不同项目中和论题相关的经验和教训糅合在一个项目中表述出来，笔下可写的东西就 多了。
还有，自己做过的项目毕竟是很有限的，要大量参考其他项目的经验或多和同行交流。也可多读网站、博客上介绍架构设计方面的文章，从多个角度去审视这些系统的架构，从中汲取经验，也很有好处。要多和同行交流，互通有无，一方面对自己做过的项目进行回顾; 另一方面，也学学别人的长处，往往能收到事半功倍的效果。
总之，经验越多，可写的素材就越丰富，胜算越大。平时归纳总结了，临场搬到试卷上就驾轻就熟了。
3.提高写作速度
在两个小时内，完成一篇精彩的论文是很困难的。建议选定一个论文项目，按照考试要求的时间(2个小时)进行实际练习。这种练习每周至少进行1次，如果时间允许，最好进行2次。写的次数多了，写作速度慢慢地就提高了。
4.以不变应万变
论文试题的考核内容都是 系统架构设计中的共性问题，即通用性问题，与具体的应用领域无关的问题。把握了这个规律，就有以不变应万变的办法。所谓不变，就是考生所参与开发的软件项目不变。考生应该在考前总结一下最近所参与的最有代表性的项目。不管论文的题目为何，项目的概要情况和考生所承担的角色是不会改变的，如果觉得有好几个项目可以选，那么就应该检查所选项目的规模是否能证明自己的实力或项目是否已年代久远(一般需要在近3年内做的项目)。要应付万变，就要靠平时的全面总结和积累。
20.1.2 论文写作格式
在系统架构设计师的资格考试中，论文考试的时间为下午(120分钟),且备选的论文题目通常包含4道题目，考生可以根据自己所从事的工作内容，选择比较接近的题目进行论文写作。如果没有和自己相关的内容，可以选自己比较熟悉的技术的相关题目进行论文写作，即考生可以完全根据自己的特长选做1题。
20.2 如何解答试题
如果做好了充分的论文准备，平常按照既有格式进行了练习，则临场就可以从容自如。如果试题与准备的内容出入很大的话，那也不要紧张，选定自己把握最大的论题，按平时的速度写下去。
20.2.1 论文解答步骤
本节给出论文解答的步骤。这里给出的只是一个通用的框架，考生可根据当时题目的情况和自己的实际进行解答，不必拘泥于本框架的约束。
1.时间分配
试题选择 3分钟
论文构思 12分钟
摘要 15分钟
正文 80分钟
检查修改 10分钟
2.选择题目
(1)选择自己最熟悉，把握最大的题目。
3.论文构思
(1)构思论点(主张)和下过功夫的地方。
(2)将构思的项目内容与论点相结合。
(3)决定写入摘要的内容。
(4)划分章节，把内容写成简单草稿(几字带过，无须繁枝细节)。
(5)大体字数分配。
4.写摘要
以用语简洁、明快，阐清自己的论点为上策。
5.正文撰写
(1)按草稿进行构思、追忆项目素材(包括收集的素材)进行编写。
(2)控制好内容篇幅。
(3)与构思有出入的地方，注意不要前后矛盾。
6.检查纠正
主要是有无遗漏、有无错字。注意点:
(1)力求写完论文(对速度慢者而言),切忌有头无尾。
(2)格式整齐。
20.2.2 论文解答实例
下面给出两个系统架构师考试中的实际论文题目以及面向该题目的如何进行写作的要点陈述，以帮助考生对论文考试有一个更直观的认识。
1.实例一
1)论文题目: 论软件系统建模方法及其应用
软件系统建模 (Software System Modeling) 是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性，也可以方便各类人员之间的交流。软件系统建模是在系统需求分析和系统实现之间架起的一座桥梁，系统开发人员按照软件系统模型开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。
请围绕"论软件系统建模方法及其应用"论题，依次从以下三个方面进行论述。
1.概要叙述你参与的软件系统开发项目以及你所担任的主要工作。
2.说明软件系统开发中常用的建模方法有哪几类? 阐述每种方法的特点及其适用范围。
3.详细说明你所参与的软件系统开发项目中，采用了哪些软件系统建模方法，具体实施效果如何。
2)实例一分析
问题1要点: 该方面需要简要描述所参与分析和开发的软件系统开发项目，并明确考生指出在其中承担 的主要任务和开展的主要工作。需注意所描述的项目应与论文题目中包含的主要论题相符。
问题2要点: 该方面是对论文论题中涉及的专业知识的理解和掌握程度的考核，考生可以通过详细描述， 说明自己所了解的软件系统开发中的常用建模方法，并阐述出每种方法的特点及其适用范围。 例如，考生可以描述的软件系统开发中常用的建模方法包括:
- (1)功能分解法。 功能分解法以系统需要提供的功能为中心来组织系统。首先定义各种大的功能，然后把功
能分解为子功能，同时定义功能间的接口。比较大的子功能还可以被进一步分解，直到我们可 以对它进行明确的定义。总的思想就是将系统根据功能分而治之，然后根据功能的需求设计数 据结构。 - (2)数据流法/结构化分析建模方法。 基本方法是跟踪系统的数据流，研究问题域中数据如何流动以及在各个环节上进行何种处
理，从而发现数据流和加工。然后将问题域映射为数据流、加工以及数据存储等元素并组成数 据流图，用加工和数据字典对数据流及其处理过程进行描述。 - (3)信息工程建模法。
在实体关系图基础上发展而来，其核心是识别实体及其关系。实体用于描述问题域中的一 个事物，它包含一组描述事物数据信息的属性;关系描述问题域中的各个事物之间在数据方面 的联系，它可以带有自己的属性。发展之后的方法把实体叫作对象，把关系的属性组织到关系 对象中，具有面向对象的某些特征。 - (4)面向对象建模法。 从面向对象设计领域发展而来，它通过对象对问题域进行完整的映射，对象包括了事物的数据属性和行为特征;它用结构和连接如实反映问题域中事物之间的关系，比如分类、组装等; 它通过封装、继承和消息机制等使问题域的复杂性得到控制。
问题3要点: 该方面是针对考生实际参与的软件系统开发项目，说明该项目所采用的系统建模方法，并 描述这些建模方法所产生的实际应用效果。
2.实例二
1)论文题目 论软件架构风格
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接 件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
请围绕"论软件架构风格"论题，依次从以下三个方面进行论述。
1.概要叙述你参与分析和设计的软件系统开发项目以及你所担任的主要工作。
2.软件系统开发中常用的软件架构风格有哪些?详细阐述每种风格的具体含义。
3.详细说明你所参与分析和设计的软件系统是采用什么软件架构风格的，并分析采用该架构风格设计的原因。
2)实例二分析
问题1要点: 该方面是要求考生要简要叙述自己所参与分析和开发的软件系统，并明确指出在其中承担 的主要任务和开展的主要工作。需注意所描述的项目应与论文题目中包含的主要论题相符。
问题2要点该方面是对论文论题中涉及的专业知识的理解和掌握程度的考核，考生可以通过详细描述， 说明自己所了解的软件系统开发中常用的软件构架风格，包括:
- (1)管道/过滤器:在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输 出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
- (2)数据抽象和面向对象:这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和他们的相应操作封装在一个抽象数据类型或对象中。
- (3)基于事件的隐式调用:基于事件的隐式调用风格的思想是构件不直接调用一个过程， 而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一 个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一个模块中的过程的调用。基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。
- (4)分层系统:层次系统组成一个层次结构，每一层为上层服务，并作为下层客户。
- (5)仓库系统及知识库:在仓库风格中，有两种不同的构件:中央数据结构说明当前状态，独立构件在中央数据存储上执行。若构件控制共享数据，则仓库是一传统型数据库。若中央数据结构是当前状态触发进程执行的选择，则仓库是一黑板系统。黑板系统主要由以下三部分组成:
- 知识源。知识源中包含独立的、与应用程序相关的知识， 知识源之间不直接进行通信，它们之间的交互只通过黑板来完成;
- 黑板数据结构:黑板数据是 按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题;
- 控制:控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
- (6)C2风格:C 2体系结构风格可以概括为，通过连接件绑定在一起按照一组规则运作的并 行构件网络。 C2风格中的系统组织规则如下:系统中的构件和连接件都有一个顶部和一个底部; 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件 之间的直接连接是不允许的;一个连接件可以和任意数目的其他构件和连接件连接;当两个连 接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
- (7)客户/服务器风格: C/S 体系结构有三个主要组成部分:数据库服务器、客户应用程序和网络。
- (8)三层C/S结构风格: 二层C/S结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet, 软、硬件的组合及集成能力有限，客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏，数据安全性不好。三层 C/S 体系结构是将应用功能分成表示层、功能层和数据层三个部分，削弱二层 C / S 结构的局限性。
- (9)浏览器/服务器风格:浏览器/服务器风格就是三层 C/S 结构的一种实现方式，具体结构为浏览器/W e b 服务器/数据库服务器。
问题3要点该方面是针对考生自身具体参与分析和开发的实际软件系统，说明在该系统的设计和实现 中，采用的具体一种或多种软件架构风格，并分析出采用这种软件架构风格设计的原因。
20.3 论文写作方法
两个小时内写将近3000字的文章不是一件容易的事情。根据以往的经验，学生在写作过程中，必须首先逻辑清晰，并且撰写还要保持一定的撰写速度，才可以在有限的时间范围内，较好地完成论文写作工作。下面针对如何撰写好摘要和论文的正文部分分别进行说明。
20.3.1 如何写好摘要
摘要应控制在300 ~ 400字的范围内，凡是没有写论文摘要，摘要过于简略，或者摘要中 没有实质性内容的论文将扣5~10分。如果论文写得辛辛苦苦，而摘要被扣分，就太不划算 了。而且，如果摘要的字数少于120字，论文将"给予不及格"。
下面是摘要的几种写法，供考生参考。
(1)本文讨论⋯⋯系统项目的⋯⋯(论文主题)。该系统⋯⋯(项目背景、简单功能介绍)。在本文中首先讨论了⋯⋯(技术、方法、工具、措施、手段),最后⋯⋯(不足之处/如何改进、 特色之处、发展趋势)。在本项目的开发过程中，我担任了⋯⋯(作者的工作角色)。
(2)根据⋯⋯需求(项目背景),我所在的⋯⋯组织了⋯⋯项目的开发。该项目⋯⋯(项 目背景、简单功能介绍)。在该项目中，我担任了⋯⋯(作者的工作角色)。我通过采取⋯⋯ (技术、方法、工具、措施、手段),使该项目圆满完成，得到了用户们的一致好评。但现在看 来，⋯⋯(不足之处/如何改进、特色之处、发展趋势)。
(3)⋯⋯年⋯⋯月，我参加了⋯⋯项目的开发，担任⋯⋯(作者的工作角色)。该项目⋯⋯ (项目背景、简单功能介绍)。本文结合作者的实践，以⋯⋯项目为例，讨论⋯⋯(论文主题),包括⋯⋯(技术、方法、工具、措施、手段)。
(4)⋯⋯是⋯⋯ ("戴帽子",讲论文主题的重要性)。本文结合作者的实践，以⋯⋯项目为例，讨论⋯⋯(论文主题),包括⋯⋯(技术、方法、工具、措施、手段)。在本项目的开发 过程中，我担任了⋯⋯(作者的工作角色)。
摘要应该概括地反映正文的全貌，要引人入胜，要给人一个好的初步印象。一般来说，不要在摘要中"戴帽子"如果觉得字数可能不够，例如少于300字，则可适当加50字左右的帽子。
上述的"技术、方法、工具、措施、手段"就是指论文正文中论述的技术、方法、工具、 措施、手段，可把每个方法(技术、工具、措施、手段)的要点用一两句话进行概括，写在摘要中。 在写摘要时，千万不要只谈大道理，而不牵涉到具体内容。否则，就变成了"摘要中没有实质性内容"。
20.3.2 如何写好正文
关于正文部分的写作，首先应做到字数合宜。正文的字数要求在2000~3000字，少于 2000字，则显得没有内容;多于3000字，则答题纸上无法写完。作者建议，论文正文的最佳 字数为2500字左右。其次，考生可以从写作技巧和可能涉及的关键技术层面做好应考准备。
1.写作技巧
1)以自我为中心
由于论文考核的是以考生作为系统架构设计师的角度对系统的认知能力。因此在写法上要使阅卷专家信服，只是把自己做过的事情罗列出来是不够的。考生必须清楚地说明针对具体项目自己所做的事情的由来，遇到的问题，解决方法和实施效果。因此，不要炫耀自己所参加的工程项目，体现实力的是考生做了些什么。下面几个建议可供读者参考。
- (1)体现实际经验，不要罗列课本上的内容。
- (2)条理性地说明实际经验。
- (3)写明项目开发体制和规模。
- (4)明确"我"的工作任务和所起的作用。
- (5)以"我"在项目中的贡献为重点说明。
- (6)以"我"的努力(怎样做出贡献的)为中心说明。
2)站在架构师的角度
很多考生由于平时一直是在跟程序打交道，甚至根本就没有从事过架构设计工作。因此，在思考问题上，往往单纯地从程序实现方面考虑。事实上，论文考核的是以考生作为架构师的角度对系统的认知能力，要求全面，详尽地考虑问题。因此，这类考生在论文上的落败也就在所难免。
例如，如果要写有关层次式架构设计的论文，考生就要从全局的角度把握层次式架构设计的优点及缺点、设计层次式架构的方法和过程，特别是各层次之间的接口设计问题，而不是专注于某个具体的实现细节。
3)忠实于论点
忠实于论点首先是建立在正确理解题意的基础上，因此要仔细阅读论文试题要求。为了完全符合题意，要很好地理解关于试题背景的说明。然后根据正确的题意提取论点加以阐述。阐述时要绝对服从论点，回答试题的问题，就试题的问题进行展开，不要节外生枝，化自身为困境。也不要偏离论点，半天讲不到点子上去，结果草草收场。根据作者参加阅卷和辅导的情况来看，这往往是大多数考生最容易出错的地方。
4)条理清晰，开门见山
作为一篇文章，单有内容，组织不好也会影响得分，论文的组织一定要条理清晰。题目选定后，要迅速整理一下自己所掌握的素材，列出提纲，即打算谈几个方面，每个方面是怎么做的，收效如何，简明扼要地写在草稿纸上。切忌一点，千万不要试图覆盖论文题目的全部内涵而不懂装懂，以专家的姿态高谈阔论，而要将侧重点放在汇报考生自己在项目中所做的与论题相关的工作上，所以提纲不要求全面，关键要列出自己所做过的工作。
接下来的事情就是一段一段往下写了。要让专家短时间内了解考生的论文内容并认可考生 的能力，必须把握好主次关系。
一般来说，第一部分的项目概述对评卷专家掌握整个论文非常重要。考生要学会用精练的语句说明项目的背景、意义、规模、开发过程以及自己的角色等，让评卷专家对自己所做的项目产生兴趣。
5)标新立异，要有主见
设想一下，如果评卷专家看了考生的论文有一种深受启发，耳目一新的感觉，结果会怎么样?考生想不通过都难。所以，论文中虽然不要刻意追求新奇，但也不要拘泥于教科书或常规的思维，一定要动脑筋写一些个人的见识和体会。这方面，见仁见智，在此不予赘述。
6)图文并茂，能收奇效
系统架构设计总是离不开图形，论文的紧要地方，如果能画个草图表示，往往能收到奇效。 因为图形比文字更能吸引人的注意力，更加简洁、明了。通过图形方式表达，更能让评卷专家直观地了解考生所设计的架构，从而得到专家的认可。但是，图形不要画得太"草",也不宜过大。图中的线条、箭头等要保持整洁。
7)首尾一致
在正文的写作中，要做到开头与结尾间互相呼应，言词的意思忌途中变卦。因为言词若与论文试题的提法不一致，导致论文内部不一致，阅卷专家就会怀疑考生是否如所说的那样，甚至认为考生有造假嫌疑，从而影响论文得分。因此，考生在论文准备阶段就应该注意这方面的锻炼。
此外，与首尾一致相关的一些检查事项，诸如错字、漏字等情形也要注意。如果在论文写 完还有时间的话，要做一些必要的修正，这也是合格论文的必需条件之一。
2.可能涉及的关键技术
系统架构设计师的论文题目是在对架构师所需专业知识掌握的前提下，进行专业知识在工程项目中的应用。因此，要撰写好论文，一定需要具有相关的专业技术知识，例如经典的架构风格及其应用场景(面向对象、面向过程、 SOA、 微服务等),架构设计中的质量属性设计(可 用性、性能、安全性、可修改性、可测试性、易用性设计等)和质量属性提升策略，架构评估的过程、方法和技术，架构的建模和描述方式等。这些关键技术在本书中的前面章节均已向读者陈述，考生可以根据自身的情况进行阅读，查缺补漏。
20.3.3 摘要和正文的关系
在拿到论文考题时，很多学生产生的一个问题就是究竟是先写摘要还是先写正文。其实， 没有一种固定的法则，需要根据考生的实际情况来决定。还要注意的一个问题是，正文不是摘要的延伸，而是摘要的扩展。摘要不是正文的 部分，而是正文的抽象。因此，不要把正文"接"着摘要写。
20.4 常见问题及解决办法
在撰写论文时，经常性出现的问题归纳如下。
- (1)
走题。有些考生一看到试题的标题，不认真阅读试题的3个问题，就按照三段论的方式写论文，这样往往就导致走题。同一个主题，试题所问的3个问题可以完全不一样，因此，需要按照试题的问题来组织内容。因为考查的侧重点不一样，同一篇文章，在一次考试中会得高分，但在另一次考试中就会不及格。 - (2)
字数不够。按照考试要求，摘要需要300 ~ 400字，正文需要2000 ~ 3000字。 一般来说，摘要需要写350字以上，正文需要写2500字左右。当然，实际考试时，这些字数包括标点符号和图形。 - (3)
字数偏多。如果摘要超过350字，正文超过3000字，则字数太多。有些学员在练习 时，不考虑实际写作时间，只讲究发挥淋漓尽致，结果文章写下来达4000~5000字，甚至有 超过8000字的情况。实际考试时，因为时间限制，几乎没有时间来写这么长的论文。所以，读 者在平常练习写作时，要严格按照考试要求的时间进行写作。 - (4)
摘要归纳欠妥。摘要是一篇文章的总结和归纳，是用来检查考生概括、归纳和抽象能 力的。写摘要的标准是"读者不看正文，就知道文章的全部内容"。在摘要中应该简单地包括 正文的重点词句。在摘要中尽量不要加一些"帽子性"语句，而是要把正文的内容直接"压缩" 就可以了。 - (5)
文章深度不够。文章所涉及的措施(方法、技术)太多，但都没有深入。有些文章把 主题项目中所使用的措施(方法、技术)一一列举，而因为受到字数和时间的限制，每一个措 施(方法、技术)都是蜻蜓点水式的描述，既没有特色，也没有深度。在撰写论文时，选择自 己觉得有特色的2 ~ 3个措施(方法、技术)进行深入展开讨论就可以了，不要企图面面俱到。 - (6)
缺少特色，泛泛而谈。所采取的措施(方法、技术)没有特色，泛泛而谈，把书刊杂 志上的知识点进行罗列，可信性不强。系统架构设计师考试论文实际上就是经验总结，所以一 般不需要讲理论，只要讲自己在某个项目中是如何做的就可以了。所有措施(方法、技术)都 应该紧密结合主题项目，在阐述措施(方法、技术)时，要以主题项目中的具体内容为例。 - (7)
文章口语化太重。系统架构设计师在写任何正式文档时，都要注意使用书面语言。特 别是在文章中不要到处都是"我",虽然论文强调真实性(即作者自身从事过的项目),而且 20.3.2节也强调了"以我为中心"的重要性，但是，任何一个稍微大一点的项目都不是一个人能完成的，而是集体劳动的结晶。因此，建议使用"我们"来代替一些"我"。 - (8)
文字表达能力太差。有些文章的措施(方法、技术)不错，且能紧密结合主题项目，但由于考生平时写得少，文字表达能力比较差。建议这些考生平时多读文章，多写文档。 - (9)
文章缺乏主题项目。这是一个致命缺点，系统架构设计师考试论文一定要说明作者在某年某月参加的某个具体项目的开发情况，并指明作者在该项目中的角色。因为每个论文试题的第一个问题一般就是"简述你参与开发过的项目"(也有个别情况除外),所以，考生不能笼统地说"我是做银行软件的""我负责航天软件开发"等，而要具体说明是一个什么项目，简单介绍该项目的背景和功能。 - (10)
论文项目年代久远。一般来说，主题项目应该是考生在近3年内完成的。 - (11)
整篇文章从大一二三到小123,太死板，给人以压抑感。在论文中，虽然可以用数字来标识顺序，使文章显得更有条理。但如果全文充满数字条目，则显得太死板，会影响最后得分。 - (12)
文章结构不够清晰，段落太长。这也与考生平常的训练有关，有些不合格的文章如果把段落调整一下，则是一篇好文章。另外，一般来说，每个自然段最好不要超过8行，否则会使阅卷专家产生疲劳的感觉，从而可能会影响得分。