今天踩了几个坑，主要都和怎么用好 AI Agent，以及一些平时容易忽略的底层架构有关。随便记几笔。
别指望 AI 一把梭，老老实实拆任务
最近用 OpenClaw 这类 Agent 框架比较多，发现一个硬伤：如果你把一个高度耦合的模块或者一坨大代码直接丢给它，让它自己去“重构”或者“找 bug”，它往往会陷入死循环。不仅 Token 烧得飞快，改出来的东西还全是错的。
真正的玩法应该像 oh-my-claude 里的那个核心设计一样——使用多 worker 并发机制。对于稍微复杂点的大需求，人必须先介入，把任务拆解成互相独立的子任务，然后再派发给不同的 worker 各自去跑。也就是说，现在的重点不是让 AI 帮你敲代码，而是你得想好怎么写出一份“没有歧义、不需要太多上下文关联”的 Prompt 架构。
顺带一提，最近测试下来，Gemini 3.1 在多模态能力上确实表现抢眼，但在纯写代码和编程逻辑的把控上，目前的王者依然是 Claude，无可撼动。
RTL 排版踩坑：别想在应用层糊弄底层
今天在弄富文本系统的 RTL（从右到左，比如阿拉伯语）排版支持。一开始想得很偷懒：因为系统是基于插件的，所以就想着直接写个插件，在外层把排版的方向给截胡、强行翻转一下。
结果一跑测试就拉胯了。碰上中英文混排（Bidi）这种复杂场景，底层 Canvas 如果一开始就没设计好文字方向相关的矩阵计算，外层用插件怎么打补丁都没用，出来的文字顺序全乱套了。最后没办法，还是得老老实实去底层引入专门的 Bidi 算法库做重排。
这算是个很经典的教训：底层框架如果抽象漏了东西，千万别试图在外面用插件强行糊弄，早晚要还技术债的。
升级 Spring Boot 3.x，被 AI 狠狠坑了一把
最近在把系统往 JDK 17 升，顺便升了 Spring Boot 3.x。结果 KMS（密钥管理服务）在加载 Nacos 配置的时候死活跑不起来。
比较搞笑的是，我很久以前其实在 KMS 的代码注释里清楚地写过：“升级 Spring Boot 3.x 时要注意，因为加载机制变了，要从 bootstrap 机制迁移到 configdata。”
但是今天升级的时候我图省事，直接把代码打包扔给 AI 让它去排查报错。结果 AI 根本没注意看那些业务注释，像个没头苍蝇一样在错误的方向上顿顿乱查，浪费了大量的时间和算力，最后还是我自己下场看代码才想起来。
这说明现在的 AI 还做不到“通读你的项目历史包袱”。在没有给出精确上下文的情况下，过度依赖 AI 反而会严重拖慢排错效率。
总结
AI 浪潮下，大家都在吹“全自动编程”，但实际落地的真相是：AI 是个极其高效的流水线工人（worker），但它当不了架构师，更做不了“清道夫”。如果你的系统本身耦合严重、代码面条化，AI 也会被卡死；如果没有人类去拆解任务、画定边界，AI 只会原地空转。与其指望大模型一键帮你重构陈年烂代码，不如先靠自己把架构拆干净。人把图纸画对了，AI 这把刀才能真正快起来。