对 鹰鸽博弈 的模拟，一定程度上，也让我自己多了一份释然。
其实没有必要成为凶狠的 鹰，虽然，显而易见，成为一只鹰，不论是面对鸽子，还是其它的鹰，都会给你带来直接的好处。
作为鸽子，有可能会输，而作为老鹰，则有可能会赢。听起来是同一回事，实际上完全不同，相比较对赢的期待，我们更害怕输，换句话说，我们害怕自己成为鸽子，而老鹰则不会害怕自己成为老鹰。这种害怕甚至是我们愤怒的一种来源。
但从长远的角度来看，做一只鸽子，是利大于弊的，终归是能产生更大的收益。我们应该尽可能克制这种愤怒与恐惧。
那么，这个 结果 一定是对的吗？
不见得。
只不过是内心有了预设，用代码做了模拟，进一步自证了答案而已。况且，这个模拟的结果，本身也是随机的。
你如果也有了一丝兴趣，可以在本章涉及的代码中，不断调整一些初始的参数，反复尝试，会得到更多不同的结果。
其实，我并没有结果，具体的结果，皆依赖于你。
如果你实际的工作岗位是产品经理或者市场运营，必须要面对的一个问题是 数据。经常需要 拿数据说话，可能是主动的，也可能是被动的。
如果数据在收集、汇总、分析的过程，没有人为主观倾向的介入，那么，数据是客观的。但这个前置条件一般很难达成，特别当你的工作是对他人、公司负责的时候，不管是自己意愿如何，数据都会不自觉地失去客观性。
有个有趣的事，比如一个 购买 的按钮，从 无背景色+边框+有色文字 的样式，改为 深色背景+白色文字，即使其它什么都不变化，也会提高 (点击) 转化率。这种直觉式的判断，甚至连专业性都说不上。在 《FirstWeb Pro》中，我们有介绍过产品设计，很大程度上就是 常识设计。
但是，常识设计 怎么证明呢？特别是，怎么用数据证明呢？
或者说，真的有必要证明吗？
固然要拥抱数据，但别被表象的专业性包裹，忽略掉数据是不可靠的这个因素。
在鹰鸽博弈中，我们给 双赢 的时候，增加了收益的加成，本质上就是在鼓励 鸽派 的存在；但深究起来，则是反应了 合作 本身会创造额外的价值，所以加成是应当的。但是，人为主观倾向混入数据，就会造成比较高的加成，比如代码中的 1.5，为什么不能是 1.1 呢？
还有比如我们赋予初始的 money 很少，可以加速一些 破产 的情况出现，从而淘汰一部分人；如果初始的 money 很高，相当于某种形式的 高福利 社会，它的未来走向是什么？在有限的时间内，其实很难判断鹰鸽哪派的策略更有价值。
又比如说，增加 交锋次数，会导致结果 鸽派化；而减少交锋次数，又会导致结果的 鹰派化。
简而言之，里面的参数，看似很严谨，其实有太高的弹性了。
上一段，我们说到数据不可靠的问题，即便如此，如将非常多次的结果进行汇总，形成很多张图表，那么，这个成果呈现的时候，会显得非常专业，甚至是复杂的。
这种专业，是依赖于一些非常简单的代码实现，没有特殊的算法，一些参数也是主观设定的。简而言之，这个复杂 的结果，是建立在非常简单的逻辑之上。
我们要看见一些简单的规则，在代码中复合之后产生的力量；同时，也要看见它们的局限性。一些随意给定的参数，本身是可以根据人类历史这么长时间发展积累下来的数据，推断出来的。
而 定义人类 的 class 也太简单，为了最终结果的精准，人类 应该要有更复杂的一面。两两博弈的过程，考虑的因素也应该更多；两者之间的财富分配的规则应该更细腻；每次创造出多少的财富，这个数值应该也能从人类历史中概括并推算出来；人的一生中平均有多少次交锋应该也是可以根据当下社会实际而推演出来的。
两两博弈的遭遇过程，应该有更高阶的算法来实现，来模拟真实社会的遭遇。我们只用了最简单的方法进行模拟。
当我们用简单实现了复杂的时候，不要丢掉敬畏心。
实现的本身有局限，复杂过度之后，我们就会失去控制的能力。
如果你的附近有科技馆，且有 混沌摆 的实物，可以去看看；又或者你看过《三体》，产生过一些特殊的感触。或许也就更能理解上一段提到的 数据是不可靠 了。
有些时候，我们选择 简单，因为它是可控的。当你觉得还需要去掌控复杂时，一方面可能真的没有必要，二方面则可能是我们根本不具备这样的能力。
有没有发现，鹰鸽博弈 在用代码实现的过程中，起始的 idea 是简单的，只是宏观地描述鹰鸽 的不同表现而已。
而要模拟这个博弈的最终结果，我们在没有动代码之前，就在脑海中反复思考 用代码怎么写 的问题，在思考这个问题的同时，还定义了好些规则，这时可能仍然一行代码都没有敲下。
提出一个 idea 通常会成为一个产品经理的事情，但这个 idea 要实现，又非常麻烦。最终实现之后，再去反推产品经理存在的价值，就变得有意思了。会陷入一种可是可非的状态，像一只薛定谔的猫。
说他的 idea 重要吧，确实重要，因为后续的工作，是在这个基础上扩展开来的。说他的 idea 不重要吧，也确实不重要，一个 idea 上的产品实现，其后续的工作量非常大，实现初期的工作量通常更是无限倍增的；另外还有一个原因，很多 idea 虽然 先于其它 出现，但只要在一个产品的思路上持续性的思考，类似的 idea 总是会陆续出现的，面向产品的 idea 的独创性，并没有想象中那般高。
当我们提到 产品经理算什么东西 的时候，不要在这个表述中增加情感性的倾向。
如果我们自己是产品经理，应该要保持足够的敬畏，一个 idea、原型图 会带来倍增的后续工作，那有没有可能在这个过程中，增加对后续工作的预判从而及时预先调整以避免浪费呢？甚至，有没有可能自己直接去掌握技术的力量，从而更有能力去实现自己的 idea。
同样的，如果我们自己是程序员，也同样要保持足够的敬畏。一个产品的代码实现，可能并不需要太复杂的算法，保持简单的逻辑就足够了。既然工作量倍增的现实无法逃避，就要有倾向地避免代码膨胀的潜在可能。也同样的，一个 idea 的诞生，并没有多了不起，何不自己再往前走一步，去获得自己的 idea 呢？
首先说说 Python 的性能问题，比如模拟了 50w 次交锋，大概花了 3秒 的时间。50w 的这个量级，对于真正的大数据而言，又是很简单逻辑计算， 3秒 是很慢的……
而真正的产品中，这种对于性能有极其严苛的要求，是不多见的。所以，Python 的性能问题，多数时候是伪命题，真正遇到了，就换一种技术方案，并不局限于 Python 这一门语言。同样的，比如说 Golang 的并发能力是 Python 比不过的，对于高并发的场景下， Golang 是更好的选择。但是，高 到多少才算 高，作为初学者，就先认定自己是没有资格做出这个判断的，因为，我们此时的判断，通常离错误很近。
『Python 的性能跑不起来、Python 没有办法做并发』，把 Python 换成其它语言 (甚至是 PHP)，也是一样的，这些都是误解。通过贬低某些事物，以达成一种浮于表面的骄傲，并不是很好；真正产生性能问题的，大多是写代码的人，如果因为自己的弱，最后还要归咎于手中的工具，就有些不妥当了。
至于其它 代码上 的总结，我们都还没有开始写代码，就没有什么好总结的。
反正，代码的逻辑，铺开来应该都是能理解的。
如果有什么语法是之前自己没有遇到过的， 就使用搜索引擎了解。没有必要等到所有语法全部掌握了，才能开始写代码。
凡是程序，就会有 bug。
有些 bug 是致命的，并且会导致整个程序挂掉；有些 bug 是无所谓的小细节，但也可能会导致整个程序挂掉。
而有些导致程序挂掉的 bug 反而是好的 bug，起码让我们发现了问题所在；而有些让程序继续运行的 bug，却是糟糕的，可能导致一些不可挽回的损失产生。
我们要多一些些敬畏。
我们总是会写下很多 bug，有些简单到不会出 bug 的地方，也可能会出问题。比如读写文件，将内容写入文件，总是很简单的；但是会因为文件的写权限受限，可能出错，甚至因为磁盘(硬盘)满了，而无法写入……
我们在 鹰鸽博弈 的模拟代码中，有一个明显的 bug。
引入了 5% 的突变概率，即使两个鸽子遭遇了，突变之后 (就是一只鸽子突然采用了鹰的策略)，会导致一个人获得所有收益，而另外一个人获益为 0，并且倒贴押金。
在这种情况下，突变成鹰的，虽然获得了更多的收益，但因为是变成鹰才获得的收益，那么，他以后应该变得更凶猛一些，也就是鸽系数 会降低；而另外收益归零的鸽，会认为自己当下采用鸽策略是错误的，那么也会导致鸽系数的降低。简单来说，就是两个人的鸽系数都会降低。
实际的代码中，没有针对这种情况特殊处理，只是单纯的认为，一个鸽子赢了，系数 增加，而另一个输了，则降低。这里就出现了 bug ...
鹰鸽博弈 用这种简单的方式模拟出来，不过为了化解自己内心的困惑而已。
仁智各见，真正的 总结，我没法给出。
如果一定有，或许就是 认怂 吧。吃掉一些情绪，这是理性的做法，让人生尽可能不在毫无意义的地方浪费生命。