某次Code Review时发现一段逻辑明显写错了位置，询问作者为何如此实现，得到的回答让人无奈："我知道应该加在哪里，但那个文件已经几千行，几十个if-else嵌套在一起，需求排期很紧，评估了一下，要看懂那部分代码至少需要大半天，还不确定改完会不会影响其他逻辑，所以就先这样了。而且还有几个需求因为代码过于复杂，一直没能上线。" 回顾最近代码提交记录，类似的"绕道实现"出现了十余次。这种妥协正在形成恶性循环：每一次绕道都让原本该修改的模块更加复杂，下一个开发者面对同样需求时会发现理解成本更高，于是选择继续绕道。到了不得不改变的时候了，几个月前，我开始重构推荐系统粗排服务。
大模型的成功并非偶然——从早期符号主义AI的失败，到深度学习的崛起，再到Transformer的成功，每一次进化都是从无数被淘汰的算法、模型中艰难诞生。在这艰难曲折的探索中，人类智慧的金块无疑是AI头上的一盏明灯。反过来，大模型的进化经验，能否成为我们人类认知进化的营养？由此，我们破茧成蝶，与AI时代同频共振，开启认知与智慧的跃迁。
随着公司业务的快速发展，前端平台作为研发职能部门，在高效支撑业务迭代的同时，前端新建的应用不断增加，截止到2023年5月在Uraya平台统计的各业务域的应用（B端+C端）总数已经达到170多个，发布流程中出现问题的风险逐步显现，稳定性问题逐步突出。为了更好的维护应用的代码，解决潜在的稳定性问题风险，2023年6月做了前端大仓的技术调研并在7月开始试行前端大仓的研发模式，在2024年年初开始对前端大仓应用的稳定性进行体系化治理，近2年时间的治理，前端大仓的应用无论在代码质量还是流程统一上都达到了一定的稳定程度，应用稳定性的治理达到了不错的效果，从未出现因大仓稳定性治理导致的线上问题。
本文从“道、法、术”三个层面对比AI工程与传统软件工程的异同，指出AI工程并非推倒重来，而是在传统工程坚实基础上，为应对大模型带来的不确定性（如概率性输出、幻觉、高延迟等）所进行的架构升级：在“道”上，从追求绝对正确转向管理概率预期；在“法”上，延续分层解耦、高可用等原则，但建模重心转向上下文工程与不确定性边界控制；在“术”上，融合传统工程基本功与AI新工具（如Context Engineering、轨迹可视化、多维评估体系），最终以确定性架构驾驭不确定性智能，实现可靠价值交付。
本文从原理到实践系统地分享了如何高效使用AI编程工具。涵盖其底层机制（如Token计算、工具调用、Codebase索引与Merkle Tree）、提升对话质量的方法（如规则设置、渐进式开发）、实际应用场景（如代码检索、绘图生成、问题排查），并推荐了结合AI的编码最佳实践，包括文档、注释、命名规范和安全合规，旨在帮助不同经验水平的开发者真正把AI工具用好。
在人工智能的演进历程中，大语言模型展现出了令人惊叹的文本生成能力，但其“黑箱”特性也带来了显著挑战——模型经常产生看似合理但实际错误的“幻觉”回答，缺乏透明推理过程，且无法与外部世界交互获取实时信息。ReAct（Reasoning+Acting）通过将思考过程外显化和工具使用标准化，构建了一个可解释、可验证、可扩展的智能体架构。本文将深入剖析ReAct的核心原理、技术架构及其对整个AI领域的深远影响。
本文主要介绍了针对热点深库存下单抢购场景，库存团队设计并实现的一种基于Redis分桶扣减计数和合并提交扣减DB的方案；该方案基于分布式缓存实现，但也能做到不超卖不少卖，在保证扣减强一致性的同时，也提升了库存热点扣减TPS和扣减稳定性。
在 KMP + Compose 成为主流原生 UI 技术栈的背景下，业务对“动态化”的诉求正从依赖 WebView 或独立渲染体系，转向在不破坏现有渲染链路、不新增 DSL、且不影响核心页面性能的前提下，实现更细粒度、可控的动态交付能力。本文由支付宝终端技术团队潘云逸(法慧)编写，结合工程实践，提出了一种基于 Kotlin/JS + Compose Runtime + Native Skia 的局部动态化方案：由 JS 侧负责 UI 计算，Native 侧复用既有 Skia 渲染栈完成最终上屏，在原生 Compose 页面中实现区块级、脚本驱动的动态 UI 嵌入。
