思考

最近在服务器上装了 Hermes Agent 它里面的 llm-wiki skill 引起了我的注意，当我将自己所有记录的笔记全部喂给了 llm-wiki 我发现事情开始变得不一样了。 初识 我们与 AI 交互的开始都源于一份小心试探的信任。当我把笔记上传到服务器，并告诉 Hermes Agent 去分析我的笔记时我并不知道会带来什么样的结果。但我内心确实是期待它能给我带来一丝惊喜。 当 Hermes Agent 告诉我笔记已导入完成时，我问他“当前我的知识库里有哪些内容？”，它给了我一个概括性的答复让我确定它已经把我笔记的内容完整的导入到了 llm-wiki 目录中。它也第一次了解了那么多跟我深度绑定的信息。 当他回答完我的问题后提示我导入的数据保留了原有的结构，没有提炼成知识库的结构信息并给了我一个整理的方向。 随后我让他整理了知识库至此我的笔记已经完全集成到了llm-wiki。 能力初探 我让它通过知识库说说它对我的了解，通过它的回答我确信它对我工作方面已经相当了解了。它知道我的主力开发系统，知道我使用的编辑器、知道我喜欢容器化等等等等，下面是我摘自它的回答片段： 你是一个重度 Linux / Neovim / 容器化用户，知识库里 Linux、Neovim、Docker、Podman 的内容很多。 我感觉你的开发环境画像大概是： Linux 桌面为主 偏 Arch 系发行版 喜欢 Neovim / LazyVim / NvChad 重视中文输入法、字体、Wayland/Electron/Wine 兼容性 倾向把本地开发环境容器化 对 Docker 和 Podman 都有实践经验 对 Traefik / Nginx / GitLab CI/CD 有实际部署经验 我看了它对我的描述，我觉得准确度相当的高。我曾经研究过 RAG 技术方案，就使用感受而言，我觉得 llm-wiki 以极低接入和使用门槛实现了这么高效的知识提取真的是相当厉害了。我向来对这种使用简单产品十分迷恋。 深入探索 我又提问“根据你对我的理解，你觉得我在职业上应该怎么走向下一个阶段”，它的回答让我觉得也许我们任何事情都可以先问问 AI 了。...

最近听孟岩播客《够与多》有很深的共鸣，我听了很多遍，在听的过程中去思考和感受，目的就是为了减少知识的缝隙。 要想回应什么是够什么是多，首先得定义我是谁，我需要一个怎样的人生，只有定义了这个才能知道什么是够，什么是多。 如何找自我 找寻自我非常难，很多人终其一生也没有找到自我。我也在找寻自我中陷入了迷茫，直到有一天 the pathless path 里的一句话，为我在黑暗中点起了一丝光亮。 你应该去做那些给你带来能量的事情，而不是消耗你能量的事情。 我们看到过很多地方告诉你要逃离舒适区，这种阐述似乎是没有什么问题，如果舒适区是一个圈，逃离的方向却有四面八方，你要怎么找到自己的方向才是更为关键的。 人生只有一次，我们的人生不该由他人定义，我们要花时间审视自己的人生，找到自己人生的方向。 时间跨度 以更大的时间跨度去思考自己的人生，会更有助于我们梳理人生的方向，段永平说：“做对的事情，把事做对。” 我觉得对我们找到自己人生的方向有很大的启发意义。 有些人可能会觉得玩游戏是自己人生的意义，我不否定这种意义，电竞已经成为奥运比赛的项目，可以看出游戏已经不像 20 年前那样被视为洪水猛兽。有很多游戏的职业选手，梦想的起点也是源于对游戏的热爱。 我们可以想象一直玩游戏十年以后的光景是什么，如果那个光景是你想要的那你就可以去把玩游戏当作自己的人生意义。 找到比别人好十倍的事情 我们也可以找到自己不用很努力就可以做的比别人好十倍的事情，这种事情一般不容易找到，你可以从今天开始主动觉察，去发现那些你比别人更擅长的事情。 也许你发现自己比别人好的并没有十倍，可能仅仅有两倍，那也没有关系，你已经比别人擅长了，去保护好这颗幼芽，持续灌溉，直到它生成为比别人好十倍的事情。 热爱的事情 巴菲特说每天跳着踢踏舞上班，可见热爱是有多么大的能量。热爱也是你能够让你做事比别人好十倍的基础之一。 热爱能让你苦中作乐，有些事情可能会让他人感到痛苦，但对你来说是攀登高峰的喜悦，你可以不断的在热爱的事情上突破，即帮助我们逃离舒适圈，又帮助我们更容易做出比别人好十倍的事情。 关于比较 人生的很多痛苦来自于比较，不必与他人对比，你有你自己的精彩。对于我们大多数人来说找到自己人生的意义，活出自己想要的人生才是最重要的。 什么是够？什么是多？每个人的标准都不一样，同样是有 80 亿，有人卧轨自杀了，有人却匿名捐到基金会帮助了更多的人,使自己的人生更有意义。 社会有很多的准则，工业社会不仅制造了更多的商品，也制造了人们想要更多的心，最开始我们买张桌子是为了满足放东西的需求，而现在我们买张桌子已经远远超过了放东西的基本需求… 商家通过各种影响，让我们陷入了消费陷阱，我们希望购买的商品去替我们说话，来展现自己是一个什么样的人。 当我们停下来审视自己时，或许会发现我们真正需要的并没有那么多，当我们明白自己真正需要的是什么的时候，我们自然也就逃离了消费主义陷阱。 努力活明白 世界太复杂，人生又太短。我们都在努力的活明白，我们想把复杂的世界以及我们复杂的行为阐述的清楚明白，这并不简单。 我一个朋友的父亲说过这样有一段很有哲理的话，大意如下 我们每个人一生都在努力活得自洽 是的，世界是矛盾的，我们自己也是矛盾的，能活的自洽，不拧巴真的是一件不容易的事情。这一生太宝贵，值得我们好好思考和规划。 建立自己的内核 当你有了稳定的内核，你就不会被其他事物牵着鼻子走，你有自己衡量生活的准则，你可以努力的活成自己想要的样子。 没有人比我更适合定义我是谁，我想过怎样的生活。知道了自己想要的生活，才不会被外来的干扰所裹挟，每个人都不相同，各有各自的精彩。 把握当下 有这么一则小故事 小和尚问师父： “师父，什么是修行？” 师父答： “饥来吃饭，困来即眠。” 小和尚疑惑： “这人人都会呀！” 师父说： “非也，世人吃饭时百般计较，睡觉时千头万绪；我则吃饭时吃饭，睡觉时睡觉。” 专注与当下应该做的事情，偶尔抬头看看目标即可。现在的社会更为嘈杂，我们的注意力已经被各种超级 APP 占用，每天面对山呼海啸的信息流，能做到专注于当下已经越来越难。 适当的冥想更加有助于我们抚慰内心的安宁，正像有句话说的那样：“你担心的事情，90 % 都不会发生。”既然这样，我们又何苦耗费心神，担心那些本就不会发生的事情呢。 最后附上一首小诗，祝大家都能找到自己： New York is 3 hours ahead of California, 在时间上，纽约走在加州前面三个小时, But it does not make California slow....

在多年的开发经历中，我发现不重视编程规范是普遍存在的一个问题。很多开发人员对规范的态度都是很抵触的，认为规范的条条框框是枷锁，会降低开发效率。 不仅仅是普通员工，很多公司的管理人员对于规范的重视程度也是不够的，甚至就没有制定规范的想法。 为什么会出现这种现象呢，我想每个人都会有自己的角度，大多数原因可能是因为项目周期紧张，没有时间制定规范，或是单纯的认为规范会影响开发效率。 上面的原因是客观存在的，所以大家对于不制定规范也没有太大的心智负担。今天我想就这个现象谈谈我对规范的认识。 规范一般有两种，一种是项目规范一种是编程规范。 关于项目规范 我在刚开始入行的时候，公司虽然也没有自己的规范，但是带我的前辈，给了我一份谷歌的开发规范，让我学习，代码的书写格式是怎么样的，什么时候应该换行，应该怎么避免写嵌套 if… 这让我对代码规范有了一个最基本的认识。 代码需要书写的简洁，易读。代码规范有点像写文章时的字体工整程度，越遵守代码规范，字体就越工整。你可以想象就算同样的一篇文章，字体工整和字体潦草给阅读人的感受是完全不同的。 后来我在一家公司做管理，刚到公司时也没有自己的规范，每个人的代码风格，变量命名，项目组织的习惯各有不同，导致项目的风格多样，这给我们带来了一些问题。 维护成本高 当我们维护其他同事写的代码的话，需要从头开始阅读一遍代码，才能了解问题具体出在哪。如果我们有规范就不需要通读所有代码，仅需依据规范出问题代码的大体位置。 代码复用差 当我们有一些通用业务需要封装时，如果没有规范，就需要考虑所有的代码风格，甚至要做一些额外的兼容才能把组件封装完成，有了规范我们完全就可以避免这类问题。 项目对接慢 由于没有规范，每次公司来了新同事，我们并没有很完善的文档给到他。导致新同事上手项目比较困难，中间还要不断地去询问老同事，才能对代码有一个相对比较完善的理解。 这无疑增加了很多的摩擦成本，且团队越大，这种摩擦成本就会越高。就像我们都说中文，又各自有自己的方言，大家需要了解每个人的方言体系，才能更好的深入交流。 我们需要“普通话”这样一个统一的说话规范，来降低我们团队内部的摩擦成本。 建立规范 为了解决上述问题，我们结合自身团队的特点，参考了他人的规范制定出了我们自己规范的初版。 初版规范经过内部评审和修改后，我们形成了自己的规范文档。 后续我们在实践的过程中遇到了一些规范上的不足，也进一步对规范做了补充，使规范在原有的基础上不断的迭代和优化。 这样一套规范建立后，使我们每一步都是在之前的基础之上，而不是每一次都是从 0 开始。这让我们可以不断的阶梯向上。 如何让规范落地 规范的制定后就需要考虑规范落地问题，如何让团队更好的遵守规范。 首先需要让团队认识到规范对我们团队合作是有益的。做好心理建设，消除心理的抵制情绪。 把规范塑造成开发文档，让团队养成经常查阅的习惯，对规范有疑惑就去规范文档找答案。 利用工具降低规范的执行难度，像一些代码风格的问题可以通过 IDE 代码格式化解决，不用团队开发者额外注意。 使用静态代码分析工具检测代码是否符合规范，如果使用 CI/CD 可以把这一步集成到 CI/CD 中，让不符合规范的代码，无法提交到线上环境。 关于编程规范 编程规范包括：设计模式，设计原则，编程范式，最佳实践等等。这类规范一般是行业发展多年，一些经验丰富的前辈总结的一些开发工作的规范。 因为这类规范通常是前辈们在长期实践中总结出来的。遵守这类规范能让我们更容易开发出稳定的程序，少走弯路。 这类规范一般都具有普遍性，对语言没有任何的限制，因此一旦你熟练的掌握，你用任何语言开发的程序都会有更好的稳定性，更少 Bug 、更容易维护和扩展。 我发现有些同学会遇到一些奇奇怪怪的问题，或者一段时间后，程序出现了运行瓶颈。有不少是因为没有遵守某些编程规范引发的问题。 有时他们不遵守编程规范，并非不愿意，而是因为他们不了解某些规范。因此对于编程规范，要像探寻宝藏一般，时常去探索一下。不断地完善和补充自己对编程规范的理解。 总结 规范短期看可能会觉得有点浪费时间，影响开发效率，从长期看，却未必如此，那些减少的 Bug, 复用的代码，以及与同事之间协作效率的提升，足以弥补开发时的损耗。 牛顿说：我之所以比现别人看的远，是因为我站在巨人的肩上。 运用前人的智慧和经验，能让我们做事情更加的顺利。要站在前人的肩膀上，哪怕你觉得这个人不够高，也比自己站在平地上看的更远。

最近再开展整合系统的工作，将原有系统中的共用逻辑抽离出来形成一个中台系统，根据业务开展形式的不同，划分出各个子系统。 在开展的过程中，遇到一种情况，在一些场景下子系统需要根据中台系统的一些操作去初始化自身的业务数据。 我们准备用事件（ Event ） 的形式来解决这个问题，子系统监听中台系统发布的一些事件，当中台系统进行相关操作时，触发事件通知监听中的子系统。 我们的中台系统 （ main system ） 是用 go 语言开发的，事件的触发是通过队列的形式发送给 event hadle 然后由它去发送事件通知到各个子系统。 在一些其他语言中，队列的消费一般都是启动一个进程来监听处理。而 go 有协程，可以用更轻量的协程来处理队列消费，这样以来有一个直接的好处就是服务启动了，队列的消费者就跟着启动了，不需要单独维护一个进程的启停。 当然要实现上述能力，有几个问题需要解决： 协程消费者如果崩溃了，不能影响主进程的运行 协程异常要能重新拉起一个新的消费者，保证协程消费者能一直运行。 崩溃隔离 消费者有自己的逻辑，在逻辑处理中有可能会出现 panic，我们需要消费者的 panic 限制在协程里，以避免协程崩溃影响主进程。 Go 有 recover 机制，可以让你捕获 panic 并且限制 panic 不在向上蔓延。代码如下： go (func() { defer func() { if err := recover(); err != nil { fmt.Println("捕获到 panic:", err) return } }() err := EventHandle() if err != nil { Logger.Error("event 处理监听失败", err) } })() 消费者协程保活 消费者业务逻辑在协程里，可能在一些场景（panic 或其他不可知情况）下意外退出，我们需要保证能够重新拉起消费者协程，从而保证整个事件逻辑的闭环。...

面向接口编程： 当一个实体依赖另一个实体时，不依赖实体而是依赖实体的抽象。 比如说生产一个电灯，电灯需要一个开关来控制电灯的点亮和关闭，如果电灯依赖某个具体的开关,，比如电灯出场内置开关依赖了 A 品牌，当有一天买电灯的客户家里是 B 品牌的开关，那么电灯就没办法使用了。但是如果我依赖的是开关的抽象接口，它提供打开和关闭两个行为给电灯，电灯根据打开和关闭的行为去控制电灯的点亮和关闭。 这种设计可以让生产的电灯适应市面上的所有开关，那怕未来实现了脑机接口的开关，只要这个它遵循开关的抽象提供打开和关闭两种行为，这款电灯就能受这种新开关的控制。 从上面例子上可以看出，所谓的接口是依赖双方提前的一种约定，依赖方按照这种约定去调用，被依赖方按照这种约定去实现，这种约定其实就是标准化，调用方按照约定去实现功能，使用方按照约定去使用功能。 标准化的好处 从上面的例子中可以看出，标准化带来最大的好处就是复用，你可以任意的生产各种各样的开关，只要是按照标准制定的，我的电灯都是可以使用的。 其次标准化会带来效率的提升，现实中交通规则就是一个很好的例子，交规就是一个标准, 只要是在路上的走的，都受到交规的约束，而正是有了这种约束我们才有了更高效的通勤，绿灯了可以走，红灯了，就停下来等待，我们对路上所有的车辆和行人的轨迹都有预期，从而提升通行效率。 可以设想一下没有交规，是一个什么样的场景，大概率会出现所有车辆堵在了路口，整个路口堵的水泄不通，最后整体通行效率变得无比低下。 标准化还会带来工具化，再拿生活中常见的交通为例，有了完善的交通规则，后续就可以生产适用这种规则的自动驾驶车辆，这将大大改善人们的出行效率。 标准化在工作中的用处 标准化在工作中也有着十分重要的作用，如今的工作大多都会有工种之间的划分，工种和工种之间就存在着依赖关系，上一个工种的工作要到什么程度，下一个工种应该怎么衔接，这就是一个依赖，而在这两个工种之间就需要一个明确的约定。 有了这种约定，可以减少很多不必要的沟通，不需要去关心上个工种的实现细节，只需要双方按照约定各自生产，在产品成型阶段把各个工种生产出的设备进行组装即可。 当公司来了新人的时候，他也不需要重新去每个环节去了解其他工种的产品特性，只需要去了解约定的标准化制度即可投入到生产中。 标准化的问题 标准化也并非都是好处，它在设计阶段需要投入相当的人力去设计，并且需要在后续的生产阶段通过实践中得到的反馈，去不断的完善标准。 如果标准设计的不好，频繁的变更标准，将会导致所有依赖的标准方都要进行变动，这种变动的成本是相当高的。 因此在标准设计的时候要进行必要的论证和演练，确保标准没有明显的问题，最大限度的减少标准化带来的成本。 总结 标准化相当于在一个有限范围内设计了一个小型的生态系统，标准化制定了基本的流程和规则，生态系统的其他元素按照这种流程和规则去演化出标准化所期望达成的效果。 标准化的制定是有难度的，有些时候仅从设计阶段，无法看到最终的结果，这时可以通过抓大放小的形式去解决。刨除细节，去设计整体框架，保证大方向的正确，在标准化实践的过程中去不断的丰富细节，完善标准，从而让标准化实现最终的落地。 可能某些情况下理想下的标准化永远也无法达成，但这不能成为放弃标准化的理由，不能因为我们理想是得到 100 分的好处，因为我们拿不到 100 分就放弃。拿不到 100 分，能拿 60 分也比一分都没有要好一些，你觉得呢？