先说结论，省得你在站台边反复点开又合上：手机读 17.c 起草官网的折叠页面，顺序应该是「摘要 → 示例 → 备注」。这不是拍脑袋，是编辑部几个人拿早高峰的十几分钟反复试出来的。摘要负责让你知道这一段讲什么、管不管你的活；示例负责让你判断这条和你手上的文档像不像；备注才是那些「但书」「除外」「特殊情况」，读早了反而乱。
我在这行做了些年头，改过的稿子摞起来比人高。折叠展开这种交互，本质上是个信息分层的活儿：作者把内容切成几层，读者按需往下挖。挖的顺序错了，不是读不懂，是浪费时间——手机上每多一次点开、滚动、再返回，都是实打实的注意力损耗。下面把每一层的读法和理由摊开讲。
场景实测17.c 起草官网为什么手机端折叠顺序值得较真
桌面端读条款，屏幕大、可以并排开两三个窗口，折叠展开只是个收纳工具，点开哪一个影响不大。手机不一样：一屏通常只放得下 6 到 9 行正文，一次折叠展开的动效加上滚动回位，大概要吃掉 1 到 2 秒。一条条款正文如果分成 4 个折叠块，全部点开再读完，中间来回滚动十几趟，十分钟就没了。
我们做过一个粗略的自我统计：在编辑部内部，同一篇带折叠的条款解读，按「全部展开再读」的方式，平均耗时约 11 分钟；按「摘要 → 示例 → 备注」的顺序，只展开真正相关的 2 到 3 个块，平均耗时降到 6 分钟出头。这个数字不是严格实验，样本也就十来个人，但方向是一致的——顺序带来的时间差，通常在三到五成之间。
更关键的是理解质量。折叠块默认收起时，页面只露出标题和一行引导语，读者对全文结构的感知是缺失的。先展开摘要，等于先给自己搭一个骨架，后面的示例和备注才有地方挂。反过来，一上来就点开最长的那段备注，读到一半发现这条根本不适用自己的场景，前面那几分钟就白花了。
还有个容易被忽略的点：手机上手指比鼠标粗，误触率天然更高。折叠块挨得近的时候，你想点第三个，常常点到第四个。所以顺序不只是效率问题，也是减少误操作的问题——先点顶部那几个，视线和手指都在同一区域，出错概率明显低。
核心回答17.c 起草官网手机端先展开哪一段最省时间
先展开摘要。摘要通常只有两三句，却能告诉你这一条管什么、不管什么，三十秒内就能判断要不要往下读，是整页里投入产出比最高的一格。
为什么是摘要而不是示例？因为示例写得再具体，也是「某一种情况」的演示，你得先知道这条条款的适用范围，才能判断这个示例像不像你。摘要恰好承担了这个职能：它把条款的适用对象、触发条件、大致后果压缩成几句话。读完摘要，你心里已经有了一把尺子。
举个编辑部常遇到的场景。有位读者在留言里说，他习惯先点开示例，因为示例「看着最实在」。结果那次他读到的是一个跨部门协作的例子，而他手上是单人起草的小稿，条款的适用条件根本对不上，白读了七八分钟。后来他改成先看摘要，摘要里写着「适用于两人以上共同署名的文本」，他一看就跳过了。
这个顺序还有一层好处：摘要通常放在折叠块的最前面，也就是离你手指最近的位置。手机单手操作时，拇指的自然活动区域在屏幕下半部偏右，页面刚打开时顶部内容其实不太好够到。但摘要块一般紧跟在标题下面，位置靠上，点开之后页面不会大幅跳动，读起来顺。
顺便说一句，我们整理这些读法时，凡涉及具体版本号、具体名单、具体数量，都以官方公开信息为准；暂时无法确认的，就留空不猜。这不是客套，是编辑室的规矩——写不清楚的地方宁可空着，也不拿似是而非的内容填版面。
第一步第一步：先展开摘要，三句话抓住骨架
摘要块一般不长，两三句话，偶尔配一行小字说明适用范围。读的时候别逐字抠，抓三个东西：这条管谁、什么时候触发、读完能得到什么。三样齐了，就可以决定继续还是跳过。
17.c 起草官网摘要里最该盯的两个词
第一个是限定词，比如「仅限」「适用于」「通常情况下」。这类词决定了这条的边界，漏看一个「仅限」，后面所有理解都可能跑偏。第二个是程度词，比如「建议」「应当」「必须」。这三档的强制力差别很大，摘要里出现哪一个，直接决定你后面要不要细读备注。
我个人的习惯是，读到「建议」就先松一口气，这条大概率是软性指引，读个大概就行；读到「应当」，就准备往下翻示例；读到「必须」，那基本要连备注一起看完了。这个判断在三十秒内能做完，比逐条展开高效得多。
摘要读完还没底，怎么办
有时候摘要写得太概括，读完还是不知道跟自己有没有关系。这时候别急着往下点示例，先回到页面顶部，看看这一整页的分组标题。折叠页面通常会把相关条款归到一组里，组标题往往比单条摘要更能说明问题。看完组标题再回来，判断会清楚很多。
还有一种情况：摘要里出现了你没见过的术语。这种时候建议先别展开示例，因为示例里大概率会反复用到这个词。可以先在页面内搜一下这个词，看看有没有单独的说明块——不少折叠页面会把术语解释放在靠后的位置，单独成块。
第二步第二步：再展开示例，把条款对到自己的场景
摘要给了你骨架，示例负责填血肉。示例的价值不在「告诉你标准答案」，而在「让你做类比」。读示例时，重点看它描述的场景和你手上的文档差在哪：是主体不同、流程不同，还是时间节点不同。差得越多，这条条款对你的参考价值越低。
按我们的经验，一个折叠页面里通常有 5 到 8 个示例块，但真正跟你相关的往往只有 1 到 2 个。全部点开是浪费，一个不看又容易漏。比较稳妥的做法是：先扫示例块的标题或首句，挑出场景最接近的那个，只展开它。
17.c 起草官网示例里的数字和日期怎么用
示例中常出现具体的天数、份数、比例，比如「提前 3 个工作日」「一式两份」「不超过全文的三成」。这些数字是示例的一部分，不是通用标准。看到的时候要分清：它是这条示例自身的设定，还是条款正文规定的硬性要求。分不清的时候，回到摘要确认一遍，或者直接展开备注看原始表述。
这一点上吃过亏的人不少。有读者照着示例里的「提前 3 个工作日」去安排，结果他那个场景适用的是另一档要求，时间卡得很紧。后来他自己总结出一句：示例里的数字只能当参考，正文里的数字才是标准。这话说得挺准。
17.c 起草官网什么时候可以直接跳过示例
两种情况可以跳：一是摘要已经写得足够具体，适用条件、触发场景、大致后果都交代清楚了，示例只是换个说法重复；二是你时间特别紧，只需要判断「这条跟我有没有关系」，那摘要足够，示例可以留着回头再看。手机上读东西，本来就是个取舍的活儿。
第三步第三步：最后展开备注，补边界与例外
备注是折叠页面里最容易被误读的一块。它通常放在最后，写的是例外情况、过渡安排、历史版本的差异说明。很多人一看到「备注」两个字就觉得是补充材料，随手跳过，结果恰恰漏掉了对自己最要紧的那一句。
我的建议是：只有当前面两步判断出「这条跟我有关」时，才展开备注。如果摘要阶段就已经判定不适用，备注基本不用看。反过来，如果这条确实管着你手上的活，备注不但要看，还要看得比示例细——因为例外条款往往就藏在这里。
备注里的三类信息
第一类是时间边界，比如某条从什么时间点起适用、之前的老文本怎么处理。第二类是对象边界，比如某些主体不适用、某些情形另行规定。第三类是解释性说明，用来澄清正文里可能有歧义的表述。三类里，前两类对实际操作影响最大，第三类更偏阅读理解。
读备注时有个小技巧：先找「但」「除」「另」这几个字。中文条款里，转折和例外几乎都靠这几个字引出来。手机屏幕小，一眼扫过去容易漏，用手指点着屏幕慢慢往下挪，比快速滑动靠谱。
17.c 起草官网备注读完还不确定，别硬猜
如果备注读完仍有疑问，最稳妥的做法是记下条款所在的页面位置和大致标题，回头到站内的条款攻略栏目里对照着看。我们做过几期相关的解读，讲的就是这类边界问题。实在拿不准的，宁可先按保守的方式处理，也别凭印象硬套——文本这东西，差一个字意思就可能变。
设备差异折叠展开顺序在不同设备上的差异
同样是「摘要 → 示例 → 备注」，在不同设备上执行起来手感完全不同。小屏手机（宽度 360 到 390 像素这一段）一屏能显示的内容最少，滚动次数最多，顺序带来的效率差也最明显。大屏手机和平板就好一些，一屏能放下更多，但也更容易一次点开好几个块，反而分散注意力。
| 设备类型 | 一屏可见行数（约） | 建议展开块数 | 典型耗时 |
|---|---|---|---|
| 小屏手机（≤390px） | 6–8 行 | 2–3 个 | 6–8 分钟 |
| 大屏手机（≥410px） | 9–12 行 | 3–4 个 | 5–7 分钟 |
| 平板 / 横屏 | 14–18 行 | 4–5 个 | 4–6 分钟 |
表里的数字是我们自己反复试出来的经验区间，不是严格测量值。但规律是稳的：屏幕越小，越要克制展开的数量。小屏上一次开三个以上的块，页面会变得很长，滚动起来容易迷失位置，读完一个块想回到顶部对照摘要，得滑好一会儿。
另外提一句横竖屏。竖屏适合顺序阅读，横屏适合对照阅读——比如一边看示例一边看备注。如果你手上有两个相关条款要比对，横屏会比竖屏省力不少，虽然字会小一点。
取舍建议17.c 起草官网页面展开建议：哪些段落其实可以不点
折叠页面的设计初衷，是让读者按需取用，不是让你全部展开。有些块，从标题就能判断跟自己无关，那就大方跳过。判断的依据很简单：看标题里的对象词和场景词，跟你手上的活对不对得上。
- 对象不对的块，直接跳。标题里写着「多人协作」「跨部门」，你手上是单人稿，那基本不用点。
- 场景不对的块，可以跳。比如标题带「历史版本」「过渡期安排」，你要处理的是当下的新文本，参考价值有限。
- 纯术语解释块，按需点。前面摘要里遇到不认识的词再回来点，没必要一开始就读。
- 示例块，挑一个最像的。通常是标题里出现你所在行业或文档类型的那一个。
按这个思路，一个 8 到 10 个折叠块的页面，实际需要展开的往往只有 3 到 4 个。剩下的靠标题和摘要就能建立大致印象，需要时再回来翻。这种「先建索引、后按需取用」的读法，在手机上尤其管用。
顺带说个跟内容没关系但很实用的小事：把页面字号调大一档，比反复放大缩小省事得多。手机浏览器一般都有阅读模式或字号设置，开一次，以后所有页面都受益。
避坑提醒17.c 起草官网手机端的三个常见误操作
这三个坑，编辑部收到过不止一次反馈，都是实际操作中真会遇到的。
17.c 起草官网一上来就全部展开
看着痛快，实际上页面会变得极长，读到后面忘了前面。更麻烦的是，全部展开之后，折叠块之间的视觉分隔会变弱，容易把两段不同的内容连起来读，理解上出错。顺序读法的好处之一，就是每次只看一块，边界清楚。
只看示例不看摘要
前面提过，这是最常见的。示例写得具体，容易让人产生「我懂了」的错觉，但示例只是某一种情况的演示。跳过摘要直接读示例，等于拿一个特例去套自己的场景，跑偏的概率不低。
17.c 起草官网读完不记位置，回头找不到
手机上读完一段，切出去回个消息，再回来页面往往重新加载，滚动位置没了。建议读到关键处时，顺手截个图，或者把标题里的关键词记在备忘录里。下次回来直接搜关键词，比从头翻快得多。
17.c 起草官网一份可打印的折叠顺序速查表
下面这张表可以截图存手机，也可以打印出来贴在工位旁。左边是步骤，中间是动作，右边是判断标准，照着走一遍就行。
| 步骤 | 展开哪一块 | 重点看什么 | 判断标准 |
|---|---|---|---|
| 第 1 步 | 摘要 | 限定词、程度词 | 30 秒内判断是否相关 |
| 第 2 步 | 示例（挑 1 个） | 场景差在哪 | 主体、流程、时间是否对得上 |
| 第 3 步 | 备注 | 但、除、另 | 例外条款是否落在自己身上 |
| 收尾 | 不展开 | 记标题关键词 | 留待需要时回查 |
这张表看着简单，实际用起来能省不少来回。我们编辑部有同事把它设成了手机壁纸，说是每次读长文前扫一眼，心里就有谱了。当然，具体到某一条条款，还是要以页面上的正文表述为准，速查表只是帮你排顺序，不能替代原文。
数据侧写读者常问的几个问题
下面几条是留言里出现频率最高的，集中回答一下。
手机上一屏能放几行正文，影响展开顺序吗？
摘要只有两三句，信息量够判断吗？
示例里的天数比例，能直接当标准用吗？
备注是不是可以最后再看，甚至不看？
按这个顺序读，一篇大概要多久？
页面重新加载后滚动位置丢了，怎么找回？
17.c 起草官网编辑室的口径与更新节奏
拾柒号草案馆这支编辑小组，信条是「把公文写成文学」。话说得有点大，落到日常就是：条款要写准，句子要写得让人读得下去。这篇讲折叠顺序的文章，也是按这个思路来的——先给能用的方法，再讲背后的道理，不绕弯子。
关于口径，有几条是我们一直守着的：涉及版本号、生效时间、具体数量这类可核实的细节，以官方公开信息为准；暂时无法确认的，宁可留空也不猜；不展示无法核实的播放量、评分、获奖记录。你在页面上看到的所有数字，要么是我们自己试用得到的经验区间，要么标注了来源口径，不会拿似是而非的东西充数。
更新节奏上，资讯栏目一般每周一、周三各更新一次，周末视情况补一篇轻量的读法整理。条款攻略栏目更新频率低一些，但每篇都写得比较长，通常两周一篇。版本评测栏目跟着官方节奏走，官方有动作我们才动，不硬凑。
折叠展开顺序初稿完成，编辑部内部试用两轮，调整了摘要的判断标准。
补充设备差异对照表，加入小屏与大屏的展开块数建议。
正式发布，同步更新速查表与常见问题部分。
如果你按这个顺序试过之后有不同体会，欢迎在下面留言。读法这东西没有唯一答案，多几个人试，路子才会越走越顺。
读者评论
按摘要先看的方法试了一次，确实省事。以前总是一上来点示例，读完才发现场景不对，白白浪费早高峰那十分钟。
设备差异那张表挺实在的。我小屏手机，以前一次开四五个块，滚动起来完全找不到位置，现在控制在三个以内舒服多了。
备注那段说到点子上了。我吃过亏，跳过备注结果漏了例外条款，后面返工。现在养成习惯，只要这条跟我有关，备注必看。
速查表截图存手机了。建议再加一条：读到关键处一定截图，页面重新加载后位置全丢，重新找太费劲。
喜欢这种把口径写清楚的写法。数字给了区间，也说了是经验值，没有硬造精确数据，读着放心。