在传统的移动端自动化体系中，Appium、UIAutomator 或基于 ADB 的脚本方案是绝对的主流。然而，作为在这个领域摸爬滚打多年的高级开发者，我们深知这些方案的痛点：强依赖 PC 宿主机、跨设备通信的 Socket 延迟、极易受 USB 线缆和网络波动影响的脆弱稳定性。当我们面对“高频、脱机、大规模集群”的 RPA（机器人流程自动化）需求时，传统外控方案往往显得力不从心。为此，本项目探索了一条完全不同的道路：彻底抛弃 PC 控制端，将大脑（逻辑控制）与手脚（事件注入）全部封装进 Android 设备本地。本文将剥开外壳，通过核心逻辑的源码级解构，带你走过这条充满坑与算计的“端侧自动化”之路，并客观剖析其当下面临的致命缺陷，以及结合 AI 的未来演进。
不知道你在面试的过程中，有没有被问到如何设计一个分布式抽奖系统？或者你很好奇，线上的这些抽奖活动，背后的原理是什么？这个项目本身并不大，但却涉及很多经典的技术点，因此也在面试中比较常见。本文根据自己最近做的一个体彩的抽奖活动，讲解了我在设计分布式抽奖系统的几个核心难点——匀速消耗、超卖、少卖等等，希望可以帮助同学们可以在面试中，更加从容地回答这些问题。
在日常研发中，AI 辅助代码审查（Code Review）已被广泛使用，但主流方案多仅依赖 Git Diff，只能看到修改片段，缺少类结构、方法依赖、跨文件调用关系等上下文，模型判断容易失真。跨模块返回值的空安全、多线程下的全局变量风险等细节，往往仍需人工反复核对。为解决这些落地问题，我们基于项目实践搭建了一套 AST（抽象语法树）驱动的方案，通过中间件调度补全完整上下文，为模型提供可追溯的结构化信息，从而稳步提升 AI Code Review 的准确性和可用性。
Feed 流（英文 “Feed” 原意为 “饲料”，引申为 “信息供给”）是基于用户关系、兴趣偏好或场景需求，以时间/算法排序为核心，持续向用户展示/推送结构化内容的动态信息展示形态。关注流就是用户关注的人或者账号（或发布源）所发布的feed内容按照时间顺序排列的流。实现关注流通常有三种方式：推模式（Push，又称写扩散）：当用户发布一条内容时，系统会立即将这条内容推送至所有关注者（粉丝）的关注流中；拉模式（Pull，又称读扩散）：当用户要查看自己的关注流时（或者用户收到红点或者数字气泡提醒时），系统实时地去拉取其所有关注对象的最新内容，然后时间倒序排序；推拉结合（Hybrid混合模式）：结合推拉两种模式，例如针对大V用户采用拉模式、普通用户采用推模式。还有其它的一些实现（优化）方式，如按粉丝活跃度进行部分推、非活跃用户延迟推、拉缓存（非实时）等等。本文主要对推模式的实现进行介绍。
从静态页面到模块化开发，前端工程化经历了怎样的演进？Webpack、Vite、Rspack 这些打包工具各自解决了什么问题，在实际项目中又该如何选择？
