Wait, the title should not be an h1 per the output rules. Correcting that below.
笔记记得越多，越容易乱。课上一条一条往下记，课后翻开全是零碎句子；开会时想到什么写什么，汇报前却找不到重点在哪。问题往往不在记得不够，而在没有地方放结构。大纲式笔记就是为这个准备的，幕布是其中用得比较多的一款。它用层级缩进组织内容，写起来接近列清单，需要时又能切换到思维导图视图，适合边记边理的学习和工作场景。
一个课堂笔记的搭法
设想一个修《信息管理概论》的学生。老师讲得快，板书也不完整，如果用普通文档记录，课后通常只剩一堆断句。换成大纲的做法是：每一讲的主题作为一级节点，知识点作为二级节点，老师举的例子缩进到对应知识点下面。上课时不必纠结格式，先把内容快速记下来，课后再用缩进理顺层级，这一步通常不需要太多时间。
复习时的好处更明显。把所有节点折叠到一级，整门课的框架一屏就能看完，哪一讲讲了什么心里有数。再逐层展开查漏补缺，比从头读一遍笔记快得多。关键是先看结构再看细节，回忆时顺着框架走，不容易漏掉整块内容。
产品需求怎么先搭骨架
做需求梳理时，很多人直接开写长文档，写到一半才发现前面的背景和后面的功能对不上。更稳的做法是先搭骨架。以一款校园社交小程序为例，可以先列出几个一级节点：背景与目标、用户角色、核心场景、功能清单、验收标准。每个功能点作为独立节点，下面再挂接口说明、异常情况和优先级。
骨架定下来以后，内容的位置就固定了。讨论时大家直接在对应节点下留言，不用在一大段文字里找某个功能写在哪里。有人提出某个功能缺少异常处理，就在那个节点下补充，讨论范围比较集中。这种方式不会替代需求评审，但能让评审前的沟通少走一些弯路。
周会纪要：把行动项单独拎出来
会议纪要最容易出的问题是行动项被淹没。一场会议里，结论和待办常常散落在各处，会后没人清楚谁该做什么。一种改法是在会议中直接记录：议题作为一级节点，讨论要点作为子节点，结论和待办单独放进“行动项”节点，每条写明负责人和截止时间。
这样做的价值在于会后检索。成员只需打开“行动项”节点，就知道自己名下有哪些事。下次例会开始时，先展开上周的待办逐条确认进度，比回忆“上次好像说过”要可靠。这个习惯并不复杂，难的是每次都坚持把行动项写清楚。
使用时的几个建议
- 先列几个一级主题，再往里填细节。骨架不稳，内容越多越乱。
- 节点不宜嵌套太深。层级超过三四层时，通常说明某些内容该拆成另一个主题，而不是继续缩进。
- 行动项、待办、结论单独成节点，之后按名称就能找到，不必在长文里翻。
- 每隔一段时间回顾一次，删掉重复记录，把散落的节点合并到合适的位置。
- 多人协作时，提前说好谁负责哪个节点，避免几个人同时改同一处，最后谁的版本都不完整。
什么场景适合，什么场景别硬用
- 适合：课堂笔记、读书摘要、会议纪要、项目规划、需求梳理、个人知识库。这些内容本身层层展开，大纲正好对应。
- 不太适合：需要大量排版、插图和复杂格式的正式报告。这类文档最终要交别人看版式，用专业文档工具会更省事。
- 留意数据安全：如果内容涉及敏感信息，团队在使用前最好确认权限设置、分享范围和导出方式，免得出了问题再去找。
结语
工具不会让人突然变得有条理，但好的结构能让想法更容易落地。幕布的作用，是让记录和整理发生在同一个过程里，而不是事后再花一大块时间重新排。如果手上正好有一门课、一个项目或一次会议的零散笔记，可以先用大纲搭一遍，看看结构出来后，内容是不是更快能找到。
