杂谈 on 菜鸟程序员

AI基础知识科普

Mon, 01 Jan 0001 00:00:00 +0000

AI核心概念名词解释

基础类术语

AI（Artificial Intelligence）人工智能：广义上指的是让机器具备类似人类的思考、学习、决策等智能行为的技术总称。

AGI（Artificial General Intelligence）通用人工智能：一种尚未实现的 AI 类型，能像人类一样，具备跨领域学习和通用推理能力。

Narrow AI（狭义人工智能）：目前主流 AI 类型，专注在特定任务领域（如语音识别、下围棋）表现优秀，但无法迁移能力。

ML（Machine Learning）机器学习：AI 的一个子领域，强调通过数据训练模型，让系统自动学习模式，而非手工编程规则。

DL（Deep Learning）深度学习：机器学习的一个子集，使用多层神经网络（通常 3 层以上）自动提取特征并完成复杂任务。

模型与算法类

模型（Model）：训练完成后的 AI 实体，用来对新数据进行推理和输出。例如：GPT 就是一个语言模型。

训练（Training）：通过数据喂入模型，反复调整参数，使模型学会输入与输出之间的对应关系的过程。

推理 / 推断（Inference）：模型在训练完成后，对新输入做出判断或生成输出的过程。

参数（Parameters）：模型中可以学习的数值，决定模型输出。例如 GPT-4 有数千亿个参数。

权重（Weights）：神经网络中连接节点的值，是模型学习到的核心内容。

Loss Function（损失函数）：衡量模型输出结果与实际值之间差异的函数。优化目标是“最小化损失”。

Overfitting（过拟合）：模型学得太“死板”，只记住训练集数据，导致泛化能力差。

Fine-tuning（微调）：在已有大模型的基础上，用特定领域数据再次训练，使模型更适应某个细分任务。

生成式 AI 类（大模型领域）

LLM（Large Language Model）大语言模型：使用海量文本训练出的模型，具备文本生成、翻译、总结、问答等能力。代表如：GPT、Claude、Gemini。

Prompt（提示词）：输入给大模型的一段文字，用来引导其生成特定内容。

Prompt Engineering（提示词工程）：通过精心设计提示词，提高生成质量或实现复杂功能的技巧。

Hallucination（幻觉）：AI 模型生成看似合理但实际上是虚假的信息，可能误导用户。

Token（标记）：LLM 将文本分解的最小单位（可能是一个字、词或词根），模型以 Token 形式处理语言。

Top-k / Top-p Sampling：生成式模型中的输出采样策略，用于控制生成内容的多样性与准确性。

RAG（Retrieval-Augmented Generation）检索增强生成：结合搜索引擎 + LLM 的混合架构，模型在生成内容前可访问外部知识库，以提高准确性。

多模态与交互类

多模态（Multimodal）：模型能同时处理多种信息形式：文本、语音、图像、视频。例如：GPT-4o、Gemini 可看图回答问题。

csdn自动跳转清除

Mon, 01 Jan 0001 00:00:00 +0000

find . -name "*.html" -exec sed -i '/window.location.href/d' {} \;

Git

Mon, 01 Jan 0001 00:00:00 +0000

Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

分支操作(默认的主分支名为 master)

创建分支并切换: git checkout -b 分支名称
等同于下面两句话
(
1.创建分支: git branch 分支名称
2.切换到某分支: git checkout 分支名称
)
本地创建分支并关联远程分支: git checkout -b 本地分支名 origin/远程分支名
建立本地分支和远程分支的关联，使用: git branch --set-upstream 本地分支名 origin/远程分支名

合并指定分支到当前分支: git merge 目标分支名

查看所有本地分支(当前分支前会有一个*号): git branch

删除某个分支: git branch -d 分支名

强行删除分支: git branch -D 分支名
用带参数的git log也可以看到分支的合并情况: git log --graph --pretty=oneline --abbrev-commit (用git log --graph命令可以看到分支合并图)

带参数的合并,并产生一个新的commit: git merge --no-ff -m "merge with no-ff" dev

存储当前工作空间,解决其他问题,并还原
 1. git stash "贮藏描述" (存储当前工作区)
 2. 其他操作,例如修复bug要创建新的分支,提交合并并且删除bug分支
 3. git stash list (查看工作区)
 (会输出)
 stash@{0}: WIP on master: 2b5faea new info text
 stash@{1}: WIP on dev: b0f1f6a conflict fixed
 stash@{2}: WIP on dev: b0f1f6a conflict fixed
 4. git shash apply stash@{n} (恢复到哪个工作区)
 5. git shash drop(删除缓冲区序号最小的工作区)
 (6. 45两步可以用 git stash pop 会直接还原到序号最小的工作区并将其删除)

拉取: git pull 如果有冲突，要先处理冲突。

标签 Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。打一个新的标签: git tag 标签名给某一个历史提交打标签: git tag 标签名提交Hash

代码编写指南

Mon, 01 Jan 0001 00:00:00 +0000

01

细节即是架构

下面是原文摘录，我有类似观点，但是原文就写得很好，直接摘录。

一直以来，设计(Design)和架构(Architecture)这两个概念让大多数人十分迷惑–什么是设计？什么是架构？二者究竟有什么区别？二者没有区别。一丁点区别都没有！“架构"这个词往往适用于"高层级"的讨论中，这类讨论一般都把"底层"的实现细节排除在外。而"设计"一词，往往用来指代具体的系统底层组织结构和实现的细节。但是，从一个真正的系统架构师的日常工作来看，这些区分是根本不成立的。以给我设计新房子的建筑设计师要做的事情为例。新房子当然是存在着既定架构的，但这个架构具体包含哪些内容呢？首先，它应该包括房屋的形状、外观设计、垂直高度、房间的布局，等等。

但是，如果查看建筑设计师使用的图纸，会发现其中也充斥着大量的设计细节。譬如，我们可以看到每个插座、开关以及每个电灯具体的安装位置，同时也可以看到某个开关与所控制的电灯的具体连接信息；我们也能看到壁炉的具体位置，热水器的大小和位置信息，甚至是污水泵的位置；同时也可以看到关于墙体、屋顶和地基所有非常详细的建造说明。总的来说，架构图里实际上包含了所有的底层设计细节，这些细节信息共同支撑了顶层的架构设计，底层设计信息和顶层架构设计共同组成了整个房屋的架构文档。

软件设计也是如此。底层设计细节和高层架构信息是不可分割的。他们组合在一起，共同定义了整个软件系统，缺一不可。所谓的底层和高层本身就是一系列决策组成的连续体，并没有清晰的分界线。

我们编写、review 细节代码，就是在做架构设计的一部分。我们编写的细节代码构成了整个系统。我们就应该在细节 review 中，始终带着所有架构原则去审视。你会发现，你已经写下了无数让整体变得丑陋的细节，它们背后，都有前人总结过的架构原则。

02

把代码和文档绑在一起(自解释原则)

写文档是个好习惯。但是写一个别人需要咨询老开发者才能找到的文档，是个坏习惯。这个坏习惯甚至会给工程师们带来伤害。比如，当初始开发者写的文档在一个犄角旮旯(在 wiki 里，但是阅读代码的时候没有在明显的位置看到链接)，后续代码被修改了，文档已经过时，有人再找出文档来获取到过时、错误的知识的时候，阅读文档这个同学的开发效率必然受到伤害。所以，如同 Golang 的 godoc 工具能把代码里“按规范来”的注释自动生成一个文档页面一样，我们应该:

▶︎ 按照 godoc 的要求好好写代码的注释。

▶︎ 代码首先要自解释，当解释不了的时候，需要就近、合理地写注释。

▶︎ 当小段的注释不能解释清楚的时候，应该有 doc.go 来解释，或者在同级目录的 ReadMe.md 里注释讲解。

▶︎ 文档需要强大的富文本编辑能力，Down 无法满足，可以写到 wiki 里，同时必须把 wiki 的简单描述和链接放在代码里合适的位置。让阅读和维护代码的同学一眼就看到，能做到及时的维护。

以上总结起来就是，解释信息必须离被解释的东西越近越好。代码能做到自解释，是最棒的。

03

ETC 价值观(easy to change)

ETC 是一种价值观念，不是一条原则。价值观念是帮助你做决定的: 我应该做这个，还是做那个？当你在软件领域思考时，ETC 是个向导，它能帮助你在不同的路线中选出一条。就像其他一些价值观念一样，你应该让它漂浮在意识思维之下，让它微妙地将你推向正确的方向。

敏捷软件工程，所谓敏捷，就是要能快速变更，并且在变更中保持代码的质量。所以，持有 ETC 价值观看待代码细节、技术方案，我们将能更好地编写出适合敏捷项目的代码。这是一个大的价值观，不是一个基础微观的原则，所以没有例子。本文提到的所有原则，或直接，或间接，都要为 ETC 服务。

04

DRY 原则(don not repeat yourself)

华为C语言编码规范

Mon, 01 Jan 0001 00:00:00 +0000

作为程序开发者，避免不了阅读别人代码，那么就会涉及到到一门语言的编程规范。规范虽然不是语言本身的硬性要求，但是已经是每一个语言使用者约定俗成的一个规范。

按照编程规范编写的代码，至少在代码阅读时，给人一种愉悦的心情，特别是强迫症患者。另一方面，统一的编程风格，可以减少编写错误，利于后期维护。

因为最近又开始进行纯C语言的开发，并且是基于SDK的开发，所以添加的每一行代码都应该与原来风格保持一致，不能因为一颗老鼠屎坏了一锅汤。一个良好的编程规范也可以看出编程人员的细心程度与代码质量。

之前待过的两家公司，也都有各自总结的编程规范，但都不约而同的一致，适用本公司的软件开发。这几天有幸可以参阅华为技术有限公司的C语言编程规范，相比之下，写的更加详细。

至少接触到了，在这个编程规范中体现了，并且还扩充了很多，我觉得有必要归纳总结，一遍日后查阅。先是学习规范，然后再积累规范，最后才是依规范编写。

1、清晰第一

清晰性是易于维护、易于重构的程序必需具备的特征。代码首先是给人读的,好的代码应当可以像文章一样发声朗诵出来。

2.、简洁为美

简洁就是易于理解并且易于实现。代码越长越难以看懂，也就越容易在修改时引入错误。写的代码越多，意味着出错的地方越多，也就意味着代码的可靠性越低。因此，我们提倡大家通过编写简洁明了的代码来提升代码可靠性。废弃的代码(没有被调用的函数和全局变量)要及时清除，重复代码应该尽可能提炼成函数。

3、选择合适的风格，与代码原有的风格保持一致

产品所有人共同分享同一种风格所带来的好处，远远超出为了统一而付出的代价。在公司已有编码规范的指导下，审慎地编排代码以使代码尽可能清晰，是一项非常重要的技能。如果重构/修改其他风格的代码时，比较明智的做法是根据现有代码的现有风格继续编写代码,或者使用格式转换工具进行转换成公司内部风格。

一、头文件

原则1.1 头文件中适合放置接口的声明,不适合放置实现。

说明:头文件是模块(Module)或单元(Unit)的对外接口。头文件中应放置对外部的声明,如对外提供的函数声明、宏定义、类型定义等。

原则1.2 头文件应当职责单一。

说明:头文件过于复杂，依赖过于复杂是导致编译时间过长的主要原因。很多现有代码中头文件过大，职责过多，再加上循环依赖的问题，可能导致为了在.c中使用一个宏，而包含十几个头文件。

原则1.3 头文件应向稳定的方向包含。

说明:头文件的包含关系是一种依赖，一般来说，应当让不稳定的模块依赖稳定的模块，从而当不稳定的模块发生变化时，不会影响(编译)稳定的模块。

规则1.1 每一个.c文件应有一个同名.h文件,用于声明需要对外公开的接口。

说明:如果一个.c文件不需要对外公布任何接口，则其就不应当存在，除非它是程序的入口，如main函数所在的文件。

规则1.2 禁止头文件循环依赖。

说明:头文件循环依赖，指a.h包含b.h，b.h包含c.h，c.h包含a.h之类导致任何一个头文件修改，都导致所有包含了a.h/b.h/c.h的代码全部重新编译一遍。

而如果是单向依赖，如a.h包含b.h，b.h包含c.h,而c.h不包含任何头文件，则修改a.h不会导致包含了b.h/c.h的源代码重新编译。

规则1.3 .c/.h文件禁止包含用不到的头文件。

说明:很多系统中头文件包含关系复杂，开发人员为了省事起见,可能不会去一一钻研，直接包含一切想到的头文件，甚至有些产品干脆发布了一个god.h,其中包含了所有头文件，然后发布给各个项目组使用，这种只图一时省事的做法，导致整个系统的编译时间进一步恶化,并对后来人的维护造成了巨大的麻烦。

规则1.4 头文件应当自包含。

说明:简单的说，自包含就是任意一个头文件均可独立编译。如果一个文件包含某个头文件，还要包含另外一个头文件才能工作的话，就会增加交流障碍，给这个头文件的用户增添不必要的负担。

规则1.5 总是编写内部#include保护符(#define 保护)。

说明:多次包含一个头文件可以通过认真的设计来避免。如果不能做到这一点，就需要采取阻止头文件内容被包含多于一次的机制。

注: 没有在宏最前面加上 _ ，即使用 FILENAME_H代替 FILENAME_H ，是因为一般以 _ 和 __ 开头的标识符为系统保留或者标准库使用，在有些静态检查工具中，若全局可见的标识符以 _ 开头会给出告警。

定义包含保护符时，应该遵守如下规则:

1)保护符使用唯一名称;

2)不要在受保护部分的前后放置代码或者注释。

规则1.6 禁止在头文件中定义变量。

说明:在头文件中定义变量，将会由于头文件被其他.c文件包含而导致变量重复定义。

规则1.7 只能通过包含头文件的方式使用其他.c提供的接口,禁止在.c中通过extern的方式使用外部函数接口、变量。

说明:若a.c使用了b.c定义的foo()函数，则应当在b.h中声明extern int foo(int input)；并在a.c中通过#include <b.h>来使用foo。禁止通过在a.c中直接写extern int foo(int input)；来使用foo，后面这种写法容易在foo改变时可能导致声明和定义不一致。这一点我们因为图方便经常犯的。

开发技术选型

Mon, 01 Jan 0001 00:00:00 +0000

综合技术选型

存储

关系型

MySQL
- 连接池选择
  - Druid
  - HikariCP（spring默认连接池）
Oracle(除了政府项目，一般用不到)
Sqlite(客户端项目比较好用)

非关系型

redis
- 客户端选型
  - Ridisson（98）
  - RedisTemplate（80）
  - Jedis（60）
ElesticSearch
- 客户端选型
  - Spring Data ElasticSearch（95）
  - bboss-elasticsearch（75）
  - elasticsearch-sql（60）

数据库管理

SQL审核

Yearning http://yearning.io/
Archery https://archerydms.com/

binlog解析

MyFlash
binlog2sql
Archery工具包也具有binlog解析能力

Percona Toolkit 工具包

Percona Toolkit 工具包是一组高级的管理 MySQL 的工具包集，可以用来执行各种通过手工执行非常复杂和麻烦的系统任务。简称 PT 工具，由 Percona 公司开发维护，是广大数据库维护人员的好帮手。

pt-archiver：主要用于清理、归档历史数据。
pt-duplicate-key-checker：列出并删除重复的索引和外键。
pt-kill：杀掉符合条件的数据库连接。
pt-online-schema-change：在线修改表结构，常用于大表 DDL 。
pt-query-digest：分析 MySQL 日志，并产生报告，常用于慢日志分析。
pt-table-checksum：校验主从复制一致性。

MQ

RocketMQ（95）
1. 支持延迟消息
2. 吞吐量也够大
RabbitMQ（85）
1. 支持延迟消息
2. 吞吐量略小（但对于一般项目足够了）
Kafka（75）
1. 不支持延迟消息
2. 吞吐量大，适用于数据量很大的场景，比如：日志收集
activeMQ

监控及链路追踪

SkyWalking：

Skywalking是一个分布式追踪系统，可以跟踪整个分布式系统的请求流程，并记录每个组件之间的调用关系和时间消耗。Skywalking被广泛应用于微服务架构中，帮助用户快速定位分布式事务链路上的问题。 Skywalking比较适合跟踪分布式事务链路