全栈 SDD 开发中，最常见也最致命的错误是：让 AI 从零开始写代码。AI 模型具备"通识能力"，给它一个需求描述，它确实能生成可运行的代码。但问题在于，这些代码往往是"外星代码"：风格不一致（命名规范、目录结构、分层方式与项目现有代码不同）、复用率低（没有利用项目已有的公共组件、工具函数、请求封装）、采纳率低（Code Review 时后端同学看到"外来风格"的代码，会产生大量修改意见）。结果就是：AI 生成了代码，但 Review 成本和返工成本反而更高了。
本项目构建了一个网关路由 AI 安全审计系统，采用"通用 Agent + 业务 Skill"分层设计，增量日检/存量月检。落地 Open 网关路由越权漏洞检测流程，通过 AI 批量筛查 + 人工深度验证的人机协同模式，为大规模 API 安全审计提供了可复用的智能化解决方案。充分发挥通用 Agent 能力，业务逻辑在 Skill 中快速迭代。
随着交易业务的快速增长，对质量保障工作提出了更高标准与全新要求。为提升研发体验和架构升级，大量后台页面经历从 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 平台进行了自动化能力的建设与升级，通过系统化的平台能力优化，降低人工运维费力度，提升整体运维效率与服务质量。
