碎碎念


:::info{title="aim"}
1. 借助cc+目前的毕设项目，辅助完成毕设论文
2. 轻度使用cc的各种端，弄明白cc基础操作，常用命令
3. 研究怎么去用别人的skill接入自己的系统
:::

### 1.配置
直接去官网开盖即食终端版本
配置主要分两点
1. 系统配置

主要是底层网关配置？

2. 项目配置

主要是skill配置
* 提供定制化-初始化/本地配置端口/沟通反馈prompt...
* 安全性规范-限制权限行为
* 模型反馈有一定重复的幻觉-清除幻觉

### 2.使用
#### 2.1 终端版本
* 直接在shell呼唤 
```shell
claude
```
* 根目录可以配置claude skill
  1. 在 `CLAUDE.md` 文件来提供项目上下文
      * 会在每次对话开始时自动读取，包含技术栈、角色权限、常用命令、业务流程等完整上下文，后续对话无需重新解释项目背景。
  2. 在 `.claude/commands/ ` 项目级自定义斜杠命令，
      * 在此项目目录下可直接使用 /dev、/test、/review-api。
* 一些指令
  1. `/clean`清除上下文。
  2. ctrl c直接取消对话，重新输入prompt

### 3. 强大的tool
1. 在写论文时候用“网络搜索工具”，claude就可以访问到外部环境，引用到正确的文献。
2. 生成marmaid格式图片，再转网站ai去生成svg手绘图简直无敌

### 4. skill们
> 1. [论文skill](https://github.com/Lylll9436/Paper-Polish-Workflow-skill?tab=readme-ov-file#chinese)



:::note{title="感想"}
1. 其实开袋即食的claude已经很强了，我今天只是简单对话几句它自主就可以检索信息给出完美的论文，暂时没用到skill的场景
2. 我想skill可能是出于一种深入开发高定制化|节约token的角度，需要深度使用才会有更多感受。但是目前给出论文大概用了 3% 的pro版周token，其实一周下来能做到更多的事情。
:::

claude code初尝试

:::info{title="ovo"}
根据思维导图，由面及点学习后端开发

mujica镇楼~
:::
> 参考视频：https://www.bilibili.com/video/BV1mygDe3EBa/?spm_id_from=333.337.search-card.all.click&vd_source=7f873c7a93f66dc0552d5c89042ec18a
![](/static/img/6f917097bfe44df3a05ab4a692e5d330.6F917097BFE44DF3A05AB4A692E5D330.gif)

## 0. 计算机基础
### 0.1 linux
### 0.2 设计模式
## 1. java
### 1.1 java基础
### 1.2 jvm
### 1.3 lava多线程
## 2. 基础框架软件
### 2.1 spring boot
### 2.2 mybatis
## 3. 数据库
### 3.1 mysql
### 3.2 redis
## 4. 开发工具
### 4.1 Jetbrain
### 4.2 navicat
### 4.3 maven
## 5. 加分框架
### 5.1 消息队列：kafka rabbit mq
### 5.2 arthas 性能调优
### 5.3 容器虚拟化技术： docker
### 5.4 监控组件promethus
## 6. 其他知识
### 6.1 鉴权
### 6.2 常见攻防漏洞
### 6.3 https
### 6.4 分布式锁
### 6.5 限流算法
### 6.6 布隆过滤器
### 6.7 bitmap

## 0.java后端入门思维导图
![](/static/img/611f1d987b7381bfd2bcfe01fb728fe2.java-load.webp)



通过思维导图初学Java后端（努力学习ing


:::info{title="目标"}
为codex配置一套skills，最后用codex应用搭建一套毕设（已done）
:::

> 碎碎念：
>
> * 之前用copliot免费模型写了一套跑不起来的毕设，简单会用了ai设计prompt
> * 找的skill教程都是cc的教程，感觉国内的cc没有codex稳定，先用codex之后再考虑cc

## 1. Skill

### 1.1  概念

* 给大模型的说明手册

* 根据name加载，模型按需调用

#### 1.1.1 reference 读 （占用上下文）

if条件提到另一个skill，更进一步按需加载

![](/static/img/a9b451a2ecd7c250becf2e32e8910687.image-20260328172651157.webp)

#### 1.1.2 script 跑（不消耗token）

if条件触发代码

* agent skill的代码只会被执行不会被读取。

![](/static/img/52f0667cfec3fca31b002ad8dba99eab.image-20260328173248306.webp)


### 1.2 渐进式披露机制

* 元数据层
  * 所有模型的
  * 始终加载
* 指令层
  * SKILL.md除了name+description剩余内容
  * 按需加载
* 资源层
  * reference + script
  * 进一步按需加载



### 1.3  codex配置

![](/static/img/6c920132a8afa41211966e23368fe78a.image-20260328171917127.webp)

这个目录下可以通过`config.toml`配置全局的codex skill


系统级别的开发在 `.codex/skills`

项目级别的开发在根目录下 `.agent/codex`



## 2. MCP

* 与skill区别
  * skill提供逻辑，说明文档guide
  * mcp提供数据，独立程序tool

## 3. 成品的skill们
>[ai匠心毕设のgithub地址](https://github.com/moon-ic/ssm-lab-booking-system)

1. create-skill：第一步生成了全文skill的基础
2. cretea-prd：根据我和ai对话的prompt，生成一个可以作为开发范本+自测范本的prd
3. create-api-doc：+1，作为更偏技术的文档，用来开发+自测
4. init-program：根据选好的技术栈生成项目（用ai代替了脚手架？）
5. backend-step-dev：模块生成后端，规定每个模块开发后需要闭环自测，给出模块顺序的划分和参考。先独立闭环，再接入mysql和redis。开发严格参考api-doc
6. fronted-step-dev：模块生成前端，同上。完成后整体联调。开发严格参考api-doc

### 3.1 一些感想
1. codex会默认读取skill，在完成整体开发，我手动测试bug的阶段，初步开发的两个前后端skill会不停被读取，实际上并不需要它。
2. 我猜测是因为标题 or description 的描述比较模糊,我修改为整体开发不需要读它之后，还是没用
3. 项目级别的开发感觉是够了，好像没有值得专门沉淀到系统的skill，感觉我目前搓的都是一次性的，没啥复用的必要
4. 想用下别人配置好的skill，但是英文skill对我阅读比较困难


后台管理系统-搭建skill工作流

# 后端体系入门

:::info{title="ouo"}
前端视角下后端体系~

MQ消息队列|分布式集群等内容待后面深入再学。
:::

> 本文结构参考：https://github.com/roger-hiro/BlogFN/blob/master/

## 1. 应用服务器 & web服务器

* **`web server`**
  * 处理HTTP协议，接受请求后从磁盘找到一个静态文件丢给浏览器 | 转发给`application server`
  * keyword：**反向代理、负载均衡、缓存**
  * 内容：静态资源 (HTML/JS/Image)
  * 资源消耗：较低（主要消耗 IO 和带宽）
  * 示例：`nginx，Apache HTTP Server`
* **`application server`**（狭义后端）
  * 托管业务代码，处理业务逻辑
  * keyword：**分布式事务、连接池、业务算法**
  * 内容：动态数据 (JSON/XML/生成的页面)
  * 资源消耗：较高（主要消耗 CPU 和内存）
  * 示例：`tomcat（java），nodejs`

### 1. 1 **为什么会有 webserver？**

1. 快速重定向请求无需后端处理（404页面等）
2. 静态资源返回更快
3. 某些语言没有内置生产级web服务器，需要专用web进程

### 1.2 **`Apache`、`Nginx`、`Tomcat`和`Node.js`四者的区别是什么？** 

| **工具**    | **本质身份**      | **擅长干什么**                 | **对应的“语言”**    |
| ----------- | ----------------- | ------------------------------ | ------------------- |
| **Nginx**   | 高效代理/分发器   | 静态资源、负载均衡、反向代理   | 不限（通过转发）    |
| **Apache**  | 模块化 Web 服务器 | 稳定、兼容性好、直接处理 PHP   | 主要 PHP (通过模块) |
| **Tomcat**  | Java 应用容器     | 运行 Java Web 程序 (.war/.jar) | **只能 Java**       |
| **Node.js** | JS 运行环境       | 高并发 IO、实时应用 (Socket)   | **只能 JS**         |

### 1.3 web服务器载体

* 物理服务器
  * 自己的电脑
* 虚拟专用服务器-`VPS操作系统级`
  * 大的操作系统化单间
  * 采用`容器虚拟化`，大家共用一个内核，邻居流量过大会通过内核影响到你
* 托管虚拟机实例-`VM硬件级`
  * 大机器通过硬件仿真，模拟几台独立电脑
  * 采用`硬件级别虚拟化`，每个虚拟机有自己的独立内核，隔离性很好
* PaaS平台即服务
  * 不用管装修，直接放代码就可以跑

### 1.4 docker 虚拟机与物理机

* docker
  * 所有容器跑在**宿主机内核**，利用Linux 的 `Namespace`（空间隔离）和 `Cgroups`（资源限制）技术，给进程画了个圈。
* 虚拟机
  * 硬件模拟，跑一个完整操作系统
* 物理机
  * 自己的机子本体



## 2.负载均衡器：load balancer

高可用网络基础架构的一个组成部分。

有了负载均衡，我们可以把我们的*应用服务器*部署多台，通过负载均衡将用户的请求分发到不同不同服务器，提高服务性能可靠性。

1. 分成两类：

* **第四层（传输层）**：
  * **硬件负载均衡**
  * 根据网络与传输层协议（IP,TCP,FTP,UDP）对数据进行操作
  * 不认识http协议，对标其他 tcp 应用，例如：基于C/S开发的ERP系统
  * 如F5负载均衡器
* **第七层（应用层）**：
  * **软件负载均衡**
  * 根据应用层协议（http）中数据分发请求
  * 只认识http协议，对标众多网站等，例如：基于B/S开发的系统
  * 如Ngnix，LVS，HAproxy

两种都会收到请求，并根据**配置的算法**将这些请求分发到特定的服务器。



2. 一些分发算法：

* 轮询调度，`Round robin，RR`

* 加权轮询，`Weighted round robin，WRB`

* 最少连接数，`Least connections`

* 最短的响应时间，`Least response time`

  

3. web应用程序使用负载均衡器好处：

* 降低单个服务器压力，帮助维持一致相应时间，平均到每个请求会慢一点。
* 高可用性。如服务器崩溃一个，后端请求会被路由到建康的服务器，用户无感知。



## 3. 域名解析系统 DNS

用户在地址栏输入`url`，浏览器获得`url`的`域部分`，并调用DNS。dns解析发回对应ip地址。

* 如果web应用使用负载均衡器，则应域名配置为指向负载均衡器

大多域名注册服务都提供dns管理控制台。



## 4. HTTPS/SSL 证书

https提供服务确保安全。

1. 安装证书

   一般都需要在后端安装ssl证书，任何服务器（负载均衡器，cdn服务器，应用程序服务器）都需要安装。

- 你可以使用`LetsEncrypt`免费生成证书。
- 如果你使用的是云基础架构，则可以使用托管服务，例如`AWS Certificate Manager`。这允许你创建并自动续订SSL证书并将其分发到应用程序服务器，负载平衡器和CDN服务器。
- 只有中大型的`HTTPS`证书授权中心才会被浏览器承认，否则会显示为不安全，需要手动信任。

2. ssl证书类型

* 域名型SSL证书，简称DV SSL
* 企业型SSL证书，简称OV SSL
* 增强型SSL证书，简称EV SSL。
* 它们之间都有一定的区别，认证级别也都不同，各自适合不同规模类型的网站安装。



## 5. 数据库 Database

数据库工作是将数据可靠地永久保存到存储器里，允许查询检索数据，可围绕存储地数据结构强制执行一些规则约束

### 5.1 数据库种类

早期流行3种：层次式数据库，网络式数据库，关系型数据库

如今主要是2种，关系型`SQL`数据库 | 非关系型`NoSQL`数据库

* 关系数据库（例如`MySql，Postgres，SQLServer，Oracle，SQLite`）已经存在了40多年，并且一直是大多数Web应用程序的支柱。
* 而在过去十年左右的时间里，NoSQL数据库（例如MongoDB，Cassandra，CouchDB，DynamoDB）在Web应用程序中变得越来越普遍，主要是因为它们具有**可扩展性优势**和**数据结构灵活性**。

### 5.2 数据库部署

1. 一般在多台服务器部署（可以单台），降低风险
2. 少数云托管“无服务器数据库”，可以用api调用数据库。不需要设置服务器，由云供应商提供服务。示例包括`DynamoDB（NoSQL）`，`Firebase`实时数据库（`NoSQL`）和`Aurora`无服务器（关系）。

### 5.3 数据库基础方案

基础方案分三种：

- 一主一备的架构（主备式）
- 一主一从的架构（主从式）
- 互为主从的架构（主主式）

#### 5.3.1. 一主一备的架构（主备式）

双机部署架构

* 主机A，日常提供数据读写服务
* 备机B，不提供线上服务，同步主机的数据
* 主机故障，人工踢下线主机，将备机作为主机继续服务

优点：

*  不需改造，简单部署维护

缺点：

* 人工干预废成本
* 备机严重浪费资源

#### 5.3.2. 一主一从的架构（主从式）

与主备类似，但从机需要平时一起干活

* 从机只读不写
* 主机实时同步数据

优点

* 故障时间从机可以提供读服务

缺点

* 逻辑复杂，主从都有读服务
* 延迟，主机同步从机有延迟

#### 5.3.3. 互为主从的架构（主主式）

两台自己是主机也作为对方的从机，都提供读写·，随机调用一台服务

缺点:

* 实时同步数据双向复制，会有延迟，极端情况下丢失

#### 5.3.4 集群（暂时无）

## 6. Blob 文件存储

数据库存储的数据有限制

* 前端资源：图片，css，js，静态数据...
* 用户表单上传的各种文件

云服务商会提供专用服务来存储

#### blob用处-http端点访问文件

* 向浏览器提供图像|文档
* 存储文件-分布式访问
* 音视频流式处理
* 写入日志文件
* 存储用于备份还原，灾难恢复以及存档的数据

## 7. 内容分发网络 CDN

远距离服务器访问，减少延迟

* 云服务商提供的服务，全球范围内分布有“边缘服务器”
* 边缘服务器从“原点”（如blob文件存储位置）获取文件副本，前端直直接指向cdn的url
* 物理距离更近了

## 8. 缓存服务：caching service

web应用临时缓存动态数据

* 特殊类型的数据库。采用**键值对**存储形式
* 完全保存于内存，检索非常快

常见

* redis | memcached

### 8.1 redis 对比 memcached

| Memcached      | Redis |      |
| -------------- | ----- | ---- |
| 亚毫秒级延迟   | 是    | 是   |
| 开发人员易用性 | 是    | 是   |
| 数据分区       | 是    | 是   |
| 多语言支持     | 是    | 是   |
| 高级数据结构   | -     | 是   |
| 多线程架构     | 是    | -    |
| 快照           | -     | 是   |
| 复制           | -     | 是   |
| 发布/订阅      | -     | 是   |
| Lua脚本        | -     | 是   |
| 地理空间支持   | -     | 是   |

## 9.  消息队列：Message Queue

> 适用于批处理任务 | 分离应用程序的异步消息收发

