从今年年初开始，就不再写具体的博客，或者详细的笔记。只记录一些基本的、重要的细节。 GPT 的出现，让大部分的基础的技术记录不再重要，它能够很快的给你答案，甚至比你自己去查以前的笔记都要快。如果记录笔记的时间超过一年，如果这个知识点又事确定性的，比如某个知识怎么用。我可以确定问 GPT 的速度要远远高于去找以前的旧笔记。 如果事创意文字工作者，另当别论。

在好几年前给刚刚接触软件开发的一个同学讲 git 。边讲的过程边记录了文章末尾的一段命令。
于是让 AI 根据下面的内容生成一篇 blog。 生成的内容链接 写给初学者的 Git 极简教程
内容的部分除了添加了三个位置的引入，几乎没有做修改。如果是个人来写的话可能需要一个小时，并且文字描述没有那么完整。

我确信以后我们所看到的内容，大部分都是 AI 生成的。就像在刷短视频时大部分的视频都被滤镜修饰过一样。 那么我们需要的事丑陋但真实的世界，还是看上去美丽但是虚假的世界。这可能并不冲突。当需要追求根据真实时，我们会去探索真实。 但通常并不需要太真实。

大部分的内容输出，特别是具有确定性的，有很明确的步骤和方法的内容，不再需要我们写一篇博客和笔记来描述。多去记录那些不确定的内容吧。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#记住 git 的三个位置
本地目录   <--(cache)-->  .git   <----> remote 
              add #将代码添加到缓冲区  
              commit -->  #将代码提交到仓库
                        push  -> 推送到远程
                        pull  <- 从远程拉取
                        
git status # 查看当前git 的状态

git add . # 添加目录下所有变更
git commit -m "update" # 提交代码到仓库 update 为注释
git push origin master # 将代码推送到远程(origin)的 master 分支

git pull origin master # 从远处 mater 拉代码

# 理解 origin
origin 是远程地址的别名
git remote -v # 查看远程地址 

# 理解分支
master 一般为默认主分支

git checkout -b newbanch   # 创建一个名为 newbanch 的新分支，并切换到新分支

#一般我们开发会创建一个新分支修改，修改完成后在合并到主分支
git checkout master   # 将分支切换回 master分支
git merge daihuanhuan # 将daihuanhuan 分支修改的内容和 master 分支合并（上一步已经切换到了master）

科幻作家 Ted Chiang 在评价 ChatGPT 是网上所有文本的模糊图像，大模型对它的描述是对知识的压缩
大模型对大量的数据，这里的大量是指人类有史以来创建的所有文本（音频&视频）。把文本转换成一段向量，对向量进行 transformer 计算。最后得到一个模型。 模型里面记录的是什么呢？从数学上看，它是一堆的数字，或者是概率。如果把文本比作全部北京人的通勤数据，那么得到的模型就是每个路口的信息。在导航的情况下，我们是知道了每个路口的信息，然后从北京西站到西二旗。

有一部《别惹蚂蚁》的动画电影，如果在蚂蚁洞里没有方向，没有坐标。只知道蚂蚁的运动轨迹，需要怎么来确定最佳的路线呢。只要运动轨迹足够多，那么每个洞口的信息就足够清晰，这就是大模型干的事情，通过大量的输入确定某个点的的描述。 只要这样的描述足够多，那么我们就越接近真实。

印度的数学家拉马努金在数学上，给出了很多恒等式，而且很多等式在其他人看都是靠他的直觉来计算出来的。

在使用大模型的时候，大多数时候都是在寻找已经存在的知识，比如某段代码怎么写，某个文章怎么描述，我们期望找到好的题词，进而生成更加优秀的内容。

大模型通过向量，将知识映射到了多维空间，作为个人很难去理解多维空间，在科幻小说里可能会提到四维空间，比如三体：黑暗森林里面的女巫在四维空间里摘取三维空间人的大脑。星际穿越里，在四维空间里，能够看到不同三维时空。当维度升高时，事物之间的联系会变得千丝万缕。

我们生活在三维世界，理解三维世界。当维度升高时，世界就会变得我们无法理解。大模型是一个简陋的多维世界的描述，它通过多个维度，为所有存在的文字，创建了它们内在的联系。就像拉马努金脑袋里的数字之间的联系，要比我们普通人对数字的联系要多得多。

那么大模型除了是对知识的压缩外（向量空间里面的点），它还是对知识之间直觉（点和点组成的边）的描述。

知识在大模型里到底是有损还是无损的。前两天看到一篇文章，讲到大人和儿童的学习知识的方式，儿童很容易学会，而大人学习起来会很困难。里面提到人类的学习能力，其实是一种强化学习，随着年龄的增加，某些神经突触会被强化，变成一种本能的反应，当某些地方的连接被强化的同时，就会有某些地方的连接被弱化。而儿童的认知是白纸，任何的方向都很容易被强化，所以学习会比大人更加容易。

在学习一个新的知识的时候，比如大学的时候编程里面学习面相对象编程。“多态”这个名词对于新人来说是个新的名词。课本告诉我们多态是什么，其实我们是不能够理解的。甚至面向对象编程也是一个很模糊的概念，因为大学编程的实践非常的少。很难去理解这些概念，但是这并不妨碍编程的学习。

新的知识是对某个突触的强化，它是建立在现有知识里，并对现有知识的增强。从本身来说，知识被压缩到了某个点上，它是有损的。从全局来看，它又是对其他内容的扩充，它是不久是无损，而且还增加了新的内容。我们会通过旧知识来扩展和联想新知识，让点变成面。

在发现世界的规律时，当找到一个简单的规律，比如万有引力，如何通过一个简单的规律去发现更加复杂的规律，这可能才是大模型最终的能力，它不是有成百上千的直觉，而是上亿的直觉，通过这种亿级的直觉。 我们能够发现更多的规律。

三体里面宇宙社会学，如果在大模型世界里创建三条公理，能通过三条公理发现什么规律呢。在学习数学的时候，对于会有各种概念。公理、定理、推理等等。通过公理也就是不需要论证，它就是那样。通过公理推出定理，还有各种的公式. 通过万有引力公式，能够算出逃逸速度。内部的计算逻辑在大模型里是否能够，通过现有的知识，发现新的规律呢。材料科学里少许物质的变化会形成完全不同的物理特性，它们是否有一个我们尚未发现的通用公式呢。

从现实主义的角度来讲，我们需要什么样的大模型，如果不计成本的话，当然是模型越大越好。现实世界往往都是技术在成本上妥协，或者说是同样的成本提供更好的服务。比如搜索的成本，当出现使用小型机通过集群的方式代替大型机，将单个搜索的成本下降 1000 倍，当年淘宝也有去 IOE ，如果按现在的模式，整个 AI 行业基本都是在替英伟达打工。就像 20 年前整个网络都在替思科打工。 那么未来会怎么样呢。

1. 未来同样算力的成本会下降，每一年半同样的成本算力会翻倍（摩尔定律）
2. 本地大模型优先，在线大模型为辅，普及到每个人，交互不是 prompt ，而是自然语言。
   如果在成本不变的情况下，算力提高 10000 倍，大模型会给交互设备来带什么惊喜？
   会有新的模型来代替 transformer ，会有算力更强，能耗更低的推理设备（成本下降 10000 倍），会在 chat 之外的场景（可能是任何时间，任何地点，任何设备）。

我看可以让 AI 像大师一样作画，却没法像小孩一样去打酱油。如果 AI 是那个小孩，他知道打酱油需要 2 快钱，知道要去村东头小卖部。
每个人的期望都是突然有一天，有一个天神下凡一样的人物，突然的解决所有的问题。现实是需要慢慢打怪升级。
也许 AI 是陪伴，理解，然后成为自己，它记得你所有的往事，就像银河帝国里的克里昂大帝，永远在那里，和银河消亡。

前两天看到了腾讯云开发者的账号发布以一篇 QQ 浏览器服务的优化.

bookmark

在做架构设计时将微服务变成单体服务. 我在下面做了评价.

很多做设计的没有意识到 rpc 也是需要时间的,无限度的搞微服务,复杂性和网络调用链导致问题排查不下去. 一个单体应用加个缓存的事情,最后搞成一堆服务相互依赖调用,浪费机器、浪费人力.

在做架构拆分,很容易忘记初衷是什么,而是为了架构而架构.

在做微服务的时候,基本都是目前架构冗余,业务杂糅在一起,扩容困难. 或者是数据库表太多,大量的表关联查询缓慢,所以要做微服务架构的改造,跟随一起的还有,服务要跟着一起上容器.

单体应用与微服务并不冲突

做微服务拆分,但不要拆得那么细,比如有些过分的拆分恨不得 tab 就成为一个微服务.

本来一个很简单的业务,一个微服务/单体应用就够了, 非得拆出好几个来,比如一个业务有几个任务,业务把每个任务都拆成一个服务,可每个服务的80%的代码都是一样的,甚至数据都是一个数据库来源. 没有这个必要嘛. 而且过多的拆分会导致业务代码的割裂.

grpc 很快,但是也需要时间

grpc 使用 http2 协议,相比 http 协议对比,长链接和流要快很多,但是还是需要花时间的,每多一次的 grpc 的交互,网络请求会多出 1-2ms 的时间.

有些给前端的页面渲染拆成了多个模块,当想要把所有数据一次渲染出来.内部可能需要做几次甚至是十几次的 rpc 调用. 导致在网络上的时间就超过了 20ms. 还是不考虑高负载和网络抖动的情况下.

当 rpc 出现错误重试的成本要远远高于单体应用出错重试.

让缓存前置,让请求后置

当对服务进行拆分,有时候会出现这样的情况,每个微服务配套一套缓存和 DB.通常我们在内网微服务通信,然后通过 http 来提供外网服务.如果可能的话,可以尝试让对外的服务做前置的缓存.

不要过早的优化,容器并不是银弹

容器也是有损耗的, 使用容器会带来物理机大概 5% 的性能损耗,如果业务本身很稳定,也不是高并发的系统,没有什么扩容的需求,要不还是用物理机吧.

容器带来的无状态服务,扩容等让运维变得简单,但是同时也带来了查问题的成本变高,全链路的监控和运维的成本,对于小团队来说几乎是个黑洞.

做架构升级不要为了兼容旧的东西做妥协

在做架构升级会碰到很多的技术债,为了兼容可能是错误的技术债,不得不为此妥协,当妥协的内容越来越多的时候,会发现架构升级做了个寂寞. (这个和微服务没关系)

架构的目的,不是为了炫耀新技术,而是为了稳定,作为一个技术人员,要最求新技术,善用老技术.