今年我从一家待了三年的公司离职，回南京找工作。第一场面试，对面没问我 JVM 调参，也没问分布式锁，开口三个问题：用 vibe coding 了吗？哪个模型？用到什么程度？

那一刻我清楚，风向变了。这篇文章不贩卖焦虑，讲一个做了八年 Java 的人，为什么不急着转行。

写 Java 写久了，你总会撞见一些让人血压升高的代码。

查个用户信息，请求要先从 Controller 跳到 Facade，再到 Service、BizManager、DomainService，最后才落到 Repository。六层调用，前五层除了转发参数什么都没干。一个打折功能，满减和折扣两种规则而已，却被设计成策略接口 + 两个实现 + 一个工厂 + 一个反射注册中心。还有个日活不到五百的内部系统，被拆成十几个微服务，改一行代码要拉五个团队开会。

这些代码看着都挺"专业"：模式齐整、分层规范、架构图画满一整屏。可它们干的是同一件事——把本来简单的问题搞复杂了。这就是过度设计。

电商的交互方式长期被"搜索框 + 筛选器"统治：用户得会打字、会组织关键词、会在一堆参数里勾选。可真实世界里，我们想买东西时脱口而出的往往是「我想换个手机，预算 3000 以内，主要拍照用」——一句话里同时塞了品类、预算、使用场景。能不能让系统像导购一样听懂这句话，主动把缺的信息问清楚，再挑出合适的商品念给你听？

这是我最近在做的个人项目 语音购物助手（Voice Shopping） 想解决的核心问题。它基于多智能体（Multi-Agent）架构，用户全程语音交互，系统自动完成意图理解、需求澄清、商品推荐、情感应答，全链路流式处理：ASR → Agent → TTS，WebSocket 全双工通信。本文从需求和功能两个角度，聊聊这个项目是怎么把"听懂人话的导购"这件事拆解落地的。

后端面试问到深处，绕来绕去都是那几个词：高并发、高可用、高性能。八股文铺天盖地，知识点一个比一个全，可真到了设计一个系统，或者回答"你用 X 解决过什么问题"这种开放题时，能把 MySQL、缓存、消息队列、微服务、ES 与 MongoDB 这五块串成一条线的人不多。

这篇是我梳理后端核心知识时画的一张总图：每个主题都配了一张思维导图当导航，知识点尽量覆盖全，关键的"为什么"和容易踩的坑补几句。每个主题结尾留一句记忆抓手，面试时能快速想起来。

最近博客停更两周，没摸鱼，是把所有时间都砸在了一个新项目 voice-shopping 上 —— 一个基于多智能体的语音购物助手。但比项目本身更值得说的是：整个项目我没写一行"自由发挥"的代码，全程用 OpenSpec 的 Spec Coding 流程驱动 Claude Code 来做。这篇就不展开聊技术栈了，重点说说 OpenSpec 这套玩法在真实项目里到底怎么跑、踩了哪些坑、什么场景下值。

用 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）完成开发。本文将全面介绍项目的设计思路、技术架构和开发历程。