2025-06-20 13:00:00
在我之前的视频里面当时介绍了三款不同的本地 AI 客户端，[[Cherry Studio]]，[[Chatbox]]，ChatWise，每个客户端都有自身的优缺点，前两款也还是开源的，但是今天要介绍的 ChatWise 是一款更轻量的，更强大的 AI 客户端，包括一些个人觉得非常好用的功能，比如本地联网搜索，MCP 支持，Artifacts 等等使用起来都非常方便。
我最早是因为本地使用 DeepSeek 才想要下载用一个本地的客户端，因为平时基本上都使用在线网页版本 [[Perplexity]]，ChatGPT，Claude 等，但是知道了 ChatWise 之后发现原来本地的客户端使用体验也可以非常不错。
ChatWise 支持几乎所有主流的大模型模型，包括
ChatWise 支持多种形式的输入输出，除了最普通的文本，还支持
在聊天界面只要点击地球图标就可以启用搜索。
在设置中，也有单独的 Web Search 的选项。默认情况下使用本地的 Google 搜索。
在设置中还可以使用 Tavily 搜索 API，让用户获取实时的搜索结果。
支持 HTML，React，图表，文档等内容。还支持 mermaid 流程图。
如果对话过程中有代码相关的内容，可以启用 Artifacts 那么在右侧就可以看到预览的效果。
ChatWise 支持 [[Model Context Protocol]] MCP 协议，MCP 是 Anthropic 推出的一个让模型访问外部资源的协议。开发者可以根据 MCP 规范实现一些服务，让 AI 可以通过协议获取额外的资源和上下文，比如 ChatWise 可以连接到 Notion，Google Sheets 等等外部工具，在和 AI 聊天的过程中可以调用这些 MCP 来实现更好的回答。
模型可以通过两种方式访问 MCP
在 ChatWise 的 Tools（工具） 中可以使用加号添加 MCP 服务。
官方的 MCP 仓库
2025-06-17 13:00:00
今天想给大家介绍一款特别有意思的插件叫做 SpecStory，我们现在会在 VS Code， Cursor 编辑器中使用各种类型的代码辅助工具，也会利用 Cursor 等集成的 IDE 来 vibe coding，但是如果我们每一次都重头开始描述我们想要做的事情，或者每一次都新开一个聊天窗口，AI 大模型大概率会前后表现不一致，虽然我们也可以利用 Cursor Rules 等工具来给 AI 提供一些系统级别的提示词，但是 AI 在回复的过程中也可能跑偏。
SpecStory 这款插件恰好解决了这些问题。SpecStory 的核心功能是帮助开发者在编程过程中建立和维护一个持久的、可追溯的情境描述，它会记录下所有和 AI 的聊天记录。
SpecStory 能够自动保存、组织并以结构化 Markdown 格式呈现所有 AI 聊天记录，确保每一次与 AI 的对话都成为可检索的资产。SpecStory 为 AI 提供丰富且准确的上下文信息，使得 AI 能够更好地理解你的意图，从而提供更精准的建议或生成代码。这种方式最大限度地减少了 AI 偏离主题或给出不相关建议的可能性，也避免了重复输入大量背景信息的问题。
.specstory 文件夹，将所有与 AI 的交互以 Markdown 档案形式记录。以下是如何安装和使用 SpecStory 的简单说明
确保你的编辑器兼容 SpecStory：目前 SpecStory 支持 GitHub Copilot、Cursor 编辑器。
| 编辑器 | 步骤 | 备注 |
|---|---|---|
| VS Code | 扩展市场搜寻「SpecStory」，点击安装 | 支持 GitHub Copilot 及 Cursor |
| Cursor | Cursor 编辑器内部扩展面板 (Ctrl/Cmd+Shift-X) 搜索「SpecStory」并安装 | 如从 Marketplace 网站安装，需另行在 Cursor 端安装 |
| VSIX 安装 | 下载 specstory-vscode-latest.vsix，于命令面板选择「Extensions: Install from VSIX…」 |
适用于无法从扩展市场直接安装的场景 |
打开命令面板 (Ctrl/Cmd+Shift-P)，输入 SpecStory，若能看到相关命令列表即表示安装成功。
.specstory/history/ 下的 Markdown 档案中。所有对话记录均保存在本地专案中，不会自动上传云端，并提供匿名分享选项，无需注册，即可掌控分享内容。
2025-06-17 13:00:00
很早之前就看到了 GitHub Copilot 可以在 VS Code 中提交 Git 时自动编写提交 Message，但是实际上我一直没有用起来。正好现在对 Git Message 做一个完整的学习，顺便也了解一下当前的 AI Commits 方案。
之前其实看到过一个对于 Commit message 的规范 Conventional Commits，之前的一些提交提交历史也是按照 feat, fix 等等方式来进行的，但是其实理解和书写起来也没完全按照这个模式，只借鉴了其中关于提交类型的部分。所以这次调研才看到对于内容部分更详细的说明，现在很多 AI 来产生提交历史的时候，更能看出来区别。
Git 历史记录讲述了项目文件的演进过程，包括了什么被修改了，为什么被修改，所有团队中的成员都可以有效地审查变更，通过查看 Git 变更历史可以非常容易地查明 bug 以及破坏性更改的来源。但是往往开发者在花了数小时编写代码之后，却在 Git Message 提交的时候忽略了其重要性，导致 Git 历史非常难以定位和排查。所以本文就来总结一下目前比较好用的 AI 提交 Git message 的方法。
lumen 是一个使用 Rust 编写的命令行工具，可以将 AI 结合到 git 工作流中，用来生成 Git 提交历史。
安装
brew install jnsahaj/lumen/lumen
可以利用 lumen draft 来生成提交历史，在运行这一行命令之前记得将代码 git add 到暂存区中。
默认情况下 lumen 会调用 Phind 这一个模型来生成，但是如果自己想配置 OpenAI，或者 Claude 也可以指定。
AI Commits 是一个基于命令行的工具，使用 TypeScript 编写，可以调用大语言模型帮助我们提交 Git 信息。
使用 AI Commits 需要设置 OpenAI 的 API Key。
npm install -g aicommits
aicommits config set OPENAI_KEY=XXX
aicommits
aicommits --type conventional
AI Commits 可以生成符合 Conventional Commits 规范的提交信息。
我个人使用 IntelliJ IDEA 比较多，所以在 IDEA 中也找到了一款 AI Commits 的插件。
安装之后打开设置，就可以配置调用的模型，以及系统的 Prompt。
2025-06-16 13:00:00
大概两年前我自己部署了 Uptime Kuma 来监控我的各项服务在线情况，这两年内一直工作非常稳定，除了偶尔的网络波动带来的误报，基本上没有其他大问题。
但是用了超过两年，最近访问后台加载起来越来越慢，经常需要好久才能将监控的列表加载出来。对于使用上的问题，对我的影响越来越不能忽视， 所以今天来讲一下如何优化 Uptime Kuma 的数据库。
Uptime Kuma 在 1.x 版本中需要对整个 heartbeat 表进行扫描来执行一些操作，数据库中存在大量数据时，会导致显著的性能下降。根据开发者的说明，性能限制依赖于硬件配置，超过 500 个监控或者数据库大小超过 1.5 GB 左右时会有明显的性能问题。1
于是我检查了一下我本地的 SQLite 数据库，竟然达到了 2.6 GB。
可以在 Kuma 的设置 /settings/monitor-history 中设置数据保留期限，然后手动执行清理。
因为在 v1 版本中 Kuma 使用 heartbeat 心跳表来记录检查，如果频繁的进行检查，并记录，可能导致 heartbeat 表快速膨胀，可以根据自己的情况适当地降低检查频率。
在 Uptime Kuma 的 SQLite 数据库中，历史数据主要存储在心跳相关的表中。
推荐在清理数据时，先将 Kuma 服务暂停。
推荐备份一下 kuma.db 数据库
cp kuma.db kuma-2025xxxx.db
然后使用 sqlite3 连接数据库，并执行删除语句。
DELETE FROM heartbeat WHERE time < datetime('now', '-30 days');
清理特定监控器的历史数据
-- 查看监控器ID
SELECT id, name FROM monitor;
-- 删除特定监控器的历史数据
DELETE FROM heartbeat WHERE monitor_id = [监控器ID];
数据清理之后，可以对数据库优化释放空间
VACUUM;
-- 重建索引
REINDEX;
Uptime Kuma 的维护团队正在开发 v2 版本，希望通过引入外部的 MariaDB 数据库来改善性能，等未来 v2 版本稳定之后，可以考虑升级，但是目前看官方的进度还在 beta 阶段。
2025-06-13 13:00:00
在之前的文章当中已经介绍过如何在 K3S 当中使用 Longhorn 作为分布式存储方案，那么本文再记录一下如何将 Longhorn 的备份存储到 S3 兼容的对象存储当中。
要完成这个备份,需要完成两个核心步骤。创建一个 S3 访问凭证，然后在 Longhorn 的 UI 当中配置备份目标。
首先，您需要在 longhorn-system 命名空间中创建一个 Kubernetes Secret，用于安全地存储访问 S3 存储桶所需的凭证。
准备如下的信息
http://10.6.6.25:9000 或 AWS 的 https://s3.us-east-1.amazonaws.com。您可以创建一个 YAML 文件来定义该 Secret。请注意，Secret 中的值必须经过 Base64 编码。
创建一个配置文件，比如 longhorn-backblaze-credentials.yaml
apiVersion: v1
kind: Secret
metadata:
name: longhorn-minio-credentials
namespace: longhorn-system
type: Opaque
data:
# 以下是示例值，请替换为您自己的凭证（Base64编码后）
AWS_ACCESS_KEY_ID: YWRtaW4= # 示例: echo -n 'admin' | base64
AWS_SECRET_ACCESS_KEY: YWRtaW5hZG1pbg== # 示例: echo -n 'adminadmin' | base64
AWS_ENDPOINTS: aHR0cDovLzEwLjYuMTIuMjUxOjkwMDAv # 示例: echo -n 'http://10.6.12.251:9000/' | base64
保存内容之后应用
kubectl apply -f longhorn-backblaze-credentials.yaml
创建 Secret 之后，登录 Longhorn 管理界面设置备份目标。
因为我使用 [[Rancher]] 所以直接在后台找到 Longhorn 管理页面，点击顶部菜单 Settings，然后选择 Backup Target。
在设置页面中填写如下的字段
s3://<bucket-name>@<region>/<optional-folder-path>
<bucket-name> 是您在 S3 存储中创建的存储桶名称。<region> 是存储桶所在的区域代码，例如 us-east-1
<optional-folder-path> 是存储桶内的一个可选文件夹路径，用于存放备份。/
longhorn-backblaze-credentials
我这里采用 [[Backblaze B2 Cloud Storage]] 作为备份存储，创建存储桶 (Bucket) 时，Backblaze 会提供一个 S3 Endpoint。它的格式通常是 s3.<region-code>.backblazeb2.com。例如：s3.us-west-004.backblazeb2.com。Region 这部分信息就是 Endpoint URL 中的区域代码。例如：us-west-004。Bucket Name: 您用于存储备份的 B2 存储桶的名称。
配置完成之后，点击保存按钮，在页面上就能看到 Backup Target 显示绿色的 Available。
为了测试之前的配置是否有效,我们可以进行一次手动的备份测试，最简单的备份测试就是可以通过 Longhorn 的图形界面。
Longhorn 会将卷当前的状态快照复制到配置的 Backup Target 中，可以在 Backup 标签页中查看已创建的备份。
Longhorn 允许为每个卷配置周期性的备份任务。
backup。保存设置: 配置完成后保存即可。Longhorn 会根据您设定的 CRON 表达式自动为该卷创建备份。
Longhorn 有一个优化机制，只有当卷的数据自上次备份以来发生了变化时，周期性备份任务才会创建新的备份，从而避免生成大量内容重复的备份。
2025-06-12 13:00:00
这两天在发布 iOS 应用到 App Store 的时候，在第一步创建 Bundle ID 的地方就卡住了，这是 iOS 开发过程中的一大坑，所以本文记录一下。
Bundle ID 是苹果用于标识应用的唯一字符。每一个 iOS 应用都有一个唯一的 Bundle ID，有字符串组成，通常是反向域名的形式，比如 com.domain.appname。
Bundle ID 的作用非常关键，不仅用于区分应用，还用于应用的各种资源，比如推送通知，iCloud，SDK 验证等等。
所以本文下方就展开讲讲我是怎么调入 Bundle ID 重复的坑里面的。
我开发完成 Flutter 的应用，然后使用 iPhone 真机测试，在 Xcode 中配置并完成了测试之后，想要发布应用，所以想在 Developer 网站创建 Certificates, Identifiers & Profiles 中创建 Bundle ID，然后官方给出了如下的错误：
An attribute in the provided entity has invalid value
An App ID with Identifier 'com.domain.xxx' is not available. Please enter a different string.
在网上查了一圈，也发邮件问了官方客服，得到的解答都是说 Bundle ID 重复（被占用了），所以无法创建。但是让我疑惑的是我是用我自己的域名反向作为 Bundle ID 的，这个 ID 理论上没有任何会使用。再后来我查到说，如果开发的时候使用过真机做调试，那么 Xcode 会自动生成一个通配符的 Bundle ID，忽略我下面的错误（下面的错误是因为我手动在后台删除了通配符）
而恰恰是这个问题，苹果会将应用的 Bundle ID 给注册上。所以在我们正式发布的时候要去申请 Bundle ID 就申请不下来。所以就两个办法
客服和网上的解决方法都建议直接更换 Bundle ID，但是我不想更换 Bundle，因为 Play Store 中的应用已经发布了使用了相同的 ID 也好便于管理。所以现在就想能不能联系客服将测试占用的 ID 删除。
网上有人建议直接拨打客服，但是我先尝试了一下通过邮件联系，回复的很快，但是客服说并没有在我的账号下找到被占用的 Bundle ID，所以还是建议我更换 Bundle ID。
对于我这种情况，大概率是因为我本地调试的时候，Xcode 给我自动注册了一个 Bundle ID。
但是网上还有一些朋友，因为在 Xcode 中同时使用了免费的和付费的帐号，但是在测试的时候无意之间使用免费账户申请了 Bundle ID，那么上架的时候也挺麻烦的。
经历了上述的大坑之后，给未来想要开发 iOS 应用的人避坑指南，那就是如果已经确定了当前应用的 Bundle ID，请第一时间到 Apple 开发者页面注册该 Bundle ID。
基于上面的调查，现在我的解决方案要不就是更换 Bundle ID，要不就是等待现在的 Provision Profile 过期，然后重新注册，但是官方没有任何信息说过期多久可以注册。根据一些博主的分享，说如果临时被注册，大约 1 周左右临时的 Profile 会过期。
