直接回复未走 Chat 优化的踩坑复盘（STAR）
背景在一次编排改造后，用户输入“帮我查今天的炉次生产情况”，系统返回了： 工具参数需要补充/修正（缺少参数: fnCode）… 这类回复有两个问题： 对话体验差：像在看内部错误，不像助手对话。 信息暴露风险：把内部参数名（fnCode）直接暴露给用户。 本文只记录编排与文案层面的坑和改造，不包含联调过程。 STAR 复盘S（Situation）当时的流程是： plan 识别到缺
ats_iot_ai 重构复盘：从旧编排到 LangGraph 节点化拆分
这篇文章复盘 ats_iot_ai 这一轮重构的关键路径，重点覆盖三部分： 重构记录（发生了什么、按什么顺序推进） 工程收益（稳定性、可维护性、协作成本） 风险与后续计划（哪些问题还在，下一步怎么收敛） 文中时间线和提交号均来自本地仓库历史；敏感信息（内部域名、token、账号、绝对路径）已全部脱敏。 一、重构背景：为什么必须从“旧编排”走向节点化旧阶段的核心问题并不是“功能不工作”，而是“功
踩坑复盘：ObjectMapper 被覆盖引发 shiftBeginAt/shiftDate 连锁异常
这次排障最核心的坑，不是某个 DTO 字段写错，而是 ObjectMapper 被覆盖后出现多实例分叉。shiftBeginAt 返回数组、shiftDate 反序列化报错，是同一个根因触发的两个表象。 关联提交（按你本地排障记录）： 8ba6d3c5914c23f29cd52f5326c79af4a0e8eced 49957ccc62e80014546bf5a62685e9c73f0d8000
一次被 Metadata Lock 隐藏的 AI 聊天故障：从 CommunicationsException 到长事务排查
这篇文章记录一次线上故障：Java 应用里一条普通查询，最终抛出来的是 CommunicationsException。表面看像网络或连接池问题，实际是被 DDL 等待放大的 metadata lock。 排查过程横跨 4 层： MySQL DDL 与 metadata lock 机制 JDBC 驱动的超时表现 连接池里的空闲连接与未结束事务 应用层对异常语义的误判 先说结论根因是： 某些旧
本地启动 iot-app 禁用 Kafka 配置实践
本地联调 iot-app 时，常见诉求是继续读取 Nacos 里的大部分配置，但不要连接 Kafka。直接把 Nacos 配置删掉通常不现实，因为同一个应用还依赖数据库、Redis、业务开关等其他远程配置。 这次采用的做法是：保留 Nacos 配置加载，只在 local 环境禁用 Kafka 自动装配和消费者注册，同时提供一个 no-op KafkaTemplate，让依赖 KafkaTempla
HBuilderX 改了 uni-app 代码后，怎么在微信开发者工具里看到更新
这篇整理一次最近联调 uni-app 小程序时连续踩到的几个坑： 改了 accountPage.vue 和 pages.json，微信开发者工具里就是看不到更新 HBuilderX 运行到微信开发者工具时，微信侧没有自动拿到最新项目 登录时报错： 1login:fail 系统错误，错误码：41002, appid missing [undefined] 本机 Java 服务联调时报错： 1
单模型编排四阶段改造复盘：从提示词、护栏到记忆与清理
这次复盘对应 sample_ai_service 近期一轮比较完整的单模型编排内核治理。目标不是“再做一套新框架”，而是在不改外部 API 契约、不打乱 SSE 事件语义的前提下，把原本耦合较重的编排实现，收敛成可以继续演进的 runtime 分层。 先给结论：这轮改造真正完成的，不是几个 helper 函数的搬家，而是把项目推进到了“单 LLM 编排 + Java MCP 工具执行”的清晰架构上
项目技术选型调研：通用Agent与LangGraph+LlamaIndex对比
这篇文章基于实际业务场景（原子查询工具 + RAG 分析）给出技术选型依据，重点对比 OpenClaw 这类强 Agent 项目与 LangGraph + LlamaIndex 组合方案。 1. 调研结论（先给结论）对于当前项目定位（“可控的数据查询与分析助手”，而非“全自主代码代理”），推荐主选型为： 编排内核：LangGraph 数据/RAG 层：LlamaIndex 工程护栏参考