主角色-反思角色机制
“主角色”-”反思角色“的循环机制。这种机制会有多个GPTs进行相互对话。举个例子，我输入一个要求，让它写一个高可靠的短信服务平台，那么这几个GPTs会自动相互对话，直到就最终结果达成一致。在这个过程中，可以回溯它们的对话记录，看到最终的结果是如何被讨论出来的。
go轻框架理论
go 偏向于轻框架而不是集成度特别高的框架，为什么？ 重框架也就是大型、侵入式框架的缺点 学习曲线陡峭 性能损耗 不够灵活 开发者不知道框架底层具体干了些什么 go 自己有强大的标准库，让开发者遇到问题的时候首先向内寻求解决办法，这是其轻框架理念的底气 go 组合优于继承，接口驱动设计 轻框架能够让开发者有一种掌控感，知道底层干了什么 鼓励只针对一个特定问题寻求解决方案，而不是“万能”框架 go 的轻框架理念又会带来什么问题？ 重复造轮子，功能相似但是实现逻辑不同 技术选型不知道到底选哪个 因为灵活自由，各个服务不同开发者实现出来的代码风格、框架选型可能都不一样 如何避免轻框架理念带来的问题，在自由和规范之间寻找一个平衡点？ 团队文档沉淀 着重架构设计
《局外人》读记——6.23
刚刚在夜色中缓缓升起的星星在这灯光下黯然失色。人行道上灯火通明，行人熙熙攘攘，看久了眼睛很累。
go web 框架——初探
Go Web 框架自研——初探beego 框架参考这是 beego 启动一个 web 服务的基础用法： 12345678910111213141516171819202122232425262728// controller.gopackage beegoimport "github.com/beego/beego/v2/server/web"type UserController struct { web.Controller}func (u *UserController) GetUser() { u.Ctx.WriteString("你好，我是小张")}func (u *UserController) CreateUser() { user := &User{} err := u.Ctx.BindJSON(user) if err != nil { u.Ctx.WriteString(err.Error()) return } _...
网络IO模型进化史
整个网络 IO 模型的发展是从阻塞 IO开始、中间逐步演变成非阻塞 IO、基于非阻塞 IO 的多路复用模型。其中多路复用又是从 select 发展到 poll 最后到 epoll 形式的。 阻塞 IO就是一直等着，直到拿到数据之后才继续往下执行。客户端和服务端建立好连接之后，服务端读取客户端发送过来的数据。从 read 开始就一直等着，直到读取到数据才返回，继续往下执行。这种方式的缺点就是，一个线程只能处理一个连接。如果我想处理多个客户端的连接，就只能多开线程。虽然线程是轻量的，但是当我有很多个连接的时候，线程开销会非常大。那能不能不让 read 等待呢？能不能调用了之后让它直接返回？这就是非阻塞 IO。 非阻塞 IO首先来看一下服务端是怎么一步一步把数据给到用户态的。 客户端发送数据给服务端 网卡收到客户端发来的数据 网卡等着数据全部发过来之后，将数据拷贝到内核 内核等着数据拷贝完成后，将数据拷贝给用户态 用户态等待数据全部拷贝完成整个过程也就是 客户端 -> 网卡 -> 内核 -> 用户态。 那为了能够让 read...