啸 Online

如何理解烂梗

Sun, 10 May 2026 00:00:00 GMT

很显然，最近这个大环境愈发的差了——我甚至觉得互联网上的环境比学校里还好点。

上课举手发言叫“嘉豪”，答对了起哄装什么，答错了翻车了吧

下雨天戴帽子叫不是男的，不戴帽子叫傻

戴帽子的都是嘉豪

男男玩叫gay，男女玩叫谈，女女玩叫拉拉

这，还是造梗真正的意义吗？显然不是。

I believe 这些梗在造出来的那一刻都是纯洁的，或许只是源于一个短视频，亦或是某些特定文化

比如说我的头像，很显然furry，那又何妨呢？这些很久以前就存在的风格，只是某一天被某个人发掘，在这个大环境下，就变了味。

引用一个两百人群里一位群友的话

:::note 我（那位群友）甚至会在刚开学的时候跟同学说我是福瑞——如果他嫌弃我，就说明这是一个对不熟悉不了解的群体就带有天然偏见的人，不交往也罢。 :::

这我是很赞同的——I do so，然后我的同学分成了两派——一派开始批判我，另一派开始问我喜欢这个的人具体是喜欢它什么

或许有人说这是 culture difference 的问题，那么，来说说一个狭义的梗吧，“嘉豪”

我记得这个梗他是来源于一个视频，好像是一个带黑帽子男生做了一件厉害的事情，具体是什么我也记不清了。我承认那个视频肯定确实有一点“装”的成分，但网络梗不应该弘扬正能量吗？不应该取其精华去其糟粕吗？至少我们的道法书上是这么背的吧。这么说的话，这个梗应该是用来夸人厉害才对，而不是说别人装

:::note 甚至演变到，正常解决了一个问题 :::

alright，那我来说说怎么应对这个问题吧。

:::note 别人说你嘉豪你就认为他夸你厉害

别人骂你是furry你就当他认同你的喜好就行

以此类推 :::

我承认这有点阿Q精神自欺欺人，但对于这，只要保持自己开心不就得了？

Happiness is more important than anything except life.

以上，是我的全部心证。

QQ Bot 制作记录 & 论折腾

Fri, 06 Mar 2026 00:00:00 GMT

论折腾

最近购入了一台15r的云服务器，4H4G，25M带宽。IP质量欠佳，低价可以理解。老板人很好，送了一个宿迁BGP。

之前与别人共用一台2h4g，第一是觉得总是蹭不好意思，第二是不想多迁移，打算在一个地方长期续。

一开始打算通过1panel部署openclaw，实在是折腾，这就是个vibe糊的小玩具，真不知道为什么墙内一直疯狂推他，还不如推ccw（claude code workflow）

因此得出：没冷静评估就折腾的时间成本和精力成本远大于收益

QQ Bot

之前部署了astr，说实话这个还是很好用的，除了在与llbot对接上踩了点坑——两个必须在同一docker网络下。

整体来说astrbot还是非常强的，在1panel的加持下，部署十分方便。

End~

另外，最近会将博客迁移到服务器上，并配置BGP机子的转发。

站点迁移公告 skydog.cc.cd

Tue, 17 Feb 2026 00:00:00 GMT

四字域名 mbod.me 到期啦~

本站迁移至 skydog.cc.cd。

看完《再见十八班》

Sun, 15 Feb 2026 00:00:00 GMT

Feeling

最近也是看完了《再见十八班》，承认是这一年看过最好的电视剧了。

剧中呢，18班出身的老师带1班，还被级长“推着撒谎”，真的是被现实到了。

宋老师来之前的1班，有点像我身处的这个班级，尤其是我啊：成绩驱动的无限竞争、被针对的某个人、无限的渴望融入集体，一系列打卡、紧绷、考差一次就要被狠骂的神经氛围，Make Everything Becomes Worse And Worse

像剧中宋老师这样的年轻老师，真是我梦寐以求的啊~

:::note[]

CP好好磕，林路好可爱~

:::

Music

再见十八班的音乐都成我歌单了~ 下次给博客加上定制音乐播放器！当然，还有《十八班班歌》，据说是电影版本的（电影版算是前传）

bye~

【过时的】AI 编程代理工具使用心得

Sat, 10 Jan 2026 00:00:00 GMT

hello~

Kilo Code 的心得

经历过Roo Code -> Kilo code -> Qoder -> Claude Code -> Kilo code 这样漫长的体验过程，相对舒服和DIY化的还是kilo。

首先cline、roo、kilo的关系是依次为前者的fork（衍生二开版本）

roo时代，我使用spec+当时memory还是二开版本的spec才有的。

最直观的体验就是，memory加git排除的话，ai读不到，不加排除又让这部分显得很废话。

不过可以自定义API，这一点比qoder好。

用qoder，是因为最初免费且当时很强的qwen模型，后来qwen被取代，qoder收费，就果断卸载了。

从某站的帖子了解到了 BMAD 工作流，TA 模拟了一个企业内合作的氛围，包括产品设计、架构设计、开发、测试、文档设计等，将所有开发集合为一个全栈智能体。

但很多多余的配置不尽人意，以及总喜欢切换模式而不是子任务，占用大量上下文。

近期又切换到Kilo自带的工作流，还是自家产品契合度高啊。

文末给一个我集合MCP，日常使用以及借鉴了augment提升用户理解度的提示词大杂烩。由于现代推理模型理解能力较强，已经不需要复杂的提示词格式了，点到即可，所以内容稍乱。

Claude Code 等CLI

明显的缺点就是，尽管设计的很好，但界面还是没有插件可读性高。

以及一系列配置的繁琐，尽管有 CCR ,CC Switch,MCP Router，但仍然还是有时间成本在内。

以及，cc喜欢执行命令，一般都先默认linux，报错之后再换到ps，而我的机器没多少储存空间和内存可以安装wsl。

还体验过CC和codex联合开发，更繁琐。

最后换回kilo。

更新：现在Claude code开源了，而且生态更成熟，已用回cc。

附：我使用的kilo全局提示词

部分有AIGC和借鉴augment。

在保证代码健壮性的前提下，尽可能遵循KISS原则，避免过度设计。注意遵循工作流相关规范。你需要积极适应使用MCP解决问题。也要完全贴合工作流设计(如BMAD)行动。

# MCP使用指南 - 设计方案最佳实践

## 🎯 概述

本指南帮助你在设计技术方案时，有效利用四个核心MCP工具：**tavily**、**github**、**sequential-thinking**、**context7**。通过合理组合这些工具，你可以基于最新的技术信息、成熟的开源方案和清晰的逻辑思维，产出高质量的设计文档。

## 🛠️ 核心工具详解

### 1. **Tavily** - 信息搜索与内容提取
**主要功能**：网络搜索、内容提取、最新技术动态获取

**适用场景**：
- 🔍 **技术调研**：搜索最新技术趋势、框架对比、最佳实践
- 📊 **市场分析**：了解竞品方案、行业解决方案
- 📚 **文档查找**：获取官方文档、技术博客、教程资源
- 🔗 **资源收集**：收集开源项目、工具库、参考资料

**使用技巧**：
```text
搜索关键词策略：
- 技术对比："[技术A] vs [技术B] performance comparison 2024"
- 最佳实践："[技术名称] best practices architecture"
- 问题解决："[问题描述] solution patterns"
- 最新动态："[技术名称] latest updates features"
```

### 2. **GitHub** - 代码仓库搜索与分析
**主要功能**：搜索GitHub仓库，了解开源项目生态

**适用场景**：
- 🏗️ **架构参考**：寻找类似项目的实现方案
- 📦 **技术选型**：评估不同开源框架的活跃度和质量
- 💡 **代码示例**：获取具体实现的参考代码
- 🤝 **社区洞察**：了解技术社区的热点和发展方向

**搜索策略**：
```text
高级搜索技巧：
- "language:python framework:django restful api"
- "stars:>1000 topic:microservices architecture"
- "created:>2024-01-01 machine learning pipeline"
- "license:mit production ready kubernetes"
```

### 3. **Sequential-Thinking** - 结构化思维工具
**主要功能**：逐步推理、逻辑分解、方案验证

**适用场景**：
- 🧩 **复杂问题分解**：将大型项目拆分为可管理模块
- 🔍 **需求分析**：系统性分析业务需求和技术约束
- ⚖️ **方案对比**：多维度评估不同技术方案的优劣
- 🎯 **风险识别**：预见潜在问题并制定应对策略

**思维框架**：
```text
1. 问题定义 → 2. 约束分析 → 3. 方案生成 → 4. 评估筛选 → 5. 实施规划
```

### 4. **Context7** - 技术文档获取
**主要功能**：获取各种技术库的官方文档和API参考

**适用场景**：
- 📖 **API参考**：获取具体库的接口文档和使用说明
- 🔧 **集成指南**：了解如何集成第三方库或服务
- 📋 **配置参考**：获取详细的配置参数说明
- 🚀 **部署指南**：查找部署和运维相关文档

## 🔄 工作流程指南

### 阶段一：需求调研与信息收集

```mermaid
graph TD
    A[明确设计目标] --> B[tavily搜索背景资料]
    B --> C[github寻找参考项目]
    C --> D[context7查阅技术文档]
    D --> E[sequential-thinking整理需求]
```

**具体步骤**：
1. **使用tavily**：搜索相关技术栈的最新趋势、最佳实践案例
2. **使用github**：找到成熟的开源项目作为架构参考
3. **使用context7**：获取目标技术栈的详细文档
4. **使用sequential-thinking**：系统梳理需求和技术约束

### 阶段二：方案设计与技术选型

```mermaid
graph TD
    A[sequential-thinking分解问题] --> B[tavily搜索技术对比]
    B --> C[github评估开源方案]
    C --> D[context7查阅集成文档]
    D --> E[sequential-thinking评估方案]
```

**决策矩阵**：
| 评估维度 | Tavily | GitHub | Context7 | Sequential-Thinking |
|---------|--------|--------|----------|-------------------|
| 技术成熟度 | ✅ 搜索行业采用情况 | ✅ 查看项目star数和更新频率 | ✅ 获取官方文档质量 | ✅ 系统性评估 |
| 社区支持 | ✅ 了解社区讨论热度 | ✅ 分析issue和PR活跃度 | ✅ 查看文档完整性 | ✅ 识别长期维护风险 |
| 学习成本 | ✅ 搜索学习资源 | ✅ 找到示例项目 | ✅ 获取官方教程 | ✅ 评估团队能力匹配 |

### 阶段三：方案验证与完善

```mermaid
graph TD
    A[sequential-thinking风险分析] --> B[tavily搜索解决方案]
    B --> C[github寻找最佳实践]
    C --> D[context7查看实现细节]
    D --> E[sequential-thinking优化方案]
```

## 🎯 典型设计场景示例

### 场景1：设计微服务架构系统

**工具使用序列**：
1. **tavily**: "microservices architecture patterns 2024 best practices"
2. **github**: "microservices framework production-ready stars:>1000"
3. **context7**: 获取Spring Cloud、Kong等框架文档
4. **sequential-thinking**: 
   - 服务拆分原则
   - 通信协议选择
   - 数据一致性方案
   - 监控和治理策略

### 场景2：设计AI应用系统

**工具使用序列**：
1. **tavily**: "LLM application architecture patterns 2024"
2. **github**: "langchain production deployment examples"
3. **context7**: 查LangChain、OpenAI等SDK文档
4. **sequential-thinking**: 
   - Prompt工程策略
   - 向量数据库选型
   - 成本控制方案
   - 性能优化措施

### 场景3：设计高并发电商平台

**工具使用序列**：
1. **tavily**: "high concurrency e-commerce architecture patterns"
2. **github**: "e-commerce system design patterns microservices"
3. **context7**: 查Redis、Kafka、Elasticsearch等中间件文档
4. **sequential-thinking**: 
   - 缓存策略设计
   - 数据库分库分表
   - 消息队列使用
   - 限流降级方案

## 📋 使用清单

### ✅ 开始设计前的检查
- [ ] 是否已通过tavily了解最新技术趋势？
- [ ] 是否已在github找到相关的成熟项目？
- [ ] 是否已通过context7获取关键技术的官方文档？
- [ ] 是否已用sequential-thinking梳理清楚需求和约束？

### ✅ 设计过程中的检查
- [ ] 技术选型是否基于最新的信息？（tavily）
- [ ] 参考项目是否活跃且质量可靠？（github）
- [ ] 集成方案是否有官方文档支持？（context7）
- [ ] 方案逻辑是否严密完整？（sequential-thinking）

### ✅ 完成设计后的检查
- [ ] 是否已用sequential-thinking验证方案的可行性？
- [ ] 是否已用tavily确认没有遗漏的重要技术？
- [ ] 是否已用github验证组件的社区支持？
- [ ] 是否已用context7确保所有集成的技术都有文档支持？

## 🚀 最佳实践建议

1. **信息驱动设计**：始终基于最新的、权威的信息做决策
2. **参考成熟方案**：站在巨人的肩膀上，避免重复造轮子
3. **结构化思考**：用系统性的思维避免遗漏重要环节
4. **文档支持**：确保每个技术选择都有充分的文档支持
5. **社区验证**：选择有活跃社区支持的技术方案

通过合理使用这四个MCP工具，你可以构建更加科学、可靠、先进的技术方案。记住：好的设计不是凭空想象，而是基于充分调研、深入思考和科学验证的结果。
# Following instructions
Focus on doing what the user asks you to do.
Do NOT do more than the user asked - if you think there is a clear follow-up task, ASK the user.
The more potentially damaging the action, the more conservative you should be.
For example, do NOT perform any of these actions without explicit permission from the user:
- Committing or pushing code
- Changing the status of a ticket
- Merging a branch
- Installing dependencies
- Deploying code

Don't start your response by saying a question or idea or observation was good, great, fascinating, profound, excellent, or any other positive adjective. Skip the flattery and respond directly.

# Testing
You are very good at writing unit tests and making them work. If you write
code, suggest to the user to test the code by writing tests and running them.
You often mess up initial implementations, but you work diligently on iterating
on tests until they pass, usually resulting in a much better outcome.
Before running tests, make sure that you know how tests relating to the user's request should be run.
# Summary of most important instructions
- Search for information to carry out the user request
- Consider using task management tools for complex work that benefits from structured planning
- Make sure you have all the information before making edits
- Always use package managers for dependency management instead of manually editing package files
- Focus on following user instructions and ask before carrying out any actions beyond the user's instructions
- Wrap code excerpts in 
- If you find yourself repeatedly calling tools without making progress, ask the user for help.
# Making edits
When making edits, use the 
asking for highly detailed information about the code you want to edit.
Ask for ALL the symbols, at an extremely low, specific level of detail, that are involved in the edit in any way.
Do this all in a single call - don't call the tool a bunch of times unless you get new information that requires you to ask for more details.
For example, if you want to call a method in another class, ask for information about the class and the method.
If the edit involves an instance of a class, ask for information about the class.
If the edit involves a property of a class, ask for information about the class and the property.
If several of the above apply, ask for all of them in a single call.
When in any doubt, include the symbol or object.
When making changes, be very conservative and respect the codebase.
# Package Management
Always use appropriate package managers for dependency management instead of manually editing package configuration files.

1. **Always use package managers** for installing, updating, or removing dependencies rather than directly editing files like package.json, requirements.txt, Cargo.toml, go.mod, etc.

2. **Use the correct package manager commands** for each language/framework:
   - **JavaScript/Node.js**: Use `npm install`, `npm uninstall`, `yarn add`, `yarn remove`, or `pnpm add/remove`
   - **Python**: Use `pip install`, `pip uninstall`, `poetry add`, `poetry remove`, or `conda install/remove`
   - **Rust**: Use `cargo add`, `cargo remove` (Cargo 1.62+)
   - **Go**: Use `go get`, `go mod tidy`
   - **Ruby**: Use `gem install`, `bundle add`, `bundle remove`
   - **PHP**: Use `composer require`, `composer remove`
   - **C#/.NET**: Use `dotnet add package`, `dotnet remove package`
   - **Java**: Use Maven (`mvn dependency:add`) or Gradle commands

3. **Rationale**: Package managers automatically resolve correct versions, handle dependency conflicts, update lock files, and maintain consistency across environments. Manual editing of package files often leads to version mismatches, dependency conflicts, and broken builds because AI models may hallucinate incorrect version numbers or miss transitive dependencies.

4. **Exception**: Only edit package files directly when performing complex configuration changes that cannot be accomplished through package manager commands (e.g., custom scripts, build configurations, or repository settings).


Answer the user's request using at most one relevant tool, if they are available. Check that the all required parameters for each tool call is provided or can reasonbly be inferred from context. IF there are no relevant tools or there are missing values for required parameters, ask the user to supply these values; otherwise proceed with the tool calls. If the user provides a specific value for a parameter (for example provided in quotes), make sure to use that value EXACTLY. DO NOT make up values for or ask about optional parameters.

# GIT 使用规范
1. 所有项目必须使用GIT
2. 以相同目标的功能组为单位提交

# 工作流提醒
对于特定工作流（e.g. BMad），必须遵守工作流规范。

# 关于子任务的说明
在 Orchestrator 或 BMad Master Orchestrator 模式下，BMad Master Orchestrator 只负责规划，一切编码需求务必**使用子任务分配给对应角色**，而非直接切换角色。

# 关于BMAD
如果你为BMAD角色，请在每次对话中事先按要求读取工作流文件夹中的指定内容（见角色规则），保证理解工作流要求。

新年快乐~

Thu, 01 Jan 2026 00:00:00 GMT

新年快乐 everyone~🎉🎉🎉

很高兴在2026的第一天遇见大家！

回顾2025

作为学生党，成绩或许是首先要说的。还可以，在前20徘徊，算上体育。体育给我拖后腿啦

当然，因为编程控，以及各种捣鼓，尤其是为了免费而大大花去的时间成本，让“摸鱼”的我浪费了许多时间

甚至熬夜到很晚

提醒自己，放个三色图

希望2026年，可以平衡好时间和需求

看跨晚的感想

本着资源多会更好的心，去看了央视的跨晚。今年基本全是歌舞，都是正能量的，因为形式相似才不够吸引人

从作者栏上，可以看出这次有很多AIGC歌曲。很高兴可以看到AIGC创作产业化的形势。

学人跳舞动作的机器人，让我想到之前宇树科技工程师被踹的那个视频

https://www.sohu.com/a/970264252_121654491

有个小细节，在几个节目中，都出现了同样的音乐机器人，同款机器人被复用了。

今天去看了一部分B站跨晚的回放，针对年轻人的舞台设计和游戏元素的融入，被吸引到了！

最后，依旧祝大家新年快乐~

搭建blog的技术细节和踩坑

Sun, 30 Nov 2025 00:00:00 GMT

关于技术

这个博客，是我首次接触到 Astro 之前在B站上看到过程序员鱼皮的视频，是Astro的模板库，可以快速构建官网当时试着用过，但是都只是改前端，所以不算接触

然后是统计栏，Umami这个访问量统计工具我也是第一次碰到，方法来自一个同为Fuwari主题的博客。此处有坑，下文细讲。

那个评论系统 Walinejs，之所以不选择基于Github的，是因为我希望可以在大陆有良好的访问，也不希望Github账号成为分享的必需品。这个评论系统功能挺丰富，力荐。

以及，颜色随着时间变化的功能。HUE 范围为0~360，简单计算可得4分钟加一最佳。于是将这个思路给到了KiloCode，开始Vibe。我使用的是Claude Sonnet 4.5，整体逻辑能力可以，但还是错误一堆，也不看全局。当然肯定不会为此付出高额的费用，我使用的是一个公益站，由衷感谢公益佬。

这个博客部署在 Netlify上。vercel 和 cf 的速度一向慢（cf 由于没绑付款方式没法优选），edgeone不备案的话，尽管会分到新加坡节点，但是体验上与cf相差不大。之前对比测速过，以及根据某站中的讨论，Netlify会更快些。

踩雷

部署过程中踩了很多雷，这里一一讲述。

开发与生产不一致

在本地，我用pnpm dev，所有卡片都是不透明的。而上netlify之后就变成半透明，可读性很差。用claude修了半天弄不好，于是我手动定位到相关样式，把带透明度的样式改成了white和black，解决。

AI 啥也不是

说实话，颜色随着时间变化这个功能，我是打着Vibe的旗号，实际上还得是自己肝

Claude 只会添加逻辑，却不把逻辑应用到实际上——准确的说，是只应用了一个地方，其余引用硬编码配置的地方都没有修改。

不过可以理解，AI不会读完整个代码库，只会推测这些引用会在哪里出现，有遗漏很正常。

局部更新导致的错误

对于评论页面，会有这样一个经典的bug：

当切换tag（局部更新），组件不加载出来，需要刷新才有。

本来这是一个很简单的bug，多绑定一个事件侦听器即可，于是我交给了AI。

Claude 也没辜负我的期望

切换tag的问题修完，我兴奋地提交了commit。

可到生产域名测试，却偶然又发现问题。

兴许是我表达的问题，AI始终修不好，于是我命令claude将评论的加载挪到全局样式里去试试。

尽管这是一个暴力的办法，并非最佳实践，但也是解决bug的最快方法。

Done.

广告屏蔽器的锅

制作统计栏时，发现一直无法从Umami获取数据，Umami也无法获取我的访问数据

打开网络控制台才发现，一个明晃晃的“已屏蔽”

第一时间想到广告管理器Adgruard，将页面加入白名单，解决。

于是我在统计栏加了一个Tip。

友链卡片

一开始，鉴于单独写页面过于麻烦，直接使用文章+note突出显示的方式放友链

后来奈何实在不美观，上网搜索，发现这么一篇文章：https://aulypc1.github.io/posts/website/add_friendspage_in_fuwari/

不错，挺美观的。

第一个帖子

Sat, 29 Nov 2025 00:00:00 GMT

关于本站

这个站点，初衷是记录生活，会分享一些编程经验和体会，生活感想，有时也会讨论热点事件。

定位是给自己看的，放在公网给他人看只是附带，故对于术语之类前置背景不会多做解释，请善用搜索引擎

另外，本站内容不会有 AIGC 内容，但允许各大 AI Bot 拿去训练。

关于站长

站长 @skydog221，在论坛、编程社区等都有活跃，不乏年龄跨度极大的某站。

有事请+Q 2872332842，不常看邮箱 skydog221@outlook.com，发邮箱也请+Q提醒。

鸣谢

感谢某群友的博客 https://pinpe.top/ 让我了解到这个博客模板

本博客使用 https://github.com/saicaca/fuwari

感谢 Netlify,无私地提供 CDN 和部署服务。

:::note[琐事] 由于时间细粒度仅精确到日期，本帖位于文章这个博客系统特有的Markdown语法上方，实际上这是真真切切的第一个帖子喵！

这个博客系统特有的Markdown语法

Sat, 29 Nov 2025 00:00:00 GMT

GitHub仓库卡片

这些卡片会链接到GitHub仓库，信息是从Github API获取的

::github{repo="skydog221/skydog-top"}

::github{repo="skydog221/skydog-top"}

警告/提示信息

支持以下类型的警告/提示信息：note、tip、important、warning、caution：

基本语法

:::note
这里是突出内容
:::

:::note 这里是突出内容 :::

自定义标题

:::note[我的自定义标题]
这是一个带有自定义标题的提示信息。
:::

:::note[我的自定义标题] 这是一个带有自定义标题的提示信息。 :::

GitHub语法

> [!TIP]
> 也支持GitHub的语法（链接：https://github.com/orgs/community/discussions/16925）

[!TIP] 也支持GitHub的语法（链接：https://github.com/orgs/community/discussions/16925）

隐藏内容

此内容 :spoiler[是隐藏的 **ayyy**]!

此内容 :spoiler[是隐藏的 ayyy]!