本文详细阐述了手淘跨端业务在AI时代的演进与重构。面对跨端应用性能体验的持续优化命题，团队从0到1孵化了包含体验优化 Agent在内的5款AI技术产品，构建了覆盖“本地编码-预发发布-提测-线上运维”的全链路研发闭环。文章核心展示了体验优化 Agent如何通过整合端边云基建、RAG知识库及特定Skills（如云真机调试、自动化Coding），解决传统AI无法理解手淘复杂业务语意及SSR渲染模式的痛点，从而将优化方式从“人工诊断”推向“AI自驱与自进化”。最终，该体系实现了在无需人工干预下，利用AI完成数据回收、问题分析、代码修复及配置变更，显著提升了跨端应用的性能与稳定性。
最近深度使用了 OpenClaw，基本上每天都要跟它交流几个小时，也慢慢摸索出了一些经验。看到不少人说 OpenClaw 不好用，我想先聊聊"不好用"的原因，再深入拆解一个我认为被大多数人忽略的核心问题——OpenClaw 越用越好用的本质到底是什么。先说结论：是一堆 md 文件。
随着业务发展，国内各类 App 均朝向“超级App”的方向发展：单个 App 不再围绕单个功能开发，而是以 App 为载体建设为综合性的平台。这对存量旧手机的体验与稳定性带来了极大的挑战： Android art 虚拟机的heap内存十分有限，部分老机型即使在app标注largeHeap后还是仅有256MB； Android 9 以下版本，单个进程的fd上限为1024；部分厂商在 Android 8 以下系统版本，更是限制一个app的进程+线程数不能超过500。 本文将围绕上述的三个方向：内存、FD、线程，分别深度揭秘抖音如何挽救存量旧手机的用户体验。
2023年我们开始用 AI 辅助解决问题，2025 年我们验证了 AI Coding 的可行性，2026 年我们决定更进一步——不再让 AI 当"打字员"，而是让它当"施工队长"。这篇文章记录了我们团队在 AI Native 研发模式落地过程中的思考、踩坑和最终形成的一套可复制的方法论。
携程大数据平台运行着大规模的 Spark、Flink 计算集群，为充分发挥 JDK25 LTS 版本在内存效率与运行性能上的优势，我们启动了 JDK 升级计划，并完成了 多个引擎 对 JDK25 的适配改造，开始向生产环境灰度推进。然而就在灰度期间，我们遭遇了一个极为罕见的问题：Spark、Flink 写入的 Parquet、ORC 文件出现部分损坏——写入过程无任何报错，CRC 校验也完全通过，损坏只在下游读取时才会暴露。本文记录了我们如何从一个"Zstd 解压报错"出发，借助多款 AI 工具辅助分析，历经代码排查、JDK 版本二分、自建编译环境等多个阶段，最终将问题根因锁定到 JDK25 G1GC 的一个内部优化 Bug，并推动 OpenJDK 社区完成 backport 修复。文章还将深度解析 G1 GC 的 Optional Evacuation 机制与 JNI Pinning 原理，以及 AI 工具在整个排查链路中的具体作用。
