用 AI 写代码已经快两年了。最早我也是"说一句写一句"的路子——把需求丢给 AI，它生成什么我就用什么，跑不通再追问，追问完再补。功能最后都能写出来，但回头一看代码，总觉得哪里不对劲：字段名对不上、接口路径改了三次、状态字段从枚举变成了布尔值……更崩溃的是，这种混乱会随着功能复杂度的上升指数级增长。

后来接触到了 Spec Coding 这个思路，再后来又发现了 OpenSpec 这个工具，才算找到了一种让 AI 编程真正靠谱的姿势。这篇文章把我这段时间的理解和实践做个整理。

家里有两台树莓派（Pi 3B+ 和 Pi 4B），搭配一台阿里云 ECS，通过 FRP 内网穿透把家里的服务暴露到公网。Pi 4B 上用 Docker 跑了 Dify（AI 应用开发平台）和 Home Assistant（智能家居控制中心），Pi 3B+ 作为 FRP 客户端和 Nginx 反向代理网关，ECS 则是 FRP 服务端和公网入口。本文记录这套架构的设计思路和搭建过程。

Ciff（Code It For Future）是我独立开发的一个 AI Agent 开发与运行平台，定位为简化版 Dify，面向 20-50 人小团队。支持 Agent 智能助手、知识库 RAG、工作流编排、多模型供应商适配，并提供 Web 界面和 REST API 两种交互方式。

项目从 2026 年 4 月 13 日启动，到 4 月 25 日完成全部 6 个阶段，历时约两周。后端 Java、前端 Vue 3，借助 AI 编码工具（Claude、Kimi、GLM）完成开发。本文将全面介绍项目的设计思路、技术架构和开发历程。

作为一个 Claude Code 重度用户，我经常遇到一个问题：Claude Code 在后台跑着，我切去做别的事，回来一看不知道它跑完了没有。 于是我做了一个小玩意——用 ESP32 开发板 + RGB 灯，做一个物理状态指示灯。绿灯亮着说明空闲，蓝灯闪烁说明正在思考，黄灯闪烁说明在等你确认……一眼就知道该不该切回终端了。

项目已开源：GitHub - canyuda/ClaudeCodeRGB

• 索引下推（index condition pushdown ）简称ICP，在Mysql5.6的版本上推出，用于优化查询。
• 在不使用ICP的情况下，在使用非主键索引（又叫普通索引或者二级索引）进行查询时，存储引擎通过索引检索到数据，然后返回给MySQL服务器，服务器然后判断数据是否符合条件 。
• 在使用ICP的情况下，如果存在某些被索引的列的判断条件时，MySQL服务器将这一部分判断条件传递给存储引擎，然后由存储引擎通过判断索引是否符合MySQL服务器传递的条件，只有当索引符合条件时才会将数据检索出来返回给MySQL服务器 。
• 索引条件下推优化可以减少存储引擎查询基础表的次数，也可以减少MySQL服务器从存储引擎接收数据的次数。

当Explain 与 SQL语句一起使用时，MySQL 会显示来自优化器关于SQL执行的信息。也就是说，MySQL解释了它将如何处理该语句，包括如何连接表以及什么顺序连接表等。

• 表的加载顺序
• sql 的查询类型
• 可能用到哪些索引，哪些索引又被实际使用
• 表与表之间的引用关系
• 一个表中有多少行被优化器查询 …

而为了确保核心服务的可用性，有时候我们就会故意对那些不重要的服务执行下线操作，从而确保系统中有限的资源都应用到核心服务上。这就引出了在分布式系统构建过程中非常重要的一个技术组件，即服务降级。

那么，什么是服务降级？又有那些常见的服务降级实现策略呢？

服务熔断的具体表现形式是熔断器。那么，熔断器的基本结构是怎么样的？它又是如何实现的呢？