基于大模型与RAG的团队经验自动传承系统实践

团队经验的积累几乎是每个技术团队都会头疼的问题。老员工脑子里全是踩坑多年换来的“实战心得”可一旦离职或者转岗这些东西就跟着人走了新人只能再从零踩一遍。文档库倒是建了可真正愿意认真写文档的人没几个写出来的东西也经常过期关键时刻还得靠“问人”。我在腾讯开源的大模型与 AI 智能体生态基础上搭了一套团队经验自动传承系统半年用下来新人上手速度明显加快很多重复问题不再需要“人肉答疑”经验从“个人记忆”变成了“团队资产”。这套东西的核心思路并不复杂把团队日常工作里产生的零散信息代码提交、工单、群聊讨论、排障记录自动采集起来用开源大模型做加工整理再用 RAG检索增强生成的方式按需提供给团队里的任何人。说白了就是给团队配一个“什么都知道一点的 AI 老师傅”。这篇文章我从头到尾讲清楚这套系统的设计思路、核心实现和实际落地过程中踩过的坑希望能给有同样需求的朋友一些参考。1. 这套“瑞士军刀”到底解决什么问题1.1 传统知识管理的死穴文档没人写写了的又过期大部分团队现在的知识沉淀方式无非就是 wiki、语雀、飞书文档、Confluence 之类的工具。听起来很正规但实际用起来就会发现三个绕不开的问题。第一个问题是“没人写”。写文档这件事对大多数工程师来说属于“重要但不紧急”的事平时开发任务排得满满当当哪有心思去整理什么知识沉淀结果就是文档库常年停留在项目初期那几篇架构说明。第二个问题是“写了的会过期”。系统的架构在变配置在改排障手段在迭代可文档一旦写完就没人维护了半年后再看里面的命令可能早就跑不通。第三个问题是“知识找不到”。就算文档库里有内容检索体验也一言难尽关键词稍微不对就什么都搜不到最后大家还是选择去群里问人。传统知识管理工具本质上是“被动存储”它假设人会主动去写、主动去维护、主动去检索。但人的天性是图省事与其写文档不如直接敲个消息问旁边的人。所以指望靠自觉来沉淀知识基本都会失败。1.2 腾讯开源生态给了什么基础能力我选择在腾讯开源的技术栈上搭这套系统主要是看中了三个层面的能力。第一是大模型底座。腾讯开源的混元大模型系列现在社区已经有不同参数规模的版本可以用从能跑在普通开发机上的小模型到需要多卡部署的大模型都有覆盖这意味着我可以根据团队的硬件情况灵活选择。第二是智能体框架。近两年腾讯开源了不少 AI Agent 方向的框架和组件比如 HunyuanAgent 这类把“大模型工具调用任务编排”整合起来的基础设施用它可以省去很多自己搭轮子的时间。第三是开源社区生态。腾讯云和腾讯开源的很多项目在活跃维护用的时候遇到问题能在社区找到不少现成的踩坑经验。不过真正让我决定用这套组合的还是因为一个很现实的原因——“可私有化部署”。团队内部的代码、工单、聊天记录这些数据很多都涉及内部信息根本不可能传到外部的 AI 服务上。腾讯开源的大模型和框架支持完全私有化部署数据不出内网这一点对技术团队来说是刚需。1.3 整体设计思路五层架构让经验“自动流动”这套系统整体上分五层每一层解决一个问题采集层从代码仓库、工单系统、IM 群聊、服务器日志等源头把零散的经验信息自动捞出来。加工层用大模型对原始材料进行清洗、摘要、分类、去重把“噪音”变成“知识卡片”。存储层把加工后的知识做向量化存入向量数据库同时保留结构化元数据。检索层基于向量相似度和关键词匹配在用户提问时召回最相关的知识片段。分发层通过问答机器人、周报、新人指引等场景主动或被动地把知识送到需要的人面前。这套设计里最核心的思路转变是从“人找知识”变成“知识找人”。传统方案是用户自己去文档库里翻而我希望达到的效果是——AI 自动把团队里散落的经验整理好当有人遇到问题时它已经在旁边准备好答案了。2. 从零搭建经验传承系统核心环节拆解2.1 经验采集数据从哪来怎么捞最省力采集是整个系统的基础如果采集环节做不好后面加工的原料就没有保障。我在实践过程中发现与其指望大家“主动提交经验”不如从日常工作的“副产品”里自动挖取这样成本最低、覆盖最全。我优先接的几个数据源是这样的Git 提交记录与代码评审每次代码提交和评审讨论其实都隐含了大量“为什么这么做”的信息。我写了一个采集脚本定时拉取 Git 仓库的提交日志把 commit message、文件变更、关联的 issue 编号、评审意见一起抓下来再交给大模型打标签并生成摘要。工单与故障记录内部工单系统里每一条“问题描述→排查过程→最终解决”的记录都是一份极好的经验样本。这部分数据的价值密度非常高因为它天然就是“问题答案”的结构化形式。IM 群聊中的技术讨论技术群里每天都有大量的问答有人提问、有人解答、有人追问、有人补充这就是最鲜活的隐性知识。我用机器人监听指定群组把技术讨论串抓取下来存到消息队列里备用。服务器日志与告警事件每次线上故障的日志片段、监控告警事件配合后续的处置记录可以形成“故障复盘”类的知识条目。有个实际操作中的提醒采集一定要“抓大放小”不要一开始就追求把所有数据源全部接入。很多团队卡在“数据湖”阶段就是因为想把所有东西都存下来结果存了一堆没用的数据清洗成本高得吓人。比较好的做法是先用工单系统Git 提交这两个门槛最低、价值最高的数据源跑通全流程再逐步扩展数据源。2.2 知识加工怎么把“噪音”变成干净的“知识卡片”原始数据不能直接进知识库必须经过加工这就好比再好的食材也得经过烹饪才能上桌。加工这步我交给“大模型流水线”来做具体分这么几步清洗去掉无意义的日志噪音、错误码堆砌、聊天里的表情和语气词。结构化把一条原始记录变成一个“知识卡片”包含问题描述、原因分析、解决方案、关联标签、发生时间、来源方方等字段。摘要与重写长篇幅的技术讨论用大模型压缩成 200 字以内的核心摘要如果原文口述痕迹太重就重写成更清晰的表述。分类与打标签按技术栈、系统模块、问题类型网络、存储、代码逻辑、配置等自动分类方便后续检索过滤。这里我想多说一句重写环节的度的问题。有些团队的 AI 工程师喜欢把知识卡片做得特别“干净专业”结果反而丢失了原始语境的细节比如排查问题时顺手试过哪些无效路径、哪些命令带错了参数、哪个配置在哪个版本里才生效这些“琐碎细节”恰恰是经验最有价值的部分。我的做法是保留“原始记录AI 摘要”双份存储摘要用于快速检索而原始记录作为附录供人深入查看。2.3 存储与检索向量数据库选型和 RAG 召回策略知识加工完之后就要入库。我选用的方案是“向量数据库关系型数据库”双写向量库负责语义检索关系库负责管理元数据和权限。向量化这一层我用了开源的中文 Embedding 模型 bge-large-zh原因就一条——中文效果确实比同级别的通用 Embedding 要好常见的 ELO 评测里它在中文场景中排得靠前而且 Apache 2.0 协议可以放心商用。这张 Embedding 模型在 512 token 的输入长度下表现最好这是后面确定切片大小的重要依据。向量数据库方面小规模部署我用 Chroma零配置、开箱即用规模上来了之后切到 Qdrant 或 Milvus性能更好、过滤能力更强。选型时我没有一上来就上最重的分布式方案因为对一个知识库系统来说数据量短期内到不了千万级单机的向量库完全够用没必要用复杂度和运维成本都很高的重型组件。检索策略上我采用的是“向量召回关键词召回重排序”三阶流水线。先用向量检索召回 top 50 的候选片段再用基于 BM25 的关键词检索召回 top 30然后合并去重交给一个重排序模型bge-reranker-base打分最后取 top 5 片段作为上下文送给大模型生成答案。这套组合实现起来不复杂但对答案质量的提升非常明显远比单纯做向量检索要稳。2.4 智能分发问答机器人、排障建议、新人指引加工好的知识最终要“送”到需要的人手里我做了三个比较实用的分发场景。第一个是智能问答机器人。这是最基础也最常用的场景团队成员在 IM 里直接 机器人提问比如“TSF 部署超时怎么排查”机器人会基于知识库给出带来源引用的回答。这个机器人的价值在于把老师傅的“私人经验”变成团队的“公共资源”而且回答质量不会因为提问者的人缘好坏而波动。第二个是排障建议推送。我把告警事件和知识库打通当监控系统发出某类告警时比如 Redis 连接数飙高AI 会结合历史排查记录自动生成一份“本次告警可能的原因和参考处理步骤”推送给值班同学。等于是给值班人员配了一个对这套系统非常熟悉的“虚拟搭班老师傅”。第三个是新人入门指引。新人入职时最迷茫的是不知道“遇到问题该找谁、该去哪查、该关注什么”。我开发了一键生成功能输入新人负责的模块系统自动从知识库里提炼出该模块涉及的常用术语、典型问题、关键系统文档、常见操作步骤生成一份专属入门手册。3. 实操落地我实现的最小可用系统3.1 环境准备模型部署与依赖安装先说一下我这个最小可用系统的部署环境。因为要私有化部署我没有依赖任何外部 API 服务选型如下大模型使用 Ollama 部署开源模型 qwen2.5:14b 作为生成模型这个参数量在 64G 内存的机器上用 CPU 能跑加一张 24G 显存的显卡体验更流畅。Embedding 模型bge-large-zh-v1.5负责文本向量化。重排序模型bge-reranker-base负责召回结果再排序。向量数据库Chroma 0.4.22。应用框架Python FastAPI 提供检索接口前端用一个轻量级的 Vue 页面做展示。安装依赖pip install fastapi uvicorn chromadb requests langchain-community ollama部署模型ollama pull qwen2.5:14b ollama pull bge-large-zh:latest这里有个小建议Embedding 模型不建议用 Ollama 里的版本跑因为 Ollama 默认的 OpenAI 兼容接口返回向量是 768 维还是 1024 维和各模型权重实际配置有关调试起来容易出偏差。我后面自己加载了 bge 模型来生成向量用 Hugging Face Transformers 直接跑逻辑更清晰也方便调试。3.2 核心代码实现采集脚本、知识入库、检索问答先看采集 Git 提交记录的脚本这是经验采集最轻量的一环import subprocess import json from datetime import datetime, timedelta def fetch_git_logs(repo_path, days7): since (datetime.now() - timedelta(daysdays)).strftime(%Y-%m-%d) cmd [ git, -C, repo_path, log, f--since{since}, --prettyformat:__COMMIT__%n%H%n%an%n%ad%n%s%n%b ] output subprocess.check_output(cmd, textTrue) commits [] for block in output.split(__COMMIT__): lines block.strip().splitlines() if len(lines) 5: continue commit { hash: lines[0], author: lines[1], date: lines[2], subject: lines[3], body: \n.join(lines[4:]), files: get_changed_files(repo_path, lines[0]) } commits.append(commit) return commits def get_changed_files(repo_path, commit_hash): cmd [git, -C, repo_path, show, --name-only, --pretty, commit_hash] return subprocess.check_output(cmd, textTrue).strip().splitlines()采集到的原始数据接下来进入加工流水线核心逻辑是把提交记录组装成一份 prompt交给大模型生成知识卡片from ollama import Client ollama_client Client(hosthttp://localhost:11434) def generate_knowledge_card(commit_data): prompt f 你是一个技术知识沉淀助手。请根据下面的 Git 提交记录生成一张知识卡片。 要求 1. 提炼这次提交解决的核心问题 2. 如果涉及技术难点或踩坑重点说明 3. 输出为 JSON 格式包含 - title: 一句话标题 - problem: 问题描述 - solution: 解决方案 - tags: 标签列表 提交信息 题目{commit_data[subject]} 正文{commit_data[body]} 涉及文件{, .join(commit_data[files][:10])} response ollama_client.chat( modelqwen2.5:14b, messages[{role: user, content: prompt}] ) return response[message][content]知识入库的代码也不复杂关键是要先把文本切片再向量化。切片这一步我后面细说先看入库逻辑import chromadb from chromadb.utils import embedding_functions from transformers import AutoTokenizer, AutoModel import torch class BGEEmbeddingFunction: def __init__(self, model_nameBAAI/bge-large-zh-v1.5): self.tokenizer AutoTokenizer.from_pretrained(model_name) self.model AutoModel.from_pretrained(model_name) self.model.eval() if torch.cuda.is_available(): self.model self.model.to(cuda) def __call__(self, input): encoded self.tokenizer( input, paddingTrue, truncationTrue, max_length512, return_tensorspt ) if torch.cuda.is_available(): encoded {k: v.to(cuda) for k, v in encoded.items()} with torch.no_grad(): outputs self.model(**encoded) # 取 [CLS] 向量做句子向量 embeddings outputs.last_hidden_state[:, 0, :] embeddings torch.nn.functional.normalize(embeddings, p2, dim1) return embeddings.cpu().numpy().tolist() chroma_client chromadb.PersistentClient(path./knowledge_db) collection chroma_client.get_or_create_collection( nameteam_experience, embedding_functionBGEEmbeddingFunction() ) def add_knowledge(card_id, text, metadata): collection.add( documents[text], ids[card_id], metadatas[metadata] )检索问答的接口是 FastAPI 写的核心链路是先召回再排序再生成from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): question: str top_k: int 5 class QueryResponse(BaseModel): answer: str sources: list[dict] app.post(/ask, response_modelQueryResponse) def ask_question(req: QueryRequest): # 第一步向量召回 results collection.query( query_texts[req.question], n_resultsreq.top_k * 10, include[documents, metadatas, distances] ) # 第二步组装上下文送大模型生成回答 context_blocks [] sources [] for i, doc in enumerate(results[documents][0][:req.top_k]): context_blocks.append(f[{i1}] {doc}) sources.append({ id: results[ids][0][i], metadata: results[metadatas][0][i] }) prompt f 你是一个团队经验问答助手。请基于以下知识片段回答问题。 要求 1. 只能依据给定的知识片段回答不要编造 2. 回答时标明引用来源编号如 [1] [2] 3. 如果知识片段中找不到答案请坦诚说明“已有知识中未找到相关信息” 知识片段 {chr(10).join(context_blocks)} 问题{req.question} response ollama_client.chat( modelqwen2.5:14b, messages[{role: user, content: prompt}] ) return QueryResponse( answerresponse[message][content], sourcessources )这个最小系统从功能上看已经闭环了。采集脚本把经验喂进知识库问答接口把知识输出给使用者。实际部署的时候我用 systemd 服务把采集脚本、Ollama、FastAPI 进程全部托管日常基本不用人工干预。3.3 核心参数怎么调切片大小、召回数量、温度系数参数调优是我在这个系统上花时间最多的地方也是最直接影响使用体验的部分。这里把几个关键参数的选择逻辑写清楚。文本切片大小chunk_size。我用的 bge-large-zh-v1.5 支持最长 512 token所以初始切片大小我设的是 512 token。但实际项目里直接按 512 切效果并不好因为很多技术文档一句话就几百 token硬切很容易把完整逻辑切成碎片。我后来调整成“段落感知重叠窗口”的策略先按自然段落分块每块再统一截断到 384 token相邻块之间重叠 64 token。384 这个数值来源于大模型上下文窗口的余量考虑——检索回来的 5 个片段每个 384 token加起来约 1920 token加问题、加 Prompt 模板、加指令约束整体输入控制在 2500 token 左右给生成留足空间也避免上下文过长导致注意力分散。召回数量top_k。我一开始用 top_k3发现经常漏掉关键信息调到 10 之后虽然上下文里塞了很多内容但大模型容易被无关片段干扰回答反而变糊。最后定的是先召回 50 个候选重排序之后取 top 5。5 这个数字是在“信息完整度”和“上下文纯净度”之间反复试出来的平衡点一般技术类的问答5 个不同角度的知识片段基本能覆盖一个问题的完整答案。温度系数temperature。生成模型的知识问答场景温度设 0.1 比较稳。温度越低回答越确定越不会乱发挥。但有个小坑是推理类问题比如让 AI 对比几种方案的优劣温度太低会导致分析过于呆板。我的解决方案是在 Prompt 里区分两套指令知识问答类走严格模式分析归纳类走宽松模式而不是改全局温度。重排序阈值。bge-reranker 输出的分数是相似度概率不是标准化的距离不同模型的取值范围不太一样。我第一次用的时候直接设 0.5 作为过滤线结果发现大量本该保留的候选被过滤掉了。后来我做了归一化处理在单次查询里把所有候选分数缩放到 0 到 1 之间再取相对分数前 5。阈值这个思路在使用中要谨慎绝对阈值跨模型不通用。3.4 前端交互与团队接入后端能力有了前端和 IM 接入得跟上来不然没法真正让团队用起来。我没有做很重的管理系统而是做了一个简洁的问答页面团队内部访问输入问题就能得到带引用的答案。页面还用了一个设计——在答案尾部展示“相关经验卡片”的来源列表点击可以查看原始记录这既增加了可信度也方便用户追溯。IM 接入这里多说一句。企业微信机器人有 Webhook 回调能力可以接收群里的消息并调用后端接口这样一来团队不需要打开新页面直接在群里 机器人就能提问。我对机器人做了一层简单的指令解析比如“/ask 命令 问题内容”“/hot 查看今日热门问题”降低了使用门槛。实测下来IM 端的咨询量远远大于网页端的咨询量这可能跟大家习惯在 IM 里解决问题的行为模式有关。4. 落地过程中踩过的坑和排查方法4.1 权限与数据安全知识共享和隐私边界怎么平衡知识库落地后遇到的第一个大问题是权限。团队里不是所有人都应该看到所有经验记录比如某些敏感的故障复盘、涉及客户信息的工单、高级别技术讨论就不能对全员开放。我在权限设计上采用了“分级标注独立集合”的方案。所有知识入库时由加工层自动打上敏感等级标签公开、内部、敏感。公开级所有成员可见内部级仅限相关项目组成员敏感级只能由管理员检索。实现上不是一个集合里做查询过滤而是把不同等级的知识存到多个独立的 Chroma 集合再根据用户角色路由到对应集合。这样做的原因是 Chroma 的元数据过滤在高并发下性能一般多重集合的隔离方式能保证检索效率权限逻辑也更清晰。这里有个教训是不要在入库之后再补权限标签。我一开始偷懒先全部入库后面再补过滤策略结果很多知识没有原始分级信息漏出来一批敏感内容。最好是在加工流水线里就把分级作为固定字段从源头控制。4.2 幻觉控制怎么让 AI 少“一本正经地胡说八道”大模型回答问题最大的风险就是幻觉——它可能用看上去很专业的话编一个根本不存在的解决方案。在知识答疑场景里这种幻觉的后果可能很严重比如 AI 编造一个错误的重启命令让值班同事照着执行直接把服务搞挂了。我控制幻觉用了三层措施。第一层是 Prompt 强约束在系统 Prompt 里明确写“只能依据知识片段回答知识片段中没有的信息明确说不知道”并且要求答案带引用编号。第二层是引用溯源所有回答必须附上来源如果某个回答引用的片段与问题主题相关性低于阈值前端会提示“此回答可能缺少足够依据请谨慎参考”。第三层是“拒绝机制”当检索阶段候选片段的最高相似度分数低于某个底线我这里是相对分数低于 0.3时系统直接返回“已有知识库中未找到相关信息”不让大模型强行作答。实际运行下来这三层措施能把幻觉率压到一个比较低的水平。但要说完全消除说实话做不到大模型的生成机制决定了它天然会“脑补”我们能做的是让脑补的部分尽量少出现、出现时尽量容易被发现。4.3 新旧知识冲突过期经验怎么处理知识库里的经验不是永远正确的。系统架构变了、组件升级了、原来的解决办法可能在新版本里已经不适用了。如果知识库回复的都是过时的方案那还不如没有这个知识库。我引入了一套知识生命周期管理机制。每条知识卡片入库时会记录“生效日期”和“来源事件类型”是生产事故、版本迭代、还是日常工单。当一条知识关联的代码模块或服务有新的变更提交时系统会把旧知识标记为“待复审”状态同时通知对应模块的负责人确认是否仍然有效。每周还有一个自动巡检找出超过 90 天未被检索或引用说明大概率已无价值的知识推送给管理员做归档或删除。影响比较大的还有一个冲突检测机制当新入库的知识与已有知识在标题、标签、问题描述上高度相似但解决方案不一致时系统会标记为“冲突条目”不会直接投入检索而是等人工确认后再生效。这一步能避免团队里两个人对同一问题给出互相矛盾的处理办法被 AI 同时推给不同的人。4.4 常见问题速查表问题现象可能原因排查方式最终解决检索结果明显不相关切片大小不合理上下文被切断检查入库文档切片块观察召回片段是否语义完整改成段落感知重叠窗口切片策略回答包含编造内容Prompt 约束不足/温度过高检查是否引用编号观察温度设置加强 Prompt 约束温度降到 0.1加拒绝机制知识入库后当天检索不到向量索引没及时提交检查 Chroma 持久化路径显式调用 collection.persist()内网环境不能下载模型没有提前做模型离线包验证模型缓存目录在能联网的机器上预先拉取模型目录拷到内网中文检索效果差未使用中文优化的 Embedding观察检索召回的语义质量换用 bge-large-zh不用通用英文模型响应速度太慢单请求串行调用大模型/重排序查看接口耗时分布做并发处理重排序用异步执行老知识和新知识矛盾未做冲突检测检索同类问题看是否并存矛盾方案增加冲突检测与人工确认流程4.5 一个很实在的心得先跑通一条场景再有更多场景如果给打算做同样事情的朋友一个建议我会说“别贪多”。我最初设计的场景有十几个自动生成周报、自动分析代码质量、自动推荐技术方案……后来发现根本跑不过来光是问答这个场景就花了大半个月调优。最后真正做到稳定运行的只有“智能问答”和“告警排障建议”两个场景。我的体会是切面越小打磨越深效果越好。先用一个高频场景让团队形成习惯等大家真正用起来、开始往系统里反馈问题了再去扩展其他场景比一开始铺开更容易成功。5. 从“查询工具”升级到“自动干活”5.1 自动生成排障报告与经验卡片知识库跑稳之后我开始琢磨另一个问题能不能让这套系统不光是“被动回答问题”还能“主动产出内容”第一个尝试是排障报告的自动生成。每次线上故障处置结束后运维同事都要花大量时间写故障复盘报告。我把故障时间线、告警日志、操作记录、知识库相关条目全部丢给大模型让它自动生成一份结构化的排障报告初稿。实测下来一份原本要写一两个小时的报告现在 AI 五分钟出初稿人只需要花十分钟核对补充。而且因为系统知道知识库里有哪些相关信息生成的报告会自动关联历史故障案例和解决办法这对避免“同一类故障反复出现”非常有价值。第二是经验卡片的自动生成。现在每次工单关闭、每次故障处置完成系统都会自动尝试抽取经验卡片提交到人工审核队列。团队里的老员工只需要花一分钟点个“确认”或“修改”就能把一次根因处理变成一条新的团队知识。这个流程我之前也提过但真正跑起来之后发现实际效果比想象中好很多——因为人的负担从“主动写文档”变成了“审核 AI 写的文档”心理门槛完全不一样了。5.2 新人培养路径自动生成新人入职最头疼的是不知道从哪学起。我基于知识库做了一个“模块导学”功能输入新同学要负责的系统模块系统会自动生成一份学习路径包括该模块的架构说明、核心代码位置、常见问题和对应的解决经验、推荐阅读的文档链接、历史上该模块出现过的典型故障及复盘。这个功能本质上是把团队多年的“踩坑史”变成了一条结构化的学习路线图。新人遇到问题的时候不再是抓着一个同事就狂问而是先去知识库检索检索不到再带着已经搜索过的信息去请教老师傅。这个行为上的改变对老员工来讲也是一种“减负”。5.3 从团队到跨团队经验市场的雏形我现在正在尝试把这套系统从单个团队扩展到部门级别让不同团队的知识库可以互相检索。这意味着 A 团队处理过的 Redis 性能问题B 团队遇到类似情况时也能直接参考而不是从头查一遍。这一层的实现要比单团队复杂主要是知识格式的统一和跨团队权限的管理。不过我觉得这个方向是对的——如果每支团队的经验都能像开源组件一样在组织内部流动、复用、演进那整个组织的“记忆能力”就会越来越强。腾讯开源生态给这个方向提供的启示也在这里开源的本质是把知识变成可持续协作的公共品而我做的这套系统某种程度上就是在一个组织内部“开源”团队的经验。最后分享一个我实际体验很深的小细节。系统上线三个月后有个同事在群里发消息说“这 AI 把我以前踩过的坑竟然说出来了我看了一眼好像回到了三个月前的凌晨三点”。那一刻我意识到所谓经验传承说到底就是让后来的人不必再踩前面的人已经踩过的坑。如果你的团队也在为“经验留不住”发愁不妨试试这个方向从一个小场景开始让 AI 当那个“永不离职的大师兄”。