奥卡姆剃刀式瘦身重构：ats_iot_ai AI 控制面分类复盘
这次复盘记录的是 ats_iot_ai 一轮典型的「奥卡姆剃刀式瘦身重构」：不再追求架构层面的概念完整性，而是优先保证主流程简单、稳定、可持续迭代。 背景：项目开始失控，必须回到核心 flow随着功能和抽象层不断叠加，编排链路已经从“可理解”滑向“难维护”：策略层、评估层、策略守卫与验证层交织，导致新增一个行为就要跨多个抽象点改动。这轮重构的目标很明确：聚焦核心 flow，把系统重新收敛到一条可解
PyCharm 调试 Uvicorn/FastAPI 与日志可见性排查
最近在调试一个 FastAPI + Uvicorn 的项目时，遇到两个高频问题： PyCharm 里到底怎么正确配 uvicorn main:app？ 代码里明明写了 LOGGER.info(...)，控制台却看不到日志？ 这篇只讲可直接落地的做法。 1) PyCharm 里如何用 Uvicorn 调试新增一个 Python 类型 Run Configuration： Run: Module
AI Chat 重构总复盘：Java MCP 收口、LLM 路由与稳定性治理
目标与边界本轮重构的目标是把 AI 聊天从“Java 单体链路”收敛为“Python 控制平面 + Java MCP 执行平面”，并解决线上已暴露的问题： 普通聊天误入 ReAct MCP 工具失败导致 run 直接失败 Qwen 超时后返回 echo 联调时 Python/Java token 不一致导致 MCP 401 边界上，Java 只保留 MCP + Tool 能力；会话编
AI控制面生产化改造：LLM意图路由与ReAct执行边界
这次改造把 ats_iot_ai 的 Orchestrator 从 MVP 规则路由，切到生产模式的 LLM 驱动编排。 背景线上痛点很明确：process_input 里 IntentRouter.route(query) 主要依赖模式匹配，无法稳定处理语义歧义、槽位缺失和复杂意图。与此同时，React 执行层存在 query 二次解析，执行边界不够清晰。 目标是把链路拉直为： Understa
ReAct Orchestrator 意图识别升级：踩坑与 QA 纪要
这篇记录来自一次真实的架构评审：我们发现当前 Orchestrator 在意图识别阶段还偏“query直通”，导致后续策略选择和工具调用容易偏离用户真实意图。本文沉淀核心踩坑、关键 QA 结论和可执行改造路径。 背景当前链路已经可用：/ai/runs + SSE + Tool Call。但意图层的主要问题是： 路由以规则/关键词为主，语义理解和槽位抽取不足。 Policy 更像静态映射
Java/Python MCP 401 排查里程碑：Token 对齐与方案简化
本篇记录本次 Java/Python MCP 401 问题的收敛结论、方案调整与发布证据。 里程碑结论 401 根因已确认：Java 侧与 Python 侧在 MCP 鉴权 token 上不一致，导致请求头 X-AI-MCP-TOKEN 校验失败。 方案已简化：Python 侧仅保留一个配置入口 MCP_API_TOKEN，默认值固定为 AAA，移除复杂 fallback 链路，减少歧义
RAG可插拔改造复盘：OpenSearch混合检索、RRF与增量Ingest
一句话结论这轮我把 RAG 从“单一本地检索”改造成“可插拔检索链路”：新增 OpenSearch Provider（BM25+向量+过滤）、Hybrid RRF、低置信/复杂 Query 的 rerank 触发、分钟级增量 ingest + upsert，并通过 fallback + 默认开关关闭确保 /ai/runs 主链路稳定不受影响。 Done 标准 检索 Provider 可
Customized Spec：我的 AI 开发流程规范（PO/架构师监管 + 多Agent并行）
这不是“多加一层流程”，而是把已经在做的事情变成可复用、可审计、可并行扩展的工程规范。 为什么要做这份 Spec过去 AI 研发里最常见的问题不是“模型不够强”，而是： 需求口径经常漂移，执行层只能边做边猜。 多个 Agent 并行时，边界不清，返工和冲突频繁。 结果难复盘，出了问题只能靠个人记忆追责。 所以我把流程标准化为 Customized Spec：用 PO/架构师做监管闭环