Nicksxs's Blog

What hurts more, the pain of hard work or the pain of regret?

一、先看总原则

  1. 创建对象麻烦

用创建型模式

  1. 类或对象的组合关系复杂

用结构型模式

  1. 对象之间职责划分、通信流程复杂

用行为型模式


二、不同设计模式适合的场景


(一)创建型模式:解决“对象怎么创建”

  1. 单例模式(Singleton)

适合场景:

  • 系统中某个类只能有一个实例
  • 如配置管理器、线程池、缓存管理器、日志对象

关键词:

  • 唯一实例
  • 全局访问点

记忆点:

  • “一个类只有一个对象”基本就是单例

  1. 工厂方法模式(Factory Method)

适合场景:

  • 需要创建对象,但不想直接 new
  • 不同条件下创建不同具体产品
  • 如不同数据库连接、不同导出器、不同支付方式对象

关键词:

  • 延迟实例化
  • 子类决定创建哪种对象

记忆点:

  • 关注“创建一个等级结构中的某一个产品”

  1. 抽象工厂模式(Abstract Factory)

适合场景:

  • 要创建一整组相关或相互依赖的对象
  • 如不同风格 UI 组件:Windows 风格按钮、文本框;Mac 风格按钮、文本框
  • 不同数据库族:连接、命令、结果集统一切换

关键词:

  • 产品族
  • 成套创建

记忆点:

  • 工厂方法是“一个产品”
  • 抽象工厂是“一族产品”

  1. 建造者模式(Builder)

适合场景:

  • 对象构造过程复杂,步骤多,但步骤顺序稳定
  • 如组装电脑、构建 SQL、创建复杂报表、创建复杂请求对象

关键词:

  • 分步构建
  • 构建过程与表示分离

记忆点:

  • “复杂对象一步步组装”就是建造者

  1. 原型模式(Prototype)

适合场景:

  • 创建对象成本高,复制比重新创建更高效
  • 如图形对象复制、配置模板复制、带大量初始化数据的对象

关键词:

  • 克隆
  • 复制现有对象

记忆点:

  • 区分浅拷贝、深拷贝是常见延伸点

(二)结构型模式:解决“类和对象怎么组织”

  1. 适配器模式(Adapter)

适合场景:

  • 已有类能用,但接口不兼容
  • 老系统对接新系统
  • 第三方接口封装

关键词:

  • 接口转换
  • 兼容旧接口

记忆点:

  • 核心是“让本来不能一起工作的类可以一起工作”

  1. 桥接模式(Bridge)

适合场景:

  • 存在两个独立变化维度,希望分别扩展
  • 如消息类型(普通/紧急)和发送方式(短信/邮件)都在变化
  • 图形形状和绘制平台都要扩展

关键词:

  • 抽象与实现分离
  • 多维度变化

记忆点:

  • 如果题目说“两个维度都要扩展,避免类爆炸”,多半是桥接

  1. 组合模式(Composite)

适合场景:

  • 树形结构
  • 如文件夹/文件、菜单/子菜单、组织架构

关键词:

  • 部分—整体
  • 树形结构统一处理

记忆点:

  • 叶子节点和容器节点统一对待

  1. 装饰器模式(Decorator)

适合场景:

  • 动态给对象增加功能,不想修改原类
  • 如 I/O 流加缓冲、加加密、加日志
  • 给组件附加权限校验、统计功能

关键词:

  • 动态增强
  • 比继承更灵活

记忆点:

  • 与代理模式容易混淆
  • 装饰器强调“增强功能”

  1. 外观模式(Facade)

适合场景:

  • 子系统复杂,希望对外提供统一简单入口
  • 如一键启动流程、统一服务入口、SDK 封装

关键词:

  • 简化调用
  • 统一入口

记忆点:

  • 核心是“隐藏子系统复杂性”

  1. 享元模式(Flyweight)

适合场景:

  • 系统中有大量细粒度对象,内存占用大
  • 如字符对象、棋子对象、图标对象

关键词:

  • 共享对象
  • 节省内存

记忆点:

  • 区分内部状态与外部状态

  1. 代理模式(Proxy)

适合场景:

  • 需要控制对对象的访问
  • 如远程代理、虚代理、权限代理、缓存代理

关键词:

  • 控制访问
  • 间接访问真实对象

记忆点:

  • 与装饰器区分:
    • 代理:控制访问
    • 装饰器:增强功能

(三)行为型模式:解决“对象之间怎么协作”

  1. 策略模式(Strategy)

适合场景:

  • 有多种算法或业务规则可互换
  • 如支付策略、折扣策略、排序策略、路由策略

关键词:

  • 算法封装
  • 可互换

记忆点:

  • “同一问题,多种算法可切换”就是策略

  1. 模板方法模式(Template Method)

适合场景:

  • 流程固定,但某些步骤实现不同
  • 如报表生成流程、数据导入流程、考试流程

关键词:

  • 定义算法骨架
  • 子类重写具体步骤

记忆点:

  • “整体流程不变,细节步骤可变”就是模板方法

  1. 观察者模式(Observer)

适合场景:

  • 一个对象状态变化,要通知多个对象
  • 如事件监听、消息订阅、UI 联动、发布订阅

关键词:

  • 一对多通知
  • 发布—订阅

记忆点:

  • 题干出现“通知多个依赖对象”基本就是观察者

  1. 责任链模式(Chain of Responsibility)

适合场景:

  • 多个对象都可能处理同一个请求,谁处理运行时决定
  • 如审批流程、过滤器链、异常处理链

关键词:

  • 请求沿链传递
  • 解耦发送者和接收者

记忆点:

  • 常见于工作流、过滤器、权限校验链

  1. 命令模式(Command)

适合场景:

  • 需要把请求封装成对象
  • 支持撤销/重做、请求队列、日志记录
  • 如菜单操作、遥控器、事务操作

关键词:

  • 请求对象化
  • 支持撤销、排队

记忆点:

  • “请求发送者与执行者解耦”是命令模式核心

  1. 状态模式(State)

适合场景:

  • 对象在不同状态下行为不同
  • 如订单状态、工作流状态、播放器状态、TCP 连接状态

关键词:

  • 状态变化引起行为变化
  • 消除大量 if-else

记忆点:

  • 与策略模式易混淆
  • 策略:主动切换算法
  • 状态:状态变化驱动行为变化

  1. 迭代器模式(Iterator)

适合场景:

  • 顺序访问聚合对象中的元素,而不暴露内部结构
  • 如遍历集合、列表、树结构

关键词:

  • 统一遍历接口
  • 隐藏内部结构

记忆点:

  • 主要用于集合遍历

  1. 中介者模式(Mediator)

适合场景:

  • 多个对象之间交互复杂,网状依赖严重
  • 如聊天系统、界面控件协作、航班调度

关键词:

  • 集中协调
  • 降低对象间耦合

记忆点:

  • “对象间不直接通信,都通过中间者协调”

  1. 备忘录模式(Memento)

适合场景:

  • 需要保存对象历史状态,以便恢复
  • 如撤销、回滚、存档点

关键词:

  • 状态快照
  • 恢复历史状态

记忆点:

  • 常和命令模式一起出现

  1. 访问者模式(Visitor)

适合场景:

  • 数据结构相对稳定,但对其进行的操作经常变化
  • 如编译器语法树处理、报表统计、对象结构分析

关键词:

  • 操作与数据结构分离
  • 易于新增操作

记忆点:

  • “结构稳定、操作多变”是判断关键

  1. 解释器模式(Interpreter)

适合场景:

  • 需要定义语法规则并解释执行
  • 如表达式计算、规则引擎、简单脚本解析

关键词:

  • 语法解释
  • 表达式求值

记忆点:

  • 适合简单语言或规则系统,不适合特别复杂语法

三、软考最常考的几个区分

  1. 工厂方法 vs 抽象工厂
  • 工厂方法:创建一种产品
  • 抽象工厂:创建一族产品

  1. 装饰器 vs 代理
  • 装饰器:增强功能
  • 代理:控制访问

  1. 策略 vs 状态
  • 策略:多种算法任选其一
  • 状态:对象状态改变导致行为变化

  1. 模板方法 vs 策略
  • 模板方法:流程骨架固定,细节延迟到子类
  • 策略:算法整体可替换

  1. 适配器 vs 桥接
  • 适配器:解决现有接口不兼容
  • 桥接:解决两个维度独立变化

前阵子在openclaw热度之后,又出来个hermes agent,主打个更高效智能的agent,我们就来体验试下
其实挺久之前就开始运行了,但是因为大部分的coding plan都涨价了,普通的api付费又可能被这类agent给刷爆
正好最近小米在做一个模型token推广计划
申请入口在这里
可以将自己的使用场景提交上去,我也申请到了一些token
就来配置到hermes agent试用下
一键安装脚本

1
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

如果有一些科学上网可能会快一点
安装好之后,主要是配置模型和gateway
因为现在最新版的已经支持了很多模型的官方配置

1
hermes model

通过这个命令,就可以进行模型设置,小米的mimo也天然支持
我一开始想用lm studio的本地模型,但是因为笔记本上只有6g显存,内存也有一些日常程序在跑
正常最低的上下文长度比如4096就可以跑起来,但是像hermes agent需要最低64k的上下文长度
如果用64k上下文运行的话显存+内存就不够了,而且本地除非配置非常牛
不然本地的token速度不够,也会很慢
如果有了申请好的mimo订阅,那就把token和端点api的地址输进去

1
https://token-plan-cn.xiaomimimo.com/v1

另外hermes agent的gateway已经支持微信通道了
可以通过

1
hermes gateway setup

选择微信,
然后扫码进行登录链接,记得比如像我Qclaw,就是替换掉不能同时连接多个龙虾类agent
扫码完一路确定就好了
然后在微信回复消息,就会有个approve的口令

1
hermes pairing approve weixin xxxxx

然后就可以跟hermes发消息了

这样就能有一个手机上可以监控和交互的agent了
这一点感觉是龙虾类的一大重要特点
还可以让hermes来对比下它和openclaw

这块我觉得主要还是要有自己的工作流和技能,能让我自己的工作或者作业流程能更高效
比如做项目开发,类似于openspec这种做sdd开发
claude有一堆的前端和设计的技能
另外还有比较重要的就是模型也得比较厉害
当然国内的模型现在也已经都提升了很多
近期用下来比如glm 5.1已经是非常不错的模型了
在有比较明确的上下文和约定下,还是能完成很多开发任务的

1
2
3
4
5
6
7
8
9
10
11
12
开发者体验

能力 OpenClaw Hermes

MCP 协议 ✓ ✓
自定义工具 ✓ ✓ (Python 插件)
技能市场 ClawHub 内置 + Hub
配置方式 CLI + 文件 CLI + YAML + .env
Profile 多实例 ? ✓
Credential Pool ? ✓ (多 API Key 轮换)
ACP (IDE 集成) ? ✓
Git worktree ? ✓ (并行 Agent)

对比适用场景

1
2
3
4
5
6
7
8
9
10
11
12
13
14

选 OpenClaw 如果你:
- 主要需要生活/工作助手(邮件、日历、航班值机)
- 使用 Google Chat、IRC、LINE、Twitch 等小众平台
- 喜欢活跃的社区和赞助商支持
- 偏好开箱即用的体验

选 Hermes Agent 如果你:
- 主要是开发者/研究者/系统管理员
- 需要灵活切换 20+ LLM 提供商(含本地模型)
- 需要子代理委派、并行任务、Git worktree
- 需要丰富的内置技能(97+)
- 需要 Email/SMS/Home Assistant 集成
- 喜欢深度自定义和 Python 生态

总结下
两者都是优秀的开源个人 AI Agent,核心思路相似:
自托管 Gateway + 多平台消息 + 工具调用 + 持久记忆。
有兴趣的可以体验下看看

上次是开始使用了Obsidian,之前也听说了Obsidian也推出了cli命令行工具,这次就来体验下,主要是为了能在例如claude code跟codex中直接操作Obsidian,比如在一些知识的学习之后希望整理成笔记
首先安装比较简单,就是在软件内开启命令行就行,会加到系统的PATH路径里
开启命令行有版本要求

1
Using the CLI requires the Obsidian 1.12 installer. See the installer version update guide.


在关于的最后高级菜单中就可以开启了
我们可以先看看这个cli能用来干啥
当然可以用help命令来查看

1
obsidian help

日常使用可以参考这些命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Open today's daily note
obsidian daily

# Add a task to your daily note
obsidian daily:append content="- [ ] Buy groceries"

# Search your vault
obsidian search query="meeting notes"

# Read the active file
obsidian read

# List all tasks from your daily note
obsidian tasks daily

# Create a new note from a template
obsidian create name="Trip to Paris" template=Travel

# List all tags in your vault with counts
obsidian tags counts

# Compare two versions of a file
obsidian diff file=README from=1 to=3

包括记录今日的日常笔记,搜索,查看活动日志等等
在结合Claude Code使用的时候
我们可以装下大佬的skill
https://github.com/kepano/obsidian-skills
我们可以通过这个安装

1
2
/plugin marketplace add kepano/obsidian-skills
/plugin install obsidian@obsidian-skills

然后我们就能用它里面的技能来处理知识笔记处理
比如

1
使用defuddle技能帮我摘录这篇文章 https://obsidian.md/help/cli

这样就能用defuddle来处理这篇文章,摘录到本地
然后再用这个包里的obsidian技能把摘录下来的文章保存到obsidian
可以看到初步的效果

这样就初步打通了这个cli的一体化体验了
当然更细致的使用还有待研究和学习
可能这块的生态来说,的确有了cli工具,整体使用起来也会变得更丝滑
从文章摘录到整理到笔记
刚才还有一步重要的就是把知识进行总结整理
通过仔细查看cli的文档也能看到这个工具不是只做出来有个样子而已
已经是比较深入到整体的系统使用
甚至包括插件的管理都有
查看安装的所有插件
plugins

List installed plugins.

1
2
3
4
filter=core|community  # filter by plugin type

versions # include version numbers
format=json|tsv|csv # output format (default: tsv)

查看启动的插件
plugins:enabled

1
2
3
4
filter=core|community  # filter by plugin type

versions # include version numbers
format=json|tsv|csv # output format (default: tsv)

启用插件
plugin:enable

1
2
id=<id>                # (required) plugin ID
filter=core|community # plugin type

这些也只是一小部分,可以具体在cli进行学习参考

之前看到Karpathy这个wiki知识库提到了使用Obsidian作为笔记软件,因为Obsidian存储笔记的格式就是markdown
Obsidian的使用方式和别的笔记系统还是有比较大差别的,我们只需要指定一个笔记目录,就可以往里存放笔记了
它的语法整体就是markdown的语法,之前比如像我用hexo写博客的话大概也知道基本的语法,
只是有个比较特殊的内部链接
通过

1
[[标题]]

来做内部链接,就能链接到笔记库内部的另一篇笔记,同时会在被链接笔记的右侧侧边栏显示链接当前笔记的笔记,有点绕
这样呢,我个人理解还是通过文章之间的联系,把孤立的一篇篇文章连接成知识体系,因为像我之前就也出现了碰到一个问题想解决它,结果解决了想记录下,一搜发现以前已经写过了
没有成体系化的笔记系统,就需要定期去整理回顾之前的笔记和文章,当然呢,工具永远只是一部分,主动地去整理记忆才是最重要的。
哪怕最好的工具,不去好好使用也只是工具
当然这个Obsidian在使用还有它很好用的网页摘录插件,因为这个甚至是把它作为笔记软件的一个重要原因
我之前使用的是为知笔记,它有个特别好用的就是在微信公众号里的文章可以直接转发他们的企微助理号,就会直接同步到笔记库里,但是前阵子可能是被微信封了
目前这个也没有完全恢复,所以也这个最大的优点没有了之后,也在考虑可以换个软件
它的网页摘录插件就是
https://chromewebstore.google.com/detail/obsidian-web-clipper/cnjifjpddelmedmihgijeibhnjfabmlf

安装这个插件后就可以把网页直接转换成markdown进行保存,包括像网页内的图片也会摘取链接转换成markdown的图片格式
还有就是笔记多端同步了,这边因为我比较熟悉syncthing,所以可以使用syncthing来做同步,我现在主力使用的安卓机,
也可以安装syncthing和Obsidian的安卓客户端,通过syncthing同步后,手机上同样指定同步的笔记库目录,就可以跨端查看笔记了

上次把pdf文档转成了markdown,这次就来试下把文档进行具体的整理学习
创建我的wiki目录,然后在目录下创建raw目录,用于存放原始的文档,最好是转成了markdown的,
方便模型读取,当然模型是多模态的,并且土豪可以无视
然后使用claude在目录下让模型帮我开始整理我的知识库
它就开启了plan模式,使用了多个agent来处理文件

1
2
3
4
5
6
7
8
9
⏺ Entered plan mode
Claude is now exploring and designing an implementation approach.

⏺ 3 Explore agents finished (ctrl+o to expand)
├─ Survey wiki structure · 9 tool uses · 0 tokens
│ ⎿ Done
├─ Inspect raw materials · 10 tool uses · 0 tokens
│ ⎿ Done
└─ Find related study notes · 9 tool uses · 0 tokens

在完成之后就又给出了我需要做的针对性选项

1
2
3
4
5
6
7
8
9
10
11
⏺ Plan(Design KB plan)
⎿  Done (0 tool uses · 11.4k tokens · 20s)
(ctrl+o to expand)

Searched for 2 patterns, read 1 file (ctrl+o to expand)

⏺ User answered Claude's questions:
⎿  · 你希望这个知识库更偏哪种使用场景? → 教材精读

⏺ Searching for 3 patterns, reading 1 file… (ctrl+o to expand)
⎿ raw/教材.md

接下去再做生成和校验

1
2
3
4
5
6
7
8
9
10
11
12
13
Verification

1. 运行脚本后,确认 1–21 章都已生成目录,尤其检查带分页符前缀的章标题是否正确识别。
2. 抽检至少 3 章:
- 第 1 章(开头正常)
- 第 9 章(架构核心章节)
- 第 10 章(前有分页符)
3. 抽检至少 15 个节/小节文件,确认:
- 文件名编号正确
- 内容没有串章
- 小节没有落错父目录
4. 检查总入口和章节索引里的链接是否全部可跳转。
5. 随机检查若干 图/表格残片,确认都被标成“待人工核对”,而不是被错误改写。

其实针对这种还是最好通过比较好的OCR模型或者多模态模型进行构建

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
⏺ 已帮你把教材整理成一版“教材精读型”知识库骨架。

完成内容:
- 新增构建脚本:./wiki/scripts/build_architect_kb.py
- 生成知识库入口:./wiki/系统架构设计师/README.md
- 生成章节目录与索引:
- 系统架构设计师/章节/**
- 系统架构设计师/索引/按章节索引.md

本次生成结果:
- 21 章
- 118 节
- 265 个小节

我已抽检通过的点:
- 第 9 章目录正常:教材/章节/09-软件架构设计/README.md:1
- 第 10 章分页符章节也识别正常:系统架构设计师/章节/10-设计模式/README.md:1
- 第 21 章重复小节问题已修正:系统架构设计师/章节/21-虚拟化、云计算与物联网/README.md:1
- 图片缺失占位已落地:系统架构设计师/章节/01-计算机组成与体系结构/01-1.1.1-计算机硬件的组成.md:11

当前知识库特点:
- 保留教材章节主线
- 自动清洗了部分 OCR 噪声和分页符
- 把孤立的“图/表”替换为待人工核对占位
- 每章都有 README,每节/小节独立成文件,并带来源行号

已知限制:
- 原始教材 OCR 质量一般,个别公式/符号仍有乱码,比如 系统架构设计师/章节/03-数据库系统/02-3.2.2-关系代数.md:11
- 这版重点是“结构化落库”,不是“内容精修”

如果你愿意,我下一步可以继续做两件事之一:
1. 继续清洗 OCR 乱码,优先修数据库/公式类章节。
2. 开始做“精读增强”,给每章补“重点 / 易混点 / 关联章节”。

这样基于这个知识库,我们可以继续进行更多的问答学习总结,防止大模型幻觉或者知识的不准确性

0%