AI Coding 的下半场：把团队踩坑史，炼成可召回的经验资产
01 一个被纠正过两次的坑
半年前，团队在用 AI Coding 开发一个上报功能。AI 给出了同步上报的实现，单看合情合理，绝大多数上报场景同步就够了。Review 时改掉：必须异步，否则 stop hook 阻塞进程，后续操作全部超时。AI 接受反馈，修正代码，session 正常关闭。
问题出在 session 结束之后。
一周后，另一位同事的 session 触发同一场景。AI 没有上次的上下文，再次给出同步上报。这位同事不是原始开发者，Review 时没识别出陷阱，代码合入，直到测试环境才炸出来：进程阻塞，一连串超时。
这不是 AI 能力问题。它在第一次 session 里被纠正过，表现很好。但那次纠正只存在于发起 session 的开发者脑子里，AI 对此毫无记忆。这就是经验断层：纠正发生在会话内，价值蒸发在会话外。
把镜头拉远，团队深入使用 AI Coding 后，四类症状反复出现：
- 经验即抛：一轮 session 反复纠偏踩出的路径，结束即清零，下一个人从零起步；
- 重复踩坑：「这个目录访问第三方服务要走特殊代理」「模块间开关引用不能用字符串参数，时机问题会导致永远默认关」，这类隐性约束写在 git blame 里，从不进文档；
- 知识碎片化：老员工脑子里的 pattern 没人有动力沉淀，文档永远追不上代码变更，AI 时代靠上下文碰巧覆盖历史，本质是碰运气；
- AI 永远是新同事：不缺编码能力，缺的是这个团队的语境，架构边界、历史包袱、踩过的坑，一概不知。
所以命题不是「怎么让 AI 写代码更快」，而是打破 AI 每次进项目都从零开始的循环：需要一套能持续捕获、提纯、沉淀团队经验，让 AI 带着项目语境进场的系统。
02 初版翻车：90% 的产出是废料
最初的方案直白得近乎天真：借 CodeBuddy 的 Plugin Hook 上报全部研发对话，让 AI 读对话自动提取经验。Prompt 核心就一句「提取你认为有价值的内容」，边界判断、排除规则全交给模型。
链路两步：对话上报 → 经验抽取 → 入库。
上线后很快发现，产出里约 90% 是废经验。这里的「废」不是主观感受，判定标准只有一个：被召回后，Agent 的行为是否发生正向改变。而且废不是一个废法，是四层结构性问题叠加：
- 噪声极高：原始对话充斥「继续」「重试一下」「换个方式」和大量失败路径。这是过程录像，不是经验。系统某次抽出「多试几次就好了」，这是碰运气，不是沉淀判断；
- 上下文脱离：抽出「stop hook 需要异步处理」，听起来对，但这条规则只适用特定环节。不加限定条件，会误导 Agent 在所有 hook 场景无差别异步，造出新 bug；
- 错误引导：比没经验更糟的是错的经验。「超时就调大超时参数」入库后，Agent 下次优先调参数而不是排查根因，系统性走错路；
- 价值难定义：「遇到复杂问题多收集上下文」永远正确，但 Agent 看完不知道下一步该干嘛。
四层问题指向同一个事实：过程录像不等于经验。自动提取放大候选集的同时，同步放大噪声。不加过滤的自动提取，就是垃圾放大器。让 AI 自己判断自己产出的价值，等于裁判兼运动员，工程上无效。
03 现成方案为什么都不行
翻车之后系统性盘了一遍业界的 Agent 经验管理方案：
| 方案 | 定位 | 机制 | 局限 |
|---|---|---|---|
| ClaudeCode AutoDream | 单会话记忆整理 | ExtractMemories 抽取实体/偏好/状态，Auto Dream 异步合并 | 无团队边界，把过程记忆当永久记忆存 |
| Hermes Agent | Prompt 驱动的 memory 策略 | 任务成功/踩坑解决等条件触发回顾 | 解决「何时记」，解决不了「记的东西值不值」，缺系统级去重与来源追溯 |
| Mem0 | Agent 长期记忆基础设施 | ADD/UPDATE/DELETE/NONE 四类判定 + 混合检索 | 假设「记忆大体有价值」，在编程场景的高噪声对话里不成立 |
三者共同指向一个取向：聚焦个人记忆，追求记住更多。而团队经验治理要的是反向操作：聚焦经验质量，留下更少但更可信，每条都带适用场景、约束边界、来源证据。业界没有现成答案，只能自己建。
04 先定义资产：什么才算「团队经验」
经验系统的最终用户不是人，是 Agent。Agent 的工作方式很明确：接收输入（含召回的经验），做出决策，产生输出。由此推出唯一判定标准：
一条信息被召回后，Agent 能否产生正向的行为变更。
这把「经验」从「一段有价值的文本」锚定到「能否改变 Agent 行为」上，成为可验证的工程标准。合格经验需同时满足：来自真实对话、有证据支撑、项目特有、非通用常识、相似场景可复用。其中最关键的是不容易直接发现：Agent 自己能推出来的，召回它没有增量价值。
「不容易直接发现」怎么客观判定？按 Agent 理解需求的路径拆成三个镜头：
| 镜头 | 障碍本质 | 典型场景 | 信息缺口 |
|---|---|---|---|
| 黑话镜头 | 语义不可发现 | 「D 站」字面只是字母 D | 需显式映射为「盗版站点」 |
| 索引镜头 | 位置不可发现 | 直达页面功能在哪 | 需显式指向 xhome 模块 FastCutXXX |
| 逻辑镜头 | 行为不可发现 | stop hook 同步上报 | 常规推理推不出并发阻塞风险 |
这三个镜头不按主题、不按重要性划分，那些维度要么列不完，要么依赖主观判断。认知障碍是客观的：一条信息 Agent 能不能自己发现，可以判定。
05 链路不是设计出来的，是被问题逼出来的
初版两步链路能跑通，跑起来后问题逐个暴露，每个环节都对应一个真实问题，而不是凭空加的工序：
- 问题 1：原始对话一股脑喂模型，主题混杂、噪声大、上下文溢出。经验需要看「失败 → 纠正 → 修复 → 采纳」的完整过程 → 新增主题分组，按 session 大纲切分片段后逐个提取；
- 问题 2：提取即入库，约 90% 是垃圾 → 新增 Review 质量审核，入库前设闸口；
- 问题 3：不同分组、不同 session 产出重复候选 → 新增 Dedup 候选去重；
- 问题 4：入库后无法长期维护，新旧经验关系是糊涂账 → 新增 Merge 历史合并，判断新建、更新、跳过还是冲突。
最终收敛为：
对话上报 → 主题分组 → 经验抽取 → Review → Dedup → Merge → 入库 → 召回统计一个反直觉的对照实验值得记住：给分组片段额外附上 session 上下文大纲的那组，产出了更多垃圾。大纲引导模型做泛化推断，反而偏离了片段里实际发生的具体经验。分组本身的粒度就够了。
06 三层治理：从「能跑」到「能用」
链路搭好只是起点，让系统可靠的是 Review、Dedup、Merge 三层治理。三层目标不同、策略不同、默认方向不同，底层驱动方式一致：错例分析 → 规则抽象 → 评测验证。
6.1 抽取源头：先研究垃圾，再反推好经验
「好经验」难一次定义到位，「垃圾经验」的特征更容易归纳。大量标注后收敛出九类典型垃圾：事实性错误、通用常识、对话摘要、一次性 case、用户主观偏好、缺少上下文、粒度混用、不可执行、证据不足。
九类特征走两条工程化路径。标注路径：候选经验三档价值标注（高价值/低价值/垃圾），垃圾做归因，归纳成标注规则与 Reviewer 标准，形成的评测集持续用于所有 prompt 修改的效果测量。可审计路径：要求模型为每条经验输出三维解释，为什么这是经验、命中了哪些排除规则、哪几轮对话是证据，让判断过程脱离黑盒，错例可定位。
Prompt 迭代从此不是「感觉不好改一下试试」，而是固定闭环：
固定对话样本 → 当前 prompt 提取 → 与人工标注对齐 → 错例分析 → 修改 prompt → 重新评测 → 对比指标变化三个指标一起看：Recall 看该提的提了多少，Precision 看提出来的有多少不是垃圾，Garbage Rate 看不该提的提了多少。只看一个必翻车：只看 Precision 模型会过度保守，只看 Recall 垃圾会反弹。
6.2 Review：默认保留、定向过滤，引入源码探索做事实校验
Review 的定位是入库前拦住明确垃圾，策略是默认保留、定向过滤：只对事实性错误/偏好、缺上下文、粒度混用三类做精准拦截，外加无经验类别兜底。背后的风险判断是：漏掉一条高价值经验的代价，大于放行两条边缘经验。裁决框架收敛为四步，三轮迭代后垃圾率从 8.8% 降至 5.0%（5 轮、116 样本）。
纯文本判断有天然局限：模型无法验证经验里的技术事实是否真实存在。一条真实案例：系统抽出经验称 Android 列表开发对接 FastScrollBar 应使用attachToQBListView()。文字上逻辑自洽，有场景、有方法名、有操作指引，纯文本 Review 大概率放行。引入源码探索后在代码库检索该类定义，发现它只有attachToRecyclerView()和attach()两个方法，目标方法根本不存在，正确的是FastScrollBarCompat.attachToQBRecyclerView()。经验被标记事实性错误，直接拦截。
如果这条入库，Agent 会按指示调用不存在的方法，编译失败后还会怀疑是自己理解有误，而不是经验有问题，陷入反复重试的恶性循环。
6.3 Dedup：宁严勿宽，禁止桥接合并
Dedup 的核心风险不是漏去重，是误去重：两条本该独立保留的经验被错误合并，边界污染是永久性的。四条严格否决规则：
- When 不同不能合，场景不同就是两条经验；
- 主结论类型不同不能合，操作建议、风险规避、排查方法不混为一谈；
- 局部子机制和完整系统经验不能合，粒度不一致不互相替代；
- 同一技术事实但用途不同不能合，同一条 API 既用于性能优化又用于兼容处理，不因「都涉及它」而合并。
最关键的一条：禁止桥接式合并。A 与 B 重叠、B 与 C 相关，推不出 A 与 C 重复。语义相似不等于经验等价，一旦桥接归并，边界信息永久丢失。
评测数据（260 条经验、4 个分组）：整体 F1 71.79%；最核心的严格重复场景（What 与 When 均相同）Recall 达 91.67%。值得注意的是批次差异：batch_004 仅识别出 6 个人工正例中的 1 个，其正例全部落在非「双强一致」组合上，说明去重 prompt 对边界的敏感度随输入分布变化仍有波动。
6.4 Merge：唯一目标先行，保护历史边界
Merge 是入库前最后一关，执行四种动作：create（无同类目标，新建）、update（同向且有实质新信息，合并）、skip（核心结论可互相替代，跳过）、contradict（核心冲突，标记后交人工裁决）。三条策略主线：
- 唯一目标判定前置：先从历史库召回相关子集，判断是否存在唯一最合适的目标经验。没有就默认回退 create，从根上避免「强行匹配」污染边界；
- Update 必须自检：合并后 When 是否过度泛化、What 是否保留最具体最安全最可执行的建议、Why 是否保留核心机制、是否引入原始经验不支持的新结论。Update 过判是当前最突出问题：Recall 96.30% 但 Precision 只有 78.79%，模型有明显的「积极合并」倾向；
- Contradict 不自动放过、不自动决断：冲突是团队新旧认知不一致的信号，本身有价值，系统只标记，人裁决。
六轮实验、157 个样本：整体 F1 94.27%；Create 最稳（F1 96.46%）；Skip 的 Precision 100% 但 Recall 85.71%；Update 改进空间最大。
07 跑起来之后：数据与生命周期
三层治理漏斗全程跑通后，从初版 90% 抽取垃圾率，到治理后 95% 有效率，再到平均 80% 最终入库率。目前系统已在 QQ 浏览器团队6 个仓库常态化运行，覆盖50+ 名研发，累计采集1,236 次独立对话，提取1,022 条候选经验，最终入库789 条高置信经验，Pipeline 稳定运行30+ 次。
看一次真实运行（2026/05/27）的漏斗：39 条原始对话 → 提取 34 条候选 → Review 拦截 3 条 → 与历史库合并 1 条 → 最终入库 30 条，总转化率 88.2%。
- 被拦的反例：「ForbiddenController 新增禁用能力须同步改三处」。拦截理由很精准：它在罗列修改清单，告诉读者去哪找、改什么，而不是说明隐藏技术事实，命中 S4_NOT_EXPERIENCE；
- 被放行的正例：「Chromium 源代码层只能通过 hooks 层访问 UBA 功能」，表达的是不易察觉的技术事实后果，通过并入库。
召回侧没有重新造轮子，深度复用已有基建：治理通过的经验自动写入IWIKI 经验空间，Knot 知识库实时监听并生成向量与关键词索引，通过标准 MCP 协议桥接，Agent 在 session 期间自动检索并注入上下文，另有监控旁路记录召回成功率。最新 125 次真实开发检索：请求级召回率68.8%，未命中率仅4.8%，平均每次注入2.4 条，平均检索耗时1,299 ms。在 TDev 驱动需求实现的流程里，探索阶段会自动触发历史经验召回。这种架构让团队把全部精力压在最核心的「经验提纯与治理」上。
08 四条可复用的工程原则
- 先定义资产边界，再做自动化沉淀。不回答「什么算经验、什么不算、判断标准是什么」就启动自动提取，系统会把对话摘要、通用建议、一次性 case 全塞进来。关键不是多提取，是高置信地沉淀；
- 分层治理，别用一个 prompt 解决所有问题。Review 拦垃圾、Dedup 候选集内去重、Merge 治理历史库，各层目标、指标、prompt 设计都不同。揉在一起会互相牵制，多个针对性模型各做一件事，比一个通用模型全包更可靠；
- 默认策略按业务风险分别设计，没有统一答案。Review 默认保留（误杀高价值的代价大于放行垃圾）、Dedup 宁严勿宽（误合并的边界污染不可逆）、Merge 保护历史边界（已验证资产需要更高门槛才能被修改）。「宁可错杀」与「宁可放过」的方向在各层完全相反；
- Prompt 优化从错例中抽象规则，不是凭感觉改。收集错例 → 识别误判类型 → 抽象成可操作规则 → 多轮实验验证 → 判断正向收益，用固定评测集防数据泄露和过拟合。这是工程链路，不是手艺活。
09 结语：从「能用」到「可靠」的三道关卡
系统从 0 到 1 已经跑通，但要从「能用」走到「可靠」，还有三个环环相扣的方向：
- 经验质量（生产阶段）：垃圾率已降至约 5%，但事实性错误仍难纯文本识别，源码探索只覆盖部分场景，三个镜头之外的边界类型未充分识别，评测集规模有限，prompt 迭代边际收益在收窄；
- 使用效率（召回阶段）：命中不等于采纳，目前缺乏观测 Agent 是否真的依据经验改变行为的手段；相似主题下容易出现「召回了但用不上」；
- 管理维护（生命周期）：长期未命中、未采纳的经验没有自动淘汰机制，库在静默膨胀；项目演进时历史经验可能集体失效，缺少自动识别「需要复核」的能力。
三者构成闭环：生产决定基线 → 使用暴露问题 → 维护反哺生产。任一环不闭合，经验系统就会从资产退回为噪声。
最后一句话值得抄下来：经验系统的本质不是技术系统，是团队认知能力的工程化管道。过去经验在人脑里、产出在文档里；现在经验产生于人与 AI 的对话过程，需要一条管道来捕获、提纯、分发。管道建成后，团队知识传承不再依赖「谁在那个时间段做了什么」，AI 每次进场，都带着这个团队积累了什么、在什么场景该怎么做的语境。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～