@LaurelHarmon #14
如果没有“一气呵成”的功力，就先写大纲吧，起码我是这样，大纲可以保持前后逻辑一致
还要养成 review 习惯，回头看前面写的部分，多次修改是我的常态
缺点是“慢”，完成时间有点长，且不适合对答，因为对方的提问[思维]并不是按着你的大纲走的，很容易变成“不在一个频道”的对话

“引人入胜”是另一种功力，我也不太擅长，但我知道一个简单的窍门：就是不要按顺序写
结论摆在前面，或者把某个例子摆在前面，然后再组织对这个“开头”的详细分析
缺点是“乱”，当顺序打乱，别人没弄懂是个大问题，甚至因为过分追求技巧，把自己原本的逻辑也弄乱了，很容易就变成一塌糊涂

组织一篇文章的结构对我来说是比较简单的，难在于用词，我没有文科生那么丰富的词语表达力和发散想象思维

其实跟面向对象编程一样的，拆分前后端、模块、类、函数，然后用继承、闭包、装饰器串起来，前面拆分的大部件放哪都可以，后面的连接件就是功力了，水平够就用其他不同的模式，水平不够就单例或者工厂模式
例如《西部世界》第一季，部件就是各个场景形成的小故事，参与的“真人”作为装饰器|参数，用“会员设计模式”连接各个装饰器的小故事为“会员大故事”，直到结尾才用时间重构拼接一个年轻的装饰器和一个年老的装饰器为同一对象(life=young+old)，我看了就大呼过瘾，因为一直以为两个会员大故事是各自独立的，没想到他们都只是“中故事”而已，拼接后整季才是一个真正的大故事