大家好！

今天和大家继续聊一聊结构化思维的相关话题，关注技术写作和结构化电子病历上的应用。

技术写作上的应用

在我所在的技术写作领域，有一种称作结构化写作的理念，即将原本的整套文档层层拆解为各种元数据，并对这些元数据进行独立的撰写和更新。当需要发布文档时，再将元数据组合起来，形成一篇篇完整的文档。

例如，对于产品的用户手册而言，一般会包含功能说明、使用步骤、操作类别、注意事项、菜单文字、界面提示语、常见故障及解决方案等等，这些都是用户手册的基本数据，我们看到的手册其实就是在这些基础数据上“加工”而成的。

在结构化写作视角之下，我们在从无到有撰写一篇用户手册时，不需要采用传统的模式，即从上到下按章节撰写的“瀑布模式”，而是将原本的手册分拆成一个个信息块和元数据，这些信息块和元数据可以由不同的人员按照统一的规范进行撰写。

从理想状态来说，结构化写作可以应用于绝大多数的文档，而目前应用最多的是各类产品的用户手册，以及相关的配套文档。

表面上来看，这是对于文档本身的分解，但其本质是对于产品的分解，因为产品从无到有的设计过程也可以看成是元数据不断完善的过程，当产品最后完成开发和测试，等待交付时，其实元数据也完成了基本的雏形。

在技术写作领域，用户类文档必须和产品保持强一致性，每一个新产品的诞生、每一次的产品升级都需要文档的及时更新和撰写。

如果我们能做好产品的分解，那么产品管理的每一个环节就能输出必要的元数据雏形信息，为后续的文档工程师撰写提供高效的信息传递保障，同时，文档工程师也可以参与到各个产品管理环节，在产品正式落地之前就获取信息，提前做好必要的准备。

当这些元数据组合后，可以形成一篇篇文档。

比如将功能说明、使用步骤、操作类别和注意事项等组合起来，可以形成一篇用户手册；

针对特定功能的用法，又可以通过对上述这些元数据的删减，并配合一些新增的内容，形成一篇应用指南；

针对界面提示语和故障代码，又可以形成一本面向于技术支持工程师的维护手册。

结构化写作的另一个好处就是修改便捷，当我们需要修改一些信息时，只需到其对应的元数据处进行修改，然后在相关的文档或信息块中即会自动反映这一修改，达到“一次修改，全面开花”的高效境界。

若某一个版本升级后，改了一个界面提示语，这个时候，我们只需要在元数据中找到这个提示语，并进行修改后，可以同步更新到用户手册和维护手册中，无论这一个提示语在什么位置，也无论其有多分散。

从产品/文档元数据的分解，到最后的重新组合，形成一整套配套文档，这就是“打碎后再组合”的过程。

结构化电子病历上的应用

除了技术写作领域外，其实还有不少领域也在应用结构化写作的理念。

比如，在医疗信息化领域中，结构化电子病历成为目前医生在诊疗时的首选，医疗信息化也在各大医院如火如荼地全面铺开。

与技术写作类似，医生在撰写病历时，可以在一开始快速选择模板，然后在相应的选项中选择符合当前病人的情况，如具体的主诉病症、临床表现、是否有过敏史等，最后组合成句，形成完整的病历。

这样做的好处是，能够通过结构化和标准化的方式加快医生撰写病历的效率，使医生能够将主要精力放在对于病人的诊疗上，从而提升诊疗效率。

此外，通过结构化病历，可以将诊断过程进行一定程度上的标准化，也是提醒医生按照标准化的方式进行诊断，减少诊断过程中可能出现的疏漏。

比如，之前上海的某家医院曾出现过一次医疗事故，医生为一位年轻的感冒患者开具了头孢输液的处方，结果起了过敏反应，虽然医院以最快的响应速度进行了抢救，但仍然没有挽回年轻患者的生命。

试想，如果能在诊断和开方过程中按照结构化病历的要求，对过敏史进行确认，对于没有过敏史、过敏史不全的患者，则增加相应的检验或检查项，这样能确保万无一失。

最后

对结构化的过程其实就是对事物整理的过程，是把复杂事物层层分解，最后拨开云雾见真相的过程，这里的真相就是事物的本质。

当事物最终完成了结构化分解之后，就能从混沌中走出来。

打碎的过程是探寻事物本质的过程，而组合的过程则是在充分理解事物本质之后对于事物最终表现形态的“改造”。这样的改造是能动的，能让我们实现对事物的掌控。

这里的掌控可以认为是一种彻底的、覆盖整个生命周期的掌控，能够及时反映出事物的发展变化，甚至可以通过对结构化数据的分析，预测出事物未来的发展变化，这就是结构化给我们带来的福利。