文档啊，最重要的还是层次感

亲爱的姑娘，我的血为你流，汗为你流，我的泪也为你流，还有，还有我所有其他的一切也都为你流…

大家不要慌，你没走错地方，这是我青春时期最喜爱的作家冯唐。冯唐有很多标签，协和医学博士、托福满分、emory MBA、麦肯锡合伙人、华润医药CEO、中信资本董事总经理等等。

久仰大名

为什么讲写作技巧时要谈冯唐呢?

记得冯唐在一篇文章里说，他进麦肯锡后被训练的第一个玩意儿，叫做金字塔原则，并且“后来证明，这也是之后诸多训练中，最宝贵最有用的玩意儿。”

所以《麦肯锡教我的写作技巧》这本书售价30块，“金字塔原则”这个章节大概能值回29块。

金字塔结构的介绍

书中是这样介绍金字塔结构。

简单来说，金字塔结构就是用一种见树又见林的方式来呈现出内容框架，让人有很直观的感受。

其实多年以来，我就将这种金字塔结构归纳为层次感。看到这个章节后，很喜欢这个名字，它比层次感这个词更加具象。

金字塔结构的应用

金字塔结构应用的地方非常多。有人的地方就有江湖，我想说，有内容的地方，就有金字塔结构。

事实上，最直观的例子就是这本书，它的内容就是按照直列型金字塔来安排的。第一章节讲信息大致分类，第二章讲具体的句式，第三章拓展到文档总体的框架脉络。

联想开来，我们日常的工具就呈现了这种结构。

你看，这是word中的文档结构图。

这是pdf的书签。

还有我最喜爱的markdown也是一个十分方便呈现逻辑结构的编辑工具。

此外，对于开发者来说，甚至细微到了代码更新日志，也需要认真地来勾勒金字塔结构。

特别重要的一点，化繁为简

关于金字塔原则的运用，书中提到了一个特别重要的注意事项。也是我在这篇心得里，特别要分享的一个观点。

那就是化繁为简，抽象小标题的能力，似乎很多人都缺少这种必要的信息加工能力。

有一个让我印象特别深刻的例子，两年前遇到一个国内某大型空调公司的定制任务。前面的一个同事全职做了三个月，还是没能顺利结束。

这个功能文档总共有4页多，经历过了 技术->研发->测试 等多个部门，中间却没人梳理下功能点。也许几个环节的人都在艰难地消化了这份文档后，接受了它。但对于我这个新接手的人，又得花费和前人一样的时间精力来梳理这份文档。至今回想起来这件事，还是会带上一些情绪，对这样的事情很想吐槽一番。

这些冗长的段落摆放在那里，就这样影响了团队间的交流。大家知道完成了几个功能点，还剩下几个功能点吗?反馈某个问题时，大家能定位到哪个功能点吗?还能想到的情况是，在后续代码审核、项目交接时，每个涉及的人都要被折磨一番。

我想这个项目之所以有点乱，多半和这份指导性的文档有关系。如果能有个人化繁为简地加工下，抽象出功能点的小标题，也许会对项目情况改观不少。

这样处理下，是不是感觉清晰了很多，这样所有人都知道，这个项目无非就是这5大功能点。

另外一个例子，是我们团队成员小P。(之所以会写下这篇文章，也是答应小P分享下金字塔原则。)

小P最近加班加点地完成了一个比较大的定制项目，梳理了一份自测报告。

我对这份报告提了点意见：在具体自测部分，用了碎片化的记录方式，用具体某些条件测试得到某些结果。这样就缺少了对总体功能的把握。你想，测试组同事拿到这个任务时，要怎么开始测呢?

好的内容结构可以是这样呈现：

它的金字塔结构是这样：
第一层是总述
第二层是逐个功能点：传输、维护、心跳、火警、防拆
第三层是单个功能点的具体测试情况

---

好了，例子就说到这里。这两个例子，表面上都是文档结构，其实背后更多的是对内容的逻辑思考。

在我看来，开发者最应该成为整个团队的灵魂人物。作为衔接前端、后端的纽带，应该是对功能点有最透彻理解的人。在考虑代码前，就应该梳理清楚逻辑结构。对外输出的设计方案、测试报告如果不体现出这逻辑关系，坏的情况，可能会导致整个项目的人跟着混乱不清。

---

希望这篇文章能对你有所启发，或许你不是开发者，这也没关系。

如果立志成为团队的灵魂人物，那当下就可以注意自己的内容输出，尝试将金字塔原则运用到你的日常工作中去。

也许会有一些收获。

这篇分享收录在我的文章合集“成长之路”中。我正在从文档习惯，知识体系管理，项目管理等多个技能角度，分享一些心得。帮助自己梳理总结，也希望能对他人有所启发。

---