天猫以信号检测自动提取并沉淀工程经验

针对「超 90% 代码由 AI 生成、但知识库仍靠人工维护」的割裂，团队建立信号驱动的智能沉淀：分析发现 99% 的会话是「帮我写个按钮」这类无沉淀价值的简单问答，真正有价值的知识藏在那 1% 出问题（踩坑、试错、反复调试）的会话里，因此只对信号会话做捕获，自动沉淀三类知识——编码规范与偏好、决策与选型理由、业务模式与模板。截至 2026 年 1 月，机制在 1 个月内自动捕获 128 条经验知识，类型分布 pitfall 51%、faq 32%、decision 17%；质量上平均置信度 0.92、83% 达高置信度（0.90+）、89% 可直接入库或抽查审核；召回效果上召回率 85%、平均每次查询返回 2.3 条，pitfall 召回率最高（88%），零结果查询占 15% 用于反向补充知识缺口。典型效果：tsconfig 配置类问题解决时间从 30-60 分钟降至 1-2 分钟。 知识运营体系已在业务域 C、行业供应链、业务域 B 共 3 个业务域落地 2 个月，面向近 40 名后端同学，支撑月均 20~30 个前端需求的全栈交付，覆盖工作台 A、工作台 C、运营平台、工作台 D 等多种发布平台与大量存量页面。效果上，周反馈问题从初期的 10+ 个逐步下降到 1-2 个；正文同时说明该下降由后端同学熟悉度提升、AI 工具能力增强、知识库经验复用与协作流程优化等多因素共同作用，知识库是重要因素而非唯一因素。团队明确当前仍处于知识积累早期阶段，重点是验证「信号驱动 + 自动沉淀」机制有效性。 团队观察到同一仓库持续迭代中的需求相似度随「时间距离」衰减：较近需求（需求 3 → 需求 4）实现模式高度相似，约 60% 代码可直接参考；中等距离（需求 2 → 需求 4）设计思路相关，约 35% 架构决策可借鉴；较远（需求 1 → 需求 4）仅基础架构相关，约 15% 底层模式可参考。据此把检索策略改为优先召回同仓库内时间距离较近的需求，而不是跨仓库按关键词匹配「相似需求」。检索执行上，找到足够结果（>=3 条且相似度 >0.8）则直接返回。