先说个挺真实的场景：一位做工程合同的朋友，第一次打开 17.c 起草官网，盯着首页那面问答式标题墙看了半分钟，然后问我——「这到底是个导航，还是个 FAQ？」我当时没直接回答，而是让他把鼠标停在第三条上，点开，再缩回去，再点开旁边那条。两轮之后他自己说了句：哦，这是在教我怎么找东西。
对，这就是这面墙的定位。它不是装饰性的常见问题列表，也不是传统意义上的栏目导航。17.c 起草官网 问答式标题墙更像一份「按提问方式重排的目录」——你把脑子里那句还没成形的疑问丢进去，它给你一条可点开的路。下面这篇，我把它的结构、折叠逻辑、五步用法、以及容易踩的坑，一条条摊开讲。
问答式标题墙到底是什么，先看清它的骨架
它是一组以疑问句为标题、可折叠展开的条目集合，铺在首页首屏之下，每条问题对应一个内容落点。点开只展开摘要，真正的正文留在内页。
拆开来看，这面墙由三层东西叠起来。最外面是「问题句」，也就是你眼睛先扫到的那一行，用的是接近口语的问法，比如「旧版本条款去哪找」「同一份文档两个版本差在哪」。中间层是折叠面板，点了才展开，展开后通常给三到五行的短摘要，交代这条问题大概涉及什么范围。最里面一层是跳转入口，摘要末尾挂一条内链，把你送去真正讲透的页面。
这个三层结构的意义在于：它把「检索」和「阅读」分开处理了。你在墙上做的是判断——这条问题是不是我要的；点进内页之后才进入真正的精读状态。对每天要处理十几份文档的人来说，这个分离很值钱，因为它把最贵的注意力留给了真正需要读的内容。
另外提醒一句，墙上的问题句都是编辑根据读者来信和检索词整理的，不是凭空编的。但具体某条问题背后涉及的条款版本、适用场景，仍然以内页正文和公开资料为准；我们不会为了显得权威去补一个查不到的日期或编号，这是拾柒号草案馆一直守的编辑习惯。
17.c 起草官网 问答式标题墙为什么用折叠展开
折叠展开解决的是「首屏信息量」与「条目数量」的矛盾：全部展开会让首屏变成一堵字墙，全部收起又等于没给信息，折叠是折中解。
假设这面墙有 24 条问题，每条摘要 60 到 80 字。全部展开，首屏能塞下的高度大约是 3 条多一点，剩下 20 条得滚很久才能扫完，读者会在滚动中失去耐心。全部收起呢，只留问题句，那和普通链接列表没区别，读者无法预判点进去值不值。折叠展开卡在中间：默认只露问题句，视觉上 24 条能压缩到一屏半左右；想看细节的点开，不看的一眼掠过。
还有个更实际的原因——起草人的检索往往不是「我要找 A」，而是「我隐约记得有这么个说法，但不确定叫什么」。这种情况下，问题句比栏目名更接近他的心理语言。折叠状态下，他可以快速扫过所有问题句，靠语感命中；命中之后再展开确认。整个过程像翻一本按问题编排的索引册，而不是在菜单里猜分类。
从工程角度看，折叠还有个隐性好处：默认收起意味着首屏不用渲染那么多文本节点，滚动过程中再按需展开，页面响应更稳。这点对移动端尤其明显，后面第九节会细讲。
17.c 起草官网标题墙的四个分区，各自接什么活
如果你仔细扫一遍，会发现这面墙不是一条线排下来的，它内部有分区，只是分区标识做得比较轻。按我的观察，大致是四块，各接不同的活。
17.c 起草官网第一块：新手入口区
排在最前，问法最基础，比如「第一次用该从哪看起」「栏目之间是什么关系」。这一区的条目摘要偏短，一般 40 到 60 字，因为新手不需要细节，需要的是方向感。点进去的落点通常是概览类文章，一篇能带出三四条后续路径。
17.c 起草官网第二块：操作路径区
中段最厚的一块，问的是「怎么做」——检索、比对、留存、引用编号核对。摘要长度普遍在 70 到 90 字，会交代大致步骤数,比如「三步」「五个环节」。这一区是整面墙信息密度最高的地方，也是老手停留最久的区域。
17.c 起草官网第三块：判断与评价区
问的是「差在哪」「值不值」「适不适合我」。摘要里会给出比较维度，但不给结论——结论留在内页，因为结论需要上下文，摊在墙上容易被断章取义。
第四块：边界与说明区
垫在最后，处理「哪些事这里不做」「信息以什么为准」这类问题。条目数量最少，通常 3 到 4 条，但每条都写得比较实。这一块的存在感不强，却是最容易被认真读者翻到的地方。
四块加起来，条目数一般控制在 20 到 26 条之间。少于 18 条显得单薄，多于 30 条会让折叠的节奏感崩掉——点开一条、缩回一条的动作重复太多次，人会累。
17.c 起草官网 问答式标题墙怎么用：五步上手
核心就一句话：先扫问题句、再点开确认、最后跳内页精读。别一上来就逐条展开，那是把索引当正文读，效率反而低。
下面这五步是我自己反复用下来最顺的顺序，写出来给你照着走一遍。
- 先整屏扫一遍问题句，不点开从第一条扫到最后一条，只读问题，不展开。这一步大约花 20 到 30 秒，目的是建立「这面墙有什么」的整体印象，同时让眼睛记住几条候选。
- 锁定 2 到 3 条候选，逐条点开展开后先看摘要的第一句，判断范围对不对。如果第一句就跑偏了，直接缩回去，别往下读——摘要存在的意义就是帮你快速淘汰。
- 摘要读完，判断该不该跳摘要末尾那条内链指向的页面，才是真正讲透的地方。如果摘要已经把你要的答案说完了，说明这条问题问得太浅，换个问法再找。
- 跳进内页后，先看目录再读正文内页一般都有目录盒。花 10 秒扫目录，确认你要的那一节在第几段，直接锚点跳过去，别从第一段顺着读。
- 读完把有用的条目记下来不一定要收藏，记一条「问题句 + 内页标题」就够。下次再遇到同类问题，凭问题句的语感就能直接命中。
这五步走熟之后，整面墙的检索时间能压到一分半以内。我做过一个不算严谨的自我记录：用这套顺序找「旧版本比对」相关资料，从打开首页到读完目标段落，大约两分四十秒；换成传统栏目导航逐层点，同样目标要四分钟出头。差距主要花在「猜分类」上——问题句不用猜分类。
17.c 起草官网条目为什么长这样：字数、层级与节奏
墙上每条东西的长度不是随手定的，背后有一套挺朴素的刻度。我给你摊开讲，你看完大概能理解为什么有些条目读着顺、有些读着别扭。
17.c 起草官网问题句控制在 8 到 16 字
太短说不清指向，比如「版本」两个字，你根本不知道问的是哪个版本；太长就变成一句话摘要了，扫读时眼睛负担陡增。8 到 16 字这个区间，大约是一口气读完不换气的长度，扫起来最顺。超过 20 字的问题句，在墙上通常会被拆成两条。
17.c 起草官网摘要 40 到 90 字，分两到三句
第一句交代范围，第二句给一个关键判断或步骤提示，第三句（如果有）挂内链引导。三句以上的摘要很少见，因为折叠面板一展开就是一大坨，收回去的动作会变得犹豫。
默认只展开一条
这是个体感上的设计：同时展开多条，页面高度会跳，视线会丢。默认情况下点开新的那条，旧的那条自动收起，保持墙面整洁。当然你也可以手动保持多条展开，用来做条目之间的横向对照——这个用法比较进阶，但确实好用。
17.c 起草官网层级最多两层
墙面本身不嵌套子折叠。也就是说，不存在「点开一条，里面还有一条要再点」的结构。两层以上的折叠在网页上很容易把人绕晕，而且对屏幕阅读器也不友好。需要分层的复杂内容，一律放到内页去做。
把索引做得能一眼扫完，比把索引做得无所不包更重要。前者省的是读者的时间，后者省的是编辑的力气。 —— 拾柒号草案馆编辑组内部分工备忘
和常见官网导航相比，差在哪
为了说得具体点，我拿三种常见的官网入口形态跟这面墙做个对照。不是要证明谁更好，而是让你知道什么情况下该用哪种思路找东西。
| 形态 | 首屏信息量 | 适合的检索状态 | 典型命中耗时 |
|---|---|---|---|
| 顶部栏目导航 | 低，仅栏目名 | 目标明确、知道分类 | 约 30–60 秒 |
| 搜索框 | 极低 | 记得关键词、术语准确 | 约 15–40 秒 |
| 资讯流列表 | 中，标题+时间 | 想浏览、无明确目标 | 约 1–3 分钟 |
| 问答式标题墙 | 中高，问题句+可展开摘要 | 记得大意、说不准术语 | 约 1–2 分钟 |
看这张表你会发现，问答式标题墙真正补的是「记得大意但说不准术语」这个空档。搜索框要求你词准，栏目导航要求你分类感准，资讯流要求你有闲。而绝大多数起草场景下，人的状态恰恰是第四种——脑子里有个模糊的轮廓，但落不成一个准确的词。
所以别把这面墙当搜索框的替代品。术语明确的时候，搜索框更快；只是想随便看看有什么的时候，资讯流更合适。墙的价值在中间地带，用对了省时间，用错了会觉得绕。
17.c 起草官网法务、编辑、项目经理各该怎么读
同一面墙，不同岗位的用法差别挺大。我把三类常见读者的路径分别写一下，你对照自己的角色挑着看。
17.c 起草官网法务：从边界与说明区倒着读
法务最关心的是「哪些信息是确定的、哪些是待核的」。建议直接从墙的第四区（边界与说明）读起，那里对信息口径的交代最集中。读完再回中段找操作类条目，顺序是倒的，但更符合法务的风险优先级。
17.c 起草官网编辑：把标题墙当语料库
编辑的用法有点不一样——问题句本身就是很好的语料。同一件事，读者会用什么词去问？这些问题句基本是从真实提问里提炼的，扫一遍能明显感觉到「读者语言」和「编辑语言」的落差。写稿时把这个落差记住，标题会好写很多。
项目经理：只锁操作路径区
项目经理时间碎，建议只盯第二区（操作路径）。那块的条目基本对应「怎么检索、怎么比对、怎么留存」这类动作，跟项目节点直接挂钩。其他三区偶尔扫一眼即可，不用细读。
顺便说一句，这三类读者的路径差异，也是这面墙分区存在的理由。如果所有条目混成一片，法务和项目经理的检索成本都会上升。
折叠展开会不会打断起草思路
会有轻微打断，但可控。关键是别在思路正顺的时候去点墙——把检索动作集中在起草前或卡壳时，中断感就基本消失了。
这是个很实在的顾虑。起草是个需要连续注意力的活，任何一次页面跳转、任何一次展开收起，都是一次小的注意力切换。切换成本累加起来，确实会打断节奏。
我的做法是把检索动作前置。动笔之前，先花三五分钟在墙上把可能要引用的东西都找齐，把内页开着放在旁边标签页。写作过程中如果突然想起「还有个说法要核对」，不立刻去查，而是在草稿边上记一行待办，等这一段写完再统一处理。这样折叠展开的动作都集中发生，不会碎在写作中间。
另外一点体感：折叠展开比整页跳转的打断感要小。因为它不刷新页面，视线位置基本不动，展开后内容就在原地长出来。相比之下，点一个链接跳到新页面、再跳回来找原来的位置，那个成本高得多。这也是折叠设计在起草场景下比较讨喜的原因。
当然，如果你正在写的是需要高度连贯的长段落，那连折叠都别点。把墙留着，等这段写完再说。工具是给人让路的，不是反过来。
17.c 起草官网手机上这面墙还站得住吗
站得住，但用法要调整。桌面端和移动端的检索姿势差别不小，我分开说。
桌面端屏幕宽，问题句可以横向铺得比较长，一屏能扫到 8 到 12 条。鼠标悬停时条目会有轻微抬起，点开的动作精准。这种条件下，整墙扫读是舒服的。
移动端不一样。屏幕窄，问题句会折成两行，一屏大概只能看到 4 到 6 条。这时候整墙扫读的效率下降明显，更实用的是先滚动、靠关键词定位，找到大概位置再逐条看。另外触屏上点开的误触率比鼠标高，所以折叠面板的触控区域做得比视觉边界大一圈，点起来不那么费劲。
还有个细节：移动端默认展开的条目会在展开后自动滚动到可见位置，避免你点开了却看不到内容。这个动作很小，但对小屏体验影响挺大。
以上数字仅描述本站这一版问答式标题墙的内容组织与排版口径，用于说明页面结构，不代表访问量、用户量或任何第三方评价。
17.c 起草官网六个常见误用，避掉就顺了
下面这几条，是我见过（包括自己犯过）最多的误用。前三条是用法问题，后三条是预期问题。
一、把整面墙当正文读
从头到尾逐条展开、逐条读完。这样下来花的时间比直接读三篇长文还多，而且信息是碎的。墙是索引，不是读物。
二、只点第一条
很多人扫一眼就点第一条，其实第一条未必最贴合你的问题。多扫两条，判断会更准。
三、展开后不读摘要直接跳
摘要的作用就是筛。跳过摘要直接跳内页，等于放弃了筛选机制，很容易跳进一篇跟你问题不太相关的文章。
四、期待墙上有完整答案
折叠面板里放的是摘要，不是完整解答。如果你指望在墙上就把事情搞明白，会失望。它的职责是把你送到对的地方。
五、期待问题句覆盖所有情况
墙面条目数是有限的，20 多条不可能穷尽所有提问方式。找不到对应条目时，用搜索框，或者去资讯栏翻一翻。
六、以为条目一成不变
这面墙是会更新的，条目会增删、问法会调整。上周看到的那条，这周可能换了措辞，也可能会被合并。别把某一条的措辞记成固定锚点。
17.c 起草官网这面墙多久换一次，谁在维护
既然是「官网首页」的一部分，它的更新节奏其实挺能说明一个站点的运营状态。我把观察到的规律讲一下，也顺便交代一下我们这边的编辑取舍。
从节奏上看，这面墙大致保持每周一次小调整、每月一次结构梳理的频率。小调整指的是改问题句措辞、换摘要、调条目顺序；结构梳理则可能动分区，比如把某一类问题从操作区挪到评价区，或者合并两条问法接近的条目。这种频率不算高，但也不算放养。
维护依据主要有两个来源：一是读者反馈里反复出现的提问，二是站内检索词里那些「有量但没对应条目」的长尾问法。前者说明现有条目没讲清，后者说明墙面缺条目。两个信号指向的动作不一样，得分开处理。
还有一条编辑上的自我约束：凡是涉及具体版本号、发布时间、适用范围的问题，条目摘要里一律不下结论，只做指引。原因很简单，这类信息有更新周期，写在墙上容易过期，写在正文里至少有上下文兜着。我们也不在墙上写无法核实的数字——查不到来源的，宁可不写，也不补一个看着像真的。
如果你发现某条问题句和它指向的内页对不上，或者摘要里有一句明显说过头了，欢迎通过资讯栏的反馈入口告诉我们。这类反馈比「再加点内容」有用得多。
常见问题与排查
17.c 起草官网 问答式标题墙和普通 FAQ 有什么区别？
为什么我点开的条目会自动收起上一条？
墙上找不到我要的问题怎么办？
条目摘要里的说法能直接引用吗？
这面墙上的条目是谁定的，会不会有偏向？
手机上这面墙的展开会不会很卡？
写这篇的人
读者怎么说
以前真把这面墙当装饰，看完这篇才知道要倒着从边界区读起。试了一遍，找旧版本那条路径确实快了。
五步上手那段最有用。我原来就是逐条展开读，读完比读三篇长文还累，现在改成先扫再点，省事多了。
法务视角那段说到点子上了。我们看东西第一眼就是找口径说明，墙的第四区确实是先该去的地方。
关于折叠会不会打断思路的那段挺真实。我现在都是动笔前先把要引用的找齐，写作中间不碰页面，效率确实不一样。
移动端那段有共鸣。手机上确实扫不了整屏，我现在都是先滚到大概位置再逐条看，比硬扫快。