首先，我们解决一个问题，我们有了第一个方法。然后，我们想解决包含这个问题的一类问题，我们总结一个元方法。然后，我们想知道怎么样找到一类问题的方法的方法，这是就是元方法的元方法。或者说，元元方法。这样的一个不断上溯的过程，我称之为求元方法递归。
从互联网业务 - 编程实际场景举例子，飞猪，大家都知道，阿里的在线旅行电商销售网站。飞猪最开始只是照搬了淘宝的下单组件，这个下单组件针对于一般商品的下单流程，他只能让用户填写收货地址和数量和品类。对于飞猪的签证业务来说，这样的下单组件起不了帮助。因为签证业务需要收集用户的关键护照信息，那么就只能靠客服一对一的聊天和用户确认信息。运营收集到行业商家的痛点，反馈给产品经理，产品经理思考这个需求点的合理性和整体流程，给到技术开发排期上线。好，至此为止，第一层 meta 元方法产生了。因为在这个新版的为签证业务定制的下单组件，用一个方法解决了一类问题的麻烦。
那么我们该如何衡量这个元方法的业务 / 技术收益？元方法的收益应该是 =(单个收益 * 适用范围 - 推广成本）。
继续思考，元元方法的产生。我们来讨论第二层是怎么产生的。第二层，如果有很多个类似签证的业务方，比如邮轮，机票，酒店，电话卡，都要定制他们自己的下单组件进来，怎么办？核心思想就是解耦，但是又不仅仅是解耦。比如从解耦层次上，可能是只做数据层解耦，样式定死，支持一部分样式相同的组件的快速部署。又可能是样式、数据同时解耦，还可能是组件级别解耦，业务方根据协议生成组件，交付下单页面渲染布局。
这里可以插一句，内聚 / 解耦的思想，是业务开发的核心方法论。业务开发面对底层开发在跟你炫耀 OpenGL，xx 算法模型，xx 编译原理的时候，可以先说你说的我也略懂，然后再问一句，那么，你懂 xx 业务解耦 / 组件化 / 动态布局 / 行业赋能 / 业务大脑吗？
好，到第二层元元方法就为止了吗？其实不止。必然会有第三层，元元元方法，比如解耦要解到什么地步。假设你确定了这个下单页面可以解耦到组件层级，那明年呢？明年组件层级够用吗？这是时间维度。空间维度呢？换商品详情业务，解耦到什么层级呢？假设我们说商品详情业务可以解耦到数据层级，那么为什么下单可以解耦到组件层级，商品详情业务只能解耦到数据层级？能不能创建出一个推论模式，通过几个条件来判断一个业务究竟能解耦到哪个层级？
前面说的都是业务维度，再从技术一点的维度来说，移动 App 页面开发总共可以归纳为几种形式的解耦，这些解耦各自有几种技术方案来实现。能否把解耦这事情也抽象成一个方案，使得一个业务只需要很低的开发 / 接入成本就可以切换成解耦型方案？事实上，Weex/Rax/H5 也基本等同于是一个直接可插入的组件级别解耦方案了。只是这种大型通用的技术方案，已经不能称之为技术方案了，大家习惯性地把他看成了一个可以吃十几年饭的技术栈。但当我们缩小通用性领域，提高对某一类问题的专业度和适用度的时候，我们必然可以得到一个好的行业解决方案。
第四层 … 好了，不说了，事实上抽象到第三层已经适用大多数场景了。但这并不意味着，第三层的元元元方法很少，事实上，很多。当我们在讨论 n+1 层的元方法的时候，我们必然是舍弃了 n 层中的一些信息，来获取 n1，n2，n3…. 中的一些公有的共同点。那么，舍弃 A、B、C，取 D，和舍弃 A、C、D，取 B，他们得到的 n+ 1 层的元方法都是不一样的。所以，元方法无穷无尽，每上一个维度，他的方法空间的大小也会膨胀一个维度。从一个二维的平面顿时变成了一个三维的空间。所以，抽象的世界比真实世界更复杂，只要我们未曾停下对真实世界、传统业务的扩张和改造，抽象的空间永远存在，人的思考永远有价值。
结尾来一个类似自举一般的奇妙总结。这篇本身，也是一个元方法。