用 AI Agent 控制家里的灯，让我意识到很多开发者在陷入过度工程
很多开发者在接触 AI Agent 时很容易陷入“技术自嗨”的怪圈，潜意识里认为只要 LLM 能解决，就理所当然地应该用它来实现。我这次的实操路径是这样的：首先通过语音识别捕捉我的情绪，将文本传递给 LLM 进行语义分析，接着将分析出的情感标签映射到特定的 RGB 颜色值，最后通过 API 推送到智能家居网关执行。
从技术实现层面来看，这套逻辑在代码层面几乎是完美的。为了实现精准的颜色控制，我深入研究了 LLM 的 Function Calling 机制，并定义了严格的 JSON Schema 来约束模型输出。我必须确保模型返回的是结构化数据，例如 {"color": "blue", "hex": "#0000FF"}，而不是一段随意的文学描述，否则网关根本无法解析。为了保证稳定性，我甚至在 Prompt 中加入了多轮 Few-shot 示例，强迫模型在识别到“忧郁”或“孤独”等词汇时，必须严格输出对应的十六进制颜色码。
然而，当系统真正投入使用时，现实给了我一记响亮的耳光。由于整套流程涉及语音转文字（STT）、LLM 推理以及异步 API 调用的多重链路，整个过程产生了极其明显的延迟。在实际使用场景中，我必须对着手机大喊一句“我现在觉得有点忧郁”，然后陷入死一般的寂静，等待好几秒钟，灯光才会慢吞吞地变成蓝色。而如果我直接打开智能家居 App 点一下，只需要 1 秒钟。
这次经历让我意识到，很多开发者在设计 AI 工作流时，往往只关注“技术可行性”，而忽略了“产品必要性”。我陷入了典型的成本与收益失衡：我使用了昂贵的 Token 消耗和复杂的异步调用逻辑，去替代一个简单的物理开关或快捷指令。这种设计上的脱节，正是典型的“过度工程”。
当然，这种“技术自嗨”虽然在商业价值上几乎为零，但在学习路径上确实有意义。通过这次项目的调试，我彻底搞清楚了 LLM 在实时系统中的延迟瓶颈，以及在处理高频触发任务时，模型响应时间对用户体验的毁灭性影响。
现在我在启动任何 AI 相关项目前，都会强迫自己进行一次“去 AI 化”思考：如果完全不用 AI，这个功能最简单的实现方式是什么？如果手动操作只需要 3 秒钟，那么花费巨大的开发成本去自动化它，是否真的能带来质的提升？
对于 AI Agent 的构建，最核心的竞争力不应该是“能实现多少复杂功能”，而应该是“在什么场景下，AI 的介入能产生正向的效能比”。不要为了使用 LLM 而使用 LLM，否则你最终构建的可能不是一个高效的工具，而是一个极其复杂的“电子垃圾”。
