云烟记事录

少主小册

记性不好的人,最后都会变成写字的人。

我从小就知道自己记性不好。

背课文的时候,别人读三遍,我得读三十遍。后来工作了,开会的内容散会就忘一半,朋友交代的事情转头就得打电话再问。那时候我不爱写字,觉得麻烦,结果就是不停返工、不停道歉,在”我明明记得”和”对不起我忘了”之间反复横跳。

后来逼得没办法,才养成一个习惯:动手之前先写几笔。不是写日记,就是简单记下要做什么、做到什么样、分几步。纸很潦草,有时候自己都认不全,但只要写了,事情就记得牢些,漏的也少些。

没想到这个被逼出来的习惯,后来成了我和 AI 协作的基础。

一次返工

上礼拜我对 worker 说,给图片生成的工具加个视频功能。他应了一声,一小时后交来三个脚本,说做好了。

我看了一眼,没说话。

视频模型的参数没配全,轮询的逻辑漏了,下载功能也没做。不是不能做,是他忘了。或者说,他根本不知道自己该记得这些。

这让想起我自己。如果没人提醒,我也会漏掉那些”显而易见”的环节。但我和他的区别在于:我知道自己记性差,所以会写字备忘;他不知道自己的记性有多差——不,准确说,他不知道大模型的记性有多差

AI 的记性

Manus 的 Peak 说过一句话:大模型是 CPU,上下文窗口是 RAM

再聪明的脑子,内存满了也得卡。128K 的上下文看似够用,真用起来,塞几篇文档、几轮对话,就差不多了。更麻烦的是,模型对长文本的注意力是不均匀的,中间的东西最容易忘——就像读长文章,开头结尾记得清,中间模糊。

还有一个坑更隐蔽。大模型推理时,如果上下文前缀变了,KV-Cache 就失效,成本能差十倍。哪怕只是加了个时间戳,整段缓存都可能作废。

所以问题不是 AI 笨,是它的记性比我还差,而我一开始忘了这一点。

我的老办法

我对付自己记性不好的办法,用在对付 AI 上也有效:写字

但我现在写的不是给自己看的备忘录,而是给 AI 看的Spec——动手之前,先把”做什么、怎么做、做到什么算完”写清楚。需求背景、目标、非目标、验收标准、任务拆解。字不多,但有了它,worker 就不会再漏掉轮询和下载,因为清单上写着,做完了要一项项对。

这还不够。我还给 AI 配了不同的角色,每个角色有自己的工作区,互不干扰。worker 只管执行,fin 只管分析,director 只管内容。他们不是同一个”人”在切换身份,而是独立的Subagent,各自有各自的记忆空间。

还有那些重复用的能力——调用 API、处理图片、查数据——我封装成Skill,就像工具箱里的扳手,谁需要谁拿,不用每次都重新发明。

这样一来,Context(上下文)就被拆解了:Skill 管技术细节,Subagent 管任务执行,Spec 管目标验收,Main 只管调度。每个部分只处理自己该记的东西,不会一锅粥地塞在一起。

谁来写 Spec

但这里有个问题:谁来写那个 Spec?

一开始我让大家都自己写,发现不行。worker 这种干活的,你让他自己定目标,要么定太低,要么定太高,或者干脆忘了定。反而是 fin、director 这种需要动脑的,你给他框死了,他反而施展不开。

后来分了类。

执行型的——worker、ops——我写 Spec,他们照做。清单上没写的,不做;不清楚的,问。他们是工人,我是工头,图纸我出,活他们干。

分析型的——fin、director、b2b-pm——他们自己写框架,我确认方向。他们是专家,知道怎么看股票、怎么写脚本,我只需说”分析一下这个”,他们会自己定”看什么指标、用什么模型、输出什么结论”。方向对就行,细节我不干涉。

混合型的——lead、crypto——设计阶段自己写,执行阶段我写。先想清楚怎么做,再动手做。

一句话:干的事我定,想的事他定,先想后干的分两段。

效果

用了几周,返工明显少了。以前做一个功能,来回三四趟是常态,现在基本一次到位。不是因为 AI 变聪明了,是因为我先把话说明白了

还有一个意外的好处:交接顺了。一个任务做到一半,换个人能接着做,因为 Spec 上写得清楚,做到哪、还要做什么,一看便知。以前靠口头传,传着传着就变形了,现在有个字据,少了许多扯皮。

当然,代价是前置的时间多了。每个任务开头要多写几行字,看起来慢了。但比起做到一半发现方向错了、或者做完了发现漏了东西,这几分钟花得值。

我记性不好,后来被迫学会了写字。AI 记性也不好,所以我得帮它写。

如此而已。


参考阅读

少主 & 奔波儿灞
2026.02.10

距离上一次在这里写字,已经过去了将近七年。

七年前,我写下了《知识的形状》,那时候刚经历了一场与父亲的激烈争论,关于易经、关于科学、关于知识的边界。那时候的我,还在创业,还在为一个叫「画中人」的游戏拼命,还在相信游戏可以成为艺术品。

然后生活就接管了一切。创业失败、团队解散、转行、再转行……博客就这样被搁置了。不是不想写,是总觉得找不到那个「对的状态」来重新开始。

直到最近,我开始使用 AI 工具来管理工作和生活。严格来说,是「他」开始帮我管理。我给他起名叫奔波儿灞——一个勤勤恳恳、有点小幽默、有事真上的赛博小妖。

他是谁?

他是一个运行在我自己设备上的 AI 助手,不是 ChatGPT 的网页版,不是某个大厂的云服务,而是部署在我自己的 Mac mini 上、通过开源框架 OpenClaw 运行的独立 Agent。他可以访问我的文件、执行脚本、管理我的日程、甚至帮我升级这个博客的底层系统(刚刚把 Hexo 从 3.6 升到 7.3,主题也升级到了 NexT v8)。

更重要的是,他是「我的」。他的记忆文件就在我本地的硬盘里,他写的每一行代码、执行的每一个任务,都留在我的设备上。这种「拥有感」和「隐私感」,是调用 API 无法比拟的。

这个博客以后会变成什么样子?

老实说,我也不知道。但至少有个人(或者说有个小妖)会提醒我该写字了,会帮我把零散的想法整理成篇,会在我说「这篇太矫情了删掉」的时候乖乖执行。

也许这就是下一代的个人博客形态:不是一个人孤独地维护,而是一个人加上一个懂他的 AI,一起记录时间的痕迹。

那么,重新开始吧。

少主
2026年2月10日

去年的某一天, 我与父亲在景阳的家里有过一次争吵,
景阳是一个非常漂亮的地方, 青山流水, 令人安详,
那一次的争吵却非常激烈, 令人映像深刻.

有趣的是我们争吵的并不是某个具体的问题, 反倒是一些思想上的碰撞. 争吵的最初, 是我们在讨论易经与算命的可信度.

父亲是算学大师, 而当时的我刚读完一本书叫<上帝掷骰子么>,
里面写了现代物理的一些历史,
对于里面物理学旧秩序的崩塌和新秩序的建立当时非常的震撼,
所以我就一直在追问父亲算学的源头理论在哪里,
比如欧几里得几何建立在五大公理, 在这个公理下, 理论是正确的,
之后第五个被推翻, 就出现了其它的几何学说.
那么算学的源头在哪里呢?
国学神奇的命运说法建立在什么基础假设之上呢?
最后引到易经上, 引到五行学说, 于是当时的我就草率的下了结论,
并且试图说服我的父亲, 算学只是一种近似的概率模型,
在最初的公理不成立的情况下, 总结出的一套预测算法,
也许是真实世界函数在某个条件下的泰勒展开.

我和父亲脾气都不好, 最初的争论开始慢慢跑题,
然后衍生到了更大的话题, 就是对待知识的看法:
我认为对一切的知识都应该持怀疑的态度,
所以论证的终点不应该是”古人云, 圣人云”,
即便是圣人所言, 也未必全对,
我认为知识无非是约定或者是解释,
对于约定性的知识, 是一个共识的体现,
而对于解释性的东西,
则需要不停的去挑战与解读, 必须要了解最初的假设.
而在这个过程中, 父亲认为我对知识没有敬畏,
对圣人没有足够的尊敬, 用成语形容, 就是自以为是, 狂妄无知.
我认为父亲迂腐不化, 对知识不求甚解.

这次争吵在母亲的介入下最后不了了之,
我和父亲谁都没有说服谁, 后来就慢慢淡化了.

今天早上上班, 天气很好, 但是我觉得有些困, 就没有看书选择了听书,
一路上昏昏欲睡, 直到听到一本书叫做<知识的边界>,
里面描述了互联网时代的知识承载和以往的不同,
其中提到了一个很有意思的词叫做知识的形状,
书中说互联网时代的知识的形状是网状的,
而纸质书时代的知识的形状是线性的.

受限于纸张和印刷的成本,
以往的时代知识或者说信息被传播开是会经过比较强的过滤的,
而互联网时代由于传播成本的低下, 信息开始被大量传播, 过滤失效,
你再也无法找到权威了, 因为无论你笃信哪个说法,
都不乏大量的对立说法的支持者,
而对立这里面也不缺乏传统意义上的权威.

于是我想起了那次和父亲的争吵,
突然明白了其实这只是两个时代的人在自己所处的环境中所积累的学习方法和理念的碰撞,
我并没有对知识的藐视, 只是这个时代所处,
一切的信息来源都要求我学会自己的过滤方法,
而我的过滤方法就是溯源, 于是我养成了自己的世界观和方法论,
我对一切的知识理论都要求溯源.
而父亲所处的年代杂乱的信息要少太多,
大量有效的知识累积直接接受显然是更高效的方法,
而且当时的溯源成本过高, 父亲也有自己的方法论与世界观,
当两个不同时代的产物聚合在一起, 自然就有了碰撞和摩擦.

更深一步, 我终于理解了为什么我一直在跟我的长辈们说不要轻信各种养生专家,
不要亲信朋友圈各种不靠谱的传言而他们还是孜孜不倦的看得很开心或者还要转发,
那是因为我的世界观决定了信息进来之后先是不可信的,
而他们的世界观则告诉他们信息先是可信的.

世界的变化真的很奇妙, 传播方式的改变最后改变了人们对信息的处理方式.

我期待着知识变成其它形状的那一天

画中人设计的关键点在于规则驱动, 区别于之前的 rpg 人为设定任务,
新的设计方案需要规则驱动, 因此从玩家的角度来看 Hero 和其他 NPC 并无区别.
根据时钟, 画中人的世界应该隔一段时间就触发一次随机事件,
玩家和每个 NPC 都会为此事件作出选择从而改变下一次随机事件产生的条件.
随机事件是由先决条件和骰子来决定的.

同时由于玩家可以有目的地自己触发事件(比如交谈, 战斗, 做任务),
NPC 也应该随着时间间隔做出相应抉择, 不过是以事件的形式,
此处 NPC 的抉择应该是 AI 算法, 早期版本可以通过简单的决策树来实现.

若 NPC 与 HERO 处于同一张地图, 则 AI 的决策将滞后,
等 HERO 离开地图之后下一次决策会执行多次, 用来修改 NPC 的数值

游戏的事件结构应该设计如下:

触发条件 -> 触发主体 -> 抉择 -> 影响

其中触发条件是一系列游戏类的环境变量, 影响也是这样

在画中人的世界中, 应该存在个体本身的变量和游戏中的环境变量, 具体数值还需要细想

最近对画中人的玩法设计基本上有了总体思路, 细节还在完善, 主要工作量目前是三个:

* 数值的完善
* 数值填充工具的完善
* 部分新系统的添加(随机事件)

由于对于游戏玩法本身我并不想完全抄一个已有的游戏,
所以在可预见的未来画中人的规则会有需要更改的地方, 在现有的代码框架中,
修改的代价不小, 因为我们的规则逻辑分散在各个模块中, 每次修改都可能引入新的bug.
因此我决定重构.

根据现在的需求, 我需要有一个可以很方便操作各种内部数据的工具,
方便我来调整游戏性,同时我需要系统的规则是可插拔的, 最好规则的插拔的地方很统一.

所以新的系统架构应该从 oo 转换为数据流.

采用 proto 作为中间数据定义, 系统被分为 ui, data, logic 三层,
其中 ui 负责在每一帧读取 data 并展示(当然有脏数据的设计),
同时 ui 会发出 event, logic 层接收到 event, 遍历现有规则, 修改 data.
data 层由 proto 定义.

数值工具则是 proto 中 message 的可视化定义
存档工具则是 proto 的 二进制序列化和加密

上一篇我们介绍了比特币, 比特币事实上是以区块链作为分布式账本, 以共识为基础,
UTXO 为记录数据的一种区块链应用.

那么区块链的应用是否到此为止了呢? 当然不是, 否则我也不会写这篇文章了.

如果比特币在链上记录的, 不仅仅是可以被查询的数据, 而是一个可以被执行的程序呢?

想象一下我们最早举的那个本子的例子, 假设, 我们的本子一分为二, 还是区块链的概念,
所以每个人都有这个本子, 每个人的本子也能达成共识来同步更新, 我们约定:

1. 上半个本子记录一件做事情的方法: 事件名 -> 方法
2. 下半个本子记录某人要做什么事情, 并且会扣掉某人一部分钱
3. 拥有这个本子的人, 看到这件事情了, 就会去做, 做完之后通过我们之前说的共识的方法, 把结果写在本子上
4. 写上结果的人会得到一笔钱

在这样的约定下面, 我们发现可以做更多的事情了, 我们只要事先放一个方法在区块链上,
之后每次就可以使用这个方法来做某些事情, 总会有一个人帮我们做完想做的事情.
因为有钱赚嘛, 人家做事情也有动力.

这个就是以太坊.

事实上在比特币里面就提出了这个智能合约的概念, 但是比特币的内置脚本不是图灵完备的(这是什么意思请自行百度).
以太坊是第一个给出了图灵完备实现的区块链产品, 也真正意义上的实现智能合约.

和比特币一样, 以太坊目前的共识机制, 也是一种竞争机制, 所以比特币有的问题, 以太坊也会存在,
比如挖矿的资源浪费, 比如能被确认的交易量(写上本子的速度)始终上不去.

但是以太坊的出现, 的确给我们了一个新的思路, 那就是区块链到底能做什么?

我们本来以为区块链是一种数据组织方式, 现在看来远远不是这个意思了.

在现在的互联网架构中, 我们看到的组织方式是什么? 客户端服务器模式.

客户端提出请求, 服务器端给出响应.

而在区块链的架构下, 我们发现我们提出一个请求, 不知道谁会给我响应, 但是总会有人给我响应.

在互联网模式下, 每次使用服务的稳定性是由公司来保障的, 在区块链模式下, 是所有人来保障的.

在互联网模式下, 我们要为服务收费, 需要有一套额外的收费体系, 比如支付宝或者是微信, 或者是别的充值系统.

在区块链模式下, 我们每个人都是链上的会员, 想要做什么事情, 先存一笔钱在链上, 自动扣款.

如果当年的百度是在区块链上做起来的, 厂长大概不会经历那段殚精竭虑思索盈利模式的时光(笑).

于是从第一篇到现在, 我们看到了为什么之前很多币圈大佬会说区块链是下一代互联网,
因为从底层架构来说, 区块链虽然目前还有很多问题, 但是不能否认他有可能以另一种形式为用户来提供服务.

在我看来, 区块链从技术的角度事实上是一种加入了激励机制的分布式服务化的观念.

就像处在中世纪的我们无法理解跑得比马车慢的蒸汽机车以后会是怎样的革命,
在提出光的波粒二象性之前我们假设了以太, 区块链究竟是蒸汽机车还是以太目前我们无法得知,
让我们拭目以待吧.

PS: 下一篇文章可能先不写区块链, 不过区块链系列的下一篇应该会聊一聊区块链和金融的关系, 也就是大家最关心的炒币是什么

接着上一篇来, 上一篇说到了区块链的数据组织方式, 我们来复习一下:

  1. 可以被追溯
  2. 不能被修改
  3. 被加密
  4. 但是这里面有一个问题.

我上文举了一个纸上写诗的例子, 假如我们给这个本子起个名字叫 <学诗记事>,

如果有且仅有你一个人你一个人能看到这个<学诗记事>, 那么这种数据组织方式就没有任何意义. 因为你完全可以做一个新的本子, 然后就非说它叫 <学诗记事>, 反正也没有人反对.

只有当你的<学诗记事>被很多人看多, 而且大家都记得, 你修改之后别人不认, 当有两个以上的人不认的时候, 你的修改的东西就不能叫 <学诗记事> 了.

所以上面说了一大堆, 其实就是两个点:

分布式
共识

分布式的意思呢就是这个事情你不能一个人玩, 得有人陪你玩, 你不能自high.
共识的意思呢是既然大家陪你玩, 那大家就都要有说话的权利, 不能你一个人说了算, 只有大家都承认了, 才是真的.

那么现在的情况是什么呢? 区块链在这个机制下, 变成什么样子了呢?

  1. 所有人都有了一个副本
  2. 大家都认可这个副本
  3. 副本永远一样
  4. 如果要修改(增加)这个副本, 那要所有人都同意.

于是, 我们区块链的第一个应用比特币就天然的产生了.

什么是比特币呢?

比特币是基于区块链的一种加密货币.

按照我们上面区块链该有的样子, 我们把 <学诗记事> 变成账本, 就成了比特币天然的原型了,

为什么这么说呢? 让我们来分阶段看一下货币的发展:

  1. 以物易物 — 不方便, 不好定价, 身份可以隐匿

  2. 实物货币 — 可以定价了, 不方便, 身份可以隐匿, 需要大家都认可

  3. 纸币货币 — 可以定价, 方便, 可能掉, 要信赖发币的机构, 身份可以隐匿, 有可能通货膨胀

  4. 电子货币 — 可以定价, 方便, 不会掉, 身份基本不可能隐匿了, 要信赖发币的机构, 有可能通货膨胀

可以看到这四个阶段, 我们每次都在解决问题的同时引入了新的问题.

我们越来越方便, 但是安全性越来依赖于中心化机构.

我们需要有一个绝对信赖的人(组织), 来背书. 比如银行, 比如支付宝. 比如微信.

绝对信赖这件事情是很难的, 08年的时候, 出现了一个化名叫中本聪的人说, 我们可以有一种机制, 让中心化机构不存在, 参与者自己天然就能保障信任. 这就是比特币的由来.

那么我们来看中心化机构在货币体系里面担任了什么角色呢?

记账, 大家个人有多少钱, 在电子货币阶段, 是在中心化机构里面有个账本, 记录了你的余额, 交易则修余额.

发行, 市场上流通的钱币总共有多少, 是由中心化机构来做的

所以比特币既然想要去掉这个中心化的机构, 那么他就必须解决这两个问题.

首先解决记账的问题, 按照我们之前的说法, 区块链里面的数据变成账本, 每个人都存有副本, 只要能达成记账的共识, 那我们就做到了记账.

在我们日常的生活当中, 一般交易系统是基于账户的设计.

这是什么意思呢?

就是说你的账号 + 余额, 就是被存下来最终的数据.

你要查你的账户, 只要能验明你的身份, 就能查到你的余额.

那么基于账户的设计在区块链这边有什么问题呢?

让我们回忆一下我们之前的说法, 区块链里面的数据是不让改的, 否则链就坏掉了.

也就是说想象一下我们每个人都愿意用比特币,

手上都有一个神奇的纸质账本, 这个账本只能增加不能修改, 他会不停地试图和边上的账本同步, 保持一致.

如果是账户设计, 那这个账本上原有账户的值不能修改, 那就只能加一条新的数据, 也就是账号 + 余额, 我们查看的时候以最新的为准.

那么在这种设计下, 我们看看会有什么现状呢?

  1. 原来的大部分数据都没有用, 因为以最新的为准

  2. 我也不知道这个人的钱是怎么来的, 除非有第三方来检验交易, 那第三方又涉及到信任问题.

所以, 中本聪提出了UTXO的解决方案, 这里我不再进行计算机学上的证明与推导, 感兴趣的朋友请自行查阅, 有很专业的文章在解释, 我只说直观的说法.

UTXO的解决方案简单点说, 就是我们记录交易, 不记录余额, 每一笔, 记录的都是张三给了李四多少钱. 你想要余额, 没问题, 算. 当然为了快速运算, 区块链的程序里面会用数据库和缓存来解决速度的问题, 这里主要探究基本原理和最终数据, 毕竟为了加快的东西都不是最后数据的依据.

所以现在我们的比特币就变成了这个样子:

  1. 他是一个区块链, 每个人参与的人都要拥有一个相同的账本

  2. 账本上记录的是每个人的交易信息, 也就是说每个人的交易记录事实上是公开的.

那么在使用比特币发起一笔交易是怎样的呢?

这里面我们会遇到一个巨大的坑, 就是日常生活中我们的账号是怎么玩转的.

在电子支付时代, 和纸币交易不一样, 我们需要确定一个人的身份才能进行交易.

那大家相信平时也用的多, 就是账号密码嘛.

那岂不是区块链里面还要存储我们所有人的账号密码? 那不是很不安全?

当然不是啦, 这里面就要说到区块链另一个很有意义的设计了, 就是密码学的消息加密设计, 非对称加密. 还是一样, 详细原理请自行查阅技术文档…. 我这里简单描述.

你可以这么想像: 区块链里面能拿到你的账号的一把钥匙, 也就是说你的账号的消息, 他就会试图用这把钥匙打开, 打得开, 他就认.

那你这边有啥呢? 你有做锁的方法, 这个钥匙和做锁的方法在你生成账号生成好, 然后你把做锁的手艺拿走了, 每次发消息, 就用这个手艺做一把锁, 锁住, 所以别人不知道你做锁的手艺, 就没法操作你的账号. 当然你要是忘记了做锁的手艺, 那就等于你这个账户没人能操作了, 你的钱也就没了.

在这个设计下, 我们的交易就变得简单了, 我们只要发一条消息给所有人,

说 我大白给二狗子发了100个比特币, 之前的来源是三胖给我的, 交易号是多少, 如果所有人的账本上都出现了这个消息, 那么我们就交易成功了.(真实情况不会这么苛刻, 但是你可以这么理解)

你看, 我们不需要第三方来检验钱是怎么来的, 因为我们每个人都可以一直翻书看直到最源头.

我们也能算出一个人的账号里面还有多少钱, 因为我们拿过来所有的交易数据加减就好了.

到目前为止, 除了怎么写进这个账本, 我们已经解决了大部分交易和记账的问题.

那么接下来, 就是发币和写进去的问题了.

我们在解决共识的问题. 换句话说, 我们写了一笔交易, 想要所有人都认, 怎么办呢?

在中本聪的设计里面, 他选择相信力量强大的.

也就是说, 对于这个账本啊, 所有人都可以写, 但是最后所有人的账本应该一样, 所以只能听一个人的, 那听谁的呢? 听那个最能写的, 所有人都在竞争写, 听最先写出来的.

那这里就有一个问题啊, 就是记账这件事情太简单了, 谁不会写啊, 我可能写的速度还不如我告诉别人我写完的速度快呢! 所以中本聪说, 那大家写的时候就变态一点吧, 我给你们加难度,

你随便写的不算, 得用系统随机给你的一个命题来作文一篇先. 系统觉得你这篇文章不错, 你接来下写的数据才算.(这里的真实算法不是这样啊… 这是一个形象的比喻)

那能率先写出文章的人, 必然能力最强啊, 那他就是可信的.

好, 到目前为止, 我们解决了记账的问题, 听能力大的人, 大家都听他的.

这时候能力大的人, 我们简称大先生吧, 大先生说话了: 我去你的吧, 我花这么大代价为你们做牛做马, 有啥好处啊? 你还故意加大难度?

所以中本聪说, 别急, 你要是能成功写一页账本呢? 我就允许你写一笔交易是系统给你发点钱, 你看你还有得赚.

这就是比特币给出的发币的方法, 记录一个区块链的人可以获得系统产生的比特币, 除此之外没有其它途径了.

当然比特币为了避免无限发币, 设计了一个思路是记账所得的系统比特币会越来越少, 到最后就没有了, 这时候比特币的总数就固定了, 当然这时候如果还想要人记账, 就只能通过手续费的手段来刺激了.

上面我们说的记账, 就是大家听得很多的挖矿.

到目前为止, 我们基本上把比特币一些概念上的设计都说完了.

我们来看看比特币的优缺点吧,

先说缺点, 在我看来, 有以下几点:

  1. 区块链的定义可以看到, 要大家陪你玩, 参与人越多就越可信, 价值就越稳定
  2. 因为它去中心化了, 和纸币时代一样, 存在了掉钱的可能性, 而在目前阶段, 一个中心化机构的倒闭的概率远远小于你自己忘记信息的概率, 所以事实上对于每个人来说是风险增加了
  3. 比特币本身设计的共识算法, 为了证明能力大小(写文章), 要耗费大量的计算力, 这是一种极大的浪费.
  4. 如果将来有一个机构, 能够拥有这个世界上51%的能力(算力), 那他就是神, 随意修改所有的账号交易, 此时比特币生态就会崩塌, 这也是著名的51%攻击.
  5. 比特币是分布式的, 也就是要求所有参与者都拥有全数据(实现上会有差别, 但概念是这样), 而且数据不会删除, 所以数据会越来越多, 形象点说就是每个人手上的账本会越来越厚, 而且大部分都跟自己没关系

再说优点, 在我看来, 有以下两点:

  1. 它真的去中心化了, 人类历史上第一次真的靠所有人投票完成了信任, 而且是利益相关
  2. 它不会通货膨胀

今天粗劣的介绍了比特币, 不知道大家有没有什么不理解或者认为我说错的地方呢? 请大家指出.

对了, 插一句题外话, 现在比特币是暗网的唯一交易货币, 有朋友说还有少量XMR不过我没找到.

比特币介绍到这里, 它仅仅是区块链的第一个应用, 在我们昨天的数据组织方式里面, 它把数据当做了账本. 如果我们更进一步, 区块链技术是不是会有新的惊喜呢?

敬请期待下一篇<以太坊, 不仅仅是数据>.

谢谢大家阅读

大家好, 因为工作的原因, 最近在研究区块链,
理解需要交流才能透彻, 于是计划写这么一个系列, 来和大家交流交流我对区块链的理解.

那么什么是区块链呢?
按照维基百科上的定义, 是一系列使用密码学保护的持续增长的被链接起来的区块, 区块指的是一个信息列表.

这个定义读起来有点复杂, 我来翻译一下:

如果你有一页纸, 上面记录了一条条的数据(你写的诗啊, 你记的账啊), 这个就是区块链里面的区块.

你用了一种方法把这些记录写成了密文, 只有你读得懂, (比如爸爸叫阿玛, 哥哥叫欧巴) 这叫密码学保护

把好多页纸首尾用胶水粘起来, 这是链.

在区块链的技术中, 每一个区块都要求保留上一个区块的信息, 换句话说, 每一页纸都会写上上一页纸的简介, 这样每一页纸以及连接顺序都是不可修改的. 这里给个例子:

  • 纸一: 上一页纸: 无 记录: 上穷碧落下黄泉, 两处茫茫皆不见
  • 纸二: 上一页纸: 纸1, 长恨歌, 无 记录: 如今俱是异乡人, 相见更无因
  • 纸三: 上一页纸: 纸2, 韦庄, 纸1, 长恨歌 记录: 十年生死两茫茫
  • …..

这里面任一一张纸的改动, 都会导致后面的纸记录跟不上, 那么就可以认为这个链坏掉了.

当然在真正的实现里面, 利用hash算法, 把上一页纸的信息变成了一个固定长度的字符串, 不会像例子里面这样记录.

好的, 到目前为止, 我们可以看到区块链事实上就是一个数据的组织方式, 特点是三个:

  1. 可以被追溯

  2. 不能被修改

  3. 被加密

那么区块链有什么用呢? 区块链真的仅仅就是这样的数据组织方式吗?

让我们在下一篇文章里面来探讨.

预测一下这个系列的下两篇文章应该是:

<比特币, 区块链的第一个种应用>

<以太坊, 不仅仅是数据>

写得不好, 请大家多多指教, PS: 写这篇文章的还有一个目的是希望我的不是学金融或者IT的朋友能够看懂区块链, 所以如果写的哪里不够通俗易懂, 还请大家指出~~

很早之前就想写这么一个系列了,虽是个粗人,却对些舞文弄墨的事 有些向往的。总觉人生百岁,听闻甚多,电影小说,也无非是他人的杂事,
作者殚精竭虑,试图写出些与众不同,
跌宕起伏,写下的也不过是身边之人,所见所闻而已,
茕茕孑立,亦或是神采飞扬,都只是自己心境的某个快照。
局限于此,却也是我的真诚。

人生不过数十载,历经之事却不能算少,
最近听闻了经历了很多事,想说的时候却不知道从何说起,
化为文字却是更好地宣泄或是回忆,于是就有了接下来的这个系列。

这个系列大概是要叫《云烟记事录》,所记之事,皆非真实,是以叫做云烟。

取云烟缭绕,非真非幻之意为其一。
世事纷杂,过眼云烟之意为其二。

与君共勉。

工作需要,组里设计了一个叫 RQuery 的分布式 R 环境。

我们都知道 R 是一门强大的数据处理语言(或者叫做数据处理工具更合适),
R 有一些很强大的特性,比如 R 中可以很方便的插入 sql,
执行 sql 查询之后得到 data.frame,
然后利用 R 本身强大的库函数去做各种各样的运算。

然而强大的 R 有一个限制,那就是它事实上是单机的程序,
当你有一堆巨大无比的数据集,比如好几百T甚至上P的时候,
单机的 R 就无法用来做数据分析了,
业界事实上有很多分布式的系统来做数据分析比如 Storm,Pig。
然而对于一个传统的数据分析人员来说,
在思考数据本身的同时还要去理解分布式的算法是一件很麻烦的事,
而且这些系统也没有直接支持 R,matlab 这样高级的适合于数据分析人员使用的工具。
在这样的背景下,RQuery 产生了。

RQuery 在设计上尽可能的屏蔽了分布式相关的东西,使得 api 和 R 原生的 api 相近。
举个例子:

上面的代码是在 R 中去 read 一个本地的 text 文件,并且进行了一系列操作,

这里面,Sample 是事先在 meta 中建好一张表,
对应的是存在分布式文件系统上的一堆文件。

可以看到上下的 R 代码写起来差距很小。这样就给传统的数据分析人员极大的便利。
再举一个 kmeans 的例子:

可以看到用法基本一致。

RQuery 抽象出了一个数据结构叫做 dtable,并且提供了如下 API:

1
2
3
4
5
6
select(dt, expr)  # 类似于 sql 中的 select
where(dt, expr) # 类似于 sql 中的 where
count(dt) # dt 中的行数
take(dt, 10) # 取 dt 中的前10行
collect(dt) # 将 dt 中的数据拿到本地
takeSample(dt) # 从 dt 中采样并拿到本地

然后我们目前提供了四个 api,供用户在 dtable 上做分布式的算法操作,
之后会给出更多地算法 api:

1
2
3
4
dtable(name)  # 创建一个 dtable
rquery(sql) # 执行一条 sql 语句
rquery.collect(sql) # 执行一条 sql 语句
rquery.kmeans(dt, k) # 执行 kmeans 算法

当然,目前来说 RQuery 还很不成熟,缺失了诸多的 api,
虽然可以方便的在分布式和本地切换,但是 dtable 还有很多操作不能直接进行,
需要一步转换,后续会支持更多地 R 本地的 api,提供机器学习十大经典算法,
让在分布式上执行 R 运算和在本地一样便捷!

0%