随着交易业务的快速增长，对质量保障工作提出了更高标准与全新要求。为提升研发体验和架构升级，大量后台页面经历从 Vue -> React -> 全栈的迁移过程。业务演进过程中，后台能力持续迭代与优化；团队在交付新能力的同时，同步保障存量链路的稳定与可预期行为。为进一步完善测试用例覆盖范围，高效支撑回归测试与重构验证工作，需通过技术手段升级质量保障模式，为业务与架构迭代提供更充分的质量支撑。 E2E 测试：即端到端测试，是一种从用户视角出发，模拟真实操作验证应用完整业务流程的自动化测试方法。自动化生成用例：用线上内部运营操作日志自动生成 E2E 测试用例，快速覆盖核心流程，解决用例缺失问题。智能元素定位：自动识别重构等场景 UI 变化并调整定位策略，实现维护流程的自动化。平台化管理：通过数据看板管理用例和执行结果，让 E2E 测试可追踪、可优化，提升测试效率。 基于以上分析，我们致力于构建一套自动化 + 智能化的 E2E 测试方案，该方案旨在支撑快速迭代开发模式，有效应对用例覆盖与重构验证等场景，从而在现有资源条件下，持续为业务快速迭代和技术架构升级提供可靠的质量保障。
推荐系统在提升用户体验的同时，也面临着信息茧房、兴趣收敛和内容同质化的挑战。随着用户与系统交互的深入，"推荐→用户反馈→再推荐"的闭环会逐渐强化用户的少数主兴趣，导致推荐结果趋同，降低用户的新鲜感与满意度。 生成式AI技术的快速发展为推荐系统带来了新的机遇。与传统的判别式匹配范式不同，生成式召回通过预测用户下一个可能点击的内容，实现从"匹配已知"到"预测潜在"的范式转变。在得物社区这一潮流生活方式平台上，用户对内容多样性和新颖性的需求尤为突出，这为生成式召回的探索提供了天然的场景。 基于此背景，得物启动了生成式召回方向的一期探索，旨在为下一代智能推荐系统的构建积累经验，探索推荐系统的 scaling-law 规律。
做这个 Skill 的初衷很直接，也很现实：功能开发时容易"顺手新建一个"，而不是先复用已有组件，造成组件库越来越臃肿。这件事对团队的伤害其实是复利型的：重复组件越来越多；维护成本越来越高；UI/交互一致性越来越差；AI 生成代码时也更容易继续复制混乱。所以做这个 Skill 的目标不是"帮 AI 搜索一下"，而是：把"复用优先"的思考过程流程化，让 AI 在写代码前先走一遍"查索引 → 判断是否复用 → 命不中再新建"的路径。
做后端开发，调 BUG 有一个让人头疼的固定流程：打开日志平台，输入 traceId 或关键词，搜日志；从几十上百条日志里，找到关键的那几条；把日志里的类名、方法名复制出来，去 IDE 里找对应代码；结合代码逻辑，判断哪里出了问题；如果一次找不准，回去再搜日志，再翻代码…… 这个过程相对固定，但非常耗时间。每次 BUG 定位，光在日志平台和 IDE 之间来回切换，就能消耗掉大半的时间。 最开始在去年 Q3 想到这个问题的时候，脑子里浮现的第一个方案是：用 Cursor + MCP，把日志平台接进来，再挂一个代码知识库，让 AI 帮我查日志。但这个方案有缺陷 —— 日志查询是「动态的」，它依赖环境、应用、时间范围，没办法静态预置。此外，这样处理没有办法做到比较丝滑地读代码、改代码。 后来开始用 Claude Code，接触到了 Skill 的概念：可以在项目里定义一套自定义命令，描述 AI 应该怎么执行这个命令的每个步骤，于是整个思路变得清晰了。
随着业务规模与流量的持续高速增长，自建 Redis 集群面临着更高地性能与稳定性要求，对平台化、自动化运维能力也提出了新的挑战。为进一步提升资源利用效率、保障服务稳定运行，并更好地支撑业务快速发展，我们对 Redis 平台进行了自动化能力的建设与升级，通过系统化的平台能力优化，降低人工运维费力度，提升整体运维效率与服务质量。
随着以Claude Code为代表的代码大语言模型（Code Large Language Model，以下简称Code LLM）在软件工程领域的普及，其在企业级数据仓库（以下简称数仓）建设中的应用逐渐从单一的代码补全向全链路辅助演进。本文旨在探讨Code LLM在电商数仓环境下的深度集成逻辑与工程实践。文章首先界定了数据确权中的人机边界，分析了内部数据工具向Agentic工作流演进的趋势，并提出了“认知运行时与执行运行时解耦”的架构范式。 本文认为，大模型在企业级数据仓库中的落地核心，主要体现在两大维度：一是数据确权（Data Rights Confirmation），二是规范化输入输出（Standardized I/O）。以此为框架，结合得物App真实数仓建设与研发实践，系统阐述了基于Galaxy MCP的基础设施集成方案，并对智能视觉埋点、AI OneData建模、智能周报生成、策略孵化中心等典型场景的架构设计与运行逻辑进行深入分析。最后，针对大模型应用中存在的幻觉问题与合规风险，本文提出一套系统性的治理与管控机制。
在软件开发的历史进程中，每一次效率的飞跃都伴随着抽象层次的提升。从汇编语言到高级语言，从手动内存管理到垃圾回收，开发者始终在寻求降低认知负荷的方法。进入 2026 年，生成式人工智能（GenAI）已成为编程领域不可或缺的力量。然而，行业正经历从 “模型崇拜” 向 “工程落地” 的深刻转型，单纯依靠增加大语言模型（LLM）的参数规模已无法解决复杂业务逻辑中的幻觉与失控问题。 当前的共识是，AI 编码（AICoding）的真正瓶颈不在于模型的逻辑能力，而在于上下文管理（Context Management）的失效与开发意图（Intent）的模糊。
大禹平台是一个离线 Dump 平台。在不同的场景都有自己的 Dump 流程，我们这里的 Dump 特指在搜索、推荐、广告（后续简称 “搜推广”）的场景中，将异构数据源加工处理后给到索引平台做索引的流程。
在实际迭代开发中，不同需求的代码规模差异很大，有些需求涉及上千行代码，有些则只有一两行。且对于前端的代码验收，主要侧重在界面功能，通过功能验收，没法确保每一行代码都测试到的，以及功能的代码逻辑是否合理，是否健壮、是否规范等问题，都需要通过人工代码 CR 来进一步兜底验收代码的质量，尽量降低业务线上出错的可能。但当面对上千行的代码变更时，人工 CR 也是心有余而力不足。 传统的代码审查依赖人工，面对大规模代码变更时效率有限，而 AI 代码审查能够实现自动化、标准化的质量检查，有效补充人工审查的不足。
