一、猪鼻环 ​

小时候在村子里，养猪的往往要给猪扎上鼻环。猪这种动物，有着长长的吻，喜欢拱来拱去。又因为是圈养，往往是一层砖砌的猪圈，地面还是土地。有的猪吃饱喝足了也睡够了没事干，就喜欢拱地，拱着拱着，就把猪圈拱塌了，然后它就脱离了束缚放飞自我。这往往让养猪的人很难受，不仅损失了猪圈，浪费了精力，甚至有可能失去一头猪。得益于老祖宗们数千年来的养猪经验，给猪扎上个鼻环，那么它再次拱来拱去的时候就会疼痛不已，逐渐也就变得驯服。我小时候就亲眼见到过一群大汉把一头猪给按在地上，然后拿着铁丝扎在猪鼻子上再打个结，那猪的哀嚎不绝于耳，给我单纯幼小的心灵带来了极大的震撼。

当然，用现在比较流行的话来说，就是：

人们通过深度洞察猪的核心行为路径，识别出其在“拱土场景”中的高频痛点（如破坏圈舍、饲料浪费）。基于此，打造了一套以“鼻环”为载体的轻量化干预方案，精准打在神经末梢的敏感触点上，实现了对非理性行为的即时阻断。

该方案具备高 ROI、低实施成本、强可复制性等优势，形成了一套“感知-反馈-矫正”的闭环机制，有效提升了圈舍运营的颗粒度与确定性。

同时，我们坚持“以猪为本”的底层逻辑，在最小化应激的前提下，完成了对其行为模式的柔性治理，真正做到了“拿捏痛点、打出组合拳”，为规模化养殖提供了可沉淀、可复用的方法论支撑。

事实上，不只是养猪需要些手段。比如养牛的也会给牛扎鼻环让它乖乖听话，放羊的需要带上牧羊犬来管理羊群，拉磨的驴要蒙上双眼，养狗的也要恩威并施让它明白谁才是主人，骑马的要给马套上缰绳抽打鞭子。就连美猴王都得戴上个金箍。总的来说，一切的手段都是为了让它们驯服，只要老实听话，就不会有那么多痛苦。所以不得不感慨人类的智慧，针对这些不同的特性设计了若干种行之有效的方案。当然道理都是相通的，不限于圈养禽畜和放牧。比如古时候就有一个官职名称叫做“州牧”，汉昭烈帝刘备就曾担任豫州牧。这里的“牧”和“牧马”的“牧”并无太大不同，只不过管理的对象是人口和土地罢了。

话说回来，就我所知，并非所有的猪都需要被扎上鼻环。我们通过简单的逻辑分析就可以得到如下结论：

1. 既然有的猪是人工圈养的，那么就必然有些猪是野生的，那么这些野生的猪就不用遭受扎鼻环的痛苦。
2. 猪因为不听话才会被扎鼻环。如果有的猪吃饱喝足了就是睡大觉，服服帖帖的，那么也不必遭受扎鼻环的痛苦。

关于猪鼻环这个事情，我们还有一点需要明确，即猪本身是不需要鼻环的。无论一头猪是好吃懒做还是喜欢拱来拱去，这本来就是它的天性，因为它生来没有鼻环，所以它是不需要鼻环的。给猪扎鼻环是为了让猪温驯，简而言之就是消除它的不安分因素，以符合人的利益。

我们先从人的角度来分析。针对不安分的猪，简单直接地给扎上鼻环，虽然简单有效，但一定程度上也是人的一种懒惰。本质上，我们需要解决的是环境与需求错配的问题。比如：

1. 可以因材施教：对于那些安分的猪，就放任自流，让它们负责长肉；对于不安分的猪，生态放养，让它们发挥拱地天赋，帮助松土除虫。把合适的猪放到合适的位置上。
2. 可以循循善诱：提供可拱可咬可探索的猪玩具，或者把饲料藏在稻草堆里进行觅食挑战。用正向引导替代负向惩罚。
3. 对于不同品种不同品性的猪，设计不同的养殖模式，而非统一无差别的圈养。即尊重生物多样性，避免一刀切管理。

从一头猪的角度来分析：

1. 要么选择不被人圈养，即放弃优渥的饲料和生活，到山间餐风露宿，但同时也不需要出卖自己的生命和自由。
2. 对一头不安分的猪来说，要么继续我行我素，但是会被扎上鼻环，承受极大的肉体痛苦；要么压抑自己的天性，哪怕再想拱来拱去，也要憋着，从而承受极大的精神痛苦。也就是说，对于一头不安分的猪来说，无论如何都要承担痛苦才行。
3. 但是对于那些本身就安分守己的猪来说，就无此痛苦之虞，但这样的猪也就真的只是一头待人宰杀的猪罢了。

二、猫与狗 ​

对于有些人来说，可能吃了这么多年猪肉，却并未亲眼见过活生生的猪。但是对于猫猫狗狗，相对而言应该会更为熟悉。

不管是一头圈养的猪，还是一只宠物猫狗，从本质上来说，都是出卖自己来换取相对安稳的生活，与人类的关系都是互予互取。只不过猪出卖的生命以满足人的口腹之欲，而猫狗更多的是出卖自由来给人提供精神上的安慰。

相对而言，作为宠物的猫狗的地位要比作为食物的猪（当然这里要排除掉宠物小香猪）要高一些的。毕竟从马斯洛需求层次理论来看，猫狗满足的是人类更高层次的需求。但它们同样面临着一定的风险，比如有的人会给猫狗绝育——从生物进化的角度来说，无论如何这都是绝对反天性的。

但并非所有养猫养狗的人都会给猫狗绝育，比如村子里就几乎不会——一是因为不会额外花这个钱，二是因为相对放养也不太在意。还有一些人会考虑到猫狗本身的需求不会这样子做。但总而言之，还是有挺大一部分人会给猫狗绝育，无论他们是否认识到这事实上是给宠物施加的一种痛苦，只不过因为这些宠物不会说话无力反抗罢了。我们不能用非蠢即坏来对此行为进行评判，毕竟会涉及到多种因素，以及为了避免争议，这里并不打算做过多分析，自行判断即可。

三、皇帝、将军、士兵 ​

我以前有个小领导，特地开过一个会和我们探讨一个问题，即：皇帝、将军和士兵，哪个角色的压力更大。正常来说，人都倾向于用屁股说话，所以我们多数人会说士兵的压力最大，毕竟要真刀真枪上战场，面临直接的存活压力。当然那位领导并不苟同我们的观点，他的结论是皇帝的压力最大，并尝试说服我们相信。

那个时候我就觉得，绝大部分的人作为人这种动物，本质上也不过是沐猴而冠罢了。之所以用绝大部分，是因为假如你见到过异类，那么便不能以偏概全；如果未见到过，那么更不能否认，否则就是一叶障目了。

后来再想到这个问题，还是觉得很有趣。我把这个问题交给大模型，它告诉我众生皆苦。但有人是理想主义者，有人是现实主义者，有人是战略共情者，有人是愤世嫉俗者。我觉得，无论是哪一种人，只要是知行合一的，那便不能过多苛责。但假如挂羊头卖狗肉，那就有异化的嫌疑了，为人所不取。

关于“沐猴而冠”这个成语，来源是《史记·项羽本纪》：

居数日，项羽引兵西屠咸阳，杀秦降王子婴，烧秦宫室，火三月不灭；收其货宝妇女而东。人或说项王曰：“关中阻山河四塞，地肥饶，可都以霸。”项王见秦宫皆以烧残破，又心怀思欲东归，曰：“富贵不归故乡，如衣绣夜行，谁知之者！”说者曰：“人言楚人沐猴而冠耳，果然。”项王闻之，烹说者。

关于项羽，韩信对他还有一个颇为有趣的评价：

项王见人恭敬慈爱，言语呕呕，人有疾病，涕泣分食饮，至使人有功当封爵者，印刓敝，忍不能予，此所谓妇人之仁也。

从博弈论的角度来稍作分析，我们就知道项羽完全可以选择一种双赢的结果。可惜的是，项羽这个人不爱学习，这个在史记中亦有记载：

项籍少时，学书不成，去学剑，又不成。项梁怒之。籍曰：“书足以记名姓而已。剑一人敌，不足学，学万人敌。”於是项梁乃教籍兵法，籍大喜，略知其意，又不肯竟学。

总而言之，项羽的格局和之后的失败，还是吃了没文化的亏。

四、爱身 ​

扯着扯着，就扯远了。其实，无论是猪、狗还是猫，无论是皇帝、将军还是士兵，本质上无非是你想过怎样的生活，成为怎样的人。倘若总是在别人所谓的指引和教导下，去如何如何做，成为怎样怎样的人，那就是自动带入了圈养的猪的角色。总有人会告诉你，要听话要服从安排，那么你就可以成为“我们”的一份子，但仔细想这个“我们”里真的有“我”吗？更可悲的是如此教导你的人，也不过是另一只被圈养的猪罢了。

所以人可以出卖自己，但不能无底线地出卖自己。劳动可以出卖，精神不能出卖。就像古代被迫入青楼的女子，物理上承受奇奇怪怪的客人凌辱xp也就算了，精神上还要被嘲讽和作践，那就真的无可接受了。

老子说：贵以身为天下，若可寄天下；爱以身为天下，若可托天下。也就是说，人首先得自爱，这是一切的基础。当然也要有自知之明，否则就是烂泥糊了眼。

设备 ​

• 网络
  • 路由器: 小米路由器 BE6500 Pro
  • 交换机: 小米万兆交换机
• 存储:
  • NAS: Synology DS220+ (2*16T, RAID1)
• 计算:
  • MiniServer: M4 MacMini (24G+256G)
  • DevServer: 零刻 SER8 8745HS 迷你主机 (32G+1T)

基本原则 ​

核心理念:

• 配置简单
• 运行稳定
• 对网络暂无特别高的要求

设备角色：

• NAS 尽量只做存储使用，不部署其它不必要的服务
• MiniServer 作为生产环境，部署需要长期稳定运行的服务
• DevServer 作为开发环境，用于平时开发测试，以及部署一些临时服务
• MiniServer 同时承担网关角色，统一流量入口

网络 ​

网络拓扑 ​

内网 DNS ​

出于部署方便，直接在 MiniServer 上 docker 部署了 AdGuard Home

docker run -d \
  --name adguardhome \
  --restart unless-stopped \
  -v ./work:/opt/adguardhome/work \
  -v ./conf:/opt/adguardhome/conf \
  -p 53:53/tcp \
  -p 53:53/udp \
  -p 3000:3000/tcp \
  adguard/adguardhome:v0.107.71

然后：

1. 将路由器的 DHCP 配置中，DNS 配置修改为 MiniServer 的 IP（修改第一个 DNS 配置，第二个保留为运营商的配置作为兜底）
2. AdGuard Home 中设置 DNS Rewrite，将自己的内网域名 A 记录（@ 和 *）配置为 MiniServer 的 IP

例如：

• MiniServer IP 为 192.168.31.2，自定义内网域名为 myhomelab.com（仅作为示例）
• 路由器 DHCP 的 DNS 配置为 192.168.31.2
• AdGuard Home 中设置 myhomelab.com 和 *.myhomelab.com 为 192.168.31.2

这样后续就可以通过自定义的域名来访问内网服务了。

异地组网 ​

使用 Tailscale。

1. 在 MiniServer 以及需要远程访问的设备上安装 Tailscale
2. 之前自定义内网域名为 myhomelab.com，同时也购买了公网域名
3. 在域名提供商解析域名 myhomelab.com 的 A 记录（@ 和 *），IP 使用 tailscale 提供的 100.x.y.z 地址

这样内外网都可以统一通过域名来进行访问。

服务 ​

效果 ​

使用 homepage 部署了个首页导航，效果如下：

记忆 ​

直接使用未经定制的LLM时，系统默认不具备对话记忆能力。即使在前序提示词中告知模型用户的姓名等信息，模型也无法在后续对话中记住这些信息。

两种广泛应用于对话记忆保持的方法：

• 对话缓冲区
• 对话摘要

对话缓冲区 ​

• 随着对话轮次增加，输入提示词的文本长度会持续增长，最终可能超出模型的词元限制。
• 控制上下文窗口的有效策略是仅保留最近k轮对话记录。

对话摘要 ​

• 对完整对话记录进行摘要提炼，保留核心信息。
• 提炼摘要的过程由另一个LLM完成：该模型接收完整对话历史作为输入，并负责生成简明的摘要。使用外部LLM的显著优势在于，对话系统无须局限于单一模型。

对比 ​

Agent ​

能够自主规划行动及其序列的系统被称为智能体(agent)，其核心在于利用语言模型自主制定行动决策。Agent 通过两大核心组件实现功能扩展：

• 工具(tool)：赋予智能体完成自身无法独立处理的任务的能力。
• 智能体类型(agent type)：规划行动及工具使用策略的决策框架。

ReAct的精妙之处在于建立了推理与行动的动态反馈机制：推理指导行动决策，行动结果“反哺”推理进程。在具体实现中，系统通过以下三阶段的循环迭代完成认知闭环：

• 思考(thought)
• 行动(action)
• 观察(observation)

语义搜索与RAG ​

语义搜索(semantic search)核心在于通过语义理解而非简单的关键词匹配来实现精准检索。

尽管模型能够流畅自信地输出答案，但其内容在准确性和时效性方面仍存在不足（幻觉）。解决该问题的主要方法之一，便是构建能够实时检索相关信息并输入LLM的系统，从而生成有事实依据的答案。这种被称为RAG（检索增强生成）的技术，现已成为LLM最受瞩目的应用场景。

优化语言模型在搜索领域的应用，当前主流技术可分为三大类：

• 稠密检索(dense retrieval)
• 重排序(reranking)
• RAG

稠密检索 ​

基于文本嵌入，将搜索问题转化为查询向量与文档向量的最近邻匹配过程。如图所示：接收搜索请求后，系统在文档库中进行向量比对，最终输出相关性最高的结果集合。

重排序 ​

搜索系统多采用多阶段处理流程。重排序模型作为其中关键环节，负责对初步检索结果进行相关性评分，并据此优化排序。

RAG ​

生成式搜索属于广义的RAG系统范畴。这类系统通过整合检索机制来增强文本生成功能，可有效抑制幻觉现象、提升事实准确性，并使模型输出与特定数据集保持逻辑一致性。

多模态LLM ​

视觉Transformer ​

视觉Transformer(Vision Transformer，ViT)的实现依赖Transformer架构的一个重要组件——编码器。不同于将文本分割为词元，它将原始图像切割为规则排列的图像块，进而实现特征提取。

但需注意，无法像文本词元那样直接赋予图像块固定的ID——由于图像的多样性，图像块在不同场景中的重复概率远低于文本词元。 为解决这一问题，系统会对图像块实施线性嵌入操作，将其转换为数值化的嵌入向量。当嵌入向量进入编码器后，视觉与文本模态的处理路径完全相同。

多模态嵌入模型 ​

多模态嵌入模型可在同一向量空间中为不同模态生成嵌入向量。

得益于共享向量空间的特性，我们可以直接比较不同模态的语义表示。

在众多多模态嵌入模型中，对比语言-图像预训练(Contrastive Language-Image Pre-training，CLIP)模型以其卓越的性能和广泛的适用性成为当前最主流的解决方案。

CLIP的实现逻辑相当简洁。设想存在一个包含数百万张图像及其对应描述文本的训练数据集，该数据集为构建跨模态对齐提供了基础。基于此数据集，可为每一组图像和描述文本创建两个向量表示。CLIP采用双编码器架构实现这一点：文本编码器处理描述文本，生成语义嵌入；图像编码器提取视觉特征，生成图像嵌入。如图所示，经过联合训练后，配对的图文数据将在向量空间中获得高度对齐的嵌入向量表示。

提示词 ​

LLM是一个预测引擎。基于某个输入（即提示词），它试图预测可能跟随其后的词。从本质上讲，只需少数几个词，就能激发LLM做出响应。

提示词通常用于让LLM回答特定问题或解决特定任务。这称为基于指令的提示词。

输出参数 ​

除了提示词，我们还可以通过调整模型参数来控制输出类型。

temperature ​

temperature（温度）决定生成文本的随机性或创造性。它定义了选择本来不太可能出现的词元的概率。其基本原理是，temperature为0时每次都会生成相同的响应，因为它总是选择可能性最大的词。较高的temperature值允许生成可能性更小的词。

• 较高的temperature（如0.8）通常会产生更多样化的输出。
• 较低的temperature（如0.2）会产生更具确定性的输出。

top_p ​

top-p采样，也称为核采样(nucleus sampling)，是一种控制LLM可以考虑哪些词元子集（核）的采样技术。它会考虑概率最高的若干词元，直到达到其累积概率限制。

• 如果我们将top_p设置为0.1，模型会从概率最高的词元开始考虑，直到这些词元的累积概率达到0.1。
• 如果我们将top_p设置为1，模型会考虑所有词元。

高级提示工程 ​

提示词组件 ​

常见组件：

• 角色定位：描述LLM应该扮演什么角色。例如，如果你想问一个关于天体物理学的问题，可以使用“你是一位天体物理学专家”。
• 指令：任务本身。指令应该尽可能具体，避免留下太大的解释空间。
• 上下文：描述问题或任务背景的附加信息。它回答了“为什么提出这个指令”这样的问题。
• 格式：LLM输出生成文本的格式。如果不指定格式，LLM会自行决定格式，这在自动化系统中会造成麻烦。
• 受众：生成文本的目标对象。这也描述了输出的水平。在教育目的下，使用ELI5（Explain like I'm 5，“向5岁的孩子解释”）通常很有帮助。
• 语气：LLM在生成文本中应该使用的语气。如果你要给老板写一封正式的邮件，你肯定不想使用非正式的语气。
• 数据：与任务本身相关的主要数据。

对模块化组件进行迭代是实体工程的重要步骤：

上下文学习：提供示例 ​

我们可以为LLM提供我们想要完成的目标任务的具体示例。这通常被称为上下文学习(in-context learning)，其中，我们为模型提供正确的示例。

• 零样本提示不使用示例
• 单样本提示使用一个示例
• 少样本提示使用两个或更多示例

链式提示：分解问题 ​

将一个提示词的输出作为下一个提示词的输入，从而创建一个连续的交互链来解决我们的问题。

链式提示技术让LLM能够在每个独立问题上投入更多时间，而不是一次性解决整个问题。

推理 ​

思维链：先思考再回答 ​

在提示词中提供了一些示例，展示了模型在生成响应之前应该进行的推理。这些推理过程被称为“思考”。这对于涉及较高复杂度的任务（如数学问题）帮助很大。添加这个推理步骤使模型能够在推理过程中充分利用更多的计算资源。相比于基于几个词元直接计算出完整的答案，在推理过程中每增加一个词元都能让LLM的输出更稳定。

虽然思维链是一种增强生成模型输出的好方法，但它需要在提示词中包含一个或多个推理示例，而用户可能无法获取这些示例。我们也可以不提供示例，而是直接要求生成模型进行推理（零样本思维链）。这种方法有多种形式，一种常见且有效的方法是使用“让我们逐步思考”(Let's think step-by-step)。

自洽性：采样输出 ​

用相同的提示词向生成模型多次提问，并将占多数的结果作为最终答案。在此过程中，可以通过调整不同的temperature和top_p值来影响每个答案，以提高采样的多样性。

思维树：探索中间步骤 ​

思维树(tree-of-thought，ToT)可以对多个想法进行深入探索。工作原理如下：当面对需要多个推理步骤的问题时，将其分解成多个部分通常会有所帮助。在每个步骤中，生成模型会被提示探索当前问题的不同解决方案。然后，它对最佳解决方案进行投票，并继续进行下一步。

输出验证 ​

三种控制生成模型输出的方法。

• 示例：提供多个预期输出的示例。
• 语法：控制词元选择过程。
• 微调：在包含预期输出的数据上对模型进行微调。

语法：约束采样 ​

用于约束和验证生成模型输出的软件包：Guidance、Guardrails、LMQL等。在某种程度上，它们利用生成模型来验证自己的输出。生成模型将输出作为新的提示词，并尝试基于一些预定义的规则进行验证。

文本分类 ​

表示模型和生成模型都可用于分类，但它们的方法不同。

使用表示模型进行文本分类 ​

使用特定任务模型直接进行分类，或使用通用嵌入向量间接进行分类。

• 使用特定任务模型分类：例如 Twitter-roBerta-base for Sentiment Analysis 模型做情感分析。
• 使用嵌入向量分类：
  • 监督分类：
    • 第一步：使用嵌入模型将文本输入转换为嵌入向量
    • 第二步：将这些嵌入向量将作为分类器的输入特征
  • 零样本分类（zero-shot classfication）
    • 计算文档-标签对的余弦相似度
    • 使用余弦相似度来检查给定文档与候选标签的相似程度，并选择与文档相似度最高的标签

混淆矩阵 ​

• 精确率(precision)衡量模型识别出的结果中有多少是相关的，用来评估相关结果的准确性。
• 召回率(recall)指的是所有相关类别中有多少被成功识别出来，用来评估模型找到所有相关结果的能力。
• 准确率(accuracy)指的是模型在所有预测中做出正确预测的比例，用来评估模型的整体准确性。
• F1分数(F1 score)平衡了精确率和召回率，用于衡量模型的整体性能。

使用生成模型进行文本分类 ​

我们需要帮助模型理解上下文，并引导它得出我们想要的答案。这种引导过程主要通过给模型输入指令或提示词来完成。迭代改进提示词以获得期望的输出的过程被称为提示工程(prompt engineering)。

文本聚类 ​

文本聚类的一般步骤 ​

1. 使用嵌入模型(embedding model)将输入文档转换为嵌入向量。

2. 使用降维模型(dimensionality reduction model)将嵌入向量降至更低维度空间。

3. 使用聚类模型(cluster model)对降维后的嵌入向量进行聚类。

降维 ​

• 随着维度的增加，每个维度中可能的取值数量呈指数级增长，在每个维度中寻找所有子空间变得越来越复杂。
• 降维是一种压缩技术，其底层算法并不是随意删除维度这么简单。
• 降维算法：
  • 主成分分析(Principal Component Analysis，PCA)
  • 统一流形逼近和投影(Uniform Manifold Approximation and Projection，UMAP)

聚类算法 ​

• 基于质心，例如 k-means，需要生成一组预设的簇
• 基于密度，HDBSCAN（Hierarchical Density-Based Spatial Clustering of Applications with Noise，具有噪声的分层密度空间聚类）。HDBSCAN是聚类算法DBSCAN的层次化变体，它无须显式指定簇的数量就能发现密集的（微型）簇。作为一种基于密度的方法，HDBSCAN 还可以检测数据中的离群点，即不属于任何簇的数据点。

主题建模 ​

在文本数据集合中寻找主题或潜在语义的思路，通常被称为主题建模。传统上，主题建模的目标是找到一组最能代表、捕捉主题含义的关键词或短语。

主题建模技术并非将主题标记为“手语”，而是使用诸如“手势”“语言”“翻译”等关键词来描述主题。因此，结果并不是单一的标签，用户需要通过这些关键词来理解主题的含义。

经典方法，如潜在狄利克雷分配(latent Dirichlet allocation，LDA)，假设每个主题都由语料库词表中词的概率分布来表示。这些经典方法通常使用词袋技术提取文本数据的主要特征，而没有考虑词和短语的上下文及含义。相比之下，文本聚类示例则考虑了这两方面，因为它依赖基于Transformer的嵌入向量，这种嵌入向量通过注意力机制针对语义相似性和上下文含义进行了优化。

BERTopic：一个模块化主题建模框架

我们可以对词的初始分布进行重新排序，以改进最终的表示。(即 Rerank)

语言人工智能发展历史简介 ​

词袋 ​

语言人工智能历史始于一种名为词袋(bag-of-words)的技术，其工作原理如下：

1. 分词(tokenization)，即将句子拆分成单个词或子词（词元，token）

2. 将每个句子中所有不同的词组合起来，创建一个可用于表示句子的词表(vocabulary)

3. 使用词表，我们只需计算每个句子中词出现的次数，就创建了一个词袋

word2vec ​

word2vec（词向量）于2013年发布，是首批成功利用嵌入 (embedding)这个概念来捕捉文本含义的技术之一。嵌入是数据的向量表示，试图捕捉数据的含义。为此，word2vec通过在大量文本数据（如整个维基百科）上训练来学习词的语义表示。

我们首先为词表中的每个词分配一个向量嵌入，比如说每个词有50个随机初始化的值。然后在每个训练步骤中，我们从训练数据中取出词对(pairs of words)，用模型尝试预测它们是否可能在句子中相邻。在训练过程中，word2vec会学习词与词之间的关系，并将这些信息提炼到词嵌入中。如果两个词各自的相邻词集合有更大的交集，它们的词嵌入向量就会更接近，反之亦然。

词嵌入可以用多种属性来表示一个词的含义。由于嵌入向量的大小是固定的，这些属性需要经过精心选择，以构建用来代表词的“心智表征”的抽象表示。在实践中，这些属性通常相当抽象，很少与单一实体或人类可识别的概念相关。然而，这些属性组合在一起对计算机来说是有意义的，是将人类语言转换为计算机语言行之有效的方式。

嵌入的类型 ​

• 文档嵌入（词袋）
• 句子嵌入
• 词嵌入（word2vec）
• 词元嵌入

注意力机制（Attention） ​

例如通过 RNN 来进行翻译。这种上下文嵌入方式存在局限性，因为它仅用一个嵌入向量来表示整个输入，使得处理较长的句子变得困难。

注意力机制通过选择性地聚焦于句子中最关键的词，来突出其重要性。

通过在解码步骤中添加这些注意力机制，RNN可以为输入序列中的每个词生成与潜在输出相关的信号。这并不仅仅是将上下文嵌入传递给解码器，而是传递所有输入词的隐藏状态。

Transformer ​

2017年发表的著名论文“Attention is All You Need”首次探讨了注意力机制的真正威力，以及驱动LLM展现出惊人能力的核心所在。作者提出了一种被称为Transformer 的网络架构，它完全基于注意力机制，摒弃了此前提到的RNN。与RNN相比，Transformer支持并行训练，这大大加快了训练速度。

在Transformer中，编码和解码组件相互堆叠。这种架构仍然是自回归的，每个新生成的词都被模型用于生成下一个词。

表示模型：仅编码器模型 ​

原始的Transformer模型是一个编码器-解码器架构，虽然非常适合翻译任务，但难以用于其他任务，比如文本分类。 2018年，研究人员提出了一种名为BERT（bidirectional encoder representations from Transformers，基于Transformer的双向编码器表示）的新架构，它可以应用于各种任务，并在未来几年成为语言人工智能的基石。BERT是一个仅编码器架构，专注于语言表示。

生成模型：仅解码器模型 ​

与BERT的仅编码器架构类似，2018年出现了一种用于处理生成任务的仅解码器架构—— GPT（生成式预训练Transformer，现在被称为GPT-1，以区别于后续版本）。GPT因其生成能力而得名。它与BERT编码器堆叠架构类似，堆叠了多个解码器块。

词元和嵌入 ​

分词器如何分解文本：

• 流行的方法包括字节对编码（BPE，byte pair encoding，广泛用于GPT模型）和WordPiece（用于BERT模型）。
• 分词器需要在特定数据集上进行训练，以建立能最好地表示该数据集的词表。
• 分词器处理输入（输入文本转为token id）和输出（token id转为输出）。

分词方案：

LLM 的内部机制 ​

• 模型并不是一次性生成所有文本，而是一次生成一个词元。每个词元生成步骤都是模型的一次前向传播（在机器学习中，前向传播指的是输入进入神经网络并流经计算图，最终在另一端产生输出所需的计算过程）。
• 在生成当前词元后，我们将输出词元追加到输入提示词的末尾，从而调整下一次生成的输入提示词。
• 当前的Transformer模型对一次可以处理的词元数量有限制，这个限制被称为模型的上下文长度。一个具有4K上下文长度的模型只能处理4000个词元。
• 在生成第二个词元时，我们只是简单地将输出词元追加到输入的末尾，然后再次通过模型进行前向传播。如果模型能够缓存之前的计算结果（特别是注意力机制中的一些特定向量），就不需要重复计算之前的流，而只需要计算最后一条流了。这种优化技术被称为键-值(key-value，KV)缓存，它能显著加快生成过程。

1. 简介 ​

Velox 是由 Meta 开源的一款基于 C++ 实现的通用向量执行引擎，旨在为各种数据系统（如查询引擎、分析数据库、ETL 工具等）提供高性能的底层执行能力。

Velox 的核心设计目标是提升大规模数据分析的性能和效率，同时通过模块化设计促进代码复用，避免各大系统重复“造轮子”。

文档参考。

2. 开发环境搭建 ​

根据项目 README 的介绍，在机器上直接构建，很容易遇到各种问题。目前尝试下来，最方便的方式是在容器环境中构建使用。官方提供了各种环境的镜像。

我所使用的机器环境：

• 零刻 SER8
• CPU: AMD 锐龙 R7-8745HS (8核16线程)
• RAM: 32G

Dockerfile 和构建命令参考如下：

FROM ghcr.io/facebookincubator/velox-dev:ubuntu-22.04

ARG HTTP_PROXY
ARG HTTPS_PROXY

ENV HTTP_PROXY=${HTTP_PROXY}
ENV HTTPS_PROXY=${HTTPS_PROXY}

RUN apt install -y vim && \
    cd / && \
    rm -rf velox && \
    git clone https://github.com/facebookincubator/velox.git && \
    cd velox && \
    ./scripts/setup-ubuntu.sh && \
    make && \
    cmake --install _build/release && \
    cp -r /velox/velox/external/utf8proc /usr/local/include/velox/external/ && \
    rm -rf /velox/_build && \
    rm -rf /velox/deps-download

ENV HTTP_PROXY=""
ENV HTTPS_PROXY=""

#!/bin/bash

proxy="http://192.168.31.2:1087"
tag=$(date +"%Y%m%d")

docker build \
  --build-arg HTTP_PROXY=${proxy} \
  --build-arg HTTPS_PROXY=${proxy} \
  -t velox-dev:${tag} .

# 关闭现有 swap
sudo swapoff -a

# 原有 swap 文件为 /swap.img，新建 /swapfile
sudo fallocate -l 32G /swapfile

# 设置权限
sudo chmod 600 /swapfile

# 格式化为 swap
sudo mkswap /swapfile

# 启用新的 swap
sudo swapon /swapfile

# 验证
sudo swapon --show
# 或
free -h

3. 测试 ​

• 相关代码放在 github 上
• 也可以直接使用构建好的镜像 docker pull ghcr.io/syaning/velox-dev:20251018

#include <iostream>
#include "velox/common/memory/Memory.h"
#include "velox/vector/BaseVector.h"
#include "velox/vector/ComplexVector.h"
#include "velox/vector/ConstantVector.h"
#include "velox/vector/FlatVector.h"

using namespace facebook::velox;

int main()
{
    // init memory pool
    memory::MemoryManager::initialize({});
    auto memoryManager = memory::MemoryManager::getInstance();
    auto rootPool = memoryManager->addRootPool("root");
    auto leafPool = rootPool->addLeafChild("leaf");

    // create id vector with values 1 to 7
    auto id = BaseVector::create(INTEGER(), 7, leafPool.get());
    auto *idValues = id->asFlatVector<int32_t>()->mutableRawValues();
    for (vector_size_t i = 0; i < id->size(); ++i)
    {
        idValues[i] = static_cast<int32_t>(i + 1);
    }

    // create constant vector with value 42
    auto con =
        BaseVector::createConstant(INTEGER(), Variant(42), 7, leafPool.get());

    // create day_of_week vector with string values
    auto dow = BaseVector::create(VARCHAR(), 7, leafPool.get());
    auto *dowValues = dow->asFlatVector<StringView>()->mutableRawValues();
    std::vector<std::string> days = {
        "monday",
        "tuesday",
        "wednesday",
        "thursday",
        "friday",
        "saturday",
        "sunday"};
    for (vector_size_t i = 0; i < dow->size(); ++i)
    {
        dowValues[i] = StringView(days[i]);
    }

    // create row vector with the above three vectors as children
    std::vector<std::string> names = {"id", "constant_42", "day_of_week"};
    std::vector<TypePtr> types = {INTEGER(), INTEGER(), VARCHAR()};
    auto rowType = ROW(std::move(names), std::move(types));
    std::vector<VectorPtr> children = {id, con, dow};
    auto rowVector = std::make_shared<RowVector>(
        leafPool.get(), rowType, nullptr, id->size(), std::move(children));

    std::cout << rowVector->toString() << std::endl;
    std::cout << rowVector->toString(0, rowVector->size()) << std::endl;

    return 0;
}

cmake_minimum_required(VERSION 3.18)
project(velox_demo LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_FIND_LIBRARY_PREFERENCE "STATIC")
set(CMAKE_FIND_LIBRARY_SUFFIXES ".a";".so")

find_path(VELOX_INCLUDE_DIR velox
          HINTS /usr/local/include)
find_library(VELOX_LIBRARY velox
             HINTS /usr/local/lib/velox
                   /usr/local/lib)

include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Velox REQUIRED
    VELOX_INCLUDE_DIR VELOX_LIBRARY)

if(VELOX_FOUND)
    add_library(velox UNKNOWN IMPORTED)
    set_target_properties(velox PROPERTIES
        IMPORTED_LOCATION ${VELOX_LIBRARY}
        INTERFACE_INCLUDE_DIRECTORIES ${VELOX_INCLUDE_DIR}
    )
endif()

add_executable(demo demo.cpp)
target_link_libraries(demo PRIVATE
    velox
    folly
    boost_context
    double-conversion
    event
    fmt
    gflags
    glog
    re2
    unwind
)

#!/bin/bash

rm -rf build
mkdir build

cd build
cmake ..
cmake --build .

./demo

1. ANTLR 介绍 ​

ANTLR (ANother Tool for Language Recognition) 是一款强大的语法分析器生成工具。它广泛应用于构建语言识别工具，如编译器、解释器、解析器等。ANTLR 通过定义语法规则自动生成词法分析器和语法分析器，极大地简化了开发过程。

通常来说，如果我们需要实现一个编程语言或者 DSL（Domain Specific Language）的编译器或解释器，需要：

1. 定义语法：使用 ANTLR 的话，我们可以通过 ANTLR 元语言（ANTLR's meta-language）来定义语法。
2. 词法分析（Lexical Analysis）或词法符号化（Tokenizing）：将源代码的字符序列分割为有意义的符号单元（token），例如关键字、标识符、运算符、分隔符等。这一步的程序我们称之为 Lexer 或 Tokenizer。
3. 语法分析（Syntax Analysis）：将 tokens 生成表示程序结构的抽象语法树（Abstract Syntax Tree, AST），或者叫做语法分析树（Parse Tree）或者句法树（Syntax Tree）。这一步的程序我们称之为 Parser。
4. 对语法树遍历执行。

2. 实现一个计算器 ​

2.1 需求 ​

实现一个计算器程序：

• 支持加减乘除、取模、幂运算
• 暂时只考虑非负整数操作，不考虑浮点数和负数

2.2 安装 ​

参考 Getting Started with ANTLR v4 下载：

curl -O https://www.antlr.org/download/antlr-4.13.2-complete.jar

2.3 语法定义 ​

lexer grammar CalculatorLexer;

ADD : '+';
SUB : '-';
MUL : '*';
DIV : '/';
MOD : '%';
EXP : '**';

LEFT_PAREN  : '(';
RIGHT_PAREN : ')';
NUMBER      : [1-9] [0-9]*;
WHITESPACE  : [ \t\r\n\u000C]+ -> skip;

parser grammar CalculatorParser;

options {
    tokenVocab = CalculatorLexer;
}

prog: expr EOF;

expr: expr EXP expr
    | expr (MUL|DIV|MOD) expr
    | expr (ADD|SUB) expr
    | NUMBER
    | LEFT_PAREN expr RIGHT_PAREN
    ;

2.4 调试 ​

#!/bin/bash

alias antlr4-parse='java -Xmx500M -cp "./antlr-4.13.2-complete.jar:$CLASSPATH" org.antlr.v4.gui.TestRig'
antlr4-parse *.g4 prog -gui

执行 ./grun.sh，输入表达式，例如 (1 + 2) * 3 - (5 % 3) ** 2，然后按 Ctrl + D：

可以看到解析的语法树如下：

除了 -gui 选项外，还可以使用 -tree（以 LISP 格式输出语法分析树）或者 -tokens（输出词法符号流）选项来进行调试。

2.5 代码生成 ​

该例子中，我们生成 Go 的代码，如果需要生成其它语言的代码，可以参考官方文档。

#!/bin/bash

alias antlr4='java -Xmx500M -cp "./antlr-4.13.2-complete.jar:$CLASSPATH" org.antlr.v4.Tool'
antlr4 -Dlanguage=Go -visitor -package parsing *.g4 -o ../parsing

package grammar

//go:generate ./generate.sh

执行 go generate ./...，可以生成解析器代码，生成的代码在 ../parser 目录下。

• calculator_lexer.go: 词法分析器
• calculator_parser.go: 语法分析器
• *.tokens: 词法符号表，定义了标记及其对应的整数标识符，帮助理解和调试标记识别过程
• *.interp: 包含了解析器和词法分析器的内部状态信息，用于优化解析性能和支持高级功能
• calculatorparser_listener.go: 定义了监听器接口，允许你在解析过程中监听特定事件
• calculatorparser_base_listener.go: 监听器的默认实现
• calculatorparser_visitor.go: 定义了访问器接口，允许你遍历和处理抽象语法树
• calculatorparser_base_visitor.go: 访问器的默认实现

2.6 实现 Listener ​

语法解析的过程如下图所示：

1. 原始文本解析成 ChartStream
2. 经过 lexer 将 ChartStream 解析为 TokenStream
3. 经过 parser 将 TokenStream 解析为语法树，语法树包含两类节点：RuleNode（子树的根节点）和 TerminalNode（叶子结点）

对应的语法树如下所示，其中 ProgContext 和 ExprContext 都是 calculator_parser.go 中生成的代码。

语法树会按照深度优先的方式进行遍历，过程如下图所示：

• 每个 RuleNode 的访问都有 Enter 和 Exit 两个监听
• TerminalNode 的访问会有 VisitTerminal 监听

可以先实现一个简单的 Listener:

package calc

import (
    "fmt"

    "github.com/antlr4-go/antlr/v4"

    "calculator/parsing"
)

type CalculatorListener struct {
    *parsing.BaseCalculatorParserListener
}

func NewCalculatorListener() *CalculatorListener {
    return &CalculatorListener{
        BaseCalculatorParserListener: &parsing.BaseCalculatorParserListener{},
    }
}

func (l *CalculatorListener) VisitTerminal(node antlr.TerminalNode) {
    fmt.Println("VisitTerminal", node.GetText())
}

func (l *CalculatorListener) EnterProg(ctx *parsing.ProgContext) {
    fmt.Println("EnterProg", ctx.GetText())
}

func (l *CalculatorListener) ExitProg(ctx *parsing.ProgContext) {
    fmt.Println("ExitProg", ctx.GetText())
}

func (l *CalculatorListener) EnterExpr(ctx *parsing.ExprContext) {
    fmt.Println("EnterExpr", ctx.GetText())
}

func (l *CalculatorListener) ExitExpr(ctx *parsing.ExprContext) {
    fmt.Println("ExitExpr", ctx.GetText())
}

package main

import (
    "calculator/calc"
    "calculator/parsing"

    "github.com/antlr4-go/antlr/v4"
)

func parseTree(prog string) antlr.ParseTree {
    input := antlr.NewInputStream(prog)
    lexer := parsing.NewCalculatorLexer(input)

    stream := antlr.NewCommonTokenStream(lexer, 0)
    parser := parsing.NewCalculatorParser(stream)

    return parser.Prog()
}

func main() {
    prog := `12 + 34`
    tree := parseTree(prog)

    listener := calc.NewCalculatorListener()
    antlr.ParseTreeWalkerDefault.Walk(listener, tree)
}

可以看到输出的结果为：

EnterProg 12+34<EOF>
EnterExpr 12+34
EnterExpr 12
VisitTerminal 12
ExitExpr 12
VisitTerminal +
EnterExpr 34
VisitTerminal 34
ExitExpr 34
ExitExpr 12+34
VisitTerminal <EOF>
ExitProg 12+34<EOF>

然后我们可以按照如下的思路，实现一个能实际进行计算的 Listener：

• VisitTerminal() 的时候，如果是数值类型，则入栈（也可以在 ExitExpr() 的时候，判断如果子节点只有一个，则进行入栈）
• ExitExpr() 的时候，如果有三个子节点，且中间的节点为 TerminalNode，则从栈中取出两个元素，进行计算后将结果入栈
• ExitProg() 的时候，正常栈中只有最终的结果，直接返回即可

package calc

import (
    "fmt"
    "math"
    "strconv"

    "github.com/antlr4-go/antlr/v4"

    "calculator/parsing"
)

type CalculatorListener struct {
    *parsing.BaseCalculatorParserListener
    nums []int64
}

func NewCalculatorListener() *CalculatorListener {
    return &CalculatorListener{
        BaseCalculatorParserListener: &parsing.BaseCalculatorParserListener{},
    }
}

func (l *CalculatorListener) pop() int64 {
    if len(l.nums) == 0 {
        panic("Invalid expression")
    }
    size := len(l.nums)
    val := l.nums[size-1]
    l.nums = l.nums[:size-1]
    return val
}

func (l *CalculatorListener) VisitTerminal(node antlr.TerminalNode) {
    if node.GetSymbol().GetTokenType() == parsing.CalculatorParserNUMBER {
        num, err := strconv.ParseInt(node.GetText(), 10, 64)
        if err == nil {
            l.nums = append(l.nums, num)
        }
    }
}

func (l *CalculatorListener) ExitProg(ctx *parsing.ProgContext) {
    if len(l.nums) != 1 {
        panic("Invalid expression")
    }
    fmt.Println(l.nums[0])
}

func (l *CalculatorListener) ExitExpr(ctx *parsing.ExprContext) {
    if ctx.GetChildCount() == 3 {
        if op, ok := ctx.GetChild(1).(antlr.TerminalNode); ok {
            right, left := l.pop(), l.pop()

            switch op.GetSymbol().GetTokenType() {
            case parsing.CalculatorParserADD:
                l.nums = append(l.nums, left+right)
            case parsing.CalculatorParserSUB:
                l.nums = append(l.nums, left-right)
            case parsing.CalculatorParserMUL:
                l.nums = append(l.nums, left*right)
            case parsing.CalculatorParserDIV:
                l.nums = append(l.nums, left/right)
            case parsing.CalculatorParserMOD:
                l.nums = append(l.nums, left%right)
            case parsing.CalculatorParserEXP:
                l.nums = append(l.nums, int64(math.Pow(float64(left), float64(right))))
            }
        }
    }
}

2.7 分支标签 ​

我们可以进一步优化，为 expr 的不同分支打上标签，来优化 Listener 的实现。

• 为 expr 的每个分支打上标签（即 # xxx)，并且为操作符号指定名称为 op
• 然后重新生成代码，会发现每个分支都有单独的 Enter / Exit 方法
• ExitNumber() 的时候数值入栈，ExitExp() / ExitMulDivMod() / ExitAddSub() 的时候进行相应的运算即可

parser grammar CalculatorParser;

options {
    tokenVocab = CalculatorLexer;
}

prog: expr EOF;

expr: expr op=EXP expr            # Exp
    | expr op=(MUL|DIV|MOD) expr  # MulDivMod
    | expr op=(ADD|SUB) expr      # AddSub
    | NUMBER                      # Number
    | LEFT_PAREN expr RIGHT_PAREN # Parens
    ;

package calc

import (
    "fmt"
    "math"
    "strconv"

    "calculator/parsing"
)

type CalculatorListener struct {
    *parsing.BaseCalculatorParserListener
    nums []int64
}

func NewCalculatorListener() *CalculatorListener {
    return &CalculatorListener{
        BaseCalculatorParserListener: &parsing.BaseCalculatorParserListener{},
    }
}

func (l *CalculatorListener) pop() int64 {
    if len(l.nums) == 0 {
        panic("Invalid expression")
    }
    size := len(l.nums)
    val := l.nums[size-1]
    l.nums = l.nums[:size-1]
    return val
}

func (l *CalculatorListener) ExitProg(ctx *parsing.ProgContext) {
    if len(l.nums) != 1 {
        panic("Invalid expression")
    }
    fmt.Println(l.nums[0])
}

func (l *CalculatorListener) ExitNumber(ctx *parsing.NumberContext) {
    num, err := strconv.ParseInt(ctx.GetText(), 10, 64)
    if err == nil {
        l.nums = append(l.nums, num)
    }
}

func (l *CalculatorListener) ExitExp(ctx *parsing.ExpContext) {
    right, left := l.pop(), l.pop()
    l.nums = append(l.nums, int64(math.Pow(float64(left), float64(right))))
}

func (l *CalculatorListener) ExitMulDivMod(ctx *parsing.MulDivModContext) {
    right, left := l.pop(), l.pop()
    switch ctx.GetOp().GetTokenType() {
    case parsing.CalculatorParserMUL:
        l.nums = append(l.nums, left*right)
    case parsing.CalculatorParserDIV:
        l.nums = append(l.nums, left/right)
    case parsing.CalculatorParserMOD:
        l.nums = append(l.nums, left%right)
    }
}

func (l *CalculatorListener) ExitAddSub(ctx *parsing.AddSubContext) {
    right, left := l.pop(), l.pop()
    switch ctx.GetOp().GetTokenType() {
    case parsing.CalculatorParserADD:
        l.nums = append(l.nums, left+right)
    case parsing.CalculatorParserSUB:
        l.nums = append(l.nums, left-right)
    }
}

2.8 实现 visitor ​

使用 visitor 的方式区别于事件监听的方式，而是可以手动控制如何遍历子节点，以及访问特定类型节点时如何做。下面是一个完整的实现。

package calc

import (
    "math"
    "strconv"

    "calculator/parsing"

    "github.com/antlr4-go/antlr/v4"
)

type CalculatorVisitor struct {
    *parsing.BaseCalculatorParserVisitor
}

func NewCalculatorVisitor() *CalculatorVisitor {
    return &CalculatorVisitor{
        BaseCalculatorParserVisitor: &parsing.BaseCalculatorParserVisitor{},
    }
}

func (v *CalculatorVisitor) Visit(tree antlr.ParseTree) interface{} {
    return tree.Accept(v)
}

func (v *CalculatorVisitor) VisitProg(ctx *parsing.ProgContext) interface{} {
    return v.Visit(ctx.Expr())
}

func (v *CalculatorVisitor) VisitNumber(ctx *parsing.NumberContext) interface{} {
    val, _ := strconv.ParseInt(ctx.GetText(), 10, 64)
    return val
}

func (v *CalculatorVisitor) VisitExp(ctx *parsing.ExpContext) interface{} {
    left := v.Visit(ctx.Expr(0)).(int64)
    right := v.Visit(ctx.Expr(1)).(int64)
    return int64(math.Pow(float64(left), float64(right)))
}

func (v *CalculatorVisitor) VisitMulDivMod(ctx *parsing.MulDivModContext) interface{} {
    left := v.Visit(ctx.Expr(0)).(int64)
    right := v.Visit(ctx.Expr(1)).(int64)
    if ctx.GetOp().GetTokenType() == parsing.CalculatorParserMUL {
        return left * right
    }
    if ctx.GetOp().GetTokenType() == parsing.CalculatorParserDIV {
        return left / right
    }
    return left % right
}

func (v *CalculatorVisitor) VisitAddSub(ctx *parsing.AddSubContext) interface{} {
    left := v.Visit(ctx.Expr(0)).(int64)
    right := v.Visit(ctx.Expr(1)).(int64)
    if ctx.GetOp().GetTokenType() == parsing.CalculatorParserADD {
        return left + right
    }
    return left - right
}

func (v *CalculatorVisitor) VisitParens(ctx *parsing.ParensContext) interface{} {
    return v.Visit(ctx.Expr())
}

package main

import (
    "fmt"

    "calculator/calc"
    "calculator/parsing"

    "github.com/antlr4-go/antlr/v4"
)

func parseTree(prog string) antlr.ParseTree {
    input := antlr.NewInputStream(prog)
    lexer := parsing.NewCalculatorLexer(input)

    stream := antlr.NewCommonTokenStream(lexer, 0)
    parser := parsing.NewCalculatorParser(stream)

    return parser.Prog()
}

func main() {
    prog := `(1 + 2) * 3 - (5 % 3) * 2`
    tree := parseTree(prog)

    visitor := calc.NewCalculatorVisitor()
    result := visitor.Visit(tree)
    fmt.Println(result)
}

工作思考 ​

• 有种说法是“一流公司做标准，二流公司做品牌，三流公司做服务，四流公司做价格”。本质上也就是“顶层架构→实现→集成”。做产品也是类似，尽可能地去做标准，做平台，让别人集成你而不是自己苦哈哈地去做各种集成。大道至简，小而美胜过大而无当。
• 不去做所有的事，不去赚所有的钱。考虑到边际效应，合作共赢，各取所长，才是最高效的商业逻辑。避免把技术密集型的事情做成劳动密集型。
• 不要被客户第一这句口号所绑架。客户第一只是一层皮，最终一定是商业利益。为了特定需求做定制，服务于少数几个客户，这只是狭隘的客户第一，与商业利益也是相悖的。真正的客户第一，面向的客户一定是广大的群体，需求一定是通用的，这与最终的商业利益也是一致的。
• 公司层面讲究 ROI，对于自己也是如此。尽量做有价值的事情，做对自己成长或收获有帮助的事情。靠谱的事情认真做。不靠谱的事情大多是层层拍脑袋的无稽之谈，或者无价值无意义的琐事，交差即可。

优雅编码 ​

• 尽量用 Pure Function，避免副作用。
• 避免很多个平铺参数，可以使用一个结构参数来替代，也方便后续扩展。
• 除非复用的公共变量，否则尽量就近定义。
• 合理注释，关键信息、关键逻辑一定要注释，如有必要添加相关的说明以及对应的设计文档链接。
• 可复用组件。DRY 原则。
• 避免滥封装工具 Utils。避免无效封装，例如对函数做一层不必要的包装，空字符串额外定义为 nilString 等。
• 合理组织代码结构，避免大文件、大函数。
• 在开发过程中重构，防微杜渐。不断重构本质上就是常常打扫卫生，而不是等到房间乱到不能再乱的时候统一丢弃。
• 模块化设计，高内聚低耦合。本质上就是收纳，相关物品打包放盒子里，大盒子套小盒子。
• 业务逻辑和算法逻辑分离。业务逻辑可以调用算法，算法逻辑中不要耦合业务。

关注的项目 ​

• maybe - The OS for your personal finances.
• glance - A self-hosted dashboard that puts all your feeds in one place.
• asdf - Manage multiple runtime versions with a single CLI tool, extendable via plugins.
• lucide - Beautiful & consistent icon toolkit made by the community. Open-source project and a fork of Feather Icons.
• OpenGFW

Less is More ​

过年回到老家，突然之间多了许多琐碎的事情。仅仅是过年前的准备都有好多。贴春联、挂灯笼，还有各种各样的仪式和讲究。并非是对传统习俗有什么偏见，只是对我来说，最讨厌繁文缛节，尤其是各种各样没有意义的流程，很多甚至都不能称之为习俗，可能只是家庭范围内流传下来的习惯罢了。生活简单一些，自己身心也轻松一些，不是更好么。

由此想到简洁与繁琐的对立。比如许多音乐 APP 都喜欢做得臃肿无比，加入了各种广告、社交、直播等功能，实在是让人喜欢不起来，所以最终我还是用回了 Apple Music。还有国内的许多的流媒体应用，也是各种花式的操作，暂停了也得看个广告，我其实就想看下画面细节，但是做不到。以至于我宁愿找资源存在 NAS 上然后用 Jellyfin 来看。虽然其中有很多商业的因素存在，但从用户的角度来说，我还是更喜欢纯粹一些的使用体验，至少作为单一的用户个体，我有选择不被恶心的权利。

关于纯粹，许多人许多事情，在浑浑噩噩的发展过程中，已经变得失其本心了。

一直很喜欢的《道德经》第二十二章：

曲则全，枉则直，洼则盈，敝则新，少则多，多则惑。是以圣人执一为天下式。不自见，故明；不自是，故彰；不自伐，故有功；不自矜，故能长。夫唯不争，故天下莫能与之争。……

关注的项目 ​

• markmap: 基于 markdown 的思维导图，感觉后面有需要的话可以在 vitepress 里去集成下，这样博客就直接可以生成思维导图了，不需要嵌入图片。
• utterances: 基于 github issue 的评论系统，不过暂时没打算给博客加评论，先收藏下。
• GitButler: 使用 Tauri + Rust 实现的 git 分支管理应用，看着挺好看的。不过个人更倾向于命令行来使用，先关注下。
• typst: 新的排版系统，对标 LaTeX.

One More Thing ​

新年快乐！🎆